geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: AW: Using JacORB not possible within Geronimo?
Date Mon, 23 Jul 2007 17:51:05 GMT
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="eeNamespaces">http://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>                             
>>> <groupId>org.apache.geronimo.configs</groupId>                  
          
>>> <artifactId>j2ee-corba-yoko</artifactId>                        
    
>>> <type>car</type>                         
>>> </dependency>                     </dependencies>               
 
>>> </environment>
>>>
>>>             </attribute>
>>>
>>>         </gbean>
>>>
>>>         <gbean name="AdminObjectRefBuilder">
>>>
>>>             <attribute 
>>> name="eeNamespaces">http://java.sun.com/xml/ns/j2ee,http://java.sun.com/xml/ns/javaee</attribute>

>>>
>>>
>>>         </gbean>
>>>
>>>         <gbean name="ClientResourceRefBuilder">
>>>
>>>             <attribute 
>>> name="eeNamespaces">http://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>                             
>>> <groupId>org.apache.geronimo.configs</groupId>                  
          
>>> <artifactId>client-corba-yoko</artifactId>                      
      
>>> <type>car</type>                         
>>> </dependency>                     </dependencies>               
 
>>> </environment>
>>>
>>>             </attribute>
>>>
>>>         </gbean>
>>>
>>> </module>
>>>
>>>
>>>
>>> Jens
>>>
>>>
>>>
>>> Von: David Jencks [mailto:david_jencks@yahoo.com]
>>> 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 information please visit http://www.messagelabs.com/email
>>> ______________________________________________________________________
>>>
>>>
>>> ************************************************
>>> 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.
>>> ************************************************
>>>
>>
>
>


Mime
View raw message