October 2006 - jbossws-dev - Jboss List Archives

[Design of JBoss Web Services] - Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep

by darran.lofthouse＠jboss.com

Personally I prefer option 2 as well as this means for all deployments we will allways be working with a clean web.xml and it means the user never sees their web.xml modified. The downside of this approach is that for it to work 3 different products need to change. Tomcat needs to be changed so that the 'altDDName' attribute is exposed. At the moment I can access this from JBoss as: - Context ctx = (Context) server.getAttribute(objectName, "managedResource"); | ctx.setAltDDName(metaData.getAltDD()); However this is a bit of a hack and if we are going to use it it should be exposed properly. Secondly the WebMetaData class will need modifying so include an attribute to hold the name of the new web.xml so that TomcatDeployer can pass it to Tomcat. The earliest we could get this in would be for JBoss 4.0.6.GA and once in JBossWS would not be compatible with previous JBossAS versions. Having said that despite the number of projects affected this is probably the simplest to implement, just a few lines of changes in each product. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978616#3978616 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978616

18 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep

by jason.greene＠jboss.com

I actually like option 2 the best. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978597#3978597 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978597

18 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1093 - normal servlets the web.xml is modified as i

by jason.greene＠jboss.com

The issue with tomcat is that there isnt a classloader or even a parent clasloader available at this time in the process. Basically we need to create a classloader that follows the tomcat classpath. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978593#3978593 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978593

18 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1079 - Incorrect WSDL to Java mapping for anonymous

by jason.greene＠jboss.com

We don't have to follow this, and I don't see why it's necessary. JSR-109 redefined the mapping of wsdl to java, and as long as the mapping file is accurate, it doesnt matter what we call the classes. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978590#3978590 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978590

18 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - JBWS-1093 - normal servlets the web.xml is modified as if th

by darran.lofthouse＠jboss.com

Originally before the support for Tomcat was added to JBossWS the process of modifying the web.xml was implemented to only modify the servlet entries in the web.xml if the servlet was actually a web service. For JSR-109 deployments web services were identified by the presence of the 'servlet-link' in the webservices.xml, for JSR-181 deployments this was identified by checking if the class has the @WebService annotation. I believe this is still the correct mechanism to identify if the servlet is supposed to be exposed as a web service. For deployments deployed to JBoss from the UnifiedMetaData we can get the list of all of the servlet-links so this could be passed into the 'rewriteWebXML' method to be used to identify which servlets need to be converted. For Tomcat deployments we do not have this information available at the moment. For JSR-109 deployments I think we just need to parse the webservices.xml to get the list of servlet-links. For JSR-181 deployments we are going to need a classloader to load the servlet classes to check if they have the @WebService annotation. Because this is not always called from within the container we are going to need to create a classloader so that we can load the classes in the war, I think we should create a URLClassLoader so we can add all of the jars in the war and the classes folder in the war. The parent of the URLClassloader should be set to the current classloader at the time it is created. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978572#3978572 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978572

18 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redeploym

by darran.lofthouse＠jboss.com

For users deploying a JSR-181 POJO deployment with an exploded WAR subsequent deployments fail as the web.xml is modified with the JBossWS servlet name. On the next deployment it is the JBossWS servlet that is checked for annotations not the endpoint class itself, this means the web service is not detected. The only option the user has is to manually put the original web.xml back in place for each deployment / server restart. A second minor problem is that users deploying JSR-109 POJO endpoints with an exploded war may not want their web.xml modified by JBoss, however their web service is still correctly deployed for subsequent deployments. So far I can see the following options: - 1 - Modify org.jboss.metadata.WebMetaData so that it also reads the init-params from the web.xml, if the servlet-class is an implementation of StandardEndpointServlet then we can lookup the 'ServiceEndpointImpl' parameter and test that instead. 2 - Instead of modifying the web.xml deployment descriptor create a new file to use in place of the web.xml descriptor, this means we can write the changes to the new file without affecting the original file. It is not currently exposed as an attribute of the MBean but the StandardContext class within Tomcat does have an attribute 'altDDName', this attribute can be set to override the name of the deployment descriptor to use so an alternative can be specified. 3 - JBossWS in addition to using the WebMetaData can also parse the web.xml to retrieve the parameters so as for 1 if the JBossWS servlet is found the 'ServiceEndpointImpl' parameter can be used to identify the correct class to check for annotations. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978538#3978538 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978538

18 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - JBWS-1079 - Incorrect WSDL to Java mapping for anonymous str

by darran.lofthouse＠jboss.com

I need some clarification on what is going to be the correct solution for this task. It looks like the current naming convention was chosen because that is the way it is generated by wscompile, we even have a test in the testsuite to make sure that the generated class does have the same name as the class generated by wscompile. As I mentioned in the Jira task the jax-rpc specification says that the name should be the name of the nearest enclosing element, complexType or simpleType, I haven't seen anything that says it should be created by concatenating a series of names together. There would however be a problem with just taking the name of the enclosing element. If two different elements with the same name (because they are in their own complex types contain an anonymous simple type then there will be a name collision. The jax-rpc specification does contain a section that describes the expected collisions and this doesn't appear to be one of them. To try and get an idea of how this has evolved in the later specs I have tried generating the code using the JaxB 2.0 RI from Sun, the RI generates the type as a static inner class within the class representing the enclosing type. This does mean that the anonymous type is named after the element that contains it and it also gets round the naming collisions but it feels as if this is ahead of what is intended by the JAX-RPC spec. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978411#3978411 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978411

18 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1115 - Automatic detection of Tomcat port

by darran.lofthouse＠jboss.com

I have commited an implementation for this. I have added a couple of methods to the ServerConfig interface so that these two values can be retrieved. For the JBoss implementation I query the MBean server for all connectors and return the port for the first one that is secured and the port for the first one that is not secured. Within the ServiceEndpointManager if the ports have not already been set I retrieve the ServerConfig using the factory and lookup these two values. I have not been able to implement the Tomcat versions of these methods yet as I can not get the latest JBossWS to deploy on Tomcat, however I believe the approach should be similar so I can raised the following task: - http://jira.jboss.com/jira/browse/JBWS-1304 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978409#3978409 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978409

18 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - JBAS-3766, port the webservice deployer

by scott.stark＠jboss.org

http://jira.jboss.com/jira/browse/JBAS-3766 The webservice deployer is now broken in head as the deployers it depends on have been ported to the the new VDF. We certainly are sufficiently far along to begin the migration of the webservice deployer to the VDF. However, the tomcat deployer and jbossweb itself probably are not sufficiently refactored to allow the webservice deployer to manipulate the metadata model derived from the web.xml/jboss-web.xml rather than trying to manipulate the war descriptors. That is where we need to get to though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978306#3978306 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978306

18 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - ws-eventing: event notification failure

by maeste

I noticed that event notification failure are completely lost. If an event notification fail jbossws just log the error and does nothing. I took a look and I think could be pretty simple to modify the code to store these failures in the SubscriptionManager MBEAN with exceptions generated to make possible to analyze problems without watching console all day long :) And is also possible add one or more methods to the MBEAN to resend failed notification. What do you think about? Can I put my hand on this part of code? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977692#3977692 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977692

18 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-dev October 2006