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.
Currently when we do automatic assignment of the server (type based) the assignment is done to any server type. This might not be really useful if version of the server is lower than the version used to create the project. I think it could be solved this way: 1) Plugin should provide the version of the instance - this does not have to match the exact server version, it should mark "degree of compatibility". For example for jboss 4.0, jboss 4.0.1, jboss 4.2 it could return 4. This enhancement would be optional for the server plugin. 2) Such version would be stored in project.properties. 3) In situation when the automatic assignment of the server (missing private.properties for example) would be needed it would be based on the server type _and_ version if present. Auto assignment would be done only if the version of the server would be greater or equal. Of course this isn't bulletproof as greater version does not really mean full compatibility, but I think it is good enough. In case when there is a huge change in the server (GFv2 and GFv3 for example) it should be registered as a new server type anyway. There is also independent, but related issue #198341.
Just for the record could you describe please a concrete problem of a server which changed specification and which is causing this problem? Thanks. Btw. issue 198341 seems to me a duplicate of this one or vice versa.
(In reply to comment #1) > Just for the record could you describe please a concrete problem of a server > which changed specification and which is causing this problem? Thanks. Not sure what you mean. We've already learned that spec version is just not enough (capabilities, optional parts of the spec etc.). It does not seem safe enough for example to assign Tomcat 5.0 to project created with Tomcat 7.0 (although it would be J2EE 1.4 project). Same applies to JBoss 4, 5, 6. Also note specific DDs, datasources etc - these might be changed with every server release (while the new server usually handle old format, the old server certainly won't handle the new one). > > Btw. issue 198341 seems to me a duplicate of this one or vice versa. That's why it is not a duplicate.
What I meant is that I would like to clearly know what problems we are fixing (as well as ones which we are not fixing) by introduction of server instance version. It does sound like a useful thing to add. When you mention "JBoss 4, 5, 6" - these each have different server type, no? And similarly Tomcat 5 and 7. Or am I missing something?
(In reply to comment #3) > When you mention "JBoss 4, 5, 6" - these each have different server type, no? No. > And similarly Tomcat 5 and 7. Or am I missing something? Not a different server type anymore. Now the comment #2 should make more sense.
Yes, now it make sense. So Server Type is really a family of servers - GlassFish, Weblogic, Tomcat. And Server Instance Version is a version of server. Simple. :-) Why did we started at some point using server type to identify different versions of a server? gfv2, gfv3 server types? I thought that whatever GF was doing was preferred way and that other servers should just be updated. Not vice versa.
FYI, gfv2 and gfv3 are still separate plugins and server types, because they are totally different and use a different codebase (now v2 is on update center only). There is also the UI requirement that if possible, we only want to have one entry per server in the New Server Instance wizard, not a separate entry per version. The version should be inferred by the wizard based on the server's file structure etc.
(In reply to comment #5) > Yes, now it make sense. So Server Type is really a family of servers - > GlassFish, Weblogic, Tomcat. And Server Instance Version is a version of > server. Simple. :-) > > Why did we started at some point using server type to identify different > versions of a server? gfv2, gfv3 server types? I thought that whatever GF was > doing was preferred way and that other servers should just be updated. Not vice > versa. I would not be that strict. As Petr already wrote the GFv2 and GFv3 are significantly different. So when it is practical and/or logical different server type is ok. On the other hand it does not make much sense to have GF Prelude, GF 3.0, GF 3.1 and similarly Tomcat 5.5, Tomcat 6.0, Tomcat 7.0 as different server types. The j2eeserver and plugins have long history with many contributors. Some of them were copy-pasting and some of them wrote the code from scratch. From time to time we may discover bug or inconsistency we should deal with. And this is the case. Honestly this enhancement does not have really big priority as nobody really complained about it. Perhaps user could just uses Resolve missing server button without any automatic assignment of the server. But this could bring us some user experience complaints :) I just thought it was a right thing to file it and at least to discuss it.
> gfv2 and gfv3 are still separate plugins and server types, because they > are totally different and use a different codebase I see. That explains it to me. Having a single server type which would have to have a single New Server Wizard while two different code bases are involved would require too much cooperation and therefore it justifies the exception for two different server types. I accept that. > There is also the UI requirement that if possible, we only want to have > one entry per server in the New Server Instance wizard. Yeap, agreed. > Honestly this enhancement does not have really big priority as nobody really > complained about it. Perhaps user could just uses Resolve missing server button > without any automatic assignment of the server. But this could bring us some > user experience complaints :) > > I just thought it was a right thing to file it and at least to discuss it. Now this issue makes perfect sense to me. Go ahead and do it. Thanks for explaining it to me. It would be good if you could describe somewhere (perhaps in Javadoc of server type?) when server type should be changed. For example in #0 you write "In case when there is a huge change in the server [...] it should be registered as a new server type anyway." I do not think that's true. Server type should never change for a family of servers. The exception justifying it is for example if support comes two different teams or two source code bases. It should also mention that two different server types for one family of servers will result in two New Server Wizard which is undesirable as well.