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.

Bug 94865 - After disabling web service security on an endpoint, settings are left in sun-web.xml
Summary: After disabling web service security on an endpoint, settings are left in sun...
Status: VERIFIED FIXED
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Identity (show other bugs)
Version: 5.x
Hardware: All All
: P1 blocker (vote)
Assignee: Peter Liu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-07 15:35 UTC by rdelaplante
Modified: 2007-08-24 16:40 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
1.5 project for reproducing this issue (26.75 KB, application/octet-stream)
2007-02-27 01:40 UTC, Peter Liu
Details
Patch to resolve this issue. (8.21 KB, text/plain)
2007-03-07 01:37 UTC, _ pcw
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rdelaplante 2007-02-07 15:35:59 UTC
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.
Comment 1 Tientien Li 2007-02-12 18:38:27 UTC
This is not a 5.5.1 service assembly editor bug. It probably should be filed 
against websvc or other related components.
Comment 2 Martin Grebac 2007-02-13 10:23:22 UTC
This is not WSIT, but Access Manager issue.
Comment 3 Peter Liu 2007-02-14 05:28:16 UTC
The message-level-security api from the server plugin could be flaky.
Comment 4 Peter Liu 2007-02-16 09:12:21 UTC
The workaround for this issue is to manually modify the sun-web.xml to remove
the security elements.

Comment 5 astashkova 2007-02-16 13:11:13 UTC
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.
Comment 6 Alexei Mokeev 2007-02-19 07:08:55 UTC
No Objections in 48 hours. Waived.
Comment 7 Peter Liu 2007-02-20 17:10:00 UTC
*** Issue 95957 has been marked as a duplicate of this issue. ***
Comment 8 Peter Liu 2007-02-20 17:30:36 UTC
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.
Comment 9 rdelaplante 2007-02-21 19:37:41 UTC
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. 
Comment 10 _ pcw 2007-02-27 01:16:21 UTC
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?
Comment 11 Peter Liu 2007-02-27 01:38:38 UTC
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.
Comment 12 Peter Liu 2007-02-27 01:40:00 UTC
Created attachment 38936 [details]
1.5 project for reproducing this issue
Comment 13 Alexei Mokeev 2007-03-05 17:24:06 UTC
Removed Beta EP551_WAIVER_APPROVED keyword - we are going forward to FCS.
Comment 14 _ pcw 2007-03-06 22:53:27 UTC
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.
Comment 15 _ pcw 2007-03-07 01:34:26 UTC
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.
Comment 16 _ pcw 2007-03-07 01:37:49 UTC
Created attachment 39228 [details]
Patch to resolve this issue.
Comment 17 _ pcw 2007-03-07 01:41:24 UTC
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.
Comment 18 _ pcw 2007-03-07 01:49:48 UTC
Changes committed to trunk (can't be tested there though since the config editor
is disabled still though)
Comment 19 rdelaplante 2007-03-07 14:23:18 UTC
> 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
Comment 20 Peter Liu 2007-03-07 18:57:42 UTC
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.

Comment 22 Jaroslav Pospisil 2007-08-24 16:40:32 UTC
VERIFIED