Hi,
we're running some WS-Security load tests with Apache CXF 2.2.12 + WSS4J
1.5.10 and might have found a concurrency issue.
We're getting the following exception:
[runTest(bash)] OUT> Caused by: java.util.ConcurrentModificationException
[runTest(bash)] OUT> at
java.util.AbstractList
Hi Alessio,
Very interesting, I haven't seen this problem before. It looks like a
problem in WSS4J - I'm not sure how multiple threads are altering the
same WSDocInfo object.
Would it be possible to check whether it exists with CXF 2.4.0 and
WSS4J 1.6.0? I want to get a WSS4J 1.6.1 release out as
Hi Colm,
yes, I'll try reproducing this locally (the load test is actually run on
a bench environment that can't be moved quickly to cxf 2.4.0 / wss4j
1.6) and let you know asap.
Thanks
Alessio
On 06/01/2011 11:26 AM, Colm O hEigeartaigh wrote:
Hi Alessio,
Very interesting, I haven't seen th
I'm going to relax the default for accepted Timestamps created in the
future from 0 to 60 seconds:
https://issues.apache.org/jira/browse/WSS-291
In the meantime, you can relax the default in configuration via the
following jaxws property:
"ws-security.timestamp.futureTimeToLive"
http://cxf.apac
Hi Shenglin
It's a step in the right direction, thanks, but JMXServer still needs
to be cleaned up quite a bit.
- as I said earlier you have 4 big functions basically duplicating
each other. We can't have a method per every attribute a given MBean
may have. Have a single function only, max two (on
We'd definitely be interested in such a thing. We have a similar thing for
Spring that scans the beans in the context for the annotation, but I don't
think it's used much.
The main "downside" with the auto deployer things is the lack of control of
basic things like the URL that is used. If
On Wednesday, June 01, 2011 4:52:24 AM Alessio Soldano wrote:
> Hi,
> we're running some WS-Security load tests with Apache CXF 2.2.12 + WSS4J
> 1.5.10 and might have found a concurrency issue.
I know this was an issue with 1.5.6 or so that I fixed (or thought I fixed) a
long time ago.It was
OK, here I am with some data.
I've been able to reproduce the problem locally (had to tune the load
test application to run on my laptop and still reproduce the problem
;-)) and it seems CXF 2.4.1-SNAPSHOT + WSS4J 1.6 is not affected.
So I had a look at the commits that went in to the 1.5.x fix
Hi Dan,
On 06/01/2011 05:01 PM, Daniel Kulp wrote:
Is this something that you can create a small maven testcase for to
demonstrate? I'm not really sure what would be going on. :-(
currently this is reproduced using an application that hits a ws
endpoint on a candidate for the next JBoss Ente
On Wednesday, June 01, 2011 11:29:22 AM Alessio Soldano wrote:
> OK, here I am with some data.
> I've been able to reproduce the problem locally (had to tune the load
> test application to run on my laptop and still reproduce the problem
> ;-)) and it seems CXF 2.4.1-SNAPSHOT + WSS4J 1.6 is not aff
Did you get chance to look into this?
On Thu, May 26, 2011 at 2:19 PM, Sergey Beryozkin wrote:
> Sorry, not yet, hoping to do it shortly
>
> Sergey
>
> On Thu, May 26, 2011 at 8:36 PM, Biju Nair wrote:
> > did you get chance to update the patch and test it?
> >
> > Biju
> >
> > On Wed, May 25, 2
I did. It needs a bit more work and I'll need to allocate some time to
add a test and see what needs to be improved, ex, having empty if
branches is not possible. Realistically, it has to be Map> (where Primitive is String or Integer/etc, to handle
m.v=1&m.v=2 or similar), so isMapSupported() shoul
On 06/01/2011 05:57 PM, Daniel Kulp wrote:
No, it's slightly different. Up until that commit, the EnvelopIdResolver was
pretty much just used as a singleton. It didn't have any state and thus a
singleton was created and reused. With that commit, it was given state, but
all the places that us
Hi,
Currently when use wsdl2java, by default the generated exception class
has a serialVersionUID field which use the timestamp when generate
the code, also we have another flag useFQCNForFaultSerialVersionUID
which generate serialVersionUID based on hashcode of the fully
qualified clas
+1 for this.
It makes senses we don't generate the transition serialVersionUID for
the exception.
On 6/2/11 9:18 AM, Freeman Fang wrote:
Hi,
Currently when use wsdl2java, by default the generated exception class
has a serialVersionUID field which use the timestamp when generate the
code, al
-0
I'd actually go a separate direction with this. I would create a new
useTimestampForFaultSerialVersionUID flag or similar, but make the default to
NOT output a serialVersionUID at all in the faults. Let the JDK handle that
based on the normal semantics of the object and such. I just t
Thanks Dan.
This also works for me, create CXF-3566[1] to track it.
[1]https://issues.apache.org/jira/browse/CXF-3566
Freeman
On 2011-6-2, at 上午10:09, Daniel Kulp wrote:
-0
I'd actually go a separate direction with this. I would create a new
useTimestampForFaultSerialVersionUID flag or sim
Hi Dan,
Sorry, I was too eager to reply your thread.
Don't put serialVersionUID in faults class and let JDK to handle it
still can cause problems, as different JDK may generate
serialVersionUID during compile time even the source class is exactly
same, that's not we're expecting, correct?
The more I think about it the more I disagree.
Fundamentally, we are a WEB SERVICES stack. In particular, a JAX-WS and JAX-RS
implementation. Part of that is being completely interopable and
interchangable (when using defaults) with other JAX-WS implementations.
Thus, if we're going to ch
19 matches
Mail list logo
