--
Carla Mott
Sun Microsystems
carla.mott_at_sun.com
attached mail follows:
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
persistence Digest 9 Nov 2005 15:23:42 -0000 Issue 13
Topics (messages 74 through 78):
Re: One-to-Many bug
74 by: Craig L Russell
76 by: Sanjeeb Kumar Sahoo
Re: Out-of-container example?
75 by: Marina Vatkina
78 by: Michael Bouschen
EAR scope persistence jar and classpath
77 by: Sanjeeb Kumar Sahoo
Administrivia:
To subscribe to the digest, e-mail:
persistence-digest-subscribe_at_glassfish.dev.java.net
To unsubscribe from the digest, e-mail:
persistence-digest-unsubscribe_at_glassfish.dev.java.net
To post to the list, e-mail:
persistence_at_glassfish.dev.java.net
----------------------------------------------------------------------
MIME-version: 1.0
Content-type: message/rfc822
Date: Mon, 07 Nov 2005 09:39:03 -0800
From: Craig L Russell <Craig.Russell_at_Sun.COM>
Subject: Re: One-to-Many bug
To: persistence_at_glassfish.dev.java.net
Cc: Shelly.McGowan_at_Sun.COM, Kenneth Saks <Kenneth.Saks_at_Sun.COM>,
Deepa Singh <Deepa.Singh_at_Sun.COM>, Marina Vatkina <Marina.Vatkina_at_Sun.COM>,
"ejb3-toplink_ww_at_oracle.com" <ejb3-toplink_ww_at_oracle.com>
Message-id: <C0F9EA4F-2F9E-474E-9D87-DB9DE14BFEE1_at_sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII
Content-transfer-encoding: 7BIT
Hi Sahoo,
On Nov 7, 2005, at 5:32 AM, Sanjeeb Kumar Sahoo wrote:
> Hi Tom/Chris,
> I have figured out what is causing that failure. TopLink Essentials
> calls PersistenceUnitInfo.getTempClassLoader() twice:
>
> public EntityManagerFactory createContainerEntityManagerFactory
> (PersistenceUnitInfo info){
> EntityManagerSetupImpl emSetupImpl = new EntityManagerSetupImpl();
> Collection entities = buildEntityList(info, info.getTempClassLoader
> ());
> ClassFileTransformer transformer = emSetupImpl.predeploy(entities,
> info.getTempClassLoader(), info);
> ...
> }
>
> When I changed the above TopLink file to call getTempClassLoader()
> only once, that validation exception went away. Looks like the
> contract for getTempClassLoader() needs to be well defined.
>
> Our container creates a new ClassLoader for each invocation of
> getTempClassLoader. This is fine as far as the contract defined in
> the javadocs of that API:
> /**
> * Return a ClassLoader that the provider may use to temporarily
> load any
> * classes, resources, or open URLs. The scope and classpath of this
> loader
> * is exactly the same as that of the loader returned by
> * PersistenceInfo.getClassLoader. None of the classes loaded by
> this class
> * loader will be visible to application components.
> *
> * @return Temporary ClassLoader with same visibility as current loader
> */
> public ClassLoader getTempClassLoader();
>
>
> See the above javadocs is silent about what should happen for
> multiple invocations. Where as the earlier javadocs for
> InstrumentableClassLoader's copy() method used to say the following:
>
> /**
> * Create and return a temporary loader with the same visibility
> * as this loader. The temporary loader may be used to load
> * resources or any other application classes for the purposes of
> * introspecting them for annotations. The persistence provider
> * should not maintain any references to the temporary loader,
> * or any objects loaded by it.
> *
> * @return A temporary classloader with the same classpath as this
> loader
> */
> public ClassLoader copy();
>
> The earlier one at least talked about what should happen each time
> it is called.
>
> Since container is not allowed to maintain a reference to this
> class loader, I think provider should not call getTempClassLoader()
> multiple times.
Can you please explain where it says the container is not allowed to
maintain a reference? The javadoc immediately above refers to the
persistence provider, not the container.
Maybe it's mentioned somewhere else?
I agree with you that the javadoc should explicitly say what the
behavior is if the persistence provider calls getTempClassLoader
multiple times. And, if the container must return the same temp class
loader to multiple invocations, when the temp class loader is allowed
to be garbage collected. Is it at undeployment?
And shouldn't the javadoc say "the persistence provider must not
maintain any references to the temporary loader or any objects loaded
by it"?
Thanks,
Craig
>
> Thanks,
> Sahoo
>
> Markus Fuchs wrote:
>
>
>> Hi Shelly, hi Ken,
>>
>> Thanks very much for forwarding this information.
>>
>> Ken,
>>
>> I see the same behavior when running the Quicklook persistence-
>> onetomanyApp.ear:
>>
>> The class pe.ejb.ejb30.persistence.toplinksample.ejb.OrderEntity
>> is loaded twice.
>>
>> once with a ClassLoader I:
>> com.sun.enterprise.util.ConnectorClassLoader @8537
>> Parent: com.sun.enterprise.loader.EJBClassLoader @8732
>>
>> once with a ClassLoader II:
>> com.sun.enterprise.util.ConnectorClassLoader @6763
>> Parent: com.sun.enterprise.loader.EJBClassLoader @8732
>>
>> Any idea, why the same class is loader twice by different
>> ClassLoaders, each sharing the same ParentClassLoader? The
>> Quicklook test can be found appserv-tests/sqetests/ejb/ejb30/
>> persistence/onetomany in the glassfish repository.
>>
>> Thanks!
>>
>> -- markus.
>>
>>
>> Shelly (Donna) McGowan wrote:
>>
>>
>>> Markus,
>>>
>>> I'm not sure if your debugging the schema deployment problem
>>> exhibited
>>> in Deepa's quicklook test or the ManyToOne/OneToMany
>>> relationships fail
>>> to load or both, but Oracle sent this email on Friday inferring a
>>> classloader issue on the ManyToOne/OneToMany issue. Just wanted
>>> to make
>>> sure you saw this.
>>>
>>> Shelly
>>>
>>>
>>>
>>> Markus Fuchs wrote On 11/04/05 20:13,:
>>>
>>>
>>>> Hi,
>>>>
>>>> I now can reproduce the problem in my environment and should be
>>>> able to find the problem soon. But I have to leave now. I'm
>>>> planning on updating y'all Sunday.
>>>>
>>>> Have a good weekend,
>>>>
>>>> -- markus.
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> -----
>>>>
>>>> Subject:
>>>> Re: [Issue 66] New - Enterprise archives fail to load if MX1 and
>>>> 1XM relationships used in entities within persistence archive
>>>> From:
>>>> Christopher Delahunt <christopher.delahunt_at_oracle.com>
>>>> Date:
>>>> Fri, 04 Nov 2005 14:53:04 -0500
>>>> To:
>>>> persistence_at_glassfish.dev.java.net
>>>>
>>>> To:
>>>> persistence_at_glassfish.dev.java.net
>>>> CC:
>>>> Peter Krogh <peter.krogh_at_oracle.com>, Shelly.McGowan_at_Sun.COM
>>>>
>>>>
>>>> Hello Sun,
>>>>
>>>> In tracking down this bug, we have encountered a situation we
>>>> cannot explain. In our initialization code we explicitly load
>>>> all entity classes with the provided temp loader. When
>>>> processing Order, the return type on getLineItem yields a class
>>>> that was loaded by a loader that is different than the one
>>>> provided. This behavior is the root of the problem, and is
>>>> occurring since the changes on the 26th.
>>>>
>>>>
>>>> Any insight is appreciated.
>>>>
>>>>
>>>> Best Regards,
>>>> Chris
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Shelly (Donna) McGowan [mailto:Shelly.McGowan_at_Sun.COM]
>>>>> Sent: Wednesday, November 02, 2005 4:58 PM
>>>>> To: persistence_at_glassfish.dev.java.net
>>>>> Subject: Re: [Issue 66] New - Enterprise archives fail to load
>>>>> if MX1
>>>>> and 1XM relationships used in entities within persistence archive
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This issue is still occurring on the latest Glassfish builds
>>>>> (11/1).
>>>>> There is no workaround that I'm aware of that resolves the
>>>>> issue except
>>>>> to use last week's promoted build (10/26).
>>>>>
>>>>> If there is a workaround, please reply to this alias.
>>>>>
>>>>> Shelly
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> smcgowan_at_dev.java.net wrote On 10/30/05 17:01,:
>>>>>
>>>>>
>>>>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=66
>>>>>> Issue #|66
>>>>>> Summary|Enterprise archives fail to load if MX1 and 1XM relati
>>>>>> |onships used in entities within persistence archive
>>>>>> Component|glassfish
>>>>>> Version|9.0pe
>>>>>> Platform|Sun
>>>>>> OS/Version|Solaris
>>>>>> URL|
>>>>>> Status|NEW
>>>>>> Status whiteboard|
>>>>>> Keywords|
>>>>>> Resolution|
>>>>>> Issue type|DEFECT
>>>>>> Priority|P1
>>>>>> Subcomponent|entity-persistence
>>>>>> Assigned to|mvatkina
>>>>>> Reported by|smcgowan
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------- Additional comments from smcgowan_at_dev.java.net Sun Oct
>>>>>> 30 22:01:42 +0000 2005 -------
>>>>>> enterprise archives containing a persistence archive in which
>>>>>> the entities have
>>>>>> a ManyToOne or OneToMany relationship defined fail to load with a
>>>>>> ValidationException as shown below. These mapping of the
>>>>>> relationships are
>>>>>> correctly defined and have worked till recently (10/27). The
>>>>>> verifier
>>>>>> highlights the same problem.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Exception Description: The attribute [employees] in entity
>>>>>> class [class
>>>>>> com.sun.ts.tests.ejb30.persistence.query.apitests.Insurance] has
>>>>>> a mappedBy value of [insurance] which does not exist in its
>>>>>> owning entity class
>>>>>> [class com.sun.ts.tests.ejb30.persistence.query.apitests.
>>>>>> EmbeddableSuperclass, this is invalid, and your attribute
>>>>>> should reference the
>>>>>> correct subclass.
>>>>>> Local Exception Stack:
>>>>>> Exception [TOPLINK-7154] (Oracle TopLink Essentials - 10g
>>>>>> release 4 (10.1.4.0.0)
>>>>>> (Build 051026Dev)):
>>>>>> oracle.toplink.essentials.exceptions.ValidationException
>>>>>> Exception Description: The attribute [employees] in entity
>>>>>> class [class
>>>>>> com.sun.ts.tests.ejb30.persistence.query.apitests.Insurance] has
>>>>>> a mappedBy value of [insurance] which does not exist in its
>>>>>> owning entity class
>>>>>> [class com.sun.ts.tests.ejb30.persistence.query.apitests.
>>>>>> EmbeddableSuperclass, this is invalid, and your attribute
>>>>>> should reference the
>>>>>> correct subclass.
>>>>>> at
>>>>>> oracle.toplink.essentials.exceptions.ValidationException.noMapped
>>>>>> ByAttributeFound(ValidationException.java:1019)
>>>>>> at
>>>>>> oracle.toplink.essentials.internal.annotations.EJBAnnotationsProc
>>>>>> essor.getOwnerMapping(EJBAnnotationsProcessor.java:418)
>>>>>> at
>>>>>> oracle.toplink.essentials.internal.annotations.EJBAnnotationsProc
>>>>>> essor.getOwnerMappingForeignKeys(EJBAnnotationsProcessor.java:
>>>>>> 430)
>>>>>> at
>>>>>> oracle.toplink.essentials.internal.annotations.EJBAnnotationsProc
>>>>>> essor.processOneToMany(EJBAnnotationsProcessor.java:1893)
>>>>>> at
>>>>>> oracle.toplink.essentials.internal.annotations.EJBAnnotationsProc
>>>>>> essor.processRelationshipAccessor(EJBAnnotationsProcessor.java:
>>>>>> 2236)
>>>>>> at
>>>>>> oracle.toplink.essentials.internal.annotations.EJBAnnotationsProc
>>>>>> essor.processRelatedClass(EJBAnnotationsProcessor.java:2207)
>>>>>> at
>>>>>> oracle.toplink.essentials.internal.annotations.EJBAnnotationsProc
>>>>>> essor.processORAnnotations(EJBAnnotationsProcessor.java:1989)
>>>>>> at
>>>>>> oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImp
>>>>>> l.predeploy(EntityManagerSetupImpl.java:299)
>>>>>> at
>>>>>> oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.c
>>>>>> reateContainerEntityManagerFactory
>>>>>> (EntityManagerFactoryProvider.java:
>>>>>> 104)
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> ----
>>>>>> To unsubscribe, e-mail: issues-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: issues-
>>>>>> help_at_glassfish.dev.java.net
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>
>
MIME-version: 1.0
Content-type: message/rfc822
Date: Tue, 08 Nov 2005 08:21:22 +0530
From: Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
Subject: Re: One-to-Many bug
To: persistence_at_glassfish.dev.java.net
Cc: Shelly.McGowan_at_Sun.COM, Kenneth Saks <Kenneth.Saks_at_Sun.COM>,
Deepa Singh <Deepa.Singh_at_Sun.COM>, Marina Vatkina <Marina.Vatkina_at_Sun.COM>,
"ejb3-toplink_ww_at_oracle.com" <ejb3-toplink_ww_at_oracle.com>
Message-id: <437012AA.2080501_at_Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
Hi Craig,
Craig L Russell wrote:
> Hi Sahoo,
>
> On Nov 7, 2005, at 5:32 AM, Sanjeeb Kumar Sahoo wrote:
>
>> Hi Tom/Chris,
>> I have figured out what is causing that failure. TopLink Essentials
>> calls PersistenceUnitInfo.getTempClassLoader() twice:
>>
>> public EntityManagerFactory createContainerEntityManagerFactory
>> (PersistenceUnitInfo info){
>> EntityManagerSetupImpl emSetupImpl = new EntityManagerSetupImpl();
>> Collection entities = buildEntityList(info, info.getTempClassLoader ());
>> ClassFileTransformer transformer = emSetupImpl.predeploy(entities,
>> info.getTempClassLoader(), info);
>> ...
>> }
>>
>> When I changed the above TopLink file to call getTempClassLoader()
>> only once, that validation exception went away. Looks like the
>> contract for getTempClassLoader() needs to be well defined.
>>
>> Our container creates a new ClassLoader for each invocation of
>> getTempClassLoader. This is fine as far as the contract defined in
>> the javadocs of that API:
>> /**
>> * Return a ClassLoader that the provider may use to temporarily load
>> any
>> * classes, resources, or open URLs. The scope and classpath of this
>> loader
>> * is exactly the same as that of the loader returned by
>> * PersistenceInfo.getClassLoader. None of the classes loaded by this
>> class
>> * loader will be visible to application components.
>> *
>> * @return Temporary ClassLoader with same visibility as current loader
>> */
>> public ClassLoader getTempClassLoader();
>>
>>
>> See the above javadocs is silent about what should happen for
>> multiple invocations. Where as the earlier javadocs for
>> InstrumentableClassLoader's copy() method used to say the following:
>>
>> /**
>> * Create and return a temporary loader with the same visibility
>> * as this loader. The temporary loader may be used to load
>> * resources or any other application classes for the purposes of
>> * introspecting them for annotations. The persistence provider
>> * should not maintain any references to the temporary loader,
>> * or any objects loaded by it.
>> *
>> * @return A temporary classloader with the same classpath as this
>> loader
>> */
>> public ClassLoader copy();
>>
>> The earlier one at least talked about what should happen each time
>> it is called.
>>
>> Since container is not allowed to maintain a reference to this class
>> loader, I think provider should not call getTempClassLoader()
>> multiple times.
>
>
> Can you please explain where it says the container is not allowed to
> maintain a reference? The javadoc immediately above refers to the
> persistence provider, not the container.
I am sorry. It was my fault. I over looked that javadocs. There is no
such restriction for container in that javadocs. I derived that once
based on my understanding that temporary class loader's life cycle is
not yet fully defined in the spec. So if container caches an instance,
that might come in the way of garbage collector.
>
> Maybe it's mentioned somewhere else?
>
> I agree with you that the javadoc should explicitly say what the
> behavior is if the persistence provider calls getTempClassLoader
> multiple times. And, if the container must return the same temp class
> loader to multiple invocations, when the temp class loader is allowed
> to be garbage collected. Is it at undeployment?
Now Mike has clarified this in a subsequent email. The javadocs will be
changed so that container creates a new one every time as we are doing now.
>
> And shouldn't the javadoc say "the persistence provider must not
> maintain any references to the temporary loader or any objects loaded
> by it"?
I hope it does.
Thanks,
Sahoo
>
> Thanks,
>
> Craig
>
>>
>> Thanks,
>> Sahoo
>>
>> Markus Fuchs wrote:
>>
>>
>>> Hi Shelly, hi Ken,
>>>
>>> Thanks very much for forwarding this information.
>>>
>>> Ken,
>>>
>>> I see the same behavior when running the Quicklook persistence-
>>> onetomanyApp.ear:
>>>
>>> The class pe.ejb.ejb30.persistence.toplinksample.ejb.OrderEntity is
>>> loaded twice.
>>>
>>> once with a ClassLoader I:
>>> com.sun.enterprise.util.ConnectorClassLoader @8537
>>> Parent: com.sun.enterprise.loader.EJBClassLoader @8732
>>>
>>> once with a ClassLoader II:
>>> com.sun.enterprise.util.ConnectorClassLoader @6763
>>> Parent: com.sun.enterprise.loader.EJBClassLoader @8732
>>>
>>> Any idea, why the same class is loader twice by different
>>> ClassLoaders, each sharing the same ParentClassLoader? The
>>> Quicklook test can be found appserv-tests/sqetests/ejb/ejb30/
>>> persistence/onetomany in the glassfish repository.
>>>
>>> Thanks!
>>>
>>> -- markus.
>>>
>>>
>>> Shelly (Donna) McGowan wrote:
>>>
>>>
>>>> Markus,
>>>>
>>>> I'm not sure if your debugging the schema deployment problem
>>>> exhibited
>>>> in Deepa's quicklook test or the ManyToOne/OneToMany relationships
>>>> fail
>>>> to load or both, but Oracle sent this email on Friday inferring a
>>>> classloader issue on the ManyToOne/OneToMany issue. Just wanted
>>>> to make
>>>> sure you saw this.
>>>>
>>>> Shelly
>>>>
>>>>
>>>>
>>>> Markus Fuchs wrote On 11/04/05 20:13,:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> I now can reproduce the problem in my environment and should be
>>>>> able to find the problem soon. But I have to leave now. I'm
>>>>> planning on updating y'all Sunday.
>>>>>
>>>>> Have a good weekend,
>>>>>
>>>>> -- markus.
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------
>>>>> -----
>>>>>
>>>>> Subject:
>>>>> Re: [Issue 66] New - Enterprise archives fail to load if MX1 and
>>>>> 1XM relationships used in entities within persistence archive
>>>>> From:
>>>>> Christopher Delahunt <christopher.delahunt_at_oracle.com>
>>>>> Date:
>>>>> Fri, 04 Nov 2005 14:53:04 -0500
>>>>> To:
>>>>> persistence_at_glassfish.dev.java.net
>>>>>
>>>>> To:
>>>>> persistence_at_glassfish.dev.java.net
>>>>> CC:
>>>>> Peter Krogh <peter.krogh_at_oracle.com>, Shelly.McGowan_at_Sun.COM
>>>>>
>>>>>
>>>>> Hello Sun,
>>>>>
>>>>> In tracking down this bug, we have encountered a situation we
>>>>> cannot explain. In our initialization code we explicitly load all
>>>>> entity classes with the provided temp loader. When processing
>>>>> Order, the return type on getLineItem yields a class that was
>>>>> loaded by a loader that is different than the one provided. This
>>>>> behavior is the root of the problem, and is occurring since the
>>>>> changes on the 26th.
>>>>>
>>>>>
>>>>> Any insight is appreciated.
>>>>>
>>>>>
>>>>> Best Regards,
>>>>> Chris
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Shelly (Donna) McGowan [mailto:Shelly.McGowan_at_Sun.COM]
>>>>>> Sent: Wednesday, November 02, 2005 4:58 PM
>>>>>> To: persistence_at_glassfish.dev.java.net
>>>>>> Subject: Re: [Issue 66] New - Enterprise archives fail to load
>>>>>> if MX1
>>>>>> and 1XM relationships used in entities within persistence archive
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> This issue is still occurring on the latest Glassfish builds
>>>>>> (11/1).
>>>>>> There is no workaround that I'm aware of that resolves the issue
>>>>>> except
>>>>>> to use last week's promoted build (10/26).
>>>>>>
>>>>>> If there is a workaround, please reply to this alias.
>>>>>>
>>>>>> Shelly
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> smcgowan_at_dev.java.net wrote On 10/30/05 17:01,:
>>>>>>
>>>>>>
>>>>>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=66
>>>>>>> Issue #|66
>>>>>>> Summary|Enterprise archives fail to load if MX1 and 1XM relati
>>>>>>> |onships used in entities within persistence archive
>>>>>>> Component|glassfish
>>>>>>> Version|9.0pe
>>>>>>> Platform|Sun
>>>>>>> OS/Version|Solaris
>>>>>>> URL|
>>>>>>> Status|NEW
>>>>>>> Status whiteboard|
>>>>>>> Keywords|
>>>>>>> Resolution|
>>>>>>> Issue type|DEFECT
>>>>>>> Priority|P1
>>>>>>> Subcomponent|entity-persistence
>>>>>>> Assigned to|mvatkina
>>>>>>> Reported by|smcgowan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------- Additional comments from smcgowan_at_dev.java.net Sun Oct
>>>>>>> 30 22:01:42 +0000 2005 -------
>>>>>>> enterprise archives containing a persistence archive in which
>>>>>>> the entities have
>>>>>>> a ManyToOne or OneToMany relationship defined fail to load with a
>>>>>>> ValidationException as shown below. These mapping of the
>>>>>>> relationships are
>>>>>>> correctly defined and have worked till recently (10/27). The
>>>>>>> verifier
>>>>>>> highlights the same problem.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Exception Description: The attribute [employees] in entity
>>>>>>> class [class
>>>>>>> com.sun.ts.tests.ejb30.persistence.query.apitests.Insurance] has
>>>>>>> a mappedBy value of [insurance] which does not exist in its
>>>>>>> owning entity class
>>>>>>> [class com.sun.ts.tests.ejb30.persistence.query.apitests.
>>>>>>> EmbeddableSuperclass, this is invalid, and your attribute
>>>>>>> should reference the
>>>>>>> correct subclass.
>>>>>>> Local Exception Stack:
>>>>>>> Exception [TOPLINK-7154] (Oracle TopLink Essentials - 10g
>>>>>>> release 4 (10.1.4.0.0)
>>>>>>> (Build 051026Dev)):
>>>>>>> oracle.toplink.essentials.exceptions.ValidationException
>>>>>>> Exception Description: The attribute [employees] in entity
>>>>>>> class [class
>>>>>>> com.sun.ts.tests.ejb30.persistence.query.apitests.Insurance] has
>>>>>>> a mappedBy value of [insurance] which does not exist in its
>>>>>>> owning entity class
>>>>>>> [class com.sun.ts.tests.ejb30.persistence.query.apitests.
>>>>>>> EmbeddableSuperclass, this is invalid, and your attribute
>>>>>>> should reference the
>>>>>>> correct subclass.
>>>>>>> at
>>>>>>> oracle.toplink.essentials.exceptions.ValidationException.noMapped
>>>>>>> ByAttributeFound(ValidationException.java:1019)
>>>>>>> at
>>>>>>> oracle.toplink.essentials.internal.annotations.EJBAnnotationsProc
>>>>>>> essor.getOwnerMapping(EJBAnnotationsProcessor.java:418)
>>>>>>> at
>>>>>>> oracle.toplink.essentials.internal.annotations.EJBAnnotationsProc
>>>>>>> essor.getOwnerMappingForeignKeys(EJBAnnotationsProcessor.java: 430)
>>>>>>> at
>>>>>>> oracle.toplink.essentials.internal.annotations.EJBAnnotationsProc
>>>>>>> essor.processOneToMany(EJBAnnotationsProcessor.java:1893)
>>>>>>> at
>>>>>>> oracle.toplink.essentials.internal.annotations.EJBAnnotationsProc
>>>>>>> essor.processRelationshipAccessor(EJBAnnotationsProcessor.java:
>>>>>>> 2236)
>>>>>>> at
>>>>>>> oracle.toplink.essentials.internal.annotations.EJBAnnotationsProc
>>>>>>> essor.processRelatedClass(EJBAnnotationsProcessor.java:2207)
>>>>>>> at
>>>>>>> oracle.toplink.essentials.internal.annotations.EJBAnnotationsProc
>>>>>>> essor.processORAnnotations(EJBAnnotationsProcessor.java:1989)
>>>>>>> at
>>>>>>> oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImp
>>>>>>> l.predeploy(EntityManagerSetupImpl.java:299)
>>>>>>> at
>>>>>>> oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.c
>>>>>>> reateContainerEntityManagerFactory
>>>>>>> (EntityManagerFactoryProvider.java:
>>>>>>> 104)
>>>>>>>
>>>>>>> -----------------------------------------------------------------
>>>>>>> ----
>>>>>>> To unsubscribe, e-mail: issues-unsubscribe_at_glassfish.dev.java.net
>>>>>>> For additional commands, e-mail: issues-
>>>>>>> help_at_glassfish.dev.java.net
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>
MIME-version: 1.0
Content-type: message/rfc822
Date: Mon, 07 Nov 2005 16:56:00 -0800
From: Marina Vatkina <Marina.Vatkina_at_Sun.COM>
Subject: Re: Out-of-container example?
To: persistence_at_glassfish.dev.java.net
Cc: Tom Ware <tom.ware_at_oracle.com>
Message-id: <436FF7A0.4050106_at_Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Hi Michael,
Are there any rules for locating persistence.xml in this case?
thanks,
-marina
Michael Bouschen wrote On 11/04/05 00:26,:
> Hi Marina,
>
>
>>Hi Michael,
>>
>>Thanks for the example. Just to make sure I understand it correctly,
>>"<driver>" is to be substituted with my driver class com.database.MyDriver,
>>etc., right?
>
>
> Yes that's right, e.g. it is oracle.jdbc.driver.OracleDriver in case of
> an oracle database.
>
> Regards Michael
>
>
>>thanks,
>>-marina
>>
>>Michael Bouschen wrote:
>>
>>
>>
>>>Hi Marina,
>>>
>>>attached you find a Main.java and a persistence.xml.
>>>
>>>Class Main implements a main method that creates EMF, EM, starts a tx,
>>>persists a new Customer, commits the tx and then runs an EJBQL query.
>>>The persistence.xml lists the persistent classes from the application
>>>domain, e.g. oracle.toplink.examples.Customer, etc. I added the values
>>>for jdbc driver name, url, anme and password as <driver>, <url>, etc.
>>>This needs to be changed according to the local environment.
>>>
>>>You need to add the -javaagent option to the jvm call:
>>> java -javaagent:${glassfish.home}/lib/toplink-essentials-agent.jar Main
>>>
>>>In addition to the jdbc driver I have the following jars from the
>>>{glassfish.home}/lib directory in the classpath: asm.jar,
>>>toplink-essentials.jar, antlr.jar, javaee.jar.
>>>
>>>I hope this helps.
>>>
>>>Regards Michael
>>>
>>>
>>>
>>>>Michael, Tom,
>>>>
>>>>Can you give an example of persistence.xml
>>>>and a main() method that constructs emf for
>>>>a Java SE persistence?
>>>>
>>>>It'll be helpful to put this on the Entity
>>>>Persistence web page.
>>>>
>>>>thanks,
>>>>-marina
>>>>
>>>
>>> --------------------------------------------------------------------------------
>>> Name: Main.java
>>> Main.java Type: Plain Text (text/plain)
>>> Encoding: 7BIT
>>>
>>> Name: persistence.xml
>>> persistence.xml Type: text/xml
>>> Encoding: 7BIT
>>
>>
>
MIME-version: 1.0
Content-type: message/rfc822
Date: Tue, 08 Nov 2005 15:57:16 +0100
From: Michael Bouschen <Michael.Bouschen_at_Sun.COM>
Subject: Re: Out-of-container example?
To: persistence_at_glassfish.dev.java.net
Cc: Tom Ware <tom.ware_at_oracle.com>
Message-id: <4370BCCC.4040806_at_sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Hi Marina,
the persistence.xml file must be in a META-INF directory reachable from
the CLASSPATH. In my test environment I have all the class files in a
classes directory. I copy the persistence.xml file to classes/META-INF
and then put the classes directory in the beginning of the CLASSPATH.
Regards Michael
> Hi Michael,
>
> Are there any rules for locating persistence.xml in this case?
>
> thanks,
> -marina
>
> Michael Bouschen wrote On 11/04/05 00:26,:
>
>>Hi Marina,
>>
>>
>>
>>>Hi Michael,
>>>
>>>Thanks for the example. Just to make sure I understand it correctly,
>>>"<driver>" is to be substituted with my driver class com.database.MyDriver,
>>>etc., right?
>>
>>
>>Yes that's right, e.g. it is oracle.jdbc.driver.OracleDriver in case of
>>an oracle database.
>>
>>Regards Michael
>>
>>
>>
>>>thanks,
>>>-marina
>>>
>>>Michael Bouschen wrote:
>>>
>>>
>>>
>>>
>>>>Hi Marina,
>>>>
>>>>attached you find a Main.java and a persistence.xml.
>>>>
>>>>Class Main implements a main method that creates EMF, EM, starts a tx,
>>>>persists a new Customer, commits the tx and then runs an EJBQL query.
>>>>The persistence.xml lists the persistent classes from the application
>>>>domain, e.g. oracle.toplink.examples.Customer, etc. I added the values
>>>>for jdbc driver name, url, anme and password as <driver>, <url>, etc.
>>>>This needs to be changed according to the local environment.
>>>>
>>>>You need to add the -javaagent option to the jvm call:
>>>> java -javaagent:${glassfish.home}/lib/toplink-essentials-agent.jar Main
>>>>
>>>>In addition to the jdbc driver I have the following jars from the
>>>>{glassfish.home}/lib directory in the classpath: asm.jar,
>>>>toplink-essentials.jar, antlr.jar, javaee.jar.
>>>>
>>>>I hope this helps.
>>>>
>>>>Regards Michael
>>>>
>>>>
>>>>
>>>>
>>>>>Michael, Tom,
>>>>>
>>>>>Can you give an example of persistence.xml
>>>>>and a main() method that constructs emf for
>>>>>a Java SE persistence?
>>>>>
>>>>>It'll be helpful to put this on the Entity
>>>>>Persistence web page.
>>>>>
>>>>>thanks,
>>>>>-marina
>>>>>
>>>>
>>>>--------------------------------------------------------------------------------
>>>> Name: Main.java
>>>> Main.java Type: Plain Text (text/plain)
>>>> Encoding: 7BIT
>>>>
>>>> Name: persistence.xml
>>>> persistence.xml Type: text/xml
>>>> Encoding: 7BIT
>>>
>>>
>
MIME-version: 1.0
Content-type: message/rfc822
Date: Tue, 08 Nov 2005 17:44:31 +0530
From: Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
Subject: EAR scope persistence jar and classpath
To: Mike Keith <michael.keith_at_oracle.com>
Cc: "persistence_at_glassfish.dev.java.net" <persistence_at_glassfish.dev.java.net>
Message-id: <437096A7.9080200_at_Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252; format=flowed
Content-transfer-encoding: 8BIT
Hi Mike,
Referring to the latest packaging proposal (10/19), I see the following
is mentioned in section #6.2.
"All persistence classes defined at the level of the Java EE EAR must be
accessible to all other Java EE
components in the application— i.e. loaded by the application
classloader— such that if the same entity
class is referenced by two different Java EE components (which may be
using different persistence
units), the referenced class is the same identical class."
Is container responsible for making the EAR scoped persistence jars
available to all other components in the EAR even if user has not
explicitly specified a dependency on those jar files using Class-Path
manifest in individual component's manifest file? This indirectly means
they are treated as library jar files even though they are not placed in
library directory of EAR file.
Thanks,
Sahoo