[Design of JBoss Web Services] - JBossWS brings Metro/CXF but in waht version?
by thomas.diesler@jboss.com
Folks,
we are about to release jbossws-2.0.3.GA on 1-Feb-2008. So far we communicated that jbossws-2.1 will come with plugablility for Metro and CXF and the release criteria was that all three stacks pass a common jax-ws testsuite that is defined in our framework module.
| The JBossWS project is organised like this
|
| +~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~+ +~~~~+
| Target Container: | AS-5.0 | | AS-4.2 | | AS-4.0 | | |
| +~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~+ | |
| +~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~+ | |
| Container Integration: | jbossws-jboss50 | | jbossws-jboss42 | | jbossws-jboss40 | | |
| +~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~+ | |
| +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | |
| WS Framework: | jbossws-spi, jbossws-framework, jbossws-common | | |
| +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | |
| +~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~+ | |
| WS Stack Integration: | jbossws-native | | jbossws-metro | | jbossws-cxf | | |
| +~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~+ | |
| +~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~+ | |
| WS Stack: | jbossws-core | | Sun Metro | | Apache CXF | | |
| +~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~+ | |
| WS-* Extensions: +~+ +~+ +~+ +~+ +~+ +~+ | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| +~+ +~+ +~+ +~+ +~+ +~+ +~~~~+
| JAXWS Testsuite
|
For both stacks Metro and CXF the testsuite passes except a few minor issues that we currently cannot make progress because of some cooperation details with Sun/Apache that would need to be resolved.
In short, I would like to release jbossws-2.1 (maybe called jbossws-3.0) for JBossWorld and anounce that we have pluggable stacks available for public consumtion.
What I am not sure about however is the versioning scheme of our upcomming releases. The version number appears in
* Download file (i.e. jbossws-native-2.0.2.GA)
* JIRA version (i.e. roadmap, changelog)
* SVN tag
* Binary repository
All of the above follow the same version scheme.
Given that all stacks have an independent live cycle and are essentially standalone projects (as reflected in our SVN structure) I find it difficult to come up with an adequate versioning scheme
| * jbossws-native-2.1.0
| * jbossws-metro-2.1.0
| * jbossws-cxf-2.1.0
|
| |
| | poses the question where is jbossws-metro-1.0.0. Also eight weeks later we might not have changes in all three stacks - do we redundantly release all three stacks or only the stacks that have actually changed?
| |
| |
| | | * jbossws-native-2.0.3
| | | * jbossws-metro-1.0.0
| | | * jbossws-cxf-1.0.0
| | |
| | | |
| | | | Misses the point that a new area (pluggable stacks) has begun and it would make little sense to talk about jbossws-2.1 if there is no download and no jira roadmap for it.
| | | |
| | | |
| | | | | * jbossws-2.1.0-native-2.0.3
| | | | | * jbossws-2.1.0-metro-1.0.0
| | | | | * jbossws-2.1.0-cxf-1.0.0
| | | | |
| | | | | |
| | | | | | Is another possibility that would transport the idea of a fast moving jbossws framework project (8 week release cycle) with independent release cycles for the containing stacks.
| | | | | |
| | | | | | Generally, I would like to stick to the jbossws brand with a single version, which would get lost if we talk about three independent projects.
| | | | | |
| | | | | | I am interested to hear your feedback
| | | | | |
| | | | | | cheers
| | | | | |
| | | | | |
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119056#4119056
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119056
18 years, 2 months
[Design the new POJO MicroContainer] - Re: Moving out of the UnifiedClassloaders
by alesj
"adrian(a)jboss.org" wrote :
| What is getURLsFromClassLoader()?
| The new Classloader is not a URLClassLoader so there is no getURLs().
|
In our case the resourceName != null, so that part was obviously not used. :-)
But I still don't see where the non vfs URLs came from, or the duplicates.
"adrian(a)jboss.org" wrote :
| Looks a wrong/bad assumption to me. :-)
|
A deprecated assumption. ;-)
"adrian(a)jboss.org" wrote :
| This looks like the same issue as was raised for Hibernate
| in the context of the embedded server.
|
Only in embedded or the whole AS5?
Is this about the Hibernate core or AS's Hibernate-int?
I already did a simple VFS introduction into Hibernate class, but that also needs fixing, since it also assumes URLCL.
"adrian(a)jboss.org" wrote :
| The way to scan/visit the deployment structure needs to be pluggable.
| You can't just assume it is a jar or file structure if we want to handle abitrary
| virtual files.
|
I was able to do minor 'hacks' for beta3 to make it work.
But I agree, and so does Pete, this needs rewriting into pluggable impl.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119052#4119052
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119052
18 years, 2 months