I would think that JNDI would be the solution. A JNDI reference to
cluster A's EJB and a second JNDI reference to cluster B's EJB could
be used to control the injection of the EJB references. As long as
the Cluster hosting the App Client has both JNDI references I would
think that it _should_ work.
Of course I am talking out of my arse having not tried this or checked
that the spec allows it ;-)
On Dec 4, 2007 3:00 PM, <glassfish_at_javadesktop.org> wrote:
> Hi,
>
> after studying the known documentation at
> (https://glassfish.dev.java.net/javaee5/build/GlassFish_LB_Cluster.html
> http://developers.sun.com/appserver/reference/techart/glassfishcluster/),
> we can't find a solution for our scenario.
>
> We have the need to separate specific EJBs (different remote interfaces) to different ServerInstances (different JVMs, because of needed memory) in one enterprise application. A client needs to have access to all different EJB remote interfaces. The client is a Java WebStart which runs in an application client container (ACC).
>
> Sample:
> We have some EJBs packed together for functionality A and some others packed together for functionality B. We try to setup two clusters called A and B. cluster A should only contain (deployed) the EJBs for functionality A and the cluster B should only contain (deployed) the EJBs for functionality B. Both clusters are belongs to the same enterprise application and the same GlassFish domain.
>
> It is possible to access all EJB references for both clusters A and B from one ACC?
>
> It seems that the @EJB annotation for ACC based clients, does not work out of the box for such a scenario.
>
> We are not sure if this is the right approach for our situation. Maybe there are other possibilities to achieve different EJBs (with different remote interfaces) running in different ServerInstances (JVMs).
>
> Thanks in advance,
>
> greetings,
> Frank Meilinger
> [Message sent by forum member 'fmeili' (fmeili)]
>
> http://forums.java.net/jive/thread.jspa?messageID=248425
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>