-
15. Re: Embbedded - broken - some fixes - still not working
epbernard Nov 29, 2007 4:03 PM (in response to adrian.brock)"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 ?
Not anymore, the scanning process has been mutualized now (latest beta). -
16. Re: Embbedded - broken - some fixes - still not working
epbernard Nov 29, 2007 4:19 PM (in response to adrian.brock)"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.
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."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 :-)
I understand that scanning multiple time is stupid (though some hard figures would be better :o) ).
But how does the VFS provide some ease of use / dev? I can't find a clear benefit for Joe Pack (though I imagine Max like the concept when integrating into Eclipse).
Exposing an interface is possible but is a decent amount of work. I would like to just the urgency / necessity / usefulness before going that road :) -
17. Re: Embbedded - broken - some fixes - still not working
starksm64 Nov 29, 2007 4:33 PM (in response to adrian.brock)"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?
For a url pointing to an actual jar, JarInputStream(vf.openStream) should work regardless of the protocol. -
18. Re: Embbedded - broken - some fixes - still not working
sebersole Nov 29, 2007 4:47 PM (in response to adrian.brock)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... -
19. Re: Embbedded - broken - some fixes - still not working
starksm64 Nov 29, 2007 5:02 PM (in response to adrian.brock)"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.
Yes, this will require an adapter to provide a file: URL for an underlying vfs* URL when the jar root is exploded. The vfs* URL input stream should meet the non-exploded requirement case. -
20. Re: Embbedded - broken - some fixes - still not working
epbernard Nov 29, 2007 5:38 PM (in response to adrian.brock)"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?
There are essentially 3 kinds of app servers out there:
- the one that provide a URL pointing to a JAR
- the one that provide a URL pointing to a file directory
- the one that provide a URL whose protocol name is funny but indeed nothing more that a jar protocol.
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 -
21. Re: Embbedded - broken - some fixes - still not working
starksm64 Nov 29, 2007 6:05 PM (in response to adrian.brock)"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
According to the PersistenceUnitInfo.getJarFileUrls() javadoc, all that is required to provide integration will be to have the vfs* URL corresponding to an unpacked jar be usable via our file: protocol handler so that a file: URL can be returned. This integration is part of the PersistenceUnitInfo implementation, not the VFS. The org.jboss.ejb3.entity.PersistenceUnitInfoImpl along with the URLStreamHandler implementation we install for the file: protocol need to be updated to support this. -
22. Re: Embbedded - broken - some fixes - still not working
maxandersen Nov 30, 2007 1:40 PM (in response to adrian.brock)note seam will have the exact same issue since it also tries to scan the classpath and wont understand any vfsfile urls....
-
23. Re: Embbedded - broken - some fixes - still not working
ccrouch Nov 30, 2007 2:29 PM (in response to adrian.brock)"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....
http://jira.jboss.com/jira/browse/JBSEAM-1103 -
24. Re: Embbedded - broken - some fixes - still not working
pmuir Dec 1, 2007 2:06 PM (in response to adrian.brock)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.
-
25. Re: Embbedded - broken - some fixes - still not working
wolfc Dec 3, 2007 5:01 AM (in response to adrian.brock)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.) -
26. Re: Embbedded - broken - some fixes - still not working
epbernard Dec 3, 2007 10:24 AM (in response to adrian.brock)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. -
27. Re: Embbedded - broken - some fixes - still not working
wolfc Dec 4, 2007 5:05 AM (in response to adrian.brock)The jarjar handler doesn't fully work, for now I'm rolling back that feature.
I'll wait for EJB-326. -
28. Re: Embbedded - broken - some fixes - still not working
pmuir Dec 4, 2007 7:33 PM (in response to adrian.brock)"wolfc" wrote:
The jarjar handler doesn't fully work, for now I'm rolling back that feature.
Why? It's enough to make Hibernate work with Embedded - can you not roll it back once EJB-326 is fixed?
Otherwise I'm very close to having a working embedded on trunk - just a jms issue to work out. -
29. Re: Embbedded - broken - some fixes - still not working
epbernard Dec 4, 2007 7:57 PM (in response to adrian.brock)no, Hibernate doesn't speak jarjar :)