hi, i use a (JaxWS)HttpServletRequestFilter service to intercept WS calls to my application. it will only intercept calls that have the url pattern of the provided WS that can be configured. and i'm using metro too. we switched from cxf to metro because it was easier to work with jaxb-binding overrides...
g, kris Von: Peter Stavrinides <p.stavrini...@albourne.com> An: Tapestry users <users@tapestry.apache.org> Datum: 30.08.2010 14:59 Betreff: Re: OT: Web Services Hi Jim I evaluated quite a few Java WS stacks and was between CXF and Metro, but in the end I chose metro, but to be honest there was very little to choose btw the two... so I would suggest those two as the leading Java WS stacks. Both support maven and are very complete in terms of how much of the web service set of standards they support. Metro implements JAXWS 2.1 and JAXB2.2, so if the marketing babble is to be trusted its 'meant' to be higher performing and more extensible, but I haven't tested that claim yet. In any event it has an impressive array of security features. It also ships with the standard glassfish installation, which means no server configuration is needed if you go that route, I installed it though with Tomcat, it was as easy as executing a script... not too hard at all. Depending how you wish to approach you applications, you can use annotations for the meta programming, and avoid a lot of the messy xml. I found it to be really clean and the closest to Microsofts .Net platform implementation which is IMHO a very good implementation of Web Services ...at least more impressive than anything I have seen in the Java community, but I feel the gap is closing slowly. To integrate with Tapestry I simply overrode Tapestry filter... I am not aware of any more elegant approach, although I made a few inquiries on this list in the past. Cheers, Peter ----- Original Message ----- From: "Jim O'Callaghan" <jc1000...@yahoo.co.uk> To: "Tapestry users" <users@tapestry.apache.org> Sent: Monday, 30 August, 2010 10:52:44 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: RE: OT: Web Services Kalle, Daniel, Thanks for the responses. Good to know that there are positive experiences with CXF. It's probably the front-runner for me at the moment, but will keep an ear open for any other feedback. Looking at my original query I can see that it looks like I am focusing on generating WS clients - I should have said "providing interfaces for a system" rather than "interfacing with a system". Regards, Jim. -----Original Message----- From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com] Sent: 30 August 2010 03:43 To: Tapestry users Subject: Re: OT: Web Services Second that. CXF is the successor to XFire and its solid. Kalle On Sun, Aug 29, 2010 at 3:56 PM, Daniel Honig <daniel.ho...@gmail.com> wrote: > I know of many projects using CXF without complaints. I'd say that CXF is > probably a good way to go. > > On Sun, Aug 29, 2010 at 1:35 PM, Jim O'Callaghan > <j...@peritussolutions.com>wrote: > >> I'm aware this is off topic, but since there are so many people on the list >> with a broad skill set am hoping I can learn from their experiences / >> heartbreak. I am evaluating various WS stacks for interfacing with a >> system >> - currently I am using XFire as it requires very little configuration and >> performs quite efficiently. XFire appears to qualify every xml element >> with >> a namespace, bloating the payload considerably, or, if using the patch from >> http://jira.codehaus.org/browse/XFIRE-687 appears to have unreliable / >> inconsistent namespace qualifiers. Can anyone recommend a good WS stack >> they have positive experience of? My constraints are quite liberal - java >> 1.5 up, currently jetty as an AS, spring 3.0.2.RELEASE. Is CXF any good? >> I >> want to find something with good performance obviously, minimal config, and >> hopefully something that consistently defines package level namespaces at >> an >> envelope level and reuses them. >> >> >> >> Many thanks, >> >> Jim. >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
