Hi Patrick,

you are correct we are using SimpleLoadTimeWeaver,as because other
OpenJpaLoadTimeWeaver enhances for every request call which is disadvantage.
Let us know your view point.
 


Patrick Linskey-2 wrote:
> 
> Hi,
> 
> I think that TemporaryClassLoader is probably the only place that
> would need to be modified.
> 
> However, I'm surprised to see the TemporaryClassLoader in use at that
> time. It looks like that stack trace is for runtime behavior; the
> TemporaryClassLoader should only be used when loading metadata or
> running the enhancer, neither of which seems to be happening.
> 
> What does your Spring configuration look like? Are you using the
> SimpleLoadTimeWeaver by any chance?
> 
> -Patrick
> 
> On Dec 31, 2007 5:18 AM, Sai <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> We are using Jprobe 7.0 for code coverage testing for our web service
>> application.
>> We used OpenJPA-0.9.6 orm technology in our application.The envirornment
>> details like
>> OS-Windows XP
>> JDK- 1.5.0_02
>> Application server- Apache Geronimo 1.1.1
>> JPROBE version-7.0
>> Our application works fine when we don't use Jprobe.
>>
>> But when we run appserver with Jprobe and when the first test executes we
>> get the error as attahce serverLog file.
>> http://www.nabble.com/file/p14557478/serverLog.txt serverLog.txt
>>
>> As per the referance from(quest team support) here is the feedback
>> -----------------------------------
>> It looks like you're using JProbe in conjuction with Open JPA. The
>> problem
>> is that the JPA classloader doesn't follow the standard delegation model.
>> There is no easy workaround for this, but since Open JPA is open source
>> you
>> could try fixing it, and / or reporting to the Open JPA people that a way
>> to
>> configure the exclusions would be good; right now it appears to be
>> hard-coded to only delegate for java.*, javax.* and sun.*. Open JPA will
>> probably run into some issues with other JVMs since JVMs from e.g. IBM
>> and
>> BEA have "internal" classes outside that namespace.
>>
>> The problematic classloader we found is
>> org.apache.openjpa.lib.util.TemporaryClassLoader, which in the version
>> 0.9.6
>> source has loadClass() method with a line in it like:
>>
>>         if (name.startsWith("java.") || name.startsWith("javax.")
>>             || name.startsWith("sun."))
>>             return Class.forName(name, resolve,
>> getClass().getClassLoader());
>>
>> Ideally, this would check a configurable list, but for a quick fix, you
>> could change it to:
>>
>>         if (name.startsWith("java.") || name.startsWith("javax.")
>>             || name.startsWith("sun.")
>>             || name.startsWith("com.jprobe."))
>>             return Class.forName(name, resolve,
>> getClass().getClassLoader());
>>
>> There might be other ClassLoader implementations in Open JPA with the
>> same
>> behaviour that would also need fixing, but we only found this one.
>>
>> ps. feel free to pass this information to the Open JPA developers.
>> -------------------------------
>> we want to know what are all the places we need to change in order to use
>> Jprobe or do you see any workaround for this.
>>
>> Lookforward to your reply asap
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/OpenJPA---Jprobe-usage-issue%28class-loading%29-tp14557478p14557478.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>>
> 
> 
> 
> -- 
> Patrick Linskey
> 202 669 5907
> 
> 

-- 
View this message in context: 
http://www.nabble.com/OpenJPA---Jprobe-usage-issue%28class-loading%29-tp14557478p14594324.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Reply via email to