[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15306437#comment-15306437
]
Sergey Beryozkin commented on CXF-6869:
---
Hi Vedran,
thanks, well, if we talk about the users who are not familiar with SpringBoot
then it was me who was such a user when I started modifying a demo originally
contributed to CXF :-). And I think the principle of the least surprise was not
met.
Re the service descriptions - an issue exists to move a Swagger related code
into a diff module. Adding a WADL filter which will check every request when
people would only expect Swagger support and likewise having an extra Swagger
endpoint or filter around when only WADL is needed will not be ideal, but I do
agree the service description should be coming OOB for RS services too, I'd
only like to have a dedicated discussion/solution done later on.
Cheers, Sergey
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>Assignee: Sergey Beryozkin
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6921) Issue with Wrapper style web service client stub with implicit header
Kaushal Kishore Agrawal created CXF-6921: Summary: Issue with Wrapper style web service client stub with implicit header Key: CXF-6921 URL: https://issues.apache.org/jira/browse/CXF-6921 Project: CXF Issue Type: Bug Components: JAX-WS Runtime Affects Versions: 2.7.14 Environment: Jboss EAP 6.4 Build Tool gradle 1.11 Reporter: Kaushal Kishore Agrawal We have a small application, which accept a REST call and transform it into a SOAP call and pass the same to third application (Southbound app). Response received from Southbound application is transformed back in the REST response to be sent to the calling application (Northbound app). Southbound App has exposed a WSDL with implicit header, while generating client stub we have ignored the header part, as same need to be taken care by the SOAPHandler. But on transformation body part of SOAP message is getting populated as empty causing southbound application to reject the request. Details of the environment: ‐ Cxf 2.7.14 ‐ Jboss EAP 6.4 ‐ Southbound application is mocked using SOAP UI, URL of the mocked application need to pass as header parameter in the northbound call as ‘_mockURL’ parameter. ‐ Request and response are getting logged using LogRequest SOAP handler. Path of the log file need to be updated based on local directory structure. This is just to check the outgoing request and incoming response from southbound app. ‐ Gradle 1.11 is used as build tool Northbound request details URL : http://localhost:8080/SharedProject/customers/245?type=RETAIL Method : GET Headers: Accept - application/xml Content-Type - application/xml _mockURL - -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6921) Issue with Wrapper style web service client stub with implicit header
[ https://issues.apache.org/jira/browse/CXF-6921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kaushal Kishore Agrawal updated CXF-6921: - Attachment: SharedProject.zip > Issue with Wrapper style web service client stub with implicit header > - > > Key: CXF-6921 > URL: https://issues.apache.org/jira/browse/CXF-6921 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 2.7.14 > Environment: Jboss EAP 6.4 > Build Tool gradle 1.11 >Reporter: Kaushal Kishore Agrawal > Attachments: SharedProject.zip > > > We have a small application, which accept a REST call and transform it into a > SOAP call and pass the same to third application (Southbound app). Response > received from Southbound application is transformed back in the REST response > to be sent to the calling application (Northbound app). > Southbound App has exposed a WSDL with implicit header, while generating > client stub we have ignored the header part, as same need to be taken care by > the SOAPHandler. > But on transformation body part of SOAP message is getting populated as empty > causing southbound application to reject the request. > Details of the environment: > ‐ Cxf 2.7.14 > ‐ Jboss EAP 6.4 > ‐ Southbound application is mocked using SOAP UI, URL of the mocked > application need to pass as header parameter in the northbound call as > ‘_mockURL’ parameter. > ‐ Request and response are getting logged using LogRequest SOAP handler. > Path of the log file need to be updated based on local directory structure. > This is just to check the outgoing request and incoming response from > southbound app. > ‐ Gradle 1.11 is used as build tool > Northbound request details > URL : http://localhost:8080/SharedProject/customers/245?type=RETAIL > Method : GET > Headers: > Accept - application/xml > Content-Type - application/xml > _mockURL - -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6921) Issue with Wrapper style web service client stub with implicit header
[ https://issues.apache.org/jira/browse/CXF-6921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15306507#comment-15306507 ] Kaushal Kishore Agrawal commented on CXF-6921: -- Attached project contains all the implementation > Issue with Wrapper style web service client stub with implicit header > - > > Key: CXF-6921 > URL: https://issues.apache.org/jira/browse/CXF-6921 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 2.7.14 > Environment: Jboss EAP 6.4 > Build Tool gradle 1.11 >Reporter: Kaushal Kishore Agrawal > Attachments: SharedProject.zip > > > We have a small application, which accept a REST call and transform it into a > SOAP call and pass the same to third application (Southbound app). Response > received from Southbound application is transformed back in the REST response > to be sent to the calling application (Northbound app). > Southbound App has exposed a WSDL with implicit header, while generating > client stub we have ignored the header part, as same need to be taken care by > the SOAPHandler. > But on transformation body part of SOAP message is getting populated as empty > causing southbound application to reject the request. > Details of the environment: > ‐ Cxf 2.7.14 > ‐ Jboss EAP 6.4 > ‐ Southbound application is mocked using SOAP UI, URL of the mocked > application need to pass as header parameter in the northbound call as > ‘_mockURL’ parameter. > ‐ Request and response are getting logged using LogRequest SOAP handler. > Path of the log file need to be updated based on local directory structure. > This is just to check the outgoing request and incoming response from > southbound app. > ‐ Gradle 1.11 is used as build tool > Northbound request details > URL : http://localhost:8080/SharedProject/customers/245?type=RETAIL > Method : GET > Headers: > Accept - application/xml > Content-Type - application/xml > _mockURL - -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6922) Make JaxRsConfig not interfere with SpringBoot auto configuration process
Sergey Beryozkin created CXF-6922: - Summary: Make JaxRsConfig not interfere with SpringBoot auto configuration process Key: CXF-6922 URL: https://issues.apache.org/jira/browse/CXF-6922 Project: CXF Issue Type: Improvement Components: JAX-RS Reporter: Sergey Beryozkin Fix For: 3.1.7, 3.2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6922) Make JaxRsConfig not interfere with SpringBoot auto configuration process
[ https://issues.apache.org/jira/browse/CXF-6922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6922. --- Resolution: Fixed Assignee: Sergey Beryozkin > Make JaxRsConfig not interfere with SpringBoot auto configuration process > - > > Key: CXF-6922 > URL: https://issues.apache.org/jira/browse/CXF-6922 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 3.1.7, 3.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6922) Make JaxRsConfig not interfere with SpringBoot auto configuration process
[ https://issues.apache.org/jira/browse/CXF-6922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15306565#comment-15306565 ] Sergey Beryozkin commented on CXF-6922: --- http://git-wip-us.apache.org/repos/asf/cxf/commit/8e58f887 http://git-wip-us.apache.org/repos/asf/cxf/commit/dfa36ecb > Make JaxRsConfig not interfere with SpringBoot auto configuration process > - > > Key: CXF-6922 > URL: https://issues.apache.org/jira/browse/CXF-6922 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 3.1.7, 3.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15306593#comment-15306593
]
Sergey Beryozkin commented on CXF-6869:
---
Hi Vedran
I've started applying some parts of your patch.
First I applied your JaxRsConfig changes as part of another issue:
http://git-wip-us.apache.org/repos/asf/cxf/commit/8e58f887
I did it because it might be a migration issue for some users and as such I
thought about opening a dedicated issue.
Next I updated the version:
http://git-wip-us.apache.org/repos/asf/cxf/commit/4b0868a8
Finally, the auto-configuration improvements:
http://git-wip-us.apache.org/repos/asf/cxf/commit/3615f209
but I haven't applied JAX-RS specific changes. Specifically,
SpringScanComponentServer is imported right now into a demo application in
jaxrs_spring_boot_scan, and with your JaxRsConfig fixes it all works nice.
I know you like the idea of JAX-RS resources being auto-discovered OOB :-) but
I have few concerns, specifically, having the auto-discovery enabled by default
OOB may cause unexpected side-effects, but also, I wonder, if we really should
do the frontend specific configurations in a shared autoconfigure module.
For example, I opened a JAX-WS JIRA awhile back for JAX-WS endpoints be
auto-created too, so once it is done we'd need to add a JAX-WS specific
support, and then, with the frontend specific features likely to be needed
provided OOB as well going forward (ex, Swagger vs WADL for RS) we may find it
difficult to keep a clean enough code.
Explicitly importing SpringScanComponentServer into a demo application is an
extra effort compared to it being seamlessly enabled by the virtue of adding a
JAX-RS starter dependency, but for now I'm feeling it is a reasonable
compromise.
I'd like to discuss some options, such as introducing frontend specific
auto-configure modules. Or revisiting the idea of having only two modules, two
starters, one for JAX-WS and one for JAX-RS, with starters keeping some
auto-configuration code ? I appreciate the best practice is to keep the
starters code-free, but having a single auto-configure module may become
problematic for us going forward ?
Overall, I feel we already have a nice start as far as integrating with Spring
Boot is concerned and we can keep tuning it :-)
Thanks, Sergey
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>Assignee: Sergey Beryozkin
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6923) org.omg.CORBA.TIMEOUT is not handled with Jacorb implementation
Grzegorz Grzybek created CXF-6923:
-
Summary: org.omg.CORBA.TIMEOUT is not handled with Jacorb
implementation
Key: CXF-6923
URL: https://issues.apache.org/jira/browse/CXF-6923
Project: CXF
Issue Type: Bug
Components: CORBA Binding
Affects Versions: 3.1.6
Reporter: Grzegorz Grzybek
When using Jacorb as ORB implementation at client side:
{code:java}
System.setProperty("org.omg.CORBA.ORBClass", "org.jacorb.orb.ORB");
System.setProperty("org.omg.CORBA.ORBSingletonClass",
"org.jacorb.orb.ORBSingleton");
{code}
we can set {{jacorb.connection.client.pending_reply_timeout}} system property
that configures client-side to throw {{org.omg.CORBA.TIMEOUT}} when timeout
occurs while waiting for reply.
The problem is different implementation of DII request code:
{code:java|title=com.sun.corba.se.impl.corba.RequestImpl#doInvocation()}
} catch( SystemException ex ) {
_env.exception(ex);
// NOTE: The exception should not be thrown.
// However, JDK 1.4 and earlier threw the exception,
// so we keep the behavior to be compatible.
throw ex;
{code}
{code:java|title=org.jacorb.orb.dii.Request#_invoke()}
catch (Exception e)
{
if (logger.isDebugEnabled ())
{
logger.debug("DII Request caught Exception", e);
}
env.exception (e);
break;
}
{code}
PR + test soon
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6923) org.omg.CORBA.TIMEOUT is not handled with Jacorb implementation
[
https://issues.apache.org/jira/browse/CXF-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15306730#comment-15306730
]
ASF GitHub Bot commented on CXF-6923:
-
GitHub user grgrzybek opened a pull request:
https://github.com/apache/cxf/pull/140
[CXF-6923] Handle org.omg.CORBA.SystemException for Jacorb correctly
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/grgrzybek/cxf CXF-6923-3.1.x
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/140.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #140
commit 0759f57a0786ef71a25e03c4d65c58632be3a18a
Author: Grzegorz Grzybek
Date: 2016-05-30T14:49:06Z
[CXF-6923] Handle org.omg.CORBA.SystemException for Jacorb correctly
> org.omg.CORBA.TIMEOUT is not handled with Jacorb implementation
> ---
>
> Key: CXF-6923
> URL: https://issues.apache.org/jira/browse/CXF-6923
> Project: CXF
> Issue Type: Bug
> Components: CORBA Binding
>Affects Versions: 3.1.6
>Reporter: Grzegorz Grzybek
>
> When using Jacorb as ORB implementation at client side:
> {code:java}
> System.setProperty("org.omg.CORBA.ORBClass", "org.jacorb.orb.ORB");
> System.setProperty("org.omg.CORBA.ORBSingletonClass",
> "org.jacorb.orb.ORBSingleton");
> {code}
> we can set {{jacorb.connection.client.pending_reply_timeout}} system property
> that configures client-side to throw {{org.omg.CORBA.TIMEOUT}} when timeout
> occurs while waiting for reply.
> The problem is different implementation of DII request code:
> {code:java|title=com.sun.corba.se.impl.corba.RequestImpl#doInvocation()}
> } catch( SystemException ex ) {
> _env.exception(ex);
> // NOTE: The exception should not be thrown.
> // However, JDK 1.4 and earlier threw the exception,
> // so we keep the behavior to be compatible.
> throw ex;
> {code}
> {code:java|title=org.jacorb.orb.dii.Request#_invoke()}
> catch (Exception e)
> {
>if (logger.isDebugEnabled ())
>{
> logger.debug("DII Request caught Exception", e);
>}
> env.exception (e);
> break;
> }
> {code}
> PR + test soon
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6923) org.omg.CORBA.TIMEOUT is not handled with Jacorb implementation
[
https://issues.apache.org/jira/browse/CXF-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15306732#comment-15306732
]
Grzegorz Grzybek commented on CXF-6923:
---
PR for {{3.1.x-fixes}} branch: https://github.com/apache/cxf/pull/140
> org.omg.CORBA.TIMEOUT is not handled with Jacorb implementation
> ---
>
> Key: CXF-6923
> URL: https://issues.apache.org/jira/browse/CXF-6923
> Project: CXF
> Issue Type: Bug
> Components: CORBA Binding
>Affects Versions: 3.1.6
>Reporter: Grzegorz Grzybek
>
> When using Jacorb as ORB implementation at client side:
> {code:java}
> System.setProperty("org.omg.CORBA.ORBClass", "org.jacorb.orb.ORB");
> System.setProperty("org.omg.CORBA.ORBSingletonClass",
> "org.jacorb.orb.ORBSingleton");
> {code}
> we can set {{jacorb.connection.client.pending_reply_timeout}} system property
> that configures client-side to throw {{org.omg.CORBA.TIMEOUT}} when timeout
> occurs while waiting for reply.
> The problem is different implementation of DII request code:
> {code:java|title=com.sun.corba.se.impl.corba.RequestImpl#doInvocation()}
> } catch( SystemException ex ) {
> _env.exception(ex);
> // NOTE: The exception should not be thrown.
> // However, JDK 1.4 and earlier threw the exception,
> // so we keep the behavior to be compatible.
> throw ex;
> {code}
> {code:java|title=org.jacorb.orb.dii.Request#_invoke()}
> catch (Exception e)
> {
>if (logger.isDebugEnabled ())
>{
> logger.debug("DII Request caught Exception", e);
>}
> env.exception (e);
> break;
> }
> {code}
> PR + test soon
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6924) Provide XmlAdapter alternatives to org.apache.cxf.xjc.runtime.DataTypeAdapter
David J. M. Karlsen created CXF-6924: Summary: Provide XmlAdapter alternatives to org.apache.cxf.xjc.runtime.DataTypeAdapter Key: CXF-6924 URL: https://issues.apache.org/jira/browse/CXF-6924 Project: CXF Issue Type: Improvement Components: JAXB Databinding Reporter: David J. M. Karlsen It would be nice to have XmlAdapter versions of the DataTypeAdapter https://docs.oracle.com/javase/8/docs/api/javax/xml/bind/annotation/adapters/XmlAdapter.html The reason for this is that when referencing static methods (e.g. using DataTypeAdapter directly) in binding files this generates adapters (and typically into the package: org/w3/_2001/xmlschema/ named Adapter1, Adapter2 etc which is a ticking bomb when having several different generations with jaxb in an application. Using XmlAdapters will simply refer to the implementing class, thus avoiding generation of code in the 1st place, and secondly avoid overlapping classnames when generating in different modules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6925) Make per-realm crypto configuration as flexible as the static one
Andreas Vallen created CXF-6925: --- Summary: Make per-realm crypto configuration as flexible as the static one Key: CXF-6925 URL: https://issues.apache.org/jira/browse/CXF-6925 Project: CXF Issue Type: Improvement Components: STS Affects Versions: 3.1.6, 3.0.7 Reporter: Andreas Vallen Priority: Minor CXF-4705 updated the StaticSTSProperties object to allow the user to specify a URL + Properties object for signature + encryption crypto properties, instead of just a String pointing to a File. The per-realm configurability introduced in CXF-3924 is however still missing this more flexible mechanism. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6900) invalid signature in case of soap fault
[
https://issues.apache.org/jira/browse/CXF-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15306924#comment-15306924
]
Michael Smith commented on CXF-6900:
With 3.1.7-SNAPSHOT, signature verification succeeds. However there's another
problem processing the fault:
{noformat}
May 30, 2016 3:42:48 PM
com.sun.xml.internal.messaging.saaj.soap.ver1_2.Fault1_2Impl
checkIfStandardFaultCode
SEVERE: SAAJ0435: Sender is not a standard Code value
May 30, 2016 3:42:48 PM com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl
setFaultCode
SEVERE: SAAJ0140: Empty/Null NamespaceURI specified for faultCode fc1:Sender
{noformat}
Here's the pre-digested input. The of "Sender" looks OK to
my untrained eye; it's unqualified, but the default namespace in that block is
http://www.w3.org/2003/05/soap-envelope so it should be OK.
{code:xml}
http://www.w3.org/2003/05/soap-envelope";
xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
u:Id="_1">
http://www.w3.org/2003/05/soap-envelope";>
Sender
CustomerNotFound
{code}
> invalid signature in case of soap fault
> ---
>
> Key: CXF-6900
> URL: https://issues.apache.org/jira/browse/CXF-6900
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.0.3
> Environment: windows 2008 jdk 1.6.0_45
>Reporter: david leruse
>Assignee: Colm O hEigeartaigh
> Fix For: 3.1.7
>
> Attachments: server7.log
>
>
> Hello,
> Having signature verification problems on the cxf client-side with a .NET
> Ws-fed protected webservice, I ask you a little help...
> Here is a summary of the problem :
> Most of the time, communication works well excepted when we got a soap fault
> message.
> Indeed signature validation works usually well excepted when
> we receive a fault message inside the body of the soap message. Even In this
> boundary case, signature verification works well excepted for one element,
> the fault message (see the enclosed server7.log file).
> After digging a bit, i've found that the calculated digest couldn't be equal
> to the claimed one because the content of the message given to the
> DigesterOutpustrream is not well canonicalized or normalized.
> Partial decrypted msg
> ...
>
>xmlns="http://www.w3.org/2003/05/soap-envelope";>DataNotFoundFault xml:lang="nl-BE">ContextContactInfo with Id '1' does not
> exist. xmlns="http://schemas.riziv.fgov.be/contact/2015/08/faults";
> xmlns:i="http://www.w3.org/2001/XMLSchema-instance";>ContextContactInfoNotFoundContextContactInfo
> with Id '1' does not exist.
>
> ...
> Predigested input :
> http://www.w3.org/2003/05/soap-envelope";
> xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> u:Id="_3"> xmlns="http://www.w3.org/2003/05/soap-envelope";>DataNotFoundFault xmlns="http://www.w3.org/2003/05/soap-envelope";> xml:lang="nl-BE">ContextContactInfo with Id '1' does not
> exist. xmlns="http://schemas.riziv.fgov.be/contact/2015/08/faults";>ContextContactInfoNotFoundContextContactInfo
> with Id '1' does not
> exist.
> Could you please check this problem and give me an advice ?
> The library used are :
> cxf 3.0.3
> wss4j 2.0.2
> xmlsec 2.0.2
> on a jdk 1.6.0_45
> Thanks in advance
> David L
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6926) StaticSTSProperties does not allow initialization of crypto from Properties object
Andreas Vallen created CXF-6926: --- Summary: StaticSTSProperties does not allow initialization of crypto from Properties object Key: CXF-6926 URL: https://issues.apache.org/jira/browse/CXF-6926 Project: CXF Issue Type: Bug Affects Versions: 3.1.6 Reporter: Andreas Vallen Priority: Minor This was working in CXF 3.0.7 courtesy of the getProps method which was removed by git commit 40c9bfd, effective for 3.1 branch. The former possibility to set an initialized Properties object was helpful as an adapter to the spring infrastructure for properties (Resource and Environment abstraction, property placeholder and such) instead of relying on an additional external properties file sourced by cxf-specific mechanisms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-6923) org.omg.CORBA.TIMEOUT is not handled with Jacorb implementation
[
https://issues.apache.org/jira/browse/CXF-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-6923:
-
Assignee: Freeman Fang
> org.omg.CORBA.TIMEOUT is not handled with Jacorb implementation
> ---
>
> Key: CXF-6923
> URL: https://issues.apache.org/jira/browse/CXF-6923
> Project: CXF
> Issue Type: Bug
> Components: CORBA Binding
>Affects Versions: 3.1.6
>Reporter: Grzegorz Grzybek
>Assignee: Freeman Fang
>
> When using Jacorb as ORB implementation at client side:
> {code:java}
> System.setProperty("org.omg.CORBA.ORBClass", "org.jacorb.orb.ORB");
> System.setProperty("org.omg.CORBA.ORBSingletonClass",
> "org.jacorb.orb.ORBSingleton");
> {code}
> we can set {{jacorb.connection.client.pending_reply_timeout}} system property
> that configures client-side to throw {{org.omg.CORBA.TIMEOUT}} when timeout
> occurs while waiting for reply.
> The problem is different implementation of DII request code:
> {code:java|title=com.sun.corba.se.impl.corba.RequestImpl#doInvocation()}
> } catch( SystemException ex ) {
> _env.exception(ex);
> // NOTE: The exception should not be thrown.
> // However, JDK 1.4 and earlier threw the exception,
> // so we keep the behavior to be compatible.
> throw ex;
> {code}
> {code:java|title=org.jacorb.orb.dii.Request#_invoke()}
> catch (Exception e)
> {
>if (logger.isDebugEnabled ())
>{
> logger.debug("DII Request caught Exception", e);
>}
> env.exception (e);
> break;
> }
> {code}
> PR + test soon
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6923) org.omg.CORBA.TIMEOUT is not handled with Jacorb implementation
[
https://issues.apache.org/jira/browse/CXF-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15307266#comment-15307266
]
ASF GitHub Bot commented on CXF-6923:
-
Github user asfgit closed the pull request at:
https://github.com/apache/cxf/pull/140
> org.omg.CORBA.TIMEOUT is not handled with Jacorb implementation
> ---
>
> Key: CXF-6923
> URL: https://issues.apache.org/jira/browse/CXF-6923
> Project: CXF
> Issue Type: Bug
> Components: CORBA Binding
>Affects Versions: 3.1.6
>Reporter: Grzegorz Grzybek
>Assignee: Freeman Fang
>
> When using Jacorb as ORB implementation at client side:
> {code:java}
> System.setProperty("org.omg.CORBA.ORBClass", "org.jacorb.orb.ORB");
> System.setProperty("org.omg.CORBA.ORBSingletonClass",
> "org.jacorb.orb.ORBSingleton");
> {code}
> we can set {{jacorb.connection.client.pending_reply_timeout}} system property
> that configures client-side to throw {{org.omg.CORBA.TIMEOUT}} when timeout
> occurs while waiting for reply.
> The problem is different implementation of DII request code:
> {code:java|title=com.sun.corba.se.impl.corba.RequestImpl#doInvocation()}
> } catch( SystemException ex ) {
> _env.exception(ex);
> // NOTE: The exception should not be thrown.
> // However, JDK 1.4 and earlier threw the exception,
> // so we keep the behavior to be compatible.
> throw ex;
> {code}
> {code:java|title=org.jacorb.orb.dii.Request#_invoke()}
> catch (Exception e)
> {
>if (logger.isDebugEnabled ())
>{
> logger.debug("DII Request caught Exception", e);
>}
> env.exception (e);
> break;
> }
> {code}
> PR + test soon
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6923) org.omg.CORBA.TIMEOUT is not handled with Jacorb implementation
[
https://issues.apache.org/jira/browse/CXF-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15307295#comment-15307295
]
Freeman Fang commented on CXF-6923:
---
patch applied on behalf of Grzegorz Grzybek with thanks
> org.omg.CORBA.TIMEOUT is not handled with Jacorb implementation
> ---
>
> Key: CXF-6923
> URL: https://issues.apache.org/jira/browse/CXF-6923
> Project: CXF
> Issue Type: Bug
> Components: CORBA Binding
>Affects Versions: 3.1.6
>Reporter: Grzegorz Grzybek
>Assignee: Freeman Fang
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> When using Jacorb as ORB implementation at client side:
> {code:java}
> System.setProperty("org.omg.CORBA.ORBClass", "org.jacorb.orb.ORB");
> System.setProperty("org.omg.CORBA.ORBSingletonClass",
> "org.jacorb.orb.ORBSingleton");
> {code}
> we can set {{jacorb.connection.client.pending_reply_timeout}} system property
> that configures client-side to throw {{org.omg.CORBA.TIMEOUT}} when timeout
> occurs while waiting for reply.
> The problem is different implementation of DII request code:
> {code:java|title=com.sun.corba.se.impl.corba.RequestImpl#doInvocation()}
> } catch( SystemException ex ) {
> _env.exception(ex);
> // NOTE: The exception should not be thrown.
> // However, JDK 1.4 and earlier threw the exception,
> // so we keep the behavior to be compatible.
> throw ex;
> {code}
> {code:java|title=org.jacorb.orb.dii.Request#_invoke()}
> catch (Exception e)
> {
>if (logger.isDebugEnabled ())
>{
> logger.debug("DII Request caught Exception", e);
>}
> env.exception (e);
> break;
> }
> {code}
> PR + test soon
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6923) org.omg.CORBA.TIMEOUT is not handled with Jacorb implementation
[
https://issues.apache.org/jira/browse/CXF-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-6923.
---
Resolution: Fixed
Fix Version/s: 3.2.0
3.1.7
3.0.10
> org.omg.CORBA.TIMEOUT is not handled with Jacorb implementation
> ---
>
> Key: CXF-6923
> URL: https://issues.apache.org/jira/browse/CXF-6923
> Project: CXF
> Issue Type: Bug
> Components: CORBA Binding
>Affects Versions: 3.1.6
>Reporter: Grzegorz Grzybek
>Assignee: Freeman Fang
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> When using Jacorb as ORB implementation at client side:
> {code:java}
> System.setProperty("org.omg.CORBA.ORBClass", "org.jacorb.orb.ORB");
> System.setProperty("org.omg.CORBA.ORBSingletonClass",
> "org.jacorb.orb.ORBSingleton");
> {code}
> we can set {{jacorb.connection.client.pending_reply_timeout}} system property
> that configures client-side to throw {{org.omg.CORBA.TIMEOUT}} when timeout
> occurs while waiting for reply.
> The problem is different implementation of DII request code:
> {code:java|title=com.sun.corba.se.impl.corba.RequestImpl#doInvocation()}
> } catch( SystemException ex ) {
> _env.exception(ex);
> // NOTE: The exception should not be thrown.
> // However, JDK 1.4 and earlier threw the exception,
> // so we keep the behavior to be compatible.
> throw ex;
> {code}
> {code:java|title=org.jacorb.orb.dii.Request#_invoke()}
> catch (Exception e)
> {
>if (logger.isDebugEnabled ())
>{
> logger.debug("DII Request caught Exception", e);
>}
> env.exception (e);
> break;
> }
> {code}
> PR + test soon
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
