He is another issue with ServiceRef. Here is how to reproduce:
1. Install the standard NB.
2. First, create the stock service project by invoking New Project -> Samples -> Identity Blueprints -> Stock Service.
You'll need to resolve a few missing module references. Deploy the ear project. (Note due to bug 108075) you'll need to
restart the IDE in order to deploy the ear project.
3. Next, create the stock client project by invoking New Project -> Samples -> Identity Blueprints -> Stock Client.
4. Invoke Edit WS Attributes on the StockService service reference. Notice that AM security panel will come up with an
error message indicating that now ServiceRef exists in the project.
The only way I've found for the AM security panel to come is first build the project and then restart the IDE.
I see 2 problems actually here :
The ServiceRef object isn't created for @WebServiceRef annotation when the service class is missing.
This is in due to Annoation Model architecture, when TypeElements require to be resolved (The fully qualified name for
the service class cannot be obtained when the class doesn't exist). I am afraid we cannot do anything with this.
Edit WS Attributes cashes the information from Annotation Model.
Even, when Service class (source file) is created in the project (case 1), the "Edit WS Attributes" dialog doesn't get
the actual model. The information from J2EE Annotation Model should be obtained "on fly" when the dialog is open.
Reassigning back to Peter for evaluation as I don't know who is the owner of AM security panel.
It looks like we will just have to document the first issue.
As for the second issue, I doubled checked. The AM security panel is not caching the annotation model at all. The AM
security panel recheck for the service refs using model.runReadAction(). So, I don't this is the issue.
I am reassigning this back to Milan.
I found the reason for this issue - I mean for the second problem I described.
It's caused by the obscure way how we are adding build/generated/wsimport/client directory to source roots.
We hack somehow the WebProject's SourcePathImplementation:getResources(). Problem is that this method is not called when
client artifacts are generated from wsdl file (build action), only when a WS Clent is created by the wizard.
The result is that java source infracstructure cannot react in this case, that means java source infracstructure is not
notified that java artifacts are generated in build/generated/wsimport/client.
We need to solve this differently : similarly as in java project where we add/remove, programaticaly, the
build/generated/wsimport/client to compile classpath, when needed, that means :
when build/generated/wsimport/client is created or when build/generated/wsimport/client is removed.
I'll try to fix this issue for Beta 1.
Provided build/generated/wsimport/client is under source roots the problem no.2 is gone.
I cannot reproduce the issue since the Blueprints Sample -> StockService project cannot be created.
This should be fixed.
See also the fix for issue 112736.