Thank you for your response. Let's try to solve a specific part of this problem.
In "geronimo-application.xml" of "myappA.ear", there is the following declaration. <gbean name="my-realm" class="org.apache.geronimo.security.realm.GenericSecurityRealm" xmlns="http://geronimo.apache.org/xml/ns/deployment-1.1";> <attribute name="realmName">my-realm</attribute> <reference name="ServerInfo"> <name>ServerInfo</name> </reference> <reference name="LoginService"> <name>JaasLoginService</name> </reference> <xml-reference name="LoginModuleConfiguration"> <login-config xmlns="http://geronimo.apache.org/xml/ns/loginconfig-1.1";> <login-module control-flag="REQUIRED" server-side="true" wrap-principals="true"> <login-domain-name>my-realm</login-domain-name> <login-module-class>com.my.subject.MyLoginModule</login-module-class> </login-module> </login-config> </xml-reference> </gbean> This declares a security realm usable by all of the WARs in myappA.ear. There are two implementations of the backend security information store. SecurityInformationStoreA is a file, similar to the geronimo sample users.properties and roles.properties. SecurityInformationStoreB is the security model of "myappB.ear", accessed through an local (to geronimo instance) EJB, called MySecurityServicesB. The security information store used is controlled at run time though an external configuration file. When myappA is deployed with myappB, myappA should use SecurityInformationStoreB. When myappA is deployed alone, it should use SecurityInformationStoreA. >From your response, I gather that the XML above needs to include a reference to the SecurityInformationStoreB EJB. Using a reference rather than a dependency will allow myappA to deploy, even if myappB is not present. The suggestion below is an "ejb-ref" element. It is possible that one of these needs to go somewhere else in geronimo-application.xml. To tie this back in to the original post, myappB makes use of myappA EJBs. myappB gracefully handles the absence of myappA by returning "nothing". myappA handles the absence of myappB by using the alternative security information store. Thank you for any insight you might have into possible solutions using Geronimo 1.1.1. "David Jencks" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > On Feb 22, 2007, at 3:06 PM, pgrey wrote: > >> Yes, we have run into a problem. >> >> The EJBs are in different EARs. >> >>> If you ejbs are in different ears, things get a bit trickier. IIRC >>> you >>> have to supply the entire abstract name of the ejb container gbean >>> for >>> at least one side of the relationship. >> >> Can you give an example of "supply the entire abstract name of the ejb >> container gbean"? > > This would go in your geronimo plan, I think its the correct syntax for > g. 1.1 and 1.2. > > Lets say your looking for the bar ejb in (geronimo) module com.myco/ > app1/1.0/car in the ejb1.jar (j2ee) module > > <ejb-ref> > <ref-name>foo</ref-name> > <pattern> > <groupId>com.myco</groupId> > <artifactId>app1</artifactId> > <version>1.0</version> > <type>car</type> > <module>ejb1.jar</module> > <name>bar</name> > </pattern> > </ejb-ref> > > You can probably leave out the version, and possibly the type and module. > > thanks > david jencks > >> >> Thank you kindly. >> >> >> "David Jencks" <[EMAIL PROTECTED]> >> wrote >> in message >> news:[EMAIL PROTECTED] >>> >>> On Feb 22, 2007, at 12:24 PM, Spotts, Joel ((ISS Atlanta)) wrote: >>> >>>> I have a bit of a predicament with circular refrences in EJBs. Due to >>>> legacy reasons, I have two EJBs - each which references the other >>>> (and >>>> refactoring would be non-trivial). I would prefer to keep them local >>>> (as >>>> opposed to remote) for security reasons. Trouble is, I don't know how >>>> to >>>> deploy such an arrangement in geronimo. Each EJB will need to >>>> reference >>>> the other in openejb- jar.xml with an <ejb-ref> stanza. But since each >>>> one is dependent on the other, each one cannot be deployed before the >>>> other (as geronimo checks for the ejb reference at deploy time). >>>> Without >>>> violated some accepted principals of physics, that leads to an >>>> impossible situation. How could I go about solving this issue? >>> >>> This is supposed to work easily, at least if the ejbs are in the same >>> ear. Deployment goes in phases: in "initContext" we try to find out >>> and >>> "publish" all the things you could possibly reference, such as ejbs >>> and >>> datasources. Then in "addGBeans" we process the jndir ref info and >>> construct the jndi References to the appropriate stuff. For ejbs in >>> the >>> same ear, all necessary info should have been "published" and thus >>> available. >>> >>> If you ejbs are in different ears, things get a bit trickier. IIRC >>> you >>> have to supply the entire abstract name of the ejb container gbean >>> for >>> at least one side of the relationship. >>> >>> Are you speculating or have you actually run into a problem :-)? >>> >>> thanks >>> david jencks >>> >>>> >>>> Thanks, >>>> >>>> Yoel Spotts >>> >>> >> >> >> > >
