Nabble - cxf-dev

Re: JAXRS - POST

2009-12-23T08:05:36Z

Thanks Sergey...

Can you also tell me how to access this from a Client?
I created following class and when tried to access it threw 405 exception:

public class Client {

/**
* @param args
*/
public static void main(String[] args) {

HelloWorld helloWorld = WebClient.create("http://localhost:8081/SampleRestProject/helloWorld/customers").accept("application/json").get(HelloWorld.class);
}
}

Thanks
Padma

It should be @Consumes({"application/json", "application/xml"})

Also, pelase make sure ContentType of the HTTP request conatins either application/json or application/xml and that it accepts
application/json

cheers, Sergey

> @Path("/customers")
> public Customer getCustomers() {
> Customer customer = new Customer();
> customer.setId(1);
> customer.setName("Padma");
> return customer;
> }
>
> }
>
> <?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:jaxrs="http://cxf.apache.org/jaxrs"
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/jaxrs.xsd
> ">
>
> 
>
> <import resource="classpath:META-INF/cxf/cxf.xml" />
> <import
> resource="classpath:META-INF/cxf/cxf-extension-jaxrs-binding.xml" />
> <import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
>
> <jaxrs:server id="helloWorldService" address="/helloWorld">
> <jaxrs:serviceBeans>
> <ref bean="helloWorld" />
> </jaxrs:serviceBeans>
> <jaxrs:extensionMappings>
> <entry key="json" value="application/json" />
> <entry key="xml" value="application/xml" />
> </jaxrs:extensionMappings>
>
> </jaxrs:server>
>
> <bean id="helloWorld" class="com.tfs.pe.HelloWorldImpl" />
>
>
> </beans>
>
> Please help.
>
> Thanks
> Padma
>
> --
> View this message in context: http://old.nabble.com/JAXRS---POST-tp26897610p26897610.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>

Re: JAXRS - POST

2009-12-23T04:34:33Z

>
> Hi,
>
> I tried to create a RestFul JSON service with CXF. The example works for GET
> method. When i try the same with POST method, i get ".No operation matching
> request path found" error message.
> URL I hit is: http://localhost:8081/SampleRestProject/helloWorld/customers.
> Find below resource class and bean definition.
>
> @Path("/")
> @Produces("application/json")
> public class HelloWorldImpl implements HelloWorld
> {
>
> @POST
> @Produces("application/json")
> @Consumes("application/json,application/xml")

It should be @Consumes({"application/json", "application/xml"})

Also, pelase make sure ContentType of the HTTP request conatins either application/json or application/xml and that it accepts
application/json

cheers, Sergey

> @Path("/customers")
> public Customer getCustomers() {
> Customer customer = new Customer();
> customer.setId(1);
> customer.setName("Padma");
> return customer;
> }
>
> }
>
> <?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:jaxrs="http://cxf.apache.org/jaxrs"
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/jaxrs.xsd
> ">
>
> 
>
> <import resource="classpath:META-INF/cxf/cxf.xml" />
> <import
> resource="classpath:META-INF/cxf/cxf-extension-jaxrs-binding.xml" />
> <import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
>
> <jaxrs:server id="helloWorldService" address="/helloWorld">
> <jaxrs:serviceBeans>
> <ref bean="helloWorld" />
> </jaxrs:serviceBeans>
> <jaxrs:extensionMappings>
> <entry key="json" value="application/json" />
> <entry key="xml" value="application/xml" />
> </jaxrs:extensionMappings>
>
> </jaxrs:server>
>
> <bean id="helloWorld" class="com.tfs.pe.HelloWorldImpl" />
>
>
> </beans>
>
> Please help.
>
> Thanks
> Padma
>
> --
> View this message in context: http://old.nabble.com/JAXRS---POST-tp26897610p26897610.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>

JAXRS - POST

2009-12-22T21:15:21Z

Hi,

I tried to create a RestFul JSON service with CXF. The example works for GET method. When i try the same with POST method, i get ".No operation matching request path found" error message.
URL I hit is: http://localhost:8081/SampleRestProject/helloWorld/customers.
Find below resource class and bean definition.

@Path("/")
@Produces("application/json")
public class HelloWorldImpl implements HelloWorld
{

@POST
@Produces("application/json")
@Consumes("application/json,application/xml")
@Path("/customers")
public Customer getCustomers() {
Customer customer = new Customer();
customer.setId(1);
customer.setName("Padma");
return customer;
}

}

<?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:jaxrs="http://cxf.apache.org/jaxrs"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxrs
http://cxf.apache.org/schemas/jaxrs.xsd
">



<import resource="classpath:META-INF/cxf/cxf.xml" />
<import
resource="classpath:META-INF/cxf/cxf-extension-jaxrs-binding.xml" />
<import resource="classpath:META-INF/cxf/cxf-servlet.xml" />

<jaxrs:server id="helloWorldService" address="/helloWorld">
<jaxrs:serviceBeans>
<ref bean="helloWorld" />
</jaxrs:serviceBeans>
<jaxrs:extensionMappings>
<entry key="json" value="application/json" />
<entry key="xml" value="application/xml" />
</jaxrs:extensionMappings>

</jaxrs:server>

<bean id="helloWorld" class="com.tfs.pe.HelloWorldImpl" />

</beans>

Please help.

Thanks
Padma

Re: Spring 3 and SpringSecurity 2.0.4 tests

2009-12-21T13:41:32Z

On Mon December 21 2009 12:38:45 pm Sergey Beryozkin wrote:
> Hi,
>
> The jaxrs spring security system tests should be paasing now with
> -Pspring3, I did a minor update to the spring aop helper to ensure double
> cglib proxies are handled ok...

Major thanks Sergey!

> I actully tried with updating the tests to use SpringSecurity 3.0.RC2, but
> I'd consider introducing SpringSecurity 3.0 specific tests later on, given
> that they changed the package name for Secured annotation, etc

Yea. I definitely prefer keeping things working with Spring 2.5 as the
default for now. I'm glad it all now works with Spring 3.0 as well. :-)

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

Re: Questions regarding JAX-RS exception handling

2009-12-21T09:54:44Z

Hi Cyrille

Please see comments inline

>
> Dear all,
>
> I am looking at the consistency of exception handling among JAX-WS
> and JAX-RS. My primary goal is to ensure cxf management metrics (JMX)
> are consistent.
>
> Here are few questions :
>
> SERVER SIDE JAXRS EXCEPTION MAPPER
> ====================================
>
> If an ExceptionMapper handles the exception :
>
> 1) The JAXRSInvoker returns a Response instead of throwing an Exception

Yes, this is for JAXRS message body writers be able to handle whatever Response entity a given mapper might've set up.

>
> 2) Thus PhaseInterceptorChain does NOT see that an exception occurred
> during the invocation

Yes

>
> 3) Thus the "Out Interceptors" are not replaced by the "Out Fault
> Interceptors" and these "Out Interceptors" are called on
> #handleMessage() with the outMessage (ie the response created by the
> ExceptionMapper) instead of being called on #handleFaultMessage() with
> the inMessage when information like the FaultMode is still holded by
> the inMessage

Yes

>
> 4) Interceptors like the ResponseTimeMessageOutInterceptor who rely on
> the faultMode attribute located on the Message that is being passed to
> handleMessage/handleFault are lost, they don't find the information
> they look for

I see...

>
> Questions :
> * Wouldn't it make sense to call the "Out Fault Interceptors" if a
> JAX-RS exception is mapped to a custom response ?

Now that you suggested it, perhaps, one alternative in mapping exceptions to exception mappers would be to
register JAX-RS specific fault interceptors which will do the mapping, instead of doing it in the JAXRSInInterceptor or
JAXRSInvoker...
So other registered fault interceptors will get their chance as well...

What complicates things a bit is that JAXRS users can have ResponseHandler filteres registered which can override the
ExceptionMapper responses...

> * which message should be given to the handleFaultMessage() ? The
> inMessage that caused the exception and that holds the exception as an
> attribute (it would be consistent with JAX-WS) or the outMessage as
> currently done ?

Perhaps we should consider introducing JAXRS fault interceptors ? They will do Exception Mapping and abort the chain if the mapping
has been found ? I'm not yet sure how feasible and/or sensitive such a change might be, but may be it will be the right step forward

>
> CLIENT SIDE JAXRS EXCEPTION HANDLING
> =============================================
>
> ClientProxyImpl handles exceptions after calling the interceptors
> when, with JAX-WS, exception handling (CheckFaultInterceptor) is
> performed in the POST_PROTOCOL phase.
>
> Due to this, the "In Interceptors Chain" is called instead of the "In
> Fault Interceptors Chain" and interceptors like
> ResponseTimeMessageInInterceptor don't see the Response as an
> exception.
>
> Question :
> Can we imagine to refactor jaxrs client side exception handling as a
> post protocol interceptor ?

The client side needs some refactoring going forward....Some of its code would definitely need to be moved to some isolated
interceptors. However, please see JAXRSSoapBookTest, Eamonn did quite a few tests with faulty features/interceptors/server faults...

>
>
> I hope this email was not too long ; it took me few hours to check all
> these use cases and figure out how it worked :-)

No problems :-), please type as long a message as you'd like to :-), thanks for starting this thread

cheers, Sergey

>
> Cyrille
> --
> Cyrille Le Clerc
> cleclerc@...

Spring 3 and SpringSecurity 2.0.4 tests

2009-12-21T09:38:45Z

Hi,

The jaxrs spring security system tests should be paasing now with -Pspring3, I did a minor update to the spring aop helper to ensure
double cglib proxies are handled ok...

I actully tried with updating the tests to use SpringSecurity 3.0.RC2, but I'd consider introducing SpringSecurity 3.0 specific
tests later on, given that they changed the package name for Secured annotation, etc

cheers, Sergey

Questions regarding JAX-RS exception handling

2009-12-21T08:52:02Z

Dear all,

I am looking at the consistency of exception handling among JAX-WS
and JAX-RS. My primary goal is to ensure cxf management metrics (JMX)
are consistent.

Here are few questions :

SERVER SIDE JAXRS EXCEPTION MAPPER
====================================

If an ExceptionMapper handles the exception :

1) The JAXRSInvoker returns a Response instead of throwing an Exception

2) Thus PhaseInterceptorChain does NOT see that an exception occurred
during the invocation

3) Thus the "Out Interceptors" are not replaced by the "Out Fault
Interceptors" and these "Out Interceptors" are called on
#handleMessage() with the outMessage (ie the response created by the
ExceptionMapper) instead of being called on #handleFaultMessage() with
the inMessage when information like the FaultMode is still holded by
the inMessage

4) Interceptors like the ResponseTimeMessageOutInterceptor who rely on
the faultMode attribute located on the Message that is being passed to
handleMessage/handleFault are lost, they don't find the information
they look for

Questions :
* Wouldn't it make sense to call the "Out Fault Interceptors" if a
JAX-RS exception is mapped to a custom response ?
* which message should be given to the handleFaultMessage() ? The
inMessage that caused the exception and that holds the exception as an
attribute (it would be consistent with JAX-WS) or the outMessage as
currently done ?

CLIENT SIDE JAXRS EXCEPTION HANDLING
=============================================

ClientProxyImpl handles exceptions after calling the interceptors
when, with JAX-WS, exception handling (CheckFaultInterceptor) is
performed in the POST_PROTOCOL phase.

Due to this, the "In Interceptors Chain" is called instead of the "In
Fault Interceptors Chain" and interceptors like
ResponseTimeMessageInInterceptor don't see the Response as an
exception.

Question :
Can we imagine to refactor jaxrs client side exception handling as a
post protocol interceptor ?

I hope this email was not too long ; it took me few hours to check all
these use cases and figure out how it worked :-)

Cyrille
--
Cyrille Le Clerc
cleclerc@...

Re: DOSGi deploy failing on Hudson

2009-12-18T07:00:36Z

Ok - I'll take a look.
I can't just change it to 1.0.0-SNAPSHOT because these classes are
defined by the OSGi Alliance and their version is actually 1.0.0. But
maybe we can avoid building this module separately, this module is
only an internal artefact for DOSGi...

Cheers,

David

2009/12/18 Daniel Kulp <dkulp@...>:

>
>
> The problem is due to:
> parent/pom.xml:
> <remote.service.admin.interfaces.version>1.0.0</remote.service.admin.interfaces.version>
>
>
> Thus, the build of
> dsw/cxf-osgi-remote-service-admin-interfaces/pom.xml
>
> is considered a release and is trying to deploy as a release. That version
> number needs to change to a SNAPSHOT.
>
> Dan
>
>
> On Fri December 18 2009 4:35:36 am davidb@... wrote:
>> Hi all,
>>
>> The DOSGi deploy build on Hudson is failing with the following:
>>
>> [INFO] Error deploying artifact: Authorization failed: Access denied
>> to:
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apac
>> he/cxf/dosgi/cxf-dosgi-remote-service-admin-interfaces/1.0.0/cxf-dosgi-remo
>> te-service-admin-interfaces-1.0.0.jar
>>
>> See [1]. Anyone an idea what might be causing this or how to resolve it?
>>
>> Thanks!
>>
>> David
>>
>> [1]
>> http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi-deploy/81/org
>> .apache.cxf.dosgi$cxf-dosgi-remote-service-admin-interfaces/console
>>
>
> --
> Daniel Kulp
> dkulp@...
> http://www.dankulp.com/blog
>

Re: DOSGi deploy failing on Hudson

2009-12-18T04:49:40Z

The problem is due to:
parent/pom.xml:
<remote.service.admin.interfaces.version>1.0.0</remote.service.admin.interfaces.version>

Thus, the build of
dsw/cxf-osgi-remote-service-admin-interfaces/pom.xml

is considered a release and is trying to deploy as a release. That version
number needs to change to a SNAPSHOT.

Dan

On Fri December 18 2009 4:35:36 am davidb@... wrote:

> Hi all,
>
> The DOSGi deploy build on Hudson is failing with the following:
>
> [INFO] Error deploying artifact: Authorization failed: Access denied
> to:
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apac
> he/cxf/dosgi/cxf-dosgi-remote-service-admin-interfaces/1.0.0/cxf-dosgi-remo
> te-service-admin-interfaces-1.0.0.jar
>
> See [1]. Anyone an idea what might be causing this or how to resolve it?
>
> Thanks!
>
> David
>
> [1]
> http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi-deploy/81/org
> .apache.cxf.dosgi$cxf-dosgi-remote-service-admin-interfaces/console
>

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

Re: svn commit: r892222 - in /cxf/dosgi/trunk/dsw/cxf-dsw/src: main/java/org/apache/cxf/dosgi/dsw/handlers/ test/java/org/apache/cxf/dosgi/dsw/handlers/

2009-12-18T04:03:17Z

Hi David

>> The endpoint.uri is a new property that's introduced in the OSGi Remote
>> Service Admin spec. This is now the standard way to configure the endpoint
>> URI. The old properties are still supported for backward compatibility.
>
> This endpoint.uri property will work JAXRS services as well ?
>
> If we let users have the same OSGI service exposed as SOAP and RESTful
> services, how will it work with this property being used ? Perhaps in this
> latter case org.apache.cxf.ws.address and org.apache.cxf.rs.address
>
> thanks, Sergey

The we haven't refactored the JAX-RS handlers yet, see:
http://old.nabble.com/Re%3A-Migrating-CXF-DOSGi-to-be-complaint-with-the-new-OSGi-Remote--Service-Admin-spec-p26826519.html

But when we get to JAX-RS, it should also support the endpoint.uri property.
If you have a single service that you want to expose through both
using SOAP and REST we could make that possible by letting the user
set org.apache.cxf.rs.address and org.apache.cxf.ws.address, since
there's no overlap with these properties. Would that work for you?

> S.B : yes, it would, I think we're in agreement :-)

cheers, Sergey

Cheers,

David

Re: svn commit: r892222 - in /cxf/dosgi/trunk/dsw/cxf-dsw/src: main/java/org/apache/cxf/dosgi/dsw/handlers/ test/java/org/apache/cxf/dosgi/dsw/handlers/

2009-12-18T03:49:44Z

Hi Sergey,

2009/12/18 Sergey Beryozkin <sberyozk@...>:

> Hi David
>
>> Author: davidb
>> Date: Fri Dec 18 11:16:42 2009
>> New Revision: 892222
>>
>> URL: http://svn.apache.org/viewvc?rev=892222&view=rev
>> Log:
>> Added support for old way of configuring endpoint location back in. The
>> following properties on the exposed services are now equivalents and can be
>> set to a value such as http://localhost:9876/myService
>> endpoint.uri
>> org.apache.cxf.ws.address
>> osgi.remote.configuration.pojo.address
>> The endpoint.uri is a new property that's introduced in the OSGi Remote
>> Service Admin spec. This is now the standard way to configure the endpoint
>> URI. The old properties are still supported for backward compatibility.
>
> This endpoint.uri property will work JAXRS services as well ?
>
> If we let users have the same OSGI service exposed as SOAP and RESTful
> services, how will it work with this property being used ? Perhaps in this
> latter case org.apache.cxf.ws.address and org.apache.cxf.rs.address
>
> thanks, Sergey

Re: svn commit: r892222 - in /cxf/dosgi/trunk/dsw/cxf-dsw/src: main/java/org/apache/cxf/dosgi/dsw/handlers/ test/java/org/apache/cxf/dosgi/dsw/handlers/

2009-12-18T03:26:21Z

Hi David

> Author: davidb
> Date: Fri Dec 18 11:16:42 2009
> New Revision: 892222
>
> URL: http://svn.apache.org/viewvc?rev=892222&view=rev
> Log:
> Added support for old way of configuring endpoint location back in. The following properties on the exposed services are now
> equivalents and can be set to a value such as http://localhost:9876/myService
> endpoint.uri
> org.apache.cxf.ws.address
> osgi.remote.configuration.pojo.address
> The endpoint.uri is a new property that's introduced in the OSGi Remote Service Admin spec. This is now the standard way to
> configure the endpoint URI. The old properties are still supported for backward compatibility.

This endpoint.uri property will work JAXRS services as well ?

If we let users have the same OSGI service exposed as SOAP and RESTful services, how will it work with this property being used ?
Perhaps in this latter case org.apache.cxf.ws.address and org.apache.cxf.rs.address

thanks, Sergey

Re: DOSGi deploy failing on Hudson

2009-12-18T02:04:11Z

Hmmm ... smells like a Nexus issue.

If I follow that link, I'm redirected to:

https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/cxf/dosgi/cxf-dosgi-remote-service-admin-interfaces/1.0.0/cxf-dosgi-remote-service-admin-interfaces-1.0.0.jar

with the message:
Item not found on path
"/org/apache/cxf/dosgi/cxf-dosgi-remote-service-admin-interfaces/1.0.0/cxf-dosgi-remote-service-admin-interfaces-1.0.0.jar"
in repository "orgapachecxf-001"!This looks a reference to a temporary
staging area created by Nexus, for use for example while a release vote is
in motion (so for the recent dOSGi 1.1 release that I cut, the staging area
was assigned orgapachecxf-021).

Normally when the vote is declared, the staging area would be closed as the
artifacts are promoted. I'd expect the backing storage is discarded by
Nexus.

I don't know why its pointing back to the first CXF staging area ever
created in this case (i.e. the "-001" suffix) but that would have long since
ceased to exist.

Maybe report the issue to the infrastructure folks, or whomever has admin
access to Nexus.

Cheers,
Eoghan

2009/12/18 <davidb@...>

> Hi all,
>
> The DOSGi deploy build on Hudson is failing with the following:
>
> [INFO] Error deploying artifact: Authorization failed: Access denied
> to:
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/cxf/dosgi/cxf-dosgi-remote-service-admin-interfaces/1.0.0/cxf-dosgi-remote-service-admin-interfaces-1.0.0.jar
>
> See [1]. Anyone an idea what might be causing this or how to resolve it?
>
> Thanks!
>
> David
>
> [1]
> http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi-deploy/81/org.apache.cxf.dosgi$cxf-dosgi-remote-service-admin-interfaces/console
>

DOSGi deploy failing on Hudson

2009-12-18T01:35:36Z

Hi all,

The DOSGi deploy build on Hudson is failing with the following:

[INFO] Error deploying artifact: Authorization failed: Access denied
to: https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/cxf/dosgi/cxf-dosgi-remote-service-admin-interfaces/1.0.0/cxf-dosgi-remote-service-admin-interfaces-1.0.0.jar

See [1]. Anyone an idea what might be causing this or how to resolve it?

Thanks!

David

[1] http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi-deploy/81/org.apache.cxf.dosgi$cxf-dosgi-remote-service-admin-interfaces/console

Spring 3 results...

2009-12-17T17:50:05Z

We're down to two test failures when using Spring 3. Both of the
JAXRSSpringSecurity tests are failing. Not sure yet. The version of spring
security we are picking up may have an issue. Not really sure.

Anyway, things are looking pretty good with Spring3 now. :-)

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

Re: Spring 3 and JMS......

2009-12-17T17:15:14Z

OK. Figured it out. With Spring 2.x, the DefaultMessageListenerContainer
that we create seems to be automatically started. We don't ever call start
on it. With Spring 3, we need to call start(). If I add that call after
the initialize, all the JMS tests pass.

Dan

On Thu December 17 2009 5:17:52 pm Daniel Kulp wrote:

> I added a profile to the build to build/run with the recently released
> Spring 3. I have it completely building now (although a bunch of
> warnings as Spring deprecated a bunch of stuff that we need to call for
> Spring 2.5), however, the JMS tests are hanging.
>
> I would really appreciate it if someone could help look at it. Just run
>
> mvn -Pspring3
>
> and it hangs in the JMSDestinationTest. It may just be a timeout or
> something needing adjusting or similar. Don't really know yet.
>
> You can also run it in eclipse and see. A call like:
>
> mvn -Psetup.eclipse,spring3
> would setup the eclipse workspace with the spring3 jars. I can duplicate
> the hang there as well.
>

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

Spring 3 and JMS......

2009-12-17T14:17:52Z

I added a profile to the build to build/run with the recently released Spring
3. I have it completely building now (although a bunch of warnings as
Spring deprecated a bunch of stuff that we need to call for Spring 2.5),
however, the JMS tests are hanging.

I would really appreciate it if someone could help look at it. Just run

mvn -Pspring3

and it hangs in the JMSDestinationTest. It may just be a timeout or
something needing adjusting or similar. Don't really know yet.

You can also run it in eclipse and see. A call like:

mvn -Psetup.eclipse,spring3
would setup the eclipse workspace with the spring3 jars. I can duplicate the
hang there as well.

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

Distributed OSGi JIRA

2009-12-17T07:31:49Z

I just wanted to let everyone know that we've setup a separate JIRA for the
Distributed OSGi project:

https://issues.apache.org/jira/browse/DOSGI

Which should allow the project to have more control of their issues and
components and versions and such.

I've moved all the DOSGI related issues out of CXF into the new project.
This obviously changes the issue ID numbers and such, but there were only 20
or so of them so not a huge deal at this point. Better now than when we have
several hundred. :-)

Anyway, please log any DOSGi related issues there.

Enjoy!

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

Re: Should DOSGi have it's own JIRA?

2009-12-17T07:25:42Z

2009/12/17 Daniel Kulp <dkulp@...>:
> I've set it up:
> https://issues.apache.org/jira/browse/DOSGI

Nice!

> On a related note, should we have a separate DOSGi space on the wiki as well
> like we do for the docs? It could then have it's own navigation bar,
> etc....
>
> The top level page at cxf.apache.org would point dosgi project to a subdir
> like
> http://cxf.apache.org/dosgi
>
> or similar. Thoughts?
>
> Dan

Personally I think that the DOSGi wiki within the CXF wiki as it is
now is perfectly fine. It's a CXF subproject after all. Having the
strong relation between the projects visible in the Wiki is a good
thing IMHO.

David

Re: Should DOSGi have it's own JIRA?

2009-12-17T07:05:17Z

On Thu December 17 2009 5:33:39 am davidb@... wrote:
> Yeah - I think its a good idea to put CXF DOSGi as a separate project in
> JIRA.

I've set it up:
https://issues.apache.org/jira/browse/DOSGI

On a related note, should we have a separate DOSGi space on the wiki as well
like we do for the docs? It could then have it's own navigation bar,
etc....

The top level page at cxf.apache.org would point dosgi project to a subdir
like
http://cxf.apache.org/dosgi

or similar. Thoughts?

Dan

>
> Thanks,
>
> David
>
> 2009/12/17 Daniel Kulp <dkulp@...>:
> > Is there any objections to moving the DOSGI stuff out to it's own JIRA?
> > If not, I'll do so on Friday. Speak now... :-)
> >
> > Dan
> >
> > On Mon December 14 2009 2:39:17 pm Daniel Kulp wrote:
> >> Quick question:
> >>
> >> What are peoples thoughts about pulling the DOSGi stuff from the "CXF"
> >> JIRA into a separate CXFDOSGI (or just DOSGI) JIRA in the "Category:
> >> CXF" section at:
> >> https://issues.apache.org/jira/secure/BrowseProjects.jspa
> >>
> >> There are pluses and minuses:
> >> DOSGi has it's own release schedule, own version numbers,etc.... Thus,
> >> having it's own project in JIRA allows it to track those things
> >> properly without it affecting the main CXF project.
> >>
> >> Also, DOSGi has it's own components such as its own build system, local
> >> vs remote discovery, etc... Having it's own JIRA project would allow
> >> defining nice components for it's own uses.
> >>
> >> On the minus side, it does kind of lower the visibility of the DOSGi
> >> issues in the CXF JIRA since they wouldn't be there.
> >>
> >>
> >> One COULD argue that JAX-RS could also be pulled out. However, the
> >> JAX-RS stuff is currently part of the main build and released as part of
> >> the full CXF stuff. Thus, keeping it in is less of an issue. If we
> >> eventually split the builds into a "core", "webservices", "rest", etc...
> >> then it may make sense to do so at that time.
> >>
> >> Thoughts?
> >
> > --
> > Daniel Kulp
> > dkulp@...
> > http://www.dankulp.com/blog
>

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

Re: Migrating CXF-DOSGi to be complaint with the new OSGi Remote Service Admin spec

2009-12-17T03:15:06Z

Marc has submitted the first patch to bug 2427.
I'll be applying the patch shortly.

As this is work in progress, here's a summary of a few things that
aren't finished yet:
Remote Service Admin & Topology Manager (former DSW):
************************************************************
- Support of the HTTP service is not working at the moment as the
complete configuration type handler is deactivated
- Only the Pojo configuration type handler is supported at the moment
the others will follow soon
- The service decorator is disabled at the moment
- Configuration of the Remote Service Admin and the Topology Manager
via the Configuration Admin is not possible
- Most of the test cases from the former DSW are deactivated as they
need to be adapted to the Remote Service Admin and the Topology
Manager

General:
************************************************************
- Local Discovery is missing
- The Systests are deactivated as they are not yet adapted to the new
implementation

Marc and I will be working on resolving these issues.

Best regards,

David

2009/12/4 David Bosschaert <david.bosschaert@...>:

> Hi all,
>
> As you've seen, the CXF-DOSGi 1.1 release is out [1]. Thanks Eoghan!
> 1.1 is compliant with the current OSGi 4.2 Remote Services spec [2].
>
> In the mean time, in the OSGi Alliance an additional 'Distributed
> OSGi' specification is nearing completion: Remote Service Admin [3].
> This spec defines a number of APIs used internally in Distributed OSGi
> implementations. The APIs define the interaction between the
> Distribution Provider, Discovery System and a component called the
> Topology Manager. The benefit of implementing this standard is that
> you can mix & match components from various implementations together.
> For instance if someone provided a compliant Discovery implementation
> based on UDDI, you could just replace the ZooKeeper-based one in CXF
> with that UDDI one. It would just be a matter of replacing the
> bundles.
>
> CXF-DOSGi is the Reference Implementation of chapter 13, and will also
> be the reference implementation of chapter 122.
>
> Marc Schaaf has been working on refactoring the CXF-DOSGi
> implementation to also be compliant with Remote Service Admin while
> maintaining backward compatibility. Marc and I are planning to
> contribute this work to CXF-DOSGi trunk over the coming weeks.
>
> This might destabilize http://svn.apache.org/repos/asf/cxf/dosgi/trunk
> for a little while, which is one of the reasons why we waited until
> after the 1.1 release.
>
> Hope everyone is ok with this.
>
> Best regards,
>
> David
>
> [1] http://cxf.apache.org/dosgi-releases.html
> [2] Chapter 13 in the 4.2 Compendium http://www.osgi.org/Download/Release4V42
> [3] Chapter 122 in
> http://www.osgi.org/download/osgi-4.2-enterprise-early-draft4.pdf
>

Re: Should DOSGi have it's own JIRA?

2009-12-17T02:33:39Z

Yeah - I think its a good idea to put CXF DOSGi as a separate project in JIRA.

Thanks,

David

2009/12/17 Daniel Kulp <dkulp@...>:

>
> Is there any objections to moving the DOSGI stuff out to it's own JIRA? If
> not, I'll do so on Friday. Speak now... :-)
>
> Dan
>
>
> On Mon December 14 2009 2:39:17 pm Daniel Kulp wrote:
>> Quick question:
>>
>> What are peoples thoughts about pulling the DOSGi stuff from the "CXF" JIRA
>> into a separate CXFDOSGI (or just DOSGI) JIRA in the "Category: CXF"
>> section at:
>> https://issues.apache.org/jira/secure/BrowseProjects.jspa
>>
>> There are pluses and minuses:
>> DOSGi has it's own release schedule, own version numbers,etc.... Thus,
>> having it's own project in JIRA allows it to track those things properly
>> without it affecting the main CXF project.
>>
>> Also, DOSGi has it's own components such as its own build system, local vs
>> remote discovery, etc... Having it's own JIRA project would allow
>> defining nice components for it's own uses.
>>
>> On the minus side, it does kind of lower the visibility of the DOSGi issues
>> in the CXF JIRA since they wouldn't be there.
>>
>>
>> One COULD argue that JAX-RS could also be pulled out. However, the JAX-RS
>> stuff is currently part of the main build and released as part of the full
>> CXF stuff. Thus, keeping it in is less of an issue. If we eventually
>> split the builds into a "core", "webservices", "rest", etc... then it may
>> make sense to do so at that time.
>>
>> Thoughts?
>>
>
> --
> Daniel Kulp
> dkulp@...
> http://www.dankulp.com/blog
>

Re: Should DOSGi have it's own JIRA?

2009-12-16T18:58:06Z

Is there any objections to moving the DOSGI stuff out to it's own JIRA? If
not, I'll do so on Friday. Speak now... :-)

Dan

On Mon December 14 2009 2:39:17 pm Daniel Kulp wrote:

> Quick question:
>
> What are peoples thoughts about pulling the DOSGi stuff from the "CXF" JIRA
> into a separate CXFDOSGI (or just DOSGI) JIRA in the "Category: CXF"
> section at:
> https://issues.apache.org/jira/secure/BrowseProjects.jspa
>
> There are pluses and minuses:
> DOSGi has it's own release schedule, own version numbers,etc.... Thus,
> having it's own project in JIRA allows it to track those things properly
> without it affecting the main CXF project.
>
> Also, DOSGi has it's own components such as its own build system, local vs
> remote discovery, etc... Having it's own JIRA project would allow
> defining nice components for it's own uses.
>
> On the minus side, it does kind of lower the visibility of the DOSGi issues
> in the CXF JIRA since they wouldn't be there.
>
>
> One COULD argue that JAX-RS could also be pulled out. However, the JAX-RS
> stuff is currently part of the main build and released as part of the full
> CXF stuff. Thus, keeping it in is less of an issue. If we eventually
> split the builds into a "core", "webservices", "rest", etc... then it may
> make sense to do so at that time.
>
> Thoughts?
>

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

Re: svn commit: r890756 - /cxf/trunk/rt/frontend/simple/src/test/java/org/apache/cxf/service/factory/ServerFactoryTest.java

2009-12-15T04:02:38Z

Thanks for taking care of this. Sorry about that.

For some reason, my eclipse workspace isn't flagging these like it's supposed
to unless I completely clean the project and rebuild. Not sure what's going
on with it. May need to rebuild my eclipse workspace. :-(

Dan

On Tue December 15 2009 6:11:37 am bharath@... wrote:

> Author: bharath
> Date: Tue Dec 15 11:11:37 2009
> New Revision: 890756
>
> URL: http://svn.apache.org/viewvc?rev=890756&view=rev
> Log:
> Fixed a checkstyle error due to unused import.
>
> Modified:
>
> cxf/trunk/rt/frontend/simple/src/test/java/org/apache/cxf/service/factory/
> ServerFactoryTest.java
>
> Modified:
> cxf/trunk/rt/frontend/simple/src/test/java/org/apache/cxf/service/factory/
> ServerFactoryTest.java URL:
> http://svn.apache.org/viewvc/cxf/trunk/rt/frontend/simple/src/test/java/or
> g/apache/cxf/service/factory/ServerFactoryTest.java?rev=890756&r1=890755&r2
> =890756&view=diff
> ==========================================================================
> ==== ---
> cxf/trunk/rt/frontend/simple/src/test/java/org/apache/cxf/service/factory/
> ServerFactoryTest.java (original) +++
> cxf/trunk/rt/frontend/simple/src/test/java/org/apache/cxf/service/factory/
> ServerFactoryTest.java Tue Dec 15 11:11:37 2009 @@ -27,7 +27,6 @@
> import org.apache.cxf.endpoint.Server;
> import org.apache.cxf.endpoint.ServerImpl;
> import org.apache.cxf.frontend.ServerFactoryBean;
> -import org.apache.cxf.helpers.XMLUtils;
> import org.apache.cxf.jaxb.JAXBDataBinding;
> import org.apache.cxf.message.Message;
> import org.apache.cxf.service.model.EndpointInfo;
>

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

RE: Should DOSGi have it's own JIRA?

2009-12-14T13:35:16Z

Hi,

Possibly yes for DOSGI, DOSGI RI project is a higher-level project given
that it incorporates CXF, and there is a link to the Distributed OSGi
project from the main CXF page so moving the issues part into a separate
JIRA should not affect the visibility of the project, as far as users
checking the CXF is concerned... David and Eoghan and others may have a
different opinion.

However, I'm much more pessimistic about moving the JAXRS component into
a separate subproject for a number of reasons.

It is really another frontend, like Cobra and JAXWS. It is on the same
level as those frontends are. It is kind of contributing to CXF being
seen as a more complete framework capable of hosting different types of
services thus moving it away would start contributing to a more
'fragmented' view of what CXF is.
Another reason is that often enough CXF JAXRS fixes 'span' multiple
components in one go, say HTTP transport and common and the JAXRS
frontend itself. So it make it more difficult to push such fixes into
CXF JAXRS snapshots.

This is what I think at the moment.
Thanks, Sergey

-----Original Message-----
From: Daniel Kulp [mailto:dkulp@...]
Sent: 14 December 2009 19:39
To: dev@...
Subject: Should DOSGi have it's own JIRA?

Quick question:

What are peoples thoughts about pulling the DOSGi stuff from the "CXF"
JIRA
into a separate CXFDOSGI (or just DOSGI) JIRA in the "Category: CXF"
section
at:
https://issues.apache.org/jira/secure/BrowseProjects.jspa

There are pluses and minuses:
DOSGi has it's own release schedule, own version numbers,etc.... Thus,
having
it's own project in JIRA allows it to track those things properly
without it
affecting the main CXF project.

Also, DOSGi has it's own components such as its own build system, local
vs
remote discovery, etc... Having it's own JIRA project would allow
defining
nice components for it's own uses.

On the minus side, it does kind of lower the visibility of the DOSGi
issues in
the CXF JIRA since they wouldn't be there.

One COULD argue that JAX-RS could also be pulled out. However, the
JAX-RS
stuff is currently part of the main build and released as part of the
full CXF
stuff. Thus, keeping it in is less of an issue. If we eventually split
the
builds into a "core", "webservices", "rest", etc... then it may make
sense to
do so at that time.

Thoughts?

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

Should DOSGi have it's own JIRA?

2009-12-14T11:39:17Z

Quick question:

What are peoples thoughts about pulling the DOSGi stuff from the "CXF" JIRA
into a separate CXFDOSGI (or just DOSGI) JIRA in the "Category: CXF" section
at:
https://issues.apache.org/jira/secure/BrowseProjects.jspa

There are pluses and minuses:
DOSGi has it's own release schedule, own version numbers,etc.... Thus, having
it's own project in JIRA allows it to track those things properly without it
affecting the main CXF project.

Also, DOSGi has it's own components such as its own build system, local vs
remote discovery, etc... Having it's own JIRA project would allow defining
nice components for it's own uses.

On the minus side, it does kind of lower the visibility of the DOSGi issues in
the CXF JIRA since they wouldn't be there.

One COULD argue that JAX-RS could also be pulled out. However, the JAX-RS
stuff is currently part of the main build and released as part of the full CXF
stuff. Thus, keeping it in is less of an issue. If we eventually split the
builds into a "core", "webservices", "rest", etc... then it may make sense to
do so at that time.

Thoughts?

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

Re: Issues in generated Java code using apache CXF

2009-12-11T13:56:09Z

Couple of notes:

1) The stack trace line: com.sun.xml.internal.ws.model....
shows you aren't using CXF at all. You are using the JAX-WS RI built into
java6.

2) "IllegalAnnotationExceptions java.lang.StackTraceElement does not have a
no-arg default constructor"

This usually means someplace a bean is holding onto an Exception or similar
that isn't marked transient.

Dan

On Thu December 10 2009 5:04:14 pm rakeshrai wrote:

> I was trying to find out how to fix this issue which is caused after the
> generated Apache CXF code. This never happened in Axis generated Java code.
>
> Its complaining about some annotation which I don’t understand how to fix
> the same.
>
>
> In LnItm.java, I see the variables defined as shown below.
> protected int dropShipInd;
> @XmlElementRef(name = "lOA", namespace =
> "http://ws.taxwareenterprise.com", type = JAXBElement.class)
>
> Its hard to find out what exactly needs to be done to fix the error as
> shown below.
>
> Caused by: java.security.PrivilegedActionException:
> com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 6 counts
> of IllegalAnnotationExceptions java.lang.StackTraceElement does not have a
> no-arg default constructor.
> this problem is related to the following location:
> at java.lang.StackTraceElement
> at public java.lang.StackTraceElement[]
> java.lang.Throwable.getStackTrace()
> at java.lang.Throwable
> at public java.lang.Throwable java.rmi.RemoteException.detail
> at java.rmi.RemoteException
> at org.apache.axis.AxisFault
> at com.taxwareenterprise.ws.TweFault
>
> There's no ObjectFactory with an @XmlElementDecl for the element
> {http://ws.taxwareenterprise.com}lOA.
> this problem is related to the following location:
> at protected javax.xml.bind.JAXBElement
> com.taxwareenterprise.ws.cxf.LnItm.loa
> at com.taxwareenterprise.ws.cxf.LnItm
> at com.taxwareenterprise.ws.cxf.ForcLnItm
> at protected java.util.List
> com.taxwareenterprise.ws.cxf.ForcLnItms.forcLnItm
> at com.taxwareenterprise.ws.cxf.ForcLnItms
> at protected com.taxwareenterprise.ws.cxf.ForcLnItms
> com.taxwareenterprise.ws.cxf.ForcDoc.forcLnItms
> at com.taxwareenterprise.ws.cxf.ForcDoc
> at protected com.taxwareenterprise.ws.cxf.ForcDoc
> com.taxwareenterprise.ws.cxf.ForceCalculationRequest.forcDoc
> at com.taxwareenterprise.ws.cxf.ForceCalculationRequest
>
>
> at
> com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException$Builder.ch
> eck(IllegalAnnotationsException.java:66) at
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBCon
> textImpl.java:422) at
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl
> .java:270) at
> com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.ja
> va:103) at
> com.sun.xml.internal.bind.api.JAXBRIContext.newInstance(JAXBRIContext.java:
> 89) at
> com.sun.xml.internal.ws.model.AbstractSEIModelImpl$1.run(AbstractSEIModelIm
> pl.java:126) at
> com.sun.xml.internal.ws.model.AbstractSEIModelImpl$1.run(AbstractSEIModelIm
> pl.java:124) ... 11 more
>

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

Re: Proposal : HTTP view for managed endpoints

2009-12-11T09:32:25Z

Dear all,

It's a very appealing feature, I would like to have it not only as
html but also as rss and in a shell client scripts friendly format.

Here are my humble insights about web services monitoring and management :

* Exposing management and monitoring features on web pages can be a
security breach (try to Google the management URI of your favorite
open source Java EE server, it's frightening :-) ).

* Nobody is perfect, I may expose a bunch of management jsp pages but
I protect them Spring Security URI based authentication and
authorization.

* Monitoring counters are often difficult to render on a simple web
page because they most of the time are trends-up measures (1) and
rendering them requires correlation to create "Per Minute" indicators
(invocations per minute, etc).

* Web based monitoring would a nice and appealing feature but I feel
most production scenarios will prefer JMX oriented monitoring tools
for security, graphing and recording. I am personally very happy with
the Hyperic HQ Open Source edition to monitor CXF and JBoss Jopr (also
Open Source) seems to be as efficient.

* a REST based API would even be more powerful than raw html ! It
would be great for non JMX enabled monitoring tools (Nagios, etc) to
have shell script friendly format (). We would expose basic html for
web browsers, RSS for widgets and dashboards, raw text for non JMX
enabled monitoring tools (Nagios, etc).

* Such a web based monitoring solution could be very generic and not
only apply to CXF metrics ; the forthcoming Spring 3 @ManagedMetric
annotation could help.

* For security reasons, I would feel more comfortable with a dedicated
base URI to ease URL based protection (with Spring Security, web.xml,
etc). Using the @RolesAllowed standard annotation would be key to ease
method level authorization.

* By the way, would it make sense to look at the @RolesAllowed
standard annotation to protect the existing web services list (ie call
to "/services/") ?

I hope I was not too long :-)

Cyrille
--
Cyrille Le Clerc
cleclerc@...

(1) Hyperic HQ doc : "trendsup: Values will always increase. Because
of that, the rate of change becomes more important, so HQ
automatically creates a secondary metric: a per-minute rate
measurement...". See
http://support.hyperic.com/display/DOC/Metric+Parameters

On Fri, Dec 11, 2009 at 2:33 PM, Sergey Beryozkin <sberyozk@...> wrote:

>
> Hi
>
> Now that both JAXWS and JAXRS operations can be monitored over JMX (hope Cyrille will confirm it later on), I reckon it would be cool to let users issue _manage queries against individual endpoints and get an HTML view, rather than having to launch a JConsole, ex :
>
> GET http://myjaxwsservice?_manage
> GET http://myjaxrsservice?_manage
>
> A custom QueryHandler implementation, registered as part of the management feature, will convert the information from the JMX mbeans into an HTML page. For a start, it can just do some plain HTML in code. At the next stage, we can think about produceing nicer pages and adding some polling JavaScript code, etc.
>
> Any comments ? I think it would be a very nice feature which would make the CXF management feature very visible to users. If someone could take upon this task then it would be appreciated a lot. Perhaps I might also look into it later on.
>
> cheers, Sergey
>

Proposal : HTTP view for managed endpoints

2009-12-11T05:33:39Z

Hi

Now that both JAXWS and JAXRS operations can be monitored over JMX (hope Cyrille will confirm it later on), I reckon it would be cool to let users issue _manage queries against individual endpoints and get an HTML view, rather than having to launch a JConsole, ex :

GET http://myjaxwsservice?_manage
GET http://myjaxrsservice?_manage

A custom QueryHandler implementation, registered as part of the management feature, will convert the information from the JMX mbeans into an HTML page. For a start, it can just do some plain HTML in code. At the next stage, we can think about produceing nicer pages and adding some polling JavaScript code, etc.

Any comments ? I think it would be a very nice feature which would make the CXF management feature very visible to users. If someone could take upon this task then it would be appreciated a lot. Perhaps I might also look into it later on.

cheers, Sergey

Issues in generated Java code using apache CXF

2009-12-10T14:04:13Z

I was trying to find out how to fix this issue which is caused after the generated Apache CXF code. This never happened in Axis generated Java code.

Its complaining about some annotation which I don’t understand how to fix the same.

In LnItm.java, I see the variables defined as shown below.
protected int dropShipInd;
@XmlElementRef(name = "lOA", namespace = "http://ws.taxwareenterprise.com", type = JAXBElement.class)

Its hard to find out what exactly needs to be done to fix the error as shown below.

Caused by: java.security.PrivilegedActionException: com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 6 counts of IllegalAnnotationExceptions java.lang.StackTraceElement does not have a no-arg default constructor.
this problem is related to the following location:
at java.lang.StackTraceElement
at public java.lang.StackTraceElement[] java.lang.Throwable.getStackTrace()
at java.lang.Throwable
at public java.lang.Throwable java.rmi.RemoteException.detail
at java.rmi.RemoteException
at org.apache.axis.AxisFault
at com.taxwareenterprise.ws.TweFault

There's no ObjectFactory with an @XmlElementDecl for the element {http://ws.taxwareenterprise.com}lOA.
this problem is related to the following location:
at protected javax.xml.bind.JAXBElement com.taxwareenterprise.ws.cxf.LnItm.loa
at com.taxwareenterprise.ws.cxf.LnItm
at com.taxwareenterprise.ws.cxf.ForcLnItm
at protected java.util.List com.taxwareenterprise.ws.cxf.ForcLnItms.forcLnItm
at com.taxwareenterprise.ws.cxf.ForcLnItms
at protected com.taxwareenterprise.ws.cxf.ForcLnItms com.taxwareenterprise.ws.cxf.ForcDoc.forcLnItms
at com.taxwareenterprise.ws.cxf.ForcDoc
at protected com.taxwareenterprise.ws.cxf.ForcDoc com.taxwareenterprise.ws.cxf.ForceCalculationRequest.forcDoc
at com.taxwareenterprise.ws.cxf.ForceCalculationRequest

at com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:66)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:422)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:270)
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:103)
at com.sun.xml.internal.bind.api.JAXBRIContext.newInstance(JAXBRIContext.java:89)
at com.sun.xml.internal.ws.model.AbstractSEIModelImpl$1.run(AbstractSEIModelImpl.java:126)
at com.sun.xml.internal.ws.model.AbstractSEIModelImpl$1.run(AbstractSEIModelImpl.java:124)
... 11 more

Re: Validation for incoming request, not for response

2009-12-09T08:10:09Z

On Wed December 9 2009 4:35:38 am Heemskerk, Marcel (M.) wrote:
> Hello,
>
> Is there a way to enable XSD validation for the incoming request, whilst
> not validating the outgoing response?

You can write an interceptor that lives early in the out chain that just
does:

message.put("schema-validation-enabled", Boolean.FALSE)
to turn it off on that chain.

You can TRY doing this in the WebServiceContext in your impl as well. I'm
not sure if the outgoing chain would pick it up. I think it would, but I'm
not 100% sure.

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

Validation for incoming request, not for response

2009-12-09T01:35:38Z

Hello,

Is there a way to enable XSD validation for the incoming request, whilst
not validating the outgoing response?

Thanks!

Marcel Heemskerk

Re: org.apache.cxf.systest.jaxrs.JAXRSLoggingAtomPushTest stack traces and stuff

2009-12-08T02:22:54Z

There were a couple of System.out.println() statements printing nice feeds :-), they've been removed now.
Note the AtomPushEngine might do System.err.println() occasionally, but I believe it is the only way AtomPushEngine can log itself,
at least at the moment. I'm not sure how feasible it is for it to avoid handling its own logging events...

Sergey

>
> The org.apache.cxf.systest.jaxrs.JAXRSLoggingAtomPushTest is spitting all
> kinds of stuff out to stdout/stderr. Can that be fixed?
>
>
> --
> Daniel Kulp
> dkulp@...
> http://www.dankulp.com/blog

Re: Status of Atom logging stuff....

2009-12-08T01:47:35Z

Hi

>
> Quick question about the Atom logging stuff...
>
> Is this intended for 2.2.6 or just for 2.3? Just wondering if I need to
> merge it back or not.

I was planning to backmerge the Andy's commits, just haven't had a chance yet. I'll unblock the relevant revisions if needed

cheers, Sergey
>
> Thanks!
>
> --
> Daniel Kulp
> dkulp@...
> http://www.dankulp.com/blog

Re: [RESULT] [VOTE] Cyrille Le Clerc for committer....

2009-12-07T15:48:58Z

Dear community,

It's a great honor for me to be welcomed in the Apache CXF community.
It's a great honor to contribute to a foundation that changed the face of
Open Source and I am specially touched to join a team that provides one of
the most widely used web services technologies.

I will do my best to deserve your confidence, I must admit that I am very
impressed :-) .

Cyrille.

On Mon, Dec 7, 2009 at 8:08 PM, Daniel Kulp <dkulp@...> wrote:

>
> With 13 +1 votes and no other votes, this vote passes.
>
> Welcome aboard Cyrille!
>
> Dan
>
>
> On Thu December 3 2009 10:48:29 am Daniel Kulp wrote:
> > Cyrille has submitted several patches to various management and logging
> > related things for CXF starting way back in February. I think he's up
> to
> > 7 or 8 submitted patches. He's also been hanging around the user list
> > for almost a year answering some questions. Thus, I think he's a bit
> > over due to become a committer.
> >
> > Here is my +1.
> >
> > Vote will be open for at least 72 hours.
> >
>
> --
> Daniel Kulp
> dkulp@...
> http://www.dankulp.com/blog
>