You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "John D. Ament" <jo...@gmail.com> on 2014/09/01 22:41:04 UTC
Data Module - some issues in SE/Maven Tests
Hi All!
I've hit a couple of issues with the Data Module and wanted to know if it
was worth fixing.
First, my sample app can be found at [1] (note you'll need JDK8 to run) and
you can run the test JPATest to see the results, using
mvn -Dtest=JPATest -Ddeltaspike.version=1.0.2
First issue you'll note is that the following output (or something similar
to it will be given):
java.lang.IllegalArgumentException: URL does not exist:
archive:se-examples.jar/META-INF/persistence.xml
at
org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)
at
org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)
at
org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)
at
org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)
at
org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)
at
org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:73)
(full stack available at [2], test.log). It seems like the
RepositoryExtension is picking up on my persistence.xml and aggressively
trying to parse them (at this point, I don't have any @Repository's defined
in my app). For some reason it cannot parse this URL but it does seem to
pick up the persistence.xml from target/classes/META-INF so it does
eventually parse it. To work around this, I wrapped
DescriptorReader.readAllFromClassPath's result.add with an exception check.
I figure if it can't read the descriptor, no reason to make the whole app
die. What do you think?
Second issue, after fixing this one, was that AbstractEntityRepository was
being picked up as a @Repository and erroring out saying that there's no
entity for it. This one I wasn't expecting. To fix it, in
RepsitoryComponents, I added an explicit check if it was the base class, if
it was return null rather than exception and check for null in the add
method. This also fixed things and the tests started running fine. This
fix seems more hacky, and I'm wondering if I'm just doing something wrong
to make this class be picked up.
You can see the summary of changes in the gist's patch.txt.
John
[1]: https://github.com/johnament/restful-and-beyond-tut2184
[2]: https://gist.github.com/johnament/d4a55ce7251062ee0b85
Re: Data Module - some issues in SE/Maven Tests
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
Archive url issue is due to the arquillian adapter (so no problem for data
module)
Can't the other one be fixed using @Typed?
Le 1 sept. 2014 21:41, "John D. Ament" <jo...@gmail.com> a écrit :
> Hi All!
>
> I've hit a couple of issues with the Data Module and wanted to know if it
> was worth fixing.
>
> First, my sample app can be found at [1] (note you'll need JDK8 to run) and
> you can run the test JPATest to see the results, using
>
> mvn -Dtest=JPATest -Ddeltaspike.version=1.0.2
>
> First issue you'll note is that the following output (or something similar
> to it will be given):
>
> java.lang.IllegalArgumentException: URL does not exist:
> archive:se-examples.jar/META-INF/persistence.xml
>
> at
>
> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)
>
> at
>
> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)
>
> at
>
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)
>
> at
>
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)
>
> at
>
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)
>
> at
>
> org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:73)
>
> (full stack available at [2], test.log). It seems like the
> RepositoryExtension is picking up on my persistence.xml and aggressively
> trying to parse them (at this point, I don't have any @Repository's defined
> in my app). For some reason it cannot parse this URL but it does seem to
> pick up the persistence.xml from target/classes/META-INF so it does
> eventually parse it. To work around this, I wrapped
> DescriptorReader.readAllFromClassPath's result.add with an exception check.
> I figure if it can't read the descriptor, no reason to make the whole app
> die. What do you think?
>
> Second issue, after fixing this one, was that AbstractEntityRepository was
> being picked up as a @Repository and erroring out saying that there's no
> entity for it. This one I wasn't expecting. To fix it, in
> RepsitoryComponents, I added an explicit check if it was the base class, if
> it was return null rather than exception and check for null in the add
> method. This also fixed things and the tests started running fine. This
> fix seems more hacky, and I'm wondering if I'm just doing something wrong
> to make this class be picked up.
>
> You can see the summary of changes in the gist's patch.txt.
>
> John
>
>
> [1]: https://github.com/johnament/restful-and-beyond-tut2184
> [2]: https://gist.github.com/johnament/d4a55ce7251062ee0b85
>
Re: Data Module - some issues in SE/Maven Tests
Posted by "John D. Ament" <jo...@gmail.com>.
That I never got a good resolution for. In my case, I was able to work
around by not including the persistence.xml in my archive.
On Fri, Oct 10, 2014 at 5:16 AM, Ove Ranheim <or...@gmail.com> wrote:
> Which class should be excluded in beans.xml to omit the
> "archive:.../persistence.xml" exception?
>
> 2014-09-02 11:29 GMT+02:00 John D. Ament <jo...@gmail.com>:
>
> > For the first issue, looks like if I just exclude the file from the
> archive
> > my problems are resolved. I'll go with that for now. For some reason,
> > this issue doesn't pop up using META-INF/apache-deltaspike.properties but
> > using the same approach doesn't fix it.
> >
> > For the second, the easiest fix I have (that's also a bit clean) is to
> > simply veto the class within the repository extension. If there are no
> > objections, I'll commit that change this morning. Right now I cannot
> > exclude the API from the uber jar.
> >
> > John
> >
> >
> > On Tue, Sep 2, 2014 at 3:17 AM, Thomas Hug <th...@gmail.com> wrote:
> >
> > > Instead of patching the second one, for an uber-jar it might also be a
> > > valid recommendation to exclude the class over the beans.xml.
> > >
> > >
> > > On Tue, Sep 2, 2014 at 8:12 AM, Thomas Hug <th...@gmail.com>
> wrote:
> > >
> > > > Hi John
> > > >
> > > > First one should - as Romain mentioned - usually not be a problem.
> > Might
> > > > still be worth adding the exception check as I've run into problems
> on
> > > WLS
> > > > with this particular approach. We lose the ability to deal with
> > entities
> > > > defined in orm.xml's but that's probably still better than crashing
> :-)
> > > >
> > > > The second one comes from creating an uber-jar - the api module
> doesn't
> > > > have a beans.xml. Can't think of a different approach to get rid of
> > this
> > > > one...
> > > >
> > > >
> > > > On Tue, Sep 2, 2014 at 6:54 AM, Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > wrote:
> > > >
> > > >> Hi
> > > >>
> > > >> Archive url issue is due to the arquillian adapter (so no problem
> for
> > > data
> > > >> module)
> > > >>
> > > >> Can't the other one be fixed using @Typed?
> > > >> Le 1 sept. 2014 21:41, "John D. Ament" <jo...@gmail.com> a
> > > écrit :
> > > >>
> > > >> > Hi All!
> > > >> >
> > > >> > I've hit a couple of issues with the Data Module and wanted to
> know
> > if
> > > >> it
> > > >> > was worth fixing.
> > > >> >
> > > >> > First, my sample app can be found at [1] (note you'll need JDK8 to
> > > run)
> > > >> and
> > > >> > you can run the test JPATest to see the results, using
> > > >> >
> > > >> > mvn -Dtest=JPATest -Ddeltaspike.version=1.0.2
> > > >> >
> > > >> > First issue you'll note is that the following output (or something
> > > >> similar
> > > >> > to it will be given):
> > > >> >
> > > >> > java.lang.IllegalArgumentException: URL does not exist:
> > > >> > archive:se-examples.jar/META-INF/persistence.xml
> > > >> >
> > > >> > at
> > > >> >
> > > >> >
> > > >>
> > >
> >
> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)
> > > >> >
> > > >> > at
> > > >> >
> > > >> >
> > > >>
> > >
> >
> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)
> > > >> >
> > > >> > at
> > > >> >
> > > >> >
> > > >>
> > >
> >
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)
> > > >> >
> > > >> > at
> > > >> >
> > > >> >
> > > >>
> > >
> >
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)
> > > >> >
> > > >> > at
> > > >> >
> > > >> >
> > > >>
> > >
> >
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)
> > > >> >
> > > >> > at
> > > >> >
> > > >> >
> > > >>
> > >
> >
> org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:73)
> > > >> >
> > > >> > (full stack available at [2], test.log). It seems like the
> > > >> > RepositoryExtension is picking up on my persistence.xml and
> > > aggressively
> > > >> > trying to parse them (at this point, I don't have any
> @Repository's
> > > >> defined
> > > >> > in my app). For some reason it cannot parse this URL but it does
> > seem
> > > >> to
> > > >> > pick up the persistence.xml from target/classes/META-INF so it
> does
> > > >> > eventually parse it. To work around this, I wrapped
> > > >> > DescriptorReader.readAllFromClassPath's result.add with an
> exception
> > > >> check.
> > > >> > I figure if it can't read the descriptor, no reason to make the
> > whole
> > > >> app
> > > >> > die. What do you think?
> > > >> >
> > > >> > Second issue, after fixing this one, was that
> > AbstractEntityRepository
> > > >> was
> > > >> > being picked up as a @Repository and erroring out saying that
> > there's
> > > no
> > > >> > entity for it. This one I wasn't expecting. To fix it, in
> > > >> > RepsitoryComponents, I added an explicit check if it was the base
> > > >> class, if
> > > >> > it was return null rather than exception and check for null in the
> > add
> > > >> > method. This also fixed things and the tests started running
> fine.
> > > >> This
> > > >> > fix seems more hacky, and I'm wondering if I'm just doing
> something
> > > >> wrong
> > > >> > to make this class be picked up.
> > > >> >
> > > >> > You can see the summary of changes in the gist's patch.txt.
> > > >> >
> > > >> > John
> > > >> >
> > > >> >
> > > >> > [1]: https://github.com/johnament/restful-and-beyond-tut2184
> > > >> > [2]: https://gist.github.com/johnament/d4a55ce7251062ee0b85
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: Data Module - some issues in SE/Maven Tests
Posted by Ove Ranheim <or...@gmail.com>.
Which class should be excluded in beans.xml to omit the
"archive:.../persistence.xml" exception?
2014-09-02 11:29 GMT+02:00 John D. Ament <jo...@gmail.com>:
> For the first issue, looks like if I just exclude the file from the archive
> my problems are resolved. I'll go with that for now. For some reason,
> this issue doesn't pop up using META-INF/apache-deltaspike.properties but
> using the same approach doesn't fix it.
>
> For the second, the easiest fix I have (that's also a bit clean) is to
> simply veto the class within the repository extension. If there are no
> objections, I'll commit that change this morning. Right now I cannot
> exclude the API from the uber jar.
>
> John
>
>
> On Tue, Sep 2, 2014 at 3:17 AM, Thomas Hug <th...@gmail.com> wrote:
>
> > Instead of patching the second one, for an uber-jar it might also be a
> > valid recommendation to exclude the class over the beans.xml.
> >
> >
> > On Tue, Sep 2, 2014 at 8:12 AM, Thomas Hug <th...@gmail.com> wrote:
> >
> > > Hi John
> > >
> > > First one should - as Romain mentioned - usually not be a problem.
> Might
> > > still be worth adding the exception check as I've run into problems on
> > WLS
> > > with this particular approach. We lose the ability to deal with
> entities
> > > defined in orm.xml's but that's probably still better than crashing :-)
> > >
> > > The second one comes from creating an uber-jar - the api module doesn't
> > > have a beans.xml. Can't think of a different approach to get rid of
> this
> > > one...
> > >
> > >
> > > On Tue, Sep 2, 2014 at 6:54 AM, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > >> Hi
> > >>
> > >> Archive url issue is due to the arquillian adapter (so no problem for
> > data
> > >> module)
> > >>
> > >> Can't the other one be fixed using @Typed?
> > >> Le 1 sept. 2014 21:41, "John D. Ament" <jo...@gmail.com> a
> > écrit :
> > >>
> > >> > Hi All!
> > >> >
> > >> > I've hit a couple of issues with the Data Module and wanted to know
> if
> > >> it
> > >> > was worth fixing.
> > >> >
> > >> > First, my sample app can be found at [1] (note you'll need JDK8 to
> > run)
> > >> and
> > >> > you can run the test JPATest to see the results, using
> > >> >
> > >> > mvn -Dtest=JPATest -Ddeltaspike.version=1.0.2
> > >> >
> > >> > First issue you'll note is that the following output (or something
> > >> similar
> > >> > to it will be given):
> > >> >
> > >> > java.lang.IllegalArgumentException: URL does not exist:
> > >> > archive:se-examples.jar/META-INF/persistence.xml
> > >> >
> > >> > at
> > >> >
> > >> >
> > >>
> >
> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)
> > >> >
> > >> > at
> > >> >
> > >> >
> > >>
> >
> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)
> > >> >
> > >> > at
> > >> >
> > >> >
> > >>
> >
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)
> > >> >
> > >> > at
> > >> >
> > >> >
> > >>
> >
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)
> > >> >
> > >> > at
> > >> >
> > >> >
> > >>
> >
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)
> > >> >
> > >> > at
> > >> >
> > >> >
> > >>
> >
> org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:73)
> > >> >
> > >> > (full stack available at [2], test.log). It seems like the
> > >> > RepositoryExtension is picking up on my persistence.xml and
> > aggressively
> > >> > trying to parse them (at this point, I don't have any @Repository's
> > >> defined
> > >> > in my app). For some reason it cannot parse this URL but it does
> seem
> > >> to
> > >> > pick up the persistence.xml from target/classes/META-INF so it does
> > >> > eventually parse it. To work around this, I wrapped
> > >> > DescriptorReader.readAllFromClassPath's result.add with an exception
> > >> check.
> > >> > I figure if it can't read the descriptor, no reason to make the
> whole
> > >> app
> > >> > die. What do you think?
> > >> >
> > >> > Second issue, after fixing this one, was that
> AbstractEntityRepository
> > >> was
> > >> > being picked up as a @Repository and erroring out saying that
> there's
> > no
> > >> > entity for it. This one I wasn't expecting. To fix it, in
> > >> > RepsitoryComponents, I added an explicit check if it was the base
> > >> class, if
> > >> > it was return null rather than exception and check for null in the
> add
> > >> > method. This also fixed things and the tests started running fine.
> > >> This
> > >> > fix seems more hacky, and I'm wondering if I'm just doing something
> > >> wrong
> > >> > to make this class be picked up.
> > >> >
> > >> > You can see the summary of changes in the gist's patch.txt.
> > >> >
> > >> > John
> > >> >
> > >> >
> > >> > [1]: https://github.com/johnament/restful-and-beyond-tut2184
> > >> > [2]: https://gist.github.com/johnament/d4a55ce7251062ee0b85
> > >> >
> > >>
> > >
> > >
> >
>
Re: Data Module - some issues in SE/Maven Tests
Posted by "John D. Ament" <jo...@gmail.com>.
For the first issue, looks like if I just exclude the file from the archive
my problems are resolved. I'll go with that for now. For some reason,
this issue doesn't pop up using META-INF/apache-deltaspike.properties but
using the same approach doesn't fix it.
For the second, the easiest fix I have (that's also a bit clean) is to
simply veto the class within the repository extension. If there are no
objections, I'll commit that change this morning. Right now I cannot
exclude the API from the uber jar.
John
On Tue, Sep 2, 2014 at 3:17 AM, Thomas Hug <th...@gmail.com> wrote:
> Instead of patching the second one, for an uber-jar it might also be a
> valid recommendation to exclude the class over the beans.xml.
>
>
> On Tue, Sep 2, 2014 at 8:12 AM, Thomas Hug <th...@gmail.com> wrote:
>
> > Hi John
> >
> > First one should - as Romain mentioned - usually not be a problem. Might
> > still be worth adding the exception check as I've run into problems on
> WLS
> > with this particular approach. We lose the ability to deal with entities
> > defined in orm.xml's but that's probably still better than crashing :-)
> >
> > The second one comes from creating an uber-jar - the api module doesn't
> > have a beans.xml. Can't think of a different approach to get rid of this
> > one...
> >
> >
> > On Tue, Sep 2, 2014 at 6:54 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> >> Hi
> >>
> >> Archive url issue is due to the arquillian adapter (so no problem for
> data
> >> module)
> >>
> >> Can't the other one be fixed using @Typed?
> >> Le 1 sept. 2014 21:41, "John D. Ament" <jo...@gmail.com> a
> écrit :
> >>
> >> > Hi All!
> >> >
> >> > I've hit a couple of issues with the Data Module and wanted to know if
> >> it
> >> > was worth fixing.
> >> >
> >> > First, my sample app can be found at [1] (note you'll need JDK8 to
> run)
> >> and
> >> > you can run the test JPATest to see the results, using
> >> >
> >> > mvn -Dtest=JPATest -Ddeltaspike.version=1.0.2
> >> >
> >> > First issue you'll note is that the following output (or something
> >> similar
> >> > to it will be given):
> >> >
> >> > java.lang.IllegalArgumentException: URL does not exist:
> >> > archive:se-examples.jar/META-INF/persistence.xml
> >> >
> >> > at
> >> >
> >> >
> >>
> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)
> >> >
> >> > at
> >> >
> >> >
> >>
> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)
> >> >
> >> > at
> >> >
> >> >
> >>
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)
> >> >
> >> > at
> >> >
> >> >
> >>
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)
> >> >
> >> > at
> >> >
> >> >
> >>
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)
> >> >
> >> > at
> >> >
> >> >
> >>
> org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:73)
> >> >
> >> > (full stack available at [2], test.log). It seems like the
> >> > RepositoryExtension is picking up on my persistence.xml and
> aggressively
> >> > trying to parse them (at this point, I don't have any @Repository's
> >> defined
> >> > in my app). For some reason it cannot parse this URL but it does seem
> >> to
> >> > pick up the persistence.xml from target/classes/META-INF so it does
> >> > eventually parse it. To work around this, I wrapped
> >> > DescriptorReader.readAllFromClassPath's result.add with an exception
> >> check.
> >> > I figure if it can't read the descriptor, no reason to make the whole
> >> app
> >> > die. What do you think?
> >> >
> >> > Second issue, after fixing this one, was that AbstractEntityRepository
> >> was
> >> > being picked up as a @Repository and erroring out saying that there's
> no
> >> > entity for it. This one I wasn't expecting. To fix it, in
> >> > RepsitoryComponents, I added an explicit check if it was the base
> >> class, if
> >> > it was return null rather than exception and check for null in the add
> >> > method. This also fixed things and the tests started running fine.
> >> This
> >> > fix seems more hacky, and I'm wondering if I'm just doing something
> >> wrong
> >> > to make this class be picked up.
> >> >
> >> > You can see the summary of changes in the gist's patch.txt.
> >> >
> >> > John
> >> >
> >> >
> >> > [1]: https://github.com/johnament/restful-and-beyond-tut2184
> >> > [2]: https://gist.github.com/johnament/d4a55ce7251062ee0b85
> >> >
> >>
> >
> >
>
Re: Data Module - some issues in SE/Maven Tests
Posted by Thomas Hug <th...@gmail.com>.
Instead of patching the second one, for an uber-jar it might also be a
valid recommendation to exclude the class over the beans.xml.
On Tue, Sep 2, 2014 at 8:12 AM, Thomas Hug <th...@gmail.com> wrote:
> Hi John
>
> First one should - as Romain mentioned - usually not be a problem. Might
> still be worth adding the exception check as I've run into problems on WLS
> with this particular approach. We lose the ability to deal with entities
> defined in orm.xml's but that's probably still better than crashing :-)
>
> The second one comes from creating an uber-jar - the api module doesn't
> have a beans.xml. Can't think of a different approach to get rid of this
> one...
>
>
> On Tue, Sep 2, 2014 at 6:54 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Hi
>>
>> Archive url issue is due to the arquillian adapter (so no problem for data
>> module)
>>
>> Can't the other one be fixed using @Typed?
>> Le 1 sept. 2014 21:41, "John D. Ament" <jo...@gmail.com> a écrit :
>>
>> > Hi All!
>> >
>> > I've hit a couple of issues with the Data Module and wanted to know if
>> it
>> > was worth fixing.
>> >
>> > First, my sample app can be found at [1] (note you'll need JDK8 to run)
>> and
>> > you can run the test JPATest to see the results, using
>> >
>> > mvn -Dtest=JPATest -Ddeltaspike.version=1.0.2
>> >
>> > First issue you'll note is that the following output (or something
>> similar
>> > to it will be given):
>> >
>> > java.lang.IllegalArgumentException: URL does not exist:
>> > archive:se-examples.jar/META-INF/persistence.xml
>> >
>> > at
>> >
>> >
>> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)
>> >
>> > at
>> >
>> >
>> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)
>> >
>> > at
>> >
>> >
>> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)
>> >
>> > at
>> >
>> >
>> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)
>> >
>> > at
>> >
>> >
>> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)
>> >
>> > at
>> >
>> >
>> org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:73)
>> >
>> > (full stack available at [2], test.log). It seems like the
>> > RepositoryExtension is picking up on my persistence.xml and aggressively
>> > trying to parse them (at this point, I don't have any @Repository's
>> defined
>> > in my app). For some reason it cannot parse this URL but it does seem
>> to
>> > pick up the persistence.xml from target/classes/META-INF so it does
>> > eventually parse it. To work around this, I wrapped
>> > DescriptorReader.readAllFromClassPath's result.add with an exception
>> check.
>> > I figure if it can't read the descriptor, no reason to make the whole
>> app
>> > die. What do you think?
>> >
>> > Second issue, after fixing this one, was that AbstractEntityRepository
>> was
>> > being picked up as a @Repository and erroring out saying that there's no
>> > entity for it. This one I wasn't expecting. To fix it, in
>> > RepsitoryComponents, I added an explicit check if it was the base
>> class, if
>> > it was return null rather than exception and check for null in the add
>> > method. This also fixed things and the tests started running fine.
>> This
>> > fix seems more hacky, and I'm wondering if I'm just doing something
>> wrong
>> > to make this class be picked up.
>> >
>> > You can see the summary of changes in the gist's patch.txt.
>> >
>> > John
>> >
>> >
>> > [1]: https://github.com/johnament/restful-and-beyond-tut2184
>> > [2]: https://gist.github.com/johnament/d4a55ce7251062ee0b85
>> >
>>
>
>
Re: Data Module - some issues in SE/Maven Tests
Posted by Thomas Hug <th...@gmail.com>.
Hi John
First one should - as Romain mentioned - usually not be a problem. Might
still be worth adding the exception check as I've run into problems on WLS
with this particular approach. We lose the ability to deal with entities
defined in orm.xml's but that's probably still better than crashing :-)
The second one comes from creating an uber-jar - the api module doesn't
have a beans.xml. Can't think of a different approach to get rid of this
one...
On Tue, Sep 2, 2014 at 6:54 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hi
>
> Archive url issue is due to the arquillian adapter (so no problem for data
> module)
>
> Can't the other one be fixed using @Typed?
> Le 1 sept. 2014 21:41, "John D. Ament" <jo...@gmail.com> a écrit :
>
> > Hi All!
> >
> > I've hit a couple of issues with the Data Module and wanted to know if it
> > was worth fixing.
> >
> > First, my sample app can be found at [1] (note you'll need JDK8 to run)
> and
> > you can run the test JPATest to see the results, using
> >
> > mvn -Dtest=JPATest -Ddeltaspike.version=1.0.2
> >
> > First issue you'll note is that the following output (or something
> similar
> > to it will be given):
> >
> > java.lang.IllegalArgumentException: URL does not exist:
> > archive:se-examples.jar/META-INF/persistence.xml
> >
> > at
> >
> >
> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)
> >
> > at
> >
> >
> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)
> >
> > at
> >
> >
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)
> >
> > at
> >
> >
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)
> >
> > at
> >
> >
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)
> >
> > at
> >
> >
> org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:73)
> >
> > (full stack available at [2], test.log). It seems like the
> > RepositoryExtension is picking up on my persistence.xml and aggressively
> > trying to parse them (at this point, I don't have any @Repository's
> defined
> > in my app). For some reason it cannot parse this URL but it does seem to
> > pick up the persistence.xml from target/classes/META-INF so it does
> > eventually parse it. To work around this, I wrapped
> > DescriptorReader.readAllFromClassPath's result.add with an exception
> check.
> > I figure if it can't read the descriptor, no reason to make the whole
> app
> > die. What do you think?
> >
> > Second issue, after fixing this one, was that AbstractEntityRepository
> was
> > being picked up as a @Repository and erroring out saying that there's no
> > entity for it. This one I wasn't expecting. To fix it, in
> > RepsitoryComponents, I added an explicit check if it was the base class,
> if
> > it was return null rather than exception and check for null in the add
> > method. This also fixed things and the tests started running fine. This
> > fix seems more hacky, and I'm wondering if I'm just doing something wrong
> > to make this class be picked up.
> >
> > You can see the summary of changes in the gist's patch.txt.
> >
> > John
> >
> >
> > [1]: https://github.com/johnament/restful-and-beyond-tut2184
> > [2]: https://gist.github.com/johnament/d4a55ce7251062ee0b85
> >
>