[Design of EJB 3.0] - Persistence metadata change
by alesj
I've changed the usage of PersistenceMetaData in Ejb3/core.
It now uses classes from our metadata project - instead of some wrapper hack with hibernate.
Chatting with Carlo, we didn't seem to find any relevant tests that would verify this change.
I also made changes to AS5_trunk, to use this, but I haven't commited yet - waiting for new ejb3 release that will include this latest changes.
This will break AS5_trunk for a while, so let me know when you plan to do the update/switch, and I'll commit my changes immediately after that - or even better, I'll do the ejb3 switch in component-matrix.
For a simple test, to see if things at least work, I ran ALR's service-test.jar.
Things were picked up, parsed, deployed as expected (OK, there was some HEM problems with VFS, but not relevant to this change).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153494#4153494
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153494
18 years
[Design the new POJO MicroContainer] - VFS and directory handling
by alesj
Another VFS issue I stumbled upon.
I guess this was there for quite some time, we just never deployed things in this way to see it. :-)
The issue is that when I deploy an artifact that contains persistence.xml as exploded jar, this is what I get:
| 2008-05-23 18:08:35,578 DEBUG [org.hibernate.ejb.packaging.AbstractJarVisitor] (HDScanner) Searching mapped entities in jar/par: vfsfile:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.CR1/server/default/deploy/service-test.jar/
| 2008-05-23 18:08:35,578 WARN [org.hibernate.ejb.packaging.InputStreamZippedJarVisitor] (HDScanner) Unable to find file (ignored): vfsfile:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.CR1/server/default/deploy/service-test.jar/
| java.io.FileNotFoundException: C:\projects\jboss5\trunk\build\output\jboss-5.0.0.CR1\server\default\deploy\service-test.jar (Access is denied)
| at java.io.FileInputStream.open(Native Method)
| at java.io.FileInputStream.<init>(FileInputStream.java:106)
| at org.jboss.net.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:106)
| at java.net.URL.openStream(URL.java:1007)
| at org.jboss.virtual.plugins.context.AbstractURLHandler.openStream(AbstractURLHandler.java:131)
| at org.jboss.virtual.VirtualFile.openStream(VirtualFile.java:216)
| at org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getInputStream(VirtualFileURLConnection.java:117)
| at java.net.URL.openStream(URL.java:1007)
| at org.hibernate.ejb.packaging.InputStreamZippedJarVisitor.doProcessElements(InputStreamZippedJarVisitor.java:38)
| at org.hibernate.ejb.packaging.AbstractJarVisitor.getMatchingEntries(AbstractJarVisitor.java:139)
| at org.hibernate.ejb.Ejb3Configuration.addScannedEntries(Ejb3Configuration.java:287)
| at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:614)
| at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:360)
| at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:131)
| at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:280)
Response from HEM team:
"emmanuel" wrote :
| You guys do not expose a directory as a directory.
| So the alternative is to go read the InputStream. I don't see why VFS could not expose a directory as an InputStream (just like a zip file does). What else can I "assume"?
|
| The proper solution is a real integration with VFS but I lack time at the moment.
|
No to blame them.
But I guess we're gonna see a lot of this eventaully.
So, this needs more generic solution, which doesn't expect all external libs to adopt VFS.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153493#4153493
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153493
18 years