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 <[email protected]> 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 <[email protected]> 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 <
> [email protected]>
> > 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" <[email protected]> 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
> >> >
> >>
> >
> >
>

Reply via email to