Re: [VOTE] Apache CXF 2.3.3

[Tomasz Oponowicz]

+1

On Thu, Feb 24, 2011 at 8:28 AM, Freeman Fang  wrote:
> +1
>
> Freeman
> On 2011-2-24, at 上午4:30, Daniel Kulp wrote:
>
>>
>>
>> We've resolved over 50 issues since 2.3.2.   Thus, we really should get
>> 2.3.3 out, especially since 2.3.2 contained an issue preventing it from
>> being used as a  JAX-WS implementation for J2EE
>> containers.
>>
>>
>> List of issues:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12316073
>>
>> The Maven staging areas are at:
>> https://repository.apache.org/content/repositories/orgapachecxf-044/
>>
>> The distributions are in:
>>
>> https://repository.apache.org/content/repositories/orgapachecxf-044/org/apache/cxf/apache-cxf/2.3.3/
>>
>> This release is tagged at:
>> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.3
>>
>>
>> This vote is likely to be open until Monday as I'll be out of town.   If
>> any issues arise, please email me directly.
>>
>>
>> Here is my +1.
>>
>>
>> --
>> Daniel Kulp
>> dk...@apache.org
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>
>
> --
> Freeman Fang
>
> 
>
> FuseSource: http://fusesource.com
> blog: http://freemanfang.blogspot.com
> twitter: http://twitter.com/freemanfang
> Apache Servicemix:http://servicemix.apache.org
> Apache Cxf: http://cxf.apache.org
> Apache Karaf: http://karaf.apache.org
> Apache Felix: http://felix.apache.org
>
>



-- 
Best regards,
Tomasz Oponowicz

Re: [VOTE] Apache CXF 2.3.3

[Alessio Soldano]

+1

Alessio

On 02/23/2011 09:30 PM, Daniel Kulp wrote:


We've resolved over 50 issues since 2.3.2.   Thus, we really should get 2.3.3 
out, especially since 2.3.2 contained an issue preventing it from being used as 
a  JAX-WS implementation for J2EE
containers.


List of issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12316073

The Maven staging areas are at:
https://repository.apache.org/content/repositories/orgapachecxf-044/

The distributions are in:
https://repository.apache.org/content/repositories/orgapachecxf-044/org/apache/cxf/apache-cxf/2.3.3/

This release is tagged at:
http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.3


This vote is likely to be open until Monday as I'll be out of town.   If any 
issues arise, please email me directly.


Here is my +1.





--
Alessio Soldano
Web Service Lead, JBoss

Re: LogBrowser project is on the trunk

[Tomasz Oponowicz]

Hi Sergey,

On Thu, Feb 17, 2011 at 12:34 PM, Sergey Beryozkin  wrote:
> Hi Tomasz
>
> 1. LogBrowser has a showstopper bug which I'm sure is due to the fact we
> just did not look at it for a while :-). Basically, when I go and generate
> the logs, and then click 'refresh' on the endpoint, the browser reports an
> exception.
>>
>> I can't reproduce this (however it doesn't mean that there isn't bug ;) ).
>>
>> To solidify my understanding, use case:
>>
>> 1) Run 'logbrowser' through sample;
>> 2) Go to 'http://localhost:9002/log/browser/LogBrowser.html';
>> 3) Add new endpoint with URL 'http://localhost:9002/log/logs';
>> 4) Select newly created endpoint;
>> 5) In new tab open 'http://localhost:9002/customer-service.html' and
>> add few 'customers';
>> 6) Go back to 'logbrowser';
>> 6) Click 'refresh' link;
>>
>> Expected:
>> List is refreshed and new items are shown.
>>
>> Environment:
>> Firefox 3.6.x
>>
>> Is this use case correct? Thanks for your help.
>>
>
> It is, I'll try again asap - definitely looks like a platform/browser
> specific issue, it's Ubuntu 9 + FireFox 3.6.13 which I upgraded to
> recently using the apt-get facility...So I'm not worried really then,
> but I'll try again, and on Windows too...
>
>> Maybe try with force refresh (i.e. "Ctrl + R"). However I have to add
>> revision number to static resources URL to avoid cache problems.
>>
>>> this is is the only main issue at the moment
>
> 2. Please move ManageEndpoints button either immediately above or below 
> the
> Filter button

 You mean something similar to "original" layout - "Manage endpoint" is
 "attached" to the bottom of the page?

>>>
>>> I'm thinking that given we have a Filter button in the bottom of the
>>> left-side pane, it would be ok to have both 'Manage Endpoints' and
>>> 'Filters' co-located...
>>>
> 3. Remove the Tasks and Endpoints buttons/entries, lets have it the way 
> you
> did it originally. We only need to  see the list of endpoints which will 
> be
> added via "ManageEndpoints", the explorer style is just too complex.

According to 2, 3:

I left old layout, but I fixed CSS. It looks really nice now.

We need layout which is easy to extend. Section "tasks" give us
ability to add new actions later. I think it makes sense to keep this
layout.

> 4. When I go to ManageEndpoints, "Sign Out" leaks into the new panel and
> overlaps with the "Settings" entry,
>>
>> Fixed.
>
> Super
>
>>
 Looks like 2, 3, 4 are layout problems... I have to clean up this. At
 the moment we are using mix of CSS and "table layout". I'm not CSS
 expert so I will fix it by moving problematic parts to "table layout".

In general I committed many layout fixes.

>> I noticed that when you use latest Chrome or Safari, list of logs and
>> detailed view isn't shown. I consider this as a blocker. I will
>> prepare fix for this ASAP.

Fixed.

> May be it's somehow related to what I see with the application
> exception above...
>
> What I will need to do is to provide an abstract utility
> ReadableStorage implementation which can be easily overridden to have
> the file-based logs viewable. I don't think we can make LogBrowser
> perfect and feature-complete by the 2.4.0 is released, but hope users
> will give it a try anyway...
>
> Few other "would be nice to fix" issues - definitely not show stoppers :
> - LogBrowser has the 'embedded' providers, one for servicing the
> gzipped file and another one for unqualified JSON, this would be nice
> to move to the demo's Application (JSONProvider can be configured
> directly to drop the namespaces) - I can look into it
> - Authentication: I've noticed there's AuthenticationRequired
> annotation attached to some of the BootstrapStorage methods - we
> really need to remove this annotation and for now just pop-up a login
> window on the browser start-up.
> Users will be configuring the LogBrowser application as part of the
> real deployments. So what would be good is to write the GWT client
> code such that it only pops up a window  when the initial GET returns
> 401 - can you use CXF WebClient there and do 'Response r =
> webClient.get()' and if r.getStatus() == 401 then pop-up a login
> dialog ? We can deal with this issue later, when we have more time,
> and then we'll also decide whether to support https in cases when the
> authentication is needed or may be do the UT profile, we'll see...

According to your list of tasks please consider also fallowing tasks:

- Removing "Sign in" feature;
- Pros:
 - Simplify implementation;
 - Easy configuration for end user;
 - Every company has got their own internal user
authentication system (LDAP, OpenID, internal SSO etc.);
 - Even if LogBrowser doesn't contain any user authentication
system, it's still very easy to add integration with some
authentication system:
 - Simply interceptor before request rich controller;
 

RE: [VOTE] Apache CXF 2.3.3

[Sean O'Callaghan]

+1

-Original Message-
From: Daniel Kulp [mailto:dk...@apache.org] 
Sent: 23 February 2011 20:31
To: dev@cxf.apache.org
Subject: [VOTE] Apache CXF 2.3.3



We've resolved over 50 issues since 2.3.2.   Thus, we really should get 2.3.3 
out, especially since 2.3.2 contained an issue preventing it from being used as 
a  JAX-WS implementation for J2EE 
containers.   


List of issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12316073

The Maven staging areas are at:
https://repository.apache.org/content/repositories/orgapachecxf-044/

The distributions are in: 
https://repository.apache.org/content/repositories/orgapachecxf-044/org/apache/cxf/apache-cxf/2.3.3/

This release is tagged at:
http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.3


This vote is likely to be open until Monday as I'll be out of town.   If any 
issues arise, please email me directly.


Here is my +1.


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

Re: [VOTE] Apache CXF 2.3.3

[Glen Mazza]

+1

Glen

On 2/23/2011 6:23 PM, Eric Johnson wrote:

+1

On Wed, Feb 23, 2011 at 6:04 PM, Sergey Beryozkin  wrote:

+1

thanks, Sergey

On Wed, Feb 23, 2011 at 8:30 PM, Daniel Kulp  wrote:


We've resolved over 50 issues since 2.3.2.   Thus, we really should get 2.3.3 
out, especially since 2.3.2 contained an issue preventing it from being used as 
a  JAX-WS implementation for J2EE
containers.


List of issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12316073

The Maven staging areas are at:
https://repository.apache.org/content/repositories/orgapachecxf-044/

The distributions are in:
https://repository.apache.org/content/repositories/orgapachecxf-044/org/apache/cxf/apache-cxf/2.3.3/

This release is tagged at:
http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.3


This vote is likely to be open until Monday as I'll be out of town.   If any 
issues arise, please email me directly.


Here is my +1.


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

Re: svn commit: r1074119 - in /cxf/branches/2.3.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport: http/AbstractHTTPDestination.java http/Servlet3ContinuationProvider.java servlet/Serv

[Sergey Beryozkin]

Hi Willem

Are you planning to commit to the trunk ? Just wondering why you
started from the 2.3.x branch...

Cheers, Sergey

On Thu, Feb 24, 2011 at 11:58 AM,   wrote:
> Author: ningjiang
> Date: Thu Feb 24 11:58:26 2011
> New Revision: 1074119
>
> URL: http://svn.apache.org/viewvc?rev=1074119&view=rev
> Log:
> CXF-3362 Fix the issue of CXF Servlet deploying into Servlet3 container
>
> Modified:
>    
> cxf/branches/2.3.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java
>    
> cxf/branches/2.3.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/http/Servlet3ContinuationProvider.java
>    
> cxf/branches/2.3.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/ServletDestination.java
>
> Modified: 
> cxf/branches/2.3.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java
> URL: 
> http://svn.apache.org/viewvc/cxf/branches/2.3.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java?rev=1074119&r1=1074118&r2=1074119&view=diff
> ==
> --- 
> cxf/branches/2.3.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java
>  (original)
> +++ 
> cxf/branches/2.3.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java
>  Thu Feb 24 11:58:26 2011
> @@ -384,7 +384,7 @@ public abstract class AbstractHTTPDestin
>     protected void setupContinuation(Message inMessage,
>                       final HttpServletRequest req,
>                       final HttpServletResponse resp) {
> -        if (isServlet3) {
> +        if (isServlet3 && req.isAsyncSupported()) {
>             inMessage.put(ContinuationProvider.class.getName(),
>                           new Servlet3ContinuationProvider(req, resp, 
> inMessage));
>         }
>
> Modified: 
> cxf/branches/2.3.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/http/Servlet3ContinuationProvider.java
> URL: 
> http://svn.apache.org/viewvc/cxf/branches/2.3.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/http/Servlet3ContinuationProvider.java?rev=1074119&r1=1074118&r2=1074119&view=diff
> ==
> --- 
> cxf/branches/2.3.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/http/Servlet3ContinuationProvider.java
>  (original)
> +++ 
> cxf/branches/2.3.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/http/Servlet3ContinuationProvider.java
>  Thu Feb 24 11:58:26 2011
> @@ -39,6 +39,7 @@ public class Servlet3ContinuationProvide
>     HttpServletResponse resp;
>     Message inMessage;
>
> +
>     public Servlet3ContinuationProvider(HttpServletRequest req,
>                                         HttpServletResponse resp,
>                                         Message inMessage) {
> @@ -64,7 +65,9 @@ public class Servlet3ContinuationProvide
>         Object obj;
>
>         public Servlet3Continuation() {
> -            isNew = !req.isAsyncStarted();
> +            // It looks current Servlet3 implementation request doesn't pass 
> the isAsyncStart
> +            // status to the redispatched request, so we use the attribute 
> to check the statues
> +            isNew = 
> req.getAttribute(AbstractHTTPDestination.CXF_CONTINUATION_MESSAGE) == null;
>             if (isNew) {
>                 
> req.setAttribute(AbstractHTTPDestination.CXF_CONTINUATION_MESSAGE,
>                                  inMessage.getExchange().getInMessage());
> @@ -83,7 +86,6 @@ public class Servlet3ContinuationProvide
>             isNew = false;
>             // Need to get the right message which is handled in the 
> interceptor chain
>             
> inMessage.getExchange().getInMessage().getInterceptorChain().suspend();
> -
>             isPending = true;
>             return true;
>         }
>
> Modified: 
> cxf/branches/2.3.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/ServletDestination.java
> URL: 
> http://svn.apache.org/viewvc/cxf/branches/2.3.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/ServletDestination.java?rev=1074119&r1=1074118&r2=1074119&view=diff
> ==
> --- 
> cxf/branches/2.3.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/ServletDestination.java
>  (original)
> +++ 
> cxf/branches/2.3.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/ServletDestination.java
>  Thu Feb 24 11:58:26 2011
> @@ -30,7 +30,9 @@ import javax.servlet.http.HttpServletRes
>
>  import org.apache.cxf.Bus;
>  import org.apache.cxf.common.logging.LogUtils;
> +import org.apache.cxf.continuations.SuspendedInvocationException;
>  import org.apache.cxf.message.ExchangeImpl;
> +im

Re: [VOTE] Apache CXF 2.3.3

[Colm O hEigeartaigh]

+1.

Colm.

On Thu, Feb 24, 2011 at 11:52 AM, Glen Mazza  wrote:
> +1
>
> Glen
>
> On 2/23/2011 6:23 PM, Eric Johnson wrote:
>>
>> +1
>>
>> On Wed, Feb 23, 2011 at 6:04 PM, Sergey Beryozkin
>>  wrote:
>>>
>>> +1
>>>
>>> thanks, Sergey
>>>
>>> On Wed, Feb 23, 2011 at 8:30 PM, Daniel Kulp  wrote:

 We've resolved over 50 issues since 2.3.2.   Thus, we really should get
 2.3.3 out, especially since 2.3.2 contained an issue preventing it from
 being used as a  JAX-WS implementation for J2EE
 containers.


 List of issues:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12316073

 The Maven staging areas are at:
 https://repository.apache.org/content/repositories/orgapachecxf-044/

 The distributions are in:

 https://repository.apache.org/content/repositories/orgapachecxf-044/org/apache/cxf/apache-cxf/2.3.3/

 This release is tagged at:
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.3


 This vote is likely to be open until Monday as I'll be out of town.   If
 any issues arise, please email me directly.


 Here is my +1.


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

>>
>>
>
>
>

WADLs

[robert]

The Web Application Description Language (WADL) is new to me.

Does CXF support WADLs in any way, relative to the REST style?

Also, what would be more applicable, WADLs or WSDLs in support of 
JMS/RESTful services?


Thanks!

Unmarshalling exception: NaN

[Aaron Ehrensberger]

Hi all,

I'm hoping someone can help me out here...

We recently upgraded CXF from 2.2.3 to 2.3.1.  In doing so, it would appear
that some of our webservices have been broken in the process.

Specifically, the issue we're having is that our client is passing across a
field like NaN, which previously was being
processed fine and we didn't have issues.  However, it would appear that
now, we are throwing an UnmarshallingException.  Debugging through eclipse,
we see an error like...
DefaultValidationEventHandler: [ERROR]: Not a number: NaN
Location: line 49  - that class comes from jaxb-api jar

That said - any ideas what to look for or change?

Thanks,

Aaron

Re: WADLs

[Glen Mazza]

You can at least view the WADL using ?_wadl at the end of the service 
string in a browser.


Unsure, but JMS/REST would seem to be a contradiction, because REST is 
based on the HTTP transport.


Glen

On 2/24/2011 9:17 AM, robert wrote:

The Web Application Description Language (WADL) is new to me.

Does CXF support WADLs in any way, relative to the REST style?

Also, what would be more applicable, WADLs or WSDLs in support of
JMS/RESTful services?

Thanks!

Re: WADLs

[robert]

Thanks for the info... I'm still trying to figure some things out
though...

Looks like WSDLs for REST are supported with WSDL 2.0:
http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/.

So with REST... should the target be in using WSDLs (i.e. 2.0), WADLs,
or neither... or it depends?

And CXF doesn't support WSDL 2.0, correct?

-- Robert

On Thu, 24 Feb 2011 09:24:18 -0500, Glen Mazza 
wrote:
> You can at least view the WADL using ?_wadl at the end of the service
> string in a browser.
> 
> Unsure, but JMS/REST would seem to be a contradiction, because REST
> is based on the HTTP transport.
> 
> Glen
> 
> On 2/24/2011 9:17 AM, robert wrote:
>> The Web Application Description Language (WADL) is new to me.
>>
>> Does CXF support WADLs in any way, relative to the REST style?
>>
>> Also, what would be more applicable, WADLs or WSDLs in support of
>> JMS/RESTful services?
>>
>> Thanks!
>>

Re: WADLs

[Bill Burke]

On 2/24/11 9:17 AM, robert wrote:

Also, what would be more applicable, WADLs or WSDLs in support of
JMS/RESTful services?



Check out HornetQ's REST interface:

http://jboss.org/hornetq/rest

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: Unmarshalling exception: NaN

[Glen Mazza]

Best to ask on the CXF User's list, devs are on both, but many more 
people are on Users.


You can look over the wire to see what is being sent/received[1] 
differently--it could be something different, or in addition to, the NaN 
issue.  I believe we went from JAXB 2.1 to 2.2 between CXF 2.2 and 2.3, 
which could be the problem (You may be able to downgrade to JAXB 2.1 
with CXF 2.3, I'm not sure of the mechanism for that.)  JAXB 
Customizations[2] and/or Handlers/Interceptors[3] to change those NaN 
numbers are possible solutions.  Custom validators[4] might also help, 
and googling the CXF-User's list on Nabble for other ideas.


Sorry I can't be more specific for a solution, perhaps someone else can 
help.


Glen

[1] http://www.jroller.com/gmazza/entry/soap_calls_over_wireshark
[2] http://www.jroller.com/gmazza/entry/customizing_jaxb_artifacts
[3] http://www.jroller.com/gmazza/entry/blog_article_index (Topics #1 
and #2 under Assorted Topics)
[4] 
http://stackoverflow.com/questions/2195034/server-side-xml-validation-with-cxf-webservice


On 2/24/2011 9:22 AM, Aaron Ehrensberger wrote:

Hi all,

I'm hoping someone can help me out here...

We recently upgraded CXF from 2.2.3 to 2.3.1.  In doing so, it would appear
that some of our webservices have been broken in the process.

Specifically, the issue we're having is that our client is passing across a
field likeNaN, which previously was being
processed fine and we didn't have issues.  However, it would appear that
now, we are throwing an UnmarshallingException.  Debugging through eclipse,
we see an error like...
DefaultValidationEventHandler: [ERROR]: Not a number: NaN
Location: line 49  - that class comes from jaxb-api jar

That said - any ideas what to look for or change?

Thanks,

Aaron

Re: WADLs

[Sergey Beryozkin]

>> Check out HornetQ's REST interface:
>>
>> http://jboss.org/hornetq/rest
>>
> This is of course a fine effort, but it's off-topic for the CXF dev list :-)

though supporting the interface you've built for HornetQ might be an
interesting option - but I guess it would be more of interest to the
ActiveMQ team

>
> thanks, Sergey
>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>

Re: WADLs

[Sergey Beryozkin]

Hi Bill

On Thu, Feb 24, 2011 at 2:45 PM, Bill Burke  wrote:
>
>
> On 2/24/11 9:17 AM, robert wrote:
>>
>> Also, what would be more applicable, WADLs or WSDLs in support of
>> JMS/RESTful services?
>>
>
> Check out HornetQ's REST interface:
>
> http://jboss.org/hornetq/rest
>
This is of course a fine effort, but it's off-topic for the CXF dev list :-)

thanks, Sergey

> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>

WSIF JMS EXtensions

[robert]

Is Apache WSIF JMS extensions considered dead too (in addition to the 
main project Apache WSIF) ? 
http://ws.apache.org/wsif/providers/wsdl_extensions/jms_extension.html


Exactly what is going on with WSIF?  Is it still hanging on?  Or did 
someone make the move to make it a TLP and retire it?


If it is retired... would it still be reachable for users who want to 
use it unsupported?


Thanks,
Robert


FROM CXF USERS LIST:


That, or graduate WSIF to a TLP before giving it the heave-ho...   :)

Glen

On 01.02.2011 19:42, Benson Margulies wrote:
That wasn't a binding veto. The real problem is that the attic does
not accept subprojects, only TLPs. So we kind of ran aground. We need
to build our own attic, and the amount of volunteer labor available at
WS is very small.

On Tue, Feb 1, 2011 at 7:18 PM, Dennis Sosnoski  
wrote:

I take it back - either this was an invalid veto, or it was missed:
http://marc.info/?l=wsif-dev&m=128198507114001&w=2 So it looks like
there should have been a resolution to retire WSIF back in August. I
haven't seen anything more on this since, but hopefully it's in 
progress.


- Dennis


On 02/02/2011 01:15 PM, Dennis Sosnoski wrote:
There was an attempt to do this just a few months ago, but it 
apparently

was vetoed:
http://permalink.gmane.org/gmane.comp.apache.webservices.wsif.devel/550
I don't know the reason behind the veto, nor was there any follow-up
that I've seen.

- Dennis


On 02/02/2011 12:17 PM, Glen Mazza wrote:

Yes, it may be time for placing it in Apache Attic.

On 01.02.2011 18:00, Gary Gregory wrote:

Sound like this project page should be better annotated or the
project moved to some dormant area of the site...

Gary Gregory
Senior Software Engineer
Rocket Software
3340 Peachtree Road, Suite 820 • Atlanta, GA 30326 • USA
Tel: +1.404.760.1560
Email: ggreg...@seagullsoftware.com
Web: seagull.rocketsoftware.com




-Original Message-
From: Dennis Sosnoski [mailto:d...@sosnoski.com]
Sent: Tuesday, February 01, 2011 16:05
To: us...@cxf.apache.org
Subject: Re: WSIF and CXF

WSIF was an early attempt to generalize access to web services, at
a
time when the standard APIs were working at the DOM level. The web
services world has moved on, though, and WSIF fell by the wayside
-
it's
been>7 years since the last release, so your chances of doing
much
that's useful with it at this point is probably close to nil.

- Dennis

Dennis M. Sosnoski
Java SOA and Web Services
Consulting
Axis2/CXF/Metro SOA and Web Services Training

Web Services Jump-Start


On 02/02/2011 06:32 AM, robert wrote:

Is Apache WSIF dead (in the sense of no longer being supported
and
sparsely used)? http://ws.apache.org/wsif/

Reference:
http://www.theserverside.com/discussions/thread.tss?thread_id=42658

If not, does CXF currently support it or has plans to support
it?

Thanks!





--
Glen Mazza
Software Engineer, Talend (http://www.talend.com)
blog: http://www.jroller.com/gmazza

Re: WADLs

[Sergey Beryozkin]

Hi

On Thu, Feb 24, 2011 at 2:37 PM, robert  wrote:
>
> Thanks for the info... I'm still trying to figure some things out
> though...
>
> Looks like WSDLs for REST are supported with WSDL 2.0:
> http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/.
>
> So with REST... should the target be in using WSDLs (i.e. 2.0), WADLs,
> or neither... or it depends?
>

CXF supports WADL and we plan to enhance the WADL support for it to be
applied to the server side development.

> And CXF doesn't support WSDL 2.0, correct?

No, it does not. However, WADL is superior to WSDL 2.0 RESTful
descriptions, IMHO. If you do prefer WSDL-first for developing SOAP
services and thus also want to use the same document for generating
the RESTful annotations then applying CXF JAX-RS user models can
easily compensate for the fact we do not do WSDL 2.0

cheers, Sergey

>
> -- Robert
>
> On Thu, 24 Feb 2011 09:24:18 -0500, Glen Mazza 
> wrote:
>> You can at least view the WADL using ?_wadl at the end of the service
>> string in a browser.
>>
>> Unsure, but JMS/REST would seem to be a contradiction, because REST
>> is based on the HTTP transport.
>>
>> Glen
>>
>> On 2/24/2011 9:17 AM, robert wrote:
>>> The Web Application Description Language (WADL) is new to me.
>>>
>>> Does CXF support WADLs in any way, relative to the REST style?
>>>
>>> Also, what would be more applicable, WADLs or WSDLs in support of
>>> JMS/RESTful services?
>>>
>>> Thanks!
>>>
>
>

Re: WADLs

[robert]

I'm looking at the ActiveMQ REST Interface documentation now...

http://activemq.apache.org/rest.html

Thanks!
Robert

On Thu, 24 Feb 2011 15:19:19 +, Sergey Beryozkin
 wrote:
>>> Check out HornetQ's REST interface:
>>>
>>> http://jboss.org/hornetq/rest
>>>
>> This is of course a fine effort, but it's off-topic for the CXF dev list :-)
> 
> though supporting the interface you've built for HornetQ might be an
> interesting option - but I guess it would be more of interest to the
> ActiveMQ team
> 
>>
>> thanks, Sergey
>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>

Mailing List Clutter

[robert]

My bad... I posted the same message to the users and dev mailing 
lists... as I thought the users post did not go through (as I thought 
the delay meant I was unsubscribed).


... sorry about the clutter... on this one too.

-- Robert

Re: WADLs

[Bill Burke]

I think you'll find that the reliability guarantees just don't exist in 
ActiveMQ's REST interface and that it is very feature-light.  (FYI, not 
saying ActiveMQ can't guarantee reliability, just that its REST 
interface is kinda weak).



On 2/24/11 10:27 AM, robert wrote:

I'm looking at the ActiveMQ REST Interface documentation now...

http://activemq.apache.org/rest.html

Thanks!
Robert

On Thu, 24 Feb 2011 15:19:19 +, Sergey Beryozkin
  wrote:

Check out HornetQ's REST interface:

http://jboss.org/hornetq/rest


This is of course a fine effort, but it's off-topic for the CXF dev list :-)


though supporting the interface you've built for HornetQ might be an
interesting option - but I guess it would be more of interest to the
ActiveMQ team



thanks, Sergey


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com







--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

SOAP over JMS and CXF.

[robert]

CXF supports SOAP over JMS; http://www.w3.org/TR/soapjms/.

Should the bindings and service extensions defined by this spec be 
better suited in a supported WSDL or WADL?


I assume WADL as supported by CXF?

Thanks!

Re: SOAP over JMS and CXF.

[Sergey Beryozkin]

Hi

On Thu, Feb 24, 2011 at 3:48 PM, robert  wrote:
> CXF supports SOAP over JMS; http://www.w3.org/TR/soapjms/.
>
> Should the bindings and service extensions defined by this spec be better
> suited in a supported WSDL or WADL?
>
> I assume WADL as supported by CXF?

Yes but only JAX-RS endpoints will support WADL. The actual endpoint
may be JMS enabled but the generated WADLs will be of interest to
HTTP-aware consumers only. CXF JAX-RS endpoints can get the JMS
messages routed to them but JMS messages containing SOAP-over-JMS
properties are not supported. You might want to have a look at the
jaxrs-http-jms demo in the Talend SF 2.3.2.0 examples [1], plain JMS
API is currently used on the client side, though in theory we can use
JAX-RS proxies alongside with WADL extensions...

cheers, Sergey

[1] http://www.talend.com/resources/documentation.php

>
> Thanks!
>
>

Re: WSIF JMS EXtensions

[Glen Mazza]

Actually, Benson, that might not be the case (I hope it isn't) -- if you 
look on the Attic: http://attic.apache.org/ they have four Jakarta 
subprojects listed, and none of the four were TLPs.  (Only Jakarta 
itself is.)  Same with Crimson (XML TLP) I suppose.


Glen


On 01.02.2011 19:42, Benson Margulies wrote:
That wasn't a binding veto. The real problem is that the attic does
not accept subprojects, only TLPs. So we kind of ran aground. We need
to build our own attic, and the amount of volunteer labor available at
WS is very small.

On Tue, Feb 1, 2011 at 7:18 PM, Dennis Sosnoski
wrote:
I take it back - either this was an invalid veto, or it was missed:
http://marc.info/?l=wsif-dev&m=128198507114001&w=2 So it looks like
there should have been a resolution to retire WSIF back in August. I
haven't seen anything more on this since, but hopefully it's in
progress.

- Dennis


On 02/02/2011 01:15 PM, Dennis Sosnoski wrote:
There was an attempt to do this just a few months ago, but it
apparently
was vetoed:
http://permalink.gmane.org/gmane.comp.apache.webservices.wsif.devel/550
I don't know the reason behind the veto, nor was there any follow-up
that I've seen.

- Dennis


On 02/02/2011 12:17 PM, Glen Mazza wrote:

Yes, it may be time for placing it in Apache Attic.

On 01.02.2011 18:00, Gary Gregory wrote:

Sound like this project page should be better annotated or the
project moved to some dormant area of the site...

Gary Gregory
Senior Software Engineer
Rocket Software
3340 Peachtree Road, Suite 820 • Atlanta, GA 30326 • USA
Tel: +1.404.760.1560
Email: ggreg...@seagullsoftware.com
Web: seagull.rocketsoftware.com




-Original Message-
From: Dennis Sosnoski [mailto:d...@sosnoski.com]
Sent: Tuesday, February 01, 2011 16:05
To: us...@cxf.apache.org
Subject: Re: WSIF and CXF

WSIF was an early attempt to generalize access to web services, at
a
time when the standard APIs were working at the DOM level. The web
services world has moved on, though, and WSIF fell by the wayside
-
it's
been>7 years since the last release, so your chances of doing
much
that's useful with it at this point is probably close to nil.

- Dennis

Dennis M. Sosnoski
Java SOA and Web Services
Consulting
Axis2/CXF/Metro SOA and Web Services Training

Web Services Jump-Start


On 02/02/2011 06:32 AM, robert wrote:

Is Apache WSIF dead (in the sense of no longer being supported
and
sparsely used)? http://ws.apache.org/wsif/

Reference:
http://www.theserverside.com/discussions/thread.tss?thread_id=42658

If not, does CXF currently support it or has plans to support
it?

Thanks!





--
Glen Mazza
Software Engineer, Talend (http://www.talend.com)
blog: http://www.jroller.com/gmazza

Re: Unmarshalling exception: NaN

[Daniel Kulp]

On Thursday 24 February 2011 9:22:28 AM Aaron Ehrensberger wrote:
> Hi all,
> 
> I'm hoping someone can help me out here...
> 
> We recently upgraded CXF from 2.2.3 to 2.3.1.  In doing so, it would appear
> that some of our webservices have been broken in the process.
> 
> Specifically, the issue we're having is that our client is passing across a
> field like NaN, which previously was being
> processed fine and we didn't have issues.  However, it would appear that
> now, we are throwing an UnmarshallingException.  Debugging through eclipse,
> we see an error like...
> DefaultValidationEventHandler: [ERROR]: Not a number: NaN
> Location: line 49  - that class comes from jaxb-api jar
> 
> That said - any ideas what to look for or change?

If it's an integer, than NaN is not a valid value and the exception is what 
should be occuring.   Ignoring that could have been considered a bug in 2.2.3.  
 

That said, you can set a property of:
 "set-jaxb-validation-event-handler"  to "false"
on the endpoint and it would again be ignored.


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

What does CXF use in place of WSDL JMS Extension ?

[robert]

Does CXF use something in place of the WSDL JMS Extension and this 
namespace: http://schemas.xmlsopa.org/wsdl/jms?


Thanks!

Re: What does CXF use in place of WSDL JMS Extension ?

[Glen Mazza]

The User's list would be more appropriate for this question, also is it 
not already answered within our user's guide?


Glen

On 2/24/2011 2:26 PM, robert wrote:

Does CXF use something in place of the WSDL JMS Extension and this
namespace: http://schemas.xmlsopa.org/wsdl/jms?

Thanks!

Re: What does CXF use in place of WSDL JMS Extension ?

[robert]

I'll take a look and try to post to the appropriate forums, thanks!

-- Robert

On Thu, 24 Feb 2011 14:29:05 -0500, Glen Mazza 
wrote:
> The User's list would be more appropriate for this question, also is
> it not already answered within our user's guide?
> 
> Glen
> 
> On 2/24/2011 2:26 PM, robert wrote:
>> Does CXF use something in place of the WSDL JMS Extension and this
>> namespace: http://schemas.xmlsoap.org/wsdl/jms?
>>
>> Thanks!
>>

Re: Unmarshalling exception: NaN

[Aaron Ehrensberger]

Perfect!

It would appear that we need to investigate our flex client then because it
seems to be passing along valid NaNs for floats and doubles, but it's also
passing them for integers and we'll need to figure that out.

Thanks for the help.

Aaron


On Thu, Feb 24, 2011 at 2:06 PM, Daniel Kulp  wrote:

> On Thursday 24 February 2011 9:22:28 AM Aaron Ehrensberger wrote:
> > Hi all,
> >
> > I'm hoping someone can help me out here...
> >
> > We recently upgraded CXF from 2.2.3 to 2.3.1.  In doing so, it would
> appear
> > that some of our webservices have been broken in the process.
> >
> > Specifically, the issue we're having is that our client is passing across
> a
> > field like NaN, which previously was being
> > processed fine and we didn't have issues.  However, it would appear that
> > now, we are throwing an UnmarshallingException.  Debugging through
> eclipse,
> > we see an error like...
> > DefaultValidationEventHandler: [ERROR]: Not a number: NaN
> > Location: line 49  - that class comes from jaxb-api jar
> >
> > That said - any ideas what to look for or change?
>
> If it's an integer, than NaN is not a valid value and the exception is what
> should be occuring.   Ignoring that could have been considered a bug in
> 2.2.3.
>
> That said, you can set a property of:
>  "set-jaxb-validation-event-handler"  to "false"
> on the endpoint and it would again be ignored.
>
>
> --
> Daniel Kulp
> dk...@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>



-- 
Aaron Ehrensberger
Software Architect
DocFinity® by Optical Image Technology, Inc.
100 Oakwood Avenue, State College, PA  16803
ph: 814.238.0038 ext. 270
fax: 814.238.0011
email: aehrensber...@docfinity.com
web: www.docfinity.com

Re: What does CXF use in place of WSDL JMS Extension ?

[Daniel Kulp]

On Thursday 24 February 2011 2:26:08 PM robert wrote:
> Does CXF use something in place of the WSDL JMS Extension and this
> namespace: http://schemas.xmlsopa.org/wsdl/jms?

At the last minute, the spec was "changed" so the namespace that is supposed 
to be used is:

http://www.w3.org/2010/soapjms/

which is what CXF uses.  See the jms-spec-demo in the kit for an example.



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

Re: What does CXF use in place of WSDL JMS Extension ?

[robert]

Thanks... that namespace isn't on this page though:
http://cxf.apache.org/docs/schemas-and-namespaces.html.

-- Robert

On Thu, 24 Feb 2011 15:06:44 -0500, Daniel Kulp 
wrote:
> On Thursday 24 February 2011 2:26:08 PM robert wrote:
>> Does CXF use something in place of the WSDL JMS Extension and this
>> namespace: http://schemas.xmlsopa.org/wsdl/jms?
> 
> At the last minute, the spec was "changed" so the namespace that is supposed 
> to be used is:
> 
> http://www.w3.org/2010/soapjms/
> 
> which is what CXF uses.  See the jms-spec-demo in the kit for an example.

Re: SOAP over JMS and CXF.

[Willem Jiang]

CXF JMS transport supports JMS URI which is part of JMS over SOAP spec
out of box. I think you can use it with JAXRS frontend without any
trouble.

2011/2/24, robert :
> CXF supports SOAP over JMS; http://www.w3.org/TR/soapjms/.
>
> Should the bindings and service extensions defined by this spec be
> better suited in a supported WSDL or WADL?
>
> I assume WADL as supported by CXF?
>
> Thanks!
>
>

-- 
从我的移动设备发送