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.
I have a normal web project that exposes a web service. Right click the service, Edit Web Service Attributes. I checked "Enable Message Level Security", chose "UserNameToken", pressed OK, then deployed. A bit later I came back to the window, unchecked "Enable Message Level Security", pressed OK and deployed. The web service clients could not use it, and the exception was related to web service authentication. I looked in the service endpoint's sun-web.xml and found this: <message-security-binding auth-layer="SOAP" provider-id="AMServerProvider-UserNameToken"> <message-security> <message/> <request-protection auth-source="content"/> <response-protection auth-source="content"/> </message-security> </message-security-binding> I removed that chunk of XML, saved, and redeployed. Clients can now access the web service.
This is not a 5.5.1 service assembly editor bug. It probably should be filed against websvc or other related components.
This is not WSIT, but Access Manager issue.
The message-level-security api from the server plugin could be flaky.
The workaround for this issue is to manually modify the sun-web.xml to remove the security elements.
Added "as is" to staged NB Enterprise Pack Release Notes (http://nbstaging.czech.sun.com/community/releases/55/1/entpack_relnotes.html#94865). Clarification needed.
No Objections in 48 hours. Waived.
*** Issue 95957 has been marked as a duplicate of this issue. ***
Additional symptoms reported in bug 95957 I haven't figured out a pattern but I view the XML source of sun-web.xml periodically and find several duplicate entries such as: <servlet> <servlet-name>MyService</servlet-name> <webservice-endpoint> <port-component-name>MyService</port-component-name> </webservice-endpoint> <webservice-endpoint> <port-component-name>MyService</port-component-name> </webservice-endpoint> <webservice-endpoint> <port-component-name>MyService</port-component-name> <message-security-binding auth-layer="SOAP" provider-id="AMServerProvider-UserNameToken"> <message-security> <message/> <request-protection auth-source="content"/> <response-protection auth-source="content"/> </message-security> </message-security-binding> </webservice-endpoint> </servlet> I've been turning security on and off repeatedly (hours between) and redeploying.
More information to help duplicate the problem: Before enabling security on a service I looked in sun-web.xml and saw only one webservice-endpoint section: <webservice-endpoint> <port-component-name>MyService</port-component-name> </webservice-endpoint> Next I used the "Edit Web Service Attributes" window to enable UserNameToken security and pressed OK. When I came back to the sun-web.xml document I saw the original webservice-endpoint was still there, and a duplicate was added this time with security settings.
If you open up sun-web.xml in the configuration editor (not as XML text), how many Web Service Descriptor entries are there under the "Web Services" node? Also is this JavaEE5 or J2EE 1.4?
The config editor only shows one entry. Only the xml text editor shows duplicate entries. As for which version, I only reproduced this problem using a 1.5 project. I haven't tried reproducing it with a 1.4 project. I'll attached a 1.5 project which I have been using to reproduce this issue. Simply open up the "Edit Web Service Attribute" editor and click ok to force a save. Note that you need to install the entpack to reproduce this. You can download the entpack build from here: http://balui.sfbay.sun.com/kits/oriondev/gavotte_beta/milestone7a/installers/ Choose the tools bundle installer to install appserver, netbeans, am server, etc.
Created attachment 38936 [details] 1.5 project for reproducing this issue
Removed Beta EP551_WAIVER_APPROVED keyword - we are going forward to FCS.
Ok, I finally got some cycles to look at this. I can reproduce it w/o enterprise pack. The issue is quite simple, but is a bit complicated to explain. What appears to be happening is that the merged annotation-dd provider, while it does send the SJSAS plugin events regarding the @WebService, is _not_ sending the corresponding event regarding the implied servlet that is the backing servlet for an annotated webservice. Since we never create the servlet entry, we never load the servlet (& it's associated endpoint) from the data cache it was added to when sun-web.xml was first loaded and so when the file is saved with new changed endpoint data, the original endpoint data (which was never removed from the cache) is saved along with the new data. That is why you start seeing multiple endpoints. I will see if there is a way I can detect this and not save the duplicate. On a related note, the reason this was probably not detected pre-5.5. ship was because the caching mechanism went in very late to fix dataloss problems associated with flaky events from the aforementioned merged annotation-dd provider. If the fix is simple, we can probably justify fixing this for 5.5.1 if you're still interested in a fix.
This issue only shows up in JavaEE5 WebApp hosted Web Service endpoints because of the missing "new servlet event" from the merged annotation-dd provider. For JavaEE5 (ejb hosted) and J2EE 1.4 (both webapp and ejb), the event flow functions as originally expected and there was no cache problem. I double checked the patch that cleans up the extranous cache entry and it causes no problems for these 3 addition cases.
Created attachment 39228 [details] Patch to resolve this issue.
To reviewer: The issue is that we cache endpoint data in two locations on load. In this case, because we never received a servlet ddbean for the backing servlet, one of the endpoint caches was not cleared (the one owned by the servlet), so that is where the duplicate or "undeleted" entry is coming from. The patch augments the loading of the web-service-descriptor entry so that both endpoint caches are cleared (if necessary) after the endpoint data has been successfully loaded.
Changes committed to trunk (can't be tested there though since the config editor is disabled still though)
> If the fix is simple, we can probably justify fixing this for 5.5.1 if you're still interested in a fix. If that sentence was for me (the reporter of the bug) then yes I would love to see this fixed in 5.5.1. Thanks
Upgrading this bug to p1. This turns out to be a serious issue without an easy workaround. Users have to manually clean up the duplicate entries everytime the sun-web.xml is saved.
Fixed in 5.5.1 branch. http://serverplugins.netbeans.org/source/browse/serverplugins/sun/sunddui/src/org/netbeans/modules/j2ee/sun/share/configbean/WebServiceDescriptor.java?r1=1.4.2.2.2.16&r2=1.4.2.2.2.16.10.1 http://serverplugins.netbeans.org/source/browse/serverplugins/sun/sunddui/src/org/netbeans/modules/j2ee/sun/share/configbean/Base.java?r1=1.1.16.4.2.11&r2=1.1.16.4.2.11.10.1
VERIFIED