[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Help with static weaving on OC4J seeing ._toplink_setmyColumn
|
Just an update here, the method with the toplink weaving false worked
for a while. However, once two applications were deployed they didn't
play nice with each other. What we ended up implementing was renaming
the persistence.xml file on deploy to OC4J. This way OC4J never sees
it and doesn't try to manage it, it's all managed by spring.
We just uncomment this line in our spring entityManagerFactory bean
automatically via ant on deploy:
<!--<property name="persistenceXmlLocation"
value="classpath:META-INF/persistence-renamedforprod.xml"/> -->
I plan on writing a full blog post at some point about using spring
with eclipselink and oc4j. The bottom line is, if you static weave and
hide your persistence.xml from OC4J it works great :)
./tch
On Thu, Jul 8, 2010 at 1:17 PM, Tim Hollosy <hollosyt@xxxxxxxxx> wrote:
> Thank you so much everyone. Sorry to have to be annoying on the list,
> but you know. Squeaky wheel gets the grease. :)
>
> So I ended up using the hack of setting toplink.weaving to false, also
> for some reason I had to add eclipselink and persistence.jar to the
> applib directory, which I can live with.
>
> I think the other solution of renaming a persistence unit would work
> as well and may be cleaner. I don't know what the ramifications of a
> frankenstein persistence unit would be so that may be safer as well.
> I'll report back if I try again.
>
> Thanks again, if I run into any of you at a eclipsecon or something I
> owe you a beer!
>
> ./tch
>
>
>
> On Thu, Jul 8, 2010 at 11:39 AM, Christopher Delahunt
> <christopher.delahunt@xxxxxxxxxx> wrote:
>> Problem seems to be a Spring interaction with Java EE 5 server JPA
>> capabilities, so you may get additional problems - the server will try to
>> inject @PersistenceContext with what it finds in the persistence.xml. The
>> problem is described in post:
>> http://forum.springsource.org/showthread.php?t=67429
>> with a slightly different issue- the container EM doesn't have the
>> datasource info that Spring would configure, and so fails to load. The post
>> mentions that Spring has a note on it ( couldn't find the reference directly
>> myself) :
>> "Note that this option may conflict with the built-in JPA capabilities of a
>> Java EE 5 server. So when running in a full Java EE 5 environment, consider
>> obtaining your EntityManagerFactory from JNDI. Alternatively, specify a
>> custom "persistenceXmlLocation" on your
>> LocalContainerEntityManagerFactoryBean definition, e.g.
>> "META-INF/my-persistence.xml", and only include a descriptor with that name
>> in your application jar files. Since the Java EE 5 server will only look for
>> default META-INF/persistence.xml files, it will ignore such custom
>> persistence units and hence avoid conflicts with a Spring-driven JPA setup
>> upfront. "
>>
>> Other posts seem to imply you can get Spring to look up the
>> EntityManagerFactory from JNDI, so presumably it would use the EMF from the
>> container rather than create it. Unfortunately, I am not familiar with
>> Spring myself so I cannot comment on specifics.
>>
>> Hope this helps,
>> Chris
>>
>> On 08/07/2010 11:26 AM, Tim Hollosy wrote:
>>
>> Alright, let's get down to it.
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <persistence version="1.0"
>> xmlns="http://java.sun.com/xml/ns/persistence";
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
>> http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd";>
>> <persistence-unit name="CSHCSModel" transaction-type="RESOURCE_LOCAL">
>> ....omitting entities
>> <!--
>> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>-->
>> <properties>
>> <property name="eclipselink.jdbc.bind-parameters" value="true" />
>> <property name="eclipselink.logging.level" value="FINEST"/>
>> <property name="eclipselink.jdbc.batch-writing" value="JDBC"/>
>> <property name="eclipselink.cache.shared.default" value="false"/>
>> <property name="eclipselink.weaving.fetchgroups" value="false" />
>> <property name="eclipselink.target-server" value="OC4J" />
>> <property name="eclipselink.weaving.changetracking" value="false" />
>> <property name="eclipselink.weaving" value="static" />
>> <property name="eclipselink.weaving.lazy" value="true"/>
>> <property name="eclipselink.logging.logger"
>> value="org.eclipse.persistence.logging.CommonsLoggingSessionLog"/>
>>
>>
>> </properties>
>>
>> </persistence-unit>
>> </persistence>
>>
>>
>> So, I'm statically weaving as part of my build process in eclipse --
>> if I don't do this spring freaks out anyway, so I don't mind doing
>> this.
>>
>> I'm getting my EM from spring with @PersistenceContext, here's the
>> relevant spring stuff.
>>
>> <bean id="jpaAdapter"
>> class="org.springframework.orm.jpa.vendor.EclipseLinkJpaVendorAdapter">
>> <property name="databasePlatform"
>> value="org.eclipse.persistence.platform.database.oracle.OraclePlatform"
>> />
>> <property name="showSql" value="true" />
>> </bean>
>>
>> <context:load-time-weaver />
>> <!-- <context:load-time-weaver
>> weaver-class="org.springframework.instrument.classloading.oc4j.OC4JLoadTimeWeaver"
>> />-->
>>
>> <bean id="entityManagerFactory"
>> class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
>> <property name="persistenceUnitName" value="CSHCSModel" />
>> <property name="dataSource" ref="dataSource" />
>> <property name="jpaVendorAdapter" ref="jpaAdapter" />
>> <!-- <property name="loadTimeWeaver" ref="loadTimeWeaver"/> -->
>> </bean>
>>
>> I've tried with and without enabling the loadTimeWeaver, it doesn't
>> seem to make a difference.
>>
>> Classloader stack, all of this closing/destroying happens during
>> predeployment.
>>
>> 10/07/08 10:16:27 ClassLoader closing: myapp.root:0.0.0 (ID #1f23303)
>> at
>> oracle.classloader.util.ClassLoadTracing$LoaderListener.loaderClosing(ClassLoadTracing.java:821)
>> at
>> oracle.classloader.EventDispatcher.loaderClosing(EventDispatcher.java:238)
>> at
>> oracle.classloader.PolicyClassLoader.close(PolicyClassLoader.java:1109)
>> at
>> oracle.classloader.PolicyClassLoader.close(PolicyClassLoader.java:1069)
>> at
>> com.evermind.server.ApplicationStateRunning.destroyClassLoaders(ApplicationStateRunning.java:1201)
>> at com.evermind.server.Application.stateCleanUp(Application.java:3766)
>> at com.evermind.server.Application.destroy(Application.java:802)
>> at
>> com.evermind.server.ApplicationServer.uninstall(ApplicationServer.java:2890)
>> at
>> com.evermind.server.ApplicationServer.uninstall(ApplicationServer.java:2832)
>> at
>> oracle.oc4j.admin.internal.ApplicationUnDeployer.doUndeploy(ApplicationUnDeployer.java:161)
>> at
>> oracle.oc4j.admin.internal.UnDeployerBase.execute(UnDeployerBase.java:94)
>> at
>> oracle.oc4j.admin.internal.UnDeployerBase.execute(UnDeployerBase.java:73)
>> at
>> oracle.oc4j.admin.internal.ApplicationDeployer.undo(ApplicationDeployer.java:384)
>> at
>> oracle.oc4j.admin.internal.DeployerBase.execute(DeployerBase.java:132)
>> at
>> oracle.oc4j.admin.jmx.server.mbeans.deploy.OC4JDeployerRunnable.doRun(OC4JDeployerRunnable.java:52)
>> at
>> oracle.oc4j.admin.jmx.server.mbeans.deploy.DeployerRunnable.run(DeployerRunnable.java:81)
>> at
>> com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:298)
>> at java.lang.Thread.run(Thread.java:595)
>>
>> 10/07/08 10:16:27 ClassLoader closing: myapp.web.CSHCS:0.0.0 (ID #1f64d29)
>> at
>> oracle.classloader.util.ClassLoadTracing$LoaderListener.loaderClosing(ClassLoadTracing.java:821)
>> at
>> oracle.classloader.EventDispatcher.loaderClosing(EventDispatcher.java:238)
>> at
>> oracle.classloader.PolicyClassLoader.close(PolicyClassLoader.java:1109)
>> at
>> oracle.classloader.PolicyClassLoader.close(PolicyClassLoader.java:1126)
>> at
>> oracle.classloader.PolicyClassLoader.close(PolicyClassLoader.java:1069)
>> at
>> com.evermind.server.ApplicationStateRunning.destroyClassLoaders(ApplicationStateRunning.java:1201)
>> at com.evermind.server.Application.stateCleanUp(Application.java:3766)
>> at com.evermind.server.Application.destroy(Application.java:802)
>> at
>> com.evermind.server.ApplicationServer.uninstall(ApplicationServer.java:2890)
>> at
>> com.evermind.server.ApplicationServer.uninstall(ApplicationServer.java:2832)
>> at
>> oracle.oc4j.admin.internal.ApplicationUnDeployer.doUndeploy(ApplicationUnDeployer.java:161)
>> at
>> oracle.oc4j.admin.internal.UnDeployerBase.execute(UnDeployerBase.java:94)
>> at
>> oracle.oc4j.admin.internal.UnDeployerBase.execute(UnDeployerBase.java:73)
>> at
>> oracle.oc4j.admin.internal.ApplicationDeployer.undo(ApplicationDeployer.java:384)
>> at
>> oracle.oc4j.admin.internal.DeployerBase.execute(DeployerBase.java:132)
>> at
>> oracle.oc4j.admin.jmx.server.mbeans.deploy.OC4JDeployerRunnable.doRun(OC4JDeployerRunnable.java:52)
>> at
>> oracle.oc4j.admin.jmx.server.mbeans.deploy.DeployerRunnable.run(DeployerRunnable.java:81)
>> at
>> com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:298)
>> at java.lang.Thread.run(Thread.java:595)
>>
>> I'll try your idea of tricking toplink into not weaving right now. I
>> think i'm just suffering from ignorance on the whole container vs app
>> managed persistence unit stuff.
>>
>> Thanks a ton, I'm trying to get eclipselink out there and used in big
>> organizations, but if I can't get it rolling on their software it's
>> going to be a tough sell :)
>>
>> ./tch
>>
>>
>>
>> On Thu, Jul 8, 2010 at 11:17 AM, Christopher Delahunt
>> <christopher.delahunt@xxxxxxxxxx> wrote:
>>
>>
>> Hello Tim,
>>
>> What does your persistence.xml look like? What seems to be happening is the
>> container also tries to deploy the EntityManager rather than just Spring -
>> are you using a JTA em or accessing the the EntityManager from the container
>> directly (vs from Spring classes/injection or resource_local transaction
>> type).
>>
>> It 'should' work if you specify EclipseLink as the provider, as the agent
>> will weave classes correctly, and these classes will be used by Spring, but
>> I suspect something with the configuration or application is causing the
>> Container managed EM to be used/loaded instead of just the Spring manged
>> one. Can you send the classloader exception stack that you mentioned? What
>> could work around the issue is to add the TopLink Essentials property to not
>> use weaving (using the toplink.weaving property with a value of false), and
>> the EclipseLink one to use Static weaving, and leave the provider blank.
>> This will allow the Container manged EM (vie TopLink Essentials) to deploy
>> without the classloader closed exception, but not have it look for the
>> _toplink_methods or weave them into the Entities getters/setters. Your
>> get/set methods will already have been woven with the _eclipseLink_methods
>> used for lazy loading etc if you have run the static weavers, so the Spring
>> em should function correctly.
>>
>> Best Regards,
>> Chris
>>
>>
>>
>> On 08/07/2010 10:51 AM, Tim Hollosy wrote:
>>
>> Still banging my head on this, I might just have to see about dumping
>> OC4J, because it's just getting ridiculous.
>>
>> Final symptoms:
>> If i define eclipselink as my persistence provider, oc4j predeploys
>> the persistence unit and then when Spring tries to initialize it, the
>> classloader for my app is already closed.
>>
>> If I don't tell oc4j my persistence provider in persistence.xml then
>> it uses toplink essentials in the background, even though spring is
>> using the eclipselink adapater. This seems to completely not matter at
>> all until I try to access a statically weaved method which must at
>> that point hand off stuff to the container, because the container now
>> wants to call the toplink weaved getters and setters.
>>
>> Can anyone think of a work around here, or post a working config set
>> for a oc4j/spring/eclipselink project. I mean, it's not that far off
>> to want to use the oracle ejb 3 container + an oracle product with
>> spring!
>>
>> ./tch
>>
>>
>>
>> On Tue, Jul 6, 2010 at 3:10 PM, Tim Hollosy <hollosyt@xxxxxxxxx> wrote:
>>
>>
>> Thanks James.
>> I'm not sure how I would even go about removing spring, since the app
>> uses spring for _everything_.
>>
>> I am using the static weaving ant task, and when I left the provider
>> off I get a stack trace when doing field accessing on a lazy field.
>> The trace is this:
>>
>> So, it looks like it's like an odd mix of toplink weaved methods on my
>> eclipslink weaved class. If I try to set the persistence provider to
>> eclipselink I get the ClassLoader issues the first time I try to
>> access the app.
>>
>>
>>
>> java.lang.NoSuchMethodError:
>> com.redacted.Enrollment._toplink_setclientRec(Lcom/redacted/Client;)V
>> at com.redacted.Enrollment._persistence_set(Enrollment.java)
>> at
>> org.eclipse.persistence.internal.descriptors.PersistenceObjectAttributeAccessor.setAttributeValueInObject(PersistenceObjectAttributeAccessor.java:46)
>> at
>> org.eclipse.persistence.mappings.DatabaseMapping.setAttributeValueInObject(DatabaseMapping.java:1367)
>> at
>> org.eclipse.persistence.mappings.ForeignReferenceMapping.buildCloneFromRow(ForeignReferenceMapping.java:198)
>> at
>> org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildAttributesIntoWorkingCopyClone(ObjectBuilder.java:1260)
>> at
>> org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildWorkingCopyCloneFromRow(ObjectBuilder.java:1381)
>> at
>> org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObjectInUnitOfWork(ObjectBuilder.java:547)
>>
>>
>> ./tch
>>
>>
>>
>> On Tue, Jul 6, 2010 at 2:55 PM, James Sutherland <jamesssss@xxxxxxxxx>
>> wrote:
>>
>>
>> I think the reason you get EclipseLink even when to setting the provider in
>> OC4J is that you have set EclipseLink in your Spring config file, so Spring
>> is ensuring that EclipseLink is being used.
>>
>> I think your class loader issue may be a conflict between using Spring
>> inside OC4J where both have their own class loaders.
>>
>> You should use the static weaving ant task, and set weaving to static.
>>
>> You may want to try deploying to OC4J without Spring, to see if you issues
>> are Spring related.
>>
>>
>>
>> tch wrote:
>>
>>
>> I'm probably talking to myself here, but here's what I've determined
>> so far today.
>>
>> I disabled static weaving in my persistence.xml and deployed in two
>> different ways.
>>
>> Once, while leaving my persistence provider blank.
>>
>> When the application deployed I see al the EL Config weaving
>> messages,etc. So I know that my app IS using Eclipselink, even though
>> I did not define a persistence provider. When I start up the app and
>> try to make my first DB connection spring starts up EL again and
>> everything works great.
>>
>> Now, I edit the persistence.xml to specify EL as the persistence
>> provider and restart the server. I get all the same EL Config messages
>> as the server starts up. When I try to access the app this time, I get
>> the ClassLoader error about the ClassLoader for my app already being
>> closed.
>>
>> I inspect both ClassLoader log outputs, both times indeed the
>> ClassLoader for my app is closed after predeployment of the
>> persistence unit. However, there must be something special happening
>> when I define the persistence provider, because only then do I get the
>> class loader errors. Of course my end game here is to use Lazy Loading
>> so I would think it should be possible to statically weave a spring
>> app on oc4j with eclipselink.
>>
>>
>> Once again any ideas on debugging this would be much appreciated.
>>
>> Some relevant spring EL config stuff:
>>
>> <bean id="jpaAdapter"
>>
>> class="org.springframework.orm.jpa.vendor.EclipseLinkJpaVendorAdapter">
>> <property name="databasePlatform"
>>
>> value="org.eclipse.persistence.platform.database.oracle.OraclePlatform"
>> />
>> <property name="showSql" value="true" />
>> </bean>
>>
>> <bean id="entityManagerFactory"
>>
>> class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
>> <property name="persistenceUnitName" value="CSHCSModel" />
>> <property name="dataSource" ref="dataSource" />
>> <property name="jpaVendorAdapter" ref="jpaAdapter" />
>> </bean>
>>
>> ./tch
>>
>>
>>
>> On Sat, Jul 3, 2010 at 1:54 PM, Tim Hollosy <hollosyt@xxxxxxxxx> wrote:
>>
>>
>> This has been bothering me all weekend, I just don't understand enough
>> about the guts of this EJB 3 stuff.
>>
>> So, some background. In the past I had a spring application deployed
>> to OC4J with eclipselink 1.x, I didn't specify a provider so I just
>> kind of assumed when I deployed it was using eclipselink as the
>> provider since my DAO's all referenced the Eclipselink packages for
>> query classes, etc. Now, I'm not sure if I used any weaving or not,
>> though I think I do in that app. So what code base is really
>> executing? Toplink essentials since I don't tell the container who the
>> provider is, even though I reference all the EL packages in my code?
>>
>> So, anyway. I was having some issues with spring and EL 1, with
>> weaving. It just didn't want to work sometimes. So I decided on this
>> next app to move on to EL 2 and just statically weave. In my dev
>> container (jetty) everything is working great. The first deploy to
>> OC4J works fine as well. Though, in this first deploy I'm not using
>> any weaving features. My next deploy I actually attempt to use lazy
>> loading, etc. This time it fails, with my original error message. I
>> tried removing the el jar's out of my WEB-INF/lib and adding them as a
>> shared lib, and I get all these classloader issues I detailed later in
>> the thread. Which I can only think has something do with Spring,
>> though it's over my head.
>>
>> Is what you're saying though that I could try to weave my jar with the
>> toplink essentials weaver and my code would work in OC4J? Which code
>> base would be used though? I use some JPA 2 features in my new
>> project, would that even work. I wouldn't have to reference toplink
>> essentials packages in my DAO's etc?
>>
>> Thanks for your help, I'm really trying to understand the guts of how
>> this actually works
>>
>>
>> ./tch
>>
>>
>>
>>
>>
>>
>> -----
>> http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
>> http://www.eclipse.org/eclipselink/
>> EclipseLink , http://www.oracle.com/technology/products/ias/toplink/
>> TopLink
>> Wiki: http://wiki.eclipse.org/EclipseLink EclipseLink ,
>> http://wiki.oracle.com/page/TopLink TopLink
>> Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
>> http://www.nabble.com/EclipseLink-f26430.html EclipseLink
>> Book: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
>> --
>> View this message in context:
>> http://old.nabble.com/Help-with-static-weaving-on-OC4J-seeing-._toplink_setmyColumn-tp29058272p29086725.html
>> Sent from the EclipseLink - Users mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>
>>
>>
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>
>>
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>
>>
>>
>>
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>
>>
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>
>>
>
