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
