OAuth 10 demo in the build
Hi I updated the samples pom.xml to link to the OAuth demo Lucash did, all the demos seem to build OK. Dan, Glen, let me know please if there is something I should be aware of, as there were excluded originally from the parent pom which leads to the cxf version in the demos itself not updated... Cheers, Sergey
Re: Moving the SAML SSO SP code to its own module
I moved the code to the new module as agreed, Cheers, Sergey On 10/05/12 10:35, Colm O hEigeartaigh wrote: +1 from me. Colm. On Wed, May 9, 2012 at 10:33 PM, Sergey Beryozkinsberyoz...@gmail.com wrote: Hi Colm and myself have been working recently on the initial support for the SAML-based Web SSO support on the Service Provider (SP) side. What we've got at the moment is the filters which can enforce the security context and redirect via GET or POST to the IDP, validate SAMLResponse and set the security context. There's still a bit of work that needs to be completed, to do with the better security context population on the actual application path, more sophisticated support for the session management, supporting the delegation of the SAMLResponse validation. Then going forward we can think about the logout support, artifact resolution support, etc, etc... Right now, the code lives in rt/rs/security/xml, I started prototyping the code there simply because it already contained the support for SAML-based validation of SAML assertions, etc. However, given a number of enhancements that are expected to be added for the SSO-based support, we thought with Colm that it would make sense to move the relevant code to its own dedicated module. As I said earlier I believe this code should work with different IDPs, so for now I'm not sure that it should be moved to the Fediz sub-project. I guess the possibility of moving to Fediz can be reviewed later on again, but right now I'd suggest creating a module such as cxf-rt-rs-security-sso-saml under rt/rs/security/sso/saml with the idea that perhaps some other SSO techologies will be supported at the CXF RS level in the future Comments are welcome. Cheers, Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: JAXRSClientServerBookTest.testGetBookXmlWildcard failures...
Hi Dan
On 14/05/12 18:17, Daniel Kulp wrote:
Sergey,
The JAXRSClientServerBookTest.testGetBookXmlWildcard test seems to randomly
fail for me. Looking into the test, it looks like the URL it's getting can
match either:
@GET
@Path(/books/{bookId}/)
@Produces(application/xml)
public Book getBook(@PathParam(bookId) String id) throws
BookNotFoundFault {
return doGetBook(id);
}
or:
@GET
@Path(/books/{bookId}/)
@Produces(text/xml)
public Book getBookTextXml(@PathParam(bookId) String id) throws
BookNotFoundFault {
return doGetBook(id);
}
And thus either of the two return content types would be valid, right?
Indeed, in fact, one more method matches the request,
@GET
@Path(/books/{bookId}/)
@Produces(application/json;q=0.9)
public Book getBookAsJSON() throws BookNotFoundFault {
return doGetBook(currentBookId);
}
As far as I recall the idea was to test that when the wildcard was
Accepted, the default would be 'application/xml', and perhaps I added a
text/xml producing method to test that the first matching method
(application/xml) would be chosen, it might be that even one of the TCK
tests was testing a similar expectation. But obviously it breaks when
the order of methods at the runtime is not necessarily in the order they
are declared in the source.
Now, as it happens, the method producing application/xml and text/xml
are also invoked from one of the other tests, so I'm just updating the
path for the method producing text/xml. That should do it...
Please ping me if you'd like me to investigate some other failures you
might be seeing
Thanks, Sergey
Can you look into that test a bit?
Thanks!
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Moving the SAML SSO SP code to its own module
Hi Colm and myself have been working recently on the initial support for the SAML-based Web SSO support on the Service Provider (SP) side. What we've got at the moment is the filters which can enforce the security context and redirect via GET or POST to the IDP, validate SAMLResponse and set the security context. There's still a bit of work that needs to be completed, to do with the better security context population on the actual application path, more sophisticated support for the session management, supporting the delegation of the SAMLResponse validation. Then going forward we can think about the logout support, artifact resolution support, etc, etc... Right now, the code lives in rt/rs/security/xml, I started prototyping the code there simply because it already contained the support for SAML-based validation of SAML assertions, etc. However, given a number of enhancements that are expected to be added for the SSO-based support, we thought with Colm that it would make sense to move the relevant code to its own dedicated module. As I said earlier I believe this code should work with different IDPs, so for now I'm not sure that it should be moved to the Fediz sub-project. I guess the possibility of moving to Fediz can be reviewed later on again, but right now I'd suggest creating a module such as cxf-rt-rs-security-sso-saml under rt/rs/security/sso/saml with the idea that perhaps some other SSO techologies will be supported at the CXF RS level in the future Comments are welcome. Cheers, Sergey
Re: Seeing a bunch of Java7 test failures....
Hi Dan On 03/05/12 22:25, Daniel Kulp wrote: I'm seeing a bunch of failure while using Java7 right now. I'll try and dig in tomorrow, but I went ahead and setup a Java7 build in Jenkins. Hopefully we can catch things sooner that way. Tests that I see failing: org.apache.cxf.systest.jaxrs.security.JAXRSSimpleSecurityTest org.apache.cxf.systest.ws.security.SecurityPolicyTest org.apache.cxf.systest.clustering.LoadDistributorTest org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest The jaxrs tests seem to be OK in the new Java7 Jenkins build this morning, there are some other intermittent issues there on Java7, but but I updated JAXRSClientServerBoookTest not to depend on the state updates just in case Cheers, Sergey
Re: Seeing a bunch of Java7 test failures....
On 04/05/12 20:59, Daniel Kulp wrote: I've now managed to get all the tests passing at least once. That's the good news. And the authorizing interceptors were enhanced along the way which is a good news too :-) Still haven't managed to get a full mvn -T 8 -Pnochecks to pass though. Keep getting random failures hear and there so there are definitely some timing related things or something going on. :-( I'll try to run Java7 builds next week too... Thanks, Sergey Dan On Friday, May 04, 2012 10:53:02 AM Sergey Beryozkin wrote: Hi Dan On 03/05/12 22:25, Daniel Kulp wrote: I'm seeing a bunch of failure while using Java7 right now. I'll try and dig in tomorrow, but I went ahead and setup a Java7 build in Jenkins. Hopefully we can catch things sooner that way. Tests that I see failing: org.apache.cxf.systest.jaxrs.security.JAXRSSimpleSecurityTest org.apache.cxf.systest.ws.security.SecurityPolicyTest org.apache.cxf.systest.clustering.LoadDistributorTest org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest The jaxrs tests seem to be OK in the new Java7 Jenkins build this morning, there are some other intermittent issues there on Java7, but but I updated JAXRSClientServerBoookTest not to depend on the state updates just in case Cheers, Sergey
Re: Jaxrs systest problem
Hi Andrei
On 27/04/12 09:49, Andrei Shakirin wrote:
Hi,
I am trying to execute systests in the trunk on Windows and have one strange
problem in systests/jaxrs:
jibx-maven-plugin throws following exception:
[DEBUG] Adding option: --package=org.apache.cxf.systest.jaxrs.codegen.jibx
[DEBUG] Adding
D:\Projects\CXF\trunk\systests\jaxrs/target/generated/src/main/java as source
directory...
[INFO] Generating Java sources in
D:\Projects\CXF\trunk\systests\jaxrs/target/generated/src/main/java from
schemas avail
able in D:\Projects\CXF\trunk\systests\jaxrs/src/test/resources/jibx...
Target directory
D:\Projects\CXF\trunk\systests\jaxrs\D:\Projects\CXF\trunk\systests\jaxrs\target\generated\src\main\jav
a is not writable
ERROR codegen.CodeGen - Terminating due to command line or customization errors
It seems that ${basedir} is double inserted in the path.
Do anybody has idea what can be the reason? Some days ago systests were
executed without any problems on the same environment.
I suspect it is a bug in a jibx plugin for Windows, I removed this
property from the configuration and it seems to be building OK when run
from a parent dir on Unix, so hopefully the issue will be resolved on Win
Cheers, Sergey
Regards,
Andrei.
Re: [DISCUSS] Drop 2.3.x patches....
On 24/04/12 19:30, Daniel Kulp wrote: Just wanted to open up a discussion about dropping support for 2.3.x. 2.3.0 was release over 18 months ago. Since then, 2.4.x was released over a year ago and 2.5.x 6 months ago. (and 2.6 last week). Thus, there has been plenty of opportunity (a whole year) for people to upgrade to newer versions. Right now, we have 4 branches we're supporting (2.6(trunk)/2.5/2.4/2.3) and we're likely soon going to make a 2.6 branch and open up trunk for 2.7 work adding yet another one. Dropping 2.3 will simplify things a bit for us. The major con to it is that there are still a lot of folks using 2.3.x. According the Nexus stats of central, last month, 2.3.3 was still the second most downloaded version. (next to 2.5.2) However, if they are on 2.3.3 which was released over a year ago, they haven't been grabbing the latest patches anyway so producing more patches won't really matter to them. In any case, I'm think about doing one more 2.3.x release (2.3.11) which would be announced as the end of the 2.3.x line.Obviously if any security issues pop up we can push another release in the future, but basically end the regular patch releases. Sounds good, 2.3.11 will be the best one in the 2.3.x line :-) Any objections or other thoughts? +1 Cheers, Sergey
Re: Fediz next steps
Hi Oli, On 24/04/12 06:35, Oliver Wulff wrote: Hi all As per our previous roadmap discussion here: http://cxf.547215.n5.nabble.com/Roadmap-for-fediz-in-sandbox-td5603441.html I'd like to push forward and get a release of Fediz ready. Thus, I'm planning to move it out of sandbox into cxf/fediz/[trunk|tags|branches] to mirror DOSGi in the next couple days unless someone objects or has better ideas. +1, sounds great Sergey Thanks Oli -- Oliver Wulff Blog: http://owulff.blogspot.comhttp://owulff.blogspot.com/ Solution Architect http://coders.talend.com http://coders.talend.comTalend Application Integration Division http://www.talend.com -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: [jira] [Resolved] (CXF-4051) Custom OAuth scopes are not supported
Hi On 13/04/12 17:27, jordi wrote: Hi Sergey, thanks a lot for your answer, but now I've got a new doubt... :-( To build the authorization header I use the following piece of code: WebClient wc = WebClient.create(http://localhost:8080/oauth/initiate;); wc.accept(application/x-www-form-urlencoded,text/html,application/xhtml+xml,application/xml); Consumer consumer = new Consumer(aKey, aSecretKey); URI callback = new URI(http://localhost:8080/dummyclient/callback;); // CXF extra parameters MapString, String extra = new HashMapString, String(); extra.put(x_oauth_uri, users/list); extra.put(x_oauth_scope, read_profile); extra.put(state, intercepted); // Token rt = OAuthClientUtils.getRequestToken(wc, consumer, callback, extra); But if I try to run it without adding the Google library I received the error: Exception in thread main java.lang.NoClassDefFoundError: net/oauth/OAuthConsumer at org.apache.cxf.rs.security.oauth.client.OAuthClientUtils.getRequestToken(OAuthClientUtils.java:84) So, how can I avoid that? This class is in the net core module so add it as a dependency please HTH, Sergey Thanks in advance, Jordi -- View this message in context: http://cxf.547215.n5.nabble.com/jira-Created-CXF-4051-Custom-OAuth-scopes-are-not-supported-tp5164840p5638815.html Sent from the cxf-issues mailing list archive at Nabble.com. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: [VOTE] Release Apache CXF 2.6.0
+1 Cheers, Sergey On 12/04/12 21:26, Daniel Kulp wrote: It's been 6 months since the 2.5.0 release and thus it's time for the 2.6 release. We've been VERY busy with many new features, lots of refactoring, bunch of OSGi enhancements, etc... The migration guide at: http://cxf.apache.org/docs/26-migration-guide.html is certainly one of the longest migration guides we've had, although a large part of the reason for that is the extra extensive testing that's been done with 2.6.0 to identify as many issues as possible. The maven staging area: https://repository.apache.org/content/repositories/orgapachecxf-039/ This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.0 The distributions are in the org/apache/cxf/apache-cxf/ directory of the Maven staging area. This vote will be open for at least 72 hours.
Re: [VOTE] Apache CXF 2.3.10/2.4.7/2.5.3
+1 Cheers, Sergey On 12/04/12 21:23, Daniel Kulp wrote: We've resolved over 110 issues since 2.5.2 which is a very large amount. We've back ported over 75 of them to 2.4.7 and 25 to 2.3.10. These patch releases are certainly overdue. List of issues: 2.3.10: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12319493 2.4.7: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12319492 2.5.3: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12319491 The Maven staging areas are at: 2.3.10: https://repository.apache.org/content/repositories/orgapachecxf-033/ 2.4.7: https://repository.apache.org/content/repositories/orgapachecxf-034/ 2.5.3: https://repository.apache.org/content/repositories/orgapachecxf-038/ The distributions are in the org/apache/cxf/apache-cxf/ directory of the Maven staging areas. This releases are tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.10 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.7 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.3 This vote will be open for at least 72 hours.
Re: jaxrs and minimal bundles for 2.6.0?
Hi Dan On 29/03/12 22:16, Sergey Beryozkin wrote: Hi Dan On 29/03/12 22:06, Daniel Kulp wrote: OK. I'll drop the minimal bundle but keep the jaxrs. That works for me. :-) Thanks, I'll also play with the minimal osgi demo in the next few days and see how it works without the jaxrs bundle. The individual modules can replace the all-like bundles quite nicely, I've tried with one of the Talend demos. The jaxrs bundle might be of help for non-Karaf users during the migration, so if you are OK with keeping it for now then lets keep it :-). The indiv modules approach work great too and would be more preferred in time as well, we can drop then the jaxrs bundle in 2.7.0 for ex Thanks, Sergey Cheers, Sergey Dan On Wednesday, March 28, 2012 04:39:30 PM Sergey Beryozkin wrote: Hi Dan On 28/03/12 16:16, Daniel Kulp wrote: Quick question: Are the jaxrs and minimal bundles still needed for 2.6.0? With the new little bundles, neither really makes any sense anymore. The minimal bundle is far from minimal (it's grown fairly large). Folks needed a more minimal environment are better just grabbing the individual bundles of just the things they need. Definitely +1 to dropping the minimal bundle, it was introduced originally to minimize DOSGi CXF single bundle distributions but it won't be needed when DOSGi CXF gets updated to CXF 2.6.0 Likewise, the jaxrs bundle is likely better served with the smaller bundles. It does not give us much now in Karaf with its features easily pulling in various smaller bundles together but dropping it might make it more difficult for some users to migrate to CXF 2.6.0 in cases they depend upon it for the apps deployed into non-Karaf based OSGI containers (I expect some users do it). The all bundle does have use outside of OSGi since that is the main jar we stick in lib. I'm just wondering if it make sense to keep maintaining the other two. I guess I'd not mind to keep the cxf jaxrs in the 2.6.x main branch if possible till 2.7 for example. But I recognize it is mostly redundant. I'll try to play with some of the demos and migrate them to depending on smaller bundles, if it simply a matter of updating the maven deps then it would be easy to migrate :-) Cheers, Sergey Thoughts? -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Roadmap for fediz in sandbox
As far as the providing Fedix CXF extensions, the one for making the IDP server running on top of CXF JAX-RS, as an alternative to the existing servlet option, is definitely part of the 2nd release plan, I'm wondering though if the CXF JAX-RS filters for protecting the endpoints as part of SAML-P/Redirect flows (currently incomplete) which I prototyped based on Colm's tests would belong to the Fediz project or not, at the moment I'm assuming that not as they kind of supposed to work even when non Fediz IDPs are around, It's a minor issue though, as Fediz is going to become a star sub-project :-) Cheers, Sergey On 02/04/12 21:20, Sergey Beryozkin wrote: +1 Sergey On 02/04/12 18:40, Colm O hEigeartaigh wrote: Sounds good to me as well. So the consensus is it should be a CXF sub-project? Colm. On Thu, Mar 29, 2012 at 9:58 PM, Daniel Kulpdk...@apache.org wrote: Sure. We should likely move it from the sandbox into /cxf/fediz/trunk or similar as well. Dan On Thursday, March 29, 2012 11:18:21 AM Oliver Wulff wrote: Hi all I've initially committed the fediz component to sandbox some months back: http://svn.apache.org/viewvc/cxf/sandbox/fediz/ I'd like to come up with a roadmap for the fediz security component as proposed by Colm in the following mail thread: http://mail-archives.apache.org/mod_mbox/cxf-users/201203.mbox/ajax/%3CCAB 8XdGAKVjb6EVJbccUWyA-nwZci_xKjZ1%3DHXK6XhCUeAjU1vQ%40mail.gmail.com%3E Roadmap - 1st release (end of april): - Move configuration code to fediz-core - Publish WS-Federation Metadata document - Move SignIn request creation to fediz-core - support callback handlers for federation parameters: wauth, whr, 2nd release (end of june): - Create CXF plugin for JAX-RS - Create Websphere plugin based on TAI - Support encrypted token - Support the role of relying party IDP in mock - Support SAML HoK: either use UseKey element in RST or collocate STS in IDP thus STS has access to underlying transport - add layer to support other protocols like SAML-P, OAuth 3rd release (end of september): - create JBoss plugin - create Jetty plugin Do you see any other features? Thanks Oli -- Oliver Wulff Blog: http://owulff.blogspot.comhttp://owulff.blogspot.com/ Solution Architect http://coders.talend.com http://coders.talend.comTalend Application Integration Division http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: [VOTE] Apache CXF BuildUtils and XJC-Utils
+1 Sergey On 30/03/12 17:11, Daniel Kulp wrote: In preparation for the CXF 2.6.0 release, we need to release a new version of cxf-xjc that contains the updated plugins and runtime module. Since we need that, might as well release cxf-buildutils as well. Only one minor change in cxf-buildutils: * Update the checkstyle line length from 110 to 120 chars as discussed a couple months ago. Changes in cxf-xjc * Move DataTypeAdapter and ToString stuff from cxf-tools-common into new cxf-xjc-runtime module that has very minimal dependencies (and is an osgi bundle) * Update tostring xjc plugin to use new cxf-xjc-runtime module classes. Staging area: https://repository.apache.org/content/repositories/orgapachecxf-131/ Tags: http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.6.0/ http://svn.apache.org/repos/asf/cxf/build-utils/tags/cxf-build-utils-2.4.1/ Here is my +1, vote open for at least 72 hours.
Re: Move JAX-RS claims classes to frontend independent module rt/security
Hi Oli thanks for initiating this thread On 29/03/12 07:06, Oliver Wulff wrote: Hi all I'd like to start working on the RBAC (see mail Role based access control with SAML in CXF) and the Claims support for JAX-WS. Sergey has already implemented that for JAX-RS. I'd propose to move these classes (claims, annotations) to a frontend independent module like rt/security thus it can be used by JAX-WS and JAX-RS. To get this done for 2.6 would be very good. Otherwise, we can do this for 2.7 earliest. I'd like to avoid in having different Claims classes for the same purpose when using JAX-RS or JAX-WS. What do you think? +1. I think it might be a bit tight to get both the annotations the actual data classes representing Claims given that at the moment Claims data classes used within the JAX-RS frontend are different from the ones available in the WS Security module. We have 3 pieces to deal with: - Annotations (visible at the application code level) [1] - ClaimsAuthorizingInterceptor which enforces those annotations against the incoming claims data available at runtime - The actual Claim classes keeping the info about the claims Moving Annotations to the common package can be done quickly enough that would let us have the JAX-WS JAX-RS code using the same visible annotations. The interim solution for JAX-WS then is to provide its own ClaimsAuthorizingInterceptor which will operate on WS specific Claim classes. And then we can introduce at some stage the common interceptor once we 'merge' the Claim data classes, I'd be OK adapting JAX-RS Claim classes as close as possible to WS ones. But let me move the annotations first. Who knows may be we will also be able to merge Claim data classes before 2.6 is out :-) Thanks, Sergey [1] http://cxf.apache.org/docs/jax-rs-saml.html#JAX-RSSAML-SAMLAuthorization Thanks Oli -- Oliver Wulff Blog: http://owulff.blogspot.comhttp://owulff.blogspot.com/ Solution Architect http://coders.talend.com http://coders.talend.comTalend Application Integration Division http://www.talend.com -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: jaxrs and minimal bundles for 2.6.0?
Hi Dan On 29/03/12 22:06, Daniel Kulp wrote: OK. I'll drop the minimal bundle but keep the jaxrs. That works for me. :-) Thanks, I'll also play with the minimal osgi demo in the next few days and see how it works without the jaxrs bundle. Cheers, Sergey Dan On Wednesday, March 28, 2012 04:39:30 PM Sergey Beryozkin wrote: Hi Dan On 28/03/12 16:16, Daniel Kulp wrote: Quick question: Are the jaxrs and minimal bundles still needed for 2.6.0? With the new little bundles, neither really makes any sense anymore. The minimal bundle is far from minimal (it's grown fairly large). Folks needed a more minimal environment are better just grabbing the individual bundles of just the things they need. Definitely +1 to dropping the minimal bundle, it was introduced originally to minimize DOSGi CXF single bundle distributions but it won't be needed when DOSGi CXF gets updated to CXF 2.6.0 Likewise, the jaxrs bundle is likely better served with the smaller bundles. It does not give us much now in Karaf with its features easily pulling in various smaller bundles together but dropping it might make it more difficult for some users to migrate to CXF 2.6.0 in cases they depend upon it for the apps deployed into non-Karaf based OSGI containers (I expect some users do it). The all bundle does have use outside of OSGi since that is the main jar we stick in lib. I'm just wondering if it make sense to keep maintaining the other two. I guess I'd not mind to keep the cxf jaxrs in the 2.6.x main branch if possible till 2.7 for example. But I recognize it is mostly redundant. I'll try to play with some of the demos and migrate them to depending on smaller bundles, if it simply a matter of updating the maven deps then it would be easy to migrate :-) Cheers, Sergey Thoughts?
Re: Move JAX-RS claims classes to frontend independent module rt/security
Forgot the links: http://svn.apache.org/viewvc?rev=1307112view=rev https://issues.apache.org/jira/browse/CXF-4215 Sergey On 29/03/12 22:30, Sergey Beryozkin wrote: Hi Oli, I've moved the Claims annotations to the api module, to the org.apache.cxf.security.claims.authorization package with the idea that the org.apache.cxf.security.claims package will hold in time few common Claim data classes. I reckon it should be enough for you to start experimenting with enforcing the same Claim annotations at the JAX-WS/WS-Security end but using the Claim data classes declared in the ws-security module. ClaimsAuthorizingInterceptor can be copied for now. If we manage to quickly adapt the Claim class used in the rt-rs-security-xml to the one used in the ws-security module then I can move the rest of the authorization code to the api. That should be quite possible but I think if we do not manage to do it in time for 2.6 then we can do it for 2.6.1/2 because I guess the Claim data classes are not really visible to the application developers. FYI, I have the SAMLSecurityContext - can be renamed to ClaimsSecurityContext, I thought a bit about also introducing ClaimsPrincipal, but then I decided to stay with SAMLSecurityContext, it's kind of similar to the base SecurityContext (Principal + its roles), or Principal + Claims (roles and more) I stopped short of introducing a new module (rt-security), a bit tight for 2.6 :-), but indeed it would be easy enough to move various security related classes from api rt/core to rt-security, except for may be for the base SecurityContext, AuthorizationPolicy, few other classes Thanks, Sergey On 29/03/12 13:00, Sergey Beryozkin wrote: Hi Oli thanks for initiating this thread On 29/03/12 07:06, Oliver Wulff wrote: Hi all I'd like to start working on the RBAC (see mail Role based access control with SAML in CXF) and the Claims support for JAX-WS. Sergey has already implemented that for JAX-RS. I'd propose to move these classes (claims, annotations) to a frontend independent module like rt/security thus it can be used by JAX-WS and JAX-RS. To get this done for 2.6 would be very good. Otherwise, we can do this for 2.7 earliest. I'd like to avoid in having different Claims classes for the same purpose when using JAX-RS or JAX-WS. What do you think? +1. I think it might be a bit tight to get both the annotations the actual data classes representing Claims given that at the moment Claims data classes used within the JAX-RS frontend are different from the ones available in the WS Security module. We have 3 pieces to deal with: - Annotations (visible at the application code level) [1] - ClaimsAuthorizingInterceptor which enforces those annotations against the incoming claims data available at runtime - The actual Claim classes keeping the info about the claims Moving Annotations to the common package can be done quickly enough that would let us have the JAX-WS JAX-RS code using the same visible annotations. The interim solution for JAX-WS then is to provide its own ClaimsAuthorizingInterceptor which will operate on WS specific Claim classes. And then we can introduce at some stage the common interceptor once we 'merge' the Claim data classes, I'd be OK adapting JAX-RS Claim classes as close as possible to WS ones. But let me move the annotations first. Who knows may be we will also be able to merge Claim data classes before 2.6 is out :-) Thanks, Sergey [1] http://cxf.apache.org/docs/jax-rs-saml.html#JAX-RSSAML-SAMLAuthorization Thanks Oli -- Oliver Wulff Blog: http://owulff.blogspot.comhttp://owulff.blogspot.com/ Solution Architect http://coders.talend.com http://coders.talend.comTalend Application Integration Division http://www.talend.com
Re: jaxrs and minimal bundles for 2.6.0?
Hi Dan On 28/03/12 16:16, Daniel Kulp wrote: Quick question: Are the jaxrs and minimal bundles still needed for 2.6.0? With the new little bundles, neither really makes any sense anymore. The minimal bundle is far from minimal (it's grown fairly large). Folks needed a more minimal environment are better just grabbing the individual bundles of just the things they need. Definitely +1 to dropping the minimal bundle, it was introduced originally to minimize DOSGi CXF single bundle distributions but it won't be needed when DOSGi CXF gets updated to CXF 2.6.0 Likewise, the jaxrs bundle is likely better served with the smaller bundles. It does not give us much now in Karaf with its features easily pulling in various smaller bundles together but dropping it might make it more difficult for some users to migrate to CXF 2.6.0 in cases they depend upon it for the apps deployed into non-Karaf based OSGI containers (I expect some users do it). The all bundle does have use outside of OSGi since that is the main jar we stick in lib. I'm just wondering if it make sense to keep maintaining the other two. I guess I'd not mind to keep the cxf jaxrs in the 2.6.x main branch if possible till 2.7 for example. But I recognize it is mostly redundant. I'll try to play with some of the demos and migrate them to depending on smaller bundles, if it simply a matter of updating the maven deps then it would be easy to migrate :-) Cheers, Sergey Thoughts?
Should be JSONP interceptors moved to rt-rs-security-cors
Hi Benson, all, I was wondering if it would make sense to move the JSONP interceptors to the CORS module. They are in rt-rs-extension-providers (on the trunk) right now, and seem a bit out place there, I'm reading CORS is a modern alternative to JSONP: http://en.wikipedia.org/wiki/Cross-origin_resource_sharing#CORS_relationship_to_JSONP thus may be grouping the interceptors dealing with supporting the cross origin resource sharing pattern (CORS the spec related, JSONP, etc) would do well, we of course can do it later too Cheers, Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: [VOTE] Apache DOSGi 1.3.1 Release
+1 Thanks, Sergey On 27/03/12 02:00, David Bosschaert wrote: The Apache CXF DOSGi subproject is the Reference Implementation of the OSGi Remote Services and Remote Services Admin Service specifications [1] which provide a distributed computing model based around OSGi Services. We have been working on CXF-DOSGi release 1.3.1 which fixes issues identified by the OSGi Remote Service Admin TCK when run on release 1.3. For more details see the release notes: http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.3.1/distribution/sources/src/main/release/release_notes.txt Staging area: https://repository.apache.org/content/repositories/orgapachecxf-101/ The vote will be open for at least 72 hours. Here's my +1. Best regards, David [1] Chapters 13 and 122 in the OSGi 4.2 Enterprise Specification at http://www.osgi.org/Download/Release4V42 -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Not able to receive inline JSON response for Multipart API
Hi Ganesh I'm forwarding it to the users list I wonder if you are looking for JSONP or similar approaches ? Have a look at this documentation: http://cxf.apache.org/docs/jax-rs-data-bindings.html#JAX-RSDataBindings-JSONWithPadding Cheers, Sergey On 24/03/12 11:10, Ganesh wrote: Hi All, We have a two issues related to receiving *application/json* response from CXF REST API. 1) When we do a file upload from ajax form submit we are receiving the inline XML response for successful uploads. But actually we need it as JSON response to handle in AJAX/JQUERY. In the server side api we used *@Consumes(multipart/form-data)* which can accept file upload along with form data. We tried to add *@Produces(application/json)* in the server side API. After adding this we are able to get JSON response, But it's opening in the popup and asking users to download it. Which is a bad experience to the user. We are looking for the solution to retrieve it as inline rather than asking download. 2) The second issue is we have an API to download CSV file from server side. In the API we used *@Produces(text/csv, application/json)* and the response class is *javax.ws.rs.core.Response* Everything is working fine for the happy flows. But we have a use case to handle the error scenario and customized error message needs to be displayed to the user. For this we need to receive the JSON response as inline rather than asking for download in the popup window. Is there any possible solutions to achieve this ? Could any one please tell us the approach to resolve these issues? Regards, Ganesh. -- View this message in context: http://cxf.547215.n5.nabble.com/Not-able-to-receive-inline-JSON-response-for-Multipart-API-tp5591532p5591532.html Sent from the cxf-dev mailing list archive at Nabble.com. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Ajax form submit for Maultipart contetnt type along with other form fields
Hi On 23/03/12 14:07, Ganesh wrote: Hi All, The requirements is to post the the form data along with the image/flash file upload via AJAX sumbit. In the server side we used @Consume(multipart/form-data) and the API argument is org.apache.cxf.jaxrs.ext.multipart.MultipartBody When we do a AJAX submit along with file upload everything is working fine. We have a use case to submit the form without file upload. when we do the AJAX sumbit without file upload the request content type is application/x-www-form-urlencoded and in the server side we are getting the below exception [org.apache.cxf.jaxrs.utils.JAXRSUtils] .No operation matching request path / is found, HTTP Method : POST, ContentType : application/x-www-form-urlencoded;charset=UTF-8, Accept : application/json,text/javascript,*/*,. 2012-03-22 21:46:27,596 WARN [org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper] WebApplicationException has been caught : no cause is available We tried to add @Consume(application/x-www-form-urlencoded) in the server side, but still we faced the same issue. In one of the thread we found to use org.apache.cxf.jaxrs.ext.RequestHandler to set the content type explicitly in the server side. Could you please tell us whether can we follow the above approach or any other solution to resolve the issue. You definitely need to have @Consume(application/x-www-form-urlencoded) if the Content-Type is application/x-www-form-urlencoded, however the FormEncodingProvider does not deal with unmarshalling application/x-www-form-urlencoded payloads into MultipartBody. Thus you need to have two POST handlers, one for dealing with application/x-www-form-urlencoded and having say MultivalueMap parameter, and another (existing) one - for handling multiparts Cheers, Sergey Regards, Ganesh -- View this message in context: http://cxf.547215.n5.nabble.com/Ajax-form-submit-for-Maultipart-contetnt-type-along-with-other-form-fields-tp5589560p5589560.html Sent from the cxf-dev mailing list archive at Nabble.com. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Hi David On 22/03/12 08:47, David Bosschaert wrote: Yes, the changes to settings.xml helped. That got me past that issue. However, I ended up having some problems with the GPG side of things (GPG on Mac OSX) - similar to [1] so I couldn't close the stage repo. It seems like the artifacts were signed by a subkey which apparently doesn't work. So it looks like I need to do things over again. Does it harm doing mvn release:prepare and mvn release:perform a second time with the same version? I guess this will mean that the tag gets moved? I got the Jettison release failing like this once, so what I did I reverted to the revision which was there before I started the release process, and then started again. Cheers, Sergey Cheers, David [1] https://issues.sonatype.org/browse/OSSRH-1525 On 21 March 2012 20:44, Sergey Beryozkinsberyoz...@gmail.com wrote: Yes, this is what I did. David, I think we also need to get your public gpg key added to http://pgp.mit.edu/, here are some links I found useful. http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/gpg-cs.html https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven You should be able to login to https://repository.apache.org/index.html#welcome with your apache login/password, This guide is good: http://www.apache.org/dev/publishing-maven-artifacts.html but this one on the Codehaus is also good: http://docs.codehaus.org/display/HAUSMATES/Codehaus+Maven+Repository+Usage+Guide HTH, thanks for deciding to give it a go :-) I'll get you a pint :-) Cheers, Sergey On 21/03/12 20:34, Daniel Kulp wrote: David, Add to your ~/.m2/settings.xml something like: settings servers server idapache.releases.https/id usernamedkulp/username passwordyourapachepassword/password /server /servers /settings to setup your credentials needed to deploy to Nexus. If that works, let me know and I'll update the release page. (or feel free to update it) Dan On Wednesday, March 21, 2012 07:55:24 PM David Bosschaert wrote: On 21 March 2012 19:09, David Bosschaertdavid.bosscha...@gmail.com wrote: On 21 March 2012 15:34, Daniel Kulpdk...@apache.orgwrote: If you are willing to do the release, then I think it's a good idea. I'd rather have a release often type thing if it fixes a few issue that are needed.Do you know if it needs a new CXF proper release or is 2.5.2 OK? If it's just a release of the DOSGi stuff, then it should be pretty simple. I think a simple: mvn release:prepare mvn release:perform should handle most of it. The release-manangement page for cxf might have more details about setting up the gpg stuff, Nexus, etc... It's the gpg and Nexus stuff that I'm unsure about in relation to how releases are done at Apache, but I see things are documented well on that page, so I'll give it a try soon. Cheers, David I successfully completed the release:prepare (I think) but the release:perform fails with the error below. Any ideas? Sergey, how did you do this before? David [INFO] BUILD FAILURE [INFO] [INFO] Total time: 7.789s [INFO] Finished at: Wed Mar 21 19:51:53 GMT 2012 [INFO] Final Memory: 10M/81M [INFO] [WARNING] The requested profile deploy could not be activated because it does not exist. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy (default-deploy) on project cxf-dosgi-ri: Failed to deploy artifacts: Could not transfer artifact org.apache.cxf.dosgi:cxf-dosgi-ri:pom:1.3.1 from/to apache.releases.https (https://repository.apache.org/service/local/staging/deploy/maven2): Failed to transfer file: https://repository.apache.org/service/local/staging/deploy/maven2/org/apac he/cxf/dosgi/cxf-dosgi-ri/1.3.1/cxf-dosgi-ri-1.3.1.pom. Return code is: 401 -[Help 1] ... more stuff ... -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Hi David On 22/03/12 12:50, David Bosschaert wrote: On 22 March 2012 11:13, Daniel Kulpdk...@apache.org wrote: On Thursday, March 22, 2012 08:47:16 AM David Bosschaert wrote: Yes, the changes to settings.xml helped. That got me past that issue. However, I ended up having some problems with the GPG side of things (GPG on Mac OSX) - similar to [1] so I couldn't close the stage repo. It seems like the artifacts were signed by a subkey which apparently doesn't work. So it looks like I need to do things over again. Does it harm doing mvn release:prepare and mvn release:perform a second time with the same version? I guess this will mean that the tag gets moved? Just make sure you svn rm the tag first. Then it should be OK to just redo it. Dan Ok, that seems to have worked now. I have the CXF-DOSGi 1.3.1 artifacts staged here: https://repository.apache.org/content/repositories/orgapachecxf-101/ Could someone please confirm that I did this correctly? Before calling the vote I would like to run the actual artifacts through the OSGi TCK to ensure that everything is still green. Is there anything else that needs to be done before the vote can be called? I quickly tested the greeter demo against single multi bundles distros, downloading all from the staged repo, looks ok. I'm seeing 1.4-SNAPSHOT in poms, I guess I can update that easily later on to 1.3.2-SNAPSHOT as I won't have enough 'material' to call a 1.4 release in few months time, the upgrade to Blueprint would of course go to 1.4 :-), but I'm not sure when exactly it will happen... Thanks, Sergey Cheers, David
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Yes, this is what I did. David, I think we also need to get your public gpg key added to http://pgp.mit.edu/, here are some links I found useful. http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/gpg-cs.html https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven You should be able to login to https://repository.apache.org/index.html#welcome with your apache login/password, This guide is good: http://www.apache.org/dev/publishing-maven-artifacts.html but this one on the Codehaus is also good: http://docs.codehaus.org/display/HAUSMATES/Codehaus+Maven+Repository+Usage+Guide HTH, thanks for deciding to give it a go :-) I'll get you a pint :-) Cheers, Sergey On 21/03/12 20:34, Daniel Kulp wrote: David, Add to your ~/.m2/settings.xml something like: settings servers server idapache.releases.https/id usernamedkulp/username passwordyourapachepassword/password /server /servers /settings to setup your credentials needed to deploy to Nexus. If that works, let me know and I'll update the release page. (or feel free to update it) Dan On Wednesday, March 21, 2012 07:55:24 PM David Bosschaert wrote: On 21 March 2012 19:09, David Bosschaertdavid.bosscha...@gmail.com wrote: On 21 March 2012 15:34, Daniel Kulpdk...@apache.org wrote: If you are willing to do the release, then I think it's a good idea. I'd rather have a release often type thing if it fixes a few issue that are needed.Do you know if it needs a new CXF proper release or is 2.5.2 OK? If it's just a release of the DOSGi stuff, then it should be pretty simple. I think a simple: mvn release:prepare mvn release:perform should handle most of it. The release-manangement page for cxf might have more details about setting up the gpg stuff, Nexus, etc... It's the gpg and Nexus stuff that I'm unsure about in relation to how releases are done at Apache, but I see things are documented well on that page, so I'll give it a try soon. Cheers, David I successfully completed the release:prepare (I think) but the release:perform fails with the error below. Any ideas? Sergey, how did you do this before? David [INFO] BUILD FAILURE [INFO] [INFO] Total time: 7.789s [INFO] Finished at: Wed Mar 21 19:51:53 GMT 2012 [INFO] Final Memory: 10M/81M [INFO] [WARNING] The requested profile deploy could not be activated because it does not exist. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy (default-deploy) on project cxf-dosgi-ri: Failed to deploy artifacts: Could not transfer artifact org.apache.cxf.dosgi:cxf-dosgi-ri:pom:1.3.1 from/to apache.releases.https (https://repository.apache.org/service/local/staging/deploy/maven2): Failed to transfer file: https://repository.apache.org/service/local/staging/deploy/maven2/org/apac he/cxf/dosgi/cxf-dosgi-ri/1.3.1/cxf-dosgi-ri-1.3.1.pom. Return code is: 401 - [Help 1] ... more stuff ...
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Hi David On 20/03/12 08:00, David Bosschaert wrote: I just got confirmation that the current trunk of the CXF-DOSGi passes the TCK again. Great news, thanks for the support from your side, It would be *really* good if we could release this version so that the Remote Services and RSA RI in the OSGi systems is a released version of CXF-DOSGi rather than a snapshot. Sergey, could I maybe ask you to do a release again? I'm planning to do a 1.3.1 release in the June/July time frame, few JIRAs have been opened against 1.3 so I'll try to address some of them too before cutting a new release. Here's a summary of the fixes: * Fixed exports from Single Bundle Distro * Fixed deadlock * Fixed cleanup * Fixed ExportReferenceImpl.equals() and hashCode() * Fixed RemoteServiceAdminCore.exportService() As these issues are all exposed by the OSGi TCK I didn't write any additional tests for them in the CXF-DOSGi codebase. As an aside. Note that it is possible for Apache committers to run the OSGi TCK. If anyone is interested let me know and I'll dig up the details. Is that info in the public domain ? If yes then may be you can add this info to the DOSGi wiki ? Thanks, Sergey Cheers, David On 13 March 2012 07:30, David Bosschaertdavid.bosscha...@gmail.com wrote: Just a little update on this. I made some more changes and at this point in time we're getting close. For me the OSGi Remote Services and Remote Service Admin TCKs are 100% passing but other people did report a failure that we have to investigate a little further. I'll chime in again when everything is good, as we could do a release at that point. Cheers, David On 20 February 2012 22:38, Sergey Beryozkinsberyoz...@gmail.com wrote: Hi David On 19/02/12 00:42, David Bosschaert wrote: Hi all, I was recently running the CXF-DOSGi 1.3 release through the OSGi TCK to make sure it's still compliant with the spec. It turned out that the changes made between 1.2 and 1.3 cause a number of TCK failures, so I've been looking at fixing them. Here's a quick summary. * the single-bundle distro (which is used with the TCK) now includes the org.osgi.enterprise-4.2.0.jar. This is fine, but it didn't export/import the types defined in there which meant that these types existed twice in the VM, once inside the single bundle distro and once outside. This caused issues with ConfigAdmin and some event types since communication with the outside world wasn't possible with these types any more. I fixed this for the single-bundle distro (it doesn't apply to the multi-bundle distro). * ExportReferenceImpl, which is really a wrapper, was used in a Map but missing hashCode and equals(). I added these. * There were some issues around close() calls not completely properly behaving, I fixed those * RemoteServiceAdminCore was putting objects of the wrong type in the collection returned by exportService() Some more changes may be needed in order to fully pass the TCK, but I've committed the above in r1290914. Cool, guess you are thinking about 1.3.1 already :-) Cheers, Sergey Cheers, David -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: svn commit: r1302802 - in /cxf/branches/2.5.x-fixes
Hi Freeman On 20/03/12 10:12, ff...@apache.org wrote: Author: ffang Date: Tue Mar 20 09:08:19 2012 New Revision: 1302802 URL: http://svn.apache.org/viewvc?rev=1302802view=rev Log: rt-transports-http module should optionally depend on spring Modified: cxf/branches/2.5.x-fixes/rt/bindings/http/pom.xml cxf/branches/2.5.x-fixes/rt/databinding/aegis/pom.xml cxf/branches/2.5.x-fixes/rt/databinding/xmlbeans/pom.xml cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml cxf/branches/2.5.x-fixes/rt/javascript/javascript-tests/pom.xml cxf/branches/2.5.x-fixes/rt/transports/http/pom.xml cxf/branches/2.5.x-fixes/systests/databinding/pom.xml cxf/branches/2.5.x-fixes/systests/jaxrs/pom.xml cxf/branches/2.5.x-fixes/systests/rs-security/pom.xml cxf/branches/2.5.x-fixes/systests/ws-security-examples/pom.xml cxf/branches/2.5.x-fixes/systests/ws-security/pom.xml cxf/branches/2.5.x-fixes/tools/javato/ws/pom.xml Modified: cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml URL: http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml?rev=1302802r1=1302801r2=1302802view=diff == --- cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml (original) +++ cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml Tue Mar 20 09:08:19 2012 @@ -182,6 +182,10 @@ artifactIdeasymock/artifactId scopetest/scope /dependency +dependency +groupIdorg.springframework/groupId +artifactIdspring-context/artifactId +/dependency /dependencies Did you mean to add a 'test' scope here like in all the other modules ? Cheers, Sergey
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Hi David On 20/03/12 11:00, David Bosschaert wrote: Hi Sergey, On 20 March 2012 09:47, Sergey Beryozkinsberyoz...@gmail.com wrote: Hi David On 20/03/12 08:00, David Bosschaert wrote: I just got confirmation that the current trunk of the CXF-DOSGi passes the TCK again. Great news, thanks for the support from your side, It would be *really* good if we could release this version so that the Remote Services and RSA RI in the OSGi systems is a released version of CXF-DOSGi rather than a snapshot. Sergey, could I maybe ask you to do a release again? I'm planning to do a 1.3.1 release in the June/July time frame, few JIRAs have been opened against 1.3 so I'll try to address some of them too before cutting a new release. The TCK compliance work I did was part of the OSGi 4.3 Compendium cycle and I expect that the RIs for that (of which CXF-DOSGi is part) will be collected soon - within 2 weeks is my guess, but I can get a more detailed deadline if needed. If we want a released version of CXF-DOSGi to be part of that RI, we need to have that release before then. Otherwise they'll take the current version which is based on a 1.4 snapshot... Would there be an issue with just releasing what's there now (read: really soon) and maybe do a 1.3.2 in June/July? I've never done an Apache release so I'm not really sure how much work is involved, but if it's just a matter of a few commands, I think it would be worth it doing it now - but obviously that all depends on time people have available too... How does this Compendium cycle work ? Having CXF DOSGi RI 'endorced' as TCK-compliant is a strong enough reason to try to cut an interim release in the next few weeks, however, I'm wondering, when would be DOSGi CXF 1.3.1 (released say in June/Jule) collected during the next cycle ? I guess you are right in won't take long to quickly do another release, my priorities are all on CXF 2.6.0 (and related projects) due in 2-3 weeks, but I guess this can be done quickly enough. Personally I'd prefer to have at least couple of user-reported issues addressed along the way but I definitely have no time for it now, So if the collection can be easily organized in the next few months then I'd prefer to wait till then, but if not doing this release now would mean the collection will happen in one year time then I guess we should go for it. Thoughts ? Here's a summary of the fixes: * Fixed exports from Single Bundle Distro * Fixed deadlock * Fixed cleanup * Fixed ExportReferenceImpl.equals() and hashCode() * Fixed RemoteServiceAdminCore.exportService() As these issues are all exposed by the OSGi TCK I didn't write any additional tests for them in the CXF-DOSGi codebase. As an aside. Note that it is possible for Apache committers to run the OSGi TCK. If anyone is interested let me know and I'll dig up the details. Is that info in the public domain ? If yes then may be you can add this info to the DOSGi wiki ? It is documented for Felix and Equinox projects that implement other OSGi specs, but I'll take an action item to document this on the DOSGi wiki as well. Sounds good, thanks Sergey Cheers, David -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Initial OAuth 2.0 support for CXF 2.6.0
Here is what we have at the moment: - support for the authorization code and implicit flows, the former is tested in a demo (to be highlighted later on), the latter is not yet - but it's very closely related to the former, it's redirection based so should be quite close to being supported well... - client_credentials, Things to do for 2.6.0: - fix java docs - documentation on the wiki - refresh token flow support - should be really simple, it's not really a flow, just a request to refresh, not a problem if postponed till later 2.6.x versions - few other minor fixes After 2.6.0 a go at the saml2 grants would need to be taken, we have a lot of supporting code in place already, but the challenge is to see how the OAuth2 data provider interface copes with such complex grant processors, I think once we do it then JWT, etc will be just supported really easy. The other enhancement which may be considered is support for OpenId-Connect - which is mostly about supporting so called code+token flows, OpenId itself will be managed by the 3rd party lib, and the support in CXF would be mostly about redirecting to the right endpoints :-) Sergey On 28/02/12 17:47, Sergey Beryozkin wrote: I've changed the package segment from oauth to oauth2 in the OAuth20 module to avoid the collision with the classes in OAuth 1.0 one, I was a bit nervous about 2 in oauth2 but at the then I thought it would be quite a few years (5-10 ?) before we start talking about OAuth 3.0 :-) so hopefully it will go okay...The other thing is that OAuth 2.0 is a new protocol completely though some similarities with OAuth 1.0 do remain, thus the scope for sharing the 'oauth' segment is pretty limited, possibly to very few support classes only Cheers, Sergey On 22/02/12 17:50, Sergey Beryozkin wrote: Hi, I added some initial code here: http://svn.apache.org/viewvc?rev=1292416view=rev now, the actual refactoring will start next :-). I think this code is not optimal mildly speaking :-), but I think we will tune it pretty quickly by building an authorization code flow demo against it... Cheers, Sergey On 20/02/12 17:52, Sergey Beryozkin wrote: Hi I've started working on the initial OAuth 2.0 support to be available in CXF 2.6.0 [1]. We already provide OAuth 1.0 support starting from CXF 2.5.0 [2] - this has been continuously enhanced during the last few months and I think it is capable enough for users seeking to write OAuth 1.0 applications with CXF to be able to rely upon it. However OAuth 2.0 [3], is really going to hit the mainstream IMHO soon enough and we are already seeing some demand for the OAuth 2.0 support. Thus I've started prototyping the initial code to do with supporting the OAuth 2.0 Authorization Code Grant [3] and the simple bearer token [4]; this combination is the closest to the OAuth 1.0 3-leg flow, further optimized by dropping the requirement to get a request token round trip. I'd like to keep the OAuth 1.0 code in 2.6.0 - there are quite a few OAuth 1.0 deployments out there and it would not surprise me if some users wanted to start with OAuth 1.0 gievn that it's well understood. Besides, despite OAuth 2.0 offering arguably a simpler alternative to the complete OAuth 1.0 flow, IMHO it is much more complex specification-wise. So I think we can see OAuth 1.0 being around for some time... The other thing I'd like to mention is the possibility of relying on the other OAuth 2.0 libraries such as Amber[5]. At the moment Amber has not been released yet. Personally I'll be open to reusing some of Amber's code or who knows even contributing back to the project, but at the moment I think it is simpler to prototype some base support within the CXF as opposed to trying to build it from the get go on the project code that has not been released yet. What is also important is that as far as CXF OAuth is concerned it is all about providing utility JAX-RS OAuth services with some additional utility support. The main complexity over time will come from the optional support for MAC or JWT tokens or say OpenId-Connect profiles. This is where we'd likely need some 'help' from the 3rd-party libraries. So for now I'm prototyping some code and hope to make the initial bits contributed in a week or so, may be earlier... Comments are welcome Sergey [1] https://issues.apache.org/jira/browse/CXF-4112 [2] http://cxf.apache.org/docs/jax-rs-oauth.html [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-23 [4] http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17 [5] http://incubator.apache.org/amber/
Re: CORS: removing allowOrigins from the annotation only
Hi Aki On 14/03/12 11:12, Aki Yoshida wrote: Hi Sergey, I am not familiar with this stuff, so what I am saying may not make sense, though :-) thanks for the comments, they make sense :-) But can you use the different default value so that you can distinguish between the null (i.e., interpreted as allowAllOrigins=true) and an empty allowOrigins (i.e., allowAllOrigins=false) ? I was just about to press commit when I saw your message :-). For the moment I restored that flag, as opposed to deleting the allowOrigins completely, one the basis that all other CrossOriginResourceSharing properties can equally be considered not method specific, but the endpoint specific... I briefly thought earlier on about the 'marker' value for allowOrigins, but the allowOrigins is an array, so having some marker value would probably complicate a bit the processing as one would need to also consider the case where valid and a marker properties are mixed in... Thanks, Sergey regards, aki 2012/3/14 Sergey Beryozkinsberyoz...@gmail.com: Hi Benson, all, I've been modifying the CrossOriginResourceSharing annotation as well as the CrossOriginResourceSharingFilter during the last couple of days to address the issue reported by Matt Bishop, namely, to do with making it possible to avoid specifying allowOrigins within the CrossOriginResourceSharing annotation, given that allowOrigins keeps the list of absolute URIs thus it is not ideal at all to have it declared in the actual code. CrossOriginResourceSharing used to have an 'allowAllOrigins' boolean property set by default to 'false' and also the 'allowOrigins' list/array property, the latter was ignored if 'allowAllOrigins' was set to true. Additionally, similar properties exist in CrossOriginResourceSharingFilter which can be effective when the annotation is not set on a given method. I started with removing what I thought was a redundant CrossOriginResourceSharing 'allowAllOrigins', instead assuming that an empty/default 'allowOrigins' does mean 'allow all origins'. The problem I'm seeing with this now that in order to be possible to avoid specifying specific 'allowOrigins' in the application code within CrossOriginResourceSharing one has to choose not to use CrossOriginResourceSharing because if it is provided it takes the preference over the possible custom values set in the filter. So one option is to restore the boolean allowAllOrigins flag. By default it is set to 'false'. Thus if CrossOriginResourceSharing' allowOrigins is empty then there must be a filter property set customizing the allowOrigins to meet the allowAllOrigins==false requirement. Another option is to remove CrossOriginResourceSharing' allowOrigins and expect the filter customize it when needed. The idea here is that it appears to be unlikely various individual methods within a current JAX-RS endpoint may have different allowed origins, rather it's more likely that the allowOrigins are going to be shared by all the JAX-RS methods for a given endpoint. So I kind of prefer the 2nd option but at the same time I'm OK with restoring the flag for the sake of simplifying the testing and such at a minor cost of keeping the somewhat redundant 'allowAllOrigins'... Let me know please what you think Cheers, Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: CORS: removing allowOrigins from the annotation only
One thing I forgot to mention from the start that the easy option is simply not to attach CrossOriginResourceSharing to a given resource method, so the filter values will be used instead. I'm only really about making sure that CrossOriginResourceSharing can still be used if preferred while only allowOrigins can be configured internally in the filter Cheers, Sergey On 14/03/12 11:19, Sergey Beryozkin wrote: Hi Aki On 14/03/12 11:12, Aki Yoshida wrote: Hi Sergey, I am not familiar with this stuff, so what I am saying may not make sense, though :-) thanks for the comments, they make sense :-) But can you use the different default value so that you can distinguish between the null (i.e., interpreted as allowAllOrigins=true) and an empty allowOrigins (i.e., allowAllOrigins=false) ? I was just about to press commit when I saw your message :-). For the moment I restored that flag, as opposed to deleting the allowOrigins completely, one the basis that all other CrossOriginResourceSharing properties can equally be considered not method specific, but the endpoint specific... I briefly thought earlier on about the 'marker' value for allowOrigins, but the allowOrigins is an array, so having some marker value would probably complicate a bit the processing as one would need to also consider the case where valid and a marker properties are mixed in... Thanks, Sergey regards, aki 2012/3/14 Sergey Beryozkinsberyoz...@gmail.com: Hi Benson, all, I've been modifying the CrossOriginResourceSharing annotation as well as the CrossOriginResourceSharingFilter during the last couple of days to address the issue reported by Matt Bishop, namely, to do with making it possible to avoid specifying allowOrigins within the CrossOriginResourceSharing annotation, given that allowOrigins keeps the list of absolute URIs thus it is not ideal at all to have it declared in the actual code. CrossOriginResourceSharing used to have an 'allowAllOrigins' boolean property set by default to 'false' and also the 'allowOrigins' list/array property, the latter was ignored if 'allowAllOrigins' was set to true. Additionally, similar properties exist in CrossOriginResourceSharingFilter which can be effective when the annotation is not set on a given method. I started with removing what I thought was a redundant CrossOriginResourceSharing 'allowAllOrigins', instead assuming that an empty/default 'allowOrigins' does mean 'allow all origins'. The problem I'm seeing with this now that in order to be possible to avoid specifying specific 'allowOrigins' in the application code within CrossOriginResourceSharing one has to choose not to use CrossOriginResourceSharing because if it is provided it takes the preference over the possible custom values set in the filter. So one option is to restore the boolean allowAllOrigins flag. By default it is set to 'false'. Thus if CrossOriginResourceSharing' allowOrigins is empty then there must be a filter property set customizing the allowOrigins to meet the allowAllOrigins==false requirement. Another option is to remove CrossOriginResourceSharing' allowOrigins and expect the filter customize it when needed. The idea here is that it appears to be unlikely various individual methods within a current JAX-RS endpoint may have different allowed origins, rather it's more likely that the allowOrigins are going to be shared by all the JAX-RS methods for a given endpoint. So I kind of prefer the 2nd option but at the same time I'm OK with restoring the flag for the sake of simplifying the testing and such at a minor cost of keeping the somewhat redundant 'allowAllOrigins'... Let me know please what you think Cheers, Sergey
Re: CORS: removing allowOrigins from the annotation only
It appears that these 'difficulties' with allowAllOrigins allowOrigins clearly indicate that the original Benson's idea to get one annotation per every property in [1] did have a lot of sense, however having the explosion of annotations seemed too much to me at the time. That said, I did also move the localPreflight property into a dedicated annotation[2] as it does not seem to belong to the main [1] Hope everyone is OK with it Sergey [1] http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/cors/src/main/java/org/apache/cxf/rs/security/cors/CrossOriginResourceSharing.java [2] http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/cors/src/main/java/org/apache/cxf/rs/security/cors/LocalPreflight.java On 14/03/12 11:22, Sergey Beryozkin wrote: One thing I forgot to mention from the start that the easy option is simply not to attach CrossOriginResourceSharing to a given resource method, so the filter values will be used instead. I'm only really about making sure that CrossOriginResourceSharing can still be used if preferred while only allowOrigins can be configured internally in the filter Cheers, Sergey On 14/03/12 11:19, Sergey Beryozkin wrote: Hi Aki On 14/03/12 11:12, Aki Yoshida wrote: Hi Sergey, I am not familiar with this stuff, so what I am saying may not make sense, though :-) thanks for the comments, they make sense :-) But can you use the different default value so that you can distinguish between the null (i.e., interpreted as allowAllOrigins=true) and an empty allowOrigins (i.e., allowAllOrigins=false) ? I was just about to press commit when I saw your message :-). For the moment I restored that flag, as opposed to deleting the allowOrigins completely, one the basis that all other CrossOriginResourceSharing properties can equally be considered not method specific, but the endpoint specific... I briefly thought earlier on about the 'marker' value for allowOrigins, but the allowOrigins is an array, so having some marker value would probably complicate a bit the processing as one would need to also consider the case where valid and a marker properties are mixed in... Thanks, Sergey regards, aki 2012/3/14 Sergey Beryozkinsberyoz...@gmail.com: Hi Benson, all, I've been modifying the CrossOriginResourceSharing annotation as well as the CrossOriginResourceSharingFilter during the last couple of days to address the issue reported by Matt Bishop, namely, to do with making it possible to avoid specifying allowOrigins within the CrossOriginResourceSharing annotation, given that allowOrigins keeps the list of absolute URIs thus it is not ideal at all to have it declared in the actual code. CrossOriginResourceSharing used to have an 'allowAllOrigins' boolean property set by default to 'false' and also the 'allowOrigins' list/array property, the latter was ignored if 'allowAllOrigins' was set to true. Additionally, similar properties exist in CrossOriginResourceSharingFilter which can be effective when the annotation is not set on a given method. I started with removing what I thought was a redundant CrossOriginResourceSharing 'allowAllOrigins', instead assuming that an empty/default 'allowOrigins' does mean 'allow all origins'. The problem I'm seeing with this now that in order to be possible to avoid specifying specific 'allowOrigins' in the application code within CrossOriginResourceSharing one has to choose not to use CrossOriginResourceSharing because if it is provided it takes the preference over the possible custom values set in the filter. So one option is to restore the boolean allowAllOrigins flag. By default it is set to 'false'. Thus if CrossOriginResourceSharing' allowOrigins is empty then there must be a filter property set customizing the allowOrigins to meet the allowAllOrigins==false requirement. Another option is to remove CrossOriginResourceSharing' allowOrigins and expect the filter customize it when needed. The idea here is that it appears to be unlikely various individual methods within a current JAX-RS endpoint may have different allowed origins, rather it's more likely that the allowOrigins are going to be shared by all the JAX-RS methods for a given endpoint. So I kind of prefer the 2nd option but at the same time I'm OK with restoring the flag for the sake of simplifying the testing and such at a minor cost of keeping the somewhat redundant 'allowAllOrigins'... Let me know please what you think Cheers, Sergey
CORS: removing allowOrigins from the annotation only
Hi Benson, all, I've been modifying the CrossOriginResourceSharing annotation as well as the CrossOriginResourceSharingFilter during the last couple of days to address the issue reported by Matt Bishop, namely, to do with making it possible to avoid specifying allowOrigins within the CrossOriginResourceSharing annotation, given that allowOrigins keeps the list of absolute URIs thus it is not ideal at all to have it declared in the actual code. CrossOriginResourceSharing used to have an 'allowAllOrigins' boolean property set by default to 'false' and also the 'allowOrigins' list/array property, the latter was ignored if 'allowAllOrigins' was set to true. Additionally, similar properties exist in CrossOriginResourceSharingFilter which can be effective when the annotation is not set on a given method. I started with removing what I thought was a redundant CrossOriginResourceSharing 'allowAllOrigins', instead assuming that an empty/default 'allowOrigins' does mean 'allow all origins'. The problem I'm seeing with this now that in order to be possible to avoid specifying specific 'allowOrigins' in the application code within CrossOriginResourceSharing one has to choose not to use CrossOriginResourceSharing because if it is provided it takes the preference over the possible custom values set in the filter. So one option is to restore the boolean allowAllOrigins flag. By default it is set to 'false'. Thus if CrossOriginResourceSharing' allowOrigins is empty then there must be a filter property set customizing the allowOrigins to meet the allowAllOrigins==false requirement. Another option is to remove CrossOriginResourceSharing' allowOrigins and expect the filter customize it when needed. The idea here is that it appears to be unlikely various individual methods within a current JAX-RS endpoint may have different allowed origins, rather it's more likely that the allowOrigins are going to be shared by all the JAX-RS methods for a given endpoint. So I kind of prefer the 2nd option but at the same time I'm OK with restoring the flag for the sake of simplifying the testing and such at a minor cost of keeping the somewhat redundant 'allowAllOrigins'... Let me know please what you think Cheers, Sergey
Re: svn commit: r1295714
Hi Aki,
Thanks for fixing this issue.
As far as I recall, the written uris property was added to address
https://issues.apache.org/jira/browse/CXF-3958
I can get the test added asap just to confirm the fix you provided will
also do for CXF-3958
Thanks, Sergey
On 01/03/12 17:58, a...@apache.org wrote:
Author: ay
Date: Thu Mar 1 17:58:19 2012
New Revision: 1295714
URL: http://svn.apache.org/viewvc?rev=1295714view=rev
Log:
[CXF-4150] Transform feature's OutTransformWriter may not correctly generate
namespace declarations
Added:
cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/resources/wstrustReqSTRC.xml
(with props)
cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/resources/wstrustReqSTRCIn1.xml
(with props)
Modified:
cxf/trunk/api/src/main/java/org/apache/cxf/staxutils/transform/OutTransformWriter.java
cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/transform/InTransformReaderTest.java
cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/transform/OutTransformWriterTest.java
Modified:
cxf/trunk/api/src/main/java/org/apache/cxf/staxutils/transform/OutTransformWriter.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/api/src/main/java/org/apache/cxf/staxutils/transform/OutTransformWriter.java?rev=1295714r1=1295713r2=1295714view=diff
==
---
cxf/trunk/api/src/main/java/org/apache/cxf/staxutils/transform/OutTransformWriter.java
(original)
+++
cxf/trunk/api/src/main/java/org/apache/cxf/staxutils/transform/OutTransformWriter.java
Thu Mar 1 17:58:19 2012
@@ -20,8 +20,6 @@ package org.apache.cxf.staxutils.transfo
import java.util.ArrayList;
import java.util.HashMap;
-import java.util.HashSet;
-import java.util.LinkedList;
import java.util.List;
import java.util.Map;
import java.util.Set;
@@ -43,7 +41,6 @@ public class OutTransformWriter extends
private QNamesMap attributesMap;
private MapQName, ElementProperty appendMap = new HashMapQName,
ElementProperty(5);
private MapString, String nsMap = new HashMapString, String(5);
-private ListSetString writtenUris = new LinkedListSetString();
private SetQName dropElements;
private StackListParsingEvent pushedAheadEvents = new
StackListParsingEvent();
@@ -96,7 +93,7 @@ public class OutTransformWriter extends
uri = value != null ? value : uri;
-if (writtenUris.get(0).contains(uri)) {
+if (prefix.equals(getPrefix(uri))) {
return;
}
@@ -108,7 +105,6 @@ public class OutTransformWriter extends
}
super.writeNamespace(prefix, uri);
}
-writtenUris.get(0).add(uri);
}
@Override
@@ -117,13 +113,6 @@ public class OutTransformWriter extends
if (matchesDropped(false)) {
return;
}
-SetString s;
-if (writtenUris.isEmpty()) {
-s = new HashSetString();
-} else {
-s = new HashSetString(writtenUris.get(0));
-}
-writtenUris.add(0, s);
final QName theName = new QName(uri, local, prefix);
final ElementProperty appendProp = appendMap.remove(theName);
@@ -243,9 +232,7 @@ public class OutTransformWriter extends
} else if (dropDepth 0) {
dropDepth = 0;
}
-if (!writtenUris.isEmpty()) {
-writtenUris.remove(0);
-}
+
QName theName = elementsStack.pop();
final boolean dropped = dropElements.contains(theName);
if (!dropped) {
Added:
cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/resources/wstrustReqSTRC.xml
URL:
http://svn.apache.org/viewvc/cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/resources/wstrustReqSTRC.xml?rev=1295714view=auto
==
Binary file - no diff available.
Propchange:
cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/resources/wstrustReqSTRC.xml
--
svn:mime-type = application/xml
Added:
cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/resources/wstrustReqSTRCIn1.xml
URL:
http://svn.apache.org/viewvc/cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/resources/wstrustReqSTRCIn1.xml?rev=1295714view=auto
==
Binary file - no diff available.
Propchange:
cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/resources/wstrustReqSTRCIn1.xml
--
svn:mime-type = application/xml
Modified:
cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/transform/InTransformReaderTest.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/transform/InTransformReaderTest.java?rev=1295714r1=1295713r2=1295714view=diff
Re: svn commit: r1295714
Sure... I have to sign off at the moment, will look asap tomorrow,
thanks, Sergey
On 01/03/12 22:15, Daniel Kulp wrote:
On Thursday, March 01, 2012 10:01:59 PM Sergey Beryozkin wrote:
Hi Aki,
Thanks for fixing this issue.
As far as I recall, the written uris property was added to address
https://issues.apache.org/jira/browse/CXF-3958
I can get the test added asap just to confirm the fix you provided will
also do for CXF-3958
Well, it was modified for CXF-3958, not added.
However, with this change, I am seeing test failures which Jenkins is seeing as
well:
https://builds.apache.org/view/A-F/view/CXF/job/CXF-Trunk-JDK15/org.apache.cxf.systests$cxf-systests-jaxrs/3065/testReport/
So that definitely needs to be addresed.
Dan
Thanks, Sergey
On 01/03/12 17:58, a...@apache.org wrote:
Author: ay
Date: Thu Mar 1 17:58:19 2012
New Revision: 1295714
URL: http://svn.apache.org/viewvc?rev=1295714view=rev
Log:
[CXF-4150] Transform feature's OutTransformWriter may not correctly
generate namespace declarations
Added:
cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/resources/wstrus
tReqSTRC.xml (with props)
cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/resources/wstru
stReqSTRCIn1.xml (with props)
Modified:
cxf/trunk/api/src/main/java/org/apache/cxf/staxutils/transform/OutTra
nsformWriter.java
cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/transform/InTra
nsformReaderTest.java
cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/transform/OutTr
ansformWriterTest.java
Modified:
cxf/trunk/api/src/main/java/org/apache/cxf/staxutils/transform/OutTransfo
rmWriter.java URL:
http://svn.apache.org/viewvc/cxf/trunk/api/src/main/java/org/apache/cxf/s
taxutils/transform/OutTransformWriter.java?rev=1295714r1=1295713r2=12957
14view=diff
=
= ---
cxf/trunk/api/src/main/java/org/apache/cxf/staxutils/transform/OutTransfo
rmWriter.java (original) +++
cxf/trunk/api/src/main/java/org/apache/cxf/staxutils/transform/OutTransfo
rmWriter.java Thu Mar 1 17:58:19 2012 @@ -20,8 +20,6 @@ package
org.apache.cxf.staxutils.transfo
import java.util.ArrayList;
import java.util.HashMap;
-import java.util.HashSet;
-import java.util.LinkedList;
import java.util.List;
import java.util.Map;
import java.util.Set;
@@ -43,7 +41,6 @@ public class OutTransformWriter extends
private QNamesMap attributesMap;
private MapQName, ElementProperty appendMap = new HashMapQName,
ElementProperty(5); private MapString, String nsMap = new
HashMapString, String(5);
-private ListSetString writtenUris = new
LinkedListSetString();
private SetQName dropElements;
private StackListParsingEvent pushedAheadEvents = new
StackListParsingEvent();
@@ -96,7 +93,7 @@ public class OutTransformWriter extends
uri = value != null ? value : uri;
-if (writtenUris.get(0).contains(uri)) {
+if (prefix.equals(getPrefix(uri))) {
return;
}
@@ -108,7 +105,6 @@ public class OutTransformWriter extends
}
super.writeNamespace(prefix, uri);
}
-writtenUris.get(0).add(uri);
}
@Override
@@ -117,13 +113,6 @@ public class OutTransformWriter extends
if (matchesDropped(false)) {
return;
}
-SetString s;
-if (writtenUris.isEmpty()) {
-s = new HashSetString();
-} else {
-s = new HashSetString(writtenUris.get(0));
-}
-writtenUris.add(0, s);
final QName theName = new QName(uri, local, prefix);
final ElementProperty appendProp = appendMap.remove(theName);
@@ -243,9 +232,7 @@ public class OutTransformWriter extends
} else if (dropDepth 0) {
dropDepth = 0;
}
-if (!writtenUris.isEmpty()) {
-writtenUris.remove(0);
-}
+
QName theName = elementsStack.pop();
final boolean dropped = dropElements.contains(theName);
if (!dropped) {
Added:
cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/resources/wstrustReq
STRC.xml URL:
http://svn.apache.org/viewvc/cxf/trunk/api/src/test/java/org/apache/cxf/s
taxutils/resources/wstrustReqSTRC.xml?rev=1295714view=auto
=
= Binary file - no diff available.
Propchange:
cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/resources/wstrustReq
STRC.xml
-
-
svn:mime-type = application/xml
Added:
cxf/trunk/api/src/test/java/org/apache/cxf/staxutils/resources/wstrustReq
STRCIn1.xml URL:
http://svn.apache.org/viewvc/cxf/trunk/api/src/test/java/org/apache/cxf/s
taxutils/resources/wstrustReqSTRCIn1.xml?rev=1295714view=auto
Re: svn commit: r1293213 - /cxf/trunk/rt/rs/security/xml/src/main/java/org/apache/cxf/rs/security/xml/EncryptionUtils.java
Wow, thanks Colm :-) The black magic security stuff in action :-)
Cheers, Sergey
On 24/02/12 12:17, cohei...@apache.org wrote:
Author: coheigea
Date: Fri Feb 24 12:17:22 2012
New Revision: 1293213
URL: http://svn.apache.org/viewvc?rev=1293213view=rev
Log:
Fixed failing RS-Security tests with the IBM JDK and Santuario 1.5.x
Modified:
cxf/trunk/rt/rs/security/xml/src/main/java/org/apache/cxf/rs/security/xml/EncryptionUtils.java
Modified:
cxf/trunk/rt/rs/security/xml/src/main/java/org/apache/cxf/rs/security/xml/EncryptionUtils.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/rs/security/xml/src/main/java/org/apache/cxf/rs/security/xml/EncryptionUtils.java?rev=1293213r1=1293212r2=1293213view=diff
==
---
cxf/trunk/rt/rs/security/xml/src/main/java/org/apache/cxf/rs/security/xml/EncryptionUtils.java
(original)
+++
cxf/trunk/rt/rs/security/xml/src/main/java/org/apache/cxf/rs/security/xml/EncryptionUtils.java
Fri Feb 24 12:17:22 2012
@@ -18,11 +18,15 @@
*/
package org.apache.cxf.rs.security.xml;
+import java.security.InvalidAlgorithmParameterException;
import java.security.InvalidKeyException;
import java.security.Key;
import java.security.cert.X509Certificate;
+import java.security.spec.MGF1ParameterSpec;
import javax.crypto.Cipher;
+import javax.crypto.spec.OAEPParameterSpec;
+import javax.crypto.spec.PSource;
import org.apache.ws.security.WSSecurityException;
import org.apache.ws.security.util.WSSecurityUtil;
@@ -38,11 +42,25 @@ public final class EncryptionUtils {
throws WSSecurityException {
Cipher cipher = WSSecurityUtil.getCipherInstance(keyEncAlgo);
try {
-cipher.init(mode, cert);
+OAEPParameterSpec oaepParameterSpec = null;
+if (XMLCipher.RSA_OAEP.equals(keyEncAlgo)) {
+oaepParameterSpec = new OAEPParameterSpec(
+SHA-1, MGF1, new MGF1ParameterSpec(SHA-1),
PSource.PSpecified.DEFAULT
+);
+}
+if (oaepParameterSpec == null) {
+cipher.init(mode, cert);
+} else {
+cipher.init(mode, cert.getPublicKey(), oaepParameterSpec);
+}
} catch (InvalidKeyException e) {
throw new WSSecurityException(
WSSecurityException.FAILED_ENCRYPTION, null, null, e
);
+} catch (InvalidAlgorithmParameterException e) {
+throw new WSSecurityException(
+WSSecurityException.FAILED_ENCRYPTION, null, null, e
+);
}
return cipher;
}
@@ -51,11 +69,25 @@ public final class EncryptionUtils {
throws WSSecurityException {
Cipher cipher = WSSecurityUtil.getCipherInstance(keyEncAlgo);
try {
-cipher.init(mode, key);
+OAEPParameterSpec oaepParameterSpec = null;
+if (XMLCipher.RSA_OAEP.equals(keyEncAlgo)) {
+oaepParameterSpec = new OAEPParameterSpec(
+SHA-1, MGF1, new MGF1ParameterSpec(SHA-1),
PSource.PSpecified.DEFAULT
+);
+}
+if (oaepParameterSpec == null) {
+cipher.init(mode, key);
+} else {
+cipher.init(mode, key, oaepParameterSpec);
+}
} catch (InvalidKeyException e) {
throw new WSSecurityException(
WSSecurityException.FAILED_ENCRYPTION, null, null, e
);
+} catch (InvalidAlgorithmParameterException e) {
+throw new WSSecurityException(
+WSSecurityException.FAILED_ENCRYPTION, null, null, e
+);
}
return cipher;
}
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: svn commit: r1293413 - in /cxf/trunk/systests/rs-security: pom.xml src/test/java/org/apache/cxf/systest/jaxrs/security/oauth/TemporaryCredentialServiceTest.java
Hi Aki
On 24/02/12 21:14, Aki Yoshida wrote:
Hi Sergey,
I was having a problem in building 2.5.x and trunk in a restricted
fresh environment, then I noticed that systests/rs-security was still
referring to cxf-rt-rs-security-oauth-test which no longer existed in
2.5.x and trunk. I saw the corresponding classes now exist in
systests/rs-security's test package.
However, because of this reference, the test itself was currently
picking up some older snapshot version of those classes from the
apache repos. I removed this reference so that the test uses those
corresponding classes in the same test package. Unfortunately, there
seems to have been some change between the older version and the one
in the test package that is causing one of the tests to fail. So, I
temporarily disabled this test. Could you take a look into it?
I'll take a look, should be something minor
thanks, Sergey
Thanks.
Regards, aki
2012/2/24a...@apache.org:
Author: ay
Date: Fri Feb 24 20:56:37 2012
New Revision: 1293413
URL: http://svn.apache.org/viewvc?rev=1293413view=rev
Log:
remove unexistent cxf-rt-rs-security-oauth-test ref from systests/rs-security
Modified:
cxf/trunk/systests/rs-security/pom.xml
cxf/trunk/systests/rs-security/src/test/java/org/apache/cxf/systest/jaxrs/security/oauth/TemporaryCredentialServiceTest.java
Modified: cxf/trunk/systests/rs-security/pom.xml
URL:
http://svn.apache.org/viewvc/cxf/trunk/systests/rs-security/pom.xml?rev=1293413r1=1293412r2=1293413view=diff
==
--- cxf/trunk/systests/rs-security/pom.xml (original)
+++ cxf/trunk/systests/rs-security/pom.xml Fri Feb 24 20:56:37 2012
@@ -84,12 +84,6 @@
/dependency
dependency
groupIdorg.apache.cxf/groupId
-artifactIdcxf-rt-rs-security-oauth-test/artifactId
-version${project.version}/version
-scopetest/scope
-/dependency
-dependency
-groupIdorg.apache.cxf/groupId
artifactIdcxf-rt-transports-http/artifactId
version${project.version}/version
/dependency
Modified:
cxf/trunk/systests/rs-security/src/test/java/org/apache/cxf/systest/jaxrs/security/oauth/TemporaryCredentialServiceTest.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/systests/rs-security/src/test/java/org/apache/cxf/systest/jaxrs/security/oauth/TemporaryCredentialServiceTest.java?rev=1293413r1=1293412r2=1293413view=diff
==
---
cxf/trunk/systests/rs-security/src/test/java/org/apache/cxf/systest/jaxrs/security/oauth/TemporaryCredentialServiceTest.java
(original)
+++
cxf/trunk/systests/rs-security/src/test/java/org/apache/cxf/systest/jaxrs/security/oauth/TemporaryCredentialServiceTest.java
Fri Feb 24 20:56:37 2012
@@ -34,13 +34,13 @@ import net.oauth.ParameterStyle;
import org.apache.cxf.common.logging.LogUtils;
import org.apache.cxf.common.util.StringUtils;
-import org.apache.cxf.rs.security.oauth.test.OAuthTestUtils;
import org.apache.cxf.testutil.common.AbstractBusClientServerTestBase;
import org.eclipse.jetty.http.HttpHeaders;
import org.junit.Assert;
import org.junit.BeforeClass;
+import org.junit.Ignore;
import org.junit.Test;
public class TemporaryCredentialServiceTest extends
AbstractBusClientServerTestBase {
@@ -56,6 +56,7 @@ public class TemporaryCredentialServiceT
launchServer(OAuthServer.class, true));
}
+@Ignore
@Test
public void testGetTemporaryCredentialsURIQuery() throws Exception {
MapString, String parameters = new HashMapString, String();
Re: Initial OAuth 2.0 support for CXF 2.6.0
Hi, I added some initial code here: http://svn.apache.org/viewvc?rev=1292416view=rev now, the actual refactoring will start next :-). I think this code is not optimal mildly speaking :-), but I think we will tune it pretty quickly by building an authorization code flow demo against it... Cheers, Sergey On 20/02/12 17:52, Sergey Beryozkin wrote: Hi I've started working on the initial OAuth 2.0 support to be available in CXF 2.6.0 [1]. We already provide OAuth 1.0 support starting from CXF 2.5.0 [2] - this has been continuously enhanced during the last few months and I think it is capable enough for users seeking to write OAuth 1.0 applications with CXF to be able to rely upon it. However OAuth 2.0 [3], is really going to hit the mainstream IMHO soon enough and we are already seeing some demand for the OAuth 2.0 support. Thus I've started prototyping the initial code to do with supporting the OAuth 2.0 Authorization Code Grant [3] and the simple bearer token [4]; this combination is the closest to the OAuth 1.0 3-leg flow, further optimized by dropping the requirement to get a request token round trip. I'd like to keep the OAuth 1.0 code in 2.6.0 - there are quite a few OAuth 1.0 deployments out there and it would not surprise me if some users wanted to start with OAuth 1.0 gievn that it's well understood. Besides, despite OAuth 2.0 offering arguably a simpler alternative to the complete OAuth 1.0 flow, IMHO it is much more complex specification-wise. So I think we can see OAuth 1.0 being around for some time... The other thing I'd like to mention is the possibility of relying on the other OAuth 2.0 libraries such as Amber[5]. At the moment Amber has not been released yet. Personally I'll be open to reusing some of Amber's code or who knows even contributing back to the project, but at the moment I think it is simpler to prototype some base support within the CXF as opposed to trying to build it from the get go on the project code that has not been released yet. What is also important is that as far as CXF OAuth is concerned it is all about providing utility JAX-RS OAuth services with some additional utility support. The main complexity over time will come from the optional support for MAC or JWT tokens or say OpenId-Connect profiles. This is where we'd likely need some 'help' from the 3rd-party libraries. So for now I'm prototyping some code and hope to make the initial bits contributed in a week or so, may be earlier... Comments are welcome Sergey [1] https://issues.apache.org/jira/browse/CXF-4112 [2] http://cxf.apache.org/docs/jax-rs-oauth.html [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-23 [4] http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17 [5] http://incubator.apache.org/amber/ -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Initial OAuth 2.0 support for CXF 2.6.0
Hi I've started working on the initial OAuth 2.0 support to be available in CXF 2.6.0 [1]. We already provide OAuth 1.0 support starting from CXF 2.5.0 [2] - this has been continuously enhanced during the last few months and I think it is capable enough for users seeking to write OAuth 1.0 applications with CXF to be able to rely upon it. However OAuth 2.0 [3], is really going to hit the mainstream IMHO soon enough and we are already seeing some demand for the OAuth 2.0 support. Thus I've started prototyping the initial code to do with supporting the OAuth 2.0 Authorization Code Grant [3] and the simple bearer token [4]; this combination is the closest to the OAuth 1.0 3-leg flow, further optimized by dropping the requirement to get a request token round trip. I'd like to keep the OAuth 1.0 code in 2.6.0 - there are quite a few OAuth 1.0 deployments out there and it would not surprise me if some users wanted to start with OAuth 1.0 gievn that it's well understood. Besides, despite OAuth 2.0 offering arguably a simpler alternative to the complete OAuth 1.0 flow, IMHO it is much more complex specification-wise. So I think we can see OAuth 1.0 being around for some time... The other thing I'd like to mention is the possibility of relying on the other OAuth 2.0 libraries such as Amber[5]. At the moment Amber has not been released yet. Personally I'll be open to reusing some of Amber's code or who knows even contributing back to the project, but at the moment I think it is simpler to prototype some base support within the CXF as opposed to trying to build it from the get go on the project code that has not been released yet. What is also important is that as far as CXF OAuth is concerned it is all about providing utility JAX-RS OAuth services with some additional utility support. The main complexity over time will come from the optional support for MAC or JWT tokens or say OpenId-Connect profiles. This is where we'd likely need some 'help' from the 3rd-party libraries. So for now I'm prototyping some code and hope to make the initial bits contributed in a week or so, may be earlier... Comments are welcome Sergey [1] https://issues.apache.org/jira/browse/CXF-4112 [2] http://cxf.apache.org/docs/jax-rs-oauth.html [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-23 [4] http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17 [5] http://incubator.apache.org/amber/
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Hi David On 19/02/12 00:42, David Bosschaert wrote: Hi all, I was recently running the CXF-DOSGi 1.3 release through the OSGi TCK to make sure it's still compliant with the spec. It turned out that the changes made between 1.2 and 1.3 cause a number of TCK failures, so I've been looking at fixing them. Here's a quick summary. * the single-bundle distro (which is used with the TCK) now includes the org.osgi.enterprise-4.2.0.jar. This is fine, but it didn't export/import the types defined in there which meant that these types existed twice in the VM, once inside the single bundle distro and once outside. This caused issues with ConfigAdmin and some event types since communication with the outside world wasn't possible with these types any more. I fixed this for the single-bundle distro (it doesn't apply to the multi-bundle distro). * ExportReferenceImpl, which is really a wrapper, was used in a Map but missing hashCode and equals(). I added these. * There were some issues around close() calls not completely properly behaving, I fixed those * RemoteServiceAdminCore was putting objects of the wrong type in the collection returned by exportService() Some more changes may be needed in order to fully pass the TCK, but I've committed the above in r1290914. Cool, guess you are thinking about 1.3.1 already :-) Cheers, Sergey Cheers, David
Logging interceptors and binary payloads
Hi
I'd like to get the Logging interceptors updated to report the 'pure'
binary payload only optionally. Right now I'm working on a demo where an
image payload is uploaded and then returned and I'm finding it difficult
to view through the logs with the binary content being logged.
So I'd like to suggest that only a string 'representing' such a payload
is logged, example:
ID: 41
Response-Code: 200
Content-Type: image/png
Headers: {Date=[Mon, 13 Feb 2012 11:30:40 GMT], Content-Length=[18522]}
Messages: --- Binary Content ---
where --- Binary Content --- replaces the actual 18K binary data.
If really needed showing the binary payload can be enforced by setting a
relevant property. For a start, application/octet-stream and image/*
media types are checked...
I've attached a patch to [1], I'll apply it a bit later on if we agree
it does make sense.
Thanks, Sergey
[1] https://issues.apache.org/jira/browse/CXF-4102
Re: Logging interceptors and binary payloads
Hi,
On 13/02/12 15:46, Daniel Kulp wrote:
Looks OK to me. The only additional suggestion I have is to add the flags to
the @Logging annotation as well to keep that consistent and up to date.
Sure, added a 'showBinary' annotation property, set to 'false' by default.
I will also investigate later on how to deal with multipart/* without
having too many temp files created, I thought may be we can get
SequenceInputStream, with some individual InputStreams set to ---
Binary Content---,
thanks, Sergey
Dan
On Monday, February 13, 2012 11:47:12 AM Sergey Beryozkin wrote:
Hi
I'd like to get the Logging interceptors updated to report the 'pure'
binary payload only optionally. Right now I'm working on a demo where an
image payload is uploaded and then returned and I'm finding it difficult
to view through the logs with the binary content being logged.
So I'd like to suggest that only a string 'representing' such a payload
is logged, example:
ID: 41
Response-Code: 200
Content-Type: image/png
Headers: {Date=[Mon, 13 Feb 2012 11:30:40 GMT], Content-Length=[18522]}
Messages: --- Binary Content ---
where --- Binary Content --- replaces the actual 18K binary data.
If really needed showing the binary payload can be enforced by setting a
relevant property. For a start, application/octet-stream and image/*
media types are checked...
I've attached a patch to [1], I'll apply it a bit later on if we agree
it does make sense.
Thanks, Sergey
[1] https://issues.apache.org/jira/browse/CXF-4102
Re: [VOTE] Apache DOSGi 1.3 Release
We have 6 binding +1 votes, I'm going to promote the artifacts shortly Thanks, Sergey On 02/02/12 13:33, Sergey Beryozkin wrote: Apache CXF DOSGI subproject is a Reference Implementation of the OSGI Remote Services Specification which offers an alternative approach toward dynamically deploying and updating remote service endpoints and consumers using the OSGI programming model. We have been working on the 1.3 release during the last 2 months and have resolved about 15 issues: http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.3/distribution/sources/src/main/release/release_notes.txt Apache CXF 2.5.2 JAX-WS and JAX-RS runtimes are used internally to create the web service endpoints and consumers. The staging area: https://repository.apache.org/content/repositories/orgapachecxf-178/ This vote will be open for at least 72 hours. Here is my +1. Sergey
Re: JAX-RS: Is anyone using CodeGeneratorProvider
On 02/02/12 15:04, Sergey Beryozkin wrote: Hi, I'm thinking of deleting CodeGeneratorProvider [1] for 2.6 only, given that it seems to be redundant now that we have a wadl2java command line tool and plugin. The idea behind CodeGeneratorProvider has been that one can just quickly download a zipped source from the dev/test service endpoint, compile, enhance a bit and test, but with the wadl2java tools it is not needed any more. One can get an existing WADL or use the one generated by CXF and feed it into a wadl code generator locally... Does anyone feel it should be kept nonetheless and if yes then why ? Let me know please, as I'm planning to remove it in the next few days. This will also let me move the SourceGenerator code which CodeGeneratorProvider relies upon to the tools/wadl, where it does belong... I proceeded with this move as it appears it is unlikely any is using this provider...This change is only for 2.6, ping me please if you feel it is still needed. At any time in the future we can get a dedicated codegen module which will keep both SourceGenerator and (restored) CodeGeneratorProvider code if there's some demand for it But for now it's one more step toward simplifying the jaxrs frontend a bit Cheers, Sergey Thanks, Sergey [1] http://cxf.apache.org/docs/jaxrs-services-description.html#JAXRSServicesDescription-GeneratingtheclientcodefromWADLatruntime
Re: svn commit: r1240347 - in /cxf/branches/2.4.x-fixes: ./ systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/BookSubresourceImpl.java
Dan , thanks for taking care of it,
Sergey
On 03/02/12 21:31, dk...@apache.org wrote:
Author: dkulp
Date: Fri Feb 3 21:31:23 2012
New Revision: 1240347
URL: http://svn.apache.org/viewvc?rev=1240347view=rev
Log:
Merged revisions 1240326 via svnmerge from
https://svn.apache.org/repos/asf/cxf/branches/2.5.x-fixes
r1240326 | dkulp | 2012-02-03 15:05:40 -0500 (Fri, 03 Feb 2012) | 9 lines
Merged revisions 1240325 via svnmerge from
https://svn.apache.org/repos/asf/cxf/trunk
r1240325 | dkulp | 2012-02-03 15:04:29 -0500 (Fri, 03 Feb 2012) | 1 line
Remove @Override annotation
Modified:
cxf/branches/2.4.x-fixes/ (props changed)
cxf/branches/2.4.x-fixes/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/BookSubresourceImpl.java
Propchange: cxf/branches/2.4.x-fixes/
('svn:mergeinfo' removed)
Propchange: cxf/branches/2.4.x-fixes/
--
Binary property 'svnmerge-integrated' - no diff available.
Modified:
cxf/branches/2.4.x-fixes/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/BookSubresourceImpl.java
URL:
http://svn.apache.org/viewvc/cxf/branches/2.4.x-fixes/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/BookSubresourceImpl.java?rev=1240347r1=1240346r2=1240347view=diff
==
---
cxf/branches/2.4.x-fixes/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/BookSubresourceImpl.java
(original)
+++
cxf/branches/2.4.x-fixes/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/BookSubresourceImpl.java
Fri Feb 3 21:31:23 2012
@@ -103,7 +103,6 @@ public class BookSubresourceImpl impleme
return order;
}
-@Override
public Book getTheBookWithContext(UriInfo ui) throws BookNotFoundFault {
return getTheBook();
}
Re: Failing to set an Origin header with a WebClient
Hi
The hint from Alex Declent, The solution is to set the system property
sun.net.http.allowRestrictedHeaders to true. ,
should help here as well, I may update the CORS tests to use WebClient
and see if it helps...
Cheers, Sergey
On 01/12/11 16:13, Sergey Beryozkin wrote:
Hi Dan
On 01/12/11 16:09, Daniel Kulp wrote:
On Thursday, December 01, 2011 10:04:27 AM Sergey Beryozkin wrote:
Hi Benson
so HTTPUrlConnection drops 'Origin' ? It's unfortunate.
It seems we'd need to look into some sort of integration with Apache
Http Client at some time,
Started working on that a long time ago:
http://svn.apache.org/repos/asf/cxf/branches/async-
client/rt/transports/http/src/main/java/org/apache/cxf/transport/http/async/
Just never had time to really finish it. :-(
The reflection trick you proposed may get us past this particular issue
:-)...Making it OSGI can be a concern, but may be, as far as CORS is
concerned, it's mainly targeted at browser consumers, not sure though
Actually, just wondering if it is possible to 'fix' HTTPUrlConnection to
support arbitrary HTTP verbs...
thanks, Sergey
Dan
Sergey
On 30/11/11 20:00, Benson Margulies wrote:
Logging. The output logger on the web client shows Origin, but not the
input logger on the JAX-RS endpoint it's talking to.
INFO: Outbound Message
---
ID: 1
Address: http://localhost:9000/simpleGet/HelloThere
Http-Method: GET
Content-Type: */*
Headers: {Origin=[http://localhost:9000], Accept=[text/plain],
Content-Type=[*/*]}
--
Nov 30, 2011 2:58:48 PM org.apache.cxf.interceptor.LoggingInInterceptor
INFO: Inbound Message
ID: 2
Address: http://localhost:9000/simpleGet/HelloThere
Http-Method: GET
Content-Type: */*
Headers: {Accept=[text/plain], Cache-Control=[no-cache],
connection=[keep-alive], content-type=[*/*], Host=[localhost:9000],
Pragma=[no-cache], User-Agent=[Apache CXF ${project.version}]}
On Wed, Nov 30, 2011 at 2:54 PM, Benson
Marguliesbimargul...@gmail.com
wrote:
I dumped the exchange, and Origin isn't in there. I haven't turned on
the logging interceptors yet.
[null, null, null, null, null, null, null, null, null,
org.apache.cxf.message.Message.PROTOCOL_HEADERS={Accept=[text/plain],
Cache-Control=[no-cache], connection=[keep-alive], content-type=[*/*],
Host=[localhost:9000], Pragma=[no-cache], User-Agent=[Apache CXF
${project.version}]}, null, null, null, null, null, null,
HTTP_CONTEXT_MATCH_STRATEGY=stem,
org.apache.cxf.request.url=http://localhost:9000/simpleGet/HelloThere,
null, null, null, null,
org.apache.cxf.request.uri=/simpleGet/HelloThere, null,
org.apache.cxf.resource.method=public java.lang.String
org.apache.cxf.systest.jaxrs.cors.CorsServer.simpleGet(java.lang.Strin
g), HTTP.REQUEST=(GET /simpleGet/HelloThere)@372285153
org.eclipse.jetty.server.Request@16309ee1, null, null,
HTTP.CONFIG=org.eclipse.jetty.servlet.ServletHolder$Config@520ed128,
Accept=text/plain, null,
org.apache.cxf.message.Message.PATH_INFO=/simpleGet/HelloThere, null,
null, null, null, null, null, null, null,
org.apache.cxf.continuations.ContinuationProvider=org.apache.cxf.trans
port.http.Servlet3ContinuationProvider@4ac5c32e, null, null, null,
org.apache.cxf.message.Message.IN_INTERCEPTORS=[org.apache.cxf.transpo
rt.https.CertConstraintsInterceptor@7d91275b], null, null,
org.apache.cxf.message.Message.QUERY_STRING=null,
HTTP.RESPONSE=HTTP/1.1 200
On Wed, Nov 30, 2011 at 2:47 PM, Benson
Marguliesbimargul...@gmail.com
wrote:
I'm failing to set an Origin header with a WebClient. Here's the
client side code, and the header does not make it to the other end.
This makes it rather difficult to write tests for CORS.
On the other hand, should WebClient have native support for the
client
side of CORS? That's complex and unpleasant in prospect.
String origin = http://localhost:; + PORT;
WebClient wc = WebClient.create(origin + /);
// Since our WebClient doesn't know from Origin, we
need to do
this ourselves.
wc.header(Origin, origin);
Response r =
wc.replacePath(/simpleGet/HelloThere).accept(text/plain).get();
assertEquals(Response.Status.OK.getStatusCode(),
r.getStatus());
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
[VOTE] Apache DOSGi 1.3 Release
Apache CXF DOSGI subproject is a Reference Implementation of the OSGI Remote Services Specification which offers an alternative approach toward dynamically deploying and updating remote service endpoints and consumers using the OSGI programming model. We have been working on the 1.3 release during the last 2 months and have resolved about 15 issues: http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.3/distribution/sources/src/main/release/release_notes.txt Apache CXF 2.5.2 JAX-WS and JAX-RS runtimes are used internally to create the web service endpoints and consumers. The staging area: https://repository.apache.org/content/repositories/orgapachecxf-178/ This vote will be open for at least 72 hours. Here is my +1. Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
JAX-RS: Is anyone using CodeGeneratorProvider
Hi, I'm thinking of deleting CodeGeneratorProvider [1] for 2.6 only, given that it seems to be redundant now that we have a wadl2java command line tool and plugin. The idea behind CodeGeneratorProvider has been that one can just quickly download a zipped source from the dev/test service endpoint, compile, enhance a bit and test, but with the wadl2java tools it is not needed any more. One can get an existing WADL or use the one generated by CXF and feed it into a wadl code generator locally... Does anyone feel it should be kept nonetheless and if yes then why ? Let me know please, as I'm planning to remove it in the next few days. This will also let me move the SourceGenerator code which CodeGeneratorProvider relies upon to the tools/wadl, where it does belong... Thanks, Sergey [1] http://cxf.apache.org/docs/jaxrs-services-description.html#JAXRSServicesDescription-GeneratingtheclientcodefromWADLatruntime -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: [VOTE] Apache DOSGi 1.3 Release
On 02/02/12 14:30, Colm O hEigeartaigh wrote: +1. One minor point from the release notes - Many dependencies have been updated, including the update to CXF 2.5.1. - this should be 2.5.2 right? Will it require me to repeat the process or a minor note on the DOSGi page pointing to the typo will do ? Sergey Colm. On Thu, Feb 2, 2012 at 1:59 PM, David Bosschaert david.bosscha...@gmail.com wrote: Excellent work, Sergey. Big +1 from me! David On 2 February 2012 13:33, Sergey Beryozkinsberyoz...@gmail.com wrote: Apache CXF DOSGI subproject is a Reference Implementation of the OSGI Remote Services Specification which offers an alternative approach toward dynamically deploying and updating remote service endpoints and consumers using the OSGI programming model. We have been working on the 1.3 release during the last 2 months and have resolved about 15 issues: http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.3/distribution/sources/src/main/release/release_notes.txt Apache CXF 2.5.2 JAX-WS and JAX-RS runtimes are used internally to create the web service endpoints and consumers. The staging area: https://repository.apache.org/content/repositories/orgapachecxf-178/ This vote will be open for at least 72 hours. Here is my +1. Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: svn commit: r1239141 - in /cxf/trunk/distribution/src/main/release/samples/logbrowser: pom.xml src/main/java/demo/logbrowser/App.java
Thanks for it, still planning to do some package changes, so was
planning to fix the demo build itself a bit later...
Cheers, Sergey
On 01/02/12 14:12, ningji...@apache.org wrote:
Author: ningjiang
Date: Wed Feb 1 14:12:12 2012
New Revision: 1239141
URL: http://svn.apache.org/viewvc?rev=1239141view=rev
Log:
Fixed the build error of the logbrowser example
Modified:
cxf/trunk/distribution/src/main/release/samples/logbrowser/pom.xml
cxf/trunk/distribution/src/main/release/samples/logbrowser/src/main/java/demo/logbrowser/App.java
Modified: cxf/trunk/distribution/src/main/release/samples/logbrowser/pom.xml
URL:
http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/logbrowser/pom.xml?rev=1239141r1=1239140r2=1239141view=diff
==
--- cxf/trunk/distribution/src/main/release/samples/logbrowser/pom.xml
(original)
+++ cxf/trunk/distribution/src/main/release/samples/logbrowser/pom.xml Wed Feb
1 14:12:12 2012
@@ -81,7 +81,11 @@
artifactIdcxf-rt-management-web/artifactId
version${project.version}/version
/dependency
-
+dependency
+groupIdorg.apache.cxf/groupId
+artifactIdcxf-rt-rs-extension-providers/artifactId
+version${project.version}/version
+/dependency
dependency
groupIdorg.apache.cxf/groupId
artifactIdcxf-rt-transports-http-jetty/artifactId
Modified:
cxf/trunk/distribution/src/main/release/samples/logbrowser/src/main/java/demo/logbrowser/App.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/logbrowser/src/main/java/demo/logbrowser/App.java?rev=1239141r1=1239140r2=1239141view=diff
==
---
cxf/trunk/distribution/src/main/release/samples/logbrowser/src/main/java/demo/logbrowser/App.java
(original)
+++
cxf/trunk/distribution/src/main/release/samples/logbrowser/src/main/java/demo/logbrowser/App.java
Wed Feb 1 14:12:12 2012
@@ -23,8 +23,8 @@ import java.util.HashSet;
import java.util.Set;
import javax.ws.rs.core.Application;
-import org.apache.cxf.jaxrs.provider.AtomEntryProvider;
-import org.apache.cxf.jaxrs.provider.AtomFeedProvider;
+import org.apache.cxf.jaxrs.ext.provider.AtomEntryProvider;
+import org.apache.cxf.jaxrs.ext.provider.AtomFeedProvider;
import org.apache.cxf.management.web.browser.bootstrapping.BootstrapStorage;
import
org.apache.cxf.management.web.browser.bootstrapping.SimpleXMLSettingsStorage;
Re: [Discuss] Move gzip feature to core
Hi Christian On 30/01/12 10:34, Christian Schneider wrote: We currently have a transports/common project that only contains the gzip feature. As this feature is even used from core I propose we move it there and remove the whole transports/common module. As far as I recall the gzip feature was in transports/http originally and then there was a demand for GZIP be supported at the JMS level... I proposed to move it to transports/common as opposed to rt/core, it does not seem to belong to the core really, as it's a very transport specific feature I would like to change the package name from org.apache.cxf.transport.common.gzip to org.apache.cxf.gzip. To remain compatible I would leave a copy of the classes in the old package with @Deprecated annotation. I'd still propose to scope 'gzip', may be not with 'common' but with something else Cheers, Sergey Christian
Re: [Discuss] Move gzip feature to core
On 30/01/12 10:56, Christian Schneider wrote: We could of course also have a spearate module for gzip. At a time we talked about moving some more HTTP-centric interceptors from rt/core to transports/common, may be fastinfoset ones. Dan may have more ideas, I recall him referring to this common module. The reason why I think about moving it to core is that it just contains 3 classes and does not have additional dependencies. I've just moved a cors code from the jaxrs module, it does have 3 classes at the moment only but it does not quite belong to the main jaxrs module. rt/core can become quite lumpy, not a big issue probably... Basically I like the idea to separate modules on the architecture level. On the runtime level I doubt though that any user would mind having these classes available every time. About a prefix for the gzip classes. I also thought about what could be suitable. Of course gzip is kind of on the transport level but it is no transport. So perhaps it is a kind of a transformation or encoding. 'encoding' or 'common.encoding' sounds good to me thanks, Sergey Christian Am 30.01.2012 11:43, schrieb Sergey Beryozkin: Hi Christian On 30/01/12 10:34, Christian Schneider wrote: We currently have a transports/common project that only contains the gzip feature. As this feature is even used from core I propose we move it there and remove the whole transports/common module. As far as I recall the gzip feature was in transports/http originally and then there was a demand for GZIP be supported at the JMS level... I proposed to move it to transports/common as opposed to rt/core, it does not seem to belong to the core really, as it's a very transport specific feature I would like to change the package name from org.apache.cxf.transport.common.gzip to org.apache.cxf.gzip. To remain compatible I would leave a copy of the classes in the old package with @Deprecated annotation. I'd still propose to scope 'gzip', may be not with 'common' but with something else Cheers, Sergey Christian
Re: [Discuss] Move gzip feature to core
Hi On 30/01/12 19:29, Daniel Kulp wrote: On Monday, January 30, 2012 11:56:06 AM Christian Schneider wrote: We could of course also have a spearate module for gzip. The reason why I think about moving it to core is that it just contains 3 classes and does not have additional dependencies. Basically I like the idea to separate modules on the architecture level. On the runtime level I doubt though that any user would mind having these classes available every time. About a prefix for the gzip classes. I also thought about what could be suitable. Of course gzip is kind of on the transport level but it is no transport. So perhaps it is a kind of a transformation or encoding. I really have some mixed opinions on this.In API we have some similar features similar to the gzip feature that really could be grouped into this, but we have that split-package issue. For example, the FastInfosetFeature kind of falls into the same basic idea and could likely be grouped into a separate features bundle, but because we stuck it in org.apache.cxf.feature, I have to leave it API. :-( (and the fact that the implementation of the feature lives in org.apache.cxf.interceptor, also in API) One positive from dropping this module is that we will have 1 less module, and as Christian pointed out it won't affect users directly. I guess it means the simpler config of features too... Possible cons is that rt/core will start accumulating some more or less common transport-specific code - but may be indeed some more material is needed before getting a transport-specific module created for good... Not sure :-). Whatever makes it better for 2.6 is good for me :-) Cheers, Sergey Dan Christian Am 30.01.2012 11:43, schrieb Sergey Beryozkin: Hi Christian On 30/01/12 10:34, Christian Schneider wrote: We currently have a transports/common project that only contains the gzip feature. As this feature is even used from core I propose we move it there and remove the whole transports/common module. As far as I recall the gzip feature was in transports/http originally and then there was a demand for GZIP be supported at the JMS level... I proposed to move it to transports/common as opposed to rt/core, it does not seem to belong to the core really, as it's a very transport specific feature I would like to change the package name from org.apache.cxf.transport.common.gzip to org.apache.cxf.gzip. To remain compatible I would leave a copy of the classes in the old package with @Deprecated annotation. I'd still propose to scope 'gzip', may be not with 'common' but with something else Cheers, Sergey Christian
Re: Removing two more modules ?
Hi It is time to return to this thread with more modules being and about to be added to the trunk On 20/09/11 12:07, Sergey Beryozkin wrote: Hi What do you think of dropping a couple of modules for 2.5: - both rt-bindings-local and rt-bindings-object seem to do the same thing, I recall there were some interesting discussions around these two modules awhile back :-), but today I guess it's more important which module we actually encourage users to use. If it is rt-bindings-local then lets drop rt-bindings-object or the other way around Can I hack either of those modules on the trunk only, the users definitely use the collocated support, the question is, do we have an indication of which module is actually used or both of them can be used ? If it is the latter, can users migrate to the which will be kept in 2.6 (assuming of course that one module is removed) without any major problems ? - cxf-rt-bindings-http - dropping it for 2.5 would encourage existing users to finalize their migration to JAX-RS I'm poised to remove it on the trunk only, we got one +1 from Eric, any concerns about deleting it ? Cheers, Sergey I guess we can continue keeping the above modules, was just thinking if we could compensate somehow the fact that the new modules are being added, with more to come... Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Removing two more modules ?
Hi On 27/01/12 15:59, Daniel Kulp wrote: On Friday, January 27, 2012 1:02:11 PM Sergey Beryozkin wrote: Hi It is time to return to this thread with more modules being and about to be added to the trunk On 20/09/11 12:07, Sergey Beryozkin wrote: Hi What do you think of dropping a couple of modules for 2.5: - both rt-bindings-local and rt-bindings-object seem to do the same thing, I recall there were some interesting discussions around these two modules awhile back :-), but today I guess it's more important which module we actually encourage users to use. If it is rt-bindings-local then lets drop rt-bindings-object or the other way around Can I hack either of those modules on the trunk only, the users definitely use the collocated support, the question is, do we have an indication of which module is actually used or both of them can be used ? If it is the latter, can users migrate to the which will be kept in 2.6 (assuming of course that one module is removed) without any major problems ? I assume you mean rt-transport-local, not binding-local... The two of those really have different use cases right now and it would be a significant amount of work to get the uses cases for one to be met by the other.I'm OK with doing that, but I'm warning that it will be a lot of work. There isn't really a way to get rid of rt-transport-local. It has a specific use case of allowing FULL CXF feature sets, but without opening ports or anything. We use it in our tests all over the place. Basically, it allows things like policy and security and gzip and everything to work exactly like if it was an HTTP connect, just in-vm. (that said, I think the performance of local is actually less than http) The issue is between binding-object and binding-coloc.Most likely, binding-coloc could be re-written in terms of binding-object or vice versa, but I've never really dug into them. Sorry, I meant rt-binding-object rt-binding-coloc... I basically looked at the list of modules and I also vaguely remember that they more or less do the same thing so thought one of the modules was a 'candidate'...Better keep both of them then for a while just in case - cxf-rt-bindings-http - dropping it for 2.5 would encourage existing users to finalize their migration to JAX-RS I'm poised to remove it on the trunk only, we got one +1 from Eric, any concerns about deleting it ? No concerns for 2.6. Go for it. Sure, will do. My only concern is that this one lets users write the code that say unwraps in XML into multiple parameters which is not possible with JAX-RS. But if it will really block some users from migrating to 2.6 then I'd be ready to consider doing the extension in the rs frontend. Overall it was a nice effort from Dan D but it's a simply an unsupported module now with JAX-RS taking the priority Cheers, Sergey Dan Cheers, Sergey I guess we can continue keeping the above modules, was just thinking if we could compensate somehow the fact that the new modules are being added, with more to come... Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: split-packages, osgi bundles, etc.....
Hi Dan On 24/01/12 22:19, Daniel Kulp wrote: I just committed some changes that change the features.xml on trunk to use the modularized bundles instead of the big bundle. It's definitely not complete yet, but consider it a starting point to attempt some testing.:-) Right now, I know I have a few issue to resolve: 1) API loading CXFBusFactory - the call to BusFactory.getDefaultBus or createBus or anything requires API to load a class from rt-core. I'm currently using a dynamic import for this, but that sucks. I need to add an activator to API to find the implementations. This really just affects people using pure API applications or JAX-WS API applications (like wsn). Folks using SpringDM or Blueprint aren't affected by this. 2) Applications that use Require-Bundle for the old bundle. I create a compatbilitiy bundle of the same name that re-exports stuff from core/api/http that works for a couple of Talend's test cases. I definitely need to flush this out more. HOWEVER, applications that import more than just META-INF/cxf/cxf.xml will have issues as that's the only thing we can really export. That said, ALL the other cxf/cxf-extendion-*.xml files have been deprecated for 2 releases and have spit warnings out in the logs. People should have removed them already. I'd probably want a similar one for cxf-jaxrs to give the users which rely on Require-Bundle a chance to keep the changes to the minimum or avoid them for a bit of time :-) +1 to dropping cxf-minimal from 2.6.0 though 3) In a couple of my tests, I'm getting warnings in logs about schemas not being available. With the big bundle, we have all the schemas in /schemas so we can easily pull them in for resolving things like ws-addressing and such. I need to figure out exactly what the issue is with the missing schemas and figure out the best solutions for them. More investigation needed. 4) Testing - I've really just run 2 of the Talend examples with it so far and started up the wsn service. Very minimal.Definitely a lot more work to do here. 5) Dependency checking - I updated the features.xml with a bunch of new features. However, I haven't gone through all the jars to see if all the imports resolve or not and then decide which we should resolve. For example, I know aegis databinding jar's dependency on jdom doesn't resolve, but I'm not sure if we should by default resolve that or not since it is completely optional. JAXRS has a few of these as well (like abdera). Anyway, it's progressing.:-) Cheers, SErgey
Re: Preparing for DOSGi RI 1.3 release
I got rid of the references to the remoteadmin and compendium modules, things seem to be OK, so we are nearly ready to go for 1.3 Sergey On 25/01/12 07:48, David Bosschaert wrote: +1 on including the enterprise jar. It should also replace the compendium jar if that's currently mentioned in the project... Cheers, David On 24 January 2012 18:37, jbertalbert.d...@gmail.com wrote: I second the need for the enterprise API jar. I would also like to note that the POMs in trunk still need to be changed to point to the org.osgi.enterprise JAR, right now they're still pointing to the remoteadmin project. This means that the current sources cannot be built unless you check out a revision of November and build the remoteadmin project to get a 1.3 SNAPSHOT. If it's not clear what I mean, I could create a simple patch tomorrow. Best regards, Bert -- View this message in context: http://cxf.547215.n5.nabble.com/Preparing-for-DOSGi-RI-1-3-release-tp5094303p5324430.html Sent from the cxf-dev mailing list archive at Nabble.com. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Transform Feature Improvements (Was: Re: svn commit: r1227691)
Hi Aki
I've changed the subject, hope you are ok with it
On 25/01/12 10:04, Aki Yoshida wrote:
2012/1/24 Sergey Beryozkinsberyoz...@gmail.com:
Hi Aki
On 05/01/12 16:49, a...@apache.org wrote:
Author: ay
Date: Thu Jan 5 16:49:56 2012
New Revision: 1227691
URL: http://svn.apache.org/viewvc?rev=1227691view=rev
Log:
[CXF-4013] Enhancing the element-append and drop options of
OutTransformWriter
I've finally updated the documentation [1] to take note of your enhancement,
thanks for this fine effort.
It's quite complete now, this feature, may be we can offer some basic
conditional transformation support in time too :-)
Hi Sergey,
Thanks for the documentation update. We have now the inbound and
outbound transformation features aligned.
Yes, we can add a few things along this transformation model. Allowing
a simple node path rather than just its node name to pick the node is
a useful extension. This will be easy. Providing some conditional
transformation is also useful one. If we can limit its functionality
and complexity in some reasonably level, that will be good.
I thought briefly about it, supporting node paths and simple conditions
can probably be handled at the same time.
As far as the condition is concerned, it should probably be
straightforward conditions such as:
/a:bar/a:foo = text
/a:bar/a:foo/@baz = text
and say inTransformMap:
/a:bar/a:foo : {myns2}foo
I recall you had an idea how to specify prefixes, may be we can also set
a custom namespaceToPrefixes map so that we can say:
/a:bar/a:foo : {b}foo
at any moment of time we can get String or some stack pointing to the
current simple element or attribute.
If no conditions are there then as soon as we get a matching path we
apply the transfpormation, otherwise we additionally check that the
simple conditions are met
I guess we can do something not too over-complex indeed, in many cases
it's probably simple logic or path that can be applied
Cheers, Sergey
Regards, aki
Cheers
Sergey
[1]
https://cwiki.apache.org/confluence/display/CXF20DOC/TransformationFeature
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: [VOTE] Apache CXF 2.3.9/2.4.6/2.5.2
+1 Cheers, Sergey On 20/01/12 00:08, Daniel Kulp wrote: We've resolved over 45 issues since 2.5.1. Most importantly, several of them were regressions since 2.5.0 and thus we need to get a new release out. We've also ported back over 25 of the fixes to 2.4.6 and 8 of those to 2.3.9. List of issues: 2.3.9: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12319251 2.4.6: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12319250 2.5.2: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12319249 The Maven staging areas are at: 2.3.9: https://repository.apache.org/content/repositories/orgapachecxf-099/ 2.4.6: https://repository.apache.org/content/repositories/orgapachecxf-101/ 2.5.2: https://repository.apache.org/content/repositories/orgapachecxf-104/ The distributions are in the org/apache/cxf/apache-cxf/ directory of the Maven staging areas. This releases are tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.9 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.6 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.2 This vote will be open for at least 72 hours.
Re: [VOTE] Apache CXF 2.3.9/2.4.6/2.5.2 - take 2
+1 Sergey On 20/01/12 17:56, Daniel Kulp wrote: We've resolved over 45 issues since 2.5.1. Most importantly, several of them were regressions since 2.5.0 and thus we need to get a new release out. We've also ported back over 25 of the fixes to 2.4.6 and 8 of those to 2.3.9. This is the second attempt at this release which fixes the issues of getting the 2.5.2 OSGi bundles properly deploying. List of issues: 2.3.9: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12319251 2.4.6: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12319250 2.5.2: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12319249 The Maven staging areas are at: 2.3.9: https://repository.apache.org/content/repositories/orgapachecxf-099/ 2.4.6: https://repository.apache.org/content/repositories/orgapachecxf-101/ 2.5.2: https://repository.apache.org/content/repositories/orgapachecxf-112/ The distributions are in the org/apache/cxf/apache-cxf/ directory of the Maven staging areas. This releases are tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.9 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.6 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.2 This vote will be open for at least 72 hours. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: CORS documentation
On 06/01/12 11:50, Sergey Beryozkin wrote: Hi Benson I've created a page for documenting the initial CORS support, https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+CORS if you get a chance, fill it in please; I can contribute too but a bit later I started putting some code examples from the tests you did, which is a start. The package.html is also very good, I have a couple of minor changes, will commit a bit later. It seems we have some good support for people to start experimenting with CORS, By the way I'm planning to move the CORS code into a dedicated module as it's very likely to grow Cheers, Sergey
Re: CORS documentation
On 19/01/12 20:10, Benson Margulies wrote: Sorry, I've been marginally sick and that has stopped me from making it to this task. I did try to write a lot of javadoc. It is all very well documented, thanks... Cheers, Sergey On Thu, Jan 19, 2012 at 1:19 PM, Sergey Beryozkinsberyoz...@gmail.com wrote: On 06/01/12 11:50, Sergey Beryozkin wrote: Hi Benson I've created a page for documenting the initial CORS support, https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+CORS if you get a chance, fill it in please; I can contribute too but a bit later I started putting some code examples from the tests you did, which is a start. The package.html is also very good, I have a couple of minor changes, will commit a bit later. It seems we have some good support for people to start experimenting with CORS, By the way I'm planning to move the CORS code into a dedicated module as it's very likely to grow Cheers, Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: CORS documentation
Hi On 19/01/12 20:38, Satheesh Chinthapatla wrote: Hello All, I would like to contribute some thing into this project but I am not sure where to start since I am very new in contributing into open source. About me: I am lead java developer having 12 yrs of experience and currently working in NJ. Are you interested in contributing specifically to the CORS effort or to CXF in general ? Please check http://cxf.apache.org/getting-involved.html and then if it is CORS then I think what should help is experimenting with what we already have, testing it with different browsers, and submitting patches if needed Thanks, Sergey Thanks Satish On Jan 19, 2012, at 3:11 PM, Benson Marguliesbimargul...@gmail.com wrote: Sorry, I've been marginally sick and that has stopped me from making it to this task. I did try to write a lot of javadoc. On Thu, Jan 19, 2012 at 1:19 PM, Sergey Beryozkinsberyoz...@gmail.com wrote: On 06/01/12 11:50, Sergey Beryozkin wrote: Hi Benson I've created a page for documenting the initial CORS support, https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+CORS if you get a chance, fill it in please; I can contribute too but a bit later I started putting some code examples from the tests you did, which is a start. The package.html is also very good, I have a couple of minor changes, will commit a bit later. It seems we have some good support for people to start experimenting with CORS, By the way I'm planning to move the CORS code into a dedicated module as it's very likely to grow Cheers, Sergey
Re: DOSGi and Knopflerfish
http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.2/samples/greeter/ By the way, I'm redirecting to the users list Sergey On 18/01/12 14:53, Jesus wrote: Sorry Sergey, what demo do you said? Actual version of D-OSGi is 1.2 On Wed, Jan 18, 2012 at 3:23 PM, Sergey Beryozkin-5 [via CXF] ml-node+s547215n5154947...@n5.nabble.com wrote: Hi On 18/01/12 09:58, Jesus wrote: Hello all, I need to develop a OSGi bundle for Knopflerfish and export a service. For this, I want to used D-OSGi, but I can't access to my bundle through a web service. In my Activator code I introduce this code: props.put(osgi.remote.configuration.type, wsdl); props.put(service.exported.interfaces, *); props.put(service.exported.configs, org.apache.cxf.ws); props.put(org.apache.cxf.ws.address, http://localhost:8080/droolstest;); But I think this is wrong. Where can I read any example code for run D-OSGi in Knopflerfish? Anybody have idea? Try a greeter demo from the 1.2 distribution, a wsdl type will be supported in 1.3 Sergey Thanks in advance, Jesus, -- View this message in context: http://cxf.547215.n5.nabble.com/DOSGi-and-Knopflerfish-tp5154329p5154329.html Sent from the cxf-dev mailing list archive at Nabble.com. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com -- If you reply to this email, your message will be added to the discussion below: http://cxf.547215.n5.nabble.com/DOSGi-and-Knopflerfish-tp5154329p5154947.html To unsubscribe from DOSGi and Knopflerfish, click herehttp://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=5154329code=c295ZWxtYXRlb0BnbWFpbC5jb218NTE1NDMyOXwtODU2MzA5NTk1 . NAMLhttp://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespacebreadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://cxf.547215.n5.nabble.com/DOSGi-and-Knopflerfish-tp5154329p5155042.html Sent from the cxf-dev mailing list archive at Nabble.com. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
CORS documentation
Hi Benson I've created a page for documenting the initial CORS support, https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+CORS if you get a chance, fill it in please; I can contribute too but a bit later Cheers, Sergey
Re: Start the 2.5.x_fixes branch, trunk to 2.6.0?
Hi On 04/01/12 20:53, Daniel Kulp wrote: Now that 2.5.1 is out, I like to create the 2.5.x_fixes branch and change trunk to target 2.6.0. Any objections? If not, I'll do so tomorrow. I'd like to start working on a few things for 2.6.x: 1) Individual OSGi bundles (when possible, sent a note about that before). Will require some minor code refactoring. 2) raw type cleanups. I'd like to turn back on a couple of the eclipse warnings, but this requires some cleanup. A lot of them are things like changing Class foo to Class? foo and such, but there are others. Some of this MAY have minor updates to public APIs to add the generics. 3) Better OSGi config support - things like the http:jetty stuff, http:conduit things, etc... should likely be controllable from the OSGi config, not per application. I'd like to investigate this a bit. 4) Likely some OSGi based system tests. Definitely needed. 5) Try to revive/rework the commons-http based async transport from my branch. That should also let me start gradually implementing JAX-RS 2.0, CXF 2.6.0 may have the server part updated, etc... Cheers, Sergey
Re: How to contribue a CXF JAX-RS OSGi Sample?
Hi, this demo is on the trunk now, I tested it and it worked fine Thanks for this contribution, Cheers, Sergey On 16/12/11 22:34, K Fung wrote: Hello, I'm sorry - I should've put it into 2.5.1 - but it will definitely make it into 2.5.2 - and I hope it would be of interest to users. No worries Sergey. Thanks for all your helpful suggestions and guidance while I worked on this in 2 week spurts. It took us countless hours and much frustration to figure out how to run CXF JAX-RS in our OSGI environment. Hopefully this sample will alleviate the time needed for others to get up to speed with CXF JAX-RS in their own environments. In 2.5.2 on later we can think of introducing an activator into the jaxrs frontend so that it can discover custom Applications and providers registered as OSGI services Perhaps we should have a discussion on a separate thread to discuss how you envision seeing this? In particular, I'm wondering what's the baseline/environment you think this would be running. For example, right now there is no activator in the CXF JAX-RS bundle but what are the consequence of an activator in 2.5.2+ - can it be disabled? Do we rely on the OSGI HttpService or do we use a built-in Jetty? Can we support both? I guess you can see that I'm pretty interested in this topic :-) On Fri, Dec 16, 2011 at 2:21 PM, Sergey Beryozkinsberyoz...@gmail.comwrote: Hi KL On 16/12/11 22:13, K Fung wrote: Hi Sergey, I've uploaded the final version (for now) to CXF-3859. I've bumped up the version to 2.5.2-SNAPSHOT and commented out the Apache Snapshot repository. Hopefully, this meets the quality bar for commit :-) I'm sorry - I should've put it into 2.5.1 - but it will definitely make it into 2.5.2 - and I hope it would be of interest to users. I did investigate creating the JAXRSServerFactoryBean directly (instead of subclassing CXFNonSpringJaxrsServlet). If I went down this route, I would have had to include a dependency on Jetty directly (as the traffic wouldn't be provided via the OSGI HttpService) or duplicate much of the servlet code in CXFNonSpringJaxrsServlet. In the end, I decided that it just wasn't worth it. Sounds right... In 2.5.2 on later we can think of introducing an activator into the jaxrs frontend so that it can discover custom Applications and providers registered as OSGI services thanks, Sergey Cheers, kl On Mon, Dec 5, 2011 at 9:39 AM, Sergey Beryozkinsberyoz...@gmail.com** wrote: Hi KL On 03/12/11 00:50, K Fung wrote: Hi Sergey, Adding Dynamic-Import: * would likely resolve the issue. It also makes any package/class name resolution a lot slower because all the OSGI bundles will basically now be a gigantic class path. I would not be inclined to go down this route. I've uploaded a new version to CXF-3859. I've updated the code so that it compiles in Java 5 (turns out this wasn't too hard once I figured how ServiceMix got it to work) and now when you compile the samples pom.xml, it'll also compile the JAX-RS Minimal OSGI sample. The final things on my TODO list are to investigate how to avoid using my own special servlet and the removal the snapshot repository. For the latter, I'll likely just comment this out since it turns out that in the samples pom.xml, snapshots are enabled. Please try commenting it out. It seems like it's ready for a commit, thanks, Sergey Regards, kl -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Preparing for DOSGi RI 1.3 release
Hi All, Dan, myself and David talked about the possibility of releasing DOSGi RI 1.3 based on Apache CXF. There are few reasons why we thought it was a good idea to pursue it. We are seeing a number of users periodically asking DOSGI-related questions and it's been unfortunate that some basic bugs have stopped users from experimenting with DOSGi and proceeding with the POC deployments and such though we believe a number of users have actually successfully deployed DOSGI RI in their projects without major problems or by fixing bugs locally and submitting patched back to the DOSGi RI project. So helping the community with fixing as many bugs as realistically possible in the short term and releasing DOSGi RI 1.3 is important. DOSGi RI has CXF JAX-WS and JAX-RS frontends operating on the OSGI Service registrations and look-ups and hence we hope that it can open up more interesting options for users to deploy web services in OSGi and therefore stress CXF from a different direction. I've spent few days on closing the JIRAs reported against DOSGi 1.1 and 1.2 due to DOSGI 1.3-SNAPSHOT has had its dependencies changed a lot (thanks to a major patch from Ancoron Luciferis), with CXF 2.5.1 supporting it now. I've also resolved a lot of JIRAs containing patches or hints on some basic modifications needed to get the issues fixed. Two modules have been removed, a zookeeper bundle wrapper and the local OSGI RemoteAdminService code which is now available in Central. Here is a complete list: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+DOSGI+AND+resolutiondate+%3E%3D-1w+ORDER+BY+updated+DESC Here is the list of outstanding issues: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+DOSGI+AND+resolutiondate+%3E%3D-1w+ORDER+BY+updated+DESC IMHO we are nearly good to go with the 1.3 release. What I'd like to do is to ask users who are interested in working or experimenting with DOSGi to give 1.3-SNAPSHOT a test on the latest Felix or Equinox distributions as well as check the list of outstanding issues and may be submit a couple of more patches. Personally I'd get a pint to anyone who will figure out how to fix https://issues.apache.org/jira/browse/DOSGI-18 :-) (that works in a single bundle case), though in case of JAX-RS the consumers can be the browsers. https://issues.apache.org/jira/browse/DOSGI-106 also seems important enough, though HttpService can be used just fine with multi-bundle distros. So please give it a test, consider fixing a couple of more issues and we will be ready to proceed with the release early next year Thanks, Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: CORS filter a bit noisy
Hi Benson On 21/12/11 18:32, Benson Margulies wrote: It looks to me as if the CORS filter has a bug: it returns headers even when the request is not cross-origin. Sergey, WTYT? I'm sure it's not a tragedy and that I could fix that easily enough. Which headers are you referring to, the ones that are returned as part of the SIMPLE request post-processing or some other headers ? Cheers, Sergey
Re: CORS filter a bit noisy
On 21/12/11 22:23, Sergey Beryozkin wrote: Hi Benson On 21/12/11 18:32, Benson Margulies wrote: It looks to me as if the CORS filter has a bug: it returns headers even when the request is not cross-origin. Sergey, WTYT? I'm sure it's not a tragedy and that I could fix that easily enough. Which headers are you referring to, the ones that are returned as part of the SIMPLE request post-processing or some other headers ? Oh, you mean the usual plain requests, right ? Thought in the code the cors filter does not do anything in such cases on the output and just returns Cheers, Sergey
Re: Activators for individual frontends
On 19/12/11 10:35, Sergey Beryozkin wrote: Hi KL, All, On 16/12/11 22:34, K Fung wrote: In 2.5.2 on later we can think of introducing an activator into the jaxrs frontend so that it can discover custom Applications and providers registered as OSGI services Perhaps we should have a discussion on a separate thread to discuss how you envision seeing this? In particular, I'm wondering what's the baseline/environment you think this would be running. For example, right now there is no activator in the CXF JAX-RS bundle but what are the consequence of an activator in 2.5.2+ - can it be disabled? Do we rely on the OSGI HttpService or do we use a built-in Jetty? Can we support both? I guess you can see that I'm pretty interested in this topic :-) I was thinking earlier on that CXF can get a master/root activator which will provide BundleContext, etc to individual activators which say JAXWS and JAXRS frontends may offer; I think these activators will not act as independent activators on its own I guess they actually may once we get individual modules OSGI-fied. But when get cxf-bundle or cxf-rs bundle deployed these activators are plain beans; I think they have to get hold of the root activator, which is org.apache.cxf.bus.osgi.OSGiExtensionLocator, and get BundleContext from it and do whatever they need to do - ServiceTrack(er) the Application interfaces, or in case of JAX-WS listening on bundles with jaxws annotations, something like that, etc. IMHO that will be actually cool - will add a lot of dynamism, and it won't interfere with say the existing deployment model where we create blueprint or spring contexts What I don't understand is how say OSGiExtensionLocator will pass BundleContext to frontend-specific Activator beans. Sergey , they will simply be able to react to the information (BundleContext for ex) that the actual root activator may offer. For example, in case of JAX-RS, this sub-activator will probably register ServiceTrackers and start listening for (JAX-RS) Application interfaces and then will create an endpoint by using HttpService or embedded Jetty, something like that What do you think ? Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Activators for individual frontends
On 20/12/11 19:04, Daniel Kulp wrote: On Monday, December 19, 2011 10:35:07 AM Sergey Beryozkin wrote: Hi KL, All, On 16/12/11 22:34, K Fung wrote: In 2.5.2 on later we can think of introducing an activator into the jaxrs frontend so that it can discover custom Applications and providers registered as OSGI services Perhaps we should have a discussion on a separate thread to discuss how you envision seeing this? In particular, I'm wondering what's the baseline/environment you think this would be running. For example, right now there is no activator in the CXF JAX-RS bundle but what are the consequence of an activator in 2.5.2+ - can it be disabled? Do we rely on the OSGI HttpService or do we use a built-in Jetty? Can we support both? I guess you can see that I'm pretty interested in this topic :-) I was thinking earlier on that CXF can get a master/root activator which will provide BundleContext, etc to individual activators which say JAXWS and JAXRS frontends may offer; I think these activators will not act as independent activators on its own, they will simply be able to react to the information (BundleContext for ex) that the actual root activator may offer. Well, we could have the current activator grab a list out of the current bundle (cxf-bundle) of other activators to instantiate and call. For example, we could have a META-INF/cxf/osgi-activators.txt that is created during bundling (shade can do it) that the OSGiExtensionLocator thing will grab and then call the start/stop on it. Super, this looks like a good way to start We'd only need to look in the current bundle. Once we split into modules, the core bundle would not have that and thus wouldn't do anything, but the jaxrs bundle could properly define it's own activator in it's manifest.This wouldn't be hard to do. Yea; Cheers, Sergey Dan For example, in case of JAX-RS, this sub-activator will probably register ServiceTrackers and start listening for (JAX-RS) Application interfaces and then will create an endpoint by using HttpService or embedded Jetty, something like that What do you think ? Sergey
Activators for individual frontends
Hi KL, All, On 16/12/11 22:34, K Fung wrote: In 2.5.2 on later we can think of introducing an activator into the jaxrs frontend so that it can discover custom Applications and providers registered as OSGI services Perhaps we should have a discussion on a separate thread to discuss how you envision seeing this? In particular, I'm wondering what's the baseline/environment you think this would be running. For example, right now there is no activator in the CXF JAX-RS bundle but what are the consequence of an activator in 2.5.2+ - can it be disabled? Do we rely on the OSGI HttpService or do we use a built-in Jetty? Can we support both? I guess you can see that I'm pretty interested in this topic :-) I was thinking earlier on that CXF can get a master/root activator which will provide BundleContext, etc to individual activators which say JAXWS and JAXRS frontends may offer; I think these activators will not act as independent activators on its own, they will simply be able to react to the information (BundleContext for ex) that the actual root activator may offer. For example, in case of JAX-RS, this sub-activator will probably register ServiceTrackers and start listening for (JAX-RS) Application interfaces and then will create an endpoint by using HttpService or embedded Jetty, something like that What do you think ? Sergey
Re: How to contribue a CXF JAX-RS OSGi Sample?
Hi, On 16/12/11 22:34, K Fung wrote: Hello, I'm sorry - I should've put it into 2.5.1 - but it will definitely make it into 2.5.2 - and I hope it would be of interest to users. No worries Sergey. Thanks for all your helpful suggestions and guidance while I worked on this in 2 week spurts. It took us countless hours and much frustration to figure out how to run CXF JAX-RS in our OSGI environment. Hopefully this sample will alleviate the time needed for others to get up to speed with CXF JAX-RS in their own environments. In 2.5.2 on later we can think of introducing an activator into the jaxrs frontend so that it can discover custom Applications and providers registered as OSGI services Perhaps we should have a discussion on a separate thread to discuss how you envision seeing this? In particular, I'm wondering what's the baseline/environment you think this would be running. For example, right now there is no activator in the CXF JAX-RS bundle but what are the consequence of an activator in 2.5.2+ - can it be disabled? Do we rely on the OSGI HttpService or do we use a built-in Jetty? Can we support both? I guess you can see that I'm pretty interested in this topic :-) me too :-), I started a new thread thanks, Sergey On Fri, Dec 16, 2011 at 2:21 PM, Sergey Beryozkinsberyoz...@gmail.comwrote: Hi KL On 16/12/11 22:13, K Fung wrote: Hi Sergey, I've uploaded the final version (for now) to CXF-3859. I've bumped up the version to 2.5.2-SNAPSHOT and commented out the Apache Snapshot repository. Hopefully, this meets the quality bar for commit :-) I'm sorry - I should've put it into 2.5.1 - but it will definitely make it into 2.5.2 - and I hope it would be of interest to users. I did investigate creating the JAXRSServerFactoryBean directly (instead of subclassing CXFNonSpringJaxrsServlet). If I went down this route, I would have had to include a dependency on Jetty directly (as the traffic wouldn't be provided via the OSGI HttpService) or duplicate much of the servlet code in CXFNonSpringJaxrsServlet. In the end, I decided that it just wasn't worth it. Sounds right... In 2.5.2 on later we can think of introducing an activator into the jaxrs frontend so that it can discover custom Applications and providers registered as OSGI services thanks, Sergey Cheers, kl On Mon, Dec 5, 2011 at 9:39 AM, Sergey Beryozkinsberyoz...@gmail.com** wrote: Hi KL On 03/12/11 00:50, K Fung wrote: Hi Sergey, Adding Dynamic-Import: * would likely resolve the issue. It also makes any package/class name resolution a lot slower because all the OSGI bundles will basically now be a gigantic class path. I would not be inclined to go down this route. I've uploaded a new version to CXF-3859. I've updated the code so that it compiles in Java 5 (turns out this wasn't too hard once I figured how ServiceMix got it to work) and now when you compile the samples pom.xml, it'll also compile the JAX-RS Minimal OSGI sample. The final things on my TODO list are to investigate how to avoid using my own special servlet and the removal the snapshot repository. For the latter, I'll likely just comment this out since it turns out that in the samples pom.xml, snapshots are enabled. Please try commenting it out. It seems like it's ready for a commit, thanks, Sergey Regards, kl -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
DOSGI build is being aborted
Hi I'm seeing these messages in the last few builds: [JENKINS] Archiving /home/jenkins/jenkins-slave/workspace/CXF-DOSGi/trunk/distribution/single-bundle/target/cxf-dosgi-ri-singlebundle-distribution-1.3-SNAPSHOT.jar to /home/hudson/hudson/jobs/CXF-DOSGi/modules/org.apache.cxf.dosgi$cxf-dosgi-ri-singlebundle-distribution/builds/2011-12-15_03-10-41/archive/org.apache.cxf.dosgi/cxf-dosgi-ri-singlebundle-distribution/1.3-SNAPSHOT/cxf-dosgi-ri-singlebundle-distribution-1.3-SNAPSHOT.jar Build timed out (after 18 minutes). Marking the build as aborted. [INFO] Unable to call isArchivingDisabled. Invalid object ID 41 [INFO] [INFO] Trace java.lang.IllegalStateException: Unable to call isArchivingDisabled. Invalid object ID 41 at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:268)... Is it to do with the size of the single bundle distro ? It's 12.2 MB Cheers, Sergey
Re: DOSGI build is being aborted
Actually the last one passed On 16/12/11 09:35, Sergey Beryozkin wrote: Hi I'm seeing these messages in the last few builds: [JENKINS] Archiving /home/jenkins/jenkins-slave/workspace/CXF-DOSGi/trunk/distribution/single-bundle/target/cxf-dosgi-ri-singlebundle-distribution-1.3-SNAPSHOT.jar to /home/hudson/hudson/jobs/CXF-DOSGi/modules/org.apache.cxf.dosgi$cxf-dosgi-ri-singlebundle-distribution/builds/2011-12-15_03-10-41/archive/org.apache.cxf.dosgi/cxf-dosgi-ri-singlebundle-distribution/1.3-SNAPSHOT/cxf-dosgi-ri-singlebundle-distribution-1.3-SNAPSHOT.jar Build timed out (after 18 minutes). Marking the build as aborted. [INFO] Unable to call isArchivingDisabled. Invalid object ID 41 [INFO] [INFO] Trace java.lang.IllegalStateException: Unable to call isArchivingDisabled. Invalid object ID 41 at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:268)... Is it to do with the size of the single bundle distro ? It's 12.2 MB Cheers, Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: [VOTE] Apache CXF 2.5.1/2.4.5/2.3.8
+1 Sergey On 15/12/11 20:37, Daniel Kulp wrote: We've resolved over 75 issues since 2.5.0 and thus is time for a release. We've also ported back over 40 of the fixes to 2.4.5 and 30 of those to 2.3.8. List of issues: 2.3.8: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12318348 2.4.5: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12318894 2.5.1: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=1231 The Maven staging areas are at: 2.3.8: https://repository.apache.org/content/repositories/orgapachecxf-327/ 2.4.5: https://repository.apache.org/content/repositories/orgapachecxf-328/ 2.5.1: https://repository.apache.org/content/repositories/orgapachecxf-345/ The distributions are in the org/apache/cxf/apache-cxf/ directory of the Maven staging areas. This releases are tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.8 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.5 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.1 This vote will be open for at least 72 hours. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Different namespaces for CXF Blueprint and Spring schemas
On 08/12/11 18:26, Daniel Kulp wrote: On Thursday, December 08, 2011 6:15:27 PM Sergey Beryozkin wrote: Hi Dan ... What about having a single target namespace even with one schema used by Spring 2nd - by Blueprint, example: !-- Spring -- xs:xmlns targetNamespace=http://cxf.apache.org/core; xmlns:tns=http://cxf.apache.org/core; !-- Spring-aware schema -- /xs:xmlns !-- Blueprint -- xs:xmlns targetNamespace=http://cxf.apache.org/core; xmlns:tns=http://cxf.apache.org/core; !-- Blueprint-aware schema -- /xs:xmlns This is basically what Aki was trying to do with RM and I kind of objected to which started the whole discussion. It more or less goes against the whole idea of 1:1 relationship between schema and namespace and does cause various other issues. For example, we now have a nice .htaccess file in place that redirects the namespace URL's to the appropriate schema so things like XML editors can easily pick them up and provide nice contextual information while editing the XML.If you have the same namespace mapped to two separate schemas, that no longer would work and we're right back to where we started with that. I do agree. Actually, after signing off yesterday I recalled you mentioning an .htaccess file but then figured we may get it redirecting to intermediate pages, such as the one linked to below: http://www.w3.org/2005/08/addressing/ and in principle we'd have a Blueprint and Spring links there pointing to the actual schemas. But then I thought it was kind of a 'warning' sign, we may be able to bypass this issue with linking to the actual schema representation, but it will just back-fire at some later stage; it does need to be a 1 to 1 relationship indeed as you indicated, better not break that... If we change the areas of core from the Spring specific types to xsd:anyType, we likely could do it. That's acutally how the ie nterceptor lists work already. I'm honestly not sure why the properties don't already do it that way. A good start might just be to identify the areas that are different between the schemas and just list them out.If flipping from mapType - xsd:anyType would fix it in all the cases, it might just be worth doing. Cheers, Sergey Dan Sorry if I did not clarify what I was actually after; I thought that if it could work in principle then we'd be able to experiment under the hood with various techniques which might let us collapse those 2 schemas into a single one, etc; and when needed do add http://cxf.apache.org/blueprint/core (using this ns just as example) which would point to a schema offering something unique to CXF services deployed on Blueprint But not sure if sharing the same target ns can actually work :-) Cheers, Sergey Dan
Different namespaces for CXF Blueprint and Spring schemas
Hi At the moment we have different namespaces for Blueprint and Spring schemas, example: http://cxf.apache.org/blueprint/core; http://cxf.apache.org/core; and so on for all other namespaces. I'd like to propose to keep a single namespace, example, http://cxf.apache.org/core;, etc. Spring schemas are located in /schemas resource folders, and blueprint ones in /schemas-blueprint, so I guess Blueprint and Spring will know where to look for their schemas. IMHO we should do before it is too late, it may be problematic now, but may be that is what we should do for 2.6 and document it in the Migration guide. Or is the idea that in Blueprint CXF might offer some features that won't be possible in Spring ? That may be of interest but I guess in that case we can have two namespaces for using in Blueprint: http://cxf.apache.org/blueprint/core; http://cxf.apache.org/core; with the former one identifying the schema which say imports the schema identified by the latter ns and adds some Blueprint centric extensions Thanks, Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Different namespaces for CXF Blueprint and Spring schemas
Hi Aki On 08/12/11 11:23, Aki Yoshida wrote: Hi Sergey, I think there is a possibility to use one schema that works for both of them, thereby making things a lot simpler. You will lose some degree of strictness in the combined schemas (i.e., certain attributes are available but have no associated semantics and simply ignored when configured in spring or one way or the other). But we can document this divergence in the merged schema's document/annotation elements. I am planning to take this approach for the ws-rm component. The background to this is tracked at http://cxf.547215.n5.nabble.com/thought-on-spring-and-blueprint-configuration-schemas-tt5052010.html Thanks for this link. I think it can be even up to a given module to decide which strategy to follow; having a single schema to be used in Spring and Blueprint is an option, I'd still consider such a single schema being equally useful in both cases and then if really needed have say a Blueprint specific schema adding something new to the shared one; There was some interest in CXF supporting CDI, I'm not sure if the developers who volunteered to work on that still do anything or not :-), but if it were to happen at some stage then the jaxrs frontend at least would have 'problems' :-) with a single schema only case, though it is a bit hypothetic at this stage. Personally I'd be happy at this stage if we could agree that CXF schemas will have, when possible a common namespace to be shared between Spring Blueprint; it would be the next step then how to realize that at the lower level at per-module basis, for example, using either of the 4 options listed in your email or some other approach Cheers, Sergey regards, aki 2011/12/8 Sergey Beryozkinsberyoz...@gmail.com: Hi At the moment we have different namespaces for Blueprint and Spring schemas, example: http://cxf.apache.org/blueprint/core; http://cxf.apache.org/core; and so on for all other namespaces. I'd like to propose to keep a single namespace, example, http://cxf.apache.org/core;, etc. Spring schemas are located in /schemas resource folders, and blueprint ones in /schemas-blueprint, so I guess Blueprint and Spring will know where to look for their schemas. IMHO we should do before it is too late, it may be problematic now, but may be that is what we should do for 2.6 and document it in the Migration guide. Or is the idea that in Blueprint CXF might offer some features that won't be possible in Spring ? That may be of interest but I guess in that case we can have two namespaces for using in Blueprint: http://cxf.apache.org/blueprint/core; http://cxf.apache.org/core; with the former one identifying the schema which say imports the schema identified by the latter ns and adds some Blueprint centric extensions Thanks, Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Some questions about the in CORS filter
Hi Benson On 05/12/11 16:11, Benson Margulies wrote: I translate Anne's answer just now as follows: To return information to the client, it has to be 2xx. So in the success case, it has to be 2xx. If it fails, we can do whatever we prefer: 2xx and no CORS headers or 4xx. I'm with you on a 4xx. I've updated the filter to return an empty Response in case of preflight failures but still keeping 200 by default, which can be customized to 410 or whatever status is preferred by a given client, I thought that may be 410 was not that precise, as it does not indicate to the client that the check actually took place. either way we can configure the status :-) Cheers, Sergey
Some questions about the in CORS filter
Hi Benson, all
At the moment the in CORS filter returns 'null' during a preflight
check, whenever some check fails, which means that most likely an HTTP
status code will be returned to do with failure at the selection
algorithm stage, but that status code may not necessarily to be the one
expected by the CORS client ? I'm wondering of we should return some
more specific HTTP status code instead of depending on the runtime to
eventually fail this preflight request.
The other question which we've discussed with Benson is what to do in
the case like this:
@Path(/somepath)
public class Resource {
@GET
@Produces(application/xml)
public Book getXML() {}
@GET
@Produces(application/json)
public Book getXML() {}
}
The info CORS provides is sufficient enough to select either of the the
above 2 methods thus the question is what to do at the preflight check.
In this case we thought we can expect a CrossResourceSharingAnnotation
being added to the 'good' method, or even to the all of them, possibly
uing a class-level annotation:
@Path(/somepath)
@CrossResourceSharingAnnotation(...)
public class Resource {
@GET
@Produces(application/xml)
public Book getXML() {}
@GET
@Produces(application/json)
public Book getXML() {}
}
or in case of POST:
@Path(/somepath)
public class Resource {
@POST
@Consumes(application/xml)
@CrossResourceSharingAnnotation(...)
public void addXML(Book) {}
@POST
@Consumes(multipart/form-data)
public void upload(MultipartBody) {}
}
We can also think of some configuration tricks.
Ex, if the consumer does know that only an upload POST method is 'valid'
then we can configure a CORS filter with the acceptType value which will
be passed on to the JAXRS runtime to confirm that such a method actually
exists
For the record, as agreed with Benson, I updated the filter to delegate
to the runtime to find a valid matching method during a preflight check
which is more secure than depending on the custom annotation
Cheers, Sergey
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Some questions about the in CORS filter
On 05/12/11 13:23, Benson Margulies wrote:
On Mon, Dec 5, 2011 at 7:15 AM, Sergey Beryozkinsberyoz...@gmail.com wrote:
Hi Benson, all
At the moment the in CORS filter returns 'null' during a preflight check,
whenever some check fails, which means that most likely an HTTP status code
will be returned to do with failure at the selection algorithm stage, but
that status code may not necessarily to be the one expected by the CORS
client ? I'm wondering of we should return some more specific HTTP status
code instead of depending on the runtime to eventually fail this preflight
request.
Maybe I don't understand filters.
The cors spec never, ever, calls for failing the overall HTTP request.
It calls for adding extra headers if the request is good, and not
adding them if it is bad, and otherwise leaving it alone.
Are you referring to the actual request which follows a preflight request ?
I'm looking at [1] and I'm not sure how does the client (browser ?) can
decide that a preflight request was not successful.
The filter returns Response.ok().build() in the end of the preflight
check, which indeed will let the out CORS filter to finalize the
preflight response but in cases where the preflight check was not good
then I believe a random HTTP error status will be returned depending on
where the selection algorithm fails afterwards (may be it is a path
mismatch or unexpected verb/content-type/accept-type).
Cheers, Sergey
Now, we could design a unified JAX-RS security feature that
incorporated CORS as part of its job. It could, if asked, fail
requests if they failed to meet the requirements.
[1] http://www.w3.org/TR/cors/
The other question which we've discussed with Benson is what to do in the
case like this:
@Path(/somepath)
public class Resource {
@GET
@Produces(application/xml)
public Book getXML() {}
@GET
@Produces(application/json)
public Book getXML() {}
}
The info CORS provides is sufficient enough to select either of the the
above 2 methods thus the question is what to do at the preflight check.
In this case we thought we can expect a CrossResourceSharingAnnotation being
added to the 'good' method, or even to the all of them, possibly uing a
class-level annotation:
@Path(/somepath)
@CrossResourceSharingAnnotation(...)
public class Resource {
@GET
@Produces(application/xml)
public Book getXML() {}
@GET
@Produces(application/json)
public Book getXML() {}
}
or in case of POST:
@Path(/somepath)
public class Resource {
@POST
@Consumes(application/xml)
@CrossResourceSharingAnnotation(...)
public void addXML(Book) {}
@POST
@Consumes(multipart/form-data)
public void upload(MultipartBody) {}
}
We can also think of some configuration tricks.
Ex, if the consumer does know that only an upload POST method is 'valid'
then we can configure a CORS filter with the acceptType value which will be
passed on to the JAXRS runtime to confirm that such a method actually exists
For the record, as agreed with Benson, I updated the filter to delegate to
the runtime to find a valid matching method during a preflight check which
is more secure than depending on the custom annotation
Cheers, Sergey
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Some questions about the in CORS filter
Hi
On 05/12/11 15:15, Sergey Beryozkin wrote:
On 05/12/11 13:23, Benson Margulies wrote:
On Mon, Dec 5, 2011 at 7:15 AM, Sergey Beryozkinsberyoz...@gmail.com
wrote:
Hi Benson, all
At the moment the in CORS filter returns 'null' during a preflight
check,
whenever some check fails, which means that most likely an HTTP
status code
will be returned to do with failure at the selection algorithm stage,
but
that status code may not necessarily to be the one expected by the CORS
client ? I'm wondering of we should return some more specific HTTP
status
code instead of depending on the runtime to eventually fail this
preflight
request.
Maybe I don't understand filters.
The cors spec never, ever, calls for failing the overall HTTP request.
It calls for adding extra headers if the request is good, and not
adding them if it is bad, and otherwise leaving it alone.
Are you referring to the actual request which follows a preflight request ?
I'm looking at [1] and I'm not sure how does the client (browser ?) can
decide that a preflight request was not successful.
The filter returns Response.ok().build() in the end of the preflight
check, which indeed will let the out CORS filter to finalize the
preflight response but in cases where the preflight check was not good
then I believe a random HTTP error status will be returned depending on
where the selection algorithm fails afterwards (may be it is a path
mismatch or unexpected verb/content-type/accept-type).
I can see the out filter sets certain values
in case of a preflight response - but it can only guess that the
preflight took place only if the in filter managed to reach the end of
its preflight processing.
I guess we need to set a message with a preflight and return
Response.ok().build() in all the branches in the in preflight handler,
right ?
Now, we could design a unified JAX-RS security feature that
incorporated CORS as part of its job. It could, if asked, fail
requests if they failed to meet the requirements.
By the way, I start thinking we should move this code to its own
rs/security/cors because it is really about the security and something
tells me some more code will come :-)
Cheers, Sergey
[1] http://www.w3.org/TR/cors/
The other question which we've discussed with Benson is what to do in
the
case like this:
@Path(/somepath)
public class Resource {
@GET
@Produces(application/xml)
public Book getXML() {}
@GET
@Produces(application/json)
public Book getXML() {}
}
The info CORS provides is sufficient enough to select either of the the
above 2 methods thus the question is what to do at the preflight check.
In this case we thought we can expect a
CrossResourceSharingAnnotation being
added to the 'good' method, or even to the all of them, possibly uing a
class-level annotation:
@Path(/somepath)
@CrossResourceSharingAnnotation(...)
public class Resource {
@GET
@Produces(application/xml)
public Book getXML() {}
@GET
@Produces(application/json)
public Book getXML() {}
}
or in case of POST:
@Path(/somepath)
public class Resource {
@POST
@Consumes(application/xml)
@CrossResourceSharingAnnotation(...)
public void addXML(Book) {}
@POST
@Consumes(multipart/form-data)
public void upload(MultipartBody) {}
}
We can also think of some configuration tricks.
Ex, if the consumer does know that only an upload POST method is 'valid'
then we can configure a CORS filter with the acceptType value which
will be
passed on to the JAXRS runtime to confirm that such a method actually
exists
For the record, as agreed with Benson, I updated the filter to
delegate to
the runtime to find a valid matching method during a preflight check
which
is more secure than depending on the custom annotation
Cheers, Sergey
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Some questions about the in CORS filter
Hi
On 05/12/11 15:39, Benson Margulies wrote:
On Mon, Dec 5, 2011 at 10:15 AM, Sergey Beryozkinsberyoz...@gmail.com wrote:
On 05/12/11 13:23, Benson Margulies wrote:
On Mon, Dec 5, 2011 at 7:15 AM, Sergey Beryozkinsberyoz...@gmail.com
wrote:
Hi Benson, all
At the moment the in CORS filter returns 'null' during a preflight check,
whenever some check fails, which means that most likely an HTTP status
code
will be returned to do with failure at the selection algorithm stage, but
that status code may not necessarily to be the one expected by the CORS
client ? I'm wondering of we should return some more specific HTTP status
code instead of depending on the runtime to eventually fail this
preflight
request.
Maybe I don't understand filters.
The cors spec never, ever, calls for failing the overall HTTP request.
It calls for adding extra headers if the request is good, and not
adding them if it is bad, and otherwise leaving it alone.
Are you referring to the actual request which follows a preflight request ?
I'm looking at [1] and I'm not sure how does the client (browser ?) can
decide that a preflight request was not successful.
The filter returns Response.ok().build() in the end of the preflight check,
which indeed will let the out CORS filter to finalize the preflight response
but in cases where the preflight check was not good then I believe a random
HTTP error status will be returned depending on where the selection
algorithm fails afterwards (may be it is a path mismatch or unexpected
verb/content-type/accept-type).
Yes, I see the problem here, but I don't quite know what to do.
Preflight seems to be carefully defined to get along with any existing
OPTIONS handling that is going on. So, if the programmer has an
OPTIONS method that matches, the situation is supposed to be the same
as the situation with simple requests and, say, GET handlers.
Will the JAX-RS code ever dispatch OPTIONS to a function that doesn't
have an @OPTIONS?
No
If so, I think that the problem here is more
serious. If not, I'm not sure we have a problem. I'm also not sure
that the CORS spec exactly makes sense, and I'm going to send them
some email.
My understanding now is that the client decides on whether a preflight
failed or not by checking the response headers.
Our in filter adds them one by one, or rather it prepares the info for
the out filter to decide what to add in case of preflights being processed.
Thus if the client always expects OK and only uses headers to figure out
what happened then the in filter should just always return Response.OK,
the earlier it does so the less info it will save for the response
filter and the less chance the response filter will have to provide all
the expected headers - but some clarifications at the spec level will help
Cheers, Sergey
Cheers, Sergey
Now, we could design a unified JAX-RS security feature that
incorporated CORS as part of its job. It could, if asked, fail
requests if they failed to meet the requirements.
[1] http://www.w3.org/TR/cors/
The other question which we've discussed with Benson is what to do in the
case like this:
@Path(/somepath)
public class Resource {
@GET
@Produces(application/xml)
public Book getXML() {}
@GET
@Produces(application/json)
public Book getXML() {}
}
The info CORS provides is sufficient enough to select either of the the
above 2 methods thus the question is what to do at the preflight check.
In this case we thought we can expect a CrossResourceSharingAnnotation
being
added to the 'good' method, or even to the all of them, possibly uing a
class-level annotation:
@Path(/somepath)
@CrossResourceSharingAnnotation(...)
public class Resource {
@GET
@Produces(application/xml)
public Book getXML() {}
@GET
@Produces(application/json)
public Book getXML() {}
}
or in case of POST:
@Path(/somepath)
public class Resource {
@POST
@Consumes(application/xml)
@CrossResourceSharingAnnotation(...)
public void addXML(Book) {}
@POST
@Consumes(multipart/form-data)
public void upload(MultipartBody) {}
}
We can also think of some configuration tricks.
Ex, if the consumer does know that only an upload POST method is 'valid'
then we can configure a CORS filter with the acceptType value which will
be
passed on to the JAXRS runtime to confirm that such a method actually
exists
For the record, as agreed with Benson, I updated the filter to delegate
to
the runtime to find a valid matching method during a preflight check
which
is more secure than depending on the custom annotation
Cheers, Sergey
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Some questions about the in CORS filter
The filter returns Response.ok().build() in the end of the preflight
check,
which indeed will let the out CORS filter to finalize the preflight
response
but in cases where the preflight check was not good then I believe a
random
HTTP error status will be returned depending on where the selection
algorithm fails afterwards (may be it is a path mismatch or unexpected
verb/content-type/accept-type).
Yes, I see the problem here, but I don't quite know what to do.
Preflight seems to be carefully defined to get along with any existing
OPTIONS handling that is going on. So, if the programmer has an
OPTIONS method that matches, the situation is supposed to be the same
as the situation with simple requests and, say, GET handlers.
Will the JAX-RS code ever dispatch OPTIONS to a function that doesn't
have an @OPTIONS?
No
If so, I think that the problem here is more
serious. If not, I'm not sure we have a problem. I'm also not sure
that the CORS spec exactly makes sense, and I'm going to send them
some email.
My understanding now is that the client decides on whether a preflight
failed or not by checking the response headers.
Our in filter adds them one by one, or rather it prepares the info for
the out filter to decide what to add in case of preflights being processed.
Thus if the client always expects OK and only uses headers to figure out
what happened then the in filter should just always return Response.OK,
the earlier it does so the less info it will save for the response
filter and the less chance the response filter will have to provide all
the expected headers - but some clarifications at the spec level will help
So it is 410 - I'll do a quick update and ask for the review
Sergey
Cheers, Sergey
Cheers, Sergey
Now, we could design a unified JAX-RS security feature that
incorporated CORS as part of its job. It could, if asked, fail
requests if they failed to meet the requirements.
[1] http://www.w3.org/TR/cors/
The other question which we've discussed with Benson is what to do
in the
case like this:
@Path(/somepath)
public class Resource {
@GET
@Produces(application/xml)
public Book getXML() {}
@GET
@Produces(application/json)
public Book getXML() {}
}
The info CORS provides is sufficient enough to select either of the
the
above 2 methods thus the question is what to do at the preflight
check.
In this case we thought we can expect a CrossResourceSharingAnnotation
being
added to the 'good' method, or even to the all of them, possibly
uing a
class-level annotation:
@Path(/somepath)
@CrossResourceSharingAnnotation(...)
public class Resource {
@GET
@Produces(application/xml)
public Book getXML() {}
@GET
@Produces(application/json)
public Book getXML() {}
}
or in case of POST:
@Path(/somepath)
public class Resource {
@POST
@Consumes(application/xml)
@CrossResourceSharingAnnotation(...)
public void addXML(Book) {}
@POST
@Consumes(multipart/form-data)
public void upload(MultipartBody) {}
}
We can also think of some configuration tricks.
Ex, if the consumer does know that only an upload POST method is
'valid'
then we can configure a CORS filter with the acceptType value which
will
be
passed on to the JAXRS runtime to confirm that such a method actually
exists
For the record, as agreed with Benson, I updated the filter to
delegate
to
the runtime to find a valid matching method during a preflight check
which
is more secure than depending on the custom annotation
Cheers, Sergey
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Some questions about the in CORS filter
On 05/12/11 16:00, Benson Margulies wrote:
On Mon, Dec 5, 2011 at 10:42 AM, Sergey Beryozkinsberyoz...@gmail.com wrote:
Hi
On 05/12/11 15:15, Sergey Beryozkin wrote:
On 05/12/11 13:23, Benson Margulies wrote:
On Mon, Dec 5, 2011 at 7:15 AM, Sergey Beryozkinsberyoz...@gmail.com
wrote:
Hi Benson, all
At the moment the in CORS filter returns 'null' during a preflight
check,
whenever some check fails, which means that most likely an HTTP
status code
will be returned to do with failure at the selection algorithm stage,
but
that status code may not necessarily to be the one expected by the CORS
client ? I'm wondering of we should return some more specific HTTP
status
code instead of depending on the runtime to eventually fail this
preflight
request.
Maybe I don't understand filters.
The cors spec never, ever, calls for failing the overall HTTP request.
It calls for adding extra headers if the request is good, and not
adding them if it is bad, and otherwise leaving it alone.
Are you referring to the actual request which follows a preflight request
?
I'm looking at [1] and I'm not sure how does the client (browser ?) can
decide that a preflight request was not successful.
The filter returns Response.ok().build() in the end of the preflight
check, which indeed will let the out CORS filter to finalize the
preflight response but in cases where the preflight check was not good
then I believe a random HTTP error status will be returned depending on
where the selection algorithm fails afterwards (may be it is a path
mismatch or unexpected verb/content-type/accept-type).
I can see the out filter sets certain values
in case of a preflight response - but it can only guess that the preflight
took place only if the in filter managed to reach the end of its preflight
processing.
I guess we need to set a message with a preflight and return
Response.ok().build() in all the branches in the in preflight handler,
right ?
That's exactly what I'm trying to sort out with the w3c mailing list.
There are two cases:
1) There's an @OPTIONS method that applies. In this case, it seems
pretty clear to me that the appropriate response is whatever comes
from the @OPTIONS method.
+1
2) There's no @OPTIONS method. In this case, I'm leaning to returning
an OK whether the preflight algorithm succeeds or fails, on the
grounds that the server successfully handled the OPTIONS -- and the
returned headers are the information the client was looking for.
I think it is still 410 - it does not matter to the client side why it
is 410 (network/domain error or a custom preflight check error), either
way it's a failure, but I'll pause a bit :-)
Cheers, SErgey
Now, we could design a unified JAX-RS security feature that
incorporated CORS as part of its job. It could, if asked, fail
requests if they failed to meet the requirements.
By the way, I start thinking we should move this code to its own
rs/security/cors because it is really about the security and something tells
me some more code will come :-)
no argument.
Cheers, Sergey
[1] http://www.w3.org/TR/cors/
The other question which we've discussed with Benson is what to do in
the
case like this:
@Path(/somepath)
public class Resource {
@GET
@Produces(application/xml)
public Book getXML() {}
@GET
@Produces(application/json)
public Book getXML() {}
}
The info CORS provides is sufficient enough to select either of the the
above 2 methods thus the question is what to do at the preflight check.
In this case we thought we can expect a
CrossResourceSharingAnnotation being
added to the 'good' method, or even to the all of them, possibly uing a
class-level annotation:
@Path(/somepath)
@CrossResourceSharingAnnotation(...)
public class Resource {
@GET
@Produces(application/xml)
public Book getXML() {}
@GET
@Produces(application/json)
public Book getXML() {}
}
or in case of POST:
@Path(/somepath)
public class Resource {
@POST
@Consumes(application/xml)
@CrossResourceSharingAnnotation(...)
public void addXML(Book) {}
@POST
@Consumes(multipart/form-data)
public void upload(MultipartBody) {}
}
We can also think of some configuration tricks.
Ex, if the consumer does know that only an upload POST method is 'valid'
then we can configure a CORS filter with the acceptType value which
will be
passed on to the JAXRS runtime to confirm that such a method actually
exists
For the record, as agreed with Benson, I updated the filter to
delegate to
the runtime to find a valid matching method during a preflight check
which
is more secure than depending on the custom annotation
Cheers, Sergey
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Add .htaccess redirect for CXF schemas....
On 02/12/11 19:56, Daniel Kulp wrote: This is probably long overdue I added an .htaccess file to the root of the website which will redirect the CXF schema namespaces to the appropriate schema files on the live site. For example, if you point your browser at: http://cxf.apache.org/core (the namespace for the cxf core objects like cxf:bus) it will automatically redirect you to: http://cxf.apache.org/schemas/core.xsd and likewise for the other namespaces. Anyway, that should help folks find the right schemas and maybe help with XML editors and such. Very very nice, Cheers, Sergey
Re: [proposal] Cross-Origin JAX-RS annotations
Hi Benson On 02/12/11 22:16, Benson Margulies wrote: On Fri, Dec 2, 2011 at 4:45 PM, Sergey Beryozkinsberyoz...@gmail.com wrote: Hi Benson I think we should get rid of that Class level annotation that you introduced. It is not secure enough - the path and verb values it lists - they can not serve as a guarantee that the actual resource handler exists. They simply duplicate @Path @GET/friends. I propose to get rid of it. As I said, JAXRSUtils.getResourceClass JAXRSUtils.findOperation are the only guarantee and we should not be concerned if we have multiple GET handlers listening on the same path but differing in @Produces. Sergey, I don't yet agree(, but you'll probably convince me eventually). The whole thrust of my discussion with the CORS people is that CORS isn't exactly security. A service cannot delegate security to the browser. The browser could be hacked. The effect of CORS is to instruct the browser to open up a range of resources, but it's still up to the actual handlers for those resources in the server to implement security. @CrossScriptResourceSharing can be used to enforce the security on the server side; the class-level annotation may give us the illusion of security at the CORS level but it won't guarantee that JAXRS runtime will actually find such a matching resource. The only vocabulary for instructing the browser is URI+method, and the annotation does that. That being said, could I interest you in starting by producing an alternative version of the package.html that would explain to a user how to use your preferred alternative? I'll try but a bit later on once I get to grips with CORS :-) If I could read a user-facing document that explained what a user should do, I'd stop carping. Meanwhile, I had a thought that may just be identical to yours, but I'm feeling really slow. Let's say that we eliminate the nested annotation business. Also note that this mess only applies to preflight, so as an example I'll talk about PUT. Now, what exactly happens if we have multiple @PUT handlers for the same URI that dispatch on the incoming Content-Type, or on the presence of particular multipart pieces, which are the losing cases? We could say: Only one of them may have a @CrossScriptResourceSharing annotation. If more than one have it, we throw. Or we log and decline fail the CORS transaction. How's about that? Exactly, +1. We don't need to worry right now about such fine-grained cases where we have multiple PUT handlers which only differ from each other by accepted or produced media types, if CORS will eventually get other headers introduced to do with the major headers such as Content-Type or Accept then we will deal with such cases better. So the method selected by the runtime must contain the annotation @CrossScriptResourceSharing. I think we should configure the CORS filter with preferred Content-Type Accept header values which if set will be used during the try selection initiated by the CORS filter, otherwise we can just default to */*; it will only be needed when the developer know that say multiple PUT handlers exist; So JAXRSUtils.findResourceClass followed by JAXRSUtils.findTargetMethod in combination with @CrossScriptResourceSharing is all we need; Cheers, Sergey
Re: A moment of confusion about http headers and JAX-RS responses?
On 01/12/11 16:16, Benson Margulies wrote: I should know this, but ... The CORS spec says: Split the value of the Origin header on the U+0020 SPACE character and if any of the resulting tokens is not a case-sensitive match for any of the values in list of origins do not set any additional headers and terminate this set of steps. Now, if I'm using JAX-RS to send back the response to one of these, and the input was multiple origins, does responseBuilder.header(Origin, a); responseBuilder.header(Origin, b); create the same sort of space-separated thing, or am I supposed to glue for myself first? That will result in Origin: a, b or may be Origin: a Origin: b I believe we have a property which can be used to manage how multiple values are set. So probably responseBuilder.header(Origin, a b c); :-) Cheers, Sergey
Re: [proposal] Cross-Origin JAX-RS annotations
Hi Benson On 01/12/11 18:36, Benson Margulies wrote: Sergey, I've hit a snag with preflight. In preflight, the client sends an OPTIONS with a 'requestMethod' and we have to decide if we like that method. This is section 6.1.5. The client sends OPTIONS with the method, a list of custom headers, and of course the full URL. I need to map that to the method that would be selected for the actual request to look at the annotations. That is, given a method as a string and a URL, I need to obtain the 'annotated method' that would be invoked. Not everything we'd usually use to select a method will be there. In particular, if the Consumes is 'interesting', the relevant content-type won't be there. Here's the list of request headers that will come with the OPTIONS header. You can use JAXRSUtils.selectResourceClass JAXRSUtils.findTargetMethod, create an empty Message Accept, Accept-Language, Content-Language, or Last-Event-ID, or if it is an ASCII case-insensitive match for Content-Type and the header field value media type (excluding parameters) is an ASCII case-insensitive match for application/x-www-form-urlencoded, multipart/form-data, or text/plain. HttpHeaders should help there, lookups are case-insensitive Does it help a bit ? Cheers, Sergey The coward's way out of this is to use only class-level annotations for preflight, and document that we're doing so. Can you think of any better alternative? -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: 'parsing failed' -- detecting invalid headers
On 30/11/11 15:21, Benson Margulies wrote: In many cases, http://www.w3.org/TR/cors/#resource-preflight-requests calls for the service to note the presence of an invalid header differently from no header at all. Have we got any way to keep track of this? or do we already reject requests with 'imparsible' headers? You can get @Context HttpHeaders injected in the filter and check the headers. The only headers which are always checked on every request are Content-Type and Accept and if those are invalid then an error HTTP status will be returned. Conditional headers may be checked optionally but other custom headers are just copied/returned as is if they are requested Cheers, Sergey
Re: Test Cases failing due to double slash in the URL generated by CXF
Hi Try the 2.4.5-SNAPSHOT please, it will be built in the next few hours Cheers, Sergey On 26/11/11 04:31, irfannagoo wrote: Hi Sergey, That would be great to add a check for double slash in version 2.4.3. I hope after adding the check we would be able to invoke the REST APIs with normal single slash instead of double slash (which happens sometimes). Thanks a lot for your help on this. It would be great if you could tell us by when can we start using the new version of UrlInfoImpl class with a double slash check incorporated. Regards, Irfan -- View this message in context: http://cxf.547215.n5.nabble.com/Test-Cases-failing-due-to-double-slash-in-the-URL-generated-by-CXF-tp5016478p5024360.html Sent from the cxf-issues mailing list archive at Nabble.com. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: How to contribue a CXF JAX-RS OSGi Sample?
Hi KL On 23/11/11 16:02, K Fung wrote: Hi Sergey, I'm wondering if 'minimalosgi' has to be exported ? I tried this before and it didn't work. minimalosgi has one classloader; the CXF bundle has its own classloader. minimalosgi's classloader has knowledge about CXF (due to the Import-Package declarations in its MANIFEST.MF) but CXF doesn't have knowledge of minimalosgi because it doesn't import it. Because CXF uses its own bundle classloader to resolve minimalosgi, it won't be able to find minimalosgi. Indeed, I was still thinking about DOSGi where the dsw handler has a dynamic import. I'm wondering, is it possible for CXF bundle to Dynamic-Import everything but those packages which it imports via Import-Package. That should be safe enough or not ? If the JAX-RS Application class had a way to supply the Application via a Class? parameter it wouldn't be a problem because we could pass the Application object directly and not rely on creation via reflection inside CXF. Furthermore, if we had used the CXF-specific JAX-RS factory bean, I believe this servlet workaround wouldn't have been necessary. While experimenting with this issue, it may be possible to get around this by making the minimalosgi bundle a fragment bundle of the CXF bundle but I haven't clearly thought about the consequences of doing so yet. Can be worth experimenting in some time too Thanks, Sergey -kl -- Sergey Beryozkin http://sberyozkin.blogspot.com Talend Community Coders http://coders.talend.com/
Re: How to contribue a CXF JAX-RS OSGi Sample?
Hi KL On 19/11/11 17:20, K Fung wrote: Hi Sergey, I've updated CXF-3859 with my newest iteration of the code :-) great Here is what has changed in this version... + Removed use of java.net repository as mail.jar is no longer a required dependency + Bump version to 2.5.1-SNAPSHOT + Use org.codehaus.mojo:exec-maven-plugin instead of run.* + Updated README based on the above ++ To compile the sample, use mvn package ++ To run the sample, use mvn integration-test Here are my replies to some of your comments in this month-long old thread... + The Apache snapshot repository remains there to ease development; it'll be removed in the final version + Yes, it does indeed seem like wsdl4j is no longer a required dependency on the server runtime side OK + I could not remove the usage of SampleServlet. When I use just the base servlet, I get the following exception (which may be resolved by using JAXRSFactory directly but that's against the JSR-311 standard) javax.servlet.ServletException: No Application class minimalosgi.SampleApplication can be found I'm wondering if 'minimalosgi' has to be exported ? at org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet.loadClass(CXFNonSpringJaxrsServlet.java:365) at org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet.createServerFromApplication(CXFNonSpringJaxrsServlet.java:345) at org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet.init(CXFNonSpringJaxrsServlet.java:78) at org.apache.felix.http.base.internal.handler.ServletHandler.init(ServletHandler.java:55) at org.apache.felix.http.base.internal.handler.HandlerRegistry.addServlet(HandlerRegistry.java:65) at org.apache.felix.http.base.internal.service.HttpServiceImpl.registerServlet(HttpServiceImpl.java:95) at minimalosgi.Activator$1.addingService(Activator.java:58) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:339) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273) at minimalosgi.Activator.start(Activator.java:77) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284) at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1175) at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1153) at org.apache.felix.fileinstall.internal.DirectoryWatcher.processAllBundles(DirectoryWatcher.java:1146) at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:456) at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:263) Caused by: java.lang.ClassNotFoundException: minimalosgi.SampleApplication at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.apache.cxf.common.classloader.ClassLoaderUtils.loadClass2(ClassLoaderUtils.java:259) at org.apache.cxf.common.classloader.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:245) at org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet.loadClass(CXFNonSpringJaxrsServlet.java:363) ... 23 more Here is where I'm focusing the next round of improvements on... + Check if code compiles correctly in Java 5 (this one is currently stumping me, I'll need to see how ServiceMix makes it work in Java 5) + Remove excess repositories from the pom.xml + Parent pom.xml should compile JAX-RS OSGi sample + Any others? Sounds good, thanks Sergey Regards, kl -- Sergey Beryozkin http://sberyozkin.blogspot.com Talend Community Coders http://coders.talend.com/
Re: CORS
I was thinking a bit more about it, we should probably just put it into
org.apache.cxf.jaxrs.ext.cors in the jaxrs frontend at the moment, as I
think that the creation of cxf-rt-jaxrs-extensions is needed shortly
anyway which could keep most of the extensions, we can 'spawn' more
specific modules from it as needed, I'd like to keep the web client api
so it will live in its own extensions module, etc
Sergey
On 19/11/11 00:10, Benson Margulies wrote:
OK, but attaching it to a JIRA still gives is clear provenance and we
can find it a home later.
On Fri, Nov 18, 2011 at 11:48 AM, Sergey Beryozkinsberyoz...@gmail.com wrote:
Hi Benson
On 18/11/11 00:25, Benson Margulies wrote:
Serg,
To contribute code, it's preferred, if possible, to attach it to a JIRA.
I was thinking of simply documenting it for a start as I'm not sure where to
add this code to. I guess I'd like it to go to a sep module but at this
stage creating a module for keeping two simple filters may be a bit early.
We can have another extension package added for a start to the rs frontend,
and move it elsewhere, but I'm a bit cautious about it too as the frontend
module is becoming quite monolitic and it will need to be split in time too,
so I'm thinking that may be we just doc it and users will simply copy
paste the simple code, same way we started with JSONP code fragments.
Sergey
--benson
On Thu, Nov 17, 2011 at 12:39 PM, sergkorneysergkor...@gmail.comwrote:
here it is:
public class JaxrsCorsInputFilter implements RequestHandler {
final static String HEADER_ORIGIN = origin;
@Context
private HttpHeaders headers;
private ListStringallowedOrigins;
public void setAllowedOrigins(ListStringallowedOrigins) {
this.allowedOrigins = allowedOrigins;
}
@Override
public Response handleRequest(Message m, ClassResourceInfo
resourceClass) {
if (OPTIONS.equals(m.get(Message.HTTP_REQUEST_METHOD))) {
OperationResourceInfo opResInfo =
m.getExchange().get(OperationResourceInfo.class);
if (opResInfo != null) { // OPTIONS method defined in
service bean
return null; // continue handling
}
return Response.status(Status.SERVICE_UNAVAILABLE).build();
}
ListStringvalues = headers.getRequestHeader(HEADER_ORIGIN);
if (values != null ) {
boolean allowed = true;
if (allowedOrigins != null) {
allowed = allowedOrigins.containsAll(values);
}
if (allowed) {
m.getExchange().put(HEADER_ORIGIN, values);
}
}
return null;
}
}
--
View this message in context:
http://cxf.547215.n5.nabble.com/CORS-tp4970153p5001897.html
Sent from the cxf-dev mailing list archive at Nabble.com.
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend Community Coders
http://coders.talend.com/
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend Community Coders
http://coders.talend.com/
Re: Upgrading from 2.1.4 to 2.1.9
On 23/11/11 14:17, matiou wrote:
Hi Dan,
Thank you for your fast reply.
Daniel Kulp wrote
The error makes it sound like there is an XML issue. Can you post the xml
configuration ?
Here is the xml configuration file, which is pretty light (and works in
2.1.4) :
?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:sec=http://cxf.apache.org/configuration/security;
xmlns:http=http://cxf.apache.org/transports/http/configuration;
xmlns:jaxws=http://java.sun.com/xml/ns/jaxws;
xmlns:wsa=http://cxf.apache.org/ws/addressing;
xmlns:cxf=http://cxf.apache.org/core;
xsi:schemaLocation=http://cxf.apache.org/core
http://cxf.apache.org/schemas/core.xsd
http://cxf.apache.org/configuration/security
http://cxf.apache.org/schemas/configuration/security.xsd
http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd;
http:conduit name=*.http-conduit
http:client AutoRedirect=true Connection=Keep-Alive
ConnectionTimeout=6000 ReceiveTimeout=6000 CacheControl=no-cache
AllowChunking=false /
/http:conduit
/beans
Daniel Kulp wrote
You can also try adding the namespaces needed to the http-conduit element.
That MAY help.
What's the namespaces you are talking about ? I don't see any mention of
namespace needed in the stackstrace.
something like that I guess
http:conduit
name={http://example.com/}HelloWorldServicePort.http-conduit;
Sergey
Daniel Kulp wrote
It almost sounds like you aren't picking up woodstox, but I'm not really
sure. 2.1.9 was still long enough ago that I'm not sure what the state of
everything was. I'd definitely suggest up
dating to 2.5.0 if possible and trying to see if that fixes things.
OK, I'll try it, hoping there will not be migration problem
Thanks, matiou
--
View this message in context:
http://cxf.547215.n5.nabble.com/Upgrading-from-2-1-4-to-2-1-9-tp5009968p5016781.html
Sent from the cxf-dev mailing list archive at Nabble.com.
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend Community Coders
http://coders.talend.com/
Re: CORS
Hi Benson
On 18/11/11 00:25, Benson Margulies wrote:
Serg,
To contribute code, it's preferred, if possible, to attach it to a JIRA.
I was thinking of simply documenting it for a start as I'm not sure
where to add this code to. I guess I'd like it to go to a sep module but
at this stage creating a module for keeping two simple filters may be a
bit early.
We can have another extension package added for a start to the rs
frontend, and move it elsewhere, but I'm a bit cautious about it too as
the frontend module is becoming quite monolitic and it will need to be
split in time too, so I'm thinking that may be we just doc it and users
will simply copy paste the simple code, same way we started with JSONP
code fragments.
Sergey
--benson
On Thu, Nov 17, 2011 at 12:39 PM, sergkorneysergkor...@gmail.com wrote:
here it is:
public class JaxrsCorsInputFilter implements RequestHandler {
final static String HEADER_ORIGIN = origin;
@Context
private HttpHeaders headers;
private ListString allowedOrigins;
public void setAllowedOrigins(ListString allowedOrigins) {
this.allowedOrigins = allowedOrigins;
}
@Override
public Response handleRequest(Message m, ClassResourceInfo
resourceClass) {
if (OPTIONS.equals(m.get(Message.HTTP_REQUEST_METHOD))) {
OperationResourceInfo opResInfo =
m.getExchange().get(OperationResourceInfo.class);
if (opResInfo != null) { // OPTIONS method defined in service
bean
return null; // continue handling
}
return Response.status(Status.SERVICE_UNAVAILABLE).build();
}
ListString values = headers.getRequestHeader(HEADER_ORIGIN);
if (values != null ) {
boolean allowed = true;
if (allowedOrigins != null) {
allowed = allowedOrigins.containsAll(values);
}
if (allowed) {
m.getExchange().put(HEADER_ORIGIN, values);
}
}
return null;
}
}
--
View this message in context:
http://cxf.547215.n5.nabble.com/CORS-tp4970153p5001897.html
Sent from the cxf-dev mailing list archive at Nabble.com.
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend Community Coders
http://coders.talend.com/
Re: How to contribue a CXF JAX-RS OSGi Sample?
Hi KL, (sorry if it's not a complete name :-)) On 12/11/11 06:28, K Fung wrote: Hi Sergey, Nope, you haven't discouraged me :-) It was good feedback and I'm taking it in for my next round of revision. Unfortunately, I haven't had a lot of time to put into it but I should be able to make another pass at it toward the end of November. I'm keen on continuing to work on this as something to deliver in CXF. One feedback that I did have was instead of using BundleListener to listen for incoming bundles and registering JAX-RS things, do you think it makes sense for us to use OSGI declarative services (e.g., the Maven SCR bundle) instead to have the runtime automatically do this registration/deregistration of resources? However, this would be considered more of an enhancement to the existing CXF feature set, instead of something that illustrates how to use JAX-RS, right? Right, that would overlap quite a bit with what DOSGi can offer, so I'd postpone dealing with this enhancement until later... I reckon that having a sync request for available provider services (MessageBodyReader/Writer, etc) in Activator for them to be provided to JAXRSServerFactoryBean at a time of creating an endpoint as well as listening for bundles containing Application info in META-INF/services would be fine, S META-INF/services would be fine (similarly to the way Blueprint/Spring can be used to create endpoints when installing the bundles) Cheers, Sergey Cheers, kl On Fri, Nov 11, 2011 at 9:03 AM, Sergey Beryozkinsberyoz...@gmail.comwrote: Hi, how is your demo going, hope I haven't discouraged with my comments :-) Sergey On 19/10/11 10:28, Sergey Beryozkin wrote: By the way, at the next stage we can also probably create the Activator part in the jaxrs fronentend/osgi - this can be optionally enabled and what it will do it will probably do BundleListener and check which ones contain Applications, as well as do ServiceTracker on Application, MessageReaderWriter/Reader services, etc Cheers, Sergey On 18/10/11 14:18, Sergey Beryozkin wrote: Hi Thanks for this patch, I think it's a nice interesting example, shows the bare Activator and ServiceTracker in action... Please see comments inline On 18/10/11 05:28, K Fung wrote: Hi all, I've uploaded the initial code sample to https://issues.apache.org/**jira/browse/CXF-3859https://issues.apache.org/jira/browse/CXF-3859to garner the first round of feedback. Per request, it includes a README to explains how it works. In particular, I'm looking feedback for the following issues: - What's your opinion to using the Application model instead of JAXRSServerFactoryBean directly? One thing I noted that you introduce a SampleServlet, but CXFNonSpringJAXRSServlet can handle it itself. CXFNonSpringJAXRSServlet will also make sure Application instances can get JAX-RS contexts injected if needed and Applications themselves can be injected into resource classes which is all has to be supported in JAX-RS 1.1. Using Applications is probably better for the example, but using JAXRSServerFactoryBean will provide more options (such as applying external models to non-annotated classes). Actually, I'm seeing the READme, CXFNonSpringJAXRSServlet should still be capable though, as it delegates via ResourceUtils to load the Application classes, that should work ? - Is it okay not to use the latest Eclipse Equinox? I'm not using the latest Eclipse Equinox at the moment because 1) it has issues with Felix due to use of generics and 2) the required services bundle is not registered in Maven probably OK for the purpose of the demo, perhaps README can clarify that. What about those java.net and snapshots repositories though, can we avoid using them ? - What do you think about using Apache Felix's File Install to install the bundles? Why not, Karaf is probably using that one too - Does the README require further enhancement or more description or perhaps more documentation is necessary within the sample itself? READMe is fine but I'm wondering if we should make it sound a bit more optimistic :-), we just have JAX-RS demos working in Karaf :-). In the introduction I'd only have: This sample demonstrates the minimal amount of bundles necessary to get a sample that uses CXF's JAX-RS implementation to work correctly in most OSGI environments, etc... Before I declare it fit for prime time, I would like to work on the following things: - Check if sample runs correctly on Java 5 - Check if sample should be compiled with other samples when running maven on the parent pom Please do... - Provide a run.sh sample (in addition to the current run.bat) Can we make that run using a maven profile ? Instead of having run.bat/sh ? may be you can copy paste the relevant server profile from jaxrs/spring-security or basic - Provide an enhancement that includes the use of Apache Abdera to show the (optional) import of the Abdera bundles I think the latest Abdera
