--
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 26 Oct 2005 13:45:30 -0000 Issue 5
Topics (messages 10 through 19):
Re: EJBQL parser update supporting TRIM
10 by: Michael Bouschen
Re: packaging withour .par
11 by: Shelly (Donna) McGowan
12 by: Sanjeeb Kumar Sahoo
13 by: Marina Vatkina
14 by: Sanjeeb Kumar Sahoo
EAR scoped Persistence Unit definition
15 by: Sanjeeb Kumar Sahoo
Question about EJBQL HAVING clause
16 by: Michael Bouschen
Re: persistence-api changes for new packaging proposal]
17 by: Sanjeeb Kumar Sahoo
18 by: Sanjeeb Kumar Sahoo
New persistence.xml struture
19 by: Michael Bouschen
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, 24 Oct 2005 14:08:33 +0200
From: Michael Bouschen <Michael.Bouschen_at_Sun.COM>
Subject: Re: EJBQL parser update supporting TRIM
To: tom Ware <tom.ware_at_oracle.com>
Cc: persistence_at_glassfish.dev.java.net
Message-id: <435CCEC1.9030806_at_sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Hi Tom,
I checked in the change today.
Regards Michael
> Hi Tom,
>
> Thangs for looking into this. I can check it in. I think it makes sense
> to have this a separate check in from packaging component changes.
>
> Regards Michael
>
>> Michael,
>>
>> Looks good. Should I check it into glassfish, or do you want to? If
>> I check it in, it will probably go in when the packaging component
>> goes in.
>>
>> -Tom
>>
>>
>> Michael Bouschen wrote:
>>
>>> Hi Tom,
>>>
>>> attached you find a new update of the EJBQL parser implementation
>>> (EJBQL-Trim-051019.jar). Comments are welcome.
>>>
>>> It adds support for the string function TRIM to the EJBQL parser in
>>> entity-persistence. This version throws an exception if the TRIM
>>> function defines a trim character for a none TRAILING trim
>>> specification. I will remove this as soon as the expression framework
>>> support this feature.
>>>
>>> Regards Michael
>>>
>>>
>>>
>>>
>>>
>
MIME-version: 1.0
Content-type: message/rfc822
Date: Mon, 24 Oct 2005 08:26:25 -0400
From: "Shelly (Donna) McGowan" <Shelly.McGowan_at_Sun.COM>
Subject: Re: packaging withour .par
To: Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
Cc: "persistence_at_glassfish.dev.java.net" <persistence_at_glassfish.dev.java.net>
Message-id: <435CD2F1.2060707_at_Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Sahoo,
Sure. I can do this today.
Just to confirm,
- no longer need to specify provider (in-container)
- application.xml is no longer required
- jta-datasource and non-jta-datasource do not co-exist
- name element is required
Shelly
Sanjeeb Kumar Sahoo wrote On 10/24/05 04:18,:
> Hi Shelly,
> glassfish now supports packaging of JSR 220 entity beans in jar/war
> files. Would you mind upgrading CTS tests to use the new packaging
> format? At this point, I would suggest making just the necessary
> changes, i.e. update the persistence.xml to new schema and change file
> extension from par to jar. Let's not bundle the driver in a war file to
> start with, let them be in an ejb-jar. Is it possible to test these
> changes first? Once this works, we will change TopLink Essentials to use
> the new SPIs. We are not changing TopLink Essentials at this point
> because we want to do these changes in steps.
>
> Thanks,
> Sahoo
>
MIME-version: 1.0
Content-type: message/rfc822
Date: Mon, 24 Oct 2005 18:56:08 +0530
From: Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
Subject: Re: packaging withour .par
To: Shelly.McGowan_at_Sun.COM
Cc: "persistence_at_glassfish.dev.java.net" <persistence_at_glassfish.dev.java.net>
Message-id: <435CE0F0.207_at_Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
Shelly (Donna) McGowan wrote:
>Sahoo,
>
>Sure. I can do this today.
>
>Just to confirm,
>
>- no longer need to specify provider (in-container)
>- application.xml is no longer required
>- jta-datasource and non-jta-datasource do not co-exist
>- name element is required
>
>
Yes, you are correct in all the items.
Thanks,
Sahoo
>Shelly
>
>
>
>Sanjeeb Kumar Sahoo wrote On 10/24/05 04:18,:
>
>
>>Hi Shelly,
>> glassfish now supports packaging of JSR 220 entity beans in jar/war
>>files. Would you mind upgrading CTS tests to use the new packaging
>>format? At this point, I would suggest making just the necessary
>>changes, i.e. update the persistence.xml to new schema and change file
>>extension from par to jar. Let's not bundle the driver in a war file to
>>start with, let them be in an ejb-jar. Is it possible to test these
>>changes first? Once this works, we will change TopLink Essentials to use
>>the new SPIs. We are not changing TopLink Essentials at this point
>>because we want to do these changes in steps.
>>
>>Thanks,
>>Sahoo
>>
>>
>>
>
>
>
MIME-version: 1.0
Content-type: message/rfc822
Date: Mon, 24 Oct 2005 09:29:42 -0700
From: Marina Vatkina <Marina.Vatkina_at_Sun.COM>
Subject: Re: packaging withour .par
To: persistence_at_glassfish.dev.java.net
Cc: Shelly.McGowan_at_Sun.COM
Message-id: <435D0BF6.E66C9B8_at_sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-15
Content-transfer-encoding: 7BIT
Sanjeeb Kumar Sahoo wrote:
> Shelly (Donna) McGowan wrote:
>
> >Sahoo,
> >
> >Sure. I can do this today.
> >
> >Just to confirm,
> >
> >- no longer need to specify provider (in-container)
> >- application.xml is no longer required
> >- jta-datasource and non-jta-datasource do not co-exist
> >- name element is required
> >
> >
> Yes, you are correct in all the items.
Sahoo, the latest proposal removed jta-datasource and
non-jta-datasource restriction. Does the current code
work differently?
thanks,
-marina
>
> Thanks,
> Sahoo
>
> >Shelly
> >
> >
> >
> >Sanjeeb Kumar Sahoo wrote On 10/24/05 04:18,:
> >
> >
> >>Hi Shelly,
> >> glassfish now supports packaging of JSR 220 entity beans in jar/war
> >>files. Would you mind upgrading CTS tests to use the new packaging
> >>format? At this point, I would suggest making just the necessary
> >>changes, i.e. update the persistence.xml to new schema and change file
> >>extension from par to jar. Let's not bundle the driver in a war file to
> >>start with, let them be in an ejb-jar. Is it possible to test these
> >>changes first? Once this works, we will change TopLink Essentials to use
> >>the new SPIs. We are not changing TopLink Essentials at this point
> >>because we want to do these changes in steps.
> >>
> >>Thanks,
> >>Sahoo
> >>
> >>
> >>
> >
> >
> >
MIME-version: 1.0
Content-type: message/rfc822
Date: Mon, 24 Oct 2005 22:26:03 +0530
From: Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
Subject: Re: packaging withour .par
To: persistence_at_glassfish.dev.java.net
Cc: Shelly.McGowan_at_Sun.COM
Message-id: <435D1223.60108_at_Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-15; format=flowed
Content-transfer-encoding: 7BIT
Hi Marina,
Marina Vatkina wrote:
>Sanjeeb Kumar Sahoo wrote:
>
>
>
>>Shelly (Donna) McGowan wrote:
>>
>>
>>
>>>Sahoo,
>>>
>>>Sure. I can do this today.
>>>
>>>Just to confirm,
>>>
>>>- no longer need to specify provider (in-container)
>>>- application.xml is no longer required
>>>- jta-datasource and non-jta-datasource do not co-exist
>>>- name element is required
>>>
>>>
>>>
>>>
>>Yes, you are correct in all the items.
>>
>>
>
>Sahoo, the latest proposal removed jta-datasource and
>non-jta-datasource restriction. Does the current code
>work differently?
>
>
We never imposed the restriction earlier, so no need to remove any thing.
Secondly, since we are not using the latest SPI to communicate with the
provider,
we won't be using the transaction-type attribute from persistence.xml.
This is something I had
mentioned in one of my earlier email.
Thanks,
Sahoo
>thanks,
>-marina
>
>
>
>
>>Thanks,
>>Sahoo
>>
>>
>>
>>>Shelly
>>>
>>>
>>>
>>>Sanjeeb Kumar Sahoo wrote On 10/24/05 04:18,:
>>>
>>>
>>>
>>>
>>>>Hi Shelly,
>>>> glassfish now supports packaging of JSR 220 entity beans in jar/war
>>>>files. Would you mind upgrading CTS tests to use the new packaging
>>>>format? At this point, I would suggest making just the necessary
>>>>changes, i.e. update the persistence.xml to new schema and change file
>>>>extension from par to jar. Let's not bundle the driver in a war file to
>>>>start with, let them be in an ejb-jar. Is it possible to test these
>>>>changes first? Once this works, we will change TopLink Essentials to use
>>>>the new SPIs. We are not changing TopLink Essentials at this point
>>>>because we want to do these changes in steps.
>>>>
>>>>Thanks,
>>>>Sahoo
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
>
>
MIME-version: 1.0
Content-type: message/rfc822
Date: Tue, 25 Oct 2005 00:55:42 +0530
From: Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
Subject: EAR scoped Persistence Unit definition
To: Mike Keith <michael.keith_at_oracle.com>
Cc: "persistence_at_glassfish.dev.java.net" <persistence_at_glassfish.dev.java.net>,
Qingqing Ouyang <Qingqing.Ouyang_at_Sun.COM>
Message-id: <435D3536.3000403_at_Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252; format=flowed
Content-transfer-encoding: 8BIT
Hi Mike,
I have a question regarding root of EAR scoped persistence unit.
Referring the packaging proposal dated 19 Oct 2005, I see the following
being mentioned in the spec:
A persistence unit is defined by a persistence.xml file. The jar file or
directory whose
META-INF directory contains the persistence.xml file is termed the root
of the persistence unit.
In Java EE, the root of a persistence unit may be one of the following:
• ...
• a jar file in the root of the EAR
• a jar file in the EAR lib directory
• ...
I have an structure like this:
app.ear (lib is designated as the library dir)
par1.jar
lib/par2.jar
some_arbitrary_dir/par3.jar
some_arbitrary_dir/ejb.jar
where, par1.jar, par2.jar & par3.jar contain META-INF/persistence.xml
and neither of them is an ejb-jar or app-client-jar.
What are the ear scoped PU Roots defined here?
a) par1.jar, lib/par2.jar, some_arbitrary_dir/par3.jar
OR
b) par1.jar, lib/par2.jar
If the answer is #b, then why do we not give user the flexibility to
organise their ear scoped persistence-units in any arbitrary directory
structures, just like they can organise their ejb-jar, war, rar or
appclient-jars in any arbitrary directory structures inside the ear?
Thanks,
Sahoo
MIME-version: 1.0
Content-type: message/rfc822
Date: Tue, 25 Oct 2005 14:44:38 +0200
From: Michael Bouschen <Michael.Bouschen_at_Sun.COM>
Subject: Question about EJBQL HAVING clause
To: Linda DeMichiel <Linda.Demichiel_at_Sun.COM>,
Mike Keith <michael.keith_at_oracle.com>
Cc: persistence_at_glassfish.dev.java.net
Message-id: <435E28B6.1060706_at_sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Hi Linda, hi Mike,
I have two questions about the HAVING clause in EJBQL.
(1) Aggregates in HAVING clause
I read the current EJBQL BNF that is does not allow aggregates in the
HAVING clause. I'm wondering whether this is on purpose, because the
following query would not be valid:
SELECT c.country, COUNT(c) FROM Customer c
GROUP by c.country HAVING COUNT(c.country) > 3
The BNF for the HAVING clause is (see section 4.7 GROUP BY, HAVING on
page 79 and the BNF on page 92):
having_clause ::= HAVING conditional_expression
Only select_expression, simple_select_expression and constructor_item
allow aggregates and none of them is reachable from conditional_expression.
(2) HAVING clause w/o GROUP BY clause
The spec explicitly allows a HAVING query w/o GROUP BY. Are there any
SELECT clause restrictions in this case?
I have the feeling that there are issues with mapping such queries to
SQL. I tried to run SQL HAVING queries w/o GROUP BY on Oracle and Derby,
but did not have success. Oracle returns an error message "ORA-00979:
not a GROUP BY expression". MySql seems to accept HAVING w/o GROUP BY,
but only if the SELECT clause only uses columns from the HAVING clause.
Thanks.
Regards Michael
MIME-version: 1.0
Content-type: message/rfc822
Date: Tue, 25 Oct 2005 20:24:18 +0530
From: Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
Subject: Re: [Fwd: Re: persistence-api changes for new packaging proposal]
To: Tom Ware <tom.ware_at_oracle.com>
Cc: persistence_at_glassfish.dev.java.net
Message-id: <435E471A.4000608_at_Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
Hi Tom,
Sanjeeb Kumar Sahoo wrote:
> Hi Tom,
> Tom Ware wrote:
>
>> Sahoo,
>>
>> Here is my plan.
>>
>> I will implement a TopLink version that will handle both
>> PersistenceInfo (the old class) and PersistenceUnitInfo (the new
>> class). That way we can do a more seamless transition.
>>
>> I am attaching my version of PersistenceUnitInfo(cut and pasted from
>> the spec) and one class it is dependant on. I believe it can be
>> checked at in any time.
>>
> I have checked them in this morning after adding CDDL headers.
>
>> After it is checked in, we can do the TopLink part of the work in 4
>> phases.
>>
>> 1. Check in the TopLink version that implements both versions
>
>
> I have asked Shelly to update CTS to new spec and run one round of
> CTS. That way we would know if there was any regression in packaging
> changes that I had committed. After that you can do this change. What
> do you suggest?
Thanks to Shelly. She has migrated all the CTS tests to use the new
packaging format and had complete run of CTS. There were no new
failures. So now you can make the above change. Let me know once you
have done this.
Thanks,
Sahoo
>
>> 2. Check in the Glassfish version that uses the new TopLink
>> implementation
>
>
> I have the changes in my local workspace. I can check them in after
> you make change #1.
>
>> 3. Remove the dependance on the old version from TopLink
>> 4. Delete the PersistenceInfo class.
>
>
> #3 & #4 can be done after #2 either by you or me.
>
> Thanks,
> Sahoo
>
>>
>> Let me know what you think,
>> Tom
>>
>> Sanjeeb Kumar Sahoo wrote:
>>
>>> Hi Team,
>>> This is my plans for making changes in glassfish to the latest
>>> packaging changes:
>>>
>>> 1) I will use the latest proposal (the one sent by Linda yesterday).
>>> I will update persistence.xsd so that CTS tests can be migrated from
>>> par to jar as well as to new schema at the same time.
>>>
>>> 2) Not all features from the new packaging spec will be supported in
>>> the initial check in. We will support the persistence unit to be
>>> part of ejb-jar (stand alone as well as embedded), embedded war and
>>> embedded library jar. The rest will be implemented subsequently.
>>>
>>> 3) To minimize the amount of changes in one check in, we will not
>>> update the javax.persistence.spi interfaces in the first check in.
>>> So to start with we don't have to change the part of TopLink
>>> Essential that runs inside container. All the supported features
>>> would work fine. Once the first phase of container changes are made,
>>> in the second phase both container and TopLink Essential will be
>>> modified to use the new SPI.
>>> I hope to check in the first set of changes by Monday (subject to
>>> getting review comments from all reviewers).
>>> The second phase of changes would include update to the SPIs. This
>>> will be done mid next week (*Tom, please confirm, whether this is OK
>>> with you or not*). This will be transparent to users.
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> Subject:
>>> Re: persistence-api changes for new packaging proposal
>>> From:
>>> Tom Ware <tom.ware_at_oracle.com>
>>> Date:
>>> Thu, 20 Oct 2005 13:25:48 -0400
>>> To:
>>> Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
>>>
>>> To:
>>> Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
>>>
>>>
>>>
>>>
>>> Sanjeeb Kumar Sahoo wrote:
>>>
>>>> Tom Ware wrote:
>>>>
>>>>> What do you mean by "the latest proposal"? Are you referring to
>>>>> the version of the proposal you sent me (dated 9/12/05)?
>>>>>
>>>> No. There was a new proposal sent out yesterday by Linda and Mike.
>>>> Have you not seen it?
>>>>
>>> Ok, I'll use that one.
>>>
>>>>> As I mentioned in my earlier email, the changes we have to make in
>>>>> order to be functional on the application server are minimal.
>>>>> Essentially, we just need to update our implementation of
>>>>> PersistenceInfo so that it will compile. You mentioned yesterday
>>>>> that you thought we could come initial work without the change to
>>>>> javax.persistence.PersitenceInfo.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I would prefer this way as opposed to changing both container and
>>>> provider at the same time. What do you say?
>>>
>>>
>>>
>>>
>>>
>>> That's fine with me.
>>>
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>>>
>>>>> -Tom
>>>>>
>>>>> Sanjeeb Kumar Sahoo wrote:
>>>>>
>>>>>> Hi Tom,
>>>>>> First we need to agree on the persistence-api changes. The
>>>>>> latest proposal now contains the schema and changed APIs. Do you
>>>>>> plan to use them or do you have some other version? In any case,
>>>>>> if you have the .java files and .xsd files, please send them to me.
>>>>>>
>>>>>> Thanks,
>>>>>> Sahoo
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>
>
MIME-version: 1.0
Content-type: message/rfc822
Date: Tue, 25 Oct 2005 21:21:25 +0530
From: Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
Subject: Re: [Fwd: Re: persistence-api changes for new packaging proposal]
To: Tom Ware <tom.ware_at_oracle.com>
Cc: persistence_at_glassfish.dev.java.net
Message-id: <435E547D.2020102_at_Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
Hi Tom,
Sanjeeb Kumar Sahoo wrote:
> Hi Tom,
> Tom Ware wrote:
>
>> Sahoo,
>>
>> Here is my plan.
>>
>> I will implement a TopLink version that will handle both
>> PersistenceInfo (the old class) and PersistenceUnitInfo (the new
>> class). That way we can do a more seamless transition.
>>
>> I am attaching my version of PersistenceUnitInfo(cut and pasted from
>> the spec) and one class it is dependant on. I believe it can be
>> checked at in any time.
>>
> I have checked them in this morning after adding CDDL headers.
>
>> After it is checked in, we can do the TopLink part of the work in 4
>> phases.
>>
>> 1. Check in the TopLink version that implements both versions
>
>
> I have asked Shelly to update CTS to new spec and run one round of
> CTS. That way we would know if there was any regression in packaging
> changes that I had committed. After that you can do this change. What
> do you suggest?
Thanks to Shelly. She has migrated all the CTS tests to use the new
packaging format and had complete run of CTS. There were no new
failures. So now you can make the above change. Let me know once you
have done this.
Thanks,
Sahoo
>
>> 2. Check in the Glassfish version that uses the new TopLink
>> implementation
>
>
> I have the changes in my local workspace. I can check them in after
> you make change #1.
>
>> 3. Remove the dependance on the old version from TopLink
>> 4. Delete the PersistenceInfo class.
>
>
> #3 & #4 can be done after #2 either by you or me.
>
> Thanks,
> Sahoo
>
>>
>> Let me know what you think,
>> Tom
>>
>> Sanjeeb Kumar Sahoo wrote:
>>
>>> Hi Team,
>>> This is my plans for making changes in glassfish to the latest
>>> packaging changes:
>>>
>>> 1) I will use the latest proposal (the one sent by Linda yesterday).
>>> I will update persistence.xsd so that CTS tests can be migrated from
>>> par to jar as well as to new schema at the same time.
>>>
>>> 2) Not all features from the new packaging spec will be supported in
>>> the initial check in. We will support the persistence unit to be
>>> part of ejb-jar (stand alone as well as embedded), embedded war and
>>> embedded library jar. The rest will be implemented subsequently.
>>>
>>> 3) To minimize the amount of changes in one check in, we will not
>>> update the javax.persistence.spi interfaces in the first check in.
>>> So to start with we don't have to change the part of TopLink
>>> Essential that runs inside container. All the supported features
>>> would work fine. Once the first phase of container changes are made,
>>> in the second phase both container and TopLink Essential will be
>>> modified to use the new SPI.
>>> I hope to check in the first set of changes by Monday (subject to
>>> getting review comments from all reviewers).
>>> The second phase of changes would include update to the SPIs. This
>>> will be done mid next week (*Tom, please confirm, whether this is OK
>>> with you or not*). This will be transparent to users.
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> Subject:
>>> Re: persistence-api changes for new packaging proposal
>>> From:
>>> Tom Ware <tom.ware_at_oracle.com>
>>> Date:
>>> Thu, 20 Oct 2005 13:25:48 -0400
>>> To:
>>> Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
>>>
>>> To:
>>> Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
>>>
>>>
>>>
>>>
>>> Sanjeeb Kumar Sahoo wrote:
>>>
>>>> Tom Ware wrote:
>>>>
>>>>> What do you mean by "the latest proposal"? Are you referring to
>>>>> the version of the proposal you sent me (dated 9/12/05)?
>>>>>
>>>> No. There was a new proposal sent out yesterday by Linda and Mike.
>>>> Have you not seen it?
>>>>
>>> Ok, I'll use that one.
>>>
>>>>> As I mentioned in my earlier email, the changes we have to make in
>>>>> order to be functional on the application server are minimal.
>>>>> Essentially, we just need to update our implementation of
>>>>> PersistenceInfo so that it will compile. You mentioned yesterday
>>>>> that you thought we could come initial work without the change to
>>>>> javax.persistence.PersitenceInfo.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I would prefer this way as opposed to changing both container and
>>>> provider at the same time. What do you say?
>>>
>>>
>>>
>>>
>>>
>>> That's fine with me.
>>>
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>>>
>>>>> -Tom
>>>>>
>>>>> Sanjeeb Kumar Sahoo wrote:
>>>>>
>>>>>> Hi Tom,
>>>>>> First we need to agree on the persistence-api changes. The
>>>>>> latest proposal now contains the schema and changed APIs. Do you
>>>>>> plan to use them or do you have some other version? In any case,
>>>>>> if you have the .java files and .xsd files, please send them to me.
>>>>>>
>>>>>> Thanks,
>>>>>> Sahoo
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>
>
MIME-version: 1.0
Content-type: message/rfc822
Date: Wed, 26 Oct 2005 15:45:23 +0200
From: Michael Bouschen <Michael.Bouschen_at_Sun.COM>
Subject: New persistence.xml struture
To: Tom Ware <tom.ware_at_oracle.com>
Cc: persistence_at_glassfish.dev.java.net
Message-id: <435F8873.4020408_at_sun.com>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_j2zMBiPL0vWC1unjYNQk6w)"
This is a multi-part message in MIME format.
--Boundary_(ID_j2zMBiPL0vWC1unjYNQk6w)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Hi Tom,
today I updated the persistence.xml file in my containerless test
example according to the syntax of the latest packaging proposal.
I have two questions/issues. Do you want me to file issues in the
glassfish issue tracker system for the two?
(1) I need to include namespace uri in the top most element:
<persistence xmlns="urn:ejb3-namespace">
Otherwise, I get a NPE in PersistenceUnitProcessor.processPersistenceXML
(see attached stacktrace in stacktrace1.txt). The code expects to get a
list of PersistentUnitInfos from the context handler of the XMLReader.
W/o the namespace uri the XML reader does not find any persistence unit
and the returned list is null. Is it required to include the namespace uri?
Furthermore, I understand the recent packaging proposal discussion there
is no requirement that a persistent.xml needs to specify at least one
persistence unit. So the list of PersistentUnitInfos might be empty anyway.
(2) I read the new structure of the persistence.xml file that
persistence-unit has a required attribute called name:
<persistence-unit name="containerless">
The current implementation runs into a NPE for the above line (see
attached stacktrace in stacktrace2.txt). Instead it accepts a nested
element called name:
<persistence-unit>
<name>containerless</name>
Regards Michael
--Boundary_(ID_j2zMBiPL0vWC1unjYNQk6w)
Content-type: text/plain; name=stacktrace1.txt
Content-transfer-encoding: 7BIT
Content-disposition: inline; filename=stacktrace1.txt
run:
[java] java.lang.reflect.InvocationTargetException
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at java.lang.reflect.Method.invoke(Method.java:585)
[java] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:141)
[java] Caused by: java.lang.reflect.InvocationTargetException
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at java.lang.reflect.Method.invoke(Method.java:585)
[java] at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializerAgent.initializeFromAgent(JavaSECMPInitializerAgent.java:54)
[java] at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializerAgent.premain(JavaSECMPInitializerAgent.java:47)
[java] ... 5 more
[java] Caused by: java.lang.NullPointerException
[java] at oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcessor.processPersistenceXML(PersistenceUnitProcessor.java:166)
[java] at oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcessor.processDirectory(PersistenceUnitProcessor.java:84)
[java] at oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcessor.processPersistenceArchive(PersistenceUnitProcessor.java:132)
[java] at oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcessor.getPersistenceUnits(PersistenceUnitProcessor.java:65)
[java] at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.initPersistenceUnits(JavaSECMPInitializer.java:275)
[java] at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.initialize(JavaSECMPInitializer.java:298)
[java] at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.initializeFromAgent(JavaSECMPInitializer.java:315)
[java] ... 11 more
[java] FATAL ERROR in native method: processing of -javaagent failed
[java] Exception in thread "main"
BUILD SUCCESSFUL
Total time: 2 seconds
--Boundary_(ID_j2zMBiPL0vWC1unjYNQk6w)
Content-type: text/plain; name=stacktrace2.txt
Content-transfer-encoding: 7BIT
Content-disposition: inline; filename=stacktrace2.txt
run:
[java] java.lang.reflect.InvocationTargetException
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at java.lang.reflect.Method.invoke(Method.java:585)
[java] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:141)
[java] Caused by: java.lang.reflect.InvocationTargetException
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at java.lang.reflect.Method.invoke(Method.java:585)
[java] at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializerAgent.initializeFromAgent(JavaSECMPInitializerAgent.java:54)
[java] at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializerAgent.premain(JavaSECMPInitializerAgent.java:47)
[java] ... 5 more
[java] Caused by: java.lang.NullPointerException
[java] at oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcessor.processPersistenceXML(PersistenceUnitProcessor.java:166)
[java] at oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcessor.processDirectory(PersistenceUnitProcessor.java:84)
[java] at oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcessor.processPersistenceArchive(PersistenceUnitProcessor.java:132)
[java] at oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcessor.getPersistenceUnits(PersistenceUnitProcessor.java:65)
[java] at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.initPersistenceUnits(JavaSECMPInitializer.java:275)
[java] at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.initialize(JavaSECMPInitializer.java:298)
[java] at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.initializeFromAgent(JavaSECMPInitializer.java:315)
[java] ... 11 more
[java] FATAL ERROR in native method: processing of -javaagent failed
[java] Exception in thread "main"
BUILD SUCCESSFUL
Total time: 2 seconds
--Boundary_(ID_j2zMBiPL0vWC1unjYNQk6w)--