Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <20050127223444.GA29826@caboteria.org>
References: <20050124215635.GA16361@caboteria.org>
 <20050127155151.GA17082@caboteria.org>
 <A2153EFA-7092-11D9-A4A9-000D93361CAA@yahoo.com>
 <20050127223444.GA29826@caboteria.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0E232805-70B6-11D9-A4A9-000D93361CAA@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: problem with axis/xerces and web apps
Date: Thu, 27 Jan 2005 14:52:00 -0800
To: dev@geronimo.apache.org


On Jan 27, 2005, at 2:34 PM, toby cabot wrote:

> Thanks David.
>
> On Thu, Jan 27, 2005 at 10:38:27AM -0800, David Jencks wrote:
>> Are you using a geronimo plan with
>> <context-priority-classloader>true</context-priority-classloader>
>> for your web app?
>
> I wasusing a value of "false" before, but I tried "true" and as you
> expected it caused other problems, specifically:
>
> org.apache.commons.discovery.DiscoveryException: Class  
> org.apache.geronimo.kernel.log.GeronimoLogFactory does not implement  
> org.apache.commons.logging.LogFactory
>         at  
> org.apache.commons.discovery.tools.ClassUtils.verifyAncestory(ClassUtil 
> s.java:134)
>         at  
> org.apache.commons.discovery.tools.SPInterface.verifyAncestory(SPInterf 
> ace.java:155)
>         at  
> org.apache.commons.discovery.tools.SPInterface.newInstance(SPInterface. 
> java:149)
>         at  
> org.apache.commons.discovery.tools.DiscoverClass.newInstance(DiscoverCl 
> ass.java:533)
>         at  
> org.apache.commons.discovery.tools.DiscoverSingleton.find(DiscoverSingl 
> eton.java:372)
>         at  
> org.apache.commons.discovery.tools.DiscoverSingleton.find(DiscoverSingl 
> eton.java:332)
>         at  
> org.apache.axis.components.logger.LogFactory$1.run(LogFactory.java:45)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at  
> org.apache.axis.components.logger.LogFactory.getLogFactory(LogFactory.j 
> ava:41)
>         at  
> org.apache.axis.components.logger.LogFactory.<clinit>(LogFactory.java: 
> 33)
>
>> I think it's likely that we added axis to geronimo between early jan
>> and now.
>>
>> If this doesn't work (I think there is a reasonable chance it will
>> cause other problems) you might need to assemble geronimo using the
>> versions of axis and xerces you need.
>>
>> What happens if you use the versions of axis and xerces that geronimo
>> uses? Are our versions out of date?  If we actually implemented j2ee
>> web services would that also solve the problem :-)?
>
> I don't think it's a version problem, the versions of the tools that
> you guys are using seem to be up-to-date.  If I include Xerces in my
> war file then Axis appears to load that one, but it crashes with the
> ClassCastException in my previous email, seemingly because of some
> code in Xerces that loads a class with one classloader and tries to
> cast it to the same class, only loaded by a different classloader.  If
> I *don't* include Xerces in my war file then Castor (which I'm also
> using) can't find some xerces class that it needs so it throws.  Don't
> remember the stack trace but I can reproduce it if it helps.
>
> How hard do you think it would be to build Geronimo without Axis?  If
> Geronimo pulls the classes from the jars in my war file then it should
> work fine, at least it used to work fine.  Alternatively, could
> Geronimo load classes from the war file lib directory in preference to
> the repository?

It would probably be easier to put castor in the geronimo repo and add  
a dependency to it in j2ee-server-plan.xml than to remove axis from  
geronimo.

However, if you want to remove axis, what you need to do is:

look in all the assembly plans and remove all the axis jars, the  
geronimo-axis and the geronimo-axis-builder jars from the dependencies.  
  (geronimo-axis has transitive dependencies to most/all the plain axis  
jars, so the geronimo-axis* jars should be the only ones you'll find).   
You also have to remove the axis-builder gbean.

I'm not entirely sure if you can just remove references to the  
axis-builder gbean from the module builders or if you have to write a  
do-nothing gbean that implements and exposes ServiceReferenceBuilder,  
and deploy a copy of it in place of the axis-builder gbean.  (if you  
give it the same name and the gbeaninfo the same type "ModuleBuilder"  
you won't have to track down the references)

If I was doing this I would be sure to get at least one gbean name  
wrong so the deployers wouldn't start :-)   So, check the console  
output for non-started gbeans and the log also.

thanks
david jencks

>
> Thanks for your help,
> Toby
>