[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, 10 months
[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, 10 months
[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, 10 months
[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, 10 months