Re: A fault found while use CXF.

[Benson Margulies]

Apache mailing lists strip off attachments and pictures. Please create
problem reports without pictures.

On Fri, May 19, 2017 at 11:52 PM, Dennis Kieselhorst  wrote:
> Hi!
>
>> Just like the following pictures.
> There are no pictures attached. Please check the logs for error messages and 
> include the message in your posting.
>
> Cheers
> Dennis
>

Re: [ANNOUNCE] Introducing Microbule...

[Benson Margulies]

A small update with some irony here.

At the job I just finished today, we reached the conclusion that we
weren't getting much value out of Karaf and pax-web; no criticism
intended, we just don't dynamically provision, and we don't need any
HTTP except for CXF services. So, over the last few weeks, we
refactored the thing to use cxf-rt-transport-http-jetty in the Felix
container, with our own rather tiny class responsible for launching.
We lost a bit of flexibility in that we can't create an endpoint
'inside' of the namespace of another endpoint, but otherwise it works
just fine. The code that that I showed James is hardly changed at all.
The endpoint addresses now look like
"http://0.0.0.0:n/base/whatever; instead "/whatever".  Maybe some
day there will be an ultramicrobule that anticipates this mode of
operation.





On Mon, Nov 21, 2016 at 7:13 PM, James Carman
 wrote:
> Small update.  Microbule 0.1.0 release has been cut and will soon be
> available in Maven Central (awaiting sync from Nexus OSS).  Enjoy, folks!
>
> On Mon, Nov 21, 2016 at 1:03 PM James Carman 
> wrote:
>
>> We've been working on a Microservices framework called "Microbule" which
>> leverages CXF and Karaf (hence the cross-post):
>>
>> https://github.com/jwcarman/microbule
>>
>> The idea is to make writing Microservices easy and fun, by providing many
>> of the oft-requested features for you out-of-the-box (CORS, Caching, JSON
>> transformation, validation, etc.).  There's a README page that explains how
>> to install/run Microbule in Karaf and how to write your own services.  If
>> you're interested, take it for a spin and let us know what you think.
>>
>> Thanks,
>>
>> James
>>

Re: Coding style

[Benson Margulies]

The CXF rules do have a specific idea about order. It's in the rules,
you can read it.

Personally, FWLIW, I don't have a problem with 'extends Assert' for
tests that need a lot of different methods from Assert. It's not
ancient, ancient is 'extends TestCase'.


On Wed, Aug 10, 2016 at 7:40 AM, Colm O hEigeartaigh
 wrote:
> Checkstyle is integrated into the build process (e.g. mvn clean install),
> there is no need to call mvn checkstyle:check, which bypasses the
> CXF-specific checkstyle rules.
>
> Colm.
>
> On Wed, Aug 10, 2016 at 12:38 PM, Sergey Beryozkin 
> wrote:
>
>> Hi
>>
>> No, I'm not seeing these ones
>>
>> Sergey
>> On 10/08/16 11:53, Behrang Saeedzadeh wrote:
>>
>>> Hi,
>>>
>>> I just cloned CXF from Github (master branch, commit:
>>> 395acbd2f16b03314f34ee0b6a212b708b375873) and running mvn
>>> checkstyle:check
>>> inside $PROJECT_ROOT/rt/rs/security/jose-parent generates 5955 errors for
>>> me: http://imgur.com/9VSrQvL
>>>
>>> Do you guys also get the same errors? Some examples:
>>>
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[56]
>>> (sizes) LineLength: Line is longer than 80 characters (found 90).
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[58]
>>> (regexp) RegexpSingleline: Line has trailing spaces.
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[62]
>>> (regexp) RegexpSingleline: Line has trailing spaces.
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[66]
>>> (sizes) LineLength: Line is longer than 80 characters (found 83).
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[75,5]
>>> (design) DesignForExtension: Method 'isJwsRequired' is not designed for
>>> extension - needs to be abstract, final or empty.
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[75,5]
>>> (javadoc) JavadocMethod: Missing a Javadoc comment.
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[79,5]
>>> (design) DesignForExtension: Method 'setJwsRequired' is not designed for
>>> extension - needs to be abstract, final or empty.
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[79,5]
>>> (javadoc) JavadocMethod: Missing a Javadoc comment.
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[79,32]
>>> (misc) FinalParameters: Parameter jwsRequired should be final.
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[79,40]
>>> (coding) HiddenField: 'jwsRequired' hides a field.
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[83,5]
>>> (design) DesignForExtension: Method 'isJweRequired' is not designed for
>>> extension - needs to be abstract, final or empty.
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[83,5]
>>> (javadoc) JavadocMethod: Missing a Javadoc comment.
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[87,5]
>>> (design) DesignForExtension: Method 'setJweRequired' is not designed for
>>> extension - needs to be abstract, final or empty.
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[87,5]
>>> (javadoc) JavadocMethod: Missing a Javadoc comment.
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[87,32]
>>> (misc) FinalParameters: Parameter jweRequired should be final.
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[87,40]
>>> (coding) HiddenField: 'jweRequired' hides a field.
>>> [ERROR]
>>> src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtPro
>>> ducer.java:[90]
>>> (regexp) RegexpSingleline: Line has trailing spaces.
>>>
>>>
>>> @Sergey and @Christian: I can give it a go. It might be possible to
>>> refactor all tests using grep/awk/sed and friends.
>>>
>>> In the meantime, let me go and read some doco about contribution
>>> guidelines
>>> and the project structure. :)
>>>
>>> Best regards,
>>> Behrang Saeedzadeh
>>>
>>> On 10 August 2016 at 20:20, Christian Schneider 
>>> wrote:
>>>
>>> CXF Checkstyle seems to have a strange preference for import ordering. I
 am also often hit by this.
 I think this is defined in etc/eclipse/CXF.importorder.
 Not sure how to get eclipse to use it though.

 Christian


 On 10.08.2016 12:17, Sergey Beryozkin wrote:

 Hi
>
> Having static imports always has Checkstyle complaining for me.
> I'm fine with the new tests contributed which have the static imports
> that pass the command line builds :-).
> Refactoring the existing tests - are you 

Re: why should i use apache cxf over other webservice library

[Benson Margulies]

This question belongs on the user list, not the dev list.

Validation, CXF, OSGi, TCCL, once more

[Benson Margulies]

Working with Gunnar, I've finally gotten a complete picture of the
situation, and a somewhat general question has come up.

When pax-web calls CXF which in turn calls a JAX-RS resource class,
the TCCL is the CXF http transport bundle class loader. Is there some
reason not to set it to a class loader associated with the resource
class?

The trouble with HibernateValidation is this: way down in HV, there's
a call to ExpressionFactory.newInstance() from javax.el. That's an
old-fashioned SPI that does not have an overload that takes a
ClassLoader. So, even though HV has a class loader option in its
configuration meant to ensure the findability of resources, it does
not avail. (Unless HV set the TCCL, which its authors are not happy
about.) I'm working with them on an API that will allow the user of HV
to make their own ExpressionFactory with the TCCL set however they
like. However, it did occur to me that a different TCCL in CXF
invoking JAX-RS would have avoided all this.

Re: Validation, CXF, OSGi, TCCL, once more

[Benson Margulies]

Definitely the HTTP transport.

ResourceDelegatingBundleClassLoader{bundle=org.apache.cxf.cxf-rt-transports-http
[110],parent=BundleClassLoader{bundle=org.ops4j.pax.web.pax-web-jetty
[221],parent=null}}

Here's the whole backtrace.

"qtp1894429215-109@4540" prio=5 tid=0x6d nid=NA runnable
  java.lang.Thread.State: RUNNABLE
 at 
com.basistech.ws.common.api.options.OptionsValidator.validate(OptionsValidator.java:36)
 at 
com.basistech.ws.common.api.options.ProcessingOptions$Builder.setOptions(ProcessingOptions.java:124)
 at 
com.basistech.ws.frontend.service.AbstractRaasRsService.getProcessingOptions(AbstractRaasRsService.java:756)
 at 
com.basistech.ws.frontend.service.AbstractRaasRsService.processRequest(AbstractRaasRsService.java:582)
 at 
com.basistech.ws.frontend.service.AbstractRaasRsService.processHelper(AbstractRaasRsService.java:210)
 at 
com.basistech.ws.frontend.service.RaasRsEntityService.runEntityExtraction(RaasRsEntityService.java:108)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:497)
 at 
org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:180)
 at 
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
 at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:200)
 at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:99)
 at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
 at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96)
 at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
 - locked <0x254e> (a org.apache.cxf.phase.PhaseInterceptorChain)
 at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
 at 
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:251)
 at 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
 at 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
 at 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
 at 
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171)
 at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:293)
 at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:212)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
 at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:268)
 at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:808)
 at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
 at 
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
 at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
 at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
 at 
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:271)
 at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
 at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
 at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
 at 
org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80)
 at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
 at org.eclipse.jetty.server.Server.handle(Server.java:497)
 at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
 at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
 at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
 at java.lang.Thread.run(Thread.java:745)

On Mon, Dec 21, 2015 at 6:40 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> On Mon, Dec 21, 2015 at 3:54 PM, Daniel Kulp <dk...@apache.org> wrote:
>> Benson,
>>
>> Can you walk back through the stack a bit…  I BELIEVE that pax-web should be 
>> invoking one of our servlets which should then be

Re: Validation, CXF, OSGi, TCCL, once more

[Benson Margulies]

I single-stepped through the service creation, and I didn't spot any
capturing of a class loader by the bus initialization. I'm probably
being dense.

On Mon, Dec 21, 2015 at 6:47 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> Definitely the HTTP transport.
>
> ResourceDelegatingBundleClassLoader{bundle=org.apache.cxf.cxf-rt-transports-http
> [110],parent=BundleClassLoader{bundle=org.ops4j.pax.web.pax-web-jetty
> [221],parent=null}}
>
> Here's the whole backtrace.
>
> "qtp1894429215-109@4540" prio=5 tid=0x6d nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>  at 
> com.basistech.ws.common.api.options.OptionsValidator.validate(OptionsValidator.java:36)
>  at 
> com.basistech.ws.common.api.options.ProcessingOptions$Builder.setOptions(ProcessingOptions.java:124)
>  at 
> com.basistech.ws.frontend.service.AbstractRaasRsService.getProcessingOptions(AbstractRaasRsService.java:756)
>  at 
> com.basistech.ws.frontend.service.AbstractRaasRsService.processRequest(AbstractRaasRsService.java:582)
>  at 
> com.basistech.ws.frontend.service.AbstractRaasRsService.processHelper(AbstractRaasRsService.java:210)
>  at 
> com.basistech.ws.frontend.service.RaasRsEntityService.runEntityExtraction(RaasRsEntityService.java:108)
>  at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:497)
>  at 
> org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:180)
>  at 
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
>  at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:200)
>  at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:99)
>  at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
>  at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96)
>  at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>  - locked <0x254e> (a org.apache.cxf.phase.PhaseInterceptorChain)
>  at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>  at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:251)
>  at 
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
>  at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
>  at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
>  at 
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171)
>  at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:293)
>  at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:212)
>  at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>  at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:268)
>  at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:808)
>  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
>  at 
> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>  at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>  at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>  at 
> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:271)
>  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>  at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>  at 
> org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80)
>  at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>  at org.eclipse.jetty.server.Server.handle(Server.java:497)
>  at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>  at 
> org.eclipse.jett

Hibernate and OSGi

[Benson Margulies]

Could people who actually understand this stuff please chime in on
https://hibernate.atlassian.net/browse/HV-1039?

Re: Why the OSGi version policy I see?

[Benson Margulies]

One more ...

  <_failok>true

This seems dangerous to me. Don't we want to fix things if they are wrong?


On Tue, Dec 15, 2015 at 9:10 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> Another 'why' question.
>
> Why do we use
>
> <_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))
>
> as opposed, perhaps, to
>
>
>
> <_consumer-policy>$${range;[===,+)}
>
> or something like it? I don't, personally, even know what it means to
> put that third value into the policy, I thought that only two slots
> were defined.
>
> As a matter of pointless taste, I am not fond of
>
> ${cxf.bundle.activator}
>
> as opposed to just writing the instruction in the pom that wants it,
> but I'm not proposing to have an argument (or to change it).

Why the OSGi version policy I see?

[Benson Margulies]

Another 'why' question.

Why do we use

<_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))

as opposed, perhaps, to

   

<_consumer-policy>$${range;[===,+)}

or something like it? I don't, personally, even know what it means to
put that third value into the policy, I thought that only two slots
were defined.

As a matter of pointless taste, I am not fond of

${cxf.bundle.activator}

as opposed to just writing the instruction in the pom that wants it,
but I'm not proposing to have an argument (or to change it).

Why are we disabling 'uses' in our OSGI manifests?

[Benson Margulies]

Turning of uses would seem pretty dangerous. Howcome?

Re: Hibernate and OSGi

[Benson Margulies]

David, I'm not sure of your point here. We've been discussing issues
with the -CXF- OSGi support for bean validation in two JIRAs and a
number of email messages. Some people suggested engaging the Hibernate
community; I did, and sent an email with the coordinates. I don't see
why I would poke a generic osgi mailing list that I've never
participated in.


On Tue, Dec 15, 2015 at 6:26 PM, David Bosschaert
<david.bosscha...@gmail.com> wrote:
> Hi Benson,
>
> Did you post this to the right mailing list? Forwarding to osgi-dev...
>
> Cheers,
>
> David
>
> On 15 December 2015 at 16:20, Benson Margulies <bimargul...@gmail.com> wrote:
>> Could people who actually understand this stuff please chime in on
>> https://hibernate.atlassian.net/browse/HV-1039?

Re: Fixing up bean validation in OSGi

[Benson Margulies]

Or move them to Karaf, for that matter.


On Mon, Dec 14, 2015 at 3:25 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> I've had a PR outstanding at Bval for weeks, with no response to the
> email or JIRA. My patch might fix it's current behavior in OSGi for
> me, which is to call every bean valid. If any of you can wake the bval
> committers up from their, ahem, hibernating state, I would work
> further on it. I'm happy to set up dueling hibernate and bval features
> in CXF for 3.2.0.
>
>
> On Mon, Dec 14, 2015 at 1:38 PM, Christian Schneider
> <ch...@die-schneider.net> wrote:
>> +1 for making the bean-validation feature independent from hibernate. I
>> intended to do this for 3.2 anyway. I propose to just add the
>> javax.validation api bundle with dependency=true and remove the reference
>> to the bean-validation-core feature. Not sure if this is a good idea in
>> 3.1.x as it is slightly incompatible.
>>
>> I am -1 of adding a bval feature to CXF. Instead let us create the feature
>> either in karaf or directly provided by bval which I think would be the
>> best option. I offer my help in doing so.
>>
>> Christian
>>
>> 2015-12-14 13:37 GMT+01:00 Francesco Chicchiriccò <ilgro...@apache.org>:
>>
>>> On 14/12/2015 13:34, Romain Manni-Bucau wrote:
>>>
>>>> 2015-12-14 13:17 GMT+01:00 Francesco Chicchiriccò <ilgro...@apache.org>:
>>>>
>>>> On 14/12/2015 12:59, Romain Manni-Bucau wrote:
>>>>>
>>>>> 2015-12-14 12:45 GMT+01:00 Sergey Beryozkin <sberyoz...@gmail.com>:
>>>>>>
>>>>>> Hi Benson
>>>>>>
>>>>>>> On 11/12/15 16:19, Benson Margulies wrote:
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/CXF-6706
>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/CXF-6705
>>>>>>>>
>>>>>>>> The changes I've committed for CXF-6705 make it possible to use bean
>>>>>>>> validation, but ...
>>>>>>>>
>>>>>>>> 1: only with hibernate
>>>>>>>> 2: only with extra code to obtain the validation provider.
>>>>>>>>
>>>>>>>> This raises two questions.
>>>>>>>>
>>>>>>>> 1: should I restructure the features to split
>>>>>>>> 'cxf-bean-validation-hibernate' from 'cxf-bean-validation', leaving
>>>>>>>> room for bval?
>>>>>>>>
>>>>>>>> Please, I've heard Apache BVal is less complete, but I think we should
>>>>>>> keep the option open for users who would like to experiment with this
>>>>>>> Apache project
>>>>>>>
>>>>>>> Hi guys, happy to help fixing any gap there if you need. BVal passes
>>>>>> TCKs
>>>>>> so IMO it is a valid option.
>>>>>>
>>>>>> Hi Romain,
>>>>> AFAICT, current BVal release (2012!) passes the TCK for JSR-303 (e.g.
>>>>> Bean
>>>>> Validation 1.0), not JSR-349 (e.g. Bean Validation 1.1)
>>>>>
>>>>> http://bval.apache.org/downloads.html
>>>>>
>>>>> Am I wrong?
>>>>>
>>>>> Incidentally, this is the reason why we had to switch from BVal to
>>>>> Hibernate Validator in Syncope, a couple of major releases ago.
>>>>>
>>>>>
>>>>> http://repo1.maven.org/maven2/org/apache/bval/bval-jsr/1.1.0/ passes 1.1
>>>> TCKs (we renamed the main artifact cause naming jsr303 a jsr349 impl was
>>>> odd). Will see if I can update the website - this is one area I didnt work
>>>> on yet.
>>>>
>>>
>>> Oh, that's good to hear, thanks for update.
>>>
>>>
>>> Regards.
>>>
>>> 2: should I put the code in place that actually makes it work, and, if
>>>>>
>>>>>> so, where? I think it would be an additional bundle under 'osgi' that
>>>>>>>> provided a BeanValidationProviderFactory or a
>>>>>>>> ValidationProviderHelper.
>>>>>>>>
>>>>>>>> I guess the servicemix API spec bundle should help.
>>>>>>>>
>>>>>>>> Hi JB, do you think a new BVal spec bundle may need to be released ?
>>>>>>>
>>>>>>> See https://issues.apache.org/jira/browse/SMX4-1618, in the
>>>>>>> description,
>>>>>>>
>>>>>>> Thanks, Sergey
>>>>>>>
>>>>>>
>>> --
>>> Francesco Chicchiriccò
>>>
>>> Tirasa - Open Source Excellence
>>> http://www.tirasa.net/
>>>
>>> Involved at The Apache Software Foundation:
>>> member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF committer
>>> http://home.apache.org/~ilgrosso/
>>>
>>>
>>
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>
>>
>> Open Source Architect
>> http://www.talend.com
>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>

Re: Fixing up bean validation in OSGi

[Benson Margulies]

I've had a PR outstanding at Bval for weeks, with no response to the
email or JIRA. My patch might fix it's current behavior in OSGi for
me, which is to call every bean valid. If any of you can wake the bval
committers up from their, ahem, hibernating state, I would work
further on it. I'm happy to set up dueling hibernate and bval features
in CXF for 3.2.0.


On Mon, Dec 14, 2015 at 1:38 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> +1 for making the bean-validation feature independent from hibernate. I
> intended to do this for 3.2 anyway. I propose to just add the
> javax.validation api bundle with dependency=true and remove the reference
> to the bean-validation-core feature. Not sure if this is a good idea in
> 3.1.x as it is slightly incompatible.
>
> I am -1 of adding a bval feature to CXF. Instead let us create the feature
> either in karaf or directly provided by bval which I think would be the
> best option. I offer my help in doing so.
>
> Christian
>
> 2015-12-14 13:37 GMT+01:00 Francesco Chicchiriccò <ilgro...@apache.org>:
>
>> On 14/12/2015 13:34, Romain Manni-Bucau wrote:
>>
>>> 2015-12-14 13:17 GMT+01:00 Francesco Chicchiriccò <ilgro...@apache.org>:
>>>
>>> On 14/12/2015 12:59, Romain Manni-Bucau wrote:
>>>>
>>>> 2015-12-14 12:45 GMT+01:00 Sergey Beryozkin <sberyoz...@gmail.com>:
>>>>>
>>>>> Hi Benson
>>>>>
>>>>>> On 11/12/15 16:19, Benson Margulies wrote:
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/CXF-6706
>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/CXF-6705
>>>>>>>
>>>>>>> The changes I've committed for CXF-6705 make it possible to use bean
>>>>>>> validation, but ...
>>>>>>>
>>>>>>> 1: only with hibernate
>>>>>>> 2: only with extra code to obtain the validation provider.
>>>>>>>
>>>>>>> This raises two questions.
>>>>>>>
>>>>>>> 1: should I restructure the features to split
>>>>>>> 'cxf-bean-validation-hibernate' from 'cxf-bean-validation', leaving
>>>>>>> room for bval?
>>>>>>>
>>>>>>> Please, I've heard Apache BVal is less complete, but I think we should
>>>>>> keep the option open for users who would like to experiment with this
>>>>>> Apache project
>>>>>>
>>>>>> Hi guys, happy to help fixing any gap there if you need. BVal passes
>>>>> TCKs
>>>>> so IMO it is a valid option.
>>>>>
>>>>> Hi Romain,
>>>> AFAICT, current BVal release (2012!) passes the TCK for JSR-303 (e.g.
>>>> Bean
>>>> Validation 1.0), not JSR-349 (e.g. Bean Validation 1.1)
>>>>
>>>> http://bval.apache.org/downloads.html
>>>>
>>>> Am I wrong?
>>>>
>>>> Incidentally, this is the reason why we had to switch from BVal to
>>>> Hibernate Validator in Syncope, a couple of major releases ago.
>>>>
>>>>
>>>> http://repo1.maven.org/maven2/org/apache/bval/bval-jsr/1.1.0/ passes 1.1
>>> TCKs (we renamed the main artifact cause naming jsr303 a jsr349 impl was
>>> odd). Will see if I can update the website - this is one area I didnt work
>>> on yet.
>>>
>>
>> Oh, that's good to hear, thanks for update.
>>
>>
>> Regards.
>>
>> 2: should I put the code in place that actually makes it work, and, if
>>>>
>>>>> so, where? I think it would be an additional bundle under 'osgi' that
>>>>>>> provided a BeanValidationProviderFactory or a
>>>>>>> ValidationProviderHelper.
>>>>>>>
>>>>>>> I guess the servicemix API spec bundle should help.
>>>>>>>
>>>>>>> Hi JB, do you think a new BVal spec bundle may need to be released ?
>>>>>>
>>>>>> See https://issues.apache.org/jira/browse/SMX4-1618, in the
>>>>>> description,
>>>>>>
>>>>>> Thanks, Sergey
>>>>>>
>>>>>
>> --
>> Francesco Chicchiriccò
>>
>> Tirasa - Open Source Excellence
>> http://www.tirasa.net/
>>
>> Involved at The Apache Software Foundation:
>> member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF committer
>> http://home.apache.org/~ilgrosso/
>>
>>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>
>
> Open Source Architect
> http://www.talend.com
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>

Re: [GitHub] cxf pull request: CXF-6706 hibernate help

[Benson Margulies]

Thanks. I also started a thread at servicemix; hypothetically, this is
all about the servicemix mission and CXF should just take advantage.

On Sun, Dec 13, 2015 at 9:07 AM, reta  wrote:
> Github user reta commented on the pull request:
>
> https://github.com/apache/cxf/pull/102#issuecomment-164262300
>
> @benson-basis I'll try to help you out, @cschneider may have better idea 
> about the issue.
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---

Package versions in OSGI on master are still 3.1.2?

[Benson Margulies]

When I build on Master, I see things like:

Export-Package: org.apache.cxf;version="3.1.2",org.apache.cxf.annotation
 s;version="3.1.2"

Re: elements here and there

[Benson Margulies]

BTW, the sticking point is:

[ERROR] Failed to execute goal on project cxf-core: Could not resolve
dependencies for project
org.apache.cxf:cxf-core:bundle:3.2.0-SNAPSHOT: The following artifacts
could not be resolved:
org.springframework:org.springframework.aop:jar:2.5.6.SEC01,
org.springframework:org.springframework.beans:jar:2.5.6.SEC01,
org.springframework:org.springframework.context:jar:2.5.6.SEC01,
org.springframework:org.springframework.core:jar:2.5.6.SEC01: Could
not find artifact
org.springframework:org.springframework.aop:jar:2.5.6.SEC01 in Nexus
(http://nexus.basistech.net:8081/nexus/content/groups/public) -> [Help
1]



On Fri, Dec 11, 2015 at 8:29 AM, Benson Margulies <bimargul...@gmail.com> wrote:
> When I try to build master in my usual config with a Nexus mirror, I
> fail to find some Spring artifacts.
>
> Usually, this is because there's a  element for some
> repository I have to exempt from my mirror. The question is, why are
> there these elements in several poms, and not just in the parent?

Karaf

[Benson Margulies]

I propose to add some Karaf integration tests under osgi/karaf/itests.

I will code them for Karaf 4 unless someone expresses deep sadness at
this prospect.

I will do this work on the 3.1.x branch and merge it to master, since
the OSGi versions appear to be in an odd state on master.

elements here and there

[Benson Margulies]

When I try to build master in my usual config with a Nexus mirror, I
fail to find some Spring artifacts.

Usually, this is because there's a  element for some
repository I have to exempt from my mirror. The question is, why are
there these elements in several poms, and not just in the parent?

Import order

[Benson Margulies]

What's the correct order for the following? I'm not using Eclipse.

import java.util.ArrayList;
import java.util.List;

//CHECKSTYLE:OFF
import javax.validation.ValidationProviderResolver;
import javax.validation.ValidatorFactory;
import javax.validation.spi.ValidationProvider;
import javax.validation.Validation;
import javax.validation.bootstrap.ProviderSpecificBootstrap;
//CHECKSTYLE:ON

import org.hibernate.validator.HibernateValidator;
import org.hibernate.validator.HibernateValidatorConfiguration;

Re: Karaf

[Benson Margulies]

I'll stick to 3.0.2 on 3.1.x, and when master has it's OSGi versions
in order, off to 4.

Meanwhile,

I have a test case of mine which seems to work great with the code I
was about to commit.

But when I put, essentially, the same test case into the existing
itest, and run with Karaf 3, I am back to

Caused by: javax.el.ELException: Provider
com.sun.el.ExpressionFactoryImpl not found
at 
javax.el.FactoryFinder.newInstance(FactoryFinder.java:101)[49:javax.el-api:3.0.0]
at javax.el.FactoryFinder.find(FactoryFinder.java:197)[49:javax.el-api:3.0.0]
at 
javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:197)[49:javax.el-api:3.0.0]
at 
javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:168)[49:javax.el-api:3.0.0]
at 
org.hibernate.validator.internal.engine.messageinterpolation.InterpolationTerm.(InterpolationTerm.java:60)



On Fri, Dec 11, 2015 at 3:37 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>> On Dec 11, 2015, at 1:13 PM, Benson Margulies <bimargul...@gmail.com> wrote:
>>
>> I propose to add some Karaf integration tests under osgi/karaf/itests.
>>
>> I will code them for Karaf 4 unless someone expresses deep sadness at
>> this prospect.
>>
>> I will do this work on the 3.1.x branch and merge it to master, since
>> the OSGi versions appear to be in an odd state on master.
>
> There are some tests already (not many) in  osgi/itests that are using Karaf 
> 3.0.2.   That said, moving to Karaf 4 makes a ton of sense, definitely for 
> master.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

JMS and batches

[Benson Margulies]

So, I find myself in a situation where CXF provided a very convenient
path to accomplish something that has now led me to a very convenient
brick wall.

It was very convenient to set up work dispatching in a system by just
implementing SOAP/JMS endpoints with CXF. Now, however, I have a
performance issue that cries out for batches.

I'll probably solve this in some completely different way, but I'm
left thinking; what would a 'batch' endpoint even look like? Would it
look just the same, but a configuration parameter would cause it to be
called once for each of the N messages in a batch, with some sort of
callback to 'commit' at the end? Or would it involve getting arrays of
inputs some how?

Does anyone else find this remotely interesting?

Re: Some issues with logging and tests

[Benson Margulies]

On Sun, Sep 30, 2012 at 12:59 PM, Sergey Beryozkin sberyoz...@gmail.com wrote:
 On 30/09/12 14:33, Benson Margulies wrote:

 I've got a case, for which I'm about to file a JIRA, in which I think
 that it's important that a particular situation leads to a log message
 with some minimal content with a particular log level. Have we got any
 tests for cases like this? I'm thinking about wiring up some sort of
 test rig for intercepting log messages for the purpose.

 Meanwhile, this particular case is perhaps worth a moment's discussion.

 In JAX-RS, consider the following circumstance:

 A resource accepts a parameter of bean type, and a mapper (in my case,
 the Jackson json mapper) is responsible for mapping from the incoming
 content to the bean. The incoming headers specify 'accept:
 application/json', since that's what the function (normally) produces.

 Now, someone debugging a python client sends a json blob with a
 misspelled item in it. The mapper throws an exception.

 WebApplicationExceptionMapper catches it and maps it to a 500,
 accompanying the action with a log message at DEBUG.

 The client gets a naked '500', no message anywhere. I suspect, but I'm
 not sure, that the mapper would send back some backtracey verbiage if
 the accept header were no so restrictive.

 On the one hand, a WARN would be handy, as it's a pain to have to go
 adjust the logging config just to see why the client isn't working. On
 the other hand, a production application might get thousands of
 malformed inputs a day, and might not want all this traffic in the
 log.

 Do we have a design principle (written down?) about how we decide what
 should be logged non-DEBUG? Should errors resulting from ill-behaved
 clients get that treatment? If not, I shouldn't write a JIRA or change
 any code here.

 As I said in the previous message, it is to do with the over-optimization of
 WebApplicationExceptionMapper.

 By the way, I'm not sure I agree with the fix to CXF-4528.
 This is now getting complicated: one has to install a fault logger to get a
 stack trace, and, on top of that, the logging will happen twice, if property
 is set and FINE is active...

That was the situation *before* I changed it. As of now, if there's no
fault logger, you have a stack trace if you make the call to turn on
the stack trace. If you *do* decide to put in a fault logger, you
decide whether to dump stack traces from it.


 Let me propose something slightly different: if the fault logger is
 installed and it handled the exception: then do nothing else, the logger can
 log or ignore the error message, if not - do print the warn message because
 a number of times this issue has been raised - and this can be optimized if
 needed by turning 'printStackTrace' to false.

That's what I did, except that I left it at 'FINE'. If I messed up the
logic let's look at the code together.


 Sergey




 --
 Sergey Beryozkin

 Talend Community Coders
 http://coders.talend.com/

 Blog: http://sberyozkin.blogspot.com

Re: Apache CXF (2.6.1): Client gets “Content is not allowed in prolog”

[Benson Margulies]

This is not MTOM:

Content-Type: text/xml; charset=UTF-8; type=text/xml;
Content-Transfer-Encoding: binary
Content-ID: root.mess...@cxf.apache.org

That's not an MTOM message. See
http://en.wikipedia.org/wiki/XML-binary_Optimized_Packaging for what
one of those looks like. Rather, it appears that something has
discarded the HTTP headers that should proceed your XML.

Curious URL in OSGI support in http_jetty

[Benson Margulies]

public static final String JETTY_THREADING =
http://cxf.apache.org/configuration/parameterized-types;;

can someone explain the above?

Re: Tomcat embedding

[Benson Margulies]

On Tue, Apr 24, 2012 at 5:57 AM, Freeman Fang freeman.f...@gmail.com wrote:
 Hi Benson,

 May not answer you question directly about the tomcat embedding.
 You mentioned that the  jetty bugs that close 'idle' connections,  I ran
 into a similar issue months ago, and setMaxIdleTime on jetty can perfectly
 resolve it, not sure it's exactly same problem you encounter with jetty, but
 it's worthy of checking.
 Please take a look at [1] to get more details.

 [1]http://cxf.547215.n5.nabble.com/CXF-retrying-an-operation-td5072484.html#a5074035

Recently, that problem returned to us regardless of our setting of
maxIdleTime. I fear a new Jetty bug.


 Freeman



 On 2012-4-23, at 下午10:41, Benson Margulies wrote:

 Last year, I took a look at tomcat as an alternative to Jetty for
 embedding purposes.

 I ran aground, I was just too ignorant.

 Since I seem, again, to be hitting jetty bugs that close 'idle'
 connections inappropriately, I've got myself interested again.

 Is anyone who has a grip on server transports willing to help me out?


 -
 Freeman Fang

 FuseSource
 Email:ff...@fusesource.com
 Web: fusesource.com
 Twitter: freemanfang
 Blog: http://freemanfang.blogspot.com
 http://blog.sina.com.cn/u/1473905042
 weibo: http://weibo.com/u/1473905042

Tomcat embedding

[Benson Margulies]

Last year, I took a look at tomcat as an alternative to Jetty for
embedding purposes.

I ran aground, I was just too ignorant.

Since I seem, again, to be hitting jetty bugs that close 'idle'
connections inappropriately, I've got myself interested again.

Is anyone who has a grip on server transports willing to help me out?

Re: Tomcat embedding

[Benson Margulies]

Glen,

This is very helpful if I want to cheap out of actually teaching CXF
to embed tomcat as it currently embeds Jetty:-)

On Mon, Apr 23, 2012 at 1:46 PM, Glen Mazza glen.ma...@gmail.com wrote:

 Benson Margulies wrote

 Last year, I took a look at tomcat as an alternative to Jetty for
 embedding purposes.

 I ran aground, I was just too ignorant.

 Since I seem, again, to be hitting jetty bugs that close 'idle'
 connections inappropriately, I've got myself interested again.

 Is anyone who has a grip on server transports willing to help me out?


 I had done an example with embedded Tomcat a while back, perhaps it might
 help you:
 http://www.jroller.com/gmazza/entry/junit_web_service_testing#testtc

 Glen

 --
 View this message in context: 
 http://cxf.547215.n5.nabble.com/Tomcat-embedding-tp5659578p5660035.html
 Sent from the cxf-dev mailing list archive at Nabble.com.

Re: Tomcat embedding

[Benson Margulies]

On Mon, Apr 23, 2012 at 8:09 PM, Glen Mazza glen.ma...@gmail.com wrote:
 Really?  AFAICT the code I linked to *is* using Tomcat, if perhaps not
 directly in the manner that you're interested.
 Glen

Really. Currently, when you just 'launch an endpoint', CXF launches
Jetty behind your back. I'd love to make it possible for CXF to do the
same with Tomcat; however, your scheme gets me the same end-user
benefits for a lot less effort than building a http_tomcat transport
next to the http_jetty transport.




 Benson Margulies wrote

 Glen,

 This is very helpful if I want to cheap out of actually teaching CXF
 to embed tomcat as it currently embeds Jetty:-)

 On Mon, Apr 23, 2012 at 1:46 PM, Glen Mazza lt;glen.mazza@gt; wrote:

 Benson Margulies wrote

 Last year, I took a look at tomcat as an alternative to Jetty for
 embedding purposes.

 I ran aground, I was just too ignorant.

 Since I seem, again, to be hitting jetty bugs that close 'idle'
 connections inappropriately, I've got myself interested again.

 Is anyone who has a grip on server transports willing to help me out?


 I had done an example with embedded Tomcat a while back, perhaps it might
 help you:
 http://www.jroller.com/gmazza/entry/junit_web_service_testing#testtc

 Glen

 --
 View this message in context:
 http://cxf.547215.n5.nabble.com/Tomcat-embedding-tp5659578p5660035.html
 Sent from the cxf-dev mailing list archive at Nabble.com.



 --
 View this message in context: 
 http://cxf.547215.n5.nabble.com/Tomcat-embedding-tp5659578p5660755.html
 Sent from the cxf-dev mailing list archive at Nabble.com.

Re: CORS documentation

[Benson Margulies]

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 Beryozkin sberyoz...@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: CXF 2.5.2 later this week....

[Benson Margulies]

I haven't fixed codegen because I was hoping to lure a new person into it.

On Tue, Jan 17, 2012 at 10:50 AM, Daniel Kulp dk...@apache.org wrote:

 There were a few regressions in 2.5.1 that are now resolved (or I'll get
 resolved shortly) that I think would be a good idea to get released.   Thus,
 I'm thinking of building 2.5.2 later this week.   There aren't a LOT of
 changes (although 37 issues are resolved already), but due to the regressions,
 I think getting the fixes out sooner is a good option.

 Thoughts?

 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

2.5.1 codegen issues

[Benson Margulies]

So I apparently busted some things in the codegen plugin for 2.5.1.
Unfortunately, I've been sick for a week, and that really puts a chomp
into my ability to roll my sleeves up. My strong belief is that we
need proper plugin integration tests, the same way that other maven
plugins deal with this -- the maven-invoker-plugin. Has anyone else
got time to start on this? If not, I'll get onto it when I can.

Re: 2.5.1 codegen issues

[Benson Margulies]

On Tue, Jan 3, 2012 at 3:57 PM, Daniel Kulp dk...@apache.org wrote:
 On Tuesday, January 03, 2012 3:54:13 PM Daniel Kulp wrote:
 On Tuesday, January 03, 2012 12:45:42 PM Benson Margulies wrote:
  So I apparently busted some things in the codegen plugin for 2.5.1.
  Unfortunately, I've been sick for a week, and that really puts a chomp
  into my ability to roll my sleeves up. My strong belief is that we
  need proper plugin integration tests, the same way that other maven
  plugins deal with this -- the maven-invoker-plugin.

 +1

  Has anyone else
  got time to start on this? If not, I'll get onto it when I can.

 I've never looked into using the maven-invoker-plugin to run it tests.  I
 was going to grab olamy to help walk me through it, but he ended up having
 an additional child suddenly appear yesterday and is now on full time
 daddy duty for a bit.   :-)   (congrats to him, btw)   I may have some
 time next week, but right now, no.

 That said,  I just looked at the issues and the issues are all due to the
 exact same issue and I'm testing a fix for it now.

 Well, CXF-4002 is not.   No idea on that one yet.  The fact that it's only in
 Sonar makes me really question it.

I think that this is a Sonar bug, perhaps exposed by my cleanup of
that parameter. I'd love to hear from someone sonarial. Sonorus?


 Dan



 Basically, the
 defaultOptions were being merged in twice in SOME cases.   In the directory
 scan, it used the defaultOptions to initialize the options, but then a merge
 was done in mergeOptions and the extraArgs would get doubled.

 I ended up taking out the passing of the defaultOptions into the various
 scans and such and letting just the mergeOptions call handle it.  That
 allows it to work for the scan, the explicitly set stuff, and the wsdl dep
 case.
 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: Case-sensitivity on HTTP headers and CORS

[Benson Margulies]

See CXF-3998 instead.

On Thu, Dec 22, 2011 at 4:47 AM, Sergey Beryozkin sberyoz...@gmail.com wrote:
 Hi Benson
 On 22/12/11 02:41, Benson Margulies wrote:


 http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#author-request-headers
 demands case-sensitive comparison.

 Chrome sends, e.g.:

    Access-Control-Request-Headers: Content-Type

 Firefox sends, e.g.

   Access-Control-Request-Headers: content-type

 Should we violate the spec and do a case-insensitive comparison?


 In JAX-RS the headers can be retrieved using a case-insensitive comparison,
 ex,
 @Header(content-type) String h

 needs to work with Content-Type.

 So perhaps we should do a case-insensitive comparison by default and add a
 filter property which can be used to enforce the case-sensitive comparison

 Cheers, Sergey

CORS filter a bit noisy

[Benson Margulies]

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.

CORS filter a bit noisy

[Benson Margulies]

It looks to me as if the CORS filter has a bug: it returns headers
even when the request is not cross-origin. Sergey,

Case-sensitivity on HTTP headers and CORS

[Benson Margulies]

http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#author-request-headers
demands case-sensitive comparison.

Chrome sends, e.g.:

   Access-Control-Request-Headers: Content-Type

Firefox sends, e.g.

  Access-Control-Request-Headers: content-type

Should we violate the spec and do a case-insensitive comparison?

One other fissile idea, the maven plugins

[Benson Margulies]

I think that there might be an advantage in declaring the maven
plugins to be an independent top-level that we release after a release
of the core product, (and perhaps release in-between as needed).
There's a pattern to maven plugin projects at maven.apache.org or the
Mojo project at codehaus, and that pattern has some advantages, if
only comparability and familiarity. We could use the invoker for
tests, etc.

What do folks think?

Re: CXF releases next week....

[Benson Margulies]

Oh, glorp. I'd like to get the wsdl2js mojo in place, but I don't know
if I can do it fast enough. I'll try to finish it tonight.

On Mon, Dec 12, 2011 at 9:20 AM, Daniel Kulp dk...@apache.org wrote:

 There were a bunch of changes over the weekend and a couple of regressions so
 I want to delay this a day or so to make sure we stabilize this a bit more.
 Hope thats not an issue for anyone.

 Dan


 On Friday, December 09, 2011 10:44:29 AM Daniel Kulp wrote:
 I'm thinking of doing 2.3.8/2.4.5/2.5.1 releases on Monday so that we can
 get them out later next week.    I don't really want to do them the week
 before Christmas if we don't have to and I'd also prefer not to wait till
 January.

 We currently have 30 JIRA's marked resolved for 2.3.8, 36 for 2.4.5, and 63
 for 2.5.1 so we definitely have a good number of things fixed for these
 releases.

 Are there any objections?  Anything else need to get in first?
 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: One other fissile idea, the maven plugins

[Benson Margulies]

I'll answer your question with a question.

Could the maven plugins be in the build last, so that they could have
the same sort of integration tests as all the maven plugins at Maven
and Mojo? If so, I completely withdraw my idea. If not, I guess I
can't make a really good argument, and the tests could just live 'over
there' in systests as they do now.

Testing of the wsdl2java mojo

[Benson Margulies]

We haven't got much in the way of tests here. I found a few zingers
while refactoring (e.g. a ConcurrentModification problem from deleting
from an ArrayList in mid-iteration). But I don't feel all that certain
that I have not added some bugs as well.

It would be good if people could cook more tests; I'm not that much of
an expert on the complex things it can be asked to do.

Loop-to-loop

[Benson Margulies]

When I try to add the js tooling to the codgen plugin as a dependency
to enable the js mojo, I get whacked with this.

Any suggestions?

[ERROR] The projects in the reactor contain a cyclic reference: Edge
between 'Vertex{label='org.apache.cxf:cxf-codegen-plugin:2.5.1-SNAPSHOT'}'
and 
'Vertex{label='org.apache.cxf:cxf-tools-wsdlto-frontend-javascript:2.5.1-SNAPSHOT'}'
introduces to cycle in the graph
org.apache.cxf:cxf-tools-wsdlto-frontend-javascript:2.5.1-SNAPSHOT --
org.apache.cxf:cxf-rt-javascript:2.5.1-SNAPSHOT --
org.apache.cxf:cxf-rt-frontend-simple:2.5.1-SNAPSHOT --
org.apache.cxf:cxf-rt-bindings-xml:2.5.1-SNAPSHOT --
org.apache.cxf:cxf-rt-databinding-jaxb:2.5.1-SNAPSHOT --
org.apache.cxf:cxf-testutils:2.5.1-SNAPSHOT --
org.apache.cxf:cxf-codegen-plugin:2.5.1-SNAPSHOT --
org.apache.cxf:cxf-tools-wsdlto-frontend-javascript:2.5.1-SNAPSHOT -
[Help 1]
org.apache.maven.ProjectCycleException: The projects in the reactor
contain a cyclic reference: Edge between
'Vertex{label='org.apache.cxf:cxf-codegen-plugin:2.5.1-SNAPSHOT'}' and
'Vertex{label='org.apache.cxf:cxf-tools-wsdlto-frontend-javascript:2.5.1-SNAPSHOT'}'
introduces to cycle in the graph
org.apache.cxf:cxf-tools-wsdlto-frontend-javascript:2.5.1-SNAPSHOT --
org.apache.cxf:cxf-rt-javascript:2.5.1-SNAPSHOT --
org.apache.cxf:cxf-rt-frontend-simple:2.5.1-SNAPSHOT --
org.apache.cxf:cxf-rt-bindings-xml:2.5.1-SNAPSHOT --
org.apache.cxf:cxf-rt-databinding-jaxb:2.5.1-SNAPSHOT --
org.apache.cxf:cxf-testutils:2.5.1-SNAPSHOT --
org.apache.cxf:cxf-codegen-plugin:2.5.1-SNAPSHOT --
org.apache.cxf:cxf-tools-wsdlto-frontend-javascript:2.5.1-SNAPSHOT

Re: Loop-to-loop

[Benson Margulies]

This charming message is a fraud. the loop related to plugin
executions and is the reason why I shouldn't have put any codegen
executions in the javascript runtime pom.

On Mon, Dec 12, 2011 at 9:40 PM, Benson Margulies bimargul...@gmail.com wrote:
 When I try to add the js tooling to the codgen plugin as a dependency
 to enable the js mojo, I get whacked with this.

 Any suggestions?

 [ERROR] The projects in the reactor contain a cyclic reference: Edge
 between 'Vertex{label='org.apache.cxf:cxf-codegen-plugin:2.5.1-SNAPSHOT'}'
 and 
 'Vertex{label='org.apache.cxf:cxf-tools-wsdlto-frontend-javascript:2.5.1-SNAPSHOT'}'
 introduces to cycle in the graph
 org.apache.cxf:cxf-tools-wsdlto-frontend-javascript:2.5.1-SNAPSHOT --
 org.apache.cxf:cxf-rt-javascript:2.5.1-SNAPSHOT --
 org.apache.cxf:cxf-rt-frontend-simple:2.5.1-SNAPSHOT --
 org.apache.cxf:cxf-rt-bindings-xml:2.5.1-SNAPSHOT --
 org.apache.cxf:cxf-rt-databinding-jaxb:2.5.1-SNAPSHOT --
 org.apache.cxf:cxf-testutils:2.5.1-SNAPSHOT --
 org.apache.cxf:cxf-codegen-plugin:2.5.1-SNAPSHOT --
 org.apache.cxf:cxf-tools-wsdlto-frontend-javascript:2.5.1-SNAPSHOT -
 [Help 1]
 org.apache.maven.ProjectCycleException: The projects in the reactor
 contain a cyclic reference: Edge between
 'Vertex{label='org.apache.cxf:cxf-codegen-plugin:2.5.1-SNAPSHOT'}' and
 'Vertex{label='org.apache.cxf:cxf-tools-wsdlto-frontend-javascript:2.5.1-SNAPSHOT'}'
 introduces to cycle in the graph
 org.apache.cxf:cxf-tools-wsdlto-frontend-javascript:2.5.1-SNAPSHOT --
 org.apache.cxf:cxf-rt-javascript:2.5.1-SNAPSHOT --
 org.apache.cxf:cxf-rt-frontend-simple:2.5.1-SNAPSHOT --
 org.apache.cxf:cxf-rt-bindings-xml:2.5.1-SNAPSHOT --
 org.apache.cxf:cxf-rt-databinding-jaxb:2.5.1-SNAPSHOT --
 org.apache.cxf:cxf-testutils:2.5.1-SNAPSHOT --
 org.apache.cxf:cxf-codegen-plugin:2.5.1-SNAPSHOT --
 org.apache.cxf:cxf-tools-wsdlto-frontend-javascript:2.5.1-SNAPSHOT

Fun with maven site -- and is anyone interested in splitting the systests out of the main build?

[Benson Margulies]

I'm trying to get the maven site plugin going. I can generate a whole
lot of site, and then I get an out of memory (with -Xmx6g)! I'm going
to need a bigger computer. The site lifecycle runs a lot of the rest
of what we do, and I guess, captain, that we've sprung a leak.

For those who want to play along at home, using maven 3.0.3,

mvn process-classes site:site

This lead me to wonder: would it improve our life to define the
'released product' of CXF to exclude the systests, and treat them as a
testing resource? With modern Jenkins, we can easily have a build of
the main trunk cascade into a build of the systests on the very
snapshots built by the first build. At release time, we'd run the
systests against the candidate. We wouldn't publish them to Nexus in
any form.

I'm pretty sure, based on recent board@ and general@incubator
wrangles, that this would be legit.

Re: Some questions about the in CORS filter

[Benson Margulies]

On Mon, Dec 5, 2011 at 7:15 AM, Sergey Beryozkin sberyoz...@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.

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.


 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

[Benson Margulies]

On Mon, Dec 5, 2011 at 10:15 AM, Sergey Beryozkin sberyoz...@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? 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.



 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

[Benson Margulies]

At some point, we're going to need to try some experiments with a
browser and make sure that whatever it is we've done actually works.
Unfortunately, htmlunit doesn't have this client side yet (I'm working
on a patch). I suppose I should read the source of Chromium or
something, unless you beat me to it.

On Mon, Dec 5, 2011 at 11:04 AM, Sergey Beryozkin sberyoz...@gmail.com wrote:
 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

Re: Some questions about the in CORS filter

[Benson Margulies]

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.

Re: CORS

[Benson Margulies]

I've created org.apache.cxf.jaxrs.cors.CrossOriginResourceSharingFilter,
which is gradually learning to pass all the tests I'm figuring out to
write. It is a complete implementation of the spec AFAICT.

On Sat, Nov 12, 2011 at 2:35 AM, K Fung kfung4...@gmail.com wrote:
 Hello,

 Are there any plans to expand this code so that covers both 5.1 and 5.2 of
 the CORS specification (http://www.w3.org/TR/cors?) In particular,

 - Not blocking the request of it's an OPTIONS request but doesn't contain
 the Origin header
 - What if the request doesn't contain OPTIONS but does contain the Origin
 header (section 5.1 of the spec)
 - Adding support for Access-Control-Allow-Credentials (section 5.2 of the
 spec, step 7)
 - Adding support for Access-Control-Max-Age (section 5.2 of the spec, step
 8)

 Cheers,
 kl

Getting around HttpUrlConnection restrictions

[Benson Margulies]

There is a system property that disables it -- read once -- in a static block.

Does anyone thing it would be possible to create an independent class
loader and load this class into it a second time, with the property
set, and then talk to it via reflection?

Re: Getting around HttpUrlConnection restrictions

[Benson Margulies]

On Thu, Dec 1, 2011 at 10:34 AM, Daniel Kulp dk...@apache.org wrote:
 On Thursday, December 01, 2011 9:46:41 AM Benson Margulies wrote:
 There is a system property that disables it -- read once -- in a static
 block.

 Does anyone thing it would be possible to create an independent class
 loader and load this class into it a second time, with the property
 set, and then talk to it via reflection?

 Wouldn't it be easier to just use a little reflection to grab the set and call
 remove on it:

That hasn't occurred to me.


 Class cls = Class.forName(sun.net.www.protocol.http.HttpURLConnection);
 Field f = cls.getDeclaredField(restrictedHeaderSet);
 f.setAssible(true);
 ((Set)f.get(null)).remove(origin);


 Now, that will likely not work in OSGi as the Class.forName is likely to
 completely fail.   Would need to figure something else out there.  Probably
 would have to allow the system to export that package.


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [proposal] Cross-Origin JAX-RS annotations

[Benson Margulies]

On Thu, Dec 1, 2011 at 10:34 AM, Sergey Beryozkin sberyoz...@gmail.com wrote:
 On 01/12/11 14:51, Benson Margulies wrote:

 I propose to add the following

 @CorsAllowAllOrigins
 @CorsAllowOrigins(  origin1., ... originN )
 @CorsAllowMethods( meth1 ... methn )
 @CorsExposeMethods( ... )
 @CorsMaxAge(integer)
 @CorsAllowCredentials(boolean)

 and make the filter look for them on resources and classes in the usual
 way.

 Any objections?


 Can we collapse it all into a single annotation but with many properties ?
 @Cors(origins = ...,
      methods = a b c
      allowCredentials = true
      )

 I'd prefer if possible to avoid the explosion of annotations.

I hate space-separated. Can they be String[], or am I stuck with those spaces?


 Re @CorsAllowMethods( meth1 ... methn ) (or methods = a b) - is it
 HTTP methods ?

yes.

 Then how it work on a method annotated with say @POST ? May be it should be
 a single method value only ?

So we don't need this annotation. If any of the others are there, it
would imply permission for the method.

 Re CorsAllowOrigins, is it relative URIs ? We'd probably need to think of
 introducing properties such as absolute.uri, etc, to be reused by other
 annotation such as SchemaLocation  XMLInstruction

Origin must be an absolute URI. In fact, it's a list of them due to redirects.

You never need to list 'right here', right here is always allowed.
It's only necessary to list other places, so I don't see the need for
anything tricky.


 Thanks, Sergey

A moment of confusion about http headers and JAX-RS responses?

[Benson Margulies]

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?

Re: Failing to set an Origin header with a WebClient

[Benson Margulies]

I'd rather write the transport.

On Thu, Dec 1, 2011 at 11:13 AM, Sergey Beryozkin sberyoz...@gmail.com 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

An annotation utility I thought we would have

[Benson Margulies]

I'm a bit surprised that org.apache.cxf.jaxrs.utils.AnnotationUtils
does not have a method that says:

Here's a method and an annotation. If the method has the annotation,
return it. Otherwise, go to the containing class, and it's parents, in
search of it.

Is there something I'm missing which would make this a bad idea?

Re: An annotation utility I thought we would have

[Benson Margulies]

Doesn't help with methods, only with classes. But that still is less
code to write than nothing at all.

On Thu, Dec 1, 2011 at 11:56 AM, Daniel Kulp dk...@apache.org wrote:
 On Thursday, December 01, 2011 11:48:45 AM Benson Margulies wrote:
 I'm a bit surprised that org.apache.cxf.jaxrs.utils.AnnotationUtils
 does not have a method that says:

 Here's a method and an annotation. If the method has the annotation,
 return it. Otherwise, go to the containing class, and it's parents, in
 search of it.

 Is there something I'm missing which would make this a bad idea?

 Probably something useful to add to ReflectionUtil.

 That said, you should also ask yourself if  the annotation itself just have
 @Inherited on it and whether that would be enough or not?


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: An annotation utility I thought we would have

[Benson Margulies]

JAX-RS has an AnnotationUtils class that has other annotational
goodies, and there's no annotation code in ReflectionUtil, so I think
I'll follow the Alice's Restaurant principle.


On Thu, Dec 1, 2011 at 11:56 AM, Daniel Kulp dk...@apache.org wrote:
 On Thursday, December 01, 2011 11:48:45 AM Benson Margulies wrote:
 I'm a bit surprised that org.apache.cxf.jaxrs.utils.AnnotationUtils
 does not have a method that says:

 Here's a method and an annotation. If the method has the annotation,
 return it. Otherwise, go to the containing class, and it's parents, in
 search of it.

 Is there something I'm missing which would make this a bad idea?

 Probably something useful to add to ReflectionUtil.

 That said, you should also ask yourself if  the annotation itself just have
 @Inherited on it and whether that would be enough or not?


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [proposal] Cross-Origin JAX-RS annotations

[Benson Margulies]

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.

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.

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?

Re: [proposal] Cross-Origin JAX-RS annotations

[Benson Margulies]

I forgot to ask, can you help me figure out which class is the right
class for the information I've got?

Re: CORS

[Benson Margulies]

The code doesn't quite work as you expect.

If there is no origin header at all, the input filter gets an empty
array, not a null, so it does the wrong thing.


On Sat, Nov 12, 2011 at 2:35 AM, K Fung kfung4...@gmail.com wrote:
 Hello,

 Are there any plans to expand this code so that covers both 5.1 and 5.2 of
 the CORS specification (http://www.w3.org/TR/cors?) In particular,

 - Not blocking the request of it's an OPTIONS request but doesn't contain
 the Origin header
 - What if the request doesn't contain OPTIONS but does contain the Origin
 header (section 5.1 of the spec)
 - Adding support for Access-Control-Allow-Credentials (section 5.2 of the
 spec, step 7)
 - Adding support for Access-Control-Max-Age (section 5.2 of the spec, step
 8)

 Cheers,
 kl

'parsing failed' -- detecting invalid headers

[Benson Margulies]

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?

The JAX-RS system tests

[Benson Margulies]

There are a set of tests surrounding AbstractSpringServer. Each one
has a beans.xml that launches an endpoint; but then somehow the
additional service is launched.

Are the 'launched' services also inside the endpoint with the same providers?

Failing to set an Origin header with a WebClient

[Benson Margulies]

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());

Re: Failing to set an Origin header with a WebClient

[Benson Margulies]

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.String),
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.transport.http.Servlet3ContinuationProvider@4ac5c32e,
null, null, null,
org.apache.cxf.message.Message.IN_INTERCEPTORS=[org.apache.cxf.transport.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 Margulies bimargul...@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());

Re: Failing to set an Origin header with a WebClient

[Benson Margulies]

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 Margulies bimargul...@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.String),
 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.transport.http.Servlet3ContinuationProvider@4ac5c32e,
 null, null, null,
 org.apache.cxf.message.Message.IN_INTERCEPTORS=[org.apache.cxf.transport.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 Margulies bimargul...@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());

Re: svn commit: r1208752 - in /cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/cors: CrossOriginInputFilter.java CrossOriginOutputFilter.java

[Benson Margulies]

I almost beat you to this.

On Wed, Nov 30, 2011 at 3:27 PM,  dk...@apache.org wrote:
 Author: dkulp
 Date: Wed Nov 30 20:27:39 2011
 New Revision: 1208752

 URL: http://svn.apache.org/viewvc?rev=1208752view=rev
 Log:
 Compile on java5

 Modified:
    
 cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/cors/CrossOriginInputFilter.java
    
 cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/cors/CrossOriginOutputFilter.java

 Modified: 
 cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/cors/CrossOriginInputFilter.java
 URL: 
 http://svn.apache.org/viewvc/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/cors/CrossOriginInputFilter.java?rev=1208752r1=1208751r2=1208752view=diff
 ==
 --- 
 cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/cors/CrossOriginInputFilter.java
  (original)
 +++ 
 cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/cors/CrossOriginInputFilter.java
  Wed Nov 30 20:27:39 2011
 @@ -56,7 +56,6 @@ public class CrossOriginInputFilter impl
     private ListString allowedHeaders = Collections.emptyList();
     private boolean allowAllOrigins;

 -    @Override
     public Response handleRequest(Message m, ClassResourceInfo resourceClass) 
 {
         if (OPTIONS.equals(m.get(Message.HTTP_REQUEST_METHOD))) {
             OperationResourceInfo opResInfo = 
 m.getExchange().get(OperationResourceInfo.class);

 Modified: 
 cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/cors/CrossOriginOutputFilter.java
 URL: 
 http://svn.apache.org/viewvc/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/cors/CrossOriginOutputFilter.java?rev=1208752r1=1208751r2=1208752view=diff
 ==
 --- 
 cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/cors/CrossOriginOutputFilter.java
  (original)
 +++ 
 cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/cors/CrossOriginOutputFilter.java
  Wed Nov 30 20:27:39 2011
 @@ -52,7 +52,6 @@ public class CrossOriginOutputFilter imp
         return null;
     }

 -    @Override
     public Response handleResponse(Message m, OperationResourceInfo ori, 
 Response response) {
         String op = 
 (String)m.getExchange().get(CrossOriginOutputFilter.class.getName());
         if (op == null) {

Re: CORS

[Benson Margulies]

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 Beryozkin sberyoz...@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.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: CORS

[Benson Margulies]

Serg,

To contribute code, it's preferred, if possible, to attach it to a JIRA.

--benson


On Thu, Nov 17, 2011 at 12:39 PM, sergkorney sergkor...@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.

Re: Archetypes

[Benson Margulies]

 Does it really matter?   The entire step 3 above kind of makes it so we
 cannot just re-generate the archetypes from the originals very easily again.

I dunno. Step 3 is pretty small potatoes compared to building up the
project in the first place.

But I asked this question to find out what you thought ...


 If you want, we can create someplace (likely outside of trunk, maybe
 cxf/archetype-templates or similar) to put them.   Doesn't really matter to
 me.

.. and this is fine as a plan.



 --
 Daniel Kulp
 dk...@apache.org
 http://dankulp.com/blog
 Talend - http://www.talend.com

Re: svn commit: r1201893 - /cxf/trunk/maven-plugins/archetypes/pom.xml

[Benson Margulies]

I fixed the deps but I didn't reactivate it. Can you try and see if it
behaves for you?

On Mon, Nov 14, 2011 at 3:52 PM,  dk...@apache.org wrote:
 Author: dkulp
 Date: Mon Nov 14 20:52:49 2011
 New Revision: 1201893

 URL: http://svn.apache.org/viewvc?rev=1201893view=rev
 Log:
 Remove new archtype from build for right now.  Has a couple snapshot
 deps that I cannot resolve.

 Modified:
    cxf/trunk/maven-plugins/archetypes/pom.xml

 Modified: cxf/trunk/maven-plugins/archetypes/pom.xml
 URL: 
 http://svn.apache.org/viewvc/cxf/trunk/maven-plugins/archetypes/pom.xml?rev=1201893r1=1201892r2=1201893view=diff
 ==
 --- cxf/trunk/maven-plugins/archetypes/pom.xml (original)
 +++ cxf/trunk/maven-plugins/archetypes/pom.xml Mon Nov 14 20:52:49 2011
 @@ -36,6 +36,6 @@

     modules
         modulecxf-jaxws-javafirst/module
 -       modulecxf-jaxrs-service/module
 +        !--modulecxf-jaxrs-service/module--
     /modules
  /project

Re: svn commit: r1201893 - /cxf/trunk/maven-plugins/archetypes/pom.xml

[Benson Margulies]

On Mon, Nov 14, 2011 at 9:24 PM, Daniel Kulp dk...@apache.org wrote:
 On Monday, November 14, 2011 8:50:43 PM Benson Margulies wrote:
 I fixed the deps but I didn't reactivate it. Can you try and see if it
 behaves for you?


 Yea.  Works now.   I should have tried that.   I saw your messages on the
 Maven list about the archetype plugin and assumed you were experimenting with
 something.   :-)

I was experimenting, but all I ended up doing was writing doc. To
write doc I had to step through, and to step through I had to be
running the snapshot.


 Dan


 On Mon, Nov 14, 2011 at 3:52 PM,  dk...@apache.org wrote:
  Author: dkulp
  Date: Mon Nov 14 20:52:49 2011
  New Revision: 1201893
 
  URL: http://svn.apache.org/viewvc?rev=1201893view=rev
  Log:
  Remove new archtype from build for right now.  Has a couple snapshot
  deps that I cannot resolve.
 
  Modified:
     cxf/trunk/maven-plugins/archetypes/pom.xml
 
  Modified: cxf/trunk/maven-plugins/archetypes/pom.xml
  URL:
  http://svn.apache.org/viewvc/cxf/trunk/maven-plugins/archetypes/pom.xml
  ?rev=1201893r1=1201892r2=1201893view=diff
  ===
  === --- cxf/trunk/maven-plugins/archetypes/pom.xml (original)
  +++ cxf/trunk/maven-plugins/archetypes/pom.xml Mon Nov 14 20:52:49 2011
  @@ -36,6 +36,6 @@
 
      modules
          modulecxf-jaxws-javafirst/module
  -       modulecxf-jaxrs-service/module
  +        !--modulecxf-jaxrs-service/module--
      /modules
   /project
 --
 Daniel Kulp
 dk...@apache.org
 http://dankulp.com/blog
 Talend - http://www.talend.com

Archetypes

[Benson Margulies]

I now know how to make archetypes.

1) Make a project that looks like:

git://github.com/bimargulies/cxf-jaxrs-archetype.git

2) run mvn archetype:create-from-project

3) clean out unwanted cruft.

4) check in.

Should we make a home in SVN for these archetype-originals?

SEO

[Benson Margulies]

Try a google search on 'cxf maven archetypes'.

Nothing from cxf.apache.org anywhere near the top.

Re: CORS

[Benson Margulies]

Why a filter? I guess, the advantage would be that it would work for
SOAP and REST both. On the other hand, it's kind of 'over there'. Does
JAX-RS have any other way to share out adding a handler for OPTIONS
(and access control checking on Origin) that would have any
advantages?

On Mon, Nov 7, 2011 at 9:10 AM, Sergey Beryozkin sberyoz...@gmail.com wrote:
 Hi Benson
 On 07/11/11 04:04, Benson Margulies wrote:

 Has anyone considered adding CORS (http://www.w3.org/TR/cors/) to CXF
 REST services? Obviously, it could be coded one service at a time, but
 it looks handy.

 Can you look at
 http://cxf.547215.n5.nabble.com/CORS-Interceptor-Filter-Endpoint-td4793366.html
 please ?
 Do you reckon we should ship a CXF specific CORS filter ?

 Thanks, Sergey

CORS

[Benson Margulies]

Has anyone considered adding CORS (http://www.w3.org/TR/cors/) to CXF
REST services? Obviously, it could be coded one service at a time, but
it looks handy.

Re: Ancient JIRA issues....

[Benson Margulies]

On Wed, Sep 7, 2011 at 12:27 PM, Daniel Kulp dk...@apache.org wrote:

 I was kind of poking around to see how some other projects handle feature
 requests  for things likely not to ever be implemented as we're a similar
 situations.  We have a bunch of JIRA's logged years ago for new features, but
 no one has stepped up to implement them.

 A couple projects have a pseudo time limit.  If no-one steps up to claim it or
 submit a patch within a certain period (like maybe a year), they close is as
 Won't Fix with a comment along the lines of If someone would like to step
 up and implement this, re-open and attach a patch.

I am enthusiastically in favor of this.


 What are peoples thoughts on this?    I'd really like to get some of the
 clutter out of JIRA.    I would also suggest either a 6 month or 1 year limit
 on feature request JIRAs.


 --
 Daniel Kulp
 dk...@apache.org
 http://dankulp.com/blog
 Talend - http://www.talend.com

Re: Aegis, XmlBeans and CXF

[Benson Margulies]

An entire Apache project ('tlp', for top-level-project) requires a
viable community to answer questions, fix bugs, and move forward.
Aegis is a piece of CXF that happens to be usable without the rest of
CXF. It does not have an attached posse of human beings who could (and
have any desire to) form a TLP, so it remains inside of CXF.

On Fri, Aug 19, 2011 at 9:28 AM, Robert Liguori c...@gliesian.com wrote:
 I'm not understanding the home of the Aegis databinding within CXF.

 Shouldn't Aegis have it's own Apache project?

 Similarly, what's up with Apache XmlBeans?  It seems to need a place to
 thrive (as it's relatively inactive)...  could XmlBeans be subsumed/hosted
 by CXF?

 Better yet, what about a merger between Aegis and XmlBeans (into the
 XmlBeans project)... does this make any sense?

 'or is everything fine just how it is?

 ...just tying to grasp the dynamics of things.

 Thanks,
 Robert

Proxies as abstract classes?

[Benson Margulies]

Has anyone ever considered the utility or practicality of generating a
concrete subclass of an abstract class as a proxy? All the standards
we conform to are relentless about interfaces, aren't they?

Jenkins email storms

[Benson Margulies]

Could we set up the jobs so that one has to pass before the others
run? As it is, any glitch results in a torrent of email.

Re: [DISCUSSION] Introducing a new Reliable JMS CXF Transport

[Benson Margulies]

I'm confused. If you use AMQ configured for reliable storage on disk,
how do you lose things with the existing CXF transport?

On Fri, Jul 8, 2011 at 8:23 AM, Florent BENOIT florent.ben...@ow2.org wrote:
    Hi CXF guys,

 I would like to introduce a new CXF transport that we've developed and that
 could be contributed back to the CXF community. It is called Reliable JMS
 transport

 When this transport has been designed, the goal was to have a reliable
 transport that we could called Enterprise Transport as we wanted to use
 transactions and JMS by using containers like Java EE EJB or Spring MDP (we
 support both). We don't want to loose any requests or answers and we want to
 avoid waiting threads. This transport has not been designed from scratch as
 it is using the JMS layer and share some classes with the current CXF JMS
 transport but there are some differences between them. But we couldn't
 change the current transport as the design is not the same.

 First, let me give you details about this transport and why it's different
 from the current JMS CXF transport.

 The current CXF JMS transport is not reliable. For example, if you restart a
 client or a server you may loose some requests/answers. This is because the
 mechanism that is used is keeping data in memory. So after a JVM crash, all
 the data are lost.
 Also, for this new transport, we wanted to guarantee the delivery so it is
 using transactions. (A transaction manager is then required).
 As said before, we wanted to avoid the use of threads waiting for an answer.
 If there are 100 requests, we don't want 100 threads waiting their answer.
 This is because we can use either EJB MDB or Spring MDP to handle the
 answer. In this way, resources are allocated only if an answer is handled
 and not during all the waiting time. So the number of threads is
 dramatically reduced. Also by relying on EJB MDB or Spring MDP we're based
 on existing patterns.

 Here is a link to the documentation of this transport and pictures that are
 illustrating this solution :
 http://wiki.jonas.ow2.org/xwiki/bin/view/Main/ReliableJMS_Transport_CXF
 This illustrates how the

 And the errors handling that is working with all kind of JVM crash :
 http://wiki.jonas.ow2.org/xwiki/bin/download/Main/ReliableJMS_Transport_CXF/cxf-reliablejms-execution-flow-simple-failure-english.png

 There are integration tests included in this transport that are launched
 through our continous integration tool on http://bamboo.ow2.org
 For now, they're using JOnAS as Java EE server as we need a JTA manager and
 we test both EJB MDB and Spring MDP providers.

 To sum up, is there an interest in CXF to integrate this transport ? What
 kind of changes need to be done, etc.
 Also I hope to get some feedback about this protocol.

 Regards,

 Florent

Re: 2.4.1likely in a day or 3

[Benson Margulies]

Uh, Oh, I seem to have missed in in the tidal wave of incubator email.

On Mon, Jun 6, 2011 at 11:17 AM, Sergey Beryozkin sberyoz...@gmail.com wrote:
 Hi

 On Mon, Jun 6, 2011 at 4:08 PM, Daniel Kulp dk...@apache.org wrote:

 The vote for WSS4J 1.6.1 has been started (hint: people with binding WS 
 votes,
 please vote  :-)   )  which is really the last holdup for 2.4.1.    Thus, 
 once
 the vote passes, I'd like to get 2.4.1 built and out as it fixes a TON of
 issues.    I think we're over 85 issues already.

 If you have any more fixes/changes to get it, please get them in ASAP or let
 me know what's going on.    :-)

 I'm still working on wiring in CXF JAX-RS clients with various
 failover-related strategies, and particularly, I'd like a locator-like
 strategies be supported. I think I'll need a couple of days. I guess I
 won't be able a number of queries/issues reported recently against the
 JAX-RS frontend, but I'd like to get some completion for the failover
 feature work...

 Thanks, Sergey

 Thanks!

 --
 Daniel Kulp
 dk...@apache.org
 http://dankulp.com/blog
 Talend - http://www.talend.com




 --
 Sergey Beryozkin

 Application Integration Division of Talend
 http://sberyozkin.blogspot.com

Haven't been able to complete a build recently

[Benson Margulies]

this is after an mvn clean.

[INFO] 
[INFO] Total time: 3:12.588s
[INFO] Finished at: Fri May 06 16:44:20 EDT 2011
[INFO] Final Memory: 75M/175M
[INFO] 
[ERROR] Failed to execute goal
org.apache.cxf:cxf-corbatools-maven-plugin:2.4.1-SNAPSHOT:wsdl2idl
(generate-test-sources) on project cxf-systests-uncategorized:
java.lang.ClassCastException:
org.apache.cxf.binding.corba.wsdl.CorbaTypeImpl cannot be cast to
org.apache.cxf.binding.corba.wsdl.Fixed - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn goals -rf :cxf-systests-uncategorized
/Users/benson/asf/cxf
/Users/benson/asf/cxf

Re: cxf aegis stackoverflowerror

[Benson Margulies]

Aegis does not support circular references. You'll have to use jaxb or
something else.

On Fri, Apr 29, 2011 at 10:42 AM, Mpango Jonathan mpik...@yahoo.com wrote:
 if its a circular reference issue how can i go about it?




 Benson Margulies bimargulies@... writes:


 A circular reference would be the easiest  explanation of this, yes

 On Fri, Apr 29, 2011 at 10:25 AM, mpiksjo mpiksjo@... wrote:
  Am getting the following exception at the client side. am using cxf 2.3.0
 and
  aegis for data binding.
  Could i be having a circular reference in my pojo code? please help me.
 
 
  soap envelope received at client is incomplete as shown
 
  soap envelope
  ===
 
  soap:Envelope
  xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Body
 ns1:getUsersResponse
  xmlns:ns1=http://service.cxf.server.openxdata.org/;returnns2:User
  xmlns:ns2=http://model.admin.cxf.server.openxdata.org;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:type=ns2:Userns2:changedBy xsi:nil=true/ns2:creato
 
  exception
  ===
 
  Exception in thread main java.lang.StackOverflowError
         at java.util.Arrays.fill(Arrays.java:2465)
         at
 
 com.ctc.wstx.sr.NsAttributeCollector.resolveNamespaces(NsAttributeCollector.java
 :219)
         at
 
 com.ctc.wstx.sr.NsInputElementStack.resolveAndValidateElement(NsInputElementStac
 k.java:351)
         at
 
 com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2923)
         at
  com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2783)
         at
 com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1048)
         at
 
 org.apache.cxf.staxutils.DepthXMLStreamReader.next(DepthXMLStreamReader.java:220
 )
         at
 
 org.apache.cxf.aegis.xml.stax.ElementReader.checkHasMoreChildReaders(ElementRead
 er.java:185)
         at
 
 org.apache.cxf.aegis.xml.stax.ElementReader.hasMoreElementReaders(ElementReader.
 java:145)
         at
 org.apache.cxf.aegis.type.basic.BeanType.readObject(BeanType.java:154)
         at
 org.apache.cxf.aegis.type.basic.BeanType.readObject(BeanType.java:173)
         at
 org.apache.cxf.aegis.type.basic.BeanType.readObject(BeanType.java:173)
         at
 org.apache.cxf.aegis.type.basic.BeanType.readObject(BeanType.java:173)
         at
 org.apache.cxf.aegis.type.basic.BeanType.readObject(BeanType.java:173)
         at
 org.apache.cxf.aegis.type.basic.BeanType.readObject(BeanType.java:173)
         at
 org.apache.cxf.aegis.type.basic.BeanType.readObject(BeanType.java:173)
         at
 org.apache.cxf.aegis.type.basic.BeanType.readObject(BeanType.java:173)
         at
 org.apache.cxf.aegis.type.basic.BeanType.readObject(BeanType.java:173)
         at
 org.apache.cxf.aegis.type.basic.BeanType.readObject(BeanType.java:173)
         at
 org.apache.cxf.aegis.type.basic.BeanType.readObject(BeanType.java:173)
         at
 org.apache.cxf.aegis.type.basic.BeanType.readObject(BeanType.java:173)
         at
 org.apache.cxf.aegis.type.basic.BeanType.readObject(BeanType.java:173)
         at
 org.apache.cxf.aegis.type.basic.BeanType.readObject(BeanType.java:173)
         at
 org.apache.cxf.aegis.type.basic.BeanType.readObject(BeanType.java:173)--
  View this message in context: http://cxf.547215.n5.nabble.com/cxf-aegis-
 stackoverflowerror-tp4358799p4358799.html
  Sent from the cxf-issues mailing list archive at Nabble.com.
 

CXF trying to initialize while shutting down.

[Benson Margulies]

2011-04-29 12:04:44,320 [main] WARN
org.springframework.web.context.support.XmlWebApplicationContext -
Exception thrown from ApplicationListener handling ContextClosedEvent
org.springframework.beans.factory.BeanCreationNotAllowedException:
Error creating bean with name 'cxf': Singleton bean creation not
allowed while the singletons of this factory are in destruction (Do
not request a bean from a BeanFactory in a destroy method
implementation!)
at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:209)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:288)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
at 
org.springframework.context.event.AbstractApplicationEventMulticaster.getApplicationListeners(AbstractApplicationEventMulticaster.java:148)
at 
org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:86)
at 
org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:303)
at 
org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1007)
at 
org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:970)
at org.apache.cxf.bus.spring.SpringBus.destroyBeans(SpringBus.java:96)
at org.apache.cxf.bus.CXFBusImpl.shutdown(CXFBusImpl.java:196)
at org.apache.cxf.bus.CXFBusImpl.shutdown(CXFBusImpl.java:178)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.springframework.beans.factory.support.DisposableBeanAdapter.invokeCustomDestroyMethod(DisposableBeanAdapter.java:273)
at 
org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:199)
at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:487)
at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:463)
at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:431)
at 
org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:1048)
at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:433)
at 
org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:276)
at 
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:197)
at 
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47)
at 
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4135)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4630)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:785)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:445)
at org.apache.catalina.startup.Embedded.start(Embedded.java:825)
at 
org.codehaus.mojo.tomcat.AbstractRunMojo.startContainer(AbstractRunMojo.java:558)
at 
org.codehaus.mojo.tomcat.AbstractRunMojo.execute(AbstractRunMojo.java:255)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at 

Re: CXF trying to initialize while shutting down.

[Benson Margulies]

To create this, I had to launch a service with the
tomcat-maven-plugin, and hit an (apparent) bug in it. I think we
should let it go by.

On Fri, Apr 29, 2011 at 1:34 PM, Daniel Kulp dk...@apache.org wrote:

 Is this easily reproduced with a test case?

 It's strange as it says it's trying to create a bean named cxf, but I would
 have expected that the SpringBus from line;
  org.apache.cxf.bus.spring.SpringBus.destroyBeans(SpringBus.java:96)

 is the bean named cxf and thus would already be created (and is in the
 process of being shutdown).

 It's a strange trace.

 Dan


 On Friday, April 29, 2011 12:07:08 PM Benson Margulies wrote:
 2011-04-29 12:04:44,320 [main] WARN
 org.springframework.web.context.support.XmlWebApplicationContext -
 Exception thrown from ApplicationListener handling ContextClosedEvent
 org.springframework.beans.factory.BeanCreationNotAllowedException:
 Error creating bean with name 'cxf': Singleton bean creation not
 allowed while the singletons of this factory are in destruction (Do
 not request a bean from a BeanFactory in a destroy method
 implementation!)
       at
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.get
 Singleton(DefaultSingletonBeanRegistry.java:209) at
 org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(Ab
 stractBeanFactory.java:288) at
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abst
 ractBeanFactory.java:194) at
 org.springframework.context.event.AbstractApplicationEventMulticaster.getA
 pplicationListeners(AbstractApplicationEventMulticaster.java:148) at
 org.springframework.context.event.SimpleApplicationEventMulticaster.multic
 astEvent(SimpleApplicationEventMulticaster.java:86) at
 org.springframework.context.support.AbstractApplicationContext.publishEven
 t(AbstractApplicationContext.java:303) at
 org.springframework.context.support.AbstractApplicationContext.doClose(Abs
 tractApplicationContext.java:1007) at
 org.springframework.context.support.AbstractApplicationContext.close(Abstr
 actApplicationContext.java:970) at
 org.apache.cxf.bus.spring.SpringBus.destroyBeans(SpringBus.java:96) at
 org.apache.cxf.bus.CXFBusImpl.shutdown(CXFBusImpl.java:196)
       at org.apache.cxf.bus.CXFBusImpl.shutdown(CXFBusImpl.java:178)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
 39) at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
 pl.java:25) at java.lang.reflect.Method.invoke(Method.java:597)
       at
 org.springframework.beans.factory.support.DisposableBeanAdapter.invokeCust
 omDestroyMethod(DisposableBeanAdapter.java:273) at
 org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(Di
 sposableBeanAdapter.java:199) at
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.des
 troyBean(DefaultSingletonBeanRegistry.java:487) at
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.des
 troySingleton(DefaultSingletonBeanRegistry.java:463) at
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.des
 troySingletons(DefaultSingletonBeanRegistry.java:431) at
 org.springframework.context.support.AbstractApplicationContext.destroyBean
 s(AbstractApplicationContext.java:1048) at
 org.springframework.context.support.AbstractApplicationContext.refresh(Abs
 tractApplicationContext.java:433) at
 org.springframework.web.context.ContextLoader.createWebApplicationContext(
 ContextLoader.java:276) at
 org.springframework.web.context.ContextLoader.initWebApplicationContext(Co
 ntextLoader.java:197) at
 org.springframework.web.context.ContextLoaderListener.contextInitialized(C
 ontextLoaderListener.java:47) at
 org.apache.catalina.core.StandardContext.listenerStart(StandardContext.jav
 a:4135) at
 org.apache.catalina.core.StandardContext.start(StandardContext.java:4630)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
 at org.apache.catalina.core.StandardHost.start(StandardHost.java:785) at
 org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at
 org.apache.catalina.core.StandardEngine.start(StandardEngine.java:445) at
 org.apache.catalina.startup.Embedded.start(Embedded.java:825)
       at
 org.codehaus.mojo.tomcat.AbstractRunMojo.startContainer(AbstractRunMojo.ja
 va:558) at
 org.codehaus.mojo.tomcat.AbstractRunMojo.execute(AbstractRunMojo.java:255)
 at
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMana
 ger.java:490) at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLi
 fecycleExecutor.java:694) at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecyc
 le(DefaultLifecycleExecutor.java:556) at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLif
 ecycleExecutor.java:535) at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFa
 ilures

Can't run corba unit tests?

[Benson Margulies]

[ERROR]
[ERROR] Please refer to
/Users/benson/asf/cxf/tools/corba/target/surefire-reports for the
individual test results.
[ERROR] - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn goals -rf :cxf-tools-corba

Re: Can't run corba unit tests?

[Benson Margulies]

More detail:

Failed tests:
  
testFixedBindingGeneration(org.apache.cxf.tools.corba.processors.WSDLToCorbaBindingTest):
expected:[fixed_1] but was:[any]
  
testCORBABindingGeneration(org.apache.cxf.tools.corba.processors.WSDLToCorbaBindingTest):
expected:{http://cxf.apache.org/bindings/corba}any but
was:{http://cxf.apache.org/bindings/corba}string

Tests in error:
  
testSequenceType(org.apache.cxf.tools.corba.processors.WSDLToCorbaBindingTest):
org.apache.cxf.binding.corba.wsdl.CorbaTypeImpl cannot be cast to
org.apache.cxf.binding.corba.wsdl.Fixed



On Mon, Apr 25, 2011 at 6:22 PM, Benson Margulies bimargul...@gmail.com wrote:
 [ERROR]
 [ERROR] Please refer to
 /Users/benson/asf/cxf/tools/corba/target/surefire-reports for the
 individual test results.
 [ERROR] - [Help 1]
 [ERROR]
 [ERROR] To see the full stack trace of the errors, re-run Maven with
 the -e switch.
 [ERROR] Re-run Maven using the -X switch to enable full debug logging.
 [ERROR]
 [ERROR] For more information about the errors and possible solutions,
 please read the following articles:
 [ERROR] [Help 1]
 http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
 [ERROR]
 [ERROR] After correcting the problems, you can resume the build with the 
 command
 [ERROR]   mvn goals -rf :cxf-tools-corba

Re: Can't run corba unit tests?

[Benson Margulies]

Ryan, this isnt' a fastinstall or an eclipse issue, it's the unit tests failing?

On Mon, Apr 25, 2011 at 8:56 PM, Ryan Zoerner ryanzoer...@gmail.com wrote:
 Benson,

 When you set up the project in eclipse. When you typed 'mvn install
 -Pfastinstall -fn', there was an error in the corba setup. At the time, I
 had thought that I needed to put the CORBA plugin into eclipse, so I pulled
 it down from online, but that was not the error. You actually needed to run
 the command that I just listed twice, for whatever reason. I think that that
 might fix your problem.

 Ryan


 On Mon, Apr 25, 2011 at 5:32 PM, Benson Margulies 
 bimargul...@gmail.comwrote:

 More detail:

 Failed tests:

  testFixedBindingGeneration(org.apache.cxf.tools.corba.processors.WSDLToCorbaBindingTest):
 expected:[fixed_1] but was:[any]

  testCORBABindingGeneration(org.apache.cxf.tools.corba.processors.WSDLToCorbaBindingTest):
 expected:{http://cxf.apache.org/bindings/corba}any but
 was:{http://cxf.apache.org/bindings/corba}string

 Tests in error:

  testSequenceType(org.apache.cxf.tools.corba.processors.WSDLToCorbaBindingTest):
 org.apache.cxf.binding.corba.wsdl.CorbaTypeImpl cannot be cast to
 org.apache.cxf.binding.corba.wsdl.Fixed



 On Mon, Apr 25, 2011 at 6:22 PM, Benson Margulies bimargul...@gmail.com
 wrote:
  [ERROR]
  [ERROR] Please refer to
  /Users/benson/asf/cxf/tools/corba/target/surefire-reports for the
  individual test results.
  [ERROR] - [Help 1]
  [ERROR]
  [ERROR] To see the full stack trace of the errors, re-run Maven with
  the -e switch.
  [ERROR] Re-run Maven using the -X switch to enable full debug logging.
  [ERROR]
  [ERROR] For more information about the errors and possible solutions,
  please read the following articles:
  [ERROR] [Help 1]
  http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
  [ERROR]
  [ERROR] After correcting the problems, you can resume the build with the
 command
  [ERROR]   mvn goals -rf :cxf-tools-corba
 

Re: GSoC. CXF-48 / WSDL 2.0 Support

[Benson Margulies]

In my opinion, making the schema system pluggable would be pretty
painful. I wonder if we could just push woden to 2.0? Or does that run
afoul of the state of Axis?

If only we were using OSGi for all of this ()

On Thu, Apr 14, 2011 at 8:57 PM, Daniel Kulp dk...@apache.org wrote:
 On Thursday 14 April 2011 1:38:57 AM sagara wrote:
 Pointing out a different aspect, did you identify any utility to generate
 WSDL 2.0 model ? Apache Woden [1] can be a good candidate.

 Honestly, Apache Woden is the only one I'm really familliar with at all.
 There is EasyWSDL at OW2, but I've never really looked too in depth at it.


 But better to aware with incompatibilities at the beginning , AFAIK Woden
 and CXF use incompatible versions of XMLSchema also Woden use  Commons
 logging  API while CXF use Java Util logging and SLF4J.

 The logging thing is relatively irrelvant.  Spring uses commons-logging as
 well so we do ship it.   That saif, shipping the SLF4J commons-logging api jar
 thing might be a good idea instead.

 The XmlSchema thing is the bigger concert.  We may need to submit patches
 there to make the schema system more  pluggable.   I can definitely help out
 there as well.

 Dan



 [1] - http://ws.apache.org/woden/

 --
 View this message in context:
 http://cxf.547215.n5.nabble.com/GSoC-CXF-48-WSDL-2-0-Support-tp4296871p430
 2240.html Sent from the cxf-dev mailing list archive at Nabble.com.

 --
 Daniel Kulp
 dk...@apache.org
 http://dankulp.com/blog
 Talend - http://www.talend.com

Re: [VOTE] Release Apache CXF 2.3.4

[Benson Margulies]

+1

On Wed, Apr 13, 2011 at 5:36 AM, David Zhang zhng...@hotmail.com wrote:
 +1

 I want to apologize:
 Yes, i found out the 2.3.4-Snapshot moved to tags ...
 I built and testet it and everything works nice, including UT in encrypted
 messages.

 Thank you for this excellent work!
 David

 -Ursprüngliche Nachricht- From: zhng...@hotmail.com
 Sent: Wednesday, April 13, 2011 10:13 AM
 To: dev@cxf.apache.org
 Subject: Re: [VOTE] Release Apache CXF 2.4.0

 -1

 i just did an update to see if the patch sergey did for me is still working.
 But the build fails at
 Apache CXF JAX-WS System Tests  FAILURE

 [ERROR] Failed to execute goal
 org.apache.cxf:cxf-codegen-plugin:2.3.5-SNAPSHOT:wsdl2java
 (generate-test-sources) on project cxf-systests-jaxws:
 org.apache.xerces.impl.dv.DVFactoryException: DTD factory class
 org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from
 DTDDVFactory. - [Help 1]

 I am interested in this build because 2 days ago a build succeeded but the
 patch did not work anymore. I suddenly got an error at runtime telling me
 the message expired. Some days before this sergey commited a patch which was
 working well for me.

 David


 -Ursprüngliche Nachricht- From: Sergey Beryozkin
 Sent: Wednesday, April 13, 2011 10:57 AM
 To: dev@cxf.apache.org
 Subject: Re: [VOTE] Release Apache CXF 2.3.4

 +1

 Cheers, Sergey

 On Wed, Apr 13, 2011 at 8:42 AM, Daniel Kulp dk...@apache.org wrote:



 We've resolved over 59 issues since 2.3.3 and thus is time for a release.

 List of issues:


 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12316074

 The Maven staging areas are at:
 https://repository.apache.org/content/repositories/orgapachecxf-084

 The distributions are in:


 https://repository.apache.org/content/repositories/orgapachecxf-084/org/apache/cxf/apache-cxf/2.3.4/

 This release is tagged at:
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.4


 This vote will be open for at least 72 hours.

 Here is my +1.


 --
 Daniel Kulp
 dk...@apache.org
 http://dankulp.com/blog
 Talend - http://www.talend.com

Re: [VOTE] Release Apache CXF 2.4.0

[Benson Margulies]

+1

On Wed, Apr 13, 2011 at 5:36 AM, Dennis Sosnoski d...@sosnoski.com wrote:
 +1

  - Dennis


 On 04/13/2011 07:51 PM, Daniel Kulp wrote:
 It's been about 6 months since the release of 2.3 and we've done a fantastic
 job implenting new features  and cleaning up various parts of the code and
 integrating new versions of libraries like WSS4J, Neethi, XmlSchema, etc...
 that provide a good base for new features and enhancements going forward.   I
 think it's time to get 2.4.0 out there.


 List of issues:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12315386

 Migration guide:
 http://cxf.apache.org/docs/24-migration-guide.html

 The Maven staging areas are at:
 https://repository.apache.org/content/repositories/orgapachecxf-085/

 The distributions are in:
 https://repository.apache.org/content/repositories/orgapachecxf-085/org/apache/cxf/apache-cxf/2.4.0/

 This release is tagged at:
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.0

 Vote will be open for at least 72 hours.

 Here is my +1.

Re: [VOTE] CXF build-utils 2.3.2 (take 2)

[Benson Margulies]

+1

On Sat, Apr 9, 2011 at 10:34 AM, Sergey Beryozkin sberyoz...@gmail.com wrote:
 +1

 On 4/8/11, Daniel Kulp dk...@apache.org wrote:

 I'd like to call a vote on this just to get it out of the way to make the
 releases next week a bit easier.

 There are three changes:
 * Update the eclipse checkstyle/pmd rules so that the new  gwt generated
 code
 doesn't cause all kinds of warnings in eclipse
 * Allow use of j.u.l.Logger in the generated Services as they cannot depend
 on
 CXF specific code
 * Update the notice suppliments to include entries for the new dependencies
 for the validation related things that Benson added.   I checked the
 notices/license things on 2.4 and 2.3.x to make sure everything is OK.

 Tag:
 http://svn.apache.org/repos/asf/cxf/build-utils/tags/cxf-build-utils-2.3.2/

 Maven staging repo:
 https://repository.apache.org/content/repositories/orgapachecxf-073/

 This vote will stay open for  72 hours.

 Here is my +1.


 --
 Daniel Kulp
 dk...@apache.org
 http://dankulp.com/blog
 Talend - http://www.talend.com



 --
 Sergey Beryozkin

 Application Integration Division of Talend http://www.talend.com
 http://sberyozkin.blogspot.com

Re: [VOTE] Aki Yoshida for CXF committer

[Benson Margulies]

+1

On Wed, Apr 6, 2011 at 12:19 PM, Sergey Beryozkin sberyoz...@gmail.com wrote:
 +1

 Cheers, Sergey

 On Wed, Apr 6, 2011 at 5:03 PM, Daniel Kulp dk...@apache.org wrote:


 I'd like to call a vote on adding Aki Yoshida as a committer for CXF.

 Aki has been active with CXF for almost a year now.   In that time, he's
 submitted patches to 8 JIRA issues, including one that had been logged
 several
 years ago.   The two main areas he's contributed to are in the Management
 stuff and the WS-RM stuff which are areas that are not easy to jump right
 in
 and are areas that we don't have enough experts in.   That makes those
 contributions that much more valuable.

 He's also been very helpful on the mailing lists, answering user questions
 as
 well as having constructive design discussions on the dev list.

 I think he'd be a valuable addition to CXF.

 Here is my +1.   Vote open for 72 hours.


 --
 Daniel Kulp
 dk...@apache.org
 http://dankulp.com/blog
 Talend - http://www.talend.com




 --
 Sergey Beryozkin

 Application Integration Division of Talend http://www.talend.com
 http://sberyozkin.blogspot.com

Can't compile trunk?

[Benson Margulies]

I just got a brand new, completely clean ,tree, and ran into the following.

[INFO] Total time: 15.717s (Wall Clock)
[INFO] Finished at: Fri Apr 01 11:08:56 EDT 2011
[INFO] Final Memory: 33M/85M
[INFO] 
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
(default-compile) on project cxf-api: Compilation failure: Compilation
failure:
[ERROR] 
/Users/benson/asf/cxf/api/src/main/java/org/apache/cxf/ws/policy/AssertionInfoMap.java:[108,74]
incompatible types
[ERROR] found   :
java.util.Iteratorjava.util.Listorg.apache.neethi.PolicyComponent
[ERROR] required:
java.util.Iteratorjava.util.Listorg.apache.neethi.Assertion
[ERROR] 
/Users/benson/asf/cxf/api/src/main/java/org/apache/cxf/ws/policy/AssertionInfoMap.java:[130,71]
incompatible types
[ERROR] found   :
java.util.Iteratorjava.util.Listorg.apache.neethi.PolicyComponent
[ERROR] required:
java.util.Iteratorjava.util.Listorg.apache.neethi.Assertion
[ERROR] 
/Users/benson/asf/cxf/api/src/main/java/org/apache/cxf/ws/policy/builder/primitive/PrimitiveAssertion.java:[52,8]
cannot find symbol
[ERROR] symbol  : constructor
PrimitiveAssertion(javax.xml.namespace.QName,boolean,boolean,java.util.Mapjavax.xml.namespace.QName,java.lang.String)
[ERROR] location: class org.apache.neethi.builders.PrimitiveAssertion
[ERROR] - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn goals -rf :cxf-api

Re: Startup speed, XML, etc.....

[Benson Margulies]

I would offer +0.3 of a vote to now plan to call the next release 3.0
as a result of this.

On Fri, Mar 4, 2011 at 3:58 PM, Daniel Kulp dk...@apache.org wrote:



 On Friday 04 March 2011 3:47:55 PM Daniel Kulp wrote:
 I just committed the gigantic refactoring of the Spring bus stuff to base
 it on the  ExtensionManagerBus.   I'll describe it in a minute, but first
 the performanc result on my test case:

 Running test - 2.4.0-SNAPSHOT
 Setup: 29105 51/sec
 Invoke: 38174 39/sec
 Setup config: 39026 38/sec

 Compared to the 2.3.3:
  Running test - 2.3.3
  Setup: 49732 30/sec
  Invoke: 62276 24/sec
  Setup config: 56164 26/sec

 As you can see, it's quite a bit faster across the board now.   That's
 great. The code is also (IMO) a LOT simpler now.   We no longer have to
 modify both bus-extension.xml and cxf-extension-blah.xml files.    The
 extension loading is more unified.  The extension retrieval from the Bus
 is simpler and, for the most part, identical between the Spring and
 Non-Spring cases.    And the performance rocks.  :-)

 For the most part, it's simple to modify existing applications to work.
 Just remove all the imports for everything except META-INF/cxf/cxf.xml
 and META- INF/cxf/cxf-servlet.xml if you use a servlet.   However, there
 are a couple of other gotchas that I encountered:

 1) We had several files that did something like:

 bean id=cxf class= CXFBusImpl
      ... conifure some interceptors
 /bean

 That no longer works.   The proper way to do that has been to use the
 cxf:bus namespaced object.  It's been that way for a while.  Creating
 separate Bus's like that is just asking for having things become confused.
 I converted all the tests to do that properly.   You COULD potentially
 change that to:
 bean id=cxf class=org.apache.cxf.bus.spring.SpringBus
 but using cxf:bus is definitely the better way to go.   Directly
 instantiating and depending on internal impl classes and such is
 generally a bad idea.

 2)  depends-on and injections - since almost none of the CXF internal beans
 are now defined in the Spring context, you cannot really depend on them
 directly.   That's not a normal thing anyway.     The Bus is really the
 only thing that is in the context.

 In anycase, the rest was fairly simple.   If you do define beans in the
 spring config, they will override/replace the auto loaded stuff (just like
 before), the configurations stuff remains the same, etc    It just
 starts up a ton faster and uses a bit less memory.    :-)

 I definitely have some more testing to do, but I think it's a good start.

 Dan

 On Thursday 03 March 2011 5:01:58 PM Daniel Kulp wrote:
  I've done quite a bit of work now on trunk to speed up the normal use
  cases. With what's on trunk now, a normal JAX-WS client that doesn't
  include any spring config will get the extension bus instead.   With my
  lastest set of changes, a default extension bus now starts up without
  ANY XML parsing and very few beans and such created.   This is MUCH
  faster now.    I wrote a little benchmark based on the java-first-jaxws
  example (to avoid any WSDL related things) and depending on cxf-bundle
  to make
 
  sure we get EVERYTHING and then does:
      public static void doIteration(boolean invoke) {
 
          BusFactory.setThreadDefaultBus(null);
          BusFactory.setDefaultBus(null);
 
          Service service = Service.create(SERVICE_NAME);
          String endpointAddress = http://localhost:9000/helloWorld;;
          service.addPort(PORT_NAME,
 
                     SOAPBinding.SOAP11HTTP_BINDING, endpointAddress);
 
          if (invoke) {
 
              service.getPort(HelloWorld.class).sayHi(Hello);
 
          } else {
 
              service.getPort(HelloWorld.class);
 
          }
 
      }
 
  in a loop under 3 conditions:
  1) First is with invoke=false to basically time all the upfront setup
  costs. That includes creating the Bus, creating the Service, and then
  creating the Proxy.
 
  2) Then with invoke=true to include the additional stuff of creating the
  interceptor chains and conduits and doing a real invoke.
 
  3) Again with invoke=false, but this time with specifying a spring config
  file (cxf.xml).   This basically is the same as (1), but involves the
  spring Bus now.
 
  I then ran this with several versions of CXF.      Results are below.
  (first number is the # of ms for 1500 iterations, then it's
  iterations/sec)
 
  Basically, the Extension bus stuff is now a TON faster.  For 80% of the
  use cases, it's much faster.   I'm definitely excited about that.    The
  spring case slowed down a bit.  I'm not sure why.   I'll need to profile
  that a bit to figure it out.    In anycase, for standalone applications
  and cases where config is done through API's, this is quite a bit
  faster. As we start thinking about Blueprint and such, this can be
  important. Right now, the server side parts are all very spring based
  and thus won't benefit from this.
 
  :-(
 
  

Re: CXF + JSF blows up on tomcat

[Benson Margulies]

If you are running out of permgen space, add command line args to
tomcat to give it more permgen space.

On Wed, Mar 2, 2011 at 2:08 AM, Tanveer ul Islam
tanveer.aimfo...@gmail.com wrote:
 Hi CXF Developers,

 I have this strange issue and my timelines are tough :( I am using
 following versions of different tools  APIs:

 JDK 1.6.0_23
 Eclipse Helios/Indigo M4/Indigo M5 (Have tried on all of these)
 Tomcat 7.0.8
 CXF 2.3.3
 JSF 2.0.4
 Windows 7 (64-bit)

 What i do is just create a new 'Dynamic Web Project' and enable
 following facets:

 CXF 2.x Web Services = 1.0
 Dynamic Web Module = 3.0
 Java = 1.6
 JavaScript = 1.0
 JavaServer Faces = 2.0

 And then i try to add this project on Tomcat server and it blows up. Please
 find the error log attached with this email. Problem is why Tomcat is trying
 to load JAXB JXC 1.0 classes? CXF includes jaxb-xjc-2.2.1.1.jar... Though i
 did try to add those classes in the class-path, but still Tomcat fails with
 Permgen space error. I can not find a clue on Google, please help!
 Thanks | Regards,

 Tanveer ul Islam

 Senior Java Developer

 Aim-Force Software

Re: 2.4 later this month.....

[Benson Margulies]

How much further could we take the reduction of Spring/XML usage in
initialization?


On Tue, Mar 1, 2011 at 10:31 AM, Daniel Kulp dk...@apache.org wrote:

 I'm thinking of building 2.4 at some point later this month.

 Basically, it will have been about 6 months since 2.3 was release which is a
 pretty good amount of time.     In that time, we've integrated a couple of the
 GSoC projects, we've introduced some new features in the JAX-RS stuff, and
 we've integrated new  versions of XmlSchema, Neethi, and WSS4J which provide a
 lot of new functionality.   On the security front, the new SAML2 support in
 WSS4J and all the updates in CXF to support that is huge.   Also, a lot of
 testing has gone into the WS-Security/WS-Trust stuff, particularly with other
 STS providers, to help enhance the interopability.

 Right now, I see two risks:
 1) WSS4J - we obviously need a release of WSS4J 1.6.   Colm has a good handle
 on it with a beta out there for people to look at.  However, I'm not sure if
 the Axis/Rampart people will get a chance to look at it.

 2) Neethi - we need a release of this as well.   Andreas has already upgraded
 all of Axis2 to using the new Neethi snapshots.    I've gotten a lot of
 feedback from them already, bugs encountered, fixed, etc

 Thoughts or additional comments?

 --
 Daniel Kulp
 dk...@apache.org
 http://dankulp.com/blog
 Talend - http://www.talend.com

Re: When do we drop Java 5 support?

[Benson Margulies]

I am opposed to dropping 1.5. There are a surprising number of people
out there who have barely bothered to stop requiring *1.4*.  We could
put the animal sniffer to work to help head off any unfortunate
accidental dependencies on 1.6 APIs.

On Wed, Feb 23, 2011 at 7:53 AM, Glen Mazza gma...@talend.com wrote:
 Well, older versions of CXF--2.3.x and earlier--of course would perpetually
 support JRE 5.0.  It's just a question of moving forward, it looks like
 right now 2.4 will still support 5.0 and maybe we'll switch to 6.0 minimum
 in CXF 2.5.  I didn't know about royalty concerns  (do you have a link for
 that--can't immediately find anything off Google), but I'm sure there would
 also be some fears of running on an unmaintained JRE.  Although some
 wish/need to remain on JRE 5.0 (and hence CXF 2.3), there's also a
 counterargument, that for information security reasons, newer releases of
 CXF shouldn't allow itself to be run on unmaintained JRE's, similar to the
 way responsible builders will not put up homes on unsafe land/foundations
 even if business is lost as a result.

 Glen

 On 2/22/2011 9:27 PM, Fred Dushin wrote:

 Speaking from the field, you do not want to drop 1.5.  There are
 organization out there that are not moving to 1.6 (or are moving very
 slowly) out of fear of Oracle's collecting royalties under the 1.6
 redistribution terms.

 CXF is meant to be an embedded library.  If you drop support for 1.5, you
 will find users who will not upgrade.  At a minimum, CXF should support 1.5
 on one of its branches.

 Not everyone out there has the luxury of being on the bleeding edge.

 -Fred

 On Feb 22, 2011, at 11:17 AM, Daniel Kulp wrote:

 On Tuesday 22 February 2011 3:45:44 AM Christian Schneider wrote:

 Hi all,

 now that camel dropped Java 5 I am asking myself when will we also drop
 support for Java 5 in CXF? As CXF 2.4.0 allows some bigger changes than
 a minor version we could do that in my opinion.

 Well, I guess the question is:  what is the cost of supporting Java 5
 compared
 to the cost of dropping it?   For Camel, the cost was pretty high as they
 had
 some dependencies for various components that required Java6.   Thus, you
 really couldn't do complete Camel builds with Java5 anyway.

 CXF is a bit different.   RIGHT NOW, we don't have anything anyplace that
 requires Java 6.   In generaly, the only cost we have is the occasional
 @Override annotation that Eclipse likes to stick on everything causing a
 Jenkins build break and some slight additional complexity in the poms.
 Thus,
 the cost of supporting Java5 for us is pretty low, right now.

 Dropping support for Java5 would cause issues with SOME people,
 especially
 those trying to use CXF in some of the older App servers.    Also, to be
 honest, the new JAX-WS and JAXB 2.2 stuff in CXF works a TON better with
 Java5
 than with Java6 due to the endorsed crap.    Dropping support for Java5
 would
 mean much of the JAXWS 2.2/JAXB 2.2 would not be tested on a day to day
 basis
 as that stuff is currently only tested when run on Java5.    Thus, there
 is a
 big cost of dropping it just from a testing and support standpoint.
 Getting
 that stuff to run on Java6 properly would likely require a lot more
 configuration in the poms, updates to our plugins, likely updates to some
 of
 the Maven plugins, etc   Basically, it's not easy.

 Thus, in my opinon, I don't think *right now* is the right time to drop
 support for Java 5.   Maybe for 2.5, but likely not for 2.4.   That said,
 I
 could potentially be convinced either way.   :-)

 --
 Daniel Kulp
 dk...@apache.org
 http://dankulp.com/blog
 Talend - http://www.talend.com

Re: When do we drop Java 5 support?

[Benson Margulies]

Glen,

While I'm sympathetic to your general argument, I don't think it's
especially applicable here.

Adopting 1.6 means allowing approximately 5 new functions in the
Arrays class. (OK, a slight exaggeration.) Really, the practical
impact of 1.6 is tiny. No one working on CXF is deprived of any
interesting learning opportunities or functionality by continuing to
stick to 1.5.



--benson

Re: Abusive/harrassing off-list emails

[Benson Margulies]

I plead with all and sundry to back off from this unedifying spectacle.

If someone posts something on a public list you don't like, start by
politely calling it out on the dev list. If you don't get an answer
that satisfies you, head for private@. If you think something truly
awful is going on, or you aren't a PMC member, ping Dan.

I, for one, am going to try really hard to pretend that I didn't read
any of this, since it makes my eyeballs hurt.