glassfish_at_javadesktop.org wrote:
>> This reminds me of an other related question. My web
>> project uses EJB
>> local session beans. Since they are not remote there
>> are no stubs
>>
>
> Actually, in Glassfish there are no developer-visible stubs in the Remote case either. If the caller and target EJB are in the same .ear, there is no difference in terms of the packaging requirements between the Local EJB view and the Remote EJB view.
>
My challenge is that I can't use the local or remote EJB in my web
application without NetBeans telling me that it can't find the class
unless I add the EJB project to the libraries tab. I tell it to not
package the EJB project in the war because both projects live inside of
the EAR. I understand why this happens and it makes sense. I'm trying
to find out if there is a more proper way to handle this dependency.
>> , and
>> therefore my web project has a build dependency on
>> the EJB project. I
>> can't think of an other way to use a local EJB
>> without having a build
>> dependency on the EJB project. Is that correct?
>>
>
> All that matters is that the calling component has visibility to the classes it needs to invoke the EJB. At minimum, that means the Remote or Local interface itself, but it would also include any supporting classes or interfaces. If the caller is in a web application, those .class files can be put in WEB-INF/classes, in a .jar file in WEB-INF/lib, or refactored into a library .jar at the top-level of the .ear.
>
The visibility of these classes is different at runtime than it is at
design time. The IDE knows that my web and EJB projects are both part
of the same EAR project, but it does not automatically make my web
project able to use the classes in the EJB project. Is it not better to
add my NetBeans EJB project to the libraries tab of my NetBeans web
project instead of making physical copies of the remote or local
interface? I also don't like the idea of taking the compiled classes
from my EJB project and adding it to my WEB-INF/classes because these
interfaces change over time. However when the new Java 7 module system
makes this natural, I won't mind.
> Where you package the entity classes and where you define the PU are
> two different issues. If the entities are used by more than one module
> it's much cleaner to refactor and package the classes once at the
> top-level of the .ear. Technically, if the web application doesn't
> actually use the EntityManager API it doesn't need visibility to the
> persistence-unit, so it would be ok to define the PU in the ejb-jar
> itself. However, if that's likely to change you could just define the
> PU at the top-level of the .ear.
Thanks for the tip.
> BTW, we're paying a lot of attention to the combined web/EJB case in EJB 3.1. We'll be adding requirements that allow EJBs to be defined directly in the .war, so that the web->ejb->JPA use-case can be fully realized with only a stand-alone .war and no ejb-jar / .ear.
>
Yes I have read a bit about that. I didn't know this was going to be in
EJB 3.1 though, I thought it had something to do with Java 7 module
system. Either way I'm looking forward to this enhancement. I will then
have only one project in NetBeans instead of three (war, ejb, ear).
The improvements in EJB 3.1 that I am looking forward to the most are
singleton beans, cron like EJB timer, and stateful web services.
Thanks,
Ryan