November 2007 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: metadata simplification

by anil.saldhana＠jboss.com

Not a burning issue for me. Thanks for the update, Scott. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109104#4109104 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109104

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - JBossEjbParsingDeployer split up

by scott.stark＠jboss.org

JBossMetaData processing is now split among: - JBossEjbParsingDeployer : parse jboss.xml and standardjboss.xml to output raw JBossMetaData under attachment names "org.jboss.metadata.ejb.jboss.JBossMetaData" and "standardjboss.xml" - AnnotationMetaDataDeployer : scans deployments with existing non-metadata-complete metadata and produces a spec metadata pojo model attachment. The EjbJarMetaData model is output as "annotated.org.jboss.metadata.ejb.spec.EjbJarMetaData" - MergedJBossMetaDataDeployer : combines "org.jboss.metadata.ejb.spec.EjbJarMetaData", "org.jboss.metadata.ejb.jboss.JBossMetaData" and "annotated.org.jboss.metadata.ejb.spec.EjbJarMetaData" attachments to to replace the "org.jboss.metadata.ejb.jboss.JBossMetaData" with the combined metadata view. - StandardJBossMetaDataDeployer : combines "org.jboss.metadata.ejb.jboss.JBossMetaData" and "standardjboss.xml" attachments with a JBossMetaDataWrapper to replace the "org.jboss.metadata.ejb.jboss.JBossMetaData" with the wrapped view. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109102#4109102 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109102

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Embbedded - broken - some fixes - still not working

by scott.stark＠jboss.org

"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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109097#4109097 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109097

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Embbedded - broken - some fixes - still not working

by epbernard

"scott.stark(a)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 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109090#4109090 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109090

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: metadata simplification

by scott.stark＠jboss.org

We are still missing a merging deployer. I'm working on a MergedJBossMetaDataDeployer to combine the ejb-jar, jboss, and annotation views. It should also deal with ear level values that affect the resulting JBossMetaData object. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109087#4109087 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109087

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: metadata simplification

by anil.saldhana＠jboss.com

I have a case where the ear contains a jboss-app.xml but misses a jboss.xml. So when I ask the JBossAssemblyDescritorMetaData for the securityroles configured, it is returning null because the "SecurityRoleMetaData" is not merged. It is available in the ear metadata. What needs to be done here? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109084#4109084 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109084

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Embbedded - broken - some fixes - still not working

by scott.stark＠jboss.org

"steve.ebersole(a)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 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109082#4109082 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109082

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Embbedded - broken - some fixes - still not working

by steve.ebersole＠jboss.com

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/PersistenceUn... http://java.sun.com/javaee/5/docs/api/javax/persistence/spi/PersistenceUn... 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... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109078#4109078 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109078

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Embbedded - broken - some fixes - still not working

by scott.stark＠jboss.org

"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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109075#4109075 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109075

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Embbedded - broken - some fixes - still not working

by epbernard

"adrian(a)jboss.org" wrote : "max.andersen(a)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(a)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 :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109071#4109071 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109071

16 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2007