I did need to rebuild the latest snapshot.
For some reason the RecordProcessor.clone() API wasn't there.
Looks like the previous build was broken or the commit message wrong.
/Heiko
cxf shows regression in trunk that relates to the record management:
Caused by: java.lang.NullPointerException
at org.jboss.wsf.framework.deployment.EndpointRecordProcessorDeploymentAspect.create(EndpointRecordProcessorDeploymentAspect.java:62)
at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:115)
at org.jboss.wsf.container.jboss42.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:97)
at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:90)
Can someone take a look at this?
/Heiko
Hi,
can anyone who did changes to the SPI verify that they
are backwards compatible? This means only additions to the SPI
are ok. If you remove, rename or modify existing signatures you need to
deprecate for the next release and clearly communicate it so that we can
do an according release number in a subsequent release.
Thanks, Heiko
anonymous wrote :
| Question: if an end-user wishes to use the CXF flavor of JBossWS, is it 100% compatible with my current JAX-RPC & JAX-WS web services running in their current AS? No changes required, just a drop in replacement?
|
No, neither CXF nor Metro support JAX-RPC. You can expect JAX-WS functionality that is covered by the jbossws framework testsuite (except documented errata in the release notes) to work.
Also please note, that only jbossws-native is verified against the TCK. This is also the the only stack that is officially supported for customers.
What we are introducing here is a community release only that is not available in any of the platforms. A switch to either CXF or Metro as our default platform stack is possible in the future, but will require more work not only from a tech perspective.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120177#4120177
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120177
"thomas.diesler(a)jboss.com" wrote :
| 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.
|
I wouldn't do that. Let us try release all three stacks support simultaneously. We'll see how time expensive it will be and later we can do other strategic decisions.
"thomas.diesler(a)jboss.com" wrote :
| I would like to stick to the jbossws brand with a single version
|
+1
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119514#4119514
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119514
"thomas.diesler(a)jboss.com" wrote : ... and if only native changes we would have redundant releases?
|
| * jbossws-2.1.1-native-2.0.4
| * jbossws-2.1.1-metro-1.0.0
| * jbossws-2.1.1-cxf-1.0.0
I wouldn't call it redundant release. AFAIK each JBossWS release gets tested on at least one new tagged branch (trunk) and according to informatics axiom What is not tested it doesn't work it's always better to test and release it although it seems like redundant release. But in fact it isn't.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119509#4119509
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119509