Right click the web service client and select refresh. It asks me URL, I accept the default. It asks if I want to
accept SSL certificate. I click Yes. It asks for HTTP username and password. I click cancel. It said something about
an error, HTTP 401 I think? I expected that.
Now right click the web service client again, refresh, accept default URL, accept the SSL certificate, and it will not
prompt for a username/password again. Instead it will go straight to the same error message.
Even after restarting the IDE it will not prompt me for username/password anymore. Why? Now I can no longer do
development on my project.
I deleted the web service client and tried to create a new one. It asked if I would like to accept the SSL certificate,
I said yes, and it did not ask me for username/password. It failed to load the WSDL. I am *really* stuck now.
I tried the same URL in a web browser. It asked me to accept SSL certificate, and for a username/password. When I
entered the correct username/password, it displayed the WSDL.
Changing to P1 because I can't find a workaround
Can you try to download the WSDL, use from local WSDL option in new ws client wizard and see if it helps, please?
I saved the WSDL as a file and added a web service client to my project. I was surprised that it worked because it
references a separate xsd file (generated by JAX-WS). The output window in NetBeans looked like this:
Created dir: D:\dev\FolioService\FolioServiceClientDemo\build\generated\wsclient
Created dir: D:\dev\FolioService\FolioServiceClientDemo\build\generated\wsservice
Created dir: D:\dev\FolioService\FolioServiceClientDemo\build\generated\wsbinary
Copying 1 file to D:\dev\FolioService\FolioServiceClientDemo\build\generated\wsclient\wsdl
BUILD SUCCESSFUL (total time: 2 seconds)
However in my code window of the servlet that uses the service, many lines have the red error underline. When I type in
the package name that contains the client, no classes are shown. When I look in the files tab at the project's build
directory I can see the generated files. Restarting the IDE didn't help, it still shows up with errors everywhere. I
was able to build the project with no errors though.
Ryan, Is this the scenario that is described in your blog:
If not kindly attach or send me (firstname.lastname@example.org) the sample projects.
No that blog entry is not what I was doing. It talks about JAX-WS, and this bug is with JAX-RPC.
I can't give you my closed source source code. I can tell you that there is a JAX-RPC web service deployed to GlassFish
secured with SSL and HTTP BASIC authentication. It was developed and deployed with NetBeans into SJSAS 9.1 UR2. I
created a new web project to write a client application that would use the service.
The red lines in servlet window are most probably caused by same reason as issue 135841. If so, code is still
compillable, despite the errors . Fact, that scenario works locally means there's workaround, so it's not definitely P1.
Decreasing priority to P2.
This ticket is about NetBeans caching the username/password when retrieving WSDL to generate a web service client until
you restart NetBeans. If you enter an invalid username/password or press cancel, it will not prompt you again when
trying to regenerate a web service client. It just fails every time.
Yes I would agree the code window red lines is issue 135841).
> This ticket is about NetBeans caching the username/password when retrieving WSDL to generate a web service client until
you restart NetBeans.
Looks like attached patch solves this (at least for me), feel free to reuse.
Created attachment 62705 [details]
Will this patch also work for non-SSL web services? It looks specific to https/SSL. Thanks
looks like not :( I'll try to dig into this a bit more in the morning...
Well, actually it's JDK who's caching user credentials if some http/https resource requires BASIC authentication (same
issue appears when xml retriever is getting WSDL for JAX-WS client and perhaps also in some other scenarios)
One possibility to solve this could be introducing some kind of NB specific java.net.Authenticator but the question is
how this would influence the behaviour of the rest of the IDE if would introduce something what would be available globally.
I recall the was some user auth. related issue on the glassfish node in services tab (if admin's credentials were
invalid the dialog was poping up ~10-15x, sometimes forever), so another possibility could be to try to check how it's
solved in glassfish plugin. That could give us some clue how we could solve this in websvc area.
 see: org.netbeans.modules.j2ee.sun.ide.editors.AdminAuthenticator in j2ee.sun.appsrv module
back from the vacation...
problem seems to be in org.netbeans.core.NbAuthenticator which overrides default java.net.Authenticator instance from
the JDK in the way that user is never asked for credentials if BASIC auth is required by the server for any
http/https/??? connection - that's a regression against 5.x.x releases and an adoption blocker in moving to the 6.x
versions of the IDE => P1
I'll attach possible patch for the NbAuthenticator class later today ;-)
Great, I'm glad to see this one finally fixed. You mentioned that the code *never* asks for HTTP BASIC
authentication... For me, it does ask me for username/password the first time I try. After I press OK or cancel it
won't ask for username/password again until I restart the IDE. I seem to remember struggling through this once or twice
where even an IDE restart didn't help. Hopefully these issues are related.
yes I've mentioned never, steps follow - checked several times in 5.5.1 FCS, 6.0.1 FCS, 6.1 FCS + official patches,
nightly builds of 6.5:
-start the IDE, create a web project with a web service secured with BASIC auth (optionally running over HTTPS) and run
it (exact steps in Rayn's blog - see desc7 - thanks for that!)
-start another instance of some other IDE with clean userdir
-get all updates (iff applicable)
-register glassfish in the IDE (*)
-install JAX-RPC plugin from the UC (iff applicable)
-create new java application
-create new JAX-RPC websvc client for the service created previously
-finish the new websvc client wizard
=> in 5.5.1 this works, in any later version it doesn't work unless I do something related to glassfish, see bellow
If I skip a step marked with (*) then I'm never asked for credentials, if I don't skip it then
org.netbeans.modules.j2ee.sun.ide.editors.AdminAuthenticator seems to be set as default java.net.Authenticator for the
IDE somehow (it's enough to expand servers node in services tab) and I'm asked for the credentials in the same way as
you - adding Vince on cc - so there are actually two issues - first, I'd say more serious, in NbAuthenticator, second in
AdminAuthenticator which seems to be caching incorrect credentials (perhaps as a result of a fix for constantly poping
up auth dialog when there wasn't set admin's pwd in the IDE - I don't remember details here) according to desc1
Created attachment 63174 [details]
proposed fix for o.n.core - feel free to review and reuse
After discussion with Jirka re-assigning to myself...
fixed the core part in:
moving to GlassFish plugin to fix the rest of the issue there.
The condition on line 77 in AdminAuthenticator seems to be wrong since "displayed" can never get again to the "false"
state after it's set to "true"...
I think I was able to reproduce the issue and resolve it.
Please reopen if there is still a problem
That's great, thank you. I can't test until it's available for production use. I see you've decided to make this fix
available in Fall/Winter (NB 6.5) instead of NB 6.1 Patch 2 (next week). Is that because the fix is so close to patch 2
Unfortunately it's too late to include this in patch2. Anyway marked this for inclusion in patch3 but I'm not sure about
its release date
I don't make that decision... I check code into the trunk. pushing it into a patch release can only happen AFTER the
issue has been verified as resolved... I don't understand why you cannot do that verification, but I think there are a
couple people on the team (like jungi) who will be able to verify it. Once it is verified, it may go into a patch...
though I doubt that it will be patch 2. There is already a patch three in the works
Integrated into 'main-golden', available in NB_Trunk_Production #278 build
User: Lukas Jungmann <email@example.com>
Log: IZ #135838: I can make refresh JAX-RPC web service client fail with HTTP BASIC Authentication - core
original issue is fixed and current state is much better than it was although there are still some minor issues which I
filed separately - see issue 138222 and issue 138232
Marking this verified and ready for patch3...
I've ported the bugfix into release61_fixes repository.
http://hg.netbeans.org/main/rev/9d1eab5b6857 ported to http://hg.netbeans.org/release61_fixes/rev/b9de4829cd61
http://hg.netbeans.org/main/rev/a6a199f24265 transplanted to http://hg.netbeans.org/release61_fixes/rev/cf48733b5d7d
http://hg.netbeans.org/main/rev/d70e254a1aff transplanted to http://hg.netbeans.org/release61_fixes/rev/926915e78e70
http://hg.netbeans.org/main/rev/c5a1ad856b70 transplanted to http://hg.netbeans.org/release61_fixes/rev/5718b128743e
The bugfix cannot be delivered via AUC. It will be most likely rolled back. ( Please see issue 142048 )
I've backed out all four changesets due to new dependency on issue 142048, which blocks resolution of this issue for NB
6.1 fixes codeline. Changed status whiteboard back to 61fixes3-candidate.
See attached backout log for information about revisions.
Created attachment 65966 [details]
NB 6.1 fixes backout log
I've re-integrated the changesets into release61_fixes repository.
Those changesets got into release61_fixes repository in this way
http://hg.netbeans.org/main/rev/9d1eab5b6857 ported to http://hg.netbeans.org/release61_fixes/rev/38ca9c63f408
http://hg.netbeans.org/main/rev/a6a199f24265 transplanted to http://hg.netbeans.org/release61_fixes/rev/ffcf433e58b7
http://hg.netbeans.org/main/rev/d70e254a1aff transplanted to http://hg.netbeans.org/release61_fixes/rev/5bcbdf2f6476
http://hg.netbeans.org/main/rev/c5a1ad856b70 transplanted to http://hg.netbeans.org/release61_fixes/rev/683ff76d1a53