Hello again.
I've incorporated your code as best I could into myappA. I am able to get
and cast a reference to MySecurityServicesLocalHome. However, a call on
this to ".create()" throws a ClassCastException.
[java] Caused by: java.lang.ClassCastException:
org.openejb.proxy.SessionEJBLocalObject$$EnhancerByCGLIB$$18880c84 cannot be
cast to co.my.MySecurityServicesLocal
[java] at
org.openejb.proxy.EntityEJBLocalHome$$EnhancerByCGLIB$$8786f6ac.create(<generated>)
"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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
