geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "pgrey" <pg...@iss.net>
Subject Re: ejb circular references
Date Fri, 23 Feb 2007 21:10:39 GMT
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" <david_jencks@yahoo.com> wrote 
in message news:D5401B05-A79F-4A1D-9E18-511229CCBF37@yahoo.com...
>
> 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" <david_jencks@yahoo.com> 
>> wrote
>> in message 
>> news:58AB7426-2670-4DF0-9A96-7EF0B299E65D@yahoo.com...
>>>
>>> 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" <david_jencks@yahoo.com>
>>>> wrote
>>>> in message
>>>> news:235FAA12-810B-4CAF-975A-8A66357100A1@yahoo.com...
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
> 




Mime
View raw message