This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[#201008250001, jdk1.6] to reproduce: ------------- 1) have a NB with registered GF v3.1-b17 2) create a sample project from 'Samples > Java Web, Java Web Services, Java EE' ERROR: All the project are created with 'Missing Server Problem' You have to set the GF v3.1 as target server manually.
PetrH, is there any reason why j2ee.server.type differs for GFv3.1 and GFv3 (gfv3ee6 versus gfv3ee6wc)? That's what is causing this problem.
I don't know. I guess the plugin owner introduced that... In general I think we should not introduce more and more items that differs only in version. There might be cases when it makes sense, but its a bit strange to have items in the wizard differing in minor version.
David asks, "Why is there a difference between the two server type ID's?" The servers have different APIs and features that are exposed by 3.1 cannot be applied against a 3.0 server in some cases. I ask, "Petr, is there a way to 'order' the plugins by server type ID, so that we could test whether plugin A contains a superset of the features of server B, so a project that targets server B can be 'handled' by a server A, if a B is not available?"
(In reply to comment #3) > David asks, "Why is there a difference between the two server type ID's?" > > The servers have different APIs and features that are exposed by 3.1 cannot be > applied against a 3.0 server in some cases. Can you give a concrete example please? I thought that all what IDE is concerned about is that v3 and v31 are both EE 6 servers and therefore Web/Ejb/Ear projects created in IDE can be deployed to both of them without any difference. Or are you saying that for example for v31 we generate different version of server specific deployment descriptor?
(In reply to comment #4) > (In reply to comment #3) > > David asks, "Why is there a difference between the two server type ID's?" > > > > The servers have different APIs and features that are exposed by 3.1 cannot be > > applied against a 3.0 server in some cases. > > Can you give a concrete example please? I thought that all what IDE is > concerned about is that v3 and v31 are both EE 6 servers and therefore > Web/Ejb/Ear projects created in IDE can be deployed to both of them without any > difference. Or are you saying that for example for v31 we generate different > version of server specific deployment descriptor? yes... that is one distinction (glassfish-*.xml instead of sun-*.xml). we also do things like support restarting a remote server in debug mode when the user does 'Debug' on a project that targets a remote GF 3.1 server. the what's new for M1 and my blog cover a lot of the features that make 3.1 different from v3 and 3.0.1.
I had read NewAndWorthy and your blogs. (In reply to comment #5) > yes... that is one distinction (glassfish-*.xml instead of sun-*.xml). So web app with glassfish-xxx.xml will correctly run only on v31 but web app with sun-xxx.xml will run in both v3 and v31? Is that right? If so then I think we should be generating Web app with sun-xxx.xml so that user can deploy the app to both servers. Would not that be better? I mean in the meantime while users likely are using both versions. In NB 7.1 timeframe (an example!) when GF 3.1 is commonly used I would drop this backward compatibility. > we also > do things like support restarting a remote server in debug mode when the user > does 'Debug' on a project that targets a remote GF 3.1 server. Yes, but this is an implementation detail of GF server plugin and running server instance, no? > the what's new for M1 and my blog cover a lot of the features that make 3.1 > different from v3 and 3.0.1. There are differences but all of these (apart from new glassfish-*.xml descriptors) are GF runtime improvements. For user who built an EAR app in IDE and wants to deploy it to GlassFish it does not matter whether it is GF version 3 or GF version 3.0.1 or GF version 3.1 - all these three servers support EE 6 and therefore it is not necessary to distinguish them. If GF 3.1 provided support for a new API which is available only in JavaEE6.1 (an example!) then I would understand why we need to distinguish them. Do not get me wrong - I'm happy to distinguish servers but I would like to understand why we are doing that because it will make user's life potentially more difficult and therefore it should be justified.
How do we plan to solve this for Tomcat? It looks like it has the same problem. register a TC 5.5 server register a TC 6.0 server (if it has not been registered already) create a web app that targets the 5.5. server close the project unregister the 5.5 server open the project See the Resolve Missing Server warning.
(In reply to comment #7) > How do we plan to solve this for Tomcat? It looks like it has the same > problem. As I said giving servers different names is OK and user has to go through "Resolve Missing Server" dialog. Better then Tomcat example is GF 2.1 versus GF 3 - very different servers. But I thought and still think that GF 3 and 3.1 differ only in runtime features (in 99% cases). If we decide to keep distinction between GF 3 and 31 then Web/EE ProjectOpen hook could automatically update necessary (known) references from GF3 to GF31 if 3 is missing and 31 is available.
I think the only way to give servers different names in the 'Add Server...' wizard is to use a different server type ID value. I think that limitation is 'coded' into j2eeserver. I do not think my boss will be happy with the notion of not identifying the server release as part of the registration process.
There are many comments so rather than answering each of them I'll sum up my opinion: If it is not absolutely necessary or reasonable the plugin should not introduce new server type with each/specific release. By adding more server types the wizard screen is more and more poluted and the user has to search for proper item. If we can detect the server version, why to ask user to choose version? The different server types are ok, when the servers are significantly different such as GF2, GF3 or if the plugins do not share the same codebase (otherwise there is some internal distinction of releases and thus again no reason for new server type). I would not strictly forbid the new server type in case it is somehow justified such as GFv2 and GFv3 or WL10 and WLDWP (luckily we were able to avoid new server type for Weblogic DWP so far). The tomcat should be fixed in long term. It depends on resources we have. The Tomcat case should not be used as an example to follow imo. I don't really understand this: "I do not think my boss will be happy with the notion of not identifying the server release as part of the registration process." You can identify the server version during the registration process. Or does that mean that the user has to be forced to stop read the list of GF types and select the correct one (Did I install 3.0 or 3.1 to my harddrive?)? Is there any reason for that?
(In reply to comment #10) > There are many comments so rather than answering each of them I'll sum up my > opinion: > > If it is not absolutely necessary or reasonable the plugin should not introduce > new server type with each/specific release. By adding more server types the > wizard screen is more and more poluted and the user has to search for proper > item. If we can detect the server version, why to ask user to choose version? You see pollution. Others see user visibility... Calling out the versions prevents user confusion, too. The 'Download Now' button can be a bit tricky if the server is not called out explicitly on the first page of the 'Add Server...' dialog. > > The different server types are ok, when the servers are significantly different > such as GF2, GF3 or if the plugins do not share the same codebase (otherwise > there is some internal distinction of releases and thus again no reason for new > server type). > > I would not strictly forbid the new server type in case it is somehow justified > such as GFv2 and GFv3 or WL10 and WLDWP (luckily we were able to avoid new > server type for Weblogic DWP so far). > > The tomcat should be fixed in long term. I agree. >It depends on resources we have. The same holds true for the GF plugin. > The > Tomcat case should not be used as an example to follow imo. It is a bit late in the game to say that, don't you think? The TC plugin has been that way for a long time. > > I don't really understand this: > "I do not think my boss will be happy with the notion of not identifying the > server release as part of the registration process." The 'boss' of GF team likes to see 'GlassFish Server 3.1' in the UI of NetBeans and Eclipse. It makes it clear to users what is actually supported by the IDE and is a bit of 'advertising'. > > You can identify the server version during the registration process. Or does > that mean that the user has to be forced to stop read the list of GF types and > select the correct one (Did I install 3.0 or 3.1 to my harddrive?)? Yes... Some folks want the user to stop and read the list of supported servers. Some functions of the wizard depend on the user making an explicit choice on the first page of the 'Add Server..' wizard. >Is there > any reason for that?
> > The > > Tomcat case should not be used as an example to follow imo. > > It is a bit late in the game to say that, don't you think? The TC plugin has > been that way for a long time. Yep. It has been this way much longer than I've been with NetBeans ;) I think I would use the same approach couple of years ago. Now I think we should not use this way. It's just my opinion and perhaps I'm wrong. I'm not saying everybody should stop now and rewrite the plugins to satisfy such criteria. > > > > I don't really understand this: > > "I do not think my boss will be happy with the notion of not identifying the > > server release as part of the registration process." > > The 'boss' of GF team likes to see 'GlassFish Server 3.1' in the UI of NetBeans > and Eclipse. It makes it clear to users what is actually supported by the IDE > and is a bit of 'advertising'. I would understand that for GF2 and GF3 not for GF3 and GF3.1, possibly 3.2, 3.3 etc. I guess in case we would agreed on change it would be manager's discussion anyway. > > > > > You can identify the server version during the registration process. Or does > > that mean that the user has to be forced to stop read the list of GF types and > > select the correct one (Did I install 3.0 or 3.1 to my harddrive?)? > > Yes... Some folks want the user to stop and read the list of supported servers. > Some functions of the wizard depend on the user making an explicit choice on > the first page of the 'Add Server..' wizard. > > > >Is there > > any reason for that?
(In reply to comment #11) > > Tomcat case should not be used as an example to follow imo. > > It is a bit late in the game to say that, don't you think? The TC plugin has > been that way for a long time. We are improving rules of the game as we play it. Looking at current Add Server UI it is strange to force user to select version of the server to add. Ideally there would be one item in the list saying "GlassFish" (or perhaps "GlassFish 3.1 and older") and wizard would have description box at the bottom saying "Currently supported versions of GlassFish which can be registered in the IDE are: xx, yy, zz.". Second step of wizard would ask for server installation dir and third step would be chosen dynamically based on what GF version we are adding. That's if I look at this from UI usability point of view. I understand that marketing point of view might be different. > > I don't really understand this: > > "I do not think my boss will be happy with the notion of not identifying the > > server release as part of the registration process." > > The 'boss' of GF team likes to see 'GlassFish Server 3.1' in the UI of NetBeans > and Eclipse. It makes it clear to users what is actually supported by the IDE > and is a bit of 'advertising'. As long as this advertising involves just UI I'm fine with this. But the way it is implemented now it is causing problems to users because server type is different. You could keep "3.1" wizard in UI but generate server with the same server type as "3.0", no? > > > > > You can identify the server version during the registration process. Or does > > that mean that the user has to be forced to stop read the list of GF types and > > select the correct one (Did I install 3.0 or 3.1 to my harddrive?)? > > Yes... Some folks want the user to stop and read the list of supported servers. Put the list of supported servers in a description box underneath. > Some functions of the wizard depend on the user making an explicit choice on > the first page of the 'Add Server..' wizard. Do we think it is right design? I do not.
> You could keep "3.1" wizard in UI but generate server with the same > server type as "3.0", no? I would also favor this approach. Is it doable? > If so then I think we should be generating Web app with sun-xxx.xml so that > user can deploy the app to both servers. Would not that be better? I don't agree, I think we should encourage the best practices, and for 3.1, the best practice is to use glassfish-*.xml.
Created attachment 102407 [details] patch I would fix the bug this way. It is isolated and does not require API change. It could have one more benefit. In future we could use a list of compatible servers attached somehow to the samples instead of EQUVIVALENT_SERVERS. This way the samples would be even less server dependent.
I filed bug 191008 for multiple GF server types discussed here.
(In reply to comment #15) > Created an attachment (id=102407) [details] > patch > > I would fix the bug this way. It is isolated and does not require API change. > > It could have one more benefit. In future we could use a list of compatible > servers attached somehow to the samples instead of EQUVIVALENT_SERVERS. This > way the samples would be even less server dependent. OK. that looks great. I will assign the issue to you, since you have the fix in your workspace.
Fixed in web-main 86e7676ea90c.
(In reply to comment #14) > > If so then I think we should be generating Web app with sun-xxx.xml so that > > user can deploy the app to both servers. Would not that be better? > > I don't agree, I think we should encourage the best practices, and for 3.1, the > best practice is to use glassfish-*.xml. The best practice IMO is something what is best for user and proved to give user the least problem in long term. Well not very good definition but what I want to say is that using glassfish*.xml does not give user any benefit right now - it is just a tick box in our product feature matrix. Once there is final release of GF 3.1 and users do not have any reason to switch back to 3.0.1 then glassfish*xml is way to go. But until then users are likely to switch back to a stable 3.0.1 while testing 3.1 pre-releases. You may think I'm stubborn. And you are right. :-) But problem with issues like this one (ie. using new server type or new file descriptor) is that developers tend to ignore them until they become problem. And once they are problems it is too late - once users start using a build and generated these new descriptors or server types and later want to downgrade their server and it is not working they usually will complain and we will not be able to much about that apart from telling them to rename that descriptor file or change server by hand in proj props. Which may or may not be big deal either. But if we can solve that in advance then why not to do that?
Integrated into 'main-golden', will be available in build *201010150000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/86e7676ea90c User: Petr Hejl <phejl@netbeans.org> Log: #189828 Web and J2EE sample projects should be fixed for GF v3.1
> Once there is final release of GF 3.1 and users do not have any reason to > switch back to 3.0.1 then glassfish*xml is way to go. I agree - and GF 3.1 will be final before NetBeans 7 is final. So for NetBeans 7 final release, we should use glassfish*.xml. And I don't think we should revert to sun*.xml now and then do the change again to glassfish*.xml late in the bugfixing cycle. Development builds are supposed to converge towards the final release, and we should expose all the changes so they can be tested by the users.