[jira] Created: (CXF-2088) Wrong serialisation order of elements when using Aegis databinding.
Wrong serialisation order of elements when using Aegis databinding. --- Key: CXF-2088 URL: https://issues.apache.org/jira/browse/CXF-2088 Project: CXF Issue Type: Bug Components: Aegis Databinding Affects Versions: 2.1.4 Reporter: Christofer Dutz In my current case I hava * an abstract Java class "AbstractDatabaseObject" defining a property "id". * an abstract Java class "Credential" which extends "AbstractDatabaseObject" and defines a property "name" * a concrete Java class "UsernamePasswordCredential" which extends "Credential" and defines properties "username" and "password" All schemas are created to my greates satisfaction (Great Job!). Unfortunately the serialisation order when using Aegis databinding (don't know if its the same using others) is the wrong way around. Instead of getting: 306ce816-01b7-11de-8d92-8d4df6b73eb1 dsfgsdfgs dsfsfdg sdsdfgsdfg I get: dsfsfdg sdsdfgsdfg dsfgsdfgs 306ce816-01b7-11de-8d92-8d4df6b73eb1 Which my Flex client complains about. I'll try to whip up a patch fixing this issue today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2088) Wrong serialisation order of elements when using Aegis databinding.
[ https://issues.apache.org/jira/browse/CXF-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christofer Dutz updated CXF-2088: - Attachment: BeanType.java > Wrong serialisation order of elements when using Aegis databinding. > --- > > Key: CXF-2088 > URL: https://issues.apache.org/jira/browse/CXF-2088 > Project: CXF > Issue Type: Bug > Components: Aegis Databinding >Affects Versions: 2.1.4 >Reporter: Christofer Dutz > Attachments: BeanType.java > > > In my current case I hava > * an abstract Java class "AbstractDatabaseObject" defining a property "id". > * an abstract Java class "Credential" which extends "AbstractDatabaseObject" > and defines a property "name" > * a concrete Java class "UsernamePasswordCredential" which extends > "Credential" and defines properties "username" and "password" > All schemas are created to my greates satisfaction (Great Job!). > Unfortunately the serialisation order when using Aegis databinding (don't > know if its the same using others) is the wrong way around. > Instead of getting: > > 306ce816-01b7-11de-8d92-8d4df6b73eb1 > dsfgsdfgs > dsfsfdg > sdsdfgsdfg > > I get: > > dsfsfdg > sdsdfgsdfg > dsfgsdfgs > 306ce816-01b7-11de-8d92-8d4df6b73eb1 > > Which my Flex client complains about. > I'll try to whip up a patch fixing this issue today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2088) Wrong serialisation order of elements when using Aegis databinding.
[
https://issues.apache.org/jira/browse/CXF-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679142#action_12679142
]
Christofer Dutz commented on CXF-2088:
--
All that has to be done to resonve this issue, is to change the order of two
code fragments in the method writeObjectInternal
Here the blocks:
for (Iterator itr = inf.getElements(); itr.hasNext();) {
...
}
and
if (inf.isExtension()) {
...
}
simply have to be swapped to output the extended type first.
> Wrong serialisation order of elements when using Aegis databinding.
> ---
>
> Key: CXF-2088
> URL: https://issues.apache.org/jira/browse/CXF-2088
> Project: CXF
> Issue Type: Bug
> Components: Aegis Databinding
>Affects Versions: 2.1.4
>Reporter: Christofer Dutz
> Attachments: BeanType.java
>
>
> In my current case I hava
> * an abstract Java class "AbstractDatabaseObject" defining a property "id".
> * an abstract Java class "Credential" which extends "AbstractDatabaseObject"
> and defines a property "name"
> * a concrete Java class "UsernamePasswordCredential" which extends
> "Credential" and defines properties "username" and "password"
> All schemas are created to my greates satisfaction (Great Job!).
> Unfortunately the serialisation order when using Aegis databinding (don't
> know if its the same using others) is the wrong way around.
> Instead of getting:
>
> 306ce816-01b7-11de-8d92-8d4df6b73eb1
> dsfgsdfgs
> dsfsfdg
> sdsdfgsdfg
>
> I get:
>
> dsfsfdg
> sdsdfgsdfg
> dsfgsdfgs
> 306ce816-01b7-11de-8d92-8d4df6b73eb1
>
> Which my Flex client complains about.
> I'll try to whip up a patch fixing this issue today.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-2089) Sign before encrypt throws a ClassCastException
Sign before encrypt throws a ClassCastException --- Key: CXF-2089 URL: https://issues.apache.org/jira/browse/CXF-2089 Project: CXF Issue Type: Bug Affects Versions: 2.2 Reporter: Eamonn Dwyer Fix For: 2.2 The UX ws-sec 11 test fails in the server side with the following exception INFO: Interceptor has thrown exception, unwinding now org.apache.cxf.interceptor.Fault: java.util.ArrayList at org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.doSignBeforeEncrypt(SymmetricBindingHandler.java:380) at org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.handleBinding(SymmetricBindingHandler.java:113) at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:131) at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:1) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236) at org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:74) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:89) at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:302) at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:265) at org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:729) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) Caused by: java.lang.ClassCastException: java.util.ArrayList at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.assertSupportingTokens(AbstractBindingBuilder.java:370) at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.assertSupportingTokens(AbstractBindingBuilder.java:1343) at org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.doSignBeforeEncrypt(SymmetricBindingHandler.java:331) ... 21 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2089) Sign before encrypt throws a ClassCastException
[ https://issues.apache.org/jira/browse/CXF-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eamonn Dwyer updated CXF-2089: -- Attachment: Mar05.patch Attaching possible fix for this issue > Sign before encrypt throws a ClassCastException > --- > > Key: CXF-2089 > URL: https://issues.apache.org/jira/browse/CXF-2089 > Project: CXF > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Eamonn Dwyer > Fix For: 2.2 > > Attachments: Mar05.patch > > > The UX ws-sec 11 test fails in the server side with the following exception > INFO: Interceptor has thrown exception, unwinding now > org.apache.cxf.interceptor.Fault: java.util.ArrayList > at > org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.doSignBeforeEncrypt(SymmetricBindingHandler.java:380) > at > org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.handleBinding(SymmetricBindingHandler.java:113) > at > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:131) > at > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:1) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236) > at > org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:74) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:89) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:302) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:265) > at > org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:729) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) > Caused by: java.lang.ClassCastException: java.util.ArrayList > at > org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.assertSupportingTokens(AbstractBindingBuilder.java:370) > at > org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.assertSupportingTokens(AbstractBindingBuilder.java:1343) > at > org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.doSignBeforeEncrypt(SymmetricBindingHandler.java:331) > ... 21 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-1477) Integrate somehow with Hibernate to avoid LazyInitializationException errors
[ https://issues.apache.org/jira/browse/CXF-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Ross updated CXF-1477: Attachment: AbstractHibernateAccessorPhaseInterceptor.java > Integrate somehow with Hibernate to avoid LazyInitializationException errors > > > Key: CXF-1477 > URL: https://issues.apache.org/jira/browse/CXF-1477 > Project: CXF > Issue Type: Improvement > Components: Bus >Affects Versions: 2.0.4 > Environment: Ubuntu Feisty Fawn (7.04) >Reporter: Leandro > Attachments: AbstractHibernateAccessorPhaseInterceptor.java > > > Using Hibernate as a DAO layer will end in LazyInitializationException errors. > I've tried to define OpenSessionInView filter and mapping it to the same > address as the web service, but with no luck. > The current workaround is to set the collection with the property > lazy="false", which is not the best solution. > I'll try to build a tiny example to demonstrate it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-1477) Integrate somehow with Hibernate to avoid LazyInitializationException errors
[ https://issues.apache.org/jira/browse/CXF-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Ross updated CXF-1477: Attachment: HibernateOutInterceptor.java > Integrate somehow with Hibernate to avoid LazyInitializationException errors > > > Key: CXF-1477 > URL: https://issues.apache.org/jira/browse/CXF-1477 > Project: CXF > Issue Type: Improvement > Components: Bus >Affects Versions: 2.0.4 > Environment: Ubuntu Feisty Fawn (7.04) >Reporter: Leandro > Attachments: AbstractHibernateAccessorPhaseInterceptor.java, > HibernateInInterceptor.java, HibernateOutInterceptor.java > > > Using Hibernate as a DAO layer will end in LazyInitializationException errors. > I've tried to define OpenSessionInView filter and mapping it to the same > address as the web service, but with no luck. > The current workaround is to set the collection with the property > lazy="false", which is not the best solution. > I'll try to build a tiny example to demonstrate it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-1477) Integrate somehow with Hibernate to avoid LazyInitializationException errors
[ https://issues.apache.org/jira/browse/CXF-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Ross updated CXF-1477: Attachment: HibernateInInterceptor.java > Integrate somehow with Hibernate to avoid LazyInitializationException errors > > > Key: CXF-1477 > URL: https://issues.apache.org/jira/browse/CXF-1477 > Project: CXF > Issue Type: Improvement > Components: Bus >Affects Versions: 2.0.4 > Environment: Ubuntu Feisty Fawn (7.04) >Reporter: Leandro > Attachments: AbstractHibernateAccessorPhaseInterceptor.java, > HibernateInInterceptor.java, HibernateOutInterceptor.java > > > Using Hibernate as a DAO layer will end in LazyInitializationException errors. > I've tried to define OpenSessionInView filter and mapping it to the same > address as the web service, but with no luck. > The current workaround is to set the collection with the property > lazy="false", which is not the best solution. > I'll try to build a tiny example to demonstrate it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1477) Integrate somehow with Hibernate to avoid LazyInitializationException errors
[
https://issues.apache.org/jira/browse/CXF-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679216#action_12679216
]
Kevin Ross commented on CXF-1477:
-
I have adapted
{{org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor}} to
CXF using interceptors. We just completed this and it works for us but we have
not yet deployed to production. This depends on spring-orm (2.5.6 is what we
are using).
This may be difficult to include due to external dependencies, I'm not sure
about the best approach.
What I can say is that this is a *VERY* common issue and CXF should at least
have this in a contrib or examples section of the codebase, if not a wiki/howto
to address the issue.
> Integrate somehow with Hibernate to avoid LazyInitializationException errors
>
>
> Key: CXF-1477
> URL: https://issues.apache.org/jira/browse/CXF-1477
> Project: CXF
> Issue Type: Improvement
> Components: Bus
>Affects Versions: 2.0.4
> Environment: Ubuntu Feisty Fawn (7.04)
>Reporter: Leandro
> Attachments: AbstractHibernateAccessorPhaseInterceptor.java,
> HibernateInInterceptor.java, HibernateOutInterceptor.java
>
>
> Using Hibernate as a DAO layer will end in LazyInitializationException errors.
> I've tried to define OpenSessionInView filter and mapping it to the same
> address as the web service, but with no luck.
> The current workaround is to set the collection with the property
> lazy="false", which is not the best solution.
> I'll try to build a tiny example to demonstrate it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1477) Integrate somehow with Hibernate to avoid LazyInitializationException errors
[ https://issues.apache.org/jira/browse/CXF-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679246#action_12679246 ] Daniel Kulp commented on CXF-1477: -- Interesting. Yea, this is something I'd LOVE to see in the samples. If someone could take this and create a small "hello world hibernate" application that could be put in samples, that would be great. Probably maven based to download the dependencies and such so they don't need to be shipped would be perfect. > Integrate somehow with Hibernate to avoid LazyInitializationException errors > > > Key: CXF-1477 > URL: https://issues.apache.org/jira/browse/CXF-1477 > Project: CXF > Issue Type: Improvement > Components: Bus >Affects Versions: 2.0.4 > Environment: Ubuntu Feisty Fawn (7.04) >Reporter: Leandro > Attachments: AbstractHibernateAccessorPhaseInterceptor.java, > HibernateInInterceptor.java, HibernateOutInterceptor.java > > > Using Hibernate as a DAO layer will end in LazyInitializationException errors. > I've tried to define OpenSessionInView filter and mapping it to the same > address as the web service, but with no luck. > The current workaround is to set the collection with the property > lazy="false", which is not the best solution. > I'll try to build a tiny example to demonstrate it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CXF-2089) Sign before encrypt throws a ClassCastException
[ https://issues.apache.org/jira/browse/CXF-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp reassigned CXF-2089: Assignee: Daniel Kulp > Sign before encrypt throws a ClassCastException > --- > > Key: CXF-2089 > URL: https://issues.apache.org/jira/browse/CXF-2089 > Project: CXF > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Eamonn Dwyer >Assignee: Daniel Kulp > Fix For: 2.2 > > Attachments: Mar05.patch > > > The UX ws-sec 11 test fails in the server side with the following exception > INFO: Interceptor has thrown exception, unwinding now > org.apache.cxf.interceptor.Fault: java.util.ArrayList > at > org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.doSignBeforeEncrypt(SymmetricBindingHandler.java:380) > at > org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.handleBinding(SymmetricBindingHandler.java:113) > at > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:131) > at > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:1) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236) > at > org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:74) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:89) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:302) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:265) > at > org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:729) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) > Caused by: java.lang.ClassCastException: java.util.ArrayList > at > org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.assertSupportingTokens(AbstractBindingBuilder.java:370) > at > org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.assertSupportingTokens(AbstractBindingBuilder.java:1343) > at > org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.doSignBeforeEncrypt(SymmetricBindingHandler.java:331) > ... 21 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2086) CFX does not log caught RuntimeException
[ https://issues.apache.org/jira/browse/CXF-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-2086. --- Resolution: Fixed Fix Version/s: 2.2 I believe it's been fixed now - and the error message if any will be reported back to a client. Whatever has been fixed will probably won't close the issue of logging in general, and we'll continue improving it, but I reckon this issue can be closed now. Note, I'll do a backmerge into 2.1.5 after 2.2 gets released Feel free to reopen if you find some other weak spots, thanks > CFX does not log caught RuntimeException > > > Key: CXF-2086 > URL: https://issues.apache.org/jira/browse/CXF-2086 > Project: CXF > Issue Type: Improvement > Components: REST >Affects Versions: 2.1.4 > Environment: Java 6 and Windows 7 >Reporter: Matt Helgren > Fix For: 2.2, 2.1.5 > > > We are using CXF and the JAXRS component to build our next generation > application based on REST services. Recently we have a very hard time > debugging REST requests that fail with a 500 response. We find that the > failures are due to our own issues with JAXB marsharlling but it is very hard > to discover because JAXRS and CXF do not report/log the exceptions caught > from JAXB. > JAXB errors seem to be caught by the framework in > JAXRSInIntercepter.handleMessage(). Please add some logging to the catch > block. Right now all it does is create a fault response for the client that > has very little information about the actual root cause. > This may seem like a small change but it would help us immensely in our > development process with CXF. > I would also request that you review your error handling in general and > determine if appropriate logging is in place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2051) Exception in REST Service creates not-well-formed xml responses
[ https://issues.apache.org/jira/browse/CXF-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-2051. --- Resolution: Fixed Fix Version/s: 2.1.5 2.2 If org.apache.cxf.output.buffering is set to true or if a given provider has getEnableBuffering() method which returns true then the output will be buffered, If we're talking about small to medium size messages then the perfomance sideeffects are unlikely to happen, the CachedOutputStream is very efficient. Additionally, if enableStreaming propery is set to true on a JAXBElementProvider then a caching XMLStreamWriter will be used to capture all the events in memory and then output them to the real stream. > Exception in REST Service creates not-well-formed xml responses > --- > > Key: CXF-2051 > URL: https://issues.apache.org/jira/browse/CXF-2051 > Project: CXF > Issue Type: Bug > Components: JAXB Databinding >Affects Versions: 2.2 >Reporter: Andreas Sahlbach > Fix For: 2.2, 2.1.5 > > > I've got this with SOAP and REST services using JAXB Databinding. In case of > errors during the databinding phase, I get not well-formed xml like this: > standalone="yes"?>streetcity276Extern69250 xmlns:ns1="http://cxf.apache.org/bindings/xformat";> xmlns:ns1="http://cxf.apache.org/bindings/xformat";>org.hibernate.LazyInitializationException: > failed to lazily initialize a collection of role: > de.volkswagen.ums.persistence.data.PersistentOrganization.displaynames, no > session or session was closed > So the already created beginning of the response is not replaced but appended > by the fault, creating a not usable response. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-1884) ExceptionMapper is not called due to a NullPointerException at JAXRSOutInterceptor
[
https://issues.apache.org/jira/browse/CXF-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-1884.
---
Resolution: Fixed
Fix Version/s: 2.1.5
2.2
Finally reproduced it - fixed now...
> ExceptionMapper is not called due to a NullPointerException at
> JAXRSOutInterceptor
> --
>
> Key: CXF-1884
> URL: https://issues.apache.org/jira/browse/CXF-1884
> Project: CXF
> Issue Type: Bug
> Components: REST
>Affects Versions: 2.1.2
>Reporter: Eli Kizhnerman
> Fix For: 2.2, 2.1.5
>
>
> ExceptionMapper is not called due to a NullPointerException at
> JAXRSOutInterceptor when CXF does not find an invoked method.
> The problem is in JAXRSOutInterceptor line 150. If CXF is not able to
> identify an operation to invoke invoked is null and a NullPointerException is
> thrown. This exception causes CXF to bypass the configured ExceptionMapper
> and show the default error message from XMLFaultOutInterceptor.
> I also suspect that there are other methods that don't work right when
> invoked is null.
> JAXRSOutInterceptor line 150:
> writer.writeTo(responseObj, targetType,
> invoked.getGenericReturnType(),
>invoked != null ? invoked.getAnnotations() :
> new Annotation[]{},
>responseType,
>response.getMetadata(),
>out);
> Oct 23, 2008 3:27:47 PM org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor
> processRequest
> SEVERE: .No operation matching request path /seaarch/ is found, ContentType :
> */*, Accept : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8.
> Oct 23, 2008 3:27:47 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> INFO: Interceptor has thrown exception, unwinding now
> java.lang.NullPointerException
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.processResponse(JAXRSOutInterceptor.java:150)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleMessage(JAXRSOutInterceptor.java:61)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
> at
> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:74)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
> at
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:92)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:283)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:128)
> at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:174)
> at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.doGet(AbstractCXFServlet.java:156)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:359)
> at
> org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
> at
> org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
> at
> org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
> at
> org.springframework.security.ui.ExceptionTranslationFilter.doFilterHttp(ExceptionTranslationFilter.java:101)
> at
> org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
> at
> org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
> at
> org.springframework.security.ui.preauth.AbstractPreAuthenticatedProcessingFilter.doFilterHttp(AbstractPreAuthenticatedProcessingFilter.java:60)
> at
> org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
> at
> org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
> at
> com.reuters.agency.g3ids.security.spring.authentication.NonHttpSessionContextFilter.doFilterHttp(NonHttpSessionContextFilter.java:69
[jira] Resolved: (CXF-1650) Allow JAX-RS Resources, without XmlRootElement JAXB annotation
[ https://issues.apache.org/jira/browse/CXF-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-1650. --- Resolution: Fixed Fix Version/s: 2.1.5 2.2 I'm closing it now - but please reopen it or create a new one if you feel some more enhancements needs to be made to JAXB provider > Allow JAX-RS Resources, without XmlRootElement JAXB annotation > -- > > Key: CXF-1650 > URL: https://issues.apache.org/jira/browse/CXF-1650 > Project: CXF > Issue Type: Improvement > Components: REST >Affects Versions: 2.1 > Environment: MacOS X 10.5.2, JSE 1.5 >Reporter: Artur Karazniewicz > Fix For: 2.2, 2.1.5 > > > Currently, exposing POJO resources as application/xml MIME resource, needs > POJO to be annotated with XmlRootElement. This is serious limitations > especially, with conjunction with JAX-WS, and wsdl-first approach (when one > wants expose service through REST and SOAP). Things even goes worse with > DOC/LIT/Wrapped. XJC is little bit restrictive when it comes to emitting > XmlRootElement - see: > http://weblogs.java.net/blog/kohsuke/archive/2006/03/why_does_jaxb_p.html > It would be really helpful if there were some (plugable and customizable) > strategy, how overcome above requirement. It would definitely be helpful, > especially with mixed scenarios - JAX-WS + JAX-RS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-1858) JAXRSOutInterceptor throws NullPointerException for unknown requests when using exception mapper
[
https://issues.apache.org/jira/browse/CXF-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-1858.
---
Resolution: Fixed
Fix Version/s: 2.1.5
2.2
Fixed now
> JAXRSOutInterceptor throws NullPointerException for unknown requests when
> using exception mapper
>
>
> Key: CXF-1858
> URL: https://issues.apache.org/jira/browse/CXF-1858
> Project: CXF
> Issue Type: Bug
> Components: REST
>Affects Versions: 2.1.2
> Environment: windows XP, jdk1.6.0_07, tomcat 6.0.18
>Reporter: david
> Fix For: 2.2, 2.1.5
>
>
> JAX-RS webservice
> When a client requests URL that isnt a valid service endpoint and using an
> Exeption mapper to return more detailed error, if you add an entity in the
> response the JAXRSOutInterceptor throws a NPE.
> java.lang.NullPointerException
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.processResponse(JAXRSOutInterceptor.java:150)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleMessage(JAXRSOutInterceptor.java:61)
>.
> The exception mapper:
> public class MyExceptionMapper implements ExceptionMapper
> {
>
> private static Logger LOG =
> LogUtils.getL7dLogger(MyExceptionMapper.class);
>
> @Override
> public Response toResponse(Exception ex)
> {
> LOG.logp(Level.WARNING, "MyExceptionMapper",
> "toResponse","Caught Exception:", ex);
> return
> Response.status(503).type("text/html").entity("Myexception error
> description").build();
> }
> }
> If I dont put the entity in the response it works, but with an entity in the
> response it causes a NullPointerException.
> currently in SVN and 2.1.2 JAXRSOutInterceptor.java line 150 is :
> writer.writeTo(responseObj, targetType, invoked.getGenericReturnType(),
>invoked != null ? invoked.getAnnotations() :
> new Annotation[]{},
>responseType,
>response.getMetadata(),
>out);
>
> perhaps should be this :
> writer.writeTo(responseObj, targetType,
>invoked != null ?
> invoked.getGenericReturnType() : null,
>invoked != null ? invoked.getAnnotations() :
> new Annotation[]{},
>responseType,
>response.getMetadata(),
>out);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2045) Custom headers lost when using Cxf Interceptors
[
https://issues.apache.org/jira/browse/CXF-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-2045.
---
Resolution: Fixed
Fix Version/s: 2.1.5
2.2
Hi Gabo - I have a test now (and a fix) showing how a custom output interceptor
can add headers to the outbound message, this interceptor is registered at
Phase.MARSHAL
> Custom headers lost when using Cxf Interceptors
> ---
>
> Key: CXF-2045
> URL: https://issues.apache.org/jira/browse/CXF-2045
> Project: CXF
> Issue Type: Bug
> Components: Core, REST
>Affects Versions: 2.2
> Environment: Java 1.5
> Jetty 6.1
>Reporter: Gabo Manuel
> Fix For: 2.2, 2.1.5
>
>
> All changes to the header through the Message object in the out interceptor
> are not received by client.
> Server.java
> public class RetestRestServer {
> String basepath = "/someValue";
> int port = 8080;
> @SuppressWarnings("unchecked")
> protected RetestRestServer() throws Exception {
> JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
> sf.setResourceClasses(AccountService.class);
> sf.setResourceProvider(AccountService.class,
> new SingletonResourceProvider(new AccountService()));
> sf.setAddress("http://localhost:"+port+basepath+"/rest/Accounts/";);
>
> List out = new ArrayList(1);
> in.add(new RestOutHandler());
> sf.setOutInterceptors(in);
>
> sf.create();
> }
> public static void main(String args[]) throws Exception {
> new RetestRestServer();
> System.out.println("Server ready...");
> }
> }
> RestOutInterceptor.java
> public class RestOutHandler extends AbstractPhaseInterceptor{
> private static Logger logger = Logger.getLogger(RestOutHandler.class);
> public RestOutHandler() {
> super(Phase.POST_PROTOCOL);
> }
> public void handleMessage(Message message) throws Fault {
> Map> responseHeaders = (Map List>)message.get(Message.PROTOCOL_HEADERS);
>
> if (responseHeaders == null) {
> responseHeaders = new HashMap>();
> message.put(Message.PROTOCOL_HEADERS, responseHeaders);
> }
>
> responseHeaders.put("header1", Arrays.asList(new
> String[]{"headerValue"}));
> logger.debug("out message headers: " + responseHeaders);
> }
> }
> AccountService.java
> @Consumes("*/xml")
> @Produces("text/xml")
> @WebService(serviceName="AccountService", portName="AccountServicePort")
> public class AccountService{
> private static Logger logger = Logger.getLogger(AccountService.class);
> @GET
> @Path("/")
> @WebMethod
> public String getAccount(
> @QueryParam("serialNumber")
> @WebParam(name="serialNumber")
> long serialNumber) {
> logger.info("get Account received: " + serialNumber);
> return "get Account received: " + serialNumber;
> }
> }
> Please advise if more info is needed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2085) Applications classloader should be set during method invocations.
[ https://issues.apache.org/jira/browse/CXF-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679319#action_12679319 ] Sergey Beryozkin commented on CXF-2085: --- Hi Can you provide some simple test case please ? I'm not sure I understand. If a class lazily loaded when one of the resource class methods is being invoked then the resource class loader will be used to load the class first... > Applications classloader should be set during method invocations. > - > > Key: CXF-2085 > URL: https://issues.apache.org/jira/browse/CXF-2085 > Project: CXF > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Chaitanya Choleti > Fix For: 2.2 > > > Invocation of a JAX-RS method may depend on some application classes which > may not be loaded already, they will be loaded during invocation. But during > invocation the classloader will be CXF war application classloader, this will > lead to NoClassDefFoundErrors. To avoid this root resource class' classloader > should be set on the current thread. > Similar fix should be applied to provider methods such as readFrom, writeTo > etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2088) Wrong serialisation order of elements when using Aegis databinding.
[ https://issues.apache.org/jira/browse/CXF-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679332#action_12679332 ] Benson Margulies commented on CXF-2088: --- Could you post your fix as a patch, please? (diff -u) > Wrong serialisation order of elements when using Aegis databinding. > --- > > Key: CXF-2088 > URL: https://issues.apache.org/jira/browse/CXF-2088 > Project: CXF > Issue Type: Bug > Components: Aegis Databinding >Affects Versions: 2.1.4 >Reporter: Christofer Dutz >Assignee: Benson Margulies > Attachments: BeanType.java > > > In my current case I hava > * an abstract Java class "AbstractDatabaseObject" defining a property "id". > * an abstract Java class "Credential" which extends "AbstractDatabaseObject" > and defines a property "name" > * a concrete Java class "UsernamePasswordCredential" which extends > "Credential" and defines properties "username" and "password" > All schemas are created to my greates satisfaction (Great Job!). > Unfortunately the serialisation order when using Aegis databinding (don't > know if its the same using others) is the wrong way around. > Instead of getting: > > 306ce816-01b7-11de-8d92-8d4df6b73eb1 > dsfgsdfgs > dsfsfdg > sdsdfgsdfg > > I get: > > dsfsfdg > sdsdfgsdfg > dsfgsdfgs > 306ce816-01b7-11de-8d92-8d4df6b73eb1 > > Which my Flex client complains about. > I'll try to whip up a patch fixing this issue today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CXF-2088) Wrong serialisation order of elements when using Aegis databinding.
[ https://issues.apache.org/jira/browse/CXF-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reassigned CXF-2088: - Assignee: Benson Margulies > Wrong serialisation order of elements when using Aegis databinding. > --- > > Key: CXF-2088 > URL: https://issues.apache.org/jira/browse/CXF-2088 > Project: CXF > Issue Type: Bug > Components: Aegis Databinding >Affects Versions: 2.1.4 >Reporter: Christofer Dutz >Assignee: Benson Margulies > Attachments: BeanType.java > > > In my current case I hava > * an abstract Java class "AbstractDatabaseObject" defining a property "id". > * an abstract Java class "Credential" which extends "AbstractDatabaseObject" > and defines a property "name" > * a concrete Java class "UsernamePasswordCredential" which extends > "Credential" and defines properties "username" and "password" > All schemas are created to my greates satisfaction (Great Job!). > Unfortunately the serialisation order when using Aegis databinding (don't > know if its the same using others) is the wrong way around. > Instead of getting: > > 306ce816-01b7-11de-8d92-8d4df6b73eb1 > dsfgsdfgs > dsfsfdg > sdsdfgsdfg > > I get: > > dsfsfdg > sdsdfgsdfg > dsfgsdfgs > 306ce816-01b7-11de-8d92-8d4df6b73eb1 > > Which my Flex client complains about. > I'll try to whip up a patch fixing this issue today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2089) Sign before encrypt throws a ClassCastException
[ https://issues.apache.org/jira/browse/CXF-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-2089. -- Resolution: Fixed > Sign before encrypt throws a ClassCastException > --- > > Key: CXF-2089 > URL: https://issues.apache.org/jira/browse/CXF-2089 > Project: CXF > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Eamonn Dwyer >Assignee: Daniel Kulp > Fix For: 2.2 > > Attachments: Mar05.patch > > > The UX ws-sec 11 test fails in the server side with the following exception > INFO: Interceptor has thrown exception, unwinding now > org.apache.cxf.interceptor.Fault: java.util.ArrayList > at > org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.doSignBeforeEncrypt(SymmetricBindingHandler.java:380) > at > org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.handleBinding(SymmetricBindingHandler.java:113) > at > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:131) > at > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:1) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236) > at > org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:74) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:89) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:302) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:265) > at > org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:729) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) > Caused by: java.lang.ClassCastException: java.util.ArrayList > at > org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.assertSupportingTokens(AbstractBindingBuilder.java:370) > at > org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.assertSupportingTokens(AbstractBindingBuilder.java:1343) > at > org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.doSignBeforeEncrypt(SymmetricBindingHandler.java:331) > ... 21 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1650) Allow JAX-RS Resources, without XmlRootElement JAXB annotation
[ https://issues.apache.org/jira/browse/CXF-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artur Karazniewicz closed CXF-1650. --- > Allow JAX-RS Resources, without XmlRootElement JAXB annotation > -- > > Key: CXF-1650 > URL: https://issues.apache.org/jira/browse/CXF-1650 > Project: CXF > Issue Type: Improvement > Components: REST >Affects Versions: 2.1 > Environment: MacOS X 10.5.2, JSE 1.5 >Reporter: Artur Karazniewicz > Fix For: 2.2, 2.1.5 > > > Currently, exposing POJO resources as application/xml MIME resource, needs > POJO to be annotated with XmlRootElement. This is serious limitations > especially, with conjunction with JAX-WS, and wsdl-first approach (when one > wants expose service through REST and SOAP). Things even goes worse with > DOC/LIT/Wrapped. XJC is little bit restrictive when it comes to emitting > XmlRootElement - see: > http://weblogs.java.net/blog/kohsuke/archive/2006/03/why_does_jaxb_p.html > It would be really helpful if there were some (plugable and customizable) > strategy, how overcome above requirement. It would definitely be helpful, > especially with mixed scenarios - JAX-WS + JAX-RS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2088) Wrong serialisation order of elements when using Aegis databinding.
[ https://issues.apache.org/jira/browse/CXF-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679431#action_12679431 ] Benson Margulies commented on CXF-2088: --- Are you sure we want to run the extension code between the attributes and the elements? I guess attribute order doesn't matter. > Wrong serialisation order of elements when using Aegis databinding. > --- > > Key: CXF-2088 > URL: https://issues.apache.org/jira/browse/CXF-2088 > Project: CXF > Issue Type: Bug > Components: Aegis Databinding >Affects Versions: 2.1.4 >Reporter: Christofer Dutz >Assignee: Benson Margulies > Attachments: BeanType.java > > > In my current case I hava > * an abstract Java class "AbstractDatabaseObject" defining a property "id". > * an abstract Java class "Credential" which extends "AbstractDatabaseObject" > and defines a property "name" > * a concrete Java class "UsernamePasswordCredential" which extends > "Credential" and defines properties "username" and "password" > All schemas are created to my greates satisfaction (Great Job!). > Unfortunately the serialisation order when using Aegis databinding (don't > know if its the same using others) is the wrong way around. > Instead of getting: > > 306ce816-01b7-11de-8d92-8d4df6b73eb1 > dsfgsdfgs > dsfsfdg > sdsdfgsdfg > > I get: > > dsfsfdg > sdsdfgsdfg > dsfgsdfgs > 306ce816-01b7-11de-8d92-8d4df6b73eb1 > > Which my Flex client complains about. > I'll try to whip up a patch fixing this issue today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2088) Wrong serialisation order of elements when using Aegis databinding.
[ https://issues.apache.org/jira/browse/CXF-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies resolved CXF-2088. --- Resolution: Fixed Fix Version/s: 2.2 Fix applied to trunk. > Wrong serialisation order of elements when using Aegis databinding. > --- > > Key: CXF-2088 > URL: https://issues.apache.org/jira/browse/CXF-2088 > Project: CXF > Issue Type: Bug > Components: Aegis Databinding >Affects Versions: 2.1.4 >Reporter: Christofer Dutz >Assignee: Benson Margulies > Fix For: 2.2 > > Attachments: BeanType.java > > > In my current case I hava > * an abstract Java class "AbstractDatabaseObject" defining a property "id". > * an abstract Java class "Credential" which extends "AbstractDatabaseObject" > and defines a property "name" > * a concrete Java class "UsernamePasswordCredential" which extends > "Credential" and defines properties "username" and "password" > All schemas are created to my greates satisfaction (Great Job!). > Unfortunately the serialisation order when using Aegis databinding (don't > know if its the same using others) is the wrong way around. > Instead of getting: > > 306ce816-01b7-11de-8d92-8d4df6b73eb1 > dsfgsdfgs > dsfsfdg > sdsdfgsdfg > > I get: > > dsfsfdg > sdsdfgsdfg > dsfgsdfgs > 306ce816-01b7-11de-8d92-8d4df6b73eb1 > > Which my Flex client complains about. > I'll try to whip up a patch fixing this issue today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2045) Custom headers lost when using Cxf Interceptors
[
https://issues.apache.org/jira/browse/CXF-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679481#action_12679481
]
Gabo Manuel commented on CXF-2045:
--
Hi Sergey,
Thanks! I'll check it out next opportunity I get. :)
Gabo
> Custom headers lost when using Cxf Interceptors
> ---
>
> Key: CXF-2045
> URL: https://issues.apache.org/jira/browse/CXF-2045
> Project: CXF
> Issue Type: Bug
> Components: Core, REST
>Affects Versions: 2.2
> Environment: Java 1.5
> Jetty 6.1
>Reporter: Gabo Manuel
> Fix For: 2.2, 2.1.5
>
>
> All changes to the header through the Message object in the out interceptor
> are not received by client.
> Server.java
> public class RetestRestServer {
> String basepath = "/someValue";
> int port = 8080;
> @SuppressWarnings("unchecked")
> protected RetestRestServer() throws Exception {
> JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
> sf.setResourceClasses(AccountService.class);
> sf.setResourceProvider(AccountService.class,
> new SingletonResourceProvider(new AccountService()));
> sf.setAddress("http://localhost:"+port+basepath+"/rest/Accounts/";);
>
> List out = new ArrayList(1);
> in.add(new RestOutHandler());
> sf.setOutInterceptors(in);
>
> sf.create();
> }
> public static void main(String args[]) throws Exception {
> new RetestRestServer();
> System.out.println("Server ready...");
> }
> }
> RestOutInterceptor.java
> public class RestOutHandler extends AbstractPhaseInterceptor{
> private static Logger logger = Logger.getLogger(RestOutHandler.class);
> public RestOutHandler() {
> super(Phase.POST_PROTOCOL);
> }
> public void handleMessage(Message message) throws Fault {
> Map> responseHeaders = (Map List>)message.get(Message.PROTOCOL_HEADERS);
>
> if (responseHeaders == null) {
> responseHeaders = new HashMap>();
> message.put(Message.PROTOCOL_HEADERS, responseHeaders);
> }
>
> responseHeaders.put("header1", Arrays.asList(new
> String[]{"headerValue"}));
> logger.debug("out message headers: " + responseHeaders);
> }
> }
> AccountService.java
> @Consumes("*/xml")
> @Produces("text/xml")
> @WebService(serviceName="AccountService", portName="AccountServicePort")
> public class AccountService{
> private static Logger logger = Logger.getLogger(AccountService.class);
> @GET
> @Path("/")
> @WebMethod
> public String getAccount(
> @QueryParam("serialNumber")
> @WebParam(name="serialNumber")
> long serialNumber) {
> logger.info("get Account received: " + serialNumber);
> return "get Account received: " + serialNumber;
> }
> }
> Please advise if more info is needed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-1434) Better Fault handling demo
[ https://issues.apache.org/jira/browse/CXF-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Ivar Skogland updated CXF-1434: Attachment: CXFTest.rar I've added a file containing a working project (maven) that uses Spring, CXF and uses a custom faultInterceptor. I hope you may use this. I also hope that my sample may be of use for the cxf project. It may not be the most elegant solution ever, but it works fine for me. first; Alter the tomcat home directory in pom.xml (more info here; http://www.knutivars.net/cxf/index.html ) Build: mvn install Deploy: mvn cargo:start Please let me know if you got any questions. > Better Fault handling demo > -- > > Key: CXF-1434 > URL: https://issues.apache.org/jira/browse/CXF-1434 > Project: CXF > Issue Type: Wish > Components: Samples > Environment: this should run on any servlet container. Java >= 5 >Reporter: David Castaneda >Priority: Minor > Attachments: CXFTest.rar, java_first_spring_support_faults.zip > > > Sample application showing how to create custom Soap Faults. > The target is to show a functional example of how to transform Exceptions > (Checked and Unchecked) to SoapFaults, that can contain Server or Client > fault and a custom detail part. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
