AW: AW: Using JacORB not possible within Geronimo?

2007-07-24 Thread Andersch, Jens (DWBI)

Unfortunately openejb has a dependency on Yoko. 
Have a look at .../repository/org/apache/geronimo/configs/openejb/2.0-M6/ 
openejb-2.0-M6.car/META-INF/config.ser.

How can I get rid of this dependency and tell openejb to use jacorb?

thanks
Jens


-Ursprüngliche Nachricht-
Von: Dain Sundstrom [mailto:[EMAIL PROTECTED] 
Gesendet: Montag, 23. Juli 2007 19:33
An: user@geronimo.apache.org
Betreff: Re: AW: Using JacORB not possible within Geronimo?

The actual code we use to create the orb bound to java:comp/ORB is  
simply ORB orb = ORB.init(); so it should what with what ever you  
have configured as the default ORB in your VM.  OpenEJB doesn't even  
have a dependency on Yoko.

-dain

On Jul 20, 2007, at 8:09 AM, David Jencks wrote:

 The yoko stuff is in the connector-deployer defaultEnvironment so  
 we can construct working jndi references so you can look up  
 java:comp/ORB and IIRC it's in the ejb stuff for a similar reason.  
 So if you don't need an automatic resource-ref to java:comp/ORB or  
 anything similar I think you can override the defaultEnvironments  
 in config.xml for these two builders.

 I think that in geronimo 1.2 we were able to more easily run  
 without an orb but with the annotation stuff and various  
 automatic jndi references to orbs it has become more difficult.   
 I doubt we'll get to it by 2.0 but you might file a JIRA tracking  
 the problems you've run into here.

 thanks
 david jencks

 On Jul 20, 2007, at 1:42 AM, Andersch, Jens (DWBI) wrote:

 Thank you for your help,

 That seems to work. I only replaced the yoko jars within the  
 endorsed dir by the jacorb jars and made the following changes  
 within config.xml:

 module name=org.apache.geronimo.configs/j2ee-corba-yoko/2.0-M6/ 
 car

 gbean load=false name=NameServer

 ...

 /gbean

 gbean load=false name=Server

 ...

 /gbean

 gbean load=false name=UnprotectedServer

 ...

 /gbean

 /module



 I am not really happy with this solution because I am not sure if  
 I will get any side effects in the future.

 What should I do with the connector-deployer module which also  
 depends on yoko classes ? If I delete yoko from the

 repository subdir I get a lot of exceptions because of the  
 dependencies in the connector-deployer module.

 Moreover the openejb classes throw exceptions if they can't find  
 the yoko jars in the repository.

 So I have to keep them.



 module name=org.apache.geronimo.configs/connector-deployer/2.0- 
 M6/car

 gbean name=ResourceRefBuilder

 attribute name=eeNamespaceshttp://java.sun.com/xml/ 
 ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute

 attribute name=defaultEnvironment

 environment xmlns=http://geronimo.apache.org/xml/ 
 ns/deployment-1.2  
 dependencies  
 dependency  
 groupIdorg.apache.geronimo.configs/ 
 groupId artifactIdj2ee-corba-yoko/ 
 artifactId typecar/ 
 type /dependency / 
 dependencies /environment

 /attribute

 /gbean

 gbean name=AdminObjectRefBuilder

 attribute name=eeNamespaceshttp://java.sun.com/xml/ 
 ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute

 /gbean

 gbean name=ClientResourceRefBuilder

 attribute name=eeNamespaceshttp://java.sun.com/xml/ 
 ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute

 attribute name=defaultEnvironment

 environment xmlns=http://geronimo.apache.org/xml/ 
 ns/deployment-1.2  
 dependencies  
 dependency  
 groupIdorg.apache.geronimo.configs/ 
 groupId artifactIdclient-corba- 
 yoko/artifactId typecar/ 
 type /dependency / 
 dependencies /environment

 /attribute

 /gbean

 /module



 Jens



 Von: David Jencks [mailto:[EMAIL PROTECTED]
 Gesendet: Mittwoch, 18. Juli 2007 20:36
 An: user@geronimo.apache.org
 Betreff: Re: Using JacORB not possible within Geronimo?



 We havent' tried this, and you probably won't be able to use the  
 corba ejb transport



 I would start by moving to the almost released geronimo 1.2 or  
 also close to release 2.0 since they are set up to use a non-jdk  
 orb, namely yoko.  I think it will be easier to switch which non- 
 jdk orb you use than switch from jdk orb to non-jdk orb.



 You should then remove the yoko corba spec jars from lib/endorsed  
 and the yoko jars from the geronimo repository and comment out  
 stuff in config.xml until geronimo starts :-)



 Now put the jacORB spec jar(s) in lib/endorsed and try your app.



 Hope this helps

 david jencks

Re: AW: AW: Using JacORB not possible within Geronimo?

2007-07-24 Thread Dain Sundstrom
That is a result of how Geronimo did the integration with OpenEJB not  
the OpenEJB project itself, which has no Yoko dependencies.


-dain

On Jul 24, 2007, at 12:39 AM, Andersch, Jens (DWBI) wrote:



Unfortunately openejb has a dependency on Yoko.
Have a look at .../repository/org/apache/geronimo/configs/openejb/ 
2.0-M6/ openejb-2.0-M6.car/META-INF/config.ser.


How can I get rid of this dependency and tell openejb to use jacorb?

thanks
Jens


-Ursprüngliche Nachricht-
Von: Dain Sundstrom [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 23. Juli 2007 19:33
An: user@geronimo.apache.org
Betreff: Re: AW: Using JacORB not possible within Geronimo?

The actual code we use to create the orb bound to java:comp/ORB is
simply ORB orb = ORB.init(); so it should what with what ever you
have configured as the default ORB in your VM.  OpenEJB doesn't even
have a dependency on Yoko.

-dain

On Jul 20, 2007, at 8:09 AM, David Jencks wrote:


The yoko stuff is in the connector-deployer defaultEnvironment so
we can construct working jndi references so you can look up
java:comp/ORB and IIRC it's in the ejb stuff for a similar reason.
So if you don't need an automatic resource-ref to java:comp/ORB or
anything similar I think you can override the defaultEnvironments
in config.xml for these two builders.

I think that in geronimo 1.2 we were able to more easily run
without an orb but with the annotation stuff and various
automatic jndi references to orbs it has become more difficult.
I doubt we'll get to it by 2.0 but you might file a JIRA tracking
the problems you've run into here.

thanks
david jencks

On Jul 20, 2007, at 1:42 AM, Andersch, Jens (DWBI) wrote:


Thank you for your help,

That seems to work. I only replaced the yoko jars within the
endorsed dir by the jacorb jars and made the following changes
within config.xml:

module name=org.apache.geronimo.configs/j2ee-corba-yoko/2.0-M6/
car

gbean load=false name=NameServer

...

/gbean

gbean load=false name=Server

...

/gbean

gbean load=false name=UnprotectedServer

...

/gbean

/module



I am not really happy with this solution because I am not sure if
I will get any side effects in the future.

What should I do with the connector-deployer module which also
depends on yoko classes ? If I delete yoko from the

repository subdir I get a lot of exceptions because of the
dependencies in the connector-deployer module.

Moreover the openejb classes throw exceptions if they can't find
the yoko jars in the repository.

So I have to keep them.



module name=org.apache.geronimo.configs/connector-deployer/2.0-
M6/car

gbean name=ResourceRefBuilder

attribute name=eeNamespaceshttp://java.sun.com/xml/
ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute

attribute name=defaultEnvironment

environment xmlns=http://geronimo.apache.org/xml/
ns/deployment-1.2
dependencies
dependency
groupIdorg.apache.geronimo.configs/
groupId artifactIdj2ee-corba-yoko/
artifactId typecar/
type /dependency /
dependencies /environment

/attribute

/gbean

gbean name=AdminObjectRefBuilder

attribute name=eeNamespaceshttp://java.sun.com/xml/
ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute

/gbean

gbean name=ClientResourceRefBuilder

attribute name=eeNamespaceshttp://java.sun.com/xml/
ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute

attribute name=defaultEnvironment

environment xmlns=http://geronimo.apache.org/xml/
ns/deployment-1.2
dependencies
dependency
groupIdorg.apache.geronimo.configs/
groupId artifactIdclient-corba-
yoko/artifactId typecar/
type /dependency /
dependencies /environment

/attribute

/gbean

/module



Jens



Von: David Jencks [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 18. Juli 2007 20:36
An: user@geronimo.apache.org
Betreff: Re: Using JacORB not possible within Geronimo?



We havent' tried this, and you probably won't be able to use the
corba ejb transport



I would start by moving to the almost released geronimo 1.2 or
also close to release 2.0 since they are set up to use a non-jdk
orb, namely yoko.  I think it will be easier to switch which non-
jdk orb you use than switch from jdk orb to non-jdk orb.



You should then remove the yoko corba spec jars from lib/endorsed
and the yoko jars from the geronimo repository and comment out
stuff in config.xml until geronimo starts :-)



Now put the jacORB spec jar(s) in lib/endorsed and try your app.



Hope this helps

david jencks





On Jul 17, 2007, at 11:46 PM, Andersch, Jens (DWBI) wrote:




Hi All,



does anyone know

Re: AW: Using JacORB not possible within Geronimo?

2007-07-23 Thread Dain Sundstrom
The actual code we use to create the orb bound to java:comp/ORB is  
simply ORB orb = ORB.init(); so it should what with what ever you  
have configured as the default ORB in your VM.  OpenEJB doesn't even  
have a dependency on Yoko.


-dain

On Jul 20, 2007, at 8:09 AM, David Jencks wrote:

The yoko stuff is in the connector-deployer defaultEnvironment so  
we can construct working jndi references so you can look up  
java:comp/ORB and IIRC it's in the ejb stuff for a similar reason.  
So if you don't need an automatic resource-ref to java:comp/ORB or  
anything similar I think you can override the defaultEnvironments  
in config.xml for these two builders.


I think that in geronimo 1.2 we were able to more easily run  
without an orb but with the annotation stuff and various  
automatic jndi references to orbs it has become more difficult.   
I doubt we'll get to it by 2.0 but you might file a JIRA tracking  
the problems you've run into here.


thanks
david jencks

On Jul 20, 2007, at 1:42 AM, Andersch, Jens (DWBI) wrote:


Thank you for your help,

That seems to work. I only replaced the yoko jars within the  
endorsed dir by the jacorb jars and made the following changes  
within config.xml:


module name=org.apache.geronimo.configs/j2ee-corba-yoko/2.0-M6/ 
car


gbean load=false name=NameServer

…

/gbean

gbean load=false name=Server

…

/gbean

gbean load=false name=UnprotectedServer

…

/gbean

/module



I am not really happy with this solution because I am not sure if  
I will get any side effects in the future.


What should I do with the connector-deployer module which also  
depends on yoko classes ? If I delete yoko from the


repository subdir I get a lot of exceptions because of the  
dependencies in the connector-deployer module.


Moreover the openejb classes throw exceptions if they can’t find  
the yoko jars in the repository.


So I have to keep them.



module name=org.apache.geronimo.configs/connector-deployer/2.0- 
M6/car


gbean name=ResourceRefBuilder

attribute name=eeNamespaceshttp://java.sun.com/xml/ 
ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute


attribute name=defaultEnvironment

environment xmlns=http://geronimo.apache.org/xml/ 
ns/deployment-1.2  
dependencies  
dependency  
groupIdorg.apache.geronimo.configs/ 
groupId artifactIdj2ee-corba-yoko/ 
artifactId typecar/ 
type /dependency / 
dependencies /environment


/attribute

/gbean

gbean name=AdminObjectRefBuilder

attribute name=eeNamespaceshttp://java.sun.com/xml/ 
ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute


/gbean

gbean name=ClientResourceRefBuilder

attribute name=eeNamespaceshttp://java.sun.com/xml/ 
ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute


attribute name=defaultEnvironment

environment xmlns=http://geronimo.apache.org/xml/ 
ns/deployment-1.2  
dependencies  
dependency  
groupIdorg.apache.geronimo.configs/ 
groupId artifactIdclient-corba- 
yoko/artifactId typecar/ 
type /dependency / 
dependencies /environment


/attribute

/gbean

/module



Jens



Von: David Jencks [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 18. Juli 2007 20:36
An: user@geronimo.apache.org
Betreff: Re: Using JacORB not possible within Geronimo?



We havent' tried this, and you probably won't be able to use the  
corba ejb transport




I would start by moving to the almost released geronimo 1.2 or  
also close to release 2.0 since they are set up to use a non-jdk  
orb, namely yoko.  I think it will be easier to switch which non- 
jdk orb you use than switch from jdk orb to non-jdk orb.




You should then remove the yoko corba spec jars from lib/endorsed  
and the yoko jars from the geronimo repository and comment out  
stuff in config.xml until geronimo starts :-)




Now put the jacORB spec jar(s) in lib/endorsed and try your app.



Hope this helps

david jencks





On Jul 17, 2007, at 11:46 PM, Andersch, Jens (DWBI) wrote:




Hi All,



does anyone know, if it is possible to deploy an own ear which  
contains a connector rar that uses JacORB instead of the ORB  
Implementation used by Geronimo 1.1.1 itself.


I have the problem that the class loader loads the org.omg classes  
from …/repository/geronimo-spec/geronimo-spec-corba/1.0/geronimo- 
spec-corba-1.0.jar and my jacorb classes from the jar included in  
the rar.


Unfortunately some org.omg classes do not have the same versions  
as 

Re: AW: Using JacORB not possible within Geronimo?

2007-07-23 Thread Rick McGuire

Dain Sundstrom wrote:
The actual code we use to create the orb bound to java:comp/ORB is 
simply ORB orb = ORB.init(); so it should what with what ever you 
have configured as the default ORB in your VM.  OpenEJB doesn't even 
have a dependency on Yoko.
I would hope this is not true.  ORB.init() returns the singleton ORB 
instance, which is only guaranteed to be functional for creating Any and 
TypeCode instances. 


Rick



-dain

On Jul 20, 2007, at 8:09 AM, David Jencks wrote:

The yoko stuff is in the connector-deployer defaultEnvironment so we 
can construct working jndi references so you can look up 
java:comp/ORB and IIRC it's in the ejb stuff for a similar reason. So 
if you don't need an automatic resource-ref to java:comp/ORB or 
anything similar I think you can override the defaultEnvironments in 
config.xml for these two builders.


I think that in geronimo 1.2 we were able to more easily run without 
an orb but with the annotation stuff and various automatic jndi 
references to orbs it has become more difficult.  I doubt we'll get 
to it by 2.0 but you might file a JIRA tracking the problems you've 
run into here.


thanks
david jencks

On Jul 20, 2007, at 1:42 AM, Andersch, Jens (DWBI) wrote:


Thank you for your help,

That seems to work. I only replaced the yoko jars within the 
endorsed dir by the jacorb jars and made the following changes 
within config.xml:


module name=org.apache.geronimo.configs/j2ee-corba-yoko/2.0-M6/car

gbean load=false name=NameServer

…

/gbean

gbean load=false name=Server

…

/gbean

gbean load=false name=UnprotectedServer

…

/gbean

/module



I am not really happy with this solution because I am not sure if I 
will get any side effects in the future.


What should I do with the connector-deployer module which also 
depends on yoko classes ? If I delete yoko from the


repository subdir I get a lot of exceptions because of the 
dependencies in the connector-deployer module.


Moreover the openejb classes throw exceptions if they can’t find the 
yoko jars in the repository.


So I have to keep them.



module 
name=org.apache.geronimo.configs/connector-deployer/2.0-M6/car


gbean name=ResourceRefBuilder

attribute 
name=eeNamespaceshttp://java.sun.com/xml/ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute 



attribute name=defaultEnvironment

environment 
xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2; 
dependencies 
dependency 
groupIdorg.apache.geronimo.configs/groupId 
artifactIdj2ee-corba-yoko/artifactId 
typecar/type 
/dependency /dependencies 
/environment


/attribute

/gbean

gbean name=AdminObjectRefBuilder

attribute 
name=eeNamespaceshttp://java.sun.com/xml/ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute 



/gbean

gbean name=ClientResourceRefBuilder

attribute 
name=eeNamespaceshttp://java.sun.com/xml/ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute 



attribute name=defaultEnvironment

environment 
xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2; 
dependencies 
dependency 
groupIdorg.apache.geronimo.configs/groupId 
artifactIdclient-corba-yoko/artifactId 
typecar/type 
/dependency /dependencies 
/environment


/attribute

/gbean

/module



Jens



Von: David Jencks [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 18. Juli 2007 20:36
An: user@geronimo.apache.org
Betreff: Re: Using JacORB not possible within Geronimo?



We havent' tried this, and you probably won't be able to use the 
corba ejb transport




I would start by moving to the almost released geronimo 1.2 or also 
close to release 2.0 since they are set up to use a non-jdk orb, 
namely yoko.  I think it will be easier to switch which non-jdk orb 
you use than switch from jdk orb to non-jdk orb.




You should then remove the yoko corba spec jars from lib/endorsed 
and the yoko jars from the geronimo repository and comment out stuff 
in config.xml until geronimo starts :-)




Now put the jacORB spec jar(s) in lib/endorsed and try your app.



Hope this helps

david jencks





On Jul 17, 2007, at 11:46 PM, Andersch, Jens (DWBI) wrote:




Hi All,



does anyone know, if it is possible to deploy an own ear which 
contains a connector rar that uses JacORB instead of the ORB 
Implementation used by Geronimo 1.1.1 itself.


I have the problem that the class loader loads the org.omg classes 
from 

Re: AW: Using JacORB not possible within Geronimo?

2007-07-23 Thread Dain Sundstrom

On Jul 23, 2007, at 10:51 AM, Rick McGuire wrote:


Dain Sundstrom wrote:
The actual code we use to create the orb bound to java:comp/ORB is  
simply ORB orb = ORB.init(); so it should what with what ever  
you have configured as the default ORB in your VM.  OpenEJB  
doesn't even have a dependency on Yoko.
I would hope this is not true.  ORB.init() returns the singleton  
ORB instance, which is only guaranteed to be functional for  
creating Any and TypeCode instances.


It is true, and that is all the default orb bound into jndi is good  
for per spec.  Any thing beyond that is a vendor specific feature.


-dain


AW: Using JacORB not possible within Geronimo?

2007-07-20 Thread Andersch, Jens (DWBI)

Thank you for your help,

That seems to work. I only replaced the yoko jars within the endorsed
dir by the jacorb jars and made the following changes within config.xml:

module name=org.apache.geronimo.configs/j2ee-corba-yoko/2.0-M6/car

gbean load=false name=NameServer

...

/gbean

gbean load=false name=Server

...

/gbean

gbean load=false name=UnprotectedServer

...

/gbean

/module

 

I am not really happy with this solution because I am not sure if I will
get any side effects in the future.

What should I do with the connector-deployer module which also depends
on yoko classes ? If I delete yoko from the 

repository subdir I get a lot of exceptions because of the dependencies
in the connector-deployer module. 

Moreover the openejb classes throw exceptions if they can't find the
yoko jars in the repository. 

So I have to keep them.

 

module
name=org.apache.geronimo.configs/connector-deployer/2.0-M6/car

gbean name=ResourceRefBuilder

attribute
name=eeNamespaceshttp://java.sun.com/xml/ns/j2ee,http://java.sun.com/
xml/ns/javaee/attribute

attribute name=defaultEnvironment

environment
xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;
dependencies dependency
groupIdorg.apache.geronimo.configs/groupId
artifactIdj2ee-corba-yoko/artifactId
typecar/type /dependency
/dependencies /environment

/attribute

/gbean

gbean name=AdminObjectRefBuilder

attribute
name=eeNamespaceshttp://java.sun.com/xml/ns/j2ee,http://java.sun.com/
xml/ns/javaee/attribute

/gbean

gbean name=ClientResourceRefBuilder

attribute
name=eeNamespaceshttp://java.sun.com/xml/ns/j2ee,http://java.sun.com/
xml/ns/javaee/attribute

attribute name=defaultEnvironment

environment
xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;
dependencies dependency
groupIdorg.apache.geronimo.configs/groupId
artifactIdclient-corba-yoko/artifactId
typecar/type /dependency
/dependencies /environment

/attribute

/gbean

/module

 

Jens

 



Von: David Jencks [mailto:[EMAIL PROTECTED] 
Gesendet: Mittwoch, 18. Juli 2007 20:36
An: user@geronimo.apache.org
Betreff: Re: Using JacORB not possible within Geronimo?

 

We havent' tried this, and you probably won't be able to use the corba
ejb transport

 

I would start by moving to the almost released geronimo 1.2 or also
close to release 2.0 since they are set up to use a non-jdk orb, namely
yoko.  I think it will be easier to switch which non-jdk orb you use
than switch from jdk orb to non-jdk orb.

 

You should then remove the yoko corba spec jars from lib/endorsed and
the yoko jars from the geronimo repository and comment out stuff in
config.xml until geronimo starts :-)  

 

Now put the jacORB spec jar(s) in lib/endorsed and try your app.

 

Hope this helps

david jencks

 

 

On Jul 17, 2007, at 11:46 PM, Andersch, Jens (DWBI) wrote:





Hi All,

 

does anyone know, if it is possible to deploy an own ear which contains
a connector rar that uses JacORB instead of the ORB Implementation used
by Geronimo 1.1.1 itself.

I have the problem that the class loader loads the org.omg classes from
.../repository/geronimo-spec/geronimo-spec-corba/1.0/geronimo-spec-corba
-1.0.jar and my jacorb classes from the jar included in the rar.

Unfortunately some org.omg classes do not have the same versions as the
org.omg classes within the jarcorb.jar and I get
java.lang.NoSuchFieldErrors.

I also tried inverse-classloading but then I get a
java.lang.VerifyError.

 

Does my own Application really have to use the Geronimo ORB?

 

Jens

 

 



The information contained in, or attached to, this e-mail, may contain
confidential information and is intended solely for the use of the
individual or entity to whom they are addressed and may be subject to
legal privilege. If you have received this e-mail in error you should
notify the sender immediately by reply e-mail, delete the message from
your system and notify your system manager. Please do not copy it for
any purpose, or disclose its contents to any other person. The views or
opinions presented in this e-mail are solely those of the author and do
not necessarily represent those of the company. The recipient should
check this e-mail and any attachments for the presence of viruses. The
company accepts no liability for any damage caused, directly or
indirectly, by any virus transmitted in this email.






 


__
This email has been scanned by the MessageLabs Email Security System.
For more