geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: ejb circular references
Date Fri, 23 Feb 2007 18:28:34 GMT

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