Hello all
Now I'm developing STSClient by Apache CXF 2.7.6. But I encountered
following error.
I checked similar problem in this mailing lit, but can't find good answer.
Could anyone give me some advise for this problem.
---test env.---
JRE:
java version "1.6.0"
Java(TM) SE Runtime Environment (
Hi,
My comment inline
－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: @Freeman小屋
On 2013-8-15, at 上午1:47,
I am using Dispatch API to invokeAsync and set the AddressingProperties in
the
requestContext of the dispatch.
i.e. requestContext.put(JAXWSAConstants.CLIENT_ADDRESSING_PROPERTIES,
createAddressingProperties());
I need the service to send the response to a specific port-name and
service-name i.e
We chose WebService because it most fit our development model of programming to
an internal API, then using tools to expose the API to a specific transport.
We use CXF-WS, CXF-RS, some AMF adapters, etc. If you are comfortable with API
programming, this may be the route for you as well.
If you
Tim, Thanks a bunch for prompt reply...
Still my original question ...Why did you choose WebService instead of
WebServiceProvider?
--
View this message in context:
http://cxf.547215.n5.nabble.com/WebServiceProvider-or-WebService-tp5732420p5732458.html
Sent from the cxf-user mailing list archive
Hi Boris,
Comments inline below ...
On Aug 14, 2013, at 10:49 AM, blipsman wrote:
> Hi all,
> I would appreciate any suggestion regarding my question. I just started
> learning CXF with some knowledge of Maven And Spring Framework...
> Trying to make decision about the following questions:
>
>
Hi all,
I would appreciate any suggestion regarding my question. I just started
learning CXF with some knowledge of Maven And Spring Framework...
Trying to make decision about the following questions:
1. Which annotation would be preferable to utilize for my service endpoint:
-@WebServiceProvi
Hi all,
I would appreciate any suggestion regarding my question. I just started
learning CXF with some knowledge of Maven And Spring Framework...
Trying to make decision about the following questions:
1. Which annotation would be preferable to utilize for my service endpoint:
-@WebServiceProvi
Well, i have found a solution to insert a custom "escaper".
First, i need a filterWriter that escapes like i want. I made one
(/CustomXmlEscapingUTFWriter/) based on /com.ctc.wstx.io.UTFTextWriter/. I
add "<" escape in all cases.
I also created a custom /org.codehaus.stax2.io.EscapingWriterFactor
Ok, I'll give it a try. How often are the snapshots published ?
On Wed, Aug 14, 2013 at 4:46 PM, Sergey Beryozkin wrote:
> Hi Robert
>
> I'm hoping I've fixed it as part of
> https://issues.apache.org/jira/browse/CXF-5204
>
> Please try the snapshots a bit later on
> Thanks, Sergey
>
>
> On 14/08
Hi Kiril
I'm hoping I've fixed it as part of
https://issues.apache.org/jira/browse/CXF-5204
Please try the snapshots a bit later on
Thanks, Sergey
On 14/08/13 15:42, Sergey Beryozkin wrote:
Hi
I'm fixing this particular issue right now, you probably have
AbstractCrudResource.
Robert T. has r
Hi Robert
I'm hoping I've fixed it as part of
https://issues.apache.org/jira/browse/CXF-5204
Please try the snapshots a bit later on
Thanks, Sergey
On 14/08/13 09:52, Sergey Beryozkin wrote:
Hi
I'm on it - need to add few more tests only. TypeVariable handling is
wrong at the moment, it check
Thanks for your help. I suspected it was the Weblogic implementation of SAAJ,
but setting the implementation to be otherwise with a system property
-Djavax.xml.soap.MessageFactory= didn't work. I finally just
renamed the Weblogic saaj_1.6 jar to a backup version and that had the same
effect, the i
Let's see the stack-trace?
Colm.
On Wed, Aug 14, 2013 at 2:29 PM, Phil Sladen wrote:
> I am using Sender-Vouches policy and the PolicyBasedWSS4JOutInterceptor is
> invoking AsymmetricBindingHandler.doSignBeforeEncrypt() at the time. No
> more
> error details shown. I am using a SAMLCallbackHand
I am using Sender-Vouches policy and the PolicyBasedWSS4JOutInterceptor is
invoking AsymmetricBindingHandler.doSignBeforeEncrypt() at the time. No more
error details shown. I am using a SAMLCallbackHandler as can be found on the
net. I've searched pretty extensively but not found anything relevant
yes. something like that.
I think there was somone trying to output illegal XML characters or
something like that this way. But I couldn't find his posting anymore.
Then, you can set the context property over the cxf endpoint
configuration (over its properties).
http://cxf.apache.org/docs/jax-ws-
Hi
I'm fixing this particular issue right now, you probably have
AbstractCrudResource.
Robert T. has reported the same issue few days ago.
I'll update this thread once I'm done with my tests
Thanks, Sergey
On 14/08/13 15:35, Kiril Gavrailov wrote:
Hi,
My colleagues and I are making a REST
Hi,
My colleagues and I are making a REST service that should provide CRUD
among couple of different jpa entities.
In order not to repeat code for every new entity we have the following
setup:
1. There is and AbstractCrudResource with crud methods annotated @POST,
@GET, @PUT and @DELETE respective
I took a quick look at the spec and came to the same conclusion.
I've already contacted the 3rd party to ask for some clarification.
2013/8/14 Colm O hEigeartaigh
> Here is the relevant spec quotation (SOAP Message Security 1.1):
>
> All times MUST be in UTC format as specified by the XML Schem
Here is the relevant spec quotation (SOAP Message Security 1.1):
All times MUST be in UTC format as specified by the XML Schema type
(dateTime).
Colm.
On Wed, Aug 14, 2013 at 12:55 PM, Alessio Soldano wrote:
> Usign UTC timezone for timestamps is the right approach (and possibly also
> mandate
What does the failing Timestamp look like?
Colm.
On Wed, Aug 14, 2013 at 1:07 PM, Ted Roeloffzen wrote:
> I'm getting the following error: Expiry date must be in the future.
>
> I think that the service that i'm calling isn't using the UTC-Timezone, but
> the timezone that we're in.
> I'll cont
I'm getting the following error: Expiry date must be in the future.
I think that the service that i'm calling isn't using the UTC-Timezone, but
the timezone that we're in.
I'll contact the party that created the service and ask for some technical
specifications, to see if my assumptions are correc
Using UTC is correct. What is the exact error you are getting? If there is
a time difference of greater than 5 minutes between the two sides then the
Timestamp will not be valid. It doesn't matter what timezone you are in, as
WSS4J will convert it to UTC to compare against the Timestamp value first
Usign UTC timezone for timestamps is the right approach (and possibly
also mandated by specs, I'd need to check though).
On 14/08/13 13:46, Ted Roeloffzen wrote:
Hi All,
I've figured out why it is going wrong.
It seems that UTC is used as the TimeZone and this is 2 hours behind my own.
But ho
Hi All,
I've figured out why it is going wrong.
It seems that UTC is used as the TimeZone and this is 2 hours behind my own.
But how can i make sure that the correct timezone is used?
Ted
2013/8/14 Ted Roeloffzen
> Hi All,
>
> I'm having trouble with the timestamp that is created through CXF
Hi All,
I'm having trouble with the timestamp that is created through CXF.
The TimeStamp that is created is incorrect.
That is, because it is 2 hours in the past.
I assume that it has to do with the locale or timezone that is being used,
but i can't find where to configure it.
kind regards,
Ted
You need to do something like:
((BindingProvider)port).getResponseContext().put(SecurityConstants.IS_BSP_COMPLIANT,
"false");
Colm.
On Wed, Aug 14, 2013 at 11:16 AM, Ted Roeloffzen
wrote:
> Okay, i thought i had to configure the property in the WSS4JInInterceptor.
> If i were to do that, I wou
Okay, i thought i had to configure the property in the WSS4JInInterceptor.
If i were to do that, I would have to configure the entire security-policy
in that interceptor?
I am, however, using the WS-SecurityPolicy, but I'm creating the client
throught the API and i can't seem to figure out how to
I'm not sure what you mean by having to "configure everything by hand". If
you are using WS-SecurityPolicy simply set that property to false as a
JAX-WS property. If you are using WSS4JInInterceptor on its own, then the
value is "isBSPCompliant":
http://ws.apache.org/wss4j/config.html
Colm.
On
HI,
I'm not creating the message without EncodingType, the service that I'm
calling is doing that.
Unfortunately I have no control over that service, that is why I have to
work around it.
I assume that I can set this property in the WSS4JInterceptor, but how can
i set just this property without h
The EncodingType is mandatory according to the Basic Security Profile
specification. You can disable validation of an incoming message against
this specification by setting the property "ws-security.is-bsp-compliant"
to "false". See here for more details:
http://cxf.apache.org/docs/ws-securitypoli
Hi All,
I'm still trying to figure out CXF and WSSE.
At this point, sending a message to the server works fine, aside from the
timestamp not being correct.
But the return message gives a exception.
I get the exception that there is no EncodingType, or at least it says that
the EncodingType is "".
Hi,
I was a bit surprised to see that there is not a way to configure the
Canonicalization algorithm. I have fixed this in WSS4J:
https://issues.apache.org/jira/browse/WSS-476
This will be picked up in the next CXF release. However, note that using
any Canonicalization algorithm apart from the d
The escaping seems to be done in com.ctc.wstx.sw.BufferingXmlWriter
There's a way to add a custom "escaper" by adding a EscapingWriterFactory in
the config of the XMLWriter.
The SimpleNSStreamWiter is created from a XMLOutputFactory. It seems that a
custom XMLOutputFactory can be passed in the con
34 matches
Mail list logo
