Application client container feedback...
A few weeks ago I wrote a short article about application client containers while I was working at getting my application running with Glassfish. I've finally gotten around to posting it online and thought it might provide some useful feedback / insight since it really applies to any application server. Here's the link if anyone's interested: http://jroller.com/page/ryan6608?entry=failure_to_deploy_java_s Ryan
Re: Is there a vendor independent way of accessing EJBs from a standalone client?
I suggest you put an interface in that abstracts the lookups. This will let your code easily switch between vendors. -dain On Feb 22, 2007, at 3:13 PM, Ryan wrote: You're right, I didn't quite explain things 100%. I would like to have a .ear file that contains EJBs and a Swing client. I would like to be able to deploy that .ear and have it work on Glassfish or Geronimo, but don't want to change naming lookups, etc. I really just want to have the option of switching vendors at a later date. I will always use a matching app server and client container (ie: Geronimos AS with Geronimo ACC, or Glassfish AS with Glassfish ACC). Ryan Jencks wrote: I'm unclear on whether you plan to run the app client on the same vendors product as the ejb itself. If you plan to use 2 vendors you have to use corba. If you plan to use the app client container and the ejb container from geronimo, what you are trying should work. However for geronimo you would have to have deployed the ejb application first (assuming it is not packaged in an ear with the app client) and the ejb app would have to be a parent of the client app. Under these circumstances the deployers should be able to find your ejb at deploy time and figure out how to hook up to it when you run the app client. thanks david jencks On Feb 22, 2007, at 1:46 AM, Ryan wrote: Hi, I'm working at setting up an application client and am having some difficulty accessing EJBs on the server. I'm running my client using an application client container and am trying it out on a few different application servers. However, I'm having difficulty finding a way to lookup EJBs in a vendor independent manner. Specifically, almost every doc I can find has some variation of: Context initialContext = new InitialContext(); Object ref = initialContext.lookup(some vendor specific name here); If I replace some vendor specific name here with the proper vendor specific name for each app server and re-deploy everything works. At first I thought I could use application-client.xml to name each EJB and have the container(s) take care of the mapping, but I haven't had any luck with this approach. I tried something like this (relevant parts only): ejb-ref ejb-ref-nameejb/test1234/ConnectionTester/ejb-ref-name ejb-ref-typeSession/ejb-ref-type remotedomain.ejb.interfaces.ConnectionTesterRemote/remote /ejb-ref When I deploy to Glassfish using the above I end up with a JNDI name of ejb/test1234/ConnectionTester and can look it up using java:comp/env/ejb/test1234/ConnectionTester. However, when I try to deploy to Geronimo, I get the following error (while deploying): org.apache.openejb.OpenEJBException: Cannot find bean ejb/test1234/ConnectionTester referenced by bean GeronimoEnc. Obviously I'm missing something because Glassfish appears to use 'ejb-ref-name' as a type of alias for the EJB name while Geronimo thinks it contains the name of an existing EJB. Maybe I'm just not thinking clearly tonight, but isn't there some kind of simple, standard way of looking up an EJB from a standalone client? Is vendor independence even a realistic goal (that's what the spec is for right)? Thanks in advance for any help, Ryan P.S. Sorry for the formatting :-(
Re: ejb circular references
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=realmNamemy-realm/attribute reference name=ServerInfo nameServerInfo/name /reference reference name=LoginService nameJaasLoginService/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-namemy-realm/login-domain-name login-module-classcom.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. 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-namefoo/ref-name pattern groupIdcom.myco/groupId artifactIdapp1/artifactId version1.0/version typecar/type moduleejb1.jar/module namebar/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
Re: Is there a vendor independent way of accessing EJBs from a standalone client?
On Feb 23, 2007, at 7:26 AM, Dain Sundstrom wrote: I suggest you put an interface in that abstracts the lookups. This will let your code easily switch between vendors. Why would he want to do that? He's using a javaee app client container, so the spec says how to get to an ejb in the same ear in a standard way. On a spec compliant server it will just work. thanks david jencks -dain On Feb 22, 2007, at 3:13 PM, Ryan wrote: You're right, I didn't quite explain things 100%. I would like to have a .ear file that contains EJBs and a Swing client. I would like to be able to deploy that .ear and have it work on Glassfish or Geronimo, but don't want to change naming lookups, etc. I really just want to have the option of switching vendors at a later date. I will always use a matching app server and client container (ie: Geronimos AS with Geronimo ACC, or Glassfish AS with Glassfish ACC). Ryan Jencks wrote: I'm unclear on whether you plan to run the app client on the same vendors product as the ejb itself. If you plan to use 2 vendors you have to use corba. If you plan to use the app client container and the ejb container from geronimo, what you are trying should work. However for geronimo you would have to have deployed the ejb application first (assuming it is not packaged in an ear with the app client) and the ejb app would have to be a parent of the client app. Under these circumstances the deployers should be able to find your ejb at deploy time and figure out how to hook up to it when you run the app client. thanks david jencks On Feb 22, 2007, at 1:46 AM, Ryan wrote: Hi, I'm working at setting up an application client and am having some difficulty accessing EJBs on the server. I'm running my client using an application client container and am trying it out on a few different application servers. However, I'm having difficulty finding a way to lookup EJBs in a vendor independent manner. Specifically, almost every doc I can find has some variation of: Context initialContext = new InitialContext(); Object ref = initialContext.lookup(some vendor specific name here); If I replace some vendor specific name here with the proper vendor specific name for each app server and re-deploy everything works. At first I thought I could use application-client.xml to name each EJB and have the container(s) take care of the mapping, but I haven't had any luck with this approach. I tried something like this (relevant parts only): ejb-ref ejb-ref-nameejb/test1234/ConnectionTester/ejb-ref-name ejb-ref-typeSession/ejb-ref-type remotedomain.ejb.interfaces.ConnectionTesterRemote/remote /ejb-ref When I deploy to Glassfish using the above I end up with a JNDI name of ejb/test1234/ConnectionTester and can look it up using java:comp/env/ejb/test1234/ConnectionTester. However, when I try to deploy to Geronimo, I get the following error (while deploying): org.apache.openejb.OpenEJBException: Cannot find bean ejb/test1234/ConnectionTester referenced by bean GeronimoEnc. Obviously I'm missing something because Glassfish appears to use 'ejb-ref-name' as a type of alias for the EJB name while Geronimo thinks it contains the name of an existing EJB. Maybe I'm just not thinking clearly tonight, but isn't there some kind of simple, standard way of looking up an EJB from a standalone client? Is vendor independence even a realistic goal (that's what the spec is for right)? Thanks in advance for any help, Ryan P.S. Sorry for the formatting :-(
Re: ejb circular references
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=realmNamemy-realm/attribute
reference name=ServerInfo
nameServerInfo/name
/reference
reference name=LoginService
nameJaasLoginService/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-namemy-realm/login-domain-name
login-module-classcom.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]
Andromda ejb3 ear application on geronimo-tomcat6-j2ee5-2.0-M2
I'm using a AndroMDA EJB3
Cartridgehttp://web.aanet.com.au/persabi/andromda/to generate an ear
plus some custom merge point
mappings.The generated classes hierarchy is like
-
RentalServiceBean.javahttp://web.aanet.com.au/persabi/andromda/howto/org/andromda/test/howto3/a/RentalServiceBean.java
-
RentalServiceRemote.javahttp://web.aanet.com.au/persabi/andromda/howto/org/andromda/test/howto3/a/RentalServiceRemote.java
-
ServiceDelegateBase.javahttp://web.aanet.com.au/persabi/andromda/howto/org/andromda/test/ServiceDelegateBase.java
-
RentalServiceDelegate.javahttp://web.aanet.com.au/persabi/andromda/howto/org/andromda/test/howto3/a/RentalServiceDelegate.java
-
RentalServiceBase.javahttp://web.aanet.com.au/persabi/andromda/howto/org/andromda/test/howto3/a/RentalServiceBase.java
-
RentalServiceException.javahttp://web.aanet.com.au/persabi/andromda/howto/org/andromda/test/howto3/a/RentalServiceException.java
I just override templates/ejb3/SessionRemote.vsl and add @Remote
import javax.ejb.Remote;
@Remote
public interface UserServiceRemote
{
public com.urmet.vo.UserVO[] getAllUsers();
}
Error: Unable to distribute usermanagement-1.0-SNAPSHOT.ear: Remote
interface does not extend javax.ejb.EJBObject:
com.urmet.service.UserServiceRemote
server.log
Geronimo startup complete
18:35:37,875 WARN [OpenEJB] Auto-deploying ejb UserServiceBean:
EjbDeployment(deployment-id=geronim
o-deploymentUtil18632.tmpdir/UserServiceBean, container-id=Default
Stateless Container)
18:35:37,875 WARN [OpenEJB] Auto-deploying ejb UserDao:
EjbDeployment(deployment-id=geronimo-deploy
mentUtil18632.tmpdir/UserDao, container-id=Default Stateless Container)
I successfully deploy
calculator-stateless-pojohttps://svn.apache.org/repos/asf/geronimo/samples/trunk/samples/calculator-stateless-pojo/and
I cannot understand why I cannot deploy my application in the same
way.
Any idea or suggestions?
Re: ejb circular references
Hi, thanks so much. There is a lot of content here.
What is the package of the EjbReference class referred to below?
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=realmNamemy-realm/attribute
reference name=ServerInfo
nameServerInfo/name
/reference
reference name=LoginService
nameJaasLoginService/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-namemy-realm/login-domain-name
login-module-classcom.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
Re: ejb circular references
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=realmNamemy-realm/attribute
reference name=ServerInfo
nameServerInfo/name
/reference
reference name=LoginService
nameJaasLoginService/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-namemy-realm/login-domain-name
login-module-classcom.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
Re: ejb circular references
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 [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=realmNamemy-realm/attribute reference name=ServerInfo nameServerInfo/name /reference reference name=LoginService nameJaasLoginService/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-namemy-realm/login-domain-name login-module-classcom.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
Re: ejb circular references
Thanks again. For posterity, the class is org.openejb.proxy.EJBProxyReference (GMO 1.1.1 uses openejb 2.1.1). I think I understand what is required. Will reply Monday with results. David Jencks [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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 [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=realmNamemy-realm/attribute reference name=ServerInfo nameServerInfo/name /reference reference name=LoginService nameJaasLoginService/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-namemy-realm/login-domain-name login-module-classcom.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
Re: Andromda ejb3 ear application on geronimo-tomcat6-j2ee5-2.0-M2
I've no idea what the problem is But I'm happy to hear folks are using (or
trying to use) andromda with geronimo. Would eventually like to get a sample
together that shows this. I really like andromda... Good to see folks using it
;-)
--jason
-Original Message-
From: Michele La Porta [EMAIL PROTECTED]
Date: Fri, 23 Feb 2007 19:46:00
To:user@geronimo.apache.org
Subject: Andromda ejb3 ear application on geronimo-tomcat6-j2ee5-2.0-M2
I'm using a AndroMDA EJB3 Cartridge:
http://web.aanet.com.au/persabi/andromda/ to generate an ear plus some
custom merge point mappings.The generated classes hierarchy is like
*
:
http://web.aanet.com.au/persabi/andromda/howto/org/andromda/test/howto3/a/RentalServiceBean.java
RentalServiceBean.java
*
:
http://web.aanet.com.au/persabi/andromda/howto/org/andromda/test/howto3/a/RentalServiceRemote.java
RentalServiceRemote.java
*
:
http://web.aanet.com.au/persabi/andromda/howto/org/andromda/test/ServiceDelegateBase.java
ServiceDelegateBase.java
*
:
http://web.aanet.com.au/persabi/andromda/howto/org/andromda/test/howto3/a/RentalServiceDelegate.java
RentalServiceDelegate.java
*
:
http://web.aanet.com.au/persabi/andromda/howto/org/andromda/test/howto3/a/RentalServiceBase.java
RentalServiceBase.java
*
:
http://web.aanet.com.au/persabi/andromda/howto/org/andromda/test/howto3/a/RentalServiceException.java
RentalServiceException.java
I just override templates/ejb3/SessionRemote.vsl and add @Remote
import javax.ejb.Remote;
@Remote
public interface UserServiceRemote
{
public com.urmet.vo.UserVO[] getAllUsers();
}
Error: Unable to distribute usermanagement-1.0-SNAPSHOT.ear: Remote
interface does not extend javax.ejb.EJBObject:
com.urmet.service.UserServiceRemote
server.log
Geronimo startup complete
18:35:37,875 WARN [OpenEJB] Auto-deploying ejb UserServiceBean:
EjbDeployment(deployment-id=geronim
o-deploymentUtil18632.tmpdir/UserServiceBean, container-id=Default
Stateless Container)
18:35:37,875 WARN [OpenEJB] Auto-deploying ejb UserDao:
EjbDeployment(deployment-id=geronimo-deploy
mentUtil18632.tmpdir/UserDao, container-id=Default Stateless Container)
I successfully deploy calculator-stateless-pojo
:
https://svn.apache.org/repos/asf/geronimo/samples/trunk/samples/calculator-stateless-pojo/
and I cannot understand why I cannot deploy my application in the same way.
Any idea or suggestions?
