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 200503242007] EJB modules with web services should contain only webservice name without any prefix in <endpoint-address-uri> element in sun-ejb-jar.xml. If there's some prefix (as "webservice/" used in samples) user can't add websvc to registry through "Add to registry" without looking to sun-ejb-jar.xml (This is caused by the fact, that add to registry dialog is looking for webservice name and not for endpoint-address-uri - this is bug in NB, unfortunately, the fix is planned for the next release). Fix of this issue also implies fixes in samples of client apps.
This is absolutely not a bug. The endpoint address uri is a public interface which a provider should control and must not be forced or limited by a tool she/he uses. Think about the case of a web application. Do you want to be restricted how you represent your web resources?
first: I know that this is bug in netbeans, not in BP catalog (as said above) second: in case of webapp is URL for websvc computed as http://<computerName>[:<port>]/<webappContextName>/<websvcName> (<-same bug as above) third: as a new user who don't know much about web services I want to discover all features of IDE, so I start to play with sample applications. I create new EJB SOA sample, run it and invoke the "Add to registry" operation on webservice (because I want to test it), but error message which appears does not say much to me (only that I should check if websvc or appserver are running - and both are running). In this situation i don't know why it does not work. And we should prevent this situation (at least from QE point of view). If you don't want to remove the webservice prefix from DD, just document it somewhere (put some visible note somewhere). I prefer first solution in this case.
Jiri, what is the usability issue here? Is the <add to registry> action not pre-filling the correct value for ejb based web services? For the general case, or does it require modification of sun-ejb-jar.xml first? You also mention a bug for the next release, what is the number of that bug?
Is there a way to access the server-specific DD (e.g., sun-ejb-jar.xml)? We need to base the default WSDL URL on the <endpoint-address-uri> element of this DD. Currently it is just based on the web service name, which is how the server-specific DD puts in the default value for this element. In this case, the user changed <endpoint-address-uri> to add a qualifier,i.e., <qualifier>/<webservice-name>, so adding to registry fails using the default WSDL URL because the deployed WSDL could not be located.
Maybe the same way the IDE is getting/setting the context root in sun-web.xml via a 'predefined' well known XPath?
Here's my 2 cents. To be always correct in this dialog would require that the code in the websvc module be able invoke a j2eeserver api to read the server specific endpoint, if any. IMO, this is a post 4.1 issue, not be resolved here. However, since we control the generation both on the plugin side and the websvc side for NB 4.1, I see no reason why we cannot generate blueprints compatible endpoints on the plugin side (e.g. webservice/foo) and have the dialog autofill a blueprints compatible endpoint on the websvc side. The sample projects from blue prints should work as well. Yes, this means that if the user changes the endpoint, it will no longer be correct and they'll have to fix it. But I think that is true anyway, isn't it? As for persisting it if they change it, where would we save it to anyway? There is no way (that I'm aware of) to per-project persistence of properties.
The default now is to be blueprint compliant, ie use webservice/... So this bug is fixed... It does not mean that for non bp compliant patterns, we are clear. For that, the bug http://www.netbeans.org/issues/show_bug.cgi?id=52265 is still open.
v. 200504031800