Created attachment 62310 [details]
messages.log

deployment started : 0%
Deploying application in domain failed; Error loading deployment descriptors for module [WebApplication18] -- wsdl file
META-INF/wsdl/client/SearchWS/SearchWS.wsdl does not exist for service-ref ssb.MySessionBean/service
Deployment error:
The module has not been deployed.
See the server log for details.
        at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:174)
        at org.netbeans.modules.j2ee.ant.Deploy.execute(Deploy.java:104)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
        at sun.reflect.GeneratedMethodAccessor360.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:357)
        at org.apache.tools.ant.Target.performTasks(Target.java:385)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
        at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:277)
        at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:461)
        at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:151)
Caused by: The module has not been deployed.
        at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:168)
        ... 16 more
BUILD FAILED (total time: 2 seconds)

Not planned for 6.8

*** Bug 163083 has been marked as a duplicate of this bug. ***

Increasing to P2, as, IMO, we teach users an incorrect pattern - that also causes other problems.
When an entire ejb is on web application classpath, J2EE server doesn't know if EJB is created in web application or in a separate ejb module.

The EJB Client Jar is one solution for this.
See:
http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.jst.ejb.doc.user/topics/ceclientjars.html

Regarding the following step:

> 4)Create new remote session bean and bussiness method in it

Right now we support creation of the remote interface in a separate project, see bug 179698. Doesn't this also improve this scenario?

Majority of this problem was resolved as bug 179698 - user can generate remote interface into separate project. What should be done in this issue is to verify that "Call Enterprise Bean" wizard adds to classpath correct jar (ie. class library jar and not EJB implementation jar; it should work but needs to be retested).

I verified using the following steps:

1) Start IDE with new userdir
2) Create new JavaEE5 Enterprise App with EJB module (no web module) on Glassfish
3) Create new class library Lib1
4) Create new remote session bean in the EJB module with remote interface in library Lib1 
5) Add bussiness method to it with some implementation, e.g.  return "x";
6) Deploy the enterprise application
7) Create new Web Application Java class in it
8) Call Enterprise Bean and select the bean created in step 4
9) Use this remote call in index.jsp, e.g. 
<%= new NewClass().lookupNewSessionBeanRemote().businessMethod() %>
10) Run the web application

Everything works correctly; after step 8, Lib1 was added to the web project's classpath (not the EJB module). So resolving as FIXED.

The workaround really works, however this doesn't solve the original scenario (the case when you don't have the separate library).

The issue with this workaround is the need of separate library, specifically prepared, before remote EJB is consumed.

What's strange IMO, you need to think very ahead:

- you need to create a specific J2SE library even before EJB is created
- you need to select this library in EJB wizard
  (the strange here is the fact that remote interface is in different project than EJB)
- finally the "Call EJB" action will work as expected

The more natural scenario is:

- There is an EJB project (EJBProject1) with remote EJBs (where remote interfaces are in the same EJB project)
- User wants to consume (remote) EJB in a different project, e.g. WebApp1

In this moment I'd expect IDE will help user to copy the remote interfaces (from EJBProject1 to WebApp1), rather than adding entire EJBProject1 to classpath (silently in the background).

I tested another scenario, that I expected to work :
- There is an EJB project (EJBProject1) with remote EJBs (where remote
- copy manually remote interface from EJBProject1 to WebApp1
- in WebApp1, call (remote) EJB from EJBProject1
Though the remote interface is already there(in WebApp1) the entire EJBProject1 was added to classpath.

I am reopening the issue, and decreasing the priority as there is some workaround already.

> In this moment I'd expect IDE will help user to copy the remote interfaces
> (from EJBProject1 to WebApp1)

But then you would end up with the remote interfaces in two locations, and when you make any change in these interfaces, you would need to do them twice. Code duplication is bad practice and the IDE should NOT help you introduce duplicated code.

So I think the only good and clean solution is to place the remote interfaces to a separate library, which is then imported by both the EJB project and the Web project.

You right, separating EJB to client jar library is probably better considering interfaces are "in development".

However, this requires some more steps:

- separate EJB interface(s) from EJB project into "EJB Client jar"
- add EJB Client jar to EJB project classpath
- add EJB Client jar to Client project classpath

This also hits the problem of adding library to standalone EJB, or to standalone J2EE Client project.

So the solution with Client jar would be much complex than just "copying interfaces".

Anyway, IDE should never put entire EJB application project on client project classpath.

(In reply to comment #9)
> What's strange IMO, you need to think very ahead:
> 
> - you need to create a specific J2SE library even before EJB is created
> - you need to select this library in EJB wizard
>   (the strange here is the fact that remote interface is in different project
> than EJB)
> - finally the "Call EJB" action will work as expected

But user do need to think in advance. Remote interface is something like an API in your architecture. You do not create it suddenly when you decide to call it from an external place. Deciding whether you allow remote access to your EJB or not is significant architectural decision which you build your project around. And part of the design will be ejb-client jar.

What I agree with is that EJB wizard should allow you to not only choose J2SE library project but also allow you to create one directly from the wizard. That would definitely be useful but it is Nice-To-Have category.

(In reply to comment #11)
> However, this requires some more steps:
> - separate EJB interface(s) from EJB project into "EJB Client jar"
> - add EJB Client jar to EJB project classpath
> - add EJB Client jar to Client project classpath

I'm not sure what you mean by that. Yes, that's something what has to be done. Some steps are done automatically when done via new EJB wizard which allows you to store remote interface directly in client ejb jar.

> This also hits the problem of adding library to standalone EJB, or to
> standalone J2EE Client project.

Do you mean that standalone EJB cannot be deployed? Yes, that's something to address as well but that's different problem and should not have any impact on ejb client jar. 

> So the solution with Client jar would be much complex than just "copying
> interfaces".

I agree with Petr that IDE should never help to create code duplicity. If user is aware of what they are trying to achieve they can easily do it themselves - one or two copy tasks in customized project build script.

> Anyway, IDE should never put entire EJB application project on client project
> classpath.

That's bad but that's what we have been doing for last several years (NB 4.x - NB 6.8) and now trying to fix.

Some parts of this request were fixed and some are WONTFIX IMO.

>That's bad but that's what we have been doing for last several years (NB 4.x -
NB 6.8) and now trying to fix.

Do we have another issue for that ?

If you're closing all the issues how do you want to remember there is a problem.
The problem described here(original scenario) wasn't fixed yet and there is no any indication(hint) in IDE to use your workaround.

See also the issue 163083.

I'll let reporters either to verify or reopen the issue.

v.

Clarification: Originally build failed and I got exception from IDE - now webapp is builded correctly,but then I got exception from Glassfish during deploy as said in Issue 163083. I'm letting this issue closed,but reopening second one,since this functionality still doesn't work.