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.
JBoss Application Server 4.2 and OC4J can't deploy ear without application.xml. Provide API to setupDD from plugin or create application.xml ever.
Well, JBoss 4.2 is not a Java EE 5 compliant server, so it should not be possible to create a Java EE 5 application with JBoss 4.2 as the target, right? For J2EE 1.4, the EAR project wizard should create application.xml. Not sure about Oracle - which version is this? And is it Java EE 5 compliant? According to the spec, a Java EE 5 compliant server *must* accept an application without application.xml
That's the point of view. JBoss 4.2 and OC4J 10.1.3.2 are not J2EE 1.5 fully compliant, but they can handle EJB3.0, JPA, WEB 2.5 and EAR 1.5 as well. Actually we wants to enable these functions for the servers. If we disable java ee 5 for these servers it will be bad. Best solution is to give a chance to plugin to create an application.xml.
I think the best solution would be to let ear project ask j2ee server if application.xml is needed for (not only?) deploy
it would be the best
Although the spec states that application.xml is optional, the reality is different and we should not blindly follow the spec. I agree that project should ask the server plug-in whether it requires application.xml or not.
After discussing this issue, we have decided that the best option is to close this issue as WONTFIX. The problem that a valid javaee 5 project without deployment descriptor cannot be deployed to jboss or oc4j is a bug in these serves and thus should be fixed there. We don't want to disable creation of javaee 5 projects targeted to these servers since there is an easy work-around for it. All it needs to be done is to create the deployment descriptor manually.
Has anyone considered resolving this in the jboss or oc4j serverplugins? They could create a correct application.xml for this use case, in the same way they might create the server specific descriptor. -- it would be a server specific solution, thereby not contaminating the j2ee/javaee infrastructure with unnecessary apis. -- it can be coded to execute only against the broken server versions. -- the changes won't affect servers that handled this scenario properly.
That's the problem. I did it in oc4j plugin, but it's not fully functional. I can't acquire all data from ear project what i need. I am able to create an empty application.xml but i need fill it with included modules.