Re: JBMETA-44 - jaxws processing
by Alessio Soldano
Hi Emanuel,
> Hi,
>
> so concerning the metadata processing of WS Annotations.
> The main functionality should now be in metadata trunk - so i think it
> would be good if you can take a look :)
>
>
> The main package for the @WebServiceRef and @HandlerChain tests is:
> https://svn.jboss.org/repos/jbossas/projects/metadata/trunk/src/test/java...
>
>
>
> - AnnotationClientUnitTestCase: tests basically the @WebServiceRefs.
> - HandlerChainsTestCase: tests the @HandlerChains, which are only
> processed together with a @WebServiceRef.
>
> Basically this file shows what jboss metadata can handle atm.
> https://svn.jboss.org/repos/jbossas/projects/metadata/trunk/src/test/java...
>
>
>
> If you give your ok, i can close the jira task - maybe you can also
> provide a testcase to validate that...
>
> Thanks;
> Emanuel
Thank you, I checked you test cases and think they're OK. I think you
can close the jira task.
Regarding the tests, webserviceref testcases are already covered by the
jbossws testsuite and many of them are currently excluded (see
http://jira.jboss.org/jira/browse/JBWS-2171 for instance). As soon as we
update the dependencies to use the new metadata we'll have them back.
Tomorrow I'll try this and add a test case using both @WebServiceRef and
@HandlerChain.
Cheers
Alessio
15 years, 11 months
[Design of JBoss Web Services] - Re: JBMETA-44, ws annotation processing for references
by alessio.soldano＠jboss.com
"emuckenhuber" wrote : Okay - i have a prototype working for this.. just need to check again - maybe you can validate it then to make sure that i did not miss anything.
Sure
anonymous wrote : But ServiceReferenceHandlerMetaData cannot be defined over annotations just via the xml descriptors - right?
Yes, I can confirm this.
The ServiceReferenceHandlerMetaData (which is mapped to the JBossWS SPI UnifiedHandlerMetaData) is for JAX-RPC handlers declared in the standard J2EE1.4 descriptor.
The ServiceReferenceHandlerChainMetaData (which is mapped to the JBossWS SPI UnifiedHandlerChainMetaData) is for JAX-WS handlers declared in the standard JavaEE5 descriptor.
We then have the handlerChain attribute of the JBossWS SPI UnifiedServiceRefMetaData which is for the <handler-chain> element in the JBoss JavaEE5 descriptor or the file attribute of @HandlerChain annotation.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158998#4158998
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158998
15 years, 11 months
JBoss-JAXR in JBoss AS 5
by Darran Lofthouse
I just need to quickly check if there are any changes planned for
JBoss-JAXR to be included in JBoss 5?
I am currently working on some issues needed in the JBoss 4.2.x branch
and EAP branches: -
http://jira.jboss.com/jira/browse/JAXR
The release I am planning is JBoss JAXR 1.2.0.SP1, looking at JBoss 5 it
is also using JBoss JAXR 1.2.0.GA so will probably need an upgrade to
this new SP release.
Regards,
Darran Lofthouse.
15 years, 11 months
Re: JBossWS 3.0.2 Release Integration with AS Trunk
by Richard Opalka
See inlined comments below:
Dimitris Andreadis wrote:
> We will release CR1 as soon as we correct the TCK regressions and the
> JIRA blockers. It
> could be this week or the next one.
Great. Of course we will be very careful to don't break the WS staff
with upgrade.
>
> How you know that the new JBossWS passes TCK, or it will pass the TCK
> once the EJB3/VFS
> regressio are fixed?
We have tests-excludes-jboss501.txt file for AS trunk which holds issues
that needs to be fixed in JBAS or EJBTHREE module.
If number of AS and EJBTHREE issues in tests-excludes-jboss501.txt file
is less or equal to tests-excludes-jboss500.txt (excludes file for AS 5
Beta 4)
we know and are pretty sure it will pass TCK with high presumability.
>
> Maybe you guys should give a hand diagnosing the WS/tck failures.
>
> Richard Opalka wrote:
>> Hi Dimitris,
>>
>> we i.e. JBossWS team are releasing JBossWS 3.0.2 these days.
>> We're going to create the integration branch soon, update that branch
>> to include up2date JBossWS release in the AS codebase and then
>> we're going to merge it back to trunk.
>> My question is whether we can do it these days or you would
>> like to postpone it little bit. What's the current schedule for AS CR1?
>>
>> Richard
>>
>
--
B.Sc. Richard Opalka
Senior Software Engineer
JBoss, a division of Red Hat
Mobile: +420 731 186 942
Mail: ropalka(a)redhat.com
15 years, 11 months
Re: JBossWS 3.0.3 jira issues and stack comparison
by Richard Opalka
I'll try summarize:
WSA on CXF:
CXF endpoint needs extra CXF DD to be included in endpoint archive.
This CXF DD includes WSA feature definition.
CXF client needs extra config too to be used to configure CXF client.
This client config specifies WSA feature is in place.
WSA on Metro:
Programmers just need to specify <UsingAddressing/> WSDL extensibility
element in contract and both Metro runtime
and client are able to recognize this and act accordingly. Thus on
Metro it's completely contract driven behavior.
WSRM and WSP on CXF:
CXF endpoint needs extra CXF DD to be included in endpoint archive.
This CXF DD includes WSPolicy referencing WSRM policy definition.
CXF client needs extra config too to be used to confgure CXF client.
This client config specifies CXF features to be used (e.g. WSRM, WSP, WSA)
WSRM and WSP on Metro
Programmers just need to specify WSP extensibility element including
both addressing and RM assertions in contract WSDL + provide
wsit-ENDPOINT.xml file to activate that features.
Metro client doesn't need extra configuration. It's again contract
driven. But wsit-rt.jar must be on client classpath to let WSRM and
other Metro WS-* features be functional on client side.
To recapitulate:
CXF is just configuration driven.
Metro is fully contract driven.
The question is: What's better approach?. Both of them have their
pros/cons :)
Richard
Alessio Soldano wrote:
> Hi Richard,
>>> Finally, some thoughts I came up to rearding the stack comparison
>>> topic (as you remember, last time in Munich we said we would have
>>> unlocked wsse, wsrm, wsa, etc in all stacks and them evaluated them).
>>> In terms of WS-Security, the CXF stack doesn't offer something
>>> really special we don't have in native. It has a proprietary
>>> security configuration almost the same way we have, while the
>>> documentation and testsuite is really poor on this topic. On the
>>> contrary, our native stack documentation and available tests on
>>> WS-Security are pretty good, imho, also thanks to the improvements
>>> we did on the wiki in the last months. In terms of features
>>> comparison, native and cxf are almost equal, with a slight
>>> preference for native thanks to the better jaas integration with
>>> jboss as.
>>> The Metro stack, instead, actually offers much more than what we
>>> have in Native. I'm not talking about the WS-Trust,
>>> WS-SecureConversation, etc. we don't have at all in Native. WSIT
>>> supports WS-Security 1.1 and WS-SecurityPolicy, which basically
>>> means more features than wsse 1.0 and a standard way of configuring
>>> them all (through policies). Native of course is better integrated
>>> with the jboss as, but we can work on this topic (see JBWS-2209 for
>>> example).
>>> In short, imho moving to CXF wouldn't give us nothing more in terms
>>> of ws-security, while moving to Metro would require us some further
>>> work but might potentially give us a lot of new features (indeed we
>>> already got WS-Security 1.1 and WS-SecurityPolicy covered by tests
>>> in this 3.0.2 release). Of course wsse is only a (little) slice of
>>> the whole cake...
>>> Did you come to some other conclusions?
>> I need to dive into both CXF and Metro stacks more and then I'll do
>> the conclusions. Thus I have no opinion yet on this topic.
> Just to be clear... I meant some other conclusions (or feelings) in
> other ws area you all have worked since last meeting in Munich, like
> wsrm, wsa, etc. not in the ws-security field.
> Cheers
> Alessio
--
B.Sc. Richard Opalka
Senior Software Engineer
JBoss, a division of Red Hat
Mobile: +420 731 186 942
Mail: ropalka(a)redhat.com
15 years, 11 months
JBossWS 3.0.2 Release Integration with AS Trunk
by Richard Opalka
Hi Dimitris,
we i.e. JBossWS team are releasing JBossWS 3.0.2 these days.
We're going to create the integration branch soon, update that branch
to include up2date JBossWS release in the AS codebase and then
we're going to merge it back to trunk.
My question is whether we can do it these days or you would
like to postpone it little bit. What's the current schedule for AS CR1?
Richard
--
B.Sc. Richard Opalka
Senior Software Engineer
JBoss, a division of Red Hat
Mobile: +420 731 186 942
Mail: ropalka(a)redhat.com
15 years, 11 months
