Re: [VOTE] buildutils and xjc-utils

[Freeman Fang]

+1
－
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: http://weibo.com/u/1473905042

On 2012-11-28, at 上午3:42, Daniel Kulp wrote:

> 
> To prepare for the 2.7.1 release (likely next week), I'd like to get releases 
> of the buildutils and xjc-utils things.
> 
> Changes:
> buildutils:
> * Remove the DoubleCheckedLogging stuff from checkstyle as the latest version 
> of checkstyle no longer supports this
> * Update the xml2fastinfoset-plugin to have the m2e lifecycle things
> 
> xjc-utils:
> * Update the plugin to have the m2e lifecycle bindings
> * Update the plugin to use the BuildContext to report warnings/errors from 
> JAXB.   Allows warnings to propagate into the eclipse warning system.
> 
> 
> Staging area:
> https://repository.apache.org/content/repositories/orgapachecxf-087/
> 
> Tags:
> http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.6.1/
> http://svn.apache.org/repos/asf/cxf/build-utils/tags/cxf-build-utils-2.5.0/
> 
> 
> Here is my +1.   
> 
> -- 
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
> 

Fediz IDP refactored

[Oliver Wulff]

Hi there

I've refactored the Fediz IDP and I'd like your feedback. The IDP is based on a 
state machine which re-uses Servlet Filters to build up the processing chain 
but an abstract AbstractAuthFilter handles all the state related processing.

I was struggeling a little bit how to define the states. An enum is to static 
whereas a string to error prone. I'd like that users have the option to extend 
the IDP without having to patch the enum class to introduce new states.

I've defined the default states in a enum but all processing is based on 
strings.

It's now much easier to add the SAML profile as only the FederationFilter and 
FederationPostFilter has to be rewritten.

Another topic I'd like your opinion is the pre-state condition. A filter is 
called only if the one state condition is met. If a filter could support 
depending on different states, there is also only one FederationFilter needed.

Looking forward for your feedback.

Thanks
Oli




--

Oliver Wulff

Blog: http://owulff.blogspot.com
Solution Architect
http://coders.talend.com

Talend Application Integration Division 
http://www.talend.com

[VOTE] buildutils and xjc-utils

[Daniel Kulp]

To prepare for the 2.7.1 release (likely next week), I'd like to get releases 
of the buildutils and xjc-utils things.

Changes:
buildutils:
* Remove the DoubleCheckedLogging stuff from checkstyle as the latest version 
of checkstyle no longer supports this
* Update the xml2fastinfoset-plugin to have the m2e lifecycle things

xjc-utils:
* Update the plugin to have the m2e lifecycle bindings
* Update the plugin to use the BuildContext to report warnings/errors from 
JAXB.   Allows warnings to propagate into the eclipse warning system.


Staging area:
https://repository.apache.org/content/repositories/orgapachecxf-087/

Tags:
http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.6.1/
http://svn.apache.org/repos/asf/cxf/build-utils/tags/cxf-build-utils-2.5.0/


Here is my +1.   

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

Re: SVN trunk update issue

[Sergey Beryozkin]

I did a completely fresh checkout with the local updates patched and 
applied to the new trunk and it worked, does not work against the old 
trunk though, guess I had it corrupted somehow...


Cheers, Sergey
On 27/11/12 13:32, Sergey Beryozkin wrote:

On 27/11/12 13:27, Romain Manni-Bucau wrote:

Hi,

do you use us or eu svn?

maybe switch to us if you use eu proxy



Switching between the two addresses does not help, must be something
else I guess

Thanks, Sergey


*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog:
**http://rmannibucau.wordpress.com/*
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*




2012/11/27 Sergey Beryozkin


Hi

I'm trying to update the trunk with SVN and getting the following:

svn: Checksum mismatch while updating 'rt/core/src/main/java/org/**
apache/cxf/feature/transform/**XSLTInInterceptor.java'; expected: '**
8031abcfbea05e46f6a2b1dab30209**56', actual: '**
d41d8cd98f00b204e9800998ecf842**7e'

Any ideas how this can be fixed ?

Cheers, Sergey

Re: SVN trunk update issue

[Sergey Beryozkin]

On 27/11/12 13:27, Romain Manni-Bucau wrote:

Hi,

do you use us or eu svn?

maybe switch to us if you use eu proxy



Switching between the two addresses does not help, must be something 
else I guess


Thanks, Sergey


*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*




2012/11/27 Sergey Beryozkin


Hi

I'm trying to update the trunk with SVN and getting the following:

svn: Checksum mismatch while updating 'rt/core/src/main/java/org/**
apache/cxf/feature/transform/**XSLTInInterceptor.java'; expected: '**
8031abcfbea05e46f6a2b1dab30209**56', actual: '**
d41d8cd98f00b204e9800998ecf842**7e'

Any ideas how this can be fixed ?

Cheers, Sergey

Re: SVN trunk update issue

[Romain Manni-Bucau]

Hi,

do you use us or eu svn?

maybe switch to us if you use eu proxy

*Romain Manni-Bucau*
*Twitter: @rmannibucau *
*Blog: **http://rmannibucau.wordpress.com/*
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*




2012/11/27 Sergey Beryozkin 

> Hi
>
> I'm trying to update the trunk with SVN and getting the following:
>
> svn: Checksum mismatch while updating 'rt/core/src/main/java/org/**
> apache/cxf/feature/transform/**XSLTInInterceptor.java'; expected: '**
> 8031abcfbea05e46f6a2b1dab30209**56', actual: '**
> d41d8cd98f00b204e9800998ecf842**7e'
>
> Any ideas how this can be fixed ?
>
> Cheers, Sergey
>

SVN trunk update issue

[Sergey Beryozkin]

Hi

I'm trying to update the trunk with SVN and getting the following:

svn: Checksum mismatch while updating 
'rt/core/src/main/java/org/apache/cxf/feature/transform/XSLTInInterceptor.java'; 
expected: '8031abcfbea05e46f6a2b1dab3020956', actual: 
'd41d8cd98f00b204e9800998ecf8427e'


Any ideas how this can be fixed ?

Cheers, Sergey

Re: CXF Continuations Not Portable Issue

[Sergey Beryozkin]

Hi Richard
On 27/11/12 08:12, Richard Opalka wrote:

Hi Sergey,

On 11/26/2012 04:58 PM, Sergey Beryozkin wrote:

Hi Richard
On 26/11/12 15:05, Richard Opalka wrote:

Hi Sergey,

On 11/26/2012 02:57 PM, Richard Opalka wrote:

Hi Sergey,

On 11/26/2012 01:31 PM, Sergey Beryozkin wrote:

Hi Richard
On 26/11/12 12:29, Richard Opalka wrote:

Hi Sergey,


On 11/26/2012 01:21 PM, Sergey Beryozkin wrote:

Hi Richard
On 26/11/12 12:15, Richard Opalka wrote:

Dear CXF developers,

   I'm analyzing our recent CXF continuation related failures
in CI
and I identified the following problem:

SVN commit id: 1409193

introduced

---
@@ -57,32 +57,30 @@ public class Servlet3ContinuationProvider
implements
ContinuationProvider {

 if (continuation == null) {
 continuation = new Servlet3Continuation();
+} else {
+continuation.startAsyncAgain();
 }
 return continuation;
 }
---

method call that causes our JBossWeb to throw IllegalStateException.
According to startAsync() javadoc for Throws:

http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#startAsync%28%29




---
Throws:
IllegalStateException - if this request is within the
scope of a
filter or servlet that does not support asynchronous operations
(that
is, isAsyncSupported() returns false), or if this method is called
again
without any asynchronous dispatch (resulting from one of the
AsyncContext#dispatch methods), is called outside the scope of
any such
dispatch, or is called again within the scope of the same
dispatch, or
if the response has already been closed
---

JBossWeb is strictly following these ISE guidelines (is not lenient
like e.g. Jakarta Tomcat).


What would you say about
"Subsequent invocations of this method, or its overloaded variant,
will
return the same AsyncContext instance, reinitialized as
appropriate. " ?

Without this call I can not have the test doing multiple timeouts
on the
same continuation working...


Makes sense to me. I had a look to our JBoss Web code again and I
noticed one suspicious line there - I'm going to discuss it with our
folks.



Oh, thanks for that, I've just sent one more follow-up, sorry about
the
noise, should've waited :-)


Let's see what our Servlet experts will say -
https://issues.jboss.org/browse/JBWEB-256


Our JBoss Web guru is saying JBoss Web impl. is correct.


I'd appreciate to see more concrete clarifications, regarding the
following two points:

- the documentation clearly says that repeated calls of startAsync()
return the same instance.
- what does it mean to have called startAsync() called on the same
dispatch, does it apply to a current thread dispatch or to the whole
suspended continuation process ?

To be honest, the positive statement on the multiple startAsync calls
makes me think the ISE case applies to this method called multiple times
during the same thread dispatch...

Thanks, Sergey


Unfortunately I'm not servlet expert :( But Remy suggested (see
JBWEB-256 comments):

'Feel free to seek further clarification from the specification expert
groups if you like.'


First of all, thanks for validating the proposed fix from Dan, your 
patch has been applied.


I think at the moment the only argument I have is "it works with Tomcat 
& Jetty" which is not a strong enough proof that ISE should not be 
actually reported :-), so the fix is a good compromise. I'd love to see 
the clear statement from the servlet experts, but I wonder if it is even 
possible to get them to answer :-)


Thanks, Sergey



Cheers,

Rio







Cheers, Sergey





The last issue that I identified with
Servlet3ContinuationProvider is
the isNew flag has incorrect initial value - it should be *true*.

Sure - needs to be fixed

Re: CXF Continuations Not Portable Issue

[Richard Opalka]

Hi Sergey,

On 11/26/2012 04:58 PM, Sergey Beryozkin wrote:
> Hi Richard
> On 26/11/12 15:05, Richard Opalka wrote:
>> Hi Sergey,
>>
>> On 11/26/2012 02:57 PM, Richard Opalka wrote:
>>> Hi Sergey,
>>>
>>> On 11/26/2012 01:31 PM, Sergey Beryozkin wrote:
 Hi Richard
 On 26/11/12 12:29, Richard Opalka wrote:
> Hi Sergey,
>
>
> On 11/26/2012 01:21 PM, Sergey Beryozkin wrote:
>> Hi Richard
>> On 26/11/12 12:15, Richard Opalka wrote:
>>> Dear CXF developers,
>>>
>>>   I'm analyzing our recent CXF continuation related failures
>>> in CI
>>> and I identified the following problem:
>>>
>>> SVN commit id: 1409193
>>>
>>> introduced
>>>
>>> ---
>>> @@ -57,32 +57,30 @@ public class Servlet3ContinuationProvider
>>> implements
>>> ContinuationProvider {
>>>
>>> if (continuation == null) {
>>> continuation = new Servlet3Continuation();
>>> +} else {
>>> +continuation.startAsyncAgain();
>>> }
>>> return continuation;
>>> }
>>> ---
>>>
>>> method call that causes our JBossWeb to throw IllegalStateException.
>>> According to startAsync() javadoc for Throws:
>>>
>>> http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#startAsync%28%29
>>>
>>>
>>>
>>>
>>> ---
>>> Throws:
>>>IllegalStateException - if this request is within the
>>> scope of a
>>> filter or servlet that does not support asynchronous operations
>>> (that
>>> is, isAsyncSupported() returns false), or if this method is called
>>> again
>>> without any asynchronous dispatch (resulting from one of the
>>> AsyncContext#dispatch methods), is called outside the scope of
>>> any such
>>> dispatch, or is called again within the scope of the same
>>> dispatch, or
>>> if the response has already been closed
>>> ---
>>>
>>> JBossWeb is strictly following these ISE guidelines (is not lenient
>>> like e.g. Jakarta Tomcat).
>>
>> What would you say about
>> "Subsequent invocations of this method, or its overloaded variant,
>> will
>> return the same AsyncContext instance, reinitialized as
>> appropriate. " ?
>>
>> Without this call I can not have the test doing multiple timeouts
>> on the
>> same continuation working...
>
> Makes sense to me. I had a look to our JBoss Web code again and I
> noticed one suspicious line there - I'm going to discuss it with our
> folks.
>

 Oh, thanks for that, I've just sent one more follow-up, sorry about 
 the
 noise, should've waited :-)
>>>
>>> Let's see what our Servlet experts will say -
>>> https://issues.jboss.org/browse/JBWEB-256
>>
>> Our JBoss Web guru is saying JBoss Web impl. is correct.
>>
> I'd appreciate to see more concrete clarifications, regarding the
> following two points:
> 
> - the documentation clearly says that repeated calls of startAsync()
> return the same instance.
> - what does it mean to have called startAsync() called on the same
> dispatch, does it apply to a current thread dispatch or to the whole
> suspended continuation process ?
> 
> To be honest, the positive statement on the multiple startAsync calls
> makes me think the ISE case applies to this method called multiple times
> during the same thread dispatch...
> 
> Thanks, Sergey

Unfortunately I'm not servlet expert :( But Remy suggested (see
JBWEB-256 comments):

'Feel free to seek further clarification from the specification expert
groups if you like.'

Cheers,

Rio

> 
>>>

 Cheers, Sergey

>>
>>>
>>> The last issue that I identified with
>>> Servlet3ContinuationProvider is
>>> the isNew flag has incorrect initial value - it should be *true*.
>> Sure - needs to be fixed
>
> Thanks
>
>>
>> Thanks, Sergey
>>
>>>
>>> Cheers,
>>>
>>> Rio
>>>
>>
>
>


>>>
>>>
>>
>>
> 
> 


-- 
Richard Opalka
Principal Software Engineer
JBoss, by Red Hat
Cell: +420 731 186 942