Hi, thanks so much. There is a lot of content here. What is the package of the "EjbReference" class referred to below?
"David Jencks" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > On Feb 23, 2007, at 7:31 AM, pgrey wrote: > >> 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. >> > > you need to be able to run either app with or without the other app > present, right? > > IIUC there are 2 different situations here. > --myappB has j2ee components (ejbs) accessing ejbs in myappA. You should > be able to make this work with the ejb-ref xml I showed before in > myappB's geronimo plan. > --a login module deployed with myappA needs to be able to access ejbs in > myappB. This is harder. A login module is not a j2ee component, so it > doesn't have the java:comp/env jndi environment available to it, and > there is no spec compliant standard way to access a local ejb from a > non-j2ee-component, so you will need some geronimo specific code. The > easiest way is to use the ejb Reference object we use in jndi, yourself. > > > Your login module will need to use the geronimo Kernel. It can obtain > this from the options by looking up the key > "org.apache.geronimo.security.realm.GenericSecurityRealm.KERNEL". I'd > suggest passing in the name of the ejb it's trying to use as another > option. This would be the geronimo AbstractName of the ejb container > gbean. It also needs the moduleId of the app it's in. > > public void initialize(Subject subject, CallbackHandler > callbackHandler, Map sharedState, Map options) { > Kernel kernel = (Kernel) options.get > ("org.apache.geronimo.security.realm.GenericSecurityRealm.KERNEL"); > String ejbNameString = (String) options.get > ("com.myco.SecurityEjbAbstractName"); > AbstractNameQuery ejbNameQuery = new AbstractNameQuery > (URI.create(ejbNameString)); > String moduleIdString = (String) options.get > ("com.myco.security.ModuleId"); > Artifact moduleId = Artifact.create(moduleIdString); > > EjbReference ref = new EjbReference(moduleId, ejbNameQuery, > false); > ref.setKernel(kernel); > EjbBLocalHome home = (EjbBLocalHome) ref.getContent(); > ... > > } > > So this uses options > org.apache.geronimo.security.realm.GenericSecurityRealm.KERNEL which you > don't have to set (geronimo sets it by itself), > com.myco.SecurityEjbAbstractName (something that uniquely identifies the > ejb target. If nothing in your app has a similar name, "? name=EjbB#" > should work) > com.myco.security.ModuleId (the moduleId specified in the geronimo plan > for moduleA, as a string like groupId/artifactId/version/type) > > The last 2 need to be set in the xml login configuration. > > if you unwind the code the EjbReference uses you can eliminate the > moduleId. To compile this you'll need at least the geronimo-kernel, > geronimo-naming, and openejb-core jars in your classpath. If you copy > appropriate bits of the code you can eliminate geronmo-naming. > > hope this helps > david jencks > > > >> >> >> "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 >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > >
