[JBoss JIRA] Updated: (JBWS-1079) Incorrect WSDL to Java mapping for anonymous struct.
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1079?page=all ]
Thomas Diesler updated JBWS-1079:
---------------------------------
Fix Version/s: jbossws-1.0.5
(was: jbossws-1.0.4)
Rescheduled due to inactivity. Code freeze was on 17-Oct-2006.
Please communicate your intentions so we can act appropriately in a timely manner.
Past jira freeze, issues that are scheduled for a particular release past jira freeze
should be fixed and not allowed to be sliped. Jira freeze was on 18-Sep-2006.
If this is not possible for unforseen reason this must be escalated to the release manageer in a timely manner.
If we don't stick to these simple rules, our release planing becomes meaningless.
> Incorrect WSDL to Java mapping for anonymous struct.
> ----------------------------------------------------
>
> Key: JBWS-1079
> URL: http://jira.jboss.com/jira/browse/JBWS-1079
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: wstools
> Affects Versions: jbossws-1.0.0, jbossws-1.0.1
> Reporter: Darran Lofthouse
> Assigned To: Darran Lofthouse
> Fix For: jbossws-1.0.5
>
>
> When running wsdl to java for a wsdl that contains a complex type that contains an anonymous struct the class generated for the anonymous struct is incorrect.
> <xsd:complexType name="Person">
> <xsd:sequence>
> <xsd:element name="Address">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="Address1" />
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
> </xsd:sequence>
> </xsd:complexType>
> The above example would generate an class with the name 'PersonAddress'.
> From the jax-rpc specification (section 4.2.3) : -
> " An XML struct maps to a JavaBeans class with the same name as the type of the XML struct. If the struct is anonymous, then the name of the nearest enclosing xsd:element, xsd:complexType or xsd:simpleType is used instead."
> So the name of the generated type should be Address.
> The generation of the jaxrpc-mapping actually does assume the generated class was generated with the name 'Address' so the code generation and jaxrpc-mapping generation are out of synch.
--
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
18 years, 1 month
[JBoss JIRA] Updated: (JBWS-1133) Unpacked JSR-181 POJO deployment fails for subsquent deployment.
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1133?page=all ]
Thomas Diesler updated JBWS-1133:
---------------------------------
Fix Version/s: jbossws-1.0.5
(was: jbossws-1.0.4)
Rescheduled due to inactivity. Code freeze was on 17-Oct-2006.
Please communicate your intentions so we can act appropriately in a timely manner.
Past jira freeze, issues that are scheduled for a particular release past jira freeze
should be fixed and not allowed to be sliped. Jira freeze was on 18-Sep-2006.
If this is not possible for unforseen reason this must be escalated to the release manageer in a timely manner.
If we don't stick to these simple rules, our release planing becomes meaningless.
> Unpacked JSR-181 POJO deployment fails for subsquent deployment.
> ----------------------------------------------------------------
>
> Key: JBWS-1133
> URL: http://jira.jboss.com/jira/browse/JBWS-1133
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jaxws
> Affects Versions: jbossws-1.0.1
> Reporter: Darran Lofthouse
> Assigned To: Darran Lofthouse
> Fix For: jbossws-1.0.5
>
>
> Unpacked JSR-181 POJO deployments are not deployed correctly for subsequent server starts.
> This is because when this is first deployed the web.xml which is part of the deployment is modified so that the JBossServiceEndpointServlet servlet is used.
> On subsequent deployments the web.xml is parsed but because all of the servlet classes have been replaced with the JBossServiceEndpointServlet it is JBossServiceEndpointServlet that is checked for annotations instead of the endpoint class.
--
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
18 years, 1 month
[JBoss JIRA] Updated: (JBWS-1136) Allow username to be specified in the requires list
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1136?page=all ]
Thomas Diesler updated JBWS-1136:
---------------------------------
Fix Version/s: jbossws-1.0.5
(was: jbossws-1.0.4)
Rescheduled due to inactivity. Code freeze was on 17-Oct-2006.
Please communicate your intentions so we can act appropriately in a timely manner.
Past jira freeze, issues that are scheduled for a particular release past jira freeze
should be fixed and not allowed to be sliped. Jira freeze was on 18-Sep-2006.
If this is not possible for unforseen reason this must be escalated to the release manageer in a timely manner.
If we don't stick to these simple rules, our release planing becomes meaningless.
> Allow username to be specified in the requires list
> ---------------------------------------------------
>
> Key: JBWS-1136
> URL: http://jira.jboss.com/jira/browse/JBWS-1136
> Project: JBoss Web Services
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: ws-security
> Affects Versions: jbossws-1.0.1
> Reporter: Darran Lofthouse
> Assigned To: Darran Lofthouse
> Fix For: jbossws-1.0.5
>
>
> Allow username to be specified in the requires list for endpoints so that messages without the username can be rejected.
> At the moment for EJB endpoints they can be configured using standard J2EE security so if there is no authenticated user the request is rejected, however this can't be done for the POJO endpoints.
--
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
18 years, 1 month
[JBoss JIRA] Updated: (JBWS-844) Add support for a fully defined schema with a message endpoint
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-844?page=all ]
Thomas Diesler updated JBWS-844:
--------------------------------
Fix Version/s: jbossws-1.0.5
(was: jbossws-1.0.4)
Rescheduled due to inactivity. Code freeze was on 17-Oct-2006.
Please communicate your intentions so we can act appropriately in a timely manner.
Past jira freeze, issues that are scheduled for a particular release past jira freeze
should be fixed and not allowed to be sliped. Jira freeze was on 18-Sep-2006.
If this is not possible for unforseen reason this must be escalated to the release manageer in a timely manner.
If we don't stick to these simple rules, our release planing becomes meaningless.
> 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-1.0.5
>
>
> 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
18 years, 1 month
[JBoss JIRA] Updated: (JBWS-1188) Relax requirement for wsu:id for UsernameToken
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1188?page=all ]
Thomas Diesler updated JBWS-1188:
---------------------------------
Fix Version/s: jbossws-1.0.5
(was: jbossws-1.0.4)
Rescheduled due to inactivity. Code freeze was on 17-Oct-2006.
Please communicate your intentions so we can act appropriately in a timely manner.
Past jira freeze, issues that are scheduled for a particular release past jira freeze
should be fixed and not allowed to be sliped. Jira freeze was on 18-Sep-2006.
If this is not possible for unforseen reason this must be escalated to the release manageer in a timely manner.
If we don't stick to these simple rules, our release planing becomes meaningless.
> 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-1.0.5
>
>
> 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
18 years, 1 month