Re: svn commit: r785866
Thanks Benson :-)
- Original Message -
From:
To:
Sent: Thursday, June 18, 2009 1:31 AM
Subject: svn commit: r785866 - in /cxf/trunk/rt/frontend/jaxrs/src:
main/java/org/apache/cxf/jaxrs/provider/AbstractAegisProvider.java test/java/org/apache/cxf/jaxrs/provider/AegisProviderTest.java
Author: bimargulies
Date: Thu Jun 18 00:31:35 2009
New Revision: 785866
URL: http://svn.apache.org/viewvc?rev=785866&view=rev
Log:
Fix Aegis support for JAX-RS to deal with generics.
Modified:
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/AbstractAegisProvider.java
cxf/trunk/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/provider/AegisProviderTest.java
Modified:
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/AbstractAegisProvider.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/AbstractAegisProvider.java?rev=785866&r1=785865&r2=785866&view=diff
==
---
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/AbstractAegisProvider.java
(original)
+++
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/AbstractAegisProvider.java
Thu Jun 18 00:31:35 2009
@@ -20,6 +20,9 @@
package org.apache.cxf.jaxrs.provider;
import java.lang.annotation.Annotation;
+import java.lang.reflect.Array;
+import java.lang.reflect.GenericArrayType;
+import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
import java.util.HashSet;
import java.util.Map;
@@ -63,10 +66,30 @@
}
}
-return getClassContext(type);
+return getClassContext(type, genericType);
}
-private AegisContext getClassContext(Class type) {
+
+private void addType(Set> rootClasses, Type cls, boolean
allowArray) {
+if (cls instanceof Class) {
+if (((Class)cls).isArray() && !allowArray) {
+rootClasses.add(((Class)cls).getComponentType());
+} else {
+rootClasses.add((Class)cls);
+}
+} else if (cls instanceof ParameterizedType) {
+for (Type t2 : ((ParameterizedType)cls).getActualTypeArguments()) {
+addType(rootClasses, t2, false);
+}
+} else if (cls instanceof GenericArrayType) {
+GenericArrayType gt = (GenericArrayType)cls;
+Class ct = (Class) gt.getGenericComponentType();
+ct = Array.newInstance(ct, 0).getClass();
+
+rootClasses.add(ct);
+}
+}
+private AegisContext getClassContext(Class type, Type genericType) {
synchronized (classContexts) {
AegisContext context = classContexts.get(type);
if (context == null) {
@@ -75,6 +98,9 @@
context.setReadXsiTypes(true);
Set> rootClasses = new HashSet>();
rootClasses.add(type);
+if (!(genericType instanceof Class)) {
+addType(rootClasses, genericType, true);
+}
context.setRootClasses(rootClasses);
context.initialize();
classContexts.put(type, context);
Modified:
cxf/trunk/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/provider/AegisProviderTest.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/provider/AegisProviderTest.java?rev=785866&r1=785865&r2=785866&view=diff
==
---
cxf/trunk/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/provider/AegisProviderTest.java
(original)
+++
cxf/trunk/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/provider/AegisProviderTest.java
Thu Jun 18 00:31:35 2009
@@ -21,6 +21,8 @@
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
+import java.lang.reflect.Method;
+import java.lang.reflect.Type;
import java.util.HashMap;
import java.util.Map;
@@ -30,7 +32,6 @@
import org.apache.cxf.jaxrs.fortest.AegisTestBean;
import org.junit.Assert;
-import org.junit.Ignore;
import org.junit.Test;
public class AegisProviderTest extends Assert {
@@ -79,9 +80,13 @@
assertEquals(SIMPLE_BEAN_XML, xml);
}
+private static interface InterfaceWithMap {
+Map mapFunction();
+}
+
@SuppressWarnings("unchecked")
@Test
-@Ignore
+@org.junit.Ignore
public void testReadWriteComplexMap() throws Exception {
Map map = new HashMap();
AegisTestBean bean = new AegisTestBean();
@@ -98,7 +103,12 @@
MessageBodyReader reader = new AegisElementProvider();
byte[] simpleBytes = xml.getBytes("utf-8");
-Object beanObject = reader.readFrom((Class)Map.class, null, null,
+
+Class iwithMapClass = InterfaceWithMap.class;
+Method method = iwithMapClass.getMethod("mapFunction");
+Type mapType = m
Re: Questions about CXF WS-RM
Hi Richard, further comments in-line ... > IMHO WS-RM 1.1 is the right way to do WS-RM, because this spec. > addresses unacknowledged anonymous messages use case (see WS-MakeConnection) > This usecase wasn't addressed in WS-RM 1.0 and so I consider > this old RM spec. broken. Absolutely, the MakeConnection mechanism is the biggest motivation for moving to 1.1. > I don't see the relevant source code for CXF bus integration? Well the "bus integration" is just the addition of the RM interceptors to the Bus-level interceptor chains as opposed to the per-endpoint chains. > Could you give me the pointer to impl or test? The interceptors can be added explicitly to the Bus-level chains a la: http://svn.apache.org/viewvc/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/ws/rm/rminterceptors.xml?revision=773965 or implicitly by setting the feature on the Bus instance, e.g.: http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/ws_rm/src/demo/ws_rm/server/ws_rm.xml?view=co > And how is the integration with other WS-* technologies? Well WS-RM requires WS-Addressing, so these will always be working together. What other specific WS-* services did you have in mind? > I mean do CXF WS-RM support e.g. WS-RM with WS-Security? I don't believe we've done any specific testing of WS-Security with WS-RM. Dan may have a better sense of this, but off the top of my head there *may* be issues with re-transmitted messages (e.g. replay detection may get in the way, though I guess if the message went un-acknowledged in the first place, the original message may never have been seen by the WS-Sec layer). > If I have two RM responses comming from the server (I mean RM responses with real SOAP response). > How this is handled? User should take care of that there can be more than just one async SOAP response? > What if client will use synchronous JAX-WS api? There is no problem with a client having multiple outstanding requests to the same server/endpoint. WS-Addressing message correlation will ensure that each response is correlated to the corresponding request (requests contain a header which is then referenced in the response's header). This is true whether the request is made via JAX-WS async (a purely client-side thread-based mchanism) and/or is decoupled (in which case the server sends the response over a *separate* server->client connection). Similarly it would also be true when the WS-RM 1.1 MakeConnection mechanism is supported. > Well this should be addressed in JAX-WS spec otherwise this would leave to proprietary client side API > for manipulating the client RM store. Let's see what will come out with next metro release. AFAIK > the Sun folks are working on RM 1.1 at the moment there. Yes, it would have to be proprietary if the JAX-WS spec doesn't address this issue. But when you say "should be addressed in the JAX-WS spec", do you mean in 2.3? I haven't heard that JAX-WS 2.2 will address this. Cheers, Eoghan 2009/6/18 Richard Opalka > Hi Eoghan, > > see in lined comments below: > > Richard > > Eoghan Glynn wrote: > >> Hi Richard, >> >> Apologies for the delay in replying. >> > NP > >> Please see my comments in-line. >> >> 2009/6/15 Richard Opalka : >> >> >>> what's the current state of CXF WS-RM? >>> >>> >> >> See below. >> >> >> >>> I'm asking because we'd like to integrate probably >>> WS-RM in our JBossWS CXF integration. >>> >>> >> >> Great that you're thinking of using CXF WS-RM. >> >> >> >>> The main questions are: >>> * Which WS-RM specs are supported now (I know about 1.0, is 1.1 supported >>> already)? >>> >>> >> >> Only WS-RM 1.0 (2005/02) is supported as yet. This was the current >> version of the spec when the original RM implementation was done as >> part of the Celtix project (the precursor to CXF). >> >> We've had some interest in WS-RM 1.1 and I intend to do a costing on >> the implementation effort soon, and hopefully will get the time to >> implement support for it in the CXF 2.3 timeframe. >> >> > IMHO WS-RM 1.1 is the right way to do WS-RM, because this spec. > addresses unacknowledged anonymous messages use case (see > WS-MakeConnection) > This usecase wasn't addressed in WS-RM 1.0 and so I consider > this old RM spec. broken. > >> >> >>> * Is QoS (Quality of Service) ensured in CXF WS-RM implementation? >>> >>> >> >> Well yes, in so far as the qualities of service envisaged by the WS-RM >> spec as concerned. So for example the policy with regard to ordering >> and duplicates may be asserted via the >> /ws-rm-policy:RMAssertion/ws-rm:deliveryAssurance element in config >> (see schema[1]). >> >> However other QoS typically available in the MOM world, such as >> message expiration/TTL and priority, are not part of WS-RM. >> >> > I'm asking about 2.4 Delivery Assurances (see WS-RX 1.1 specification) > Thus I consider you respond "yes" from this point of view ;) > >> >> >>> * Is current CXF WS-RM implementation tightly coupled with Endpoint? >>> >>> >>
Re: Commit rights and few questions
cc: d...@cxf as they are good questions that others might have On Thu June 18 2009 4:49:39 am Alessio Soldano wrote: > Hi Dan, > I've few questions regarding the commitership and the way the project > contribution is organized: > - should I get an email when my account is properly set? I've just tried > committing to svn but I'm not allowed. Perhaps I just need to wait ;-) Need to wait. They process account creation requests once a week or so. You should get an email with details when that happens. > - do you have a standard procedure for validating changes before commit? > Asking as running the whole testsuite, including the systests, is *really* > time consuming. Do you have some kind of smoke test? The systests kind of are the smoke test. :-) This is actually an area where using git has been saving me a bunch of time. I used to run the full test suite 4 or 5 times a day as I was committing to svn 4 or 5 times a day.With git, I now commit things to my local git branch 4 or 5 times a day with just running localized unit tests or specific system tests. Then, I run the full test suite when I have all of the things "done" and if it passes, then "git svn dcommit" the whole batch. With git- svn, each commit I do locally turns into a svn commit, but they all occur at once.That is why you'll see 4 or 5 commits from me in the period of about 30 seconds. That's git doing its thing. For the most part, definitely run the unit tests in the areas you are touching and probably the jaxws module. Beyond that, it depends on what you are doing. If you are touching the code generators, it's DEFINITELY good to do a "mvn clean ; mvn -Pnochecks" type thing to make sure all the generated code will still compile and work correctly. That said, if you do break things (it happens, even to me :-), hudson will usually catch it fairly quickly. http://hudson.zones.apache.org/hudson/view/CXF/ > - how do you handle merge of changes from trunk to the supported fix > branches? everybody merges his stuff as soon as the fix to the trunk is > committed, or do you prefer batch merges? In general, we use the svnmerge.py script (google it) to merge from tunk -> branches. That way, what is merged and is blocked gets recorded.There are two options for getting the fixes on the branch: 1) Use svnmerge.py yourself and merge it.This is the fastest way to get it onto the fixes branch and it would then be guaranteed to make it into the nightly deploys. 2) Wait a couple days and I'll do it. Once or twice a week, I run the "DoMerges" program in trunk/bin which walks me through all the commits that haven't been merged and anything that is a bug fix, I'll merge. > Besides that, is every bug fix > supposed to be merged to all the fix branches while new features goes to > trunk only? Something like that. SOME new features do get pulled back into the fixes branches if there is some demand and it doesn't really affect any existing functionality.For example, when we added the continuation support, that got pulled back into all the branches as it made things work MUCH better in ESB's such as ServiceMix that were using some of the older versions. > Sorry for bothering for this kind of things, just wanted to be sure things > are done the way you use to. Not a bother at all. Good questions. Also, if you have ideas how to streamline things even more, please propose them. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Commit rights and few questions
Let me put in a plug for feeding the fish ... EYE. Be sure, when writing commit comments, to put JIRA numbers into them, so that FISH-EYE will automatically annotate JIRA. Which suggests an opportunity to state a few other general principles, which I will explain by telling a story. You run into a problem, or someone reports something on the user list. 1) You open a JIRA. 2) You create a test case that fails. 3) You fix the issue. 4) You commit the fix with a comment in that (a) includes the JIRA number and (b) explains what you did and why. 5) You resolve the JIRA. 6) If you think the rest of us could learn something from your travails, you send email to the dev list describing your adventures. I think we should have some workflow to organize the patch porting process a bit better, but for now you're done. On Thu, Jun 18, 2009 at 9:24 AM, Daniel Kulp wrote: > > cc: d...@cxf as they are good questions that others might have > > On Thu June 18 2009 4:49:39 am Alessio Soldano wrote: >> Hi Dan, >> I've few questions regarding the commitership and the way the project >> contribution is organized: >> - should I get an email when my account is properly set? I've just tried >> committing to svn but I'm not allowed. Perhaps I just need to wait ;-) > > Need to wait. They process account creation requests once a week or so. > You should get an email with details when that happens. > >> - do you have a standard procedure for validating changes before commit? >> Asking as running the whole testsuite, including the systests, is *really* >> time consuming. Do you have some kind of smoke test? > > The systests kind of are the smoke test. :-) > > This is actually an area where using git has been saving me a bunch of time. > I used to run the full test suite 4 or 5 times a day as I was committing to > svn 4 or 5 times a day. With git, I now commit things to my local git > branch 4 or 5 times a day with just running localized unit tests or specific > system tests. Then, I run the full test suite when I have all of the things > "done" and if it passes, then "git svn dcommit" the whole batch. With git- > svn, each commit I do locally turns into a svn commit, but they all occur at > once. That is why you'll see 4 or 5 commits from me in the period of about > 30 seconds. That's git doing its thing. > > For the most part, definitely run the unit tests in the areas you are touching > and probably the jaxws module. Beyond that, it depends on what you are > doing. If you are touching the code generators, it's DEFINITELY good to do a > "mvn clean ; mvn -Pnochecks" type thing to make sure all the generated code > will still compile and work correctly. > > That said, if you do break things (it happens, even to me :-), hudson will > usually catch it fairly quickly. > http://hudson.zones.apache.org/hudson/view/CXF/ > > >> - how do you handle merge of changes from trunk to the supported fix >> branches? everybody merges his stuff as soon as the fix to the trunk is >> committed, or do you prefer batch merges? > > In general, we use the svnmerge.py script (google it) to merge from tunk -> > branches. That way, what is merged and is blocked gets recorded. There > are two options for getting the fixes on the branch: > 1) Use svnmerge.py yourself and merge it. This is the fastest way to get it > onto the fixes branch and it would then be guaranteed to make it into the > nightly deploys. > > 2) Wait a couple days and I'll do it. Once or twice a week, I run the > "DoMerges" program in trunk/bin which walks me through all the commits that > haven't been merged and anything that is a bug fix, I'll merge. > > >> Besides that, is every bug fix >> supposed to be merged to all the fix branches while new features goes to >> trunk only? > > Something like that. SOME new features do get pulled back into the fixes > branches if there is some demand and it doesn't really affect any existing > functionality. For example, when we added the continuation support, that > got pulled back into all the branches as it made things work MUCH better in > ESB's such as ServiceMix that were using some of the older versions. > > >> Sorry for bothering for this kind of things, just wanted to be sure things >> are done the way you use to. > > Not a bother at all. Good questions. Also, if you have ideas how to > streamline things even more, please propose them. > > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
Re: Commit rights and few questions
Thanks Dan, what you say perfectly makes sense for me. Benson, +1 on putting references to jira of course... and yes, I'm a fisheye fan too, can't live, ehm, work without it ;-) Cheers Alessio
Re: CXF WS-security Signing not working - "javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI"
On Wed June 17 2009 9:11:03 pm rajla wrote:
> Sorry Dan, sometimes I am a a really loser.you are 100% right, the
> guilty party was old AXIS stuff server side. After that, I pushed the SAAJ
> stuff into the stupid endorsed directory (who came up with that brilliant
> idea anyway it is like the JBoss windows registry ha ha ha).
>
> anyway, then I added bouncy castle stuff to my class path and voila.
>
> Speaking of which, I don't remember needing bouncy castle before
> either..in fact, i think i have working in-production web services
> without bouncy castle.which is a little weird.anyway, no big deal,
> once i put it in, it works like a champ.
In order to fix a particular interop bug determining if a particular cert is
compatible, wss4j used a particular class directly from BC. That fixed the
problem, but then added a direct dependency on BC. I changed that code last
week to use the BC method if BC is there, otherwise fall back to the old
method. Thus, the next version of WSS4J should go back to not requiring BC.
You could use the latest 1.5.8 SNAPSHOTS if you want to try it.
Dan
>
> thanks Dan, I would never have realized with was AXIS stuff without you...
>
> rajla wrote:
> > Hello, I am getting the exception
> > "javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI"
> > when implementing signature secruity with WS-Security in CXF. What does
> > this mean? Anyone have any insights on what I can do to resolve this
> > issue?
> >
> >
> > Honestly, I don't remember this being so difficult to implement in older
> > CXF and I don't think I have ever seen this error before. I tried to to
> > google it a lot today and by the looks of it, not many other people have
> > seen this before either. I am on version 2.2 now.
> >
> > Could anyone please describe to me what this error means? What process
> > do I need to resolve it? P.S. The web service works fine without the
> > interceptors when I don't try and use WS-security. I followed the
> > WS-Security instructions listed here:
> > http://cwiki.apache.org/CXF20DOC/ws-security.html
> >
> > That is, I generated a keystore for my server side, generated a public
> > key for my client. Imported the public key for my client into the
> > keystore.
> >
> > Any assistance anyone can give me in regards to resolving this issue is
> > greatly appreciated.
> >
> > Below is the whole message and exception, including the SOAP exchange and
> > stuff.:
> >
> > log4j:WARN No appenders could be found for logger
> > (org.apache.cxf.bus.spring.BusApplicationContext).
> > log4j:WARN Please initialize the log4j system properly.
> > Jun 16, 2009 11:00:10 AM org.apache.cxf.bus.spring.BusApplicationContext
> > getConfigResources
> > INFO: No cxf.xml configuration file detected, relying on defaults.
> > Jun 16, 2009 11:00:14 AM
> > org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> > buildServiceFromClass
> > INFO: Creating Service {http://teams.ea.com/}EATeamsWSService from class
> > com.ea.teams.EATeamsWS
> > Jun 16, 2009 11:00:26 AM
> > org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
> > INFO: Outbound Message
> > ---
> > ID: 1
> > Address: http://teams-rwsdv:9019/teamsws/EATeamsWS
> > Encoding: UTF-8
> > Content-Type: text/xml
> > Headers: {SOAPAction=[""], Accept=[*/*]}
> > Payload: > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> >:Security
> > xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec
> >urity-secext-1.0.xsd" soap:mustUnderstand="1"> > xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; Id="Signature-1">
> >
> > > Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"; />
> > > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"; />
> >
> >
> > http://www.w3.org/2001/10/xml-exc-c14n#"; />
> >
> > http://www.w3.org/2000/09/xmldsig#sha1"; />
> > 9ugq2OUuSZq3m5dk2pchTf+XSNA=
> >
> >
> >
> > ntGCqu+lVsS5LWvKr2Bovba2xkOrIH7uOVwPk2GzEDVBUd6hdWY1Cw/l/DXH2MtFgokwNrJ2q
> >74o
> > 2wkjiZ+Tc2ak13ccUGAFWFuc0YmVoSZgYtRRZY/phhj7SHREQiodCeMQ7/4j8IZxZDf+JpGy3
> >dwd js2fRIuc9g7AvpC7KX0=
> >
> >
> > > xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec
> >urity-secext-1.0.xsd"
> > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecu
> >rity-utility-1.0.xsd"
> > wsu:Id="STRId-327383FBE9F26CE8EF12451752261753">
> >
> > CN=teams
> > 1245171677
> >
> >
> >
> > > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecu
> >rity-utility-1.0.xsd" wsu:Id="id-2"> > xmlns:ns1="http://teams.ea.com/";>sysadmin4
> >ealabels
> > --
> > Jun 16, 2009 11:00:27 AM org.apache.cxf.interceptor.LoggingInInterceptor
> > logging
> > INFO: Inbound Message
> >
> > ID: 1
> > Encoding: UTF-8
> > Content-Type: text/xml; charset=utf-8
> > Headers: {Content-Length=[225], Server=[Jetty(6.1.18)],
> > content-type=[text/xml; char
