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.
[build 20060324] Steps: 1) creat J2EE 1.4 EJB module with target server Glassfish 2) then try to deploy this module in App server 8.2 I guess that this scenario should work but the issue is that the sun-ejb-jar.xml file is created with SJSAS 9.0 PUBLIC ID hence the module can't be deployed in AS 8.2. Should we generate SJSAS 8.0 for J2EE 1.4 projects? I think, yes.
The described behavior is not a bug. However, I can understand if people would like to change it in some ways and we should discuss that. When a project is created, the SJSAS plugin determines the minimum & maximum possibly AS versions for the descriptors from the J2EE module version of the project and the current server target. This is why a J2EE 1.4 project defaults to 9.0 descriptors if created when Glassfish is the target. It would have defaulted to 8.1 (NOTE: _NOT_ 8.0) descriptors if either 8.1 or 8.2 had been the target server (both 8.1 and 8.2 use the same DTD's for all J2EE modules.) If you then switch server target from Glassfish to 8.2 and deploy you will get an error. The solution is to change the version on the deployment descriptor. To do this today, close the configuration editor if it is open (either text or GUI mode), right click the sun-xxx.xml file in question, and select properties. One of the properties will be the version number and the available selection will be appropriate for the J2EE module type of the project (e.g. AS 8.1 & 9.0 will be choices if you are using J2EE 1.4. AS 7.0 is also available if it is J2EE 1.3). The file will be silently downgraded or upgraded and immediately saved to disk.
Now, for maximum usability, I can see how we might want to default to 9.0 for JavaEE 5 modules and 8.2 for J2EE 1.4 modules. However, we also might want to consider other possibilities instead, such as detecting the current target server version on load (or if it is changed) and asking the user permission to automatically change the descriptor if it is incompatible (ie 9.0 dd file for AS 8.x) or to prompt the user to do it if we are unable to (e.g. the user changes it in project properties and the configuration editor is open -- we don't currently support a version change when there is an open configuration editor.) For now, I will leave this bug open to track this, but I would be interested in altenative opinions and other solutions.
*** Issue 79181 has been marked as a duplicate of this issue. ***
Additionally, to change the version of the descriptor, the new UI for this is in place. Just open the GUI configuration editor for the sun descriptor, click the <Doctype...> button in the upper right hand corner and select the server target you want from the list.
AFAIK EE specs are refering to server specific DDs, they are not saying anything about how the version of the server specific DD is related to Java EE version, so from this point of view it is OK to have eg. J2EE 1.3 web application with sun-web.xml which refers to sun-web-app_2_5-0.dtd as long as the _target server_ is able to handle this case (I have to agree with Vince's comment from issue 79181 here). But I don't think that result of scenario described in this issue is not a bug. Switching between target servers is supported so switching between versions of server specific DDs should be supported too (actually it is, but current solution seems to me more like an acceptable workaround for this issue as I don't think that 9.0->8.x is/will be a typical use-case). Better solution would be similar to one used in 4.1 or 5.0 in case of upgrading ejb-jar.xml from 2.0 to 2.1 (?), IMO - if user changed J2EE version from 1.3 to 1.4 in project properties then there was shown a message that ejb-jar version will be upgraded too and the change was done immediately after closing project props w/o any other prompts. just my $.02
It sounds like people would like the plugin to track server changes, in particular, the backward server change from 9.0 -> 8.1/2 since that is where the potential deployment failure would be since 8.2 can't handle 9.0 descriptors. There are some edge cases to consider -- for example: 1. If the configuration editor is open and unsaved, we will prompt the user to save it before conversion. If they cancel, conversion is cancelled as well. 2. We offer the "possible truncation" warning on all backward migrations, regardless of whether or not the user has actually used any fields subject to this constraint. It is non-trivial to detect the exact scenarios where this warning is required. I am considering deferring this issue until after NetBeans 5.5 (and as a hedge for usability, defaulting new J2EE 1.4 modules to use AS 8.2 descriptors). If someone feels strongly that this should be fixed in a more correct or versatile manner, please comment.
If tracking server changes is not feasible for release 5.5, I think the right thing to do is to create AS 9.0 doctype by default regardless of J2EE project type. There should be some mechanism that allows developers to change the doctype to AS 8.2 when deploying against AS 8.2. Afterall, NB 5.5 is the release for supporting AS 9.0. I thinking creating AS 8.2 doctype for 1.4 project is not the right solution because it essentially creates another bug where 1.4 projects are prevented from taking advantage of the new features in AS 9.0. For example, the Liberty support in the identity modules uses the new httpservlet-security-provider attribute in the sun-web-app element to set the security provider but this is currently not possible for 1.4 projects because of the 8.2 doctype.
Hi Peter, it seems the root issue is already fixed. User can change the server DD Doc Type in new dailog. Can we mark the bug as FIXED and track ?
Changing this since this is a stopper for Enterprise Pack FCS release. Please look at comments from petertliu on this bug
We cannot use the UI driven change as we need to impact this change programatically. The ideal scenario would be to have the 9.0 doctype for AS 9.0 based projects. In our usecase to enable Liberty there are set of changes that we need to automate. We cannot use this manul workaround to achieve that automation.
P1 upgrade is not the way to escalate bugs. Bugs are bugs, and this is not a P1 for NB 5.5 FCS. Now, I am confused because I tried today to create a Web App with J2EE 1.4 and GlassFish target. The sun-web.xml doctype was for GlassFish. So it does what you want no? Call us :-)
Are you using the beta2 build or release55 build? Perhaps this is fixed in release55 branch. I'll give it a try.
I am not sure things changed since 20060324 in this area (since this bug was filed)
Ludo, you're right. It turns out that, for some reason, our sample web applications had the wrong doctype. If we build it from scratch, it has the doctype for glassfish.
ludo, I was asked to change it to P1 so that this will be highlighted as a stopper for Enterprise Pack release. Unfortunatly that which is a stopper for ent pack isnt a stopper for NB also. I am not with this process as well but this is how I was asked to handle this. Seems like the core issue is that our samples had wrong doctype DD files since they were old aplications and this issue is resolved in later NB builds. We will recreate our samples with the new Nb build and make sure we test it in later builds to ensure this issue is resolved. Seems like the priroity here now reflects what is correct for NB.
Discussing with Ludo seems like for Enterprise Pack Identity tooling it would be better for the bug to be not fixed than addressed. Our use case wants the AS 9.0 doctype for projects with AS 9.0 server, which means that its better this bug not be fixed. Also, it is unclear why users would start with J2EE 1.4 project with Glassfish and then downgrade this to AS 8.2 Unclear why a user would follow this scenario. So, my request is to downgrade this bug and not have this addressed unless there is some valid customer use case asking for this.
I am closing this as will not fix. In my opinion, the DOCTYPE should follow the target... not some ambiguous mapping between spec level and server release. It looks like all the folks that were push for a fix realized they might have been mistaken. the issue has no dups...