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.
The following code in NB 6.0 is returning null: J2eeModuleProvider.getJ2eeModule().getDeploymentDescriptor( J2eeModule.WEBSERVICES_XML) This breaks the identity module functionality in the enterprise pack which depends on it to get the Webservices metadata.
Aa far as I know, this is not implemented feature. The J2EE DD APIs haven't been migrated yet.
Depends on the metadata model, which is right now being developed.
This is a stopper for enterprise pack identity functionality. Is there a workaround that you can propose for us to proceed for M9/javaone?
Petr suggested I add details on the information I need from the webservices.xml file. Here are the details: PortComponentName WebserviceDescriptionName ServiceImplBean - EjbLink/ServletLink
So when exactly does this issue happen? Is it for J2EE 1.4 / JAX-RPC, or Java EE 5 / JAX-WS, or both? Does it also happen when the file physically exists, or only when it does not exist and the information is in annotations? I can imagine that some of these cases should be easy to fix.
The issue should not happen for J2EE 1.4 projects as far as I can tell from a quick look at the code. A BaseBean for the webservices.xml file should be returned in this case. For Java EE projects null is returned no matter if a webservices.xml file exists or not. For Java EE projects the only workaround I can think of is to use the Java source API to read the WebServices annotations from the Java files. You don't seem to need much information, so it doesn't seem very hard. If I understand the mapping of annotations to webservices.xml, WebServiceDescription.getWebServiceDescriptionName(), PortComponent.getPortComponentName() and ServiceImplBean are easily available from the WebService annotation and the class it annotates. I don't know anything about EjbLink and ServletLink though. Actually the trickiest part of this workaround could be to obtain a FileObject for a Java file, which you need to pass to the Java source API methods. Do you happen to have a Java FileObject available at the time you call getDeploymentDescriptor()?
The right way to fix this issue is to implement the metadata model for web services. The getDeploymentDescriptor() method will likely be changed to: public <T> MetadataModel<T> getDeploymentDescriptor(Class<T> clazz) and you will call it with a WebservicesMetadata parameter, like in: MetadataModel<WebservicesMetadata> ws = someModule.getDeploymentDescriptor(WebservicesMetadata.class); and Milan will implement the metadata model for web services (and other developers are working on other model types, such as web or EJB). Because of the other models and the need to update existing code which uses the old BaseBean-based models, the metadata model won't be ready for M9. Reassigning to Milan as he is the implementor of the model.
This will be fixed for M10. This is not a blocker for identity anymore.
removing plan 60 to not make it part of feature planning.. but rather it will start being tracked in dashboard for M10 completion.
The web services model is implemented and you can retrieve it as described in desc8. Note the J2eeModule.getDeploymentDescriptor() method has been renamed to getMetadataModel(). Note also that the preferred way to get the web services model is probably JAXWSSupport.getWebservicesMetadataModel() and that using J2eeModuleProvider is discouraged.
I consider this issue as fixed.