Skip to main content

[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

Still stuck on this, is there anyone successfully using spring +
static weaving + oc4j on the list that I could swap config files with?

./tch



On Mon, Jul 5, 2010 at 10:53 AM, Tim Hollosy <hollosyt@xxxxxxxxx> 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
>>
>>
>>
>> On Fri, Jul 2, 2010 at 3:25 PM, Christopher Delahunt
>> <christopher.delahunt@xxxxxxxxxx> wrote:
>>> I'm not sure your options are correct.
>>> The problem you are encountering is that you have specified that the jar
>>> uses static weaving, but it has not been statically woven for TopLink
>>> Essentials.  So the options are:
>>> 1) Use EclipseLink, but you will need to add the EclipseLink.jar as a shared
>>> library or add it to the Ear, and change the persistence.xml so that it
>>> references it as the provider via the
>>>   <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider> tag.
>>> With this, you can then use dynamic weaving or static weaving (be sure your
>>> jar is statically woven though)
>>> 2) Use TopLink Essentials.  Either change the persistence.xml so that it
>>> uses dynamic weaving, or statically weave your jar.
>>>
>>> There is a demo showing EclipseLink being used in OC4J at:
>>> http://wiki.eclipse.org/EclipseLink/Examples/JPA/OC4J_Web_Tutorial
>>>
>>> Best Regards,
>>> Chris
>>>
>>> On 02/07/2010 2:08 PM, Tim Hollosy wrote:
>>>
>>> Ah, I think that's the issue. I was never actually _using_ static
>>> weaving in the past. So when I was deploying since I had
>>> eclipselink.jar in my WEB-INF/lib directory. Eclipselink was still
>>> used, but now that eclipselink needs to use the weaved classes that
>>> must happen at some deeper level.  So OC4J is trying to use toplink
>>> essentials instead.
>>>
>>> So my options are:
>>> -Don't weave (bad because all this eager fetching will kill me).
>>> -Replace toplink with eclipselink on the server (bad because i have to
>>> convince sysadmins to change something!)
>>>
>>>
>>> ./tch
>>>
>>>
>>>
>>> On Fri, Jul 2, 2010 at 1:18 PM, Christopher Delahunt
>>> <christopher.delahunt@xxxxxxxxxx> wrote:
>>>
>>>
>>> Hello,
>>>
>>> If it is looking for a _toplink_methodName, then it is using TopLink
>>> Essentials as the persistence provider rather than EclipseLink.  Have you
>>> specified the provider name in your persistence.xml or are you relying on
>>> the default?
>>> TopLink Essentials was the default JPA provider in 10g OC4J releases.
>>> Best Regards,
>>> Chris
>>>
>>> On 02/07/2010 12:48 PM, Tim Hollosy wrote:
>>>
>>>
>>> I have some statically weaved classes that are having issues when
>>> deployed to my OC4J server. It's working fine in Jetty.
>>>
>>> I'm seeing errors like: java.lang.NoSuchMethoderror:
>>> com.my.entity.Entity._toplink_setmyColumn
>>>
>>> The only thing I've changed was using lazy fetching, I could use some
>>> help from the oracle guys debugging. My first thought is that I have a
>>> bad library on the system and it's trying to use some toplink stuff
>>> instead of the correct eclipselink.jar in my WEB-INF/lib. I'm using
>>> OC4J 10.1.3.3 and Eclipselink 2.
>>>
>>> I have the eclipselink.weaving property set to static.
>>>
>>> Any direction on how to debug this would be helpful.
>>>
>>> Thanks
>>>
>>> ./tch
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>


Back to the top