JBossDeveloper

"max.andersen@jboss.com" wrote:
emmanuel - Isn't this way of starting (with PersistenceUnitInfo) different from what happens when hibernate scans for entities "on its own" in j2se scenario ?

"adrian@jboss.org" wrote:

"max.andersen@jboss.com" wrote:
...but why is this concern of where to get resources from leaked out via the urls passed down to hibernate via the urls it gets ? Can't we avoid that somehow?

I don't understand your question? You need some identifier.
JavaEE generally uses URLs (but they are not navigable
there is no generic getChildURLs()).

Currently hibernate gets the top level url and barfs because it only knows
how to navigate file:, jar:
There is no way to make it understand anything else.

"adrian@jboss.org" wrote:
We're discussing how to go beyond these for reasons of optimization
and ease of use/development.

If you want to avoid the problem then we say you always have to package
as a jar or exploded archive and we will always scan everything (multiple times :-)

"epbernard" wrote:

Correct, I think Max's train of thoughts goes down to: could the VFS implement openStream() is such a way that it would look like a JAR stream? When I wrote the visitor, this was really the "common interface" I expected URLs I interact with to implement.

The thing that I missed initially and that Emmanuel pointed out was the the spi for PersistentunitInfo done in fact imply that we can safely assume that returned urls are either jar files or directories.

http://java.sun.com/javaee/5/docs/api/javax/persistence/spi/PersistenceUnitInfo.html#getJarFileUrls()
http://java.sun.com/javaee/5/docs/api/javax/persistence/spi/PersistenceUnitInfo.html#getPersistenceUnitRootUrl()

So i think this is more than just a question of working vs optimized. We also need to consider other JPA providers being plugged into JBoss AS right? You'd have to assume they would take this "implied spec" and run with it as well...

"steve.ebersole@jboss.com" wrote:

So i think this is more than just a question of working vs optimized. We also need to consider other JPA providers being plugged into JBoss AS right? You'd have to assume they would take this "implied spec" and run with it as well...

"getJarFileUrls javadoc" wrote:

List<URL> getJarFileUrls()

Returns a list of URLs for the jar files or exploded jar file directories that the persistence provider must examine for managed classes of the persistence unit. Each URL corresponds to a named element in the persistence.xml file. A URL will either be a file: URL referring to a jar file or referring to a directory that contains an exploded jar file, or some other URL from which an InputStream in jar format can be obtained.

"scott.stark@jboss.org" wrote:

"epbernard" wrote:

Correct, I think Max's train of thoughts goes down to: could the VFS implement openStream() is such a way that it would look like a JAR stream? When I wrote the visitor, this was really the "common interface" I expected URLs I interact with to implement.

No, because this requires every protocol handler to conform to this contract.

How does the PersistenceUnitInfo.getJarFileUrls() work with other vendors when the deployment is unpacked?

"epbernard" wrote:

And now there is a 4th kind with VFS which is also how Eclipse bundle work. some opaque URL that cannot be read without proprietary API calls

note seam will have the exact same issue since it also tries to scan the classpath and wont understand any vfsfile urls....

"max.andersen@jboss.com" wrote:
note seam will have the exact same issue since it also tries to scan the classpath and wont understand any vfsfile urls....

Yes, we need to do what Adrian and Steve were discussing for Hibernate for Seam too. Ales and I are going to look at this next week.

I've changed the way EJB 3 submits the persistence root url to Hibernate.
See http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas?view=rev&revision=67653.

It works (and should also work for Toplink), but I don't like it.

I would rather see the spec bend to accept any jar url. So jar:mywar.war!/WEB-INF/classes/ becomes a valid input. (I think this works for Toplink, it does not work for Hibernate.)

Carlo,
I think the URL you describe should be accepted by HEM (as it is a spec compliant root URL: chapter 6.2 of ejb3.0-persistente).
I've opened a JIRA issue
http://opensource.atlassian.com/projects/hibernate/browse/EJB-326
If you remember how it failed, please comment on the bug report.

The jarjar handler doesn't fully work, for now I'm rolling back that feature.
I'll wait for EJB-326.

"wolfc" wrote:
The jarjar handler doesn't fully work, for now I'm rolling back that feature.

no, Hibernate doesn't speak jarjar :)