[jira] Updated: (AXIS2-4550) Parser incorrectly complains about mising prefix or duplicate attributes on the soap message
[ https://issues.apache.org/jira/browse/AXIS2-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lori VanGulick updated AXIS2-4550: -- Attachment: AXIS2-4550.patch Attaching patch. Parser incorrectly complains about mising prefix or duplicate attributes on the soap message Key: AXIS2-4550 URL: https://issues.apache.org/jira/browse/AXIS2-4550 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Lori VanGulick Attachments: AXIS2-4550.patch When using the when the JAX-WS DispatchOMElement or ProviderOMElement APIs, there may be cases where the parser incorrectly reports missing prefix and/or duplicate attributes on the SOAP message. Under some circumstances the JAX-WS implementation of the DispatchOMElement and ProviderOMElement APIs are not able to find the namespace or attribute declarations that are located on ancestor xml elements or these declarations were incorrectly discovered to be duplicated. The algorithm should be corrected to propagate namespace and attribute declarations to child elements. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4550) Parser incorrectly complains about mising prefix or duplicate attributes on the soap message
Parser incorrectly complains about mising prefix or duplicate attributes on the soap message Key: AXIS2-4550 URL: https://issues.apache.org/jira/browse/AXIS2-4550 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Lori VanGulick When using the when the JAX-WS DispatchOMElement or ProviderOMElement APIs, there may be cases where the parser incorrectly reports missing prefix and/or duplicate attributes on the SOAP message. Under some circumstances the JAX-WS implementation of the DispatchOMElement and ProviderOMElement APIs are not able to find the namespace or attribute declarations that are located on ancestor xml elements or these declarations were incorrectly discovered to be duplicated. The algorithm should be corrected to propagate namespace and attribute declarations to child elements. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2-4528) Performance issue with SOAPHANDLER'S HANDLEMESSAGE
[ https://issues.apache.org/jira/browse/AXIS2-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lori VanGulick updated AXIS2-4528: -- Attachment: AXIS2-4528patch.diff attached patch Performance issue with SOAPHANDLER'S HANDLEMESSAGE -- Key: AXIS2-4528 URL: https://issues.apache.org/jira/browse/AXIS2-4528 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Lori VanGulick Fix For: 1.6 Attachments: AXIS2-4528patch.diff Implementations of HandlerPostInvoker have no way to determine if the SOAP message has even been accessed by the handlers. Without this information they may needlessly expand the message causing performance degradation. Add a property jaxws.messageAccessed to the SOAPMessageContext when a SOAPMessageContext.getMessage() is performed. HandlerPostInvoker implementations can then check for the property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4528) Performance issue with SOAPHANDLER'S HANDLEMESSAGE
Performance issue with SOAPHANDLER'S HANDLEMESSAGE -- Key: AXIS2-4528 URL: https://issues.apache.org/jira/browse/AXIS2-4528 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Lori VanGulick Fix For: 1.6 Implementations of HandlerPostInvoker have no way to determine if the SOAP message has even been accessed by the handlers. Without this information they may needlessly expand the message causing performance degradation. Add a property jaxws.messageAccessed to the SOAPMessageContext when a SOAPMessageContext.getMessage() is performed. HandlerPostInvoker implementations can then check for the property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2-4158) Enhance URIResolverImpl to be able to use static XML catalog
[ https://issues.apache.org/jira/browse/AXIS2-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674699#action_12674699 ] Lori VanGulick commented on AXIS2-4158: --- Reworked fix on top of changes from AXIS2-4209, such that CatalogURIResolver extends URIResolverImpl. Enhance URIResolverImpl to be able to use static XML catalog Key: AXIS2-4158 URL: https://issues.apache.org/jira/browse/AXIS2-4158 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Lori VanGulick Priority: Minor URIResolverImpl currently does not attempt to resolve using a static XML catalog. Updated URIResolverImpl to extend CatalogURIResolver and attempt to use the catalog to resolve if a catalog is available. If catalog resolution fails, revert to existing resolveEntity logic to resolve remotely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2-4158) Enhance URIResolverImpl to be able to use static XML catalog
[ https://issues.apache.org/jira/browse/AXIS2-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lori VanGulick updated AXIS2-4158: -- Attachment: Axis2-4158.patch attached patch Enhance URIResolverImpl to be able to use static XML catalog Key: AXIS2-4158 URL: https://issues.apache.org/jira/browse/AXIS2-4158 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Lori VanGulick Priority: Minor Attachments: Axis2-4158.patch URIResolverImpl currently does not attempt to resolve using a static XML catalog. Updated URIResolverImpl to extend CatalogURIResolver and attempt to use the catalog to resolve if a catalog is available. If catalog resolution fails, revert to existing resolveEntity logic to resolve remotely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4158) Enhance URIResolverImpl to be able to use static XML catalog
Enhance URIResolverImpl to be able to use static XML catalog Key: AXIS2-4158 URL: https://issues.apache.org/jira/browse/AXIS2-4158 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Lori VanGulick Priority: Minor URIResolverImpl currently does not attempt to resolve using a static XML catalog. Updated URIResolverImpl to extend CatalogURIResolver and attempt to use the catalog to resolve if a catalog is available. If catalog resolution fails, revert to existing resolveEntity logic to resolve remotely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3926) Exception in client-side outbound handler ignored, message proceeds to server.
Exception in client-side outbound handler ignored, message proceeds to server. -- Key: AXIS2-3926 URL: https://issues.apache.org/jira/browse/AXIS2-3926 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Lori VanGulick This is a jaxws CTS compliance issue. Client-side outbound handler throws exception. HandlerChainProcessor swallows exception due to jira AXIS2-3712. This should be OK ... see AXIS2-3712 for details. The problem is that processing continues on the outbound flow and the request reaches the server. On the server-side the message now contains a SOAPFault so we end up with the following error: org.apache.axis2.AxisFault: The endpoint reference (EPR) for the Operation not found is http://localhost:9080/WSDLOWHandlerTestService/jaxws/Hello and the WSA Action = My fix is to have the HandlerChainProcessor continue to swallow the exception, but also return a bad result to the invoker, HandlerInvokerUtils.invokeOutboundHandlers() so that it knows not to continue sending request to server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-3926) Exception in client-side outbound handler ignored, message proceeds to server.
[ https://issues.apache.org/jira/browse/AXIS2-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lori VanGulick updated AXIS2-3926: -- Attachment: AXIS2-3926.patch Exception in client-side outbound handler ignored, message proceeds to server. -- Key: AXIS2-3926 URL: https://issues.apache.org/jira/browse/AXIS2-3926 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Lori VanGulick Attachments: AXIS2-3926.patch This is a jaxws CTS compliance issue. Client-side outbound handler throws exception. HandlerChainProcessor swallows exception due to jira AXIS2-3712. This should be OK ... see AXIS2-3712 for details. The problem is that processing continues on the outbound flow and the request reaches the server. On the server-side the message now contains a SOAPFault so we end up with the following error: org.apache.axis2.AxisFault: The endpoint reference (EPR) for the Operation not found is http://localhost:9080/WSDLOWHandlerTestService/jaxws/Hello and the WSA Action = My fix is to have the HandlerChainProcessor continue to swallow the exception, but also return a bad result to the invoker, HandlerInvokerUtils.invokeOutboundHandlers() so that it knows not to continue sending request to server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3926) Exception in client-side outbound handler ignored, message proceeds to server.
[ https://issues.apache.org/jira/browse/AXIS2-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12614843#action_12614843 ] Lori VanGulick commented on AXIS2-3926: --- Forgot to add that this happens on one-way ops only. Exception in client-side outbound handler ignored, message proceeds to server. -- Key: AXIS2-3926 URL: https://issues.apache.org/jira/browse/AXIS2-3926 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Lori VanGulick Attachments: AXIS2-3926.patch This is a jaxws CTS compliance issue. Client-side outbound handler throws exception. HandlerChainProcessor swallows exception due to jira AXIS2-3712. This should be OK ... see AXIS2-3712 for details. The problem is that processing continues on the outbound flow and the request reaches the server. On the server-side the message now contains a SOAPFault so we end up with the following error: org.apache.axis2.AxisFault: The endpoint reference (EPR) for the Operation not found is http://localhost:9080/WSDLOWHandlerTestService/jaxws/Hello and the WSA Action = My fix is to have the HandlerChainProcessor continue to swallow the exception, but also return a bad result to the invoker, HandlerInvokerUtils.invokeOutboundHandlers() so that it knows not to continue sending request to server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3816) AccessControlException when running with Java2Security
AccessControlException when running with Java2Security -- Key: AXIS2-3816 URL: https://issues.apache.org/jira/browse/AXIS2-3816 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: kernel Affects Versions: 1.4 Reporter: Lori VanGulick Priority: Minor Hit the following AccessControlExceptions when installing the axis2 1.4 ear with java2security enabled: java.security.AccessControlException: Access denied (java.util.PropertyPermission Axis2.prohibitDebugLogging read) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:210) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285) at java.lang.System.getProperty(System.java:378) at java.lang.System.getProperty(System.java:362) at org.apache.axis2.util.LoggingControl.clinit(LoggingControl.java:43) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) at org.apache.axis2.handlers.addressing.AddressingInHandler.init(AddressingInHandler.java:68) at org.apache.axis2.deployment.util.Utils.addFlowHandlers(Utils.java:133) . java.security.AccessControlException: Access denied (java.io.FilePermission C:\pyxis\WebSphere\AppServer\profiles\AppSrv01\installedApps\bulbrichtNode01Cell\axis2.ear\axis2.war\WEB-INF\scriptServices read) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:210) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.File.list(File.java:971) at java.io.File.listFiles(File.java:1051) at org.apache.axis2.scripting.ScriptRepositoryListener.findServicesInDirectory(ScriptRepositoryListener.java:43) .. java.security.AccessControlException: Access denied (java.lang.RuntimePermission modifyThreadGroup) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:210) at com.ibm.ws.security.core.SecurityManager.checkAccess(SecurityManager.java:351) at java.lang.ThreadGroup.checkAccess(ThreadGroup.java:225) at java.lang.Thread.initialize(Thread.java:331) at java.lang.Thread.init(Thread.java:267) at java.lang.Thread.init(Thread.java:91) at java.util.Timer$TimerImpl.init(Unknown Source) at java.util.Timer.init(Unknown Source) at org.apache.axis2.deployment.scheduler.Scheduler.init(Scheduler.java:28) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-3816) AccessControlException when running with Java2Security
[ https://issues.apache.org/jira/browse/AXIS2-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lori VanGulick updated AXIS2-3816: -- Attachment: d516000.1patch.txt Patch attached AccessControlException when running with Java2Security -- Key: AXIS2-3816 URL: https://issues.apache.org/jira/browse/AXIS2-3816 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: kernel Affects Versions: 1.4 Reporter: Lori VanGulick Priority: Minor Attachments: d516000.1patch.txt Hit the following AccessControlExceptions when installing the axis2 1.4 ear with java2security enabled: java.security.AccessControlException: Access denied (java.util.PropertyPermission Axis2.prohibitDebugLogging read) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:210) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285) at java.lang.System.getProperty(System.java:378) at java.lang.System.getProperty(System.java:362) at org.apache.axis2.util.LoggingControl.clinit(LoggingControl.java:43) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) at org.apache.axis2.handlers.addressing.AddressingInHandler.init(AddressingInHandler.java:68) at org.apache.axis2.deployment.util.Utils.addFlowHandlers(Utils.java:133) . java.security.AccessControlException: Access denied (java.io.FilePermission C:\pyxis\WebSphere\AppServer\profiles\AppSrv01\installedApps\bulbrichtNode01Cell\axis2.ear\axis2.war\WEB-INF\scriptServices read) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:210) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.File.list(File.java:971) at java.io.File.listFiles(File.java:1051) at org.apache.axis2.scripting.ScriptRepositoryListener.findServicesInDirectory(ScriptRepositoryListener.java:43) .. java.security.AccessControlException: Access denied (java.lang.RuntimePermission modifyThreadGroup) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:210) at com.ibm.ws.security.core.SecurityManager.checkAccess(SecurityManager.java:351) at java.lang.ThreadGroup.checkAccess(ThreadGroup.java:225) at java.lang.Thread.initialize(Thread.java:331) at java.lang.Thread.init(Thread.java:267) at java.lang.Thread.init(Thread.java:91) at java.util.Timer$TimerImpl.init(Unknown Source) at java.util.Timer.init(Unknown Source) at org.apache.axis2.deployment.scheduler.Scheduler.init(Scheduler.java:28) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1087) CLONE -Problem with resolving imported schemas from WSDL11ToAxisServiceBuilder
[ http://issues.apache.org/jira/browse/AXIS2-1087?page=all ] Lori VanGulick updated AXIS2-1087: -- Attachment: patch.txt I have attached a patch that fixes this problem for my testcases. It is the same fix I described above - a one line change in WSDL11ToAxisServiceBuilder. After doing more testing I found that it was our custom URIResolver that was causing problems with absolute import addresses, not this patch. When we fixed our URIResolver, this patch worked great. I have run all the Junit tests and this patch does not cause any regressions. CLONE -Problem with resolving imported schemas from WSDL11ToAxisServiceBuilder -- Key: AXIS2-1087 URL: http://issues.apache.org/jira/browse/AXIS2-1087 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: core Reporter: Lori VanGulick Assigned To: Ajith Harshana Ranabahu Priority: Blocker Attachments: junittest.zip, patch.txt, WIImport.ear When importing nested schemas with a relative path, I have noticed a problem with the base URI that the WSDL11ToAxisServiceBuilder passes to the getXMLSchema method. Considering the structure: WEB-INF/wsdl/porttype/Echo.wsdl and WEB-INF/wsdl/xsd/Echo.xsd If Echo.wsdl has an import statement like ../xsd/Echo.xsd, the schema will fail to import. The issue seems to be that the WSDL11ToAxisServiceBuilder passes the string WEB-INF/wsdl as the base URI. This causes the implementation of the org.apache.ws.commons.schema.resolver.URIResolver not to be able to resolve the relative location with the base URI. I wanted to point out this problem, and I am not looking for an immediate patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1087) CLONE -Problem with resolving imported schemas from WSDL11ToAxisServiceBuilder
CLONE -Problem with resolving imported schemas from WSDL11ToAxisServiceBuilder -- Key: AXIS2-1087 URL: http://issues.apache.org/jira/browse/AXIS2-1087 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: core Reporter: Lori VanGulick Assigned To: Ajith Harshana Ranabahu When importing nested schemas with a relative path, I have noticed a problem with the base URI that the WSDL11ToAxisServiceBuilder passes to the getXMLSchema method. Considering the structure: WEB-INF/wsdl/porttype/Echo.wsdl and WEB-INF/wsdl/xsd/Echo.xsd If Echo.wsdl has an import statement like ../xsd/Echo.xsd, the schema will fail to import. The issue seems to be that the WSDL11ToAxisServiceBuilder passes the string WEB-INF/wsdl as the base URI. This causes the implementation of the org.apache.ws.commons.schema.resolver.URIResolver not to be able to resolve the relative location with the base URI. I wanted to point out this problem, and I am not looking for an immediate patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1087) CLONE -Problem with resolving imported schemas from WSDL11ToAxisServiceBuilder
[
http://issues.apache.org/jira/browse/AXIS2-1087?page=comments#action_12431027 ]
Lori VanGulick commented on AXIS2-1087:
---
This is still failing in revision 437740.
Here is the structure of the wsdl and xsd:
WEB-INF/wsdl/EchoService.wsdl
WEB-INF/wsdl/porttype/Echo.wsdl
WEB-INF/wsdl/xsd/Echo.xsd
EchoService.wsdl imports porttype/Echo.wsdl. This works fine (using a custom
WSDLLocator).
Echo.wsdl imports ../xsd/Echo.xsd. This fails with the following exception:
Exception: org.apache.axis2.AxisFault:
org.apache.ws.commons.schema.XmlSchemaException:
C:\axis2\modules\kernel\target\test-classes\WEB-INF\xsd\Echo.xsd (The system
cannot find the path specified.); nested exception is:
java.lang.RuntimeException:
org.apache.ws.commons.schema.XmlSchemaException:
C:\axis2\modules\kernel\target\test-classes\WEB-INF\xsd\Echo.xsd (The system
cannot find the path specified.)
The problem is in WSDL11ToAxisServiceBuilder.copyExtensibleElements. Around
line 1557:
} else if (wsdl4jElement instanceof Schema) {
Schema schema = (Schema) wsdl4jElement;
// just add this schema - no need to worry about the imported
// ones
axisService.addSchema(getXMLSchema(schema.getElement(),
wsdl4jDefinition.getDocumentBaseURI()));
The baseURI passed to getXMLSchema is from the definition which cooresponds to
EchoService.wsdl. What we want is the baseURI from Echo.wsdl, since that is
the file that is importing the schema. I have tried fixing this by using the
baseURI from the schema Element instead of from the base definition, like this:
axisService.addSchema(getXMLSchema(schema.getElement(),
schema.getDocumentBaseURI()));
This change does work for relative URIs, like in my testcase. But I think it
might introduce problems with absolute URIs. I am still looking at it.
CLONE -Problem with resolving imported schemas from WSDL11ToAxisServiceBuilder
--
Key: AXIS2-1087
URL: http://issues.apache.org/jira/browse/AXIS2-1087
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Components: core
Reporter: Lori VanGulick
Assigned To: Ajith Harshana Ranabahu
When importing nested schemas with a relative path, I have noticed a problem
with the base URI that the WSDL11ToAxisServiceBuilder passes to the
getXMLSchema method. Considering the structure:
WEB-INF/wsdl/porttype/Echo.wsdl
and
WEB-INF/wsdl/xsd/Echo.xsd
If Echo.wsdl has an import statement like ../xsd/Echo.xsd, the schema will
fail to import. The issue seems to be that the WSDL11ToAxisServiceBuilder
passes the string WEB-INF/wsdl as the base URI. This causes the
implementation of the org.apache.ws.commons.schema.resolver.URIResolver not
to be able to resolve the relative location with the base URI. I wanted to
point out this problem, and I am not looking for an immediate patch.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-965) Need a way to build AxisServices for all ports/services in a wsld.
[ http://issues.apache.org/jira/browse/AXIS2-965?page=all ] Lori VanGulick updated AXIS2-965: - Attachment: Disclaimer_patch.txt Attached Disclaimer_patch.txt which contains a disclaimer for the new classes stating that they are a temporary solution only. This is a comment change only. Need a way to build AxisServices for all ports/services in a wsld. -- Key: AXIS2-965 URL: http://issues.apache.org/jira/browse/AXIS2-965 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: core Reporter: Lori VanGulick Attachments: AXIS2-965patch.txt, Disclaimer_patch.txt, revised-JIRA965patch.txt WSDL 11 allows multiple services per wsdl file, and multiple ports per service. Currently unless a service and port name are specified, WSDL11ToAxisServiceBuilder will only return the first port on the first service. I would like to provide an extension to WSDL11ToAxisServiceBuilder that would take a wsdl file and return a List of AxisService objects, one for each port in the wsdl. To make this more efficient I will need to make some minor changes to org.apache.axis2.description.WSDL11ToAxisServiceBuilder.java, i.e. - restructuring in the populateService method so that all the processing that is not specific to an AxisService is only done one time. Move this code to a new method, setup(). Setup code will include reading in the wsdl file, processing policies, imports, etc. - make some methods and fields protected instead of private so they can be accessed by subclasses. The new extension is proposed to be org.appache.axis2.description.WSDL11ToAllAxisServicesBuilder. It has a public method, popluateAllServices() which operates as follows - calls the setup() method on the parent. - iterates through all the services and all the ports in the wsdl, setting serviceName and portName on the parent. - calls up to populateService() on the parent. This will return an AxisService specific to the service and port name specified. - changes the name on the AxisService to the port name instead of the service name, so it can be uniquely identified. - returns the List of AxisService objects, one for each port in the wsdl I will also make corresponding changes for WSDL 2.0 in org.apache.axis2.description.WSDL20ToAxisServiceBuilder.java and create WSDL20ToAllAxisServicesBuilder.java. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-965) Need a way to build AxisServices for all ports/services in a wsld.
[ http://issues.apache.org/jira/browse/AXIS2-965?page=all ] Lori VanGulick updated AXIS2-965: - Attachment: revised-JIRA965patch.txt I have updated this patch to the new kernel module. I have verified that the tests still pass. Need a way to build AxisServices for all ports/services in a wsld. -- Key: AXIS2-965 URL: http://issues.apache.org/jira/browse/AXIS2-965 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: core Reporter: Lori VanGulick Attachments: AXIS2-965patch.txt, revised-JIRA965patch.txt WSDL 11 allows multiple services per wsdl file, and multiple ports per service. Currently unless a service and port name are specified, WSDL11ToAxisServiceBuilder will only return the first port on the first service. I would like to provide an extension to WSDL11ToAxisServiceBuilder that would take a wsdl file and return a List of AxisService objects, one for each port in the wsdl. To make this more efficient I will need to make some minor changes to org.apache.axis2.description.WSDL11ToAxisServiceBuilder.java, i.e. - restructuring in the populateService method so that all the processing that is not specific to an AxisService is only done one time. Move this code to a new method, setup(). Setup code will include reading in the wsdl file, processing policies, imports, etc. - make some methods and fields protected instead of private so they can be accessed by subclasses. The new extension is proposed to be org.appache.axis2.description.WSDL11ToAllAxisServicesBuilder. It has a public method, popluateAllServices() which operates as follows - calls the setup() method on the parent. - iterates through all the services and all the ports in the wsdl, setting serviceName and portName on the parent. - calls up to populateService() on the parent. This will return an AxisService specific to the service and port name specified. - changes the name on the AxisService to the port name instead of the service name, so it can be uniquely identified. - returns the List of AxisService objects, one for each port in the wsdl I will also make corresponding changes for WSDL 2.0 in org.apache.axis2.description.WSDL20ToAxisServiceBuilder.java and create WSDL20ToAllAxisServicesBuilder.java. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-965) Need a way to build AxisServices for all ports/services in a wsld.
[ http://issues.apache.org/jira/browse/AXIS2-965?page=comments#action_12426959 ] Lori VanGulick commented on AXIS2-965: -- Yes, the tests all pass. Keep in mind the the only change to the existing code is some restructuring in WSDLxxToAxisServiceBuilder. Existing users of that class should not see any change in behavior.It is only if you use the new classes that I am introducing that you will get a List of AxisServices with their names changed to uniquely identify them. Need a way to build AxisServices for all ports/services in a wsld. -- Key: AXIS2-965 URL: http://issues.apache.org/jira/browse/AXIS2-965 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: core Reporter: Lori VanGulick Attachments: AXIS2-965patch.txt WSDL 11 allows multiple services per wsdl file, and multiple ports per service. Currently unless a service and port name are specified, WSDL11ToAxisServiceBuilder will only return the first port on the first service. I would like to provide an extension to WSDL11ToAxisServiceBuilder that would take a wsdl file and return a List of AxisService objects, one for each port in the wsdl. To make this more efficient I will need to make some minor changes to org.apache.axis2.description.WSDL11ToAxisServiceBuilder.java, i.e. - restructuring in the populateService method so that all the processing that is not specific to an AxisService is only done one time. Move this code to a new method, setup(). Setup code will include reading in the wsdl file, processing policies, imports, etc. - make some methods and fields protected instead of private so they can be accessed by subclasses. The new extension is proposed to be org.appache.axis2.description.WSDL11ToAllAxisServicesBuilder. It has a public method, popluateAllServices() which operates as follows - calls the setup() method on the parent. - iterates through all the services and all the ports in the wsdl, setting serviceName and portName on the parent. - calls up to populateService() on the parent. This will return an AxisService specific to the service and port name specified. - changes the name on the AxisService to the port name instead of the service name, so it can be uniquely identified. - returns the List of AxisService objects, one for each port in the wsdl I will also make corresponding changes for WSDL 2.0 in org.apache.axis2.description.WSDL20ToAxisServiceBuilder.java and create WSDL20ToAllAxisServicesBuilder.java. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-965) Need a way to build AxisServices for all ports/services in a wsld.
[ http://issues.apache.org/jira/browse/AXIS2-965?page=all ] Lori VanGulick updated AXIS2-965: - Attachment: AXIS2-965patch.txt I have created a patch with the implementation described in the initial comments. I have also added a testcase to test both WSDL11ToAllAxisServicesBuilder and WSDL20ToAllAxisServicesBuilder. Need a way to build AxisServices for all ports/services in a wsld. -- Key: AXIS2-965 URL: http://issues.apache.org/jira/browse/AXIS2-965 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: core Reporter: Lori VanGulick Attachments: AXIS2-965patch.txt WSDL 11 allows multiple services per wsdl file, and multiple ports per service. Currently unless a service and port name are specified, WSDL11ToAxisServiceBuilder will only return the first port on the first service. I would like to provide an extension to WSDL11ToAxisServiceBuilder that would take a wsdl file and return a List of AxisService objects, one for each port in the wsdl. To make this more efficient I will need to make some minor changes to org.apache.axis2.description.WSDL11ToAxisServiceBuilder.java, i.e. - restructuring in the populateService method so that all the processing that is not specific to an AxisService is only done one time. Move this code to a new method, setup(). Setup code will include reading in the wsdl file, processing policies, imports, etc. - make some methods and fields protected instead of private so they can be accessed by subclasses. The new extension is proposed to be org.appache.axis2.description.WSDL11ToAllAxisServicesBuilder. It has a public method, popluateAllServices() which operates as follows - calls the setup() method on the parent. - iterates through all the services and all the ports in the wsdl, setting serviceName and portName on the parent. - calls up to populateService() on the parent. This will return an AxisService specific to the service and port name specified. - changes the name on the AxisService to the port name instead of the service name, so it can be uniquely identified. - returns the List of AxisService objects, one for each port in the wsdl I will also make corresponding changes for WSDL 2.0 in org.apache.axis2.description.WSDL20ToAxisServiceBuilder.java and create WSDL20ToAllAxisServicesBuilder.java. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-965) Need a way to build AxisServices for all ports/services in a wsld.
Need a way to build AxisServices for all ports/services in a wsld. -- Key: AXIS2-965 URL: http://issues.apache.org/jira/browse/AXIS2-965 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: core Reporter: Lori VanGulick WSDL 11 allows multiple services per wsdl file, and multiple ports per service. Currently unless a service and port name are specified, WSDL11ToAxisServiceBuilder will only return the first port on the first service. I would like to provide an extension to WSDL11ToAxisServiceBuilder that would take a wsdl file and return a List of AxisService objects, one for each port in the wsdl. To make this more efficient I will need to make some minor changes to org.apache.axis2.description.WSDL11ToAxisServiceBuilder.java, i.e. - restructuring in the populateService method so that all the processing that is not specific to an AxisService is only done one time. Move this code to a new method, setup(). Setup code will include reading in the wsdl file, processing policies, imports, etc. - make some methods and fields protected instead of private so they can be accessed by subclasses. The new extension is proposed to be org.appache.axis2.description.WSDL11ToAllAxisServicesBuilder. It has a public method, popluateAllServices() which operates as follows - calls the setup() method on the parent. - iterates through all the services and all the ports in the wsdl, setting serviceName and portName on the parent. - calls up to populateService() on the parent. This will return an AxisService specific to the service and port name specified. - changes the name on the AxisService to the port name instead of the service name, so it can be uniquely identified. - returns the List of AxisService objects, one for each port in the wsdl I will also make corresponding changes for WSDL 2.0 in org.apache.axis2.description.WSDL20ToAxisServiceBuilder.java and create WSDL20ToAllAxisServicesBuilder.java. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
