Created attachment 58055 [details]
screenshot

fixed. changeset d7f1738c6a9d.

Reproduced again in trunk and release61 for servlet in J2EE1.4 web module.Reopen.

This is a different issue really.
Original issue was in EJB project, now its in web project.

moving opened issues where TM != dev to TM=TBD

Issue 135841 might be the same as this issue (web project).  This is an adoption stopper for me.  I can't work without
the code completion and with the red errors.  I'm stuck on v6.0.1 still, because it does not suffer from this regression.

Is this ticket part of NB 6.1 Patch 2?  Issue 135841 is, and it depends on this one.  Without this fix I won't be able
to upgrade to NB 6.1. Thanks

This issue is reproducible again in trunk (6.5).

Shouldn't this be P2 or P1?

Yes.I'm raising the priority to P2,since other depending issues are also P2.

Fixed.

Diffs:
http://hg.netbeans.org/main?cmd=changeset;node=df6ba7a302c3

You broke commit validation; typo "core" for "project". BTW please use '-' to separate components of a FQN in a
*.instance file rather than '.'.

http://deadlock.netbeans.org/hudson/job/javadoc-nbms/1885/testReport/org.netbeans.core.projects/ValidateLayerConsistencyTest/testInstantiateAllInstances/

File
Projects/org-netbeans-modules-j2ee-clientproject/Lookup/org.netbeans.modules.websvc.core.jaxws.project.JaxRpcLookupProvider.instance
threw java.lang.ClassNotFoundException: org.netbeans.modules.websvc.core.jaxws.project.JaxRpcLookupProvider

Why isn't this in patch 3?  I'm still stuck on NetBeans 6.0.1 after 3 patch releases because of this regression.  I
installed NB 6.1 patch 3 two days before the release (http://blogs.sun.com/coreqa/entry/patch3_for_netbeans_6_1).  I
have a J2EE 1.4 web project that has a JAX-RPC client.  It builds fine, but the editor doesn't know where the generated
code is and shows red error lines under every line that uses the web service's objects.  No code completion is available.

To me this is a P1 showstopper for the patch 3 release.  It is a regression of 6.0 identified before 6.1 was even
released (I think), and is an adoption blocker for people who use JAX-RPC. Do you want me to create a separate ticket
because it is a web project I'm using?  I'll see if it happens from an EJB project soon. 

Fixed incorrect instance reference in layer.xml (on 06/24):
http://hg.netbeans.org/release65_m1?cmd=changeset;node=323b22c75c75

also replaced dots(.) with dashes (-) in layer.xml file:
http://hg.netbeans.org/main?cmd=changeset;node=38e87b004c43

Finally I also implemented SourceForBiaryQuery for JAX-RPC artifacts:
http://hg.netbeans.org/main?cmd=changeset;node=8d36f2b6a2a9

The last fix is important when JAX-RPC clients are used in another project. (e.g. when JAX-RPC client created in J2SE
project is consumed in web application).

I consider the issue fixed for 6.5 release.

Integrated into 'main-golden', available in build *200808280201* on http://bits.netbeans.org/dev/nightly/
Changeset: http://hg.netbeans.org/main/rev/8d36f2b6a2a9
User: mkuchtiak@netbeans.org
Log: #129645: implement SourceForBinaryQuery for JAX-RPC Client artifacts

I am using daily build 200808311401.  I did two tests and both show the editor is completely unusable, and the project
won't build:

Test #1: EJB Module Project (Java EE5)

1) Create the new project
2) Added a web service client for a JAX-RPC web service
3) Created a session bean
4) Used the "Call Web Service Operation" dialog to generate code in my EJB to call the web service

All lines that touch the web service in the editor are red.
The project will not compile


Test #2: Web Project (java EE 5)

1) Created a web project
2) Add web service client for a JAX-RPC web service
3) Create a servlet
4) Use the "Call Web Service Operation" dialog to have it generate code in my servlet that calls the web service

All lines that touch the web service in the editor are red.
The project will not compile
This is worse than before.  At least before it would compile.

I may have put my comment in the wrong ticket.  However, it seems that nobody at Sun has even tried to create a JAX-RPC
web service client and then use it. They only look at tiny fragments and fix them one at a time. I have been complaining
about this and creating tickets since before 6.1 was released. Several fixes made it into patch 1, patch 2, patch 3, and
now NetBeans 6.5 and it is STILL completely unusable. This is a big regression since 6.0 where it worked fine. Someone
PLEASE complete the full use case of creating a web service client in both web and EJB projects, use the client from a
servlet or EJB, make sure the editor works, and make sure the project compiles.   DO NOT LET 6.5 BE RELEASED UNLESS THIS
WORKS.  I've had to skip 6.1 entirely because of this regression and if I also have to skip 6.5 then I am going to 
switch IDEs. 

I tested the fix for issue 135841 in Web Application. Wouldn't mark the issue fix if it were not working at my laptop.

Tested that again for both Web App and EJB.
Works for me in web applications - see the picture (client for http://www.webservicex.net/CurrencyConvertor.asmx?wsdl)
The only red lines are related to 

currencyConvertorSoap.conversionRate(/* TODO enter operation arguments*/);

that's "as designed" since arguments should be completed.

Now I see in EJB - there is a problem.
Working on that now.

Now I am able to reproduce it also in Web Application.
Sorry for inconveniences.

Note:the workaround is to open the Project's Properties dialog and close it.

Investigating why it works for JAX-WS but not for JAX-RPC.

Fixed.

build/generated/wsclient/ should be created before project.xml is changed.

Diff:
http://hg.netbeans.org/main?cmd=changeset;node=ff4c2341c7ed

For sure I'd like to ask QE manager to test this fix.

Integrated into 'main-golden', will be available in build *200809031401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/ff4c2341c7ed
User: mkuchtiak@netbeans.org
Log: #129645: code completion fix for JAX-RPC artifacts

*** Issue 135424 has been marked as a duplicate of this issue. ***

v.