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 Mon, 26 Feb 2007 15:23:11 GMT
I'm looking around for an example of a "dependencies only" plan.  Do you 
happen to know of an example?

> parent classloader for both apps.  I'd recommend putting the  necessarly 
> interface jars into the geronimo repository at appropriate  locations and 
> deploying a "dependencies only" plan to create a  classloader including 
> these jars: then you can have a dependency on  this module in each of your 
> ears.



"David Jencks" <david_jencks@yahoo.com> wrote 
in message news:CAEDC85C-CB2F-45BE-BF37-2E11ABE0C900@yahoo.com...
>
> On Feb 23, 2007, at 1:10 PM, pgrey wrote:
>
>> 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>)
>
> OK, I forgot about this part.... but I think someone mentioned you  wanted 
> to use ejb local references.  That means the interface classes  have to be 
> in the same classloader in both apps.  Since you want to  be able to 
> deploy them independently, you have to get them into  a  parent 
> classloader for both apps.  I'd recommend putting the  necessarly 
> interface jars into the geronimo repository at appropriate  locations and 
> deploying a "dependencies only" plan to create a  classloader including 
> these jars: then you can have a dependency on  this module in each of your 
> ears.
>
> You can also use the sharedlib module, although I don't think that  gives 
> a suitably explicity level of control over your classloaders.
>
> If you don't want to have a shared parent classloader you have to use  a 
> remote rather than local reference.  I think there's code that 
> serializes/deserializes as necessary without actually going over tcp/ ip 
> but I haven't looked there in quite a while and might be wrong.
>
> I figure that if you got this far you found the EjbReference class :-)
>
> Hope this helps
> david jencks
>
>>
>>
>>
>>
>> "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