[Design of JBoss Web Services] - Re: Endpoint redeployment
by richard_opalka
We've got the following problem:
Thomas want to support the following usecase:
* User will provide the web.xml which looks like:
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
| xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
| version="2.4">
|
| <!-- Test that we can deploy an already modified web.xml -->
| <servlet>
| <servlet-name>Hello</servlet-name>
| <servlet-class>org.jboss.wsf.stack.jbws.EndpointServlet</servlet-class>
| <init-param>
| <param-name>jboss.ws.endpoint</param-name>
| <param-value>org.jboss.test.ws.jaxrpc.jbws124.HelloJavaBean</param-value>
| </init-param>
| </servlet>
| <servlet-mapping>
| <servlet-name>Hello</servlet-name>
| <url-pattern>/*</url-pattern>
| </servlet-mapping>
| </web-app>
REQUIREMENT: Such web.xml should be detected as webservice archive.
If I will consider server side deployment implementation how it works now then
this requirement is in collision with the following usecase:
1) EJB archive is detected as webservice deployment
2) web.xml file is generated for all EJB webservices
3) web.xml file is modified in the same way as the above example (probably to not be detected as webservice deployment by non EJB deployer hooks in current implementation)
4) War deployer hooks are called for created war deployment
If I'll consider the above requirement that such web archives should be recognized as
webservice deployments then this archive will be recognized as webservices
archive and JBossWS war deployer hook will try to redeploy it. This redeployment will of course fail because the endpoint registry already have already registered EJB beans).
Questions to be answered during this discussion:
* How could non EJB deployers detect that deployment work had been already done by EJB deployers and nothing should be done for such archives?
* Do we really want to support the above requirement?
NOTE: In memory changes only are not possible, because we're talking about JBoss 4.x. So there's no workaround to creation of web.xml files on the file system.
Richard
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088446#4088446
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088446
16 years, 8 months
[Design of JBoss Web Services] - Exception propagation for one way messaqges
by adinn
Can anyone clarify the intention of the WS 2.0 specification regarding the propagation of exceptions from server to client for messages whicih are tagged @OneWay. It is not clear to me whether an exeception generated by the web method implementation is supposed to be caught and handled by generating a corresponding exception for the client call.
The specific case I have in mind is one where an @OneWay web method interface is generated from WSDL. The corresponding operation is specified with a single message and no or messages and is bound ot a port and service using a SOAP binding. Obviously, I would be inetrested to hear opinions regarding what should happen in other related cases.
I have tested the case mentioned above on JBossWS 2.0.1GA (with AS5.0.0.Beta3), generating either a SOAPFaultException or a WebServiceException. The test invokes the one way method via a client proxy obtained from the generated soap service class. In both cases a client exception was not thrown. However, I'll note that neither is this definitive of what the spec intends nor does it necessarily indicate that this is the behaviour desired by the implementation. The latter point is explained below.
An HTTP error was returned to the invoking client and a SOAP fault containing the generated exception details was serialised into the response stream and dispatched back to the client. Affter I patched a bug in the remoting code the soap envelope was read from the http connection response stream as a String. This format was employed because the unmarshaller installed on the connection before invocation was an HTTP unmarshaller, not a SOAP unmarshaller. This appears to explain why the fault was not thrown in the client context. Given all the work involved in returning the SOAP fault I wonder if this was really what was meant to happen?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087841#4087841
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087841
16 years, 8 months
Re: jbossws hudson QA environment
by Thomas Diesler
Hi Ryan,
please see my comments in line. Thanks for following up on this.
-thomas
On Fri, 2007-09-21 at 17:17 +0200, Ryan Campbell wrote:
> Thomas Diesler wrote:
> > Hi Ryan,
> >
> > I would like to bring the jbossws hudson QA environment
> > http://jbws.dyndns.org:8180/hudson/
> > to the general jboss QA infrastructure.
> >
> > Ideally, we would like to have a dedicated box where we can setup and
> > maintain our QA ourselves.
> >
> > Whats your take on this?
> >
> > cheers
> > -thomas
> >
> In general, I would like to do whatever makes the most sense here. So
> getting a dedicated box for JBossWS runs sounds reasonable. However, I
> have a few questions. I am also copying Len DiMaggio, who is the test
> lead for the SOA Platform, and who will be able to respond to this issue
> while I am out for a week of vacation.
>
> Questions:
>
> 1. Could this dedicated box be a slave in our Hudson setup to which you
> could just assign your builds? IE, it would just have a Hudson slave
> running, not the complete Hudson reporting environment. It would show
> up with the rest of our Hudson slaves here:
>
> http://dev45.qa.atl.jboss.com:8585/hudson/
>
> But we wouldn't use it for anything besides your builds. The only
> reason I say this is that it gives us a single Hudson instance to update
> & maintain. Also, this instance is populated with our plugins for
> publishing to hudson.jboss.org which is important if you care to share
> your builds with the community.
The jbossws QA environment should be public, so that people know what to
expect when they checkout trunk or various branches.
We actually have two hudson instances running
http://jbws.dyndns.org:8180/hudson/
http://jbws.dyndns.org:8280/hudson/
One for trunk and one for our next release. Both are public.
To setup Hudson on a box, we currently do
svn co http://.../framework/trunk framework
cd framework
./build.sh hudson-setup
./build.sh hudson-start
Hence we would need to have an SSH account and SVN installed on that
box.
>
> 2. What would you expect from us besides getting the box setup initially?
>
> We will need to go through finance to get the box acquired, but I expect
> it should be up in a couple of months, considering past experience
> getting hardware approved and installed.
Our current box is a Packard Bell, Pentium 4 - nothing special really.
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years, 8 months