January 2007 - jbossws-issues - Jboss List Archives

[JBoss JIRA] Updated: (JBWS-844) Add support for a fully defined schema with a message endpoint

by Darran Lofthouse (JIRA)

[ http://jira.jboss.com/jira/browse/JBWS-844?page=all ] Darran Lofthouse updated JBWS-844: ---------------------------------- Fix Version/s: jbossws-2.0.0 (was: jbossws-1.2.1) > Add support for a fully defined schema with a message endpoint > -------------------------------------------------------------- > > Key: JBWS-844 > URL: http://jira.jboss.com/jira/browse/JBWS-844 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jaxrpc > Reporter: Jason T. Greene > Assigned To: Darran Lofthouse > Fix For: jbossws-2.0.0 > > > Currently a SOAPElement can only be mapped to a xsd:any type. We should add support for mapping SOAPElement to a message that has been fully specified. This would allow for the WSDL to represent a fully defined contract, and yet still allow the endpoint to have flexible parsing. > -Jason -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBWS-1188) Relax requirement for wsu:id for UsernameToken

by Darran Lofthouse (JIRA)

[ http://jira.jboss.com/jira/browse/JBWS-1188?page=all ] Darran Lofthouse updated JBWS-1188: ----------------------------------- Fix Version/s: jbossws-2.0.0 (was: jbossws-1.2.1) > Relax requirement for wsu:id for UsernameToken > ---------------------------------------------- > > Key: JBWS-1188 > URL: http://jira.jboss.com/jira/browse/JBWS-1188 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: ws-security > Affects Versions: jbossws-1.0.3 > Reporter: Darran Lofthouse > Assigned To: Darran Lofthouse > Fix For: jbossws-2.0.0 > > > The JBossWS UsernameToken implementation is mandating that the wsu:id attribute is present on incomming requests. > Some thirdparty web services stacks being used as clients to JBossWS do not send the ID so we are rejecting the request. Additionally we do not actually use the id anywhere anyway. > The requirement for the id should be relaxed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBWS-299) Tools: "NoDataBinding" option for doc/literal Web Services

by Darran Lofthouse (JIRA)

[ http://jira.jboss.com/jira/browse/JBWS-299?page=all ] Darran Lofthouse updated JBWS-299: ---------------------------------- Fix Version/s: jbossws-2.0.0 (was: jbossws-1.2.1) > Tools: "NoDataBinding" option for doc/literal Web Services > ---------------------------------------------------------- > > Key: JBWS-299 > URL: http://jira.jboss.com/jira/browse/JBWS-299 > Project: JBoss Web Services > Issue Type: Feature Request > Components: wstools > Reporter: Anil Saldhana > Assigned To: Darran Lofthouse > Priority: Optional > Fix For: jbossws-2.0.0 > > > wscompile has an option "-f:nodatabinding" that turns off data binding in the input parameters and return types for doc/lit web services. More information is available in the feature matrix. That info is copy/pasted here: > > wscompile uses this option to turn off data binding for literal encoding. This is a very important option when dealing with doc/literal wsdl files. Let us take an example of a web service that returns employee data. > > The SEI generated by wscompile will look as follows: > public interface EmployeeQuery extends Remote { > public double getSalary() throws RemoteException; > public String getManagerName(int level) throws RemoteException; > } > Now if the -f:nodatabinding option is used, the generated SEI will not have any typed arguments or return types, but they will all be mapped to javax.xml.soap.SOAPElement (xsd:any equivalent). > public interface EmployeeQuery extends Remote { > public javax.xml.soap.SOAPElement getSalary() throws RemoteException; > public javax.xml.soap.SOAPElement getManagerName(javax.xml.soap.SOAPElement level) throws RemoteException; > } > Supported by jbossws with the "nodatabinding" attribute in the <wsdltojava> element. > A point to be noted is the user will have to use SAAJ to construc messages to invoke the webservice and has to decode the return message (if any) using SAAJ. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWS-1463) Tools generated Service should implement ConfigProvider

by Thomas Diesler (JIRA)

Tools generated Service should implement ConfigProvider ------------------------------------------------------- Key: JBWS-1463 URL: http://jira.jboss.com/jira/browse/JBWS-1463 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: wstools Reporter: Thomas Diesler Fix For: jbossws-2.0.0 A JAXWS generated Service should implement the ConfigProvider interface to allow for customiztion like this  <service-ref> <service-ref-name>Service4</service-ref-name> <port-info> <service-endpoint-interface>org.jboss.test.ws.jaxws.webserviceref.TestEndpoint</service-endpoint-interface> <config-name>Custom Client</config-name> <config-file>META-INF/jbossws-client-config.xml</config-file> </port-info> <wsdl-override>META-INF/wsdl/TestEndpoint.wsdl</wsdl-override> </service-ref> See JAXWS ServiceExt and ServiceObjectFactory -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWS-1339) @Security domain vs. <security-domain>

by Thomas Diesler (JIRA)

@Security domain vs. <security-domain> -------------------------------------- Key: JBWS-1339 URL: http://jira.jboss.com/jira/browse/JBWS-1339 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Thomas Diesler Fix For: jbossws-1.0.5 I have a test where my ejb3 SLSB, jsr181 endpoint works only if I use the @SecurityDomain annotation. If I try to define the security-domain in the deployment descriptor I get a 401 http response code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 10 months

1
5
0 / 0

[JBoss JIRA] Updated: (JBWS-1093) Deploying a war that also contains normal servlets the web.xml is modified as if they are all endpoints

by Darran Lofthouse (JIRA)

[ http://jira.jboss.com/jira/browse/JBWS-1093?page=all ] Darran Lofthouse updated JBWS-1093: ----------------------------------- Fix Version/s: jbossws-1.2.1 (was: jbossws-2.0.0) > Deploying a war that also contains normal servlets the web.xml is modified as if they are all endpoints > ------------------------------------------------------------------------------------------------------- > > Key: JBWS-1093 > URL: http://jira.jboss.com/jira/browse/JBWS-1093 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jaxrpc > Affects Versions: jbossws-1.0.1 > Environment: Deploying to JBoss 4.0.4.GA > Reporter: Darran Lofthouse > Assigned To: Darran Lofthouse > Fix For: jbossws-1.0.4, jbossws-1.2.1 > > > When deploying a war that contains web services the servlet definitions for the endpoints need to be modified so that they reference a JBossWS servlet instead of the endpoint implementation, this JBossWS implementation then delegates to the endpoint. > For JBossWS 1.0.0 servlet entries were only modified if they were identified as endpoints based on the deployment of the webservices.xml > For JBossWS 1.0.1 as part of removing the dependencies on JBossAS this was refactored and now the non web services servlets are identified if their name ends 'Servlet'. The original logic from JBossWS 1.0.0 needs to be reimplemented but we also need to take into acount the different deployment scenarios. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBWS-981) Virtual host configuration for EJB endpoints

by Darran Lofthouse (JIRA)

[ http://jira.jboss.com/jira/browse/JBWS-981?page=all ] Darran Lofthouse updated JBWS-981: ---------------------------------- Fix Version/s: jbossws-1.2.1 (was: jbossws-2.0.0) > Virtual host configuration for EJB endpoints > -------------------------------------------- > > Key: JBWS-981 > URL: http://jira.jboss.com/jira/browse/JBWS-981 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jaxws > Reporter: Thomas Diesler > Assigned To: Darran Lofthouse > Fix For: jbossws-1.0.4, jbossws-1.2.1 > > > I use JBoss 4.0.4 GA and want to deploy a EJB3 (JSR-181) webserivce. Nearly everything is fine. The problem is that the generated servlet of the webservice is deployed on the default virtual host, but I want to change this to another. How is this possible? I tried to add an jboss-web.xml in META-INF directory of the jar-file containing the webservice bean and interface, but with no success. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBWS-1291) Fix JaxrpcMappingValidator

by Darran Lofthouse (JIRA)

[ http://jira.jboss.com/jira/browse/JBWS-1291?page=comments#action_12350981 ] Darran Lofthouse commented on JBWS-1291: ---------------------------------------- This now mostly works as I needed it for some of the recent tests I wrote this is mostly works, just need to double check it against the jax rpc mapping schema, > Fix JaxrpcMappingValidator > -------------------------- > > Key: JBWS-1291 > URL: http://jira.jboss.com/jira/browse/JBWS-1291 > Project: JBoss Web Services > Issue Type: Task > Security Level: Public(Everyone can see) > Components: wstools > Reporter: Thomas Diesler > Assigned To: Darran Lofthouse > Fix For: jbossws-2.1.0 > > > ClientSideArtifactsTestCase > //Compare mapping files > String fix = "resources/tools/jbws-160/wscompile/custom/mapping/jaxrpc-mapping.xml"; > String gen = "tools/jbws-160/jbossws/custom/mapping/jaxrpc-mapping.xml"; > JaxrpcMappingValidator mv = new JaxrpcMappingValidator(); > //assertTrue(mv.validate(fix,gen)); > System.out.println("FIXME:JBWS-160"); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBWS-1291) Fix JaxrpcMappingValidator

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBWS-1291?page=all ] Jason T. Greene updated JBWS-1291: ---------------------------------- Assignee: (was: Jason T. Greene) > Fix JaxrpcMappingValidator > -------------------------- > > Key: JBWS-1291 > URL: http://jira.jboss.com/jira/browse/JBWS-1291 > Project: JBoss Web Services > Issue Type: Task > Security Level: Public(Everyone can see) > Components: wstools > Reporter: Thomas Diesler > Fix For: jbossws-2.1.0 > > > ClientSideArtifactsTestCase > //Compare mapping files > String fix = "resources/tools/jbws-160/wscompile/custom/mapping/jaxrpc-mapping.xml"; > String gen = "tools/jbws-160/jbossws/custom/mapping/jaxrpc-mapping.xml"; > JaxrpcMappingValidator mv = new JaxrpcMappingValidator(); > //assertTrue(mv.validate(fix,gen)); > System.out.println("FIXME:JBWS-160"); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBWS-1443) getMessageContext Not Implemented

by Thomas Diesler (JIRA)

[ http://jira.jboss.com/jira/browse/JBWS-1443?page=comments#action_12350869 ] Thomas Diesler commented on JBWS-1443: -------------------------------------- Please assign back to me, when you are done backporting. jbossws-1.2 code freeze is Thu, 18-Jan. Expected release date is 1-Feb > getMessageContext Not Implemented > --------------------------------- > > Key: JBWS-1443 > URL: http://jira.jboss.com/jira/browse/JBWS-1443 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Thomas Diesler > Assigned To: Carlo de Wolf > Fix For: jbossws-1.2.0 > > > jboss-4.0.4.GA with EJB3-RC9FD thows a NOT IMPLEMENTED Exception when form the SessionContext he method getMessageContext is called. > Form this version with the new JbossWS stack as far i know i not anymore possible to retreive a SOAP attachement . > With the old ws4ee was possible calling the org.jboss.axis.MessageContext.getCurrentContext(); without calling SessionContext but now all the axis stuff has been removed :( -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues January 2007