[jira] Resolved: (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 ] Jeff Barrett resolved AXIS2-4158. - Resolution: Fixed Patch committed to revision 745925. Thanks for submitting the patch Lori! > 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 >Assignee: Jeff Barrett >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] Assigned: (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 ] Jeff Barrett reassigned AXIS2-4158: --- Assignee: Jeff Barrett > 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 >Assignee: Jeff Barrett >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] Resolved: (AXIS2-4198) Can not stop the ListenerManager when transports are added with the addListener() method
[ https://issues.apache.org/jira/browse/AXIS2-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-4198. - Resolution: Fixed Fix Version/s: 1.5 Fixed in trunk and 1.5 branch > Can not stop the ListenerManager when transports are added with the > addListener() method > > > Key: AXIS2-4198 > URL: https://issues.apache.org/jira/browse/AXIS2-4198 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: kernel >Affects Versions: nightly > Environment: Linux OS >Reporter: Richard Slade >Assignee: Jeff Barrett > Fix For: 1.5, nightly > > Attachments: patch > > Original Estimate: 4h > Remaining Estimate: 4h > > With recent changes to the ListenerManager with revisions 726705 and 728440. > The ListenerManager stop() method can now only be invoked after the start() > method is called because of the proper use of the 'stopped' boolean flag. But > when transports are added with the addListener() method and the 'started' > parameter is set to false, the addListener() method starts the transport > (just like invoking the start() method), but the stopped boolean is not set > to 'false'. Currently the only was to set the 'stopped' boolean flag is my > invoking the start() method. The code should be changed to set the 'stopped' > boolean flag during the addListener() method if the 'started' parameter is > set to false. > Prior to these recent changes the stop() method could be invoked with > transports added with the addListener() method. > This problem was uncovered running the sandesha2 unit tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2-4198) Can not stop the ListenerManager when transports are added with the addListener() method
[ https://issues.apache.org/jira/browse/AXIS2-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664684#action_12664684 ] Jeff Barrett commented on AXIS2-4198: - Thanks for the patch submission Rick! Fixed in trunk revision 733040 Fixed in 1_5 branch revision 735134 > Can not stop the ListenerManager when transports are added with the > addListener() method > > > Key: AXIS2-4198 > URL: https://issues.apache.org/jira/browse/AXIS2-4198 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: kernel >Affects Versions: nightly > Environment: Linux OS >Reporter: Richard Slade >Assignee: Jeff Barrett > Fix For: nightly > > Attachments: patch > > Original Estimate: 4h > Remaining Estimate: 4h > > With recent changes to the ListenerManager with revisions 726705 and 728440. > The ListenerManager stop() method can now only be invoked after the start() > method is called because of the proper use of the 'stopped' boolean flag. But > when transports are added with the addListener() method and the 'started' > parameter is set to false, the addListener() method starts the transport > (just like invoking the start() method), but the stopped boolean is not set > to 'false'. Currently the only was to set the 'stopped' boolean flag is my > invoking the start() method. The code should be changed to set the 'stopped' > boolean flag during the addListener() method if the 'started' parameter is > set to false. > Prior to these recent changes the stop() method could be invoked with > transports added with the addListener() method. > This problem was uncovered running the sandesha2 unit tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (AXIS2-4198) Can not stop the ListenerManager when transports are added with the addListener() method
[ https://issues.apache.org/jira/browse/AXIS2-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett reassigned AXIS2-4198: --- Assignee: Jeff Barrett > Can not stop the ListenerManager when transports are added with the > addListener() method > > > Key: AXIS2-4198 > URL: https://issues.apache.org/jira/browse/AXIS2-4198 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: kernel >Affects Versions: nightly > Environment: Linux OS >Reporter: Richard Slade >Assignee: Jeff Barrett > Fix For: nightly > > Attachments: patch > > Original Estimate: 4h > Remaining Estimate: 4h > > With recent changes to the ListenerManager with revisions 726705 and 728440. > The ListenerManager stop() method can now only be invoked after the start() > method is called because of the proper use of the 'stopped' boolean flag. But > when transports are added with the addListener() method and the 'started' > parameter is set to false, the addListener() method starts the transport > (just like invoking the start() method), but the stopped boolean is not set > to 'false'. Currently the only was to set the 'stopped' boolean flag is my > invoking the start() method. The code should be changed to set the 'stopped' > boolean flag during the addListener() method if the 'started' parameter is > set to false. > Prior to these recent changes the stop() method could be invoked with > transports added with the addListener() method. > This problem was uncovered running the sandesha2 unit tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2-3620) Client side support for Handler.getHeader() and MustUnderstand Check on Handler Injected headers.
[ https://issues.apache.org/jira/browse/AXIS2-3620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625485#action_12625485 ] Jeff Barrett commented on AXIS2-3620: - I added a call to the Handler getHeaders() method for JAXWS application handlers in revision 688847. I did not add the MustUnderstand checking based on the list of headers from the handlers. > Client side support for Handler.getHeader() and MustUnderstand Check on > Handler Injected headers. > - > > Key: AXIS2-3620 > URL: https://issues.apache.org/jira/browse/AXIS2-3620 > Project: Axis 2.0 (Axis2) > Issue Type: New Feature > Components: jaxws >Reporter: Nikhil Thaker >Assignee: Nikhil Thaker > > This JIRA is to add missing function in JAXWS implementation to invoke > Handler.getHeader() on JAXWS client. The function needs to perform > MustUnderstand check after the invocation on Handlers.getHeader(). This > function is very similar to what we did on server side and we will be able to > leverage some of the code that we wrote on server side. > JAXWS TCK does not check for this function on client side. So I beleive this > is a low priority item, I will provide implementation for this function. -- 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] Resolved: (AXIS2-3812) Eclipse codegen wizard fails with an invocationtargetException
[ https://issues.apache.org/jira/browse/AXIS2-3812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-3812. - Resolution: Duplicate This problem went away when I applied the patch > Eclipse codegen wizard fails with an invocationtargetException > -- > > Key: AXIS2-3812 > URL: https://issues.apache.org/jira/browse/AXIS2-3812 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: ide plugins >Affects Versions: 1.4 > Environment: winxp, jdk15, eclipse 3.2 >Reporter: anushka dayananda >Priority: Blocker > > Eclipse codegen wizard fails with an invocationtargetException. > I downloaded eclipse codegen wizard from > http://www.pangex.com/pub/apache/ws/axis2/tools/1_4/ and copied to > eclipse/plugins directory. Then i invoked the code gen wizard and tried to > generate code for a public web service located at > http://www.webservicex.net/stockquote.asmx?wsdl > However an invocationtargetexception thrown at the final step of the wizard. > Steps to reproduce: > === > 1. Open code gen wizard > 2. Select "Create Java source code from a WSDL file" > 3. Click "Next" > 4. Gave the WSDL file location as > "http://www.webservicex.net/stockquote.asmx?wsdl"; > 5. Click "Next" > 6. Gave the out put folder path. > 7. Click on "Finish" -- 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-3807) codegen changes Ant Home thus no Ant Builder task works anymore - missing AntMain
[ https://issues.apache.org/jira/browse/AXIS2-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608865#action_12608865 ] Jeff Barrett commented on AXIS2-3807: - Note that the patch for AXIS2-3792 has been commited to trunk. Based on Tom's comment above, perhaps that will resolve this issue. > codegen changes Ant Home thus no Ant Builder task works anymore - missing > AntMain > - > > Key: AXIS2-3807 > URL: https://issues.apache.org/jira/browse/AXIS2-3807 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: codegen >Affects Versions: 1.3 > Environment: Windows XP, Eclipse 3.3.2, Java 1.5.14, Ant 1.7 >Reporter: Mario L >Priority: Critical > > As soon as I copied the plugin in Eclipse plugins directory, the Ant Home > changed (see Window->Preferences->Ant->Runtime, ANt Home Entries). I didn't > do it myself so I presume the plugin did that. > Now all my project's Ant Builder tasks fail with an ominous: > java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/AntMain > at java.lang.ClassLoader.defineClass1(Native Method) > That's quite understandable, the Ant home ( the codegen plugin's /lib > directory) does not contain ant-launch.jar which exports the missing class > above. Of course I could copy the ant-launch.jar in the plugin's lib > directory, but replacing step by step the already existing Ant plugin is just > silly. The codegen should leverage the existing plugin, not provide > supplementary ant jars (chaos ensured) > If I try to workaround this in a cleaner way and add the jar to Ant classpath > as external, Eclipse will complain and not let me do it: "Specified Ant home > does not contain a "lib" directory". It looks like even the replaced Ant home > installed with the codegen plugin is wrong. > The solution is: leave the Ant path the way it is (so I had to switch back to > the Ant plugin home), and simply add the Axis2CodegenWizard.jar and whatever > other jar's you need in the Global entries (as external jar) of the above > mentioned Ant classpath. > The same solution might help also the reported bug AXIS2-3792 -- 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-3792) codegen plugin fails due to missing jar
[ https://issues.apache.org/jira/browse/AXIS2-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608847#action_12608847 ] Jeff Barrett commented on AXIS2-3792: - I commited Tom's patch to Axis2 trunk, Committed revision 672331. I did not commit any changes to the 1.4 branch. I also put a zip of the fixed plugin built against trunk Revision: 671551 (again, note that it was built against trunk and NOT the 1.4 branch). > codegen plugin fails due to missing jar > --- > > Key: AXIS2-3792 > URL: https://issues.apache.org/jira/browse/AXIS2-3792 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: Tools >Affects Versions: 1.4 > Environment: 1.4 of the codegen Eclipse plugin >Reporter: Kent Tong >Assignee: Lahiru Sandakith >Priority: Blocker > Attachments: svnDiff-head.txt, svnDiff.txt > > > When clicking "Finish" in the last step to generate Java code from WSDL, the > following exception occurs. > I believe this is a bug introduced by the commit > http://mail-archives.apache.org/mod_mbox/ws-axis-cvs/200802.mbox/[EMAIL > PROTECTED] > This change causes the plug in to use the ConcurrentHashMap class. That class > is provided by > backport-util-concurrent-2.2.jar but that jar file is not included in in the > plug's distribution (v1.4). > Here is the Eclipse console log: > > Install location: > file:/c:/eclipse/ > Configuration file: > file:/c:/eclipse/configuration/config.ini loaded > Configuration location: > file:/c:/eclipse/configuration/ > Framework located: > file:/c:/eclipse/plugins/org.eclipse.osgi_3.3.2.R33x_v20080105.jar > Framework classpath: > file:/c:/eclipse/plugins/org.eclipse.osgi_3.3.2.R33x_v20080105.jar > Splash location: > c:\eclipse\plugins\org.eclipse.platform_3.3.3.r33x_r20080129\splash.bmp > Debug options: > file:/C:/eclipse/.options not found > Time to load bundles: 16 > Starting application: 1078 > !SESSION 2008-05-05 16:17:28.265 > --- > > eclipse.buildId=M20080221-1800 > java.version=1.6.0_05 > java.vendor=Sun Microsystems Inc. > BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US > Command-line arguments: -os win32 -ws win32 -arch x86 -debug -consoleLog > > !ENTRY org.eclipse.osgi 2 1 2008-05-05 16:17:32.531 > !MESSAGE NLS unused message: _UI_LABEL_UNDEFINED_ARG1 in: > org.eclipse.wst.wsdl.u > i.internal.messages > > !ENTRY org.eclipse.osgi 2 1 2008-05-05 16:17:32.531 > !MESSAGE NLS unused message: _UI_LABEL_UNDEFINED_ARG2 in: > org.eclipse.wst.wsdl.u > i.internal.messages > > !ENTRY org.eclipse.osgi 2 1 2008-05-05 16:17:32.546 > !MESSAGE NLS unused message: _UI_LABEL_OR_UNDEFINED_ARG2 in: > org.eclipse.wst.wsd > l.ui.internal.messages > > !ENTRY org.eclipse.osgi 2 1 2008-05-05 16:17:32.562 > !MESSAGE NLS unused message: _UI_LABEL_OR_UNDEFINED_ARG3 in: > org.eclipse.wst.wsd > l.ui.internal.messages > > !ENTRY org.eclipse.osgi 2 1 2008-05-05 16:17:32.578 > !MESSAGE NLS unused message: _UI_LABEL_NO_OBJECT_SPECIFIED_ARG1 in: > org.eclipse. > wst.wsdl.ui.internal.messages > > !ENTRY org.eclipse.osgi 2 1 2008-05-05 16:17:32.578 > !MESSAGE NLS unused message: _UI_LABEL_NO_PARAMETERS_SPECIFIED in: > org.eclipse.w > st.wsdl.ui.internal.messages > Application Started: 11000 > Retrieving document at > 'C:\eclipse\workspace\SimpleServcie\SimpleService.wsdl'. > Retrieving document at > 'C:\eclipse\workspace\SimpleServcie\SimpleService.wsdl'. > java.lang.reflect.InvocationTargetException > at > org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:383) > at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:313) > at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:934) > at > org.apache.axis2.tool.codegen.eclipse.CodeGenWizard.doFinishWSDL2Java(CodeGenWizard.java:353) > at > org.apache.axis2.tool.codegen.eclipse.CodeGenWizard.performFinish(CodeGenWizard.java:171) > at > org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:742) > at > org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:373) > at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:618) > at > org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:227) > at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) > at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938) > at > org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3682) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3293) > at org.eclipse.jface.window.Window.runEventLoop(Window.java:820) > at org.eclipse.jface.window.Window.open(Window.java:79
[jira] Commented: (AXIS2-3654) Client-side role-based mustUnderstand checking for JAXWS Application Handlers
[ https://issues.apache.org/jira/browse/AXIS2-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583689#action_12583689 ] Jeff Barrett commented on AXIS2-3654: - Dims, No, I don't think it is needed for the 1.4 release. See Nikhil's comment in linked issue AXIS2-3620. > Client-side role-based mustUnderstand checking for JAXWS Application Handlers > - > > Key: AXIS2-3654 > URL: https://issues.apache.org/jira/browse/AXIS2-3654 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > > Support for server-side role-based mustUnderstand checking for JAXWS > Application Handlers was added under > https://issues.apache.org/jira/browse/AXIS2-3567. > Similar function is needed for client-side JAXWS Application Handlers. > Note that this requires https://issues.apache.org/jira/browse/AXIS2-3620 to > add client-side mustUnderstand checking based on the application handlers > getHeader(). -- 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] Resolved: (AXIS2-3679) Validation failure on using sun JDK in ParallelAsyncTests
[ https://issues.apache.org/jira/browse/AXIS2-3679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-3679. - Resolution: Fixed Committed revision 642603 > Validation failure on using sun JDK in ParallelAsyncTests > - > > Key: AXIS2-3679 > URL: https://issues.apache.org/jira/browse/AXIS2-3679 > Project: Axis 2.0 (Axis2) > Issue Type: Bug >Reporter: Jeff Barrett >Assignee: Jeff Barrett > Fix For: 1.4 > > > Tests in error: > testService_isAlive(org.apache.axis2.jaxws.sample.ParallelAsyncTests) > > testService_ExecutorShutdownNow(org.apache.axis2.jaxws.sample.ParallelAsyncTests) > > testService_ExecutorShutdownNow_2(org.apache.axis2.jaxws.sample.ParallelAsyncTests) > > testService_ExecutorShutdownNow_3(org.apache.axis2.jaxws.sample.ParallelAsyncTests) > Tests run: 5, Failures: 0, Errors: 4, Skipped: 0 > These tests pass using the IBM JDK. I am looking into this. -- 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-3679) Validation failure on using sun JDK in ParallelAsyncTests
Validation failure on using sun JDK in ParallelAsyncTests - Key: AXIS2-3679 URL: https://issues.apache.org/jira/browse/AXIS2-3679 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Jeff Barrett Assignee: Jeff Barrett Fix For: 1.4 Tests in error: testService_isAlive(org.apache.axis2.jaxws.sample.ParallelAsyncTests) testService_ExecutorShutdownNow(org.apache.axis2.jaxws.sample.ParallelAsyncTests) testService_ExecutorShutdownNow_2(org.apache.axis2.jaxws.sample.ParallelAsyncTests) testService_ExecutorShutdownNow_3(org.apache.axis2.jaxws.sample.ParallelAsyncTests) Tests run: 5, Failures: 0, Errors: 4, Skipped: 0 These tests pass using the IBM JDK. I am looking into this. -- 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] Resolved: (AXIS2-3621) @WebMethod(exclude=true) is not being honored
[ https://issues.apache.org/jira/browse/AXIS2-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-3621. - Resolution: Fixed Fixed. Committed revision 641875 > @WebMethod(exclude=true) is not being honored > - > > Key: AXIS2-3621 > URL: https://issues.apache.org/jira/browse/AXIS2-3621 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Rich Scheuerle >Assignee: Jeff Barrett >Priority: Minor > Fix For: 1.4 > > > To get the ParallelAsyncTest to pass validation, I tried to use > @WebMethod(exclude=true) on AsyncPort.customAsync(..). > Apparently the @WebMethod(exclude=true) is not being honored. > To see the error, remove the TODO at the bottom of AsyncPort. Make sure the > you run with AXIS2-3610 so that you get the validation exception that > includes all of the operation names. -- 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] Work started: (AXIS2-3621) @WebMethod(exclude=true) is not being honored
[ https://issues.apache.org/jira/browse/AXIS2-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AXIS2-3621 started by Jeff Barrett. > @WebMethod(exclude=true) is not being honored > - > > Key: AXIS2-3621 > URL: https://issues.apache.org/jira/browse/AXIS2-3621 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Rich Scheuerle >Assignee: Jeff Barrett >Priority: Minor > Fix For: 1.4 > > > To get the ParallelAsyncTest to pass validation, I tried to use > @WebMethod(exclude=true) on AsyncPort.customAsync(..). > Apparently the @WebMethod(exclude=true) is not being honored. > To see the error, remove the TODO at the bottom of AsyncPort. Make sure the > you run with AXIS2-3610 so that you get the validation exception that > includes all of the operation names. -- 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] Reopened: (AXIS2-3663) jaxws-calculator sample does not run per the README.txt
[ https://issues.apache.org/jira/browse/AXIS2-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett reopened AXIS2-3663: - The ?WSDL still works (it worked before the change). What didn't work was the client URL. We need to provide a simple client or instructions on how to create one. > jaxws-calculator sample does not run per the README.txt > > > Key: AXIS2-3663 > URL: https://issues.apache.org/jira/browse/AXIS2-3663 > Project: Axis 2.0 (Axis2) > Issue Type: Bug >Reporter: Jeff Barrett >Priority: Blocker > Fix For: 1.4 > > > Following the instructions in the README.txt, I get the following exception: > [ERROR] An error was detected during JAXWS processing > org.apache.axis2.AxisFault: An error was detected during JAXWS processing > at > org.apache.axis2.jaxws.server.JAXWSMessageReceiver.receive(JAXWSMessageReceiver.java:186) > at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176) > at > org.apache.axis2.transport.http.util.RESTUtil.invokeAxisEngine(RESTUtil.java:136) > at > org.apache.axis2.transport.http.util.RESTUtil.processURLRequest(RESTUtil.java:130) > at > org.apache.axis2.transport.http.HTTPWorker.service(HTTPWorker.java:235) > at > org.apache.axis2.transport.http.server.AxisHttpService.doService(AxisHttpService.java:281) > at > org.apache.axis2.transport.http.server.AxisHttpService.handleRequest(AxisHttpService.java:187) > at > org.apache.axis2.transport.http.server.HttpServiceProcessor.run(HttpServiceProcessor.java:84) > at > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061) > at > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575) > at java.lang.Thread.run(Thread.java:810) > Dims said he thought this might be related to this sample still using > services.xml -- 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-3664) java_first_jaxws sample does not run per README instructions
java_first_jaxws sample does not run per README instructions Key: AXIS2-3664 URL: https://issues.apache.org/jira/browse/AXIS2-3664 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Jeff Barrett Priority: Blocker Following the instructions in modules/samples/java_first_jaxws/README does not get the sample running. I copied java_first_jaxws-1.1.jar and java_first_jaxws-1.1.war from target to repository/services (note the README had no detailed instructions on this). After starting the standalone server java_first_jaxws-1.1 is reported as a fault service. The README says "Rename the resultant war as your_web_app.war and drop it into any servlet engine.", which per Dims means an instance of Tomcat (or such) needs to be running. Or the sample should be changed so it can be run in the Axis2 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-3663) jaxws-calculator sample does not run per the README.txt
jaxws-calculator sample does not run per the README.txt Key: AXIS2-3663 URL: https://issues.apache.org/jira/browse/AXIS2-3663 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Jeff Barrett Priority: Blocker Fix For: 1.4 Following the instructions in the README.txt, I get the following exception: [ERROR] An error was detected during JAXWS processing org.apache.axis2.AxisFault: An error was detected during JAXWS processing at org.apache.axis2.jaxws.server.JAXWSMessageReceiver.receive(JAXWSMessageReceiver.java:186) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176) at org.apache.axis2.transport.http.util.RESTUtil.invokeAxisEngine(RESTUtil.java:136) at org.apache.axis2.transport.http.util.RESTUtil.processURLRequest(RESTUtil.java:130) at org.apache.axis2.transport.http.HTTPWorker.service(HTTPWorker.java:235) at org.apache.axis2.transport.http.server.AxisHttpService.doService(AxisHttpService.java:281) at org.apache.axis2.transport.http.server.AxisHttpService.handleRequest(AxisHttpService.java:187) at org.apache.axis2.transport.http.server.HttpServiceProcessor.run(HttpServiceProcessor.java:84) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575) at java.lang.Thread.run(Thread.java:810) Dims said he thought this might be related to this sample still using services.xml -- 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-3654) Client-side role-based mustUnderstand checking for JAXWS Application Handlers
Client-side role-based mustUnderstand checking for JAXWS Application Handlers - Key: AXIS2-3654 URL: https://issues.apache.org/jira/browse/AXIS2-3654 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Jeff Barrett Support for server-side role-based mustUnderstand checking for JAXWS Application Handlers was added under https://issues.apache.org/jira/browse/AXIS2-3567. Similar function is needed for client-side JAXWS Application Handlers. Note that this requires https://issues.apache.org/jira/browse/AXIS2-3620 to add client-side mustUnderstand checking based on the application handlers getHeader(). -- 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] Resolved: (AXIS2-3567) Support role/actor based mustUnderstand header processing
[ https://issues.apache.org/jira/browse/AXIS2-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-3567. - Resolution: Fixed Fixed in revision 639636 > Support role/actor based mustUnderstand header processing > - > > Key: AXIS2-3567 > URL: https://issues.apache.org/jira/browse/AXIS2-3567 > Project: Axis 2.0 (Axis2) > Issue Type: Bug >Reporter: Davanum Srinivas >Assignee: Jeff Barrett > Fix For: 1.4 > > > Axis2 and JAXWS need to add support for SOAP role/actor based validation > of mustUnderstand headers. Only headers which are targeted to a > role/actor that the node supports should be considered in mustUnderstand > checks. -- 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] Resolved: (AXIS2-3626) Remove MustUnderstandValidationDispatcher / SoapMessageMUProviderChecker / MustUnderstandChecker
[ https://issues.apache.org/jira/browse/AXIS2-3626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-3626. - Resolution: Won't Fix Resolving per discussion with Dims and comment above > Remove MustUnderstandValidationDispatcher / SoapMessageMUProviderChecker / > MustUnderstandChecker > > > Key: AXIS2-3626 > URL: https://issues.apache.org/jira/browse/AXIS2-3626 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Davanum Srinivas >Assignee: Jeff Barrett >Priority: Critical > Fix For: 1.4 > > > Now that we added the hook for JAXWS to participate in mu handling, do we > need these classes anymore? > org.apache.axis2.jaxws.dispatchers.MustUnderstandValidationDispatcher > org.apache.axis2.jaxws.provider.SoapMessageMUProviderChecker > org.apache.axis2.jaxws.dispatchers.MustUnderstandChecker > thanks, > dims -- 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-3626) Remove MustUnderstandValidationDispatcher / SoapMessageMUProviderChecker / MustUnderstandChecker
[ https://issues.apache.org/jira/browse/AXIS2-3626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580404#action_12580404 ] Jeff Barrett commented on AXIS2-3626: - Dims and I just discussed this on the phone. The function added under Axis2-3568 does not duplicate the code in these classes. Specifically, that Jira added the ability for JAXWS Handlers associated with an endpoint to participate in mustUnderstand processing. The purpose of the other classes is: a) MustUnderstandValidationDispatcher checks for a very specific conformance requirement in the JAXWS 2.0 TCK that states that an operation that can not be resolved and that includes unprocessed mustUnderstand headers must get mustUnderstand fault, not an operation not found fault. b) SoapMessageMUProviderChecker is actually part of a test, so should be ignored for this Jira. c) MustUnderstandChecker: This marks any headers corresponding to paramaters on the SEI as understood. So, (a) and (c) don't duplicate any new code. While the logic could be moved to the JAXWS Message Receiver alongside the new code for Axis2-3568, I don't think we should do that. The reason is that (a) and (c) are processing mustUnderstand headers in the dispatch chain, which is the prefered way of doing that. The code added to allow the JAXWS application handlers to be involved in mustUnderstand processing had to be done in the MessageReceiver because the handlers could only be invoked (to get the list of headers they understand) after the container breech since the handlers must run under the application context. > Remove MustUnderstandValidationDispatcher / SoapMessageMUProviderChecker / > MustUnderstandChecker > > > Key: AXIS2-3626 > URL: https://issues.apache.org/jira/browse/AXIS2-3626 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Davanum Srinivas >Assignee: Jeff Barrett >Priority: Critical > Fix For: 1.4 > > > Now that we added the hook for JAXWS to participate in mu handling, do we > need these classes anymore? > org.apache.axis2.jaxws.dispatchers.MustUnderstandValidationDispatcher > org.apache.axis2.jaxws.provider.SoapMessageMUProviderChecker > org.apache.axis2.jaxws.dispatchers.MustUnderstandChecker > thanks, > dims -- 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] Assigned: (AXIS2-3626) Remove MustUnderstandValidationDispatcher / SoapMessageMUProviderChecker / MustUnderstandChecker
[ https://issues.apache.org/jira/browse/AXIS2-3626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett reassigned AXIS2-3626: --- Assignee: Jeff Barrett (was: Nikhil Thaker) > Remove MustUnderstandValidationDispatcher / SoapMessageMUProviderChecker / > MustUnderstandChecker > > > Key: AXIS2-3626 > URL: https://issues.apache.org/jira/browse/AXIS2-3626 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Davanum Srinivas >Assignee: Jeff Barrett >Priority: Critical > Fix For: 1.4 > > > Now that we added the hook for JAXWS to participate in mu handling, do we > need these classes anymore? > org.apache.axis2.jaxws.dispatchers.MustUnderstandValidationDispatcher > org.apache.axis2.jaxws.provider.SoapMessageMUProviderChecker > org.apache.axis2.jaxws.dispatchers.MustUnderstandChecker > thanks, > dims -- 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] Closed: (AXIS2-2853) Pluggable Must Understand Handling?
[ https://issues.apache.org/jira/browse/AXIS2-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett closed AXIS2-2853. --- Resolution: Duplicate This will be fixed by making an explicit check for the JAXWS Message Receiver and delegating the mustUnderstand checking to it. This change will be done under https://issues.apache.org/jira/browse/AXIS2-3568 > Pluggable Must Understand Handling? > --- > > Key: AXIS2-2853 > URL: https://issues.apache.org/jira/browse/AXIS2-2853 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement >Reporter: Davanum Srinivas >Assignee: Jeff Barrett >Priority: Critical > Fix For: 1.4 > > > Discussion here - http://marc.info/?t=11826680171&r=1&w=2 -- 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-2853) Pluggable Must Understand Handling?
[ https://issues.apache.org/jira/browse/AXIS2-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575415#action_12575415 ] Jeff Barrett commented on AXIS2-2853: - I think the remaining work will be covered by fixing https://issues.apache.org/jira/browse/AXIS2-3568 > Pluggable Must Understand Handling? > --- > > Key: AXIS2-2853 > URL: https://issues.apache.org/jira/browse/AXIS2-2853 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement >Reporter: Davanum Srinivas >Assignee: Jeff Barrett >Priority: Critical > Fix For: 1.4 > > > Discussion here - http://marc.info/?t=11826680171&r=1&w=2 -- 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] Closed: (AXIS2-3439) Support JAX-WS and Metadata client-side sparse composite to override certain annotation members
[ https://issues.apache.org/jira/browse/AXIS2-3439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett closed AXIS2-3439. --- Code dropped to SVN as noted above. > Support JAX-WS and Metadata client-side sparse composite to override certain > annotation members > --- > > Key: AXIS2-3439 > URL: https://issues.apache.org/jira/browse/AXIS2-3439 > Project: Axis 2.0 (Axis2) > Issue Type: New Feature > Components: jaxws >Reporter: Jeff Barrett >Assignee: Jeff Barrett > > Add support for a JAX-WS client to use a sparse DescriptionBuilderComposite > to override certain annotation values specified in the client artifacts on a > per-SerivceDelegate basis. This support is the basis for supporting > additional client-side metadata, such a deployment descriptor information. > Added additional tests to verify the new functionality. -- 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] Resolved: (AXIS2-3439) Support JAX-WS and Metadata client-side sparse composite to override certain annotation members
[ https://issues.apache.org/jira/browse/AXIS2-3439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-3439. - Resolution: Fixed Changes committed in revision 611042 > Support JAX-WS and Metadata client-side sparse composite to override certain > annotation members > --- > > Key: AXIS2-3439 > URL: https://issues.apache.org/jira/browse/AXIS2-3439 > Project: Axis 2.0 (Axis2) > Issue Type: New Feature > Components: jaxws >Reporter: Jeff Barrett >Assignee: Jeff Barrett > > Add support for a JAX-WS client to use a sparse DescriptionBuilderComposite > to override certain annotation values specified in the client artifacts on a > per-SerivceDelegate basis. This support is the basis for supporting > additional client-side metadata, such a deployment descriptor information. > Added additional tests to verify the new functionality. -- 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-3439) Support JAX-WS and Metadata client-side sparse composite to override certain annotation members
Support JAX-WS and Metadata client-side sparse composite to override certain annotation members --- Key: AXIS2-3439 URL: https://issues.apache.org/jira/browse/AXIS2-3439 Project: Axis 2.0 (Axis2) Issue Type: New Feature Components: jaxws Reporter: Jeff Barrett Assignee: Jeff Barrett Add support for a JAX-WS client to use a sparse DescriptionBuilderComposite to override certain annotation values specified in the client artifacts on a per-SerivceDelegate basis. This support is the basis for supporting additional client-side metadata, such a deployment descriptor information. Added additional tests to verify the new functionality. -- 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] Resolved: (AXIS2-2525) AnnotationServiceImplDescriptionTests broken
[ https://issues.apache.org/jira/browse/AXIS2-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2525. - Resolution: Fixed Fixed in Committed revision 579726 > AnnotationServiceImplDescriptionTests broken > > > Key: AXIS2-2525 > URL: https://issues.apache.org/jira/browse/AXIS2-2525 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Davanum Srinivas >Assignee: Jeff Barrett > > Testsuite: > org.apache.axis2.jaxws.description.AnnotationServiceImplDescriptionTests > Tests run: 3, Failures: 0, Errors: 1, Time elapsed: 0.562 sec > Testcase: > testOverloadedServiceImplWithSEI(org.apache.axis2.jaxws.description.AnnotationServiceImplDescriptionTests): > Caused an ERROR > Validation error: SEI return value java.util.concurrent.Future does not > match implementation method return value > javax.xml.ws.Response; > Implementation class: > org.apache.axis2.jaxws.description.DocLitWrappedImplWithSEI; Method name: > twoWayAsync; Endpoint Interface: > org.apache.axis2.jaxws.description.DocLitWrappedProxy > javax.xml.ws.WebServiceException: Validation error: SEI return value > java.util.concurrent.Future does not match implementation method return > value javax.xml.ws.Response; > Implementation class: > org.apache.axis2.jaxws.description.DocLitWrappedImplWithSEI; Method name: > twoWayAsync; Endpoint Interface: > org.apache.axis2.jaxws.description.DocLitWrappedProxy > at > org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:170) > at > org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:67) > at > org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:115) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateMethodReturnValue(ServiceDescriptionImpl.java:1079) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateImplementation(ServiceDescriptionImpl.java:984) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateIntegrity(ServiceDescriptionImpl.java:781) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateDBCLIntegrity(ServiceDescriptionImpl.java:627) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.(ServiceDescriptionImpl.java:175) > at > org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.createServiceDescriptionFromDBCMap(DescriptionFactoryImpl.java:169) > at > org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.createServiceDescription(DescriptionFactoryImpl.java:138) > at > org.apache.axis2.jaxws.description.DescriptionFactory.createServiceDescription(DescriptionFactory.java:141) > at > org.apache.axis2.jaxws.description.AnnotationServiceImplDescriptionTests.testOverloadedServiceImplWithSEI(AnnotationServiceImplDescriptionTests.java:134) -- 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-2525) AnnotationServiceImplDescriptionTests broken
[ https://issues.apache.org/jira/browse/AXIS2-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530478 ] Jeff Barrett commented on AXIS2-2525: - Working on this now; just about have it fixed. It is a problem with the validation logic and overloaded methods. The Sun compiler is returning an unordered collection in a different order than the IBM compiler, which is what surfaced the problem. > AnnotationServiceImplDescriptionTests broken > > > Key: AXIS2-2525 > URL: https://issues.apache.org/jira/browse/AXIS2-2525 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Davanum Srinivas >Assignee: Jeff Barrett > > Testsuite: > org.apache.axis2.jaxws.description.AnnotationServiceImplDescriptionTests > Tests run: 3, Failures: 0, Errors: 1, Time elapsed: 0.562 sec > Testcase: > testOverloadedServiceImplWithSEI(org.apache.axis2.jaxws.description.AnnotationServiceImplDescriptionTests): > Caused an ERROR > Validation error: SEI return value java.util.concurrent.Future does not > match implementation method return value > javax.xml.ws.Response; > Implementation class: > org.apache.axis2.jaxws.description.DocLitWrappedImplWithSEI; Method name: > twoWayAsync; Endpoint Interface: > org.apache.axis2.jaxws.description.DocLitWrappedProxy > javax.xml.ws.WebServiceException: Validation error: SEI return value > java.util.concurrent.Future does not match implementation method return > value javax.xml.ws.Response; > Implementation class: > org.apache.axis2.jaxws.description.DocLitWrappedImplWithSEI; Method name: > twoWayAsync; Endpoint Interface: > org.apache.axis2.jaxws.description.DocLitWrappedProxy > at > org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:170) > at > org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:67) > at > org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:115) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateMethodReturnValue(ServiceDescriptionImpl.java:1079) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateImplementation(ServiceDescriptionImpl.java:984) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateIntegrity(ServiceDescriptionImpl.java:781) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateDBCLIntegrity(ServiceDescriptionImpl.java:627) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.(ServiceDescriptionImpl.java:175) > at > org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.createServiceDescriptionFromDBCMap(DescriptionFactoryImpl.java:169) > at > org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.createServiceDescription(DescriptionFactoryImpl.java:138) > at > org.apache.axis2.jaxws.description.DescriptionFactory.createServiceDescription(DescriptionFactory.java:141) > at > org.apache.axis2.jaxws.description.AnnotationServiceImplDescriptionTests.testOverloadedServiceImplWithSEI(AnnotationServiceImplDescriptionTests.java:134) -- 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-3223) Plug JAX-WS / MDQ deployment into Axis2 deployment model
Plug JAX-WS / MDQ deployment into Axis2 deployment model Key: AXIS2-3223 URL: https://issues.apache.org/jira/browse/AXIS2-3223 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Reporter: Jeff Barrett Assignee: Roy A. Wood Jr. Currently the metadata processing for JAXWS (i.e. the creation of the metadata description hierachy based on annotations and WSDL) is not integrated into the Axis2 deployment model. The JAXWS unit tests are using a deprecated factory method which builds the desription hierarchy when an inbound request for a service is received. The deprecated method DescriptionFactory.createServiceDescriptionFromServiceImpl(implClass, axisSvc) is called from EndpointController.getEndpointDescription. This deprecated method causes obsolete code paths to be executed and does not go down code paths that are used for actual server integration. Actual server integration (for example in Geronimo) plugs the JAXWS metadata processing into the server's deployment logic. This is done by creating DescriptionBuilderComposite objects and using those DBCs to create the JAXWS/Metadata description hierarchy. The processes of creating the JAXWS descrition hierachy also creates the Axis2 description hierachy (e.g. AxisService and such) based on annotations (and/or WSDL). I think the following needs to be done: 1. Add a plug point in the Axis2 deployment logic that allows plugging in to the deployment logic, or perhaps overridding it completely 2. In the JAXWS integration-level tests (which require a running server), the plugpoint or override would create the JAXWS and associated Axis2 description hierachy during application deployment. 3. The logic in EndpointController.getEndpointDescription should change to consider not finding the JAXWS description hierachy an error and reject the inbound request. The deprecated method DescriptionFactory.createServiceDescriptionFromServiceImpl(implClass, axisSvc) should be removed. 4. Note that there is a convenience method DescriptionFactory.createServiceDescription(Class) that will take an implementation class and create the DBCs using relfection which may be helpful. -- 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] Resolved: (AXIS2-3129) ProviderDispatcher in JAX-WS does not allow for non-parameterized interfaces on provider implementation
[ https://issues.apache.org/jira/browse/AXIS2-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-3129. - Resolution: Fixed Patch committed to revision 568722. Thanks, Dustin! > ProviderDispatcher in JAX-WS does not allow for non-parameterized interfaces > on provider implementation > --- > > Key: AXIS2-3129 > URL: https://issues.apache.org/jira/browse/AXIS2-3129 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Affects Versions: nightly >Reporter: Dustin Amrhein >Assignee: Jeff Barrett > Fix For: nightly > > Attachments: patch.txt > > > The ProviderDispatcher in JAX-WS does not allow for non-parameterized > interfaces on a provider based implementation. This causes a > ClassCastException in the getProviderType method as the code assumes that the > result of calling getGenericInterfaces on the implementation Class object > will result in an array of ParameterizedTypes. If an object is not in the > array is not an instance of a ParameterizedType then an exception is thrown. > This check should only be done if the interface in question is the > javax.xml.ws.Provider interface. Web service provider implementations should > be free to implement other, non-parameterized interfaces. -- 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] Assigned: (AXIS2-3129) ProviderDispatcher in JAX-WS does not allow for non-parameterized interfaces on provider implementation
[ https://issues.apache.org/jira/browse/AXIS2-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett reassigned AXIS2-3129: --- Assignee: Jeff Barrett > ProviderDispatcher in JAX-WS does not allow for non-parameterized interfaces > on provider implementation > --- > > Key: AXIS2-3129 > URL: https://issues.apache.org/jira/browse/AXIS2-3129 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Affects Versions: nightly >Reporter: Dustin Amrhein >Assignee: Jeff Barrett > Fix For: nightly > > Attachments: patch.txt > > > The ProviderDispatcher in JAX-WS does not allow for non-parameterized > interfaces on a provider based implementation. This causes a > ClassCastException in the getProviderType method as the code assumes that the > result of calling getGenericInterfaces on the implementation Class object > will result in an array of ParameterizedTypes. If an object is not in the > array is not an instance of a ParameterizedType then an exception is thrown. > This check should only be done if the interface in question is the > javax.xml.ws.Provider interface. Web service provider implementations should > be free to implement other, non-parameterized interfaces. -- 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-3011) ServiceDescription caching leads to memory leak
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516743 ] Jeff Barrett commented on AXIS2-3011: - Hi Jarek, Here are a few things we need to consider regarding the scoping of the cache and freeing it up 1) There is no client API that indicates the client is done with the Service it created. So, there's really no safe place for the ServiceDelegate and the associated ServiceDescription hierachy to be released as far as I can tell. Until the client "exits", it could use that Service. In an unmanaged environment, that "exit" is the VM exit. In a managed case, that "exit" could be the module (in J2EE terms) being stopped and unloaded; so in the managed case, there may be an opporunity to remove the ServiceDelegate and associated ServiceDescription hierachy. In the unmanaged case, I don't know how we could do that. 2) The ServiceDelegate and the associated ServiceDescription hierachy is created when the client does a Service.create(...). If a client creates a new Service in a loop, it may run out of memory, just as it might creating other sorts of objects. I grant that only being able to create a "few hundred" is probably smaller than expected. Still, creating a few hundred distinct ServiceDelegates in a client may be a bit of a corner usecase. 3) Related to (1) above, the expectation is that a managed environment will provide its own implementation of the ClientConfigurationFactory which would scope the Service (and thus the ConfigurationContext and ServiceDescription hierchy), for example, to a module. The version of the ClientConfigurationFactory in SVN is for the J2SE unmanaged client case, where the scoping is VM-wide. 4) As Dustin noted regarding removing the ServiceDescription when the wsdl file is changed (or for any cache cleaning), there is a timing issue that needs to be addressed. The ServiceDescription hierachy can't be re-initialized if there are any in-flight requests. This is particularly a problem with async responses which haven't arrived yet. Perhaps some sort of "outstanding response" indicator that wouldn't cleanup the Service until the response was received might work, with logic that would throw an exception after that if the Service was used. I'm not sure that would be spec-compliant though. And it brings up the interesting situation of a client possibly having multiple ServiceDelegates to a Service with different versions of the WSDL. I think that you bring up very good points, and there is certainly room for improvement here. There are some subtle issues that need to be considered, though. > ServiceDescription caching leads to memory leak > --- > > Key: AXIS2-3011 > URL: https://issues.apache.org/jira/browse/AXIS2-3011 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jarek Gawor >Assignee: Ann Robinson > Attachments: AXIS2-3011.patch > > > The DescriptionFactoryImpl.createServiceDescription() function attempts to > cache/reuse the ServiceDescription objects and that leads to memory leaks. > First, a Hashtable is used for the cache. That means, any ServiceDescription > created will always live in the cache and won't ever be reclaimed (and there > is no clear cache function). Some sort of WeakHashMap could help the problem > so that at least some unused ServiceDescription objects could be reclaimed. > Second, the createServiceDescription() uses the > DescriptionFactory.createClientConfigurationFactory().getClientConfigurationContext() > to get the client configuration context. It looks like by default the > ClientConfigurationFactory.getClientConfigurationContext() does NOT cache the > configuration context. Therefore, each call creates a new configuration > object. That means, that by default ServiceDescription will NOT be reused > since the configuration context object instance is used to determine if the > ServiceDescription should be reused or not (see DescriptionKey.equals() > function). > So, a simple program that calls createServiceDescription() repeatably in a > loop (with the same arguments) will quickly run out of memory. -- 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-2853) Pluggable Must Understand Handling?
[ https://issues.apache.org/jira/browse/AXIS2-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513636 ] Jeff Barrett commented on AXIS2-2853: - Added a JAXWS handler that will mark SOAP Headers which correspond to SEI method parameters as processed. This will get the message through the mustUnderstand checks in the engine. Commited revision 557313. This handler needs to be added to the axis2.xml file for the client and server when JAXWS is being used. You can see an example in the axis2.xml commited in revision 557313. Basically, add the following to phaseOrder "InFlow" and "InFaultFlow" for the phase "OperationInPhase" > Pluggable Must Understand Handling? > --- > > Key: AXIS2-2853 > URL: https://issues.apache.org/jira/browse/AXIS2-2853 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement >Reporter: Davanum Srinivas >Assignee: Jeff Barrett >Priority: Critical > Fix For: 1.3 > > > Discussion here - http://marc.info/?t=11826680171&r=1&w=2 -- 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] Assigned: (AXIS2-2978) Attachment optimization properties are not current in client request context
[
https://issues.apache.org/jira/browse/AXIS2-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Barrett reassigned AXIS2-2978:
---
Assignee: Nikhil Thaker (was: Jeff Barrett)
Nikhil is going to handle this.
> Attachment optimization properties are not current in client request context
>
>
> Key: AXIS2-2978
> URL: https://issues.apache.org/jira/browse/AXIS2-2978
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: jaxws
>Affects Versions: M2
>Reporter: Samuel Isokpunwu
>Assignee: Nikhil Thaker
> Attachments: bt66899patch.txt
>
>
> The client request context is not properly updated when mtom enablement state
> properties changes.
> Example test scenario:
>{
> -
> -
> SOAPBinding binding = (SOAPBinding)dispatch.getBinding();
> binding.setMTOMEnabled(true);
> -
> response = dispatch.invoke(request);
> -
> binding.setMTOMEnabled(false);
> -
> response = dispatch.invoke(request);
> -
> -
>}
> Since the client request context for a previous request is being cached and
> reused for a subsequent request, any attachment optimization properties
> changes, in the test scenario above, are ignored. Will be adding code to
> check and copy over any new properties updates.
--
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-2853) Pluggable Must Understand Handling?
[ https://issues.apache.org/jira/browse/AXIS2-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513407 ] Jeff Barrett commented on AXIS2-2853: - Per discussion on the list and via IRC chat (transcript also posted to the list), I will implement an interim solution which uses a handler to mark the appropriate headers as "processed", indicitatng that the are understood. This will not require additional APIs in the kernel for either registering understood headers or for adding plugins specific to the mustUnderstand validation. Changed AxisEngine to check mustUnderstand on inbound messages to client (in addition to server); add testcase to verify that behavior; add test verify using handler to mark specific header QNames to pass mustUnderstand validation in the engine for inbound messages on client and server. Committed revision 557104. Contributed by Samuel Isokpunwu and Jeff Barrett. The JAXWS handler to mark the appropriate headers will be committed seperately. > Pluggable Must Understand Handling? > --- > > Key: AXIS2-2853 > URL: https://issues.apache.org/jira/browse/AXIS2-2853 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement >Reporter: Davanum Srinivas >Assignee: Jeff Barrett >Priority: Critical > Fix For: 1.3 > > > Discussion here - http://marc.info/?t=11826680171&r=1&w=2 -- 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-2853) Pluggable Must Understand Handling?
[ https://issues.apache.org/jira/browse/AXIS2-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513332 ] Jeff Barrett commented on AXIS2-2853: - The changes commited to revision 556761 have been reverted in revision 557028 per email discussions in the link posted by Glen Daniels above and IRC chats. > Pluggable Must Understand Handling? > --- > > Key: AXIS2-2853 > URL: https://issues.apache.org/jira/browse/AXIS2-2853 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement >Reporter: Davanum Srinivas >Assignee: Jeff Barrett >Priority: Critical > Fix For: 1.3 > > > Discussion here - http://marc.info/?t=11826680171&r=1&w=2 -- 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] Resolved: (AXIS2-2853) Pluggable Must Understand Handling?
[ https://issues.apache.org/jira/browse/AXIS2-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2853. - Resolution: Fixed Implented pluggable mustUnderstand checker framework. The previous comment of a temporary JAXWS workaround will not be necessary; the JAXWS validators will plug into the new framework. The framework (without the JAXWS validators) is in committed revision 556761. > Pluggable Must Understand Handling? > --- > > Key: AXIS2-2853 > URL: https://issues.apache.org/jira/browse/AXIS2-2853 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement >Reporter: Davanum Srinivas >Assignee: Jeff Barrett >Priority: Critical > Fix For: 1.3 > > > Discussion here - http://marc.info/?t=11826680171&r=1&w=2 -- 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-2853) Pluggable Must Understand Handling?
[ https://issues.apache.org/jira/browse/AXIS2-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509989 ] Jeff Barrett commented on AXIS2-2853: - I have backed out the changes made (under revision 549924) which introduced the API. This rollback was commited in revision 552954. Note that this does not fix this Jira; it simply removes the API changes for RC1. Fixing this Jira as discussed on the list will be done as follows: I think for 1.3, the JAXWS handler hack will work. Here's my proposal for 1.3 which removes the new API from AxisOperation added in revision 549924 and has a minimal effect on the JAXWS code that is doing the mustUnderstand validation for SEI header parameters: 1) In modules/kernel, remove the following methods from AxisOperation: registerUnderstoodHeaderQNames(QName) and getUnderstoodHeaderQNames(). This removes the new API that Sanjiva was concerned about. (Done in revision 552954) 2) In modules/metadata, change OperationDesc from using the above AxisOperation methods to instead set a property on the AxisOperation to contain the QNames for header parameters. 3) In modules/jaxws, add a new JAXWS handler which will look on the AxisOperation for the property set in (2) and if found it will mark any headers with the associated QNames as processed. 4) In modules/kernel AxisEngine, remove the understood-header-processing logic from checkMustUnderstand and change it back to simply checking for any headers that are marked mustUnderstand bur are not marked processed. (Done in revision 552954) I will not update axis2.xml to include the handler in (3); that can be done systems that are integrating Axis2 and JAXWS (such as Geronimo). For post-1.3, I have a proposal for extensible, pluggable mustUnderstand-header-validation that solves all the problems we were discussing, including allowing higher level components to participate in mustUnderstand checking. I will be sending out that post 1.3 proposal later on. > Pluggable Must Understand Handling? > --- > > Key: AXIS2-2853 > URL: https://issues.apache.org/jira/browse/AXIS2-2853 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement >Reporter: Davanum Srinivas >Assignee: Jeff Barrett >Priority: Blocker > Fix For: 1.3 > > > Discussion here - http://marc.info/?t=11826680171&r=1&w=2 -- 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-2853) Pluggable Must Understand Handling?
[ https://issues.apache.org/jira/browse/AXIS2-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509983 ] Jeff Barrett commented on AXIS2-2853: - Dims, Thanks for the offer, but I'm working on backing out revision 549924 right now. That's the revison that introduced the API change to AxisOperation. With that revision backed out, there will be no API difference. I think with that backed out, this Jira is no longer a blocker. Do you agree? I'll work on a JAXWS-handler based solution for header-based SEI parameters next week. That will not introduce any API changes. > Pluggable Must Understand Handling? > --- > > Key: AXIS2-2853 > URL: https://issues.apache.org/jira/browse/AXIS2-2853 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement >Reporter: Davanum Srinivas >Assignee: Jeff Barrett >Priority: Blocker > Fix For: 1.3 > > > Discussion here - http://marc.info/?t=11826680171&r=1&w=2 -- 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] Resolved: (AXIS2-2888) RPCLitMethodMarshaller should take bindng namespace into account
[ https://issues.apache.org/jira/browse/AXIS2-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2888. - Resolution: Fixed Commited to revision 552921. Thanks, Dustin! > RPCLitMethodMarshaller should take bindng namespace into account > > > Key: AXIS2-2888 > URL: https://issues.apache.org/jira/browse/AXIS2-2888 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Affects Versions: nightly >Reporter: Dustin Amrhein >Assignee: Jeff Barrett > Fix For: nightly > > Attachments: patch.txt > > > When constructing the operation QName, the RPCLitMethodMarshaller should > first consult the binding operation element to determine if there is a > namespace specified. If there is no namespace on the binding operation, it > should then use the target namespace of the WSDL document. As it stands now, > the RPCLitMethodMarshaller always uses the target namespace of the WSDL > document. -- 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] Assigned: (AXIS2-2888) RPCLitMethodMarshaller should take bindng namespace into account
[ https://issues.apache.org/jira/browse/AXIS2-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett reassigned AXIS2-2888: --- Assignee: Jeff Barrett > RPCLitMethodMarshaller should take bindng namespace into account > > > Key: AXIS2-2888 > URL: https://issues.apache.org/jira/browse/AXIS2-2888 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Affects Versions: nightly >Reporter: Dustin Amrhein >Assignee: Jeff Barrett > Fix For: nightly > > Attachments: patch.txt > > > When constructing the operation QName, the RPCLitMethodMarshaller should > first consult the binding operation element to determine if there is a > namespace specified. If there is no namespace on the binding operation, it > should then use the target namespace of the WSDL document. As it stands now, > the RPCLitMethodMarshaller always uses the target namespace of the WSDL > document. -- 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] Resolved: (AXIS2-2851) Move RESPONSE_WRITTEN flag from OperationContext to RequestResponseTransport instance
[ https://issues.apache.org/jira/browse/AXIS2-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2851. - Resolution: Fixed Patch was commited to SVN as noted above. > Move RESPONSE_WRITTEN flag from OperationContext to RequestResponseTransport > instance > - > > Key: AXIS2-2851 > URL: https://issues.apache.org/jira/browse/AXIS2-2851 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: kernel >Affects Versions: nightly >Reporter: Dustin Amrhein >Assignee: Jeff Barrett > Fix For: nightly > > Attachments: patch.txt > > > In order to properly integrate with Sandesha, we need to move the > RESPONSE_WRITTEN from the OperationContext to the RequestResponseTransport > instance. Specifically these changes were made in order to allow Axis2 and > Sandesha to handle the oneway request case in which data is sent back in the > ack. This will allow transport code to determine if data was sent back as the > RESPONSE_WRITTEN will now be on the RequestResponseTransport instance instead > of the OperationContext, which in the case of an ack is not available. -- 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-2851) Move RESPONSE_WRITTEN flag from OperationContext to RequestResponseTransport instance
[ https://issues.apache.org/jira/browse/AXIS2-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508201 ] Jeff Barrett commented on AXIS2-2851: - The patch was commited to revision 550753. > Move RESPONSE_WRITTEN flag from OperationContext to RequestResponseTransport > instance > - > > Key: AXIS2-2851 > URL: https://issues.apache.org/jira/browse/AXIS2-2851 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: kernel >Affects Versions: nightly >Reporter: Dustin Amrhein >Assignee: Jeff Barrett > Fix For: nightly > > Attachments: patch.txt > > > In order to properly integrate with Sandesha, we need to move the > RESPONSE_WRITTEN from the OperationContext to the RequestResponseTransport > instance. Specifically these changes were made in order to allow Axis2 and > Sandesha to handle the oneway request case in which data is sent back in the > ack. This will allow transport code to determine if data was sent back as the > RESPONSE_WRITTEN will now be on the RequestResponseTransport instance instead > of the OperationContext, which in the case of an ack is not available. -- 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] Resolved: (AXIS2-2597) Support WS-A action generation from pure annotations
[ https://issues.apache.org/jira/browse/AXIS2-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2597. - Resolution: Fixed Commited patch to revision 550594. Thanks, Roy! > Support WS-A action generation from pure annotations > > > Key: AXIS2-2597 > URL: https://issues.apache.org/jira/browse/AXIS2-2597 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Roy A. Wood Jr. >Assignee: Jeff Barrett > Attachments: patch_2246_2249.txt > > > Need to be able to generate ws-a actions from annotations only. When WSDL is > present, this is handled by populateServices w/in WSDL11ToAxisServicesBuilder -- 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] Resolved: (AXIS2-2216) Enable client side validation
[ https://issues.apache.org/jira/browse/AXIS2-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2216. - Resolution: Fixed The changes for this Jira were commited under Jira https://issues.apache.org/jira/browse/AXIS2-2308 into revision 527652. > Enable client side validation > - > > Key: AXIS2-2216 > URL: https://issues.apache.org/jira/browse/AXIS2-2216 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Roy A. Wood Jr. >Assignee: Jeff Barrett >Priority: Minor > Attachments: DBC0219_patch.txt, DBC_0228_patch.txt, DBC_0301_patch.txt > > > Currently, the validation is only enabled on the server side. This fix > enables it for the client side as well. -- 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] Closed: (AXIS2-2538) Fix NPE in getSyncOperation()
[ https://issues.apache.org/jira/browse/AXIS2-2538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett closed AXIS2-2538. --- > Fix NPE in getSyncOperation() > - > > Key: AXIS2-2538 > URL: https://issues.apache.org/jira/browse/AXIS2-2538 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Roy A. Wood Jr. >Priority: Minor > Attachments: patch_2158_2162.txt > > > The getSyncOperation in OperationDescriptionImpl will throw an NPE if the > call to getJavaMethodName is null. This issue fixes that problem -- 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] Resolved: (AXIS2-2538) Fix NPE in getSyncOperation()
[ https://issues.apache.org/jira/browse/AXIS2-2538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2538. - Resolution: Fixed Patch commited to revision 534196. > Fix NPE in getSyncOperation() > - > > Key: AXIS2-2538 > URL: https://issues.apache.org/jira/browse/AXIS2-2538 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Roy A. Wood Jr. >Priority: Minor > Attachments: patch_2158_2162.txt > > > The getSyncOperation in OperationDescriptionImpl will throw an NPE if the > call to getJavaMethodName is null. This issue fixes that problem -- 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] Closed: (AXIS2-2563) SOAPBinding JAX-WS API class is incorrect
[ https://issues.apache.org/jira/browse/AXIS2-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett closed AXIS2-2563. --- > SOAPBinding JAX-WS API class is incorrect > - > > Key: AXIS2-2563 > URL: https://issues.apache.org/jira/browse/AXIS2-2563 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > > The SOAPBinding JAXWS API class role-related methods should use Set > not Set -- 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] Resolved: (AXIS2-2563) SOAPBinding JAX-WS API class is incorrect
[ https://issues.apache.org/jira/browse/AXIS2-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2563. - Resolution: Fixed Fixed in commited revision 530529 > SOAPBinding JAX-WS API class is incorrect > - > > Key: AXIS2-2563 > URL: https://issues.apache.org/jira/browse/AXIS2-2563 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > > The SOAPBinding JAXWS API class role-related methods should use Set > not Set -- 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-2563) SOAPBinding JAX-WS API class is incorrect
[ https://issues.apache.org/jira/browse/AXIS2-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490073 ] Jeff Barrett commented on AXIS2-2563: - I'm working on this now. > SOAPBinding JAX-WS API class is incorrect > - > > Key: AXIS2-2563 > URL: https://issues.apache.org/jira/browse/AXIS2-2563 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > > The SOAPBinding JAXWS API class role-related methods should use Set > not Set -- 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-2563) SOAPBinding JAX-WS API class is incorrect
SOAPBinding JAX-WS API class is incorrect - Key: AXIS2-2563 URL: https://issues.apache.org/jira/browse/AXIS2-2563 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Jeff Barrett The SOAPBinding JAXWS API class role-related methods should use Set not Set -- 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-2550) SoapMessageProviderTests.testProviderSourceXMLOnly broken
[ https://issues.apache.org/jira/browse/AXIS2-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489802 ] Jeff Barrett commented on AXIS2-2550: - After fixing the tests to use the JUnit assert* methods and the service implementations to throw RuntimeExceptions instead of calling assert() [in SVN revision 529757], and turning on DEBUG logging: - Standard Error - // From the Server-side logging: java.lang.RuntimeException: Assertion false at org.apache.axis2.jaxws.provider.soapmsg.SoapMessageProvider.assertTrue(SoapMessageProvider.java:381) at org.apache.axis2.jaxws.provider.soapmsg.SoapMessageProvider.getXMLResponse(SoapMessageProvider.java:196) at org.apache.axis2.jaxws.provider.soapmsg.SoapMessageProvider.invoke(SoapMessageProvider.java:126) at org.apache.axis2.jaxws.provider.soapmsg.SoapMessageProvider.invoke(SoapMessageProvider.java:55) at org.apache.axis2.jaxws.server.dispatcher.ProviderDispatcher$1.run(ProviderDispatcher.java:178) at org.apache.axis2.java.security.AccessController.doPrivileged(AccessController.java:74) at org.apache.axis2.jaxws.server.dispatcher.ProviderDispatcher.invoke(ProviderDispatcher.java:175) at org.apache.axis2.jaxws.server.EndpointController.invoke(EndpointController.java:169) at org.apache.axis2.jaxws.server.JAXWSMessageReceiver.receive(JAXWSMessageReceiver.java:103) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:138) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:279) at org.apache.axis2.transport.http.HTTPWorker.service(HTTPWorker.java:216) at org.apache.axis2.transport.http.server.AxisHttpService.doService(AxisHttpService.java:275) at org.apache.axis2.transport.http.server.AxisHttpService.handleRequest(AxisHttpService.java:184) at org.apache.axis2.transport.http.server.HttpServiceProcessor.run(HttpServiceProcessor.java:74) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:803) - --- // Which leads to the client-side failure: Testcase: testProviderSourceXMLOnly(org.apache.axis2.jaxws.provider.SoapMessageProviderTests): FAILED null junit.framework.AssertionFailedError at org.apache.axis2.jaxws.provider.SoapMessageProviderTests.testProviderSourceXMLOnly(SoapMessageProviderTests.java:121) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) Here's an excerpt of my chat with Dims on about the problem. He had stepped through the code and found what was causing the failure: dims: i stepped thru the code. "Content-Desciption" http header is set and is checked for ... barrettjl1027: Where is the code you were stepping through? I can start looking there. dims: 2 spots are in MessageUtils.java dims: getMessageFromMessageContext dims: and putMessageOnMessageContext dims: there we copy mime headers between transport headers dims: i mean we copy mime headers <-> transport headers dims: but TRANSPORT_HEADERS is not picked up by *HttpSender. there needs to be some code that picks up that and puts them on the http/wire dims: that's problem #1. dims: if you see AbstractHTTPSender.java. we pick up HTTPConstants.HTTP_HEADERS and put them on the wire ... dims: Problem #2 is that the mimeheaders set on the SOAPMessage is not copied over to jaxws.Message in MessageFactoryImpl.createFrom(SOAPMessage message) Note that because this test was not using the JUnit assert methods, although the test had actually not been working (it probably never worked), it wasn't reporting an error. So this is not a testacase regression. > SoapMessageProviderTests.testProviderSourceXMLOnly broken > - > > Key: AXIS2-2550 > URL: https://issues.apache.org/jira/browse/AXIS2-2550 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Davanum Srinivas > > The SoapMessageProvider.java uses jdk's built-in assertions. under m1 these > were disabled and hence we saw a build break only on m2/surefire. now i > checked in an update to jaxws\project.properties (added -enableAssertions to > maven.junit.jvmargs). So you should see the build break in m1 as well. > testProviderSourceXMLOnly(org.apache.axis2.jaxws.provider.SoapMessageProviderTests) > Time elapsed: 0.171 sec <<< FAILURE! > junit.framework.AssertionFailedError:
[jira] Commented: (AXIS2-2525) AnnotationServiceImplDescriptionTests broken
[ https://issues.apache.org/jira/browse/AXIS2-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489406 ] Jeff Barrett commented on AXIS2-2525: - Dims, thanks for the info. I ran the test (and it passed) on the IBM JDK, so it seems the failure is related to a difference in the JVMs. Since the continum build was also failing, I think that was on Solaris, and also a Sun JDK. Also, thanks for commenting out the test until this is resolved. For reference, the test was excluded 4/13 by Dims: dims Temporarily exclude test - logged bug AXIS2-2525 /webservices/axis2/trunk/java/modules/metadata/pom.xml /webservices/axis2/trunk/java/modules/metadata/project.xml > AnnotationServiceImplDescriptionTests broken > > > Key: AXIS2-2525 > URL: https://issues.apache.org/jira/browse/AXIS2-2525 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Davanum Srinivas > > Testsuite: > org.apache.axis2.jaxws.description.AnnotationServiceImplDescriptionTests > Tests run: 3, Failures: 0, Errors: 1, Time elapsed: 0.562 sec > Testcase: > testOverloadedServiceImplWithSEI(org.apache.axis2.jaxws.description.AnnotationServiceImplDescriptionTests): > Caused an ERROR > Validation error: SEI return value java.util.concurrent.Future does not > match implementation method return value > javax.xml.ws.Response; > Implementation class: > org.apache.axis2.jaxws.description.DocLitWrappedImplWithSEI; Method name: > twoWayAsync; Endpoint Interface: > org.apache.axis2.jaxws.description.DocLitWrappedProxy > javax.xml.ws.WebServiceException: Validation error: SEI return value > java.util.concurrent.Future does not match implementation method return > value javax.xml.ws.Response; > Implementation class: > org.apache.axis2.jaxws.description.DocLitWrappedImplWithSEI; Method name: > twoWayAsync; Endpoint Interface: > org.apache.axis2.jaxws.description.DocLitWrappedProxy > at > org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:170) > at > org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:67) > at > org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:115) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateMethodReturnValue(ServiceDescriptionImpl.java:1079) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateImplementation(ServiceDescriptionImpl.java:984) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateIntegrity(ServiceDescriptionImpl.java:781) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateDBCLIntegrity(ServiceDescriptionImpl.java:627) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.(ServiceDescriptionImpl.java:175) > at > org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.createServiceDescriptionFromDBCMap(DescriptionFactoryImpl.java:169) > at > org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.createServiceDescription(DescriptionFactoryImpl.java:138) > at > org.apache.axis2.jaxws.description.DescriptionFactory.createServiceDescription(DescriptionFactory.java:141) > at > org.apache.axis2.jaxws.description.AnnotationServiceImplDescriptionTests.testOverloadedServiceImplWithSEI(AnnotationServiceImplDescriptionTests.java:134) -- 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] Closed: (AXIS2-2542) DescriptionFactoryImpl caching and updates need to be threadsafe
[ https://issues.apache.org/jira/browse/AXIS2-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett closed AXIS2-2542. --- > DescriptionFactoryImpl caching and updates need to be threadsafe > > > Key: AXIS2-2542 > URL: https://issues.apache.org/jira/browse/AXIS2-2542 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett > > The ServiceDescription cache and updating of the enpdoints needs to be > threadsafe. -- 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] Resolved: (AXIS2-2542) DescriptionFactoryImpl caching and updates need to be threadsafe
[ https://issues.apache.org/jira/browse/AXIS2-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2542. - Resolution: Fixed Fix contributed by Dustin Amrhein. Commited revision: 529355 > DescriptionFactoryImpl caching and updates need to be threadsafe > > > Key: AXIS2-2542 > URL: https://issues.apache.org/jira/browse/AXIS2-2542 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett > > The ServiceDescription cache and updating of the enpdoints needs to be > threadsafe. -- 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-2542) DescriptionFactoryImpl caching and updates need to be threadsafe
DescriptionFactoryImpl caching and updates need to be threadsafe Key: AXIS2-2542 URL: https://issues.apache.org/jira/browse/AXIS2-2542 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Jeff Barrett The ServiceDescription cache and updating of the enpdoints needs to be threadsafe. -- 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] Assigned: (AXIS2-2542) DescriptionFactoryImpl caching and updates need to be threadsafe
[ https://issues.apache.org/jira/browse/AXIS2-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett reassigned AXIS2-2542: --- Assignee: Jeff Barrett > DescriptionFactoryImpl caching and updates need to be threadsafe > > > Key: AXIS2-2542 > URL: https://issues.apache.org/jira/browse/AXIS2-2542 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett > > The ServiceDescription cache and updating of the enpdoints needs to be > threadsafe. -- 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] Resolved: (AXIS2-2445) Fix NPE when setting endpoint URL
[ https://issues.apache.org/jira/browse/AXIS2-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2445. - Resolution: Cannot Reproduce The code in WSDL11ToAxisServiceBuilder has been refactored, and I don't think this is a problem anymore. The revision I looked at which contained the refactoring was 529223. > Fix NPE when setting endpoint URL > - > > Key: AXIS2-2445 > URL: https://issues.apache.org/jira/browse/AXIS2-2445 > Project: Axis 2.0 (Axis2) > Issue Type: Bug >Reporter: Roy A. Wood Jr. >Priority: Minor > > The populateEndpoints method tries to set the axisService EndpointURL with > the location on a SoapAddress that may be null...causing an NPE With this > fix, the endpointURL on AxisService will be unset. -- 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-2536) Support client side WSDL files within JARs on UNIX/LINUX platforms
Support client side WSDL files within JARs on UNIX/LINUX platforms -- Key: AXIS2-2536 URL: https://issues.apache.org/jira/browse/AXIS2-2536 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Jeff Barrett Priority: Minor On *IX, the path is getting two leading "/", causing it to treat the file as remote. Dustin Amrhein found the problem and has contributed a fix which I will apply shortly. -- 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] Assigned: (AXIS2-2536) Support client side WSDL files within JARs on UNIX/LINUX platforms
[ https://issues.apache.org/jira/browse/AXIS2-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett reassigned AXIS2-2536: --- Assignee: Jeff Barrett > Support client side WSDL files within JARs on UNIX/LINUX platforms > -- > > Key: AXIS2-2536 > URL: https://issues.apache.org/jira/browse/AXIS2-2536 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett >Priority: Minor > > On *IX, the path is getting two leading "/", causing it to treat the file as > remote. Dustin Amrhein found the problem and has contributed a fix which I > will apply shortly. -- 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] Closed: (AXIS2-2536) Support client side WSDL files within JARs on UNIX/LINUX platforms
[ https://issues.apache.org/jira/browse/AXIS2-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett closed AXIS2-2536. --- > Support client side WSDL files within JARs on UNIX/LINUX platforms > -- > > Key: AXIS2-2536 > URL: https://issues.apache.org/jira/browse/AXIS2-2536 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett >Priority: Minor > > On *IX, the path is getting two leading "/", causing it to treat the file as > remote. Dustin Amrhein found the problem and has contributed a fix which I > will apply shortly. -- 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] Resolved: (AXIS2-2536) Support client side WSDL files within JARs on UNIX/LINUX platforms
[ https://issues.apache.org/jira/browse/AXIS2-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2536. - Resolution: Fixed Fix contributed by Dustin Amrhein. Committed revision 529310. > Support client side WSDL files within JARs on UNIX/LINUX platforms > -- > > Key: AXIS2-2536 > URL: https://issues.apache.org/jira/browse/AXIS2-2536 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett >Priority: Minor > > On *IX, the path is getting two leading "/", causing it to treat the file as > remote. Dustin Amrhein found the problem and has contributed a fix which I > will apply shortly. -- 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-2525) AnnotationServiceImplDescriptionTests broken
[ https://issues.apache.org/jira/browse/AXIS2-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488779 ] Jeff Barrett commented on AXIS2-2525: - I just did a checkout of 528651, and this test runs successfully on Windows. Are you seeing this error on Windows? Or on some other platform? > AnnotationServiceImplDescriptionTests broken > > > Key: AXIS2-2525 > URL: https://issues.apache.org/jira/browse/AXIS2-2525 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Davanum Srinivas > > Testsuite: > org.apache.axis2.jaxws.description.AnnotationServiceImplDescriptionTests > Tests run: 3, Failures: 0, Errors: 1, Time elapsed: 0.562 sec > Testcase: > testOverloadedServiceImplWithSEI(org.apache.axis2.jaxws.description.AnnotationServiceImplDescriptionTests): > Caused an ERROR > Validation error: SEI return value java.util.concurrent.Future does not > match implementation method return value > javax.xml.ws.Response; > Implementation class: > org.apache.axis2.jaxws.description.DocLitWrappedImplWithSEI; Method name: > twoWayAsync; Endpoint Interface: > org.apache.axis2.jaxws.description.DocLitWrappedProxy > javax.xml.ws.WebServiceException: Validation error: SEI return value > java.util.concurrent.Future does not match implementation method return > value javax.xml.ws.Response; > Implementation class: > org.apache.axis2.jaxws.description.DocLitWrappedImplWithSEI; Method name: > twoWayAsync; Endpoint Interface: > org.apache.axis2.jaxws.description.DocLitWrappedProxy > at > org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:170) > at > org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:67) > at > org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:115) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateMethodReturnValue(ServiceDescriptionImpl.java:1079) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateImplementation(ServiceDescriptionImpl.java:984) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateIntegrity(ServiceDescriptionImpl.java:781) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateDBCLIntegrity(ServiceDescriptionImpl.java:627) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.(ServiceDescriptionImpl.java:175) > at > org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.createServiceDescriptionFromDBCMap(DescriptionFactoryImpl.java:169) > at > org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.createServiceDescription(DescriptionFactoryImpl.java:138) > at > org.apache.axis2.jaxws.description.DescriptionFactory.createServiceDescription(DescriptionFactory.java:141) > at > org.apache.axis2.jaxws.description.AnnotationServiceImplDescriptionTests.testOverloadedServiceImplWithSEI(AnnotationServiceImplDescriptionTests.java:134) -- 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] Closed: (AXIS2-2522) WSDL not available for SOAP 1.2 endpoints
[ https://issues.apache.org/jira/browse/AXIS2-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett closed AXIS2-2522. --- > WSDL not available for SOAP 1.2 endpoints > - > > Key: AXIS2-2522 > URL: https://issues.apache.org/jira/browse/AXIS2-2522 > Project: Axis 2.0 (Axis2) > Issue Type: Bug >Reporter: Jeff Barrett > Assigned To: Jeff Barrett >Priority: Minor > > The metadata layer is not attaching the WSDL definition to AxisService > objects if the WSDL is SOAP 1.2. We should still > attach the WSDL definition if the WSDL is SOAP 1.2 and was deployed with the > application. We are correctly not generating > WSDL for SOAP 1.2 endpoints. -- 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] Resolved: (AXIS2-2522) WSDL not available for SOAP 1.2 endpoints
[ https://issues.apache.org/jira/browse/AXIS2-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2522. - Resolution: Fixed Fix contributed by Dustin Amrhein. Commited revision 528225. > WSDL not available for SOAP 1.2 endpoints > - > > Key: AXIS2-2522 > URL: https://issues.apache.org/jira/browse/AXIS2-2522 > Project: Axis 2.0 (Axis2) > Issue Type: Bug >Reporter: Jeff Barrett > Assigned To: Jeff Barrett >Priority: Minor > > The metadata layer is not attaching the WSDL definition to AxisService > objects if the WSDL is SOAP 1.2. We should still > attach the WSDL definition if the WSDL is SOAP 1.2 and was deployed with the > application. We are correctly not generating > WSDL for SOAP 1.2 endpoints. -- 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] Assigned: (AXIS2-2522) WSDL not available for SOAP 1.2 endpoints
[ https://issues.apache.org/jira/browse/AXIS2-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett reassigned AXIS2-2522: --- Assignee: Jeff Barrett > WSDL not available for SOAP 1.2 endpoints > - > > Key: AXIS2-2522 > URL: https://issues.apache.org/jira/browse/AXIS2-2522 > Project: Axis 2.0 (Axis2) > Issue Type: Bug >Reporter: Jeff Barrett > Assigned To: Jeff Barrett >Priority: Minor > > The metadata layer is not attaching the WSDL definition to AxisService > objects if the WSDL is SOAP 1.2. We should still > attach the WSDL definition if the WSDL is SOAP 1.2 and was deployed with the > application. We are correctly not generating > WSDL for SOAP 1.2 endpoints. -- 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-2522) WSDL not available for SOAP 1.2 endpoints
WSDL not available for SOAP 1.2 endpoints - Key: AXIS2-2522 URL: https://issues.apache.org/jira/browse/AXIS2-2522 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Jeff Barrett Priority: Minor The metadata layer is not attaching the WSDL definition to AxisService objects if the WSDL is SOAP 1.2. We should still attach the WSDL definition if the WSDL is SOAP 1.2 and was deployed with the application. We are correctly not generating WSDL for SOAP 1.2 endpoints. -- 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] Closed: (AXIS2-2517) Validation of checked exceptions between SEI and service impl is incorrect
[ https://issues.apache.org/jira/browse/AXIS2-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett closed AXIS2-2517. --- > Validation of checked exceptions between SEI and service impl is incorrect > -- > > Key: AXIS2-2517 > URL: https://issues.apache.org/jira/browse/AXIS2-2517 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett >Priority: Minor > > A service implementation method may throw fewer checked exceptions than the > SEI, but may not throw more. The current validation code is incorrect in how > it validates the checked exceptions. -- 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] Resolved: (AXIS2-2517) Validation of checked exceptions between SEI and service impl is incorrect
[ https://issues.apache.org/jira/browse/AXIS2-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2517. - Resolution: Fixed Fixed. Commited revision 528066. > Validation of checked exceptions between SEI and service impl is incorrect > -- > > Key: AXIS2-2517 > URL: https://issues.apache.org/jira/browse/AXIS2-2517 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett >Priority: Minor > > A service implementation method may throw fewer checked exceptions than the > SEI, but may not throw more. The current validation code is incorrect in how > it validates the checked exceptions. -- 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] Assigned: (AXIS2-2517) Validation of checked exceptions between SEI and service impl is incorrect
[ https://issues.apache.org/jira/browse/AXIS2-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett reassigned AXIS2-2517: --- Assignee: Jeff Barrett > Validation of checked exceptions between SEI and service impl is incorrect > -- > > Key: AXIS2-2517 > URL: https://issues.apache.org/jira/browse/AXIS2-2517 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett >Priority: Minor > > A service implementation method may throw fewer checked exceptions than the > SEI, but may not throw more. The current validation code is incorrect in how > it validates the checked exceptions. -- 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-2517) Validation of checked exceptions between SEI and service impl is incorrect
Validation of checked exceptions between SEI and service impl is incorrect -- Key: AXIS2-2517 URL: https://issues.apache.org/jira/browse/AXIS2-2517 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Jeff Barrett Priority: Minor A service implementation method may throw fewer checked exceptions than the SEI, but may not throw more. The current validation code is incorrect in how it validates the checked exceptions. -- 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] Resolved: (AXIS2-2422) Enable policy to be set on correct Operation Description
[ https://issues.apache.org/jira/browse/AXIS2-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2422. - Resolution: Fixed Assignee: Jeff Barrett (was: Sanka Samaranayake) Fix contributed by Roy Wood, Jr. The OpDescs for the JAXWS client-side async methods should use the AxisOperation of the associated sync operation. This will cause the JAXWS runtime to use the sync operation's AxisOperation rather than creating a new anonymous one. Commited revision 528044. > Enable policy to be set on correct Operation Description > > > Key: AXIS2-2422 > URL: https://issues.apache.org/jira/browse/AXIS2-2422 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Roy A. Wood Jr. > Assigned To: Jeff Barrett > > Currently, there is a problem where setting policy only works because it is > being set by using the anonymous ops. This > happens because the wrong method is being on the Operation Description. This > will fix that problem. -- 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] Closed: (AXIS2-2515) MDQ should validate that server-side SEIs/Impls do not contain async methods
[ https://issues.apache.org/jira/browse/AXIS2-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett closed AXIS2-2515. --- > MDQ should validate that server-side SEIs/Impls do not contain async methods > > > Key: AXIS2-2515 > URL: https://issues.apache.org/jira/browse/AXIS2-2515 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett > > MDQ should validate that server-side SEIs/Impls do not contain JAX-WS > client-side async methods. > -- 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] Resolved: (AXIS2-2515) MDQ should validate that server-side SEIs/Impls do not contain async methods
[ https://issues.apache.org/jira/browse/AXIS2-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2515. - Resolution: Fixed Fix contributed by Dustin Amrhein. Commited revision 527988. > MDQ should validate that server-side SEIs/Impls do not contain async methods > > > Key: AXIS2-2515 > URL: https://issues.apache.org/jira/browse/AXIS2-2515 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett > > MDQ should validate that server-side SEIs/Impls do not contain JAX-WS > client-side async methods. > -- 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] Assigned: (AXIS2-2515) MDQ should validate that server-side SEIs/Impls do not contain async methods
[ https://issues.apache.org/jira/browse/AXIS2-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett reassigned AXIS2-2515: --- Assignee: Jeff Barrett > MDQ should validate that server-side SEIs/Impls do not contain async methods > > > Key: AXIS2-2515 > URL: https://issues.apache.org/jira/browse/AXIS2-2515 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett > > MDQ should validate that server-side SEIs/Impls do not contain JAX-WS > client-side async methods. > -- 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-2515) MDQ should validate that server-side SEIs/Impls do not contain async methods
MDQ should validate that server-side SEIs/Impls do not contain async methods Key: AXIS2-2515 URL: https://issues.apache.org/jira/browse/AXIS2-2515 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Jeff Barrett MDQ should validate that server-side SEIs/Impls do not contain JAX-WS client-side async methods. -- 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] Resolved: (AXIS2-2308) Misc fixes: client-side validation, disallow wsdl generation for SOAP1.2, check SEI exceptions
[ https://issues.apache.org/jira/browse/AXIS2-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2308. - Resolution: Fixed Fix contributed by Roy Wood Jr. Commited revision 527652 > Misc fixes: client-side validation, disallow wsdl generation for SOAP1.2, > check SEI exceptions > -- > > Key: AXIS2-2308 > URL: https://issues.apache.org/jira/browse/AXIS2-2308 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Roy A. Wood Jr. > > This is a culmination of 3 fixes: > 1. Enable limited client side validation > 2. Disallow generation of wsdl for SOAP1.2 > 3. Check that exceptions on SEI have the same signature on impl -- 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] Closed: (AXIS2-2503) Stack overflow parsing circular WSDL in Jaxws
[ https://issues.apache.org/jira/browse/AXIS2-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett closed AXIS2-2503. --- > Stack overflow parsing circular WSDL in Jaxws > - > > Key: AXIS2-2503 > URL: https://issues.apache.org/jira/browse/AXIS2-2503 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett > > JAXWS gets a stack overflow parsing circular WSDL. -- 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] Closed: (AXIS2-2506) URIResolver should set InputSource id to resolved import location
[ https://issues.apache.org/jira/browse/AXIS2-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett closed AXIS2-2506. --- > URIResolver should set InputSource id to resolved import location > - > > Key: AXIS2-2506 > URL: https://issues.apache.org/jira/browse/AXIS2-2506 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett >Priority: Minor > > Addition fix related to AXIS2-2503. The URI resolver needs to set the > systemId to the resolved import location. -- 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] Resolved: (AXIS2-2506) URIResolver should set InputSource id to resolved import location
[ https://issues.apache.org/jira/browse/AXIS2-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2506. - Resolution: Fixed Fix contributed by Dustin Amrhein. Commited revision 527531 > URIResolver should set InputSource id to resolved import location > - > > Key: AXIS2-2506 > URL: https://issues.apache.org/jira/browse/AXIS2-2506 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett >Priority: Minor > > Addition fix related to AXIS2-2503. The URI resolver needs to set the > systemId to the resolved import location. -- 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-2503) Stack overflow parsing circular WSDL in Jaxws
[ https://issues.apache.org/jira/browse/AXIS2-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488104 ] Jeff Barrett commented on AXIS2-2503: - See https://issues.apache.org/jira/browse/AXIS2-2506 for an additional aspect of this fix. > Stack overflow parsing circular WSDL in Jaxws > - > > Key: AXIS2-2503 > URL: https://issues.apache.org/jira/browse/AXIS2-2503 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett > > JAXWS gets a stack overflow parsing circular WSDL. -- 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-2506) URIResolver should set InputSource id to resolved import location
URIResolver should set InputSource id to resolved import location - Key: AXIS2-2506 URL: https://issues.apache.org/jira/browse/AXIS2-2506 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Jeff Barrett Priority: Minor Addition fix related to AXIS2-2503. The URI resolver needs to set the systemId to the resolved import location. -- 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] Resolved: (AXIS2-2503) Stack overflow parsing circular WSDL in Jaxws
[ https://issues.apache.org/jira/browse/AXIS2-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2503. - Resolution: Fixed Commited revision 527301. There is an additional aspect to this fix that will be contributed by Dustin Amrhein in another Jira which will be opened shortly. > Stack overflow parsing circular WSDL in Jaxws > - > > Key: AXIS2-2503 > URL: https://issues.apache.org/jira/browse/AXIS2-2503 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett > > JAXWS gets a stack overflow parsing circular WSDL. -- 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] Assigned: (AXIS2-2503) Stack overflow parsing circular WSDL in Jaxws
[ https://issues.apache.org/jira/browse/AXIS2-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett reassigned AXIS2-2503: --- Assignee: Jeff Barrett > Stack overflow parsing circular WSDL in Jaxws > - > > Key: AXIS2-2503 > URL: https://issues.apache.org/jira/browse/AXIS2-2503 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett > > JAXWS gets a stack overflow parsing circular WSDL. -- 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-2503) Stack overflow parsing circular WSDL in Jaxws
Stack overflow parsing circular WSDL in Jaxws - Key: AXIS2-2503 URL: https://issues.apache.org/jira/browse/AXIS2-2503 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Jeff Barrett JAXWS gets a stack overflow parsing circular WSDL. -- 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] Closed: (AXIS2-2500) Metadata layer should construct element name to AxisOperation mapping differently
[ https://issues.apache.org/jira/browse/AXIS2-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett closed AXIS2-2500. --- > Metadata layer should construct element name to AxisOperation mapping > differently > - > > Key: AXIS2-2500 > URL: https://issues.apache.org/jira/browse/AXIS2-2500 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett > > The metadata layer should use the @WebParam.name and > @WebParam.targetNamespace when constructing the QName for an element > to AxisOperation mapping. -- 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] Resolved: (AXIS2-2500) Metadata layer should construct element name to AxisOperation mapping differently
[ https://issues.apache.org/jira/browse/AXIS2-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2500. - Resolution: Fixed Fix contributed by Dustin Amrhein. Commited revision 527251 > Metadata layer should construct element name to AxisOperation mapping > differently > - > > Key: AXIS2-2500 > URL: https://issues.apache.org/jira/browse/AXIS2-2500 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett > > The metadata layer should use the @WebParam.name and > @WebParam.targetNamespace when constructing the QName for an element > to AxisOperation mapping. -- 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] Assigned: (AXIS2-2500) Metadata layer should construct element name to AxisOperation mapping differently
[ https://issues.apache.org/jira/browse/AXIS2-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett reassigned AXIS2-2500: --- Assignee: Jeff Barrett > Metadata layer should construct element name to AxisOperation mapping > differently > - > > Key: AXIS2-2500 > URL: https://issues.apache.org/jira/browse/AXIS2-2500 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett > > The metadata layer should use the @WebParam.name and > @WebParam.targetNamespace when constructing the QName for an element > to AxisOperation mapping. -- 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-2500) Metadata layer should construct element name to AxisOperation mapping differently
Metadata layer should construct element name to AxisOperation mapping differently - Key: AXIS2-2500 URL: https://issues.apache.org/jira/browse/AXIS2-2500 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Jeff Barrett The metadata layer should use the @WebParam.name and @WebParam.targetNamespace when constructing the QName for an element to AxisOperation mapping. -- 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] Closed: (AXIS2-2499) The WSDL4JWrapper constructor should throw an IOException
[ https://issues.apache.org/jira/browse/AXIS2-2499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett closed AXIS2-2499. --- > The WSDL4JWrapper constructor should throw an IOException > - > > Key: AXIS2-2499 > URL: https://issues.apache.org/jira/browse/AXIS2-2499 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett >Priority: Minor > > In the case that we could not open a stream to a WSDL URL the WSDL4JWrapper > should throw an IOException instead of the > standard WSDL exception. -- 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] Resolved: (AXIS2-2499) The WSDL4JWrapper constructor should throw an IOException
[ https://issues.apache.org/jira/browse/AXIS2-2499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2499. - Resolution: Fixed Fix contributed by Dustin Amrhein. Commited revison 527240. > The WSDL4JWrapper constructor should throw an IOException > - > > Key: AXIS2-2499 > URL: https://issues.apache.org/jira/browse/AXIS2-2499 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett >Priority: Minor > > In the case that we could not open a stream to a WSDL URL the WSDL4JWrapper > should throw an IOException instead of the > standard WSDL exception. -- 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] Assigned: (AXIS2-2499) The WSDL4JWrapper constructor should throw an IOException
[ https://issues.apache.org/jira/browse/AXIS2-2499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett reassigned AXIS2-2499: --- Assignee: Jeff Barrett > The WSDL4JWrapper constructor should throw an IOException > - > > Key: AXIS2-2499 > URL: https://issues.apache.org/jira/browse/AXIS2-2499 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett >Priority: Minor > > In the case that we could not open a stream to a WSDL URL the WSDL4JWrapper > should throw an IOException instead of the > standard WSDL exception. -- 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-2499) The WSDL4JWrapper constructor should throw an IOException
The WSDL4JWrapper constructor should throw an IOException - Key: AXIS2-2499 URL: https://issues.apache.org/jira/browse/AXIS2-2499 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Jeff Barrett Priority: Minor In the case that we could not open a stream to a WSDL URL the WSDL4JWrapper should throw an IOException instead of the standard WSDL exception. -- 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] Resolved: (AXIS2-2353) Selecting a port name / wsdl provided scenario
[ https://issues.apache.org/jira/browse/AXIS2-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett resolved AXIS2-2353. - Resolution: Fixed I think the problem is in the mismatch between the SEI and the WSDL per my comment above. If that's not the problem, please reopen this issue. > Selecting a port name / wsdl provided scenario > -- > > Key: AXIS2-2353 > URL: https://issues.apache.org/jira/browse/AXIS2-2353 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Davanum Srinivas > Assigned To: Jeff Barrett > Attachments: Calculator.java, CalculatorClient.java, > CalculatorService.java, CalculatorService.wsdl > > > Port Name confusion. > EndpointDesciptionImpl#selectWSDLPortToUse (Line 1396) says: > // Per JSR-181, > // - The portType name corresponds to the WebService.name annotation > value, which is > // returned by getName() > // - The portType namespace corresponds to the > WebService.targetNamespace annotation, which > // is returned by getTargetNamespace() > String portTypeLP = getName(); > BUT, EndpointDesciptionImpl#getAnnoWebServicePortName does this: > // This is the @WebService annotation path > // Default value is the @WebService.name of the class or > interface + "Port" > // Per JSR-181 MR Sec 4.1, pg 15 > annotation_PortName = getAnnoWebServiceName() + "Port"; > So which is correct? > Here's the scenario we are trying: > http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html > We will upload the latest versions of wsdl/service/client as well. > -- dims -- 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-2353) Selecting a port name / wsdl provided scenario
[
https://issues.apache.org/jira/browse/AXIS2-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486393
]
Jeff Barrett commented on AXIS2-2353:
-
Hi Lin,
That attached SEI and WSDL still don't match each other.
Given the SEI annotation:
@WebService(name="Calculator", portName="CalculatorPortType", targetNamespace =
"http://jws.samples.geronimo.apache.org";)
public interface Calculator {
The annotation attribute "name" which indicates the WSDL PortType has a
value of "Calculator".
Give th WSDL definition:
The only PortType in the WSDL is named "CalculatorPortType".
You need to change EITHER the SEI annotation OR the WSDL. It is probably
easier to change the SEI annotation, so here's what the new SEI annotation
would probably look like. Notice I changed the attribute values for name
and portName:
@WebService(name="CalculatorPortType", portName="CalculatorPort",
targetNamespace = "http://jws.samples.geronimo.apache.org";)
public interface Calculator {
I hope that helps.
> Selecting a port name / wsdl provided scenario
> --
>
> Key: AXIS2-2353
> URL: https://issues.apache.org/jira/browse/AXIS2-2353
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: jaxws
>Reporter: Davanum Srinivas
> Assigned To: Jeff Barrett
> Attachments: Calculator.java, CalculatorClient.java,
> CalculatorService.java, CalculatorService.wsdl
>
>
> Port Name confusion.
> EndpointDesciptionImpl#selectWSDLPortToUse (Line 1396) says:
> // Per JSR-181,
> // - The portType name corresponds to the WebService.name annotation
> value, which is
> // returned by getName()
> // - The portType namespace corresponds to the
> WebService.targetNamespace annotation, which
> // is returned by getTargetNamespace()
> String portTypeLP = getName();
> BUT, EndpointDesciptionImpl#getAnnoWebServicePortName does this:
> // This is the @WebService annotation path
> // Default value is the @WebService.name of the class or
> interface + "Port"
> // Per JSR-181 MR Sec 4.1, pg 15
> annotation_PortName = getAnnoWebServiceName() + "Port";
> So which is correct?
> Here's the scenario we are trying:
> http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html
> We will upload the latest versions of wsdl/service/client as well.
> -- dims
--
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-2353) Selecting a port name / wsdl provided scenario
[
https://issues.apache.org/jira/browse/AXIS2-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485295
]
Jeff Barrett commented on AXIS2-2353:
-
Hi All,
I've looked at the WSDL and the client java attached to this Jira and at
the SEI from the link above
http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html
It looks to me like the WSDL and the annotations on the SEI don't match
up, and that is why no ports are being found. In other words, I think
this is a problem with the Calculator WSDL and/or SEI class. (I'm not
sure why Lin's change made a difference, but I didn't explore that
thouroughly since I don't believe it is a correct change.)
Specifically, the WSDL indicates that the portType is
"CalculatorPortType", however the SEI (via JSR-181 annotation defaulting)
indicates the portType is "Calculator". So, when we use the annotation
value of "Calculator" for the portType to find a port in the WSDL, none is
found since the port in the WSDL specifies a portType of
"CalculatorPortType".
WSDL SNIPPET
Excerpt from the attached WSDL file. The (only) port in the WSDL
references a wsdl:portType of "CalculatorPortType"
(1) The WSDL Port Type
(2) Referenced from this binding
http://schemas.xmlsoap.org/soap/http"/>
(3) Which is referenced from this port
http://localhost:8080/jaxws-calculator-1.0/calculator"/>
http://www.w3.org/2005/08/addressing/wsdl"/>
SEI SNIPPET
===
Excerpt from Calculator.java from
http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html
@WebService
public interface Calculator {
@WebMethod
public int add(@WebParam(name = "value1") int value1,
@WebParam(name = "value2") int value2);
}
(1) Notice that the @WebService annotation has no attributes specified, so
the values will be defaulted. So, for portType which maps to
WebService.name, the default value will be "Calculator". This is per
JSR-181 section 4.1 "Annotation: javax.jws.WebService" section 4.1.1:
- "name" Used as the name of the wsdl:portType. Default value is "Simple
name of the Java class or interface".
TESTCASE THAT VALIDATES DEFAULT PORT SELECTION
==
there is a test for the default port selection in the JAXWS test bucket:
/axis2-apache/modules/jaxws/test/org/apache/axis2/jaxws/description/PortSelectionTests.java
> Selecting a port name / wsdl provided scenario
> --
>
> Key: AXIS2-2353
> URL: https://issues.apache.org/jira/browse/AXIS2-2353
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: jaxws
>Reporter: Davanum Srinivas
> Assigned To: Jeff Barrett
> Attachments: CalculatorClient.java, CalculatorService.java,
> CalculatorService.wsdl
>
>
> Port Name confusion.
> EndpointDesciptionImpl#selectWSDLPortToUse (Line 1396) says:
> // Per JSR-181,
> // - The portType name corresponds to the WebService.name annotation
> value, which is
> // returned by getName()
> // - The portType namespace corresponds to the
> WebService.targetNamespace annotation, which
> // is returned by getTargetNamespace()
> String portTypeLP = getName();
> BUT, EndpointDesciptionImpl#getAnnoWebServicePortName does this:
> // This is the @WebService annotation path
> // Default value is the @WebService.name of the class or
> interface + "Port"
> // Per JSR-181 MR Sec 4.1, pg 15
> annotation_PortName = getAnnoWebServiceName() + "Port";
> So which is correct?
> Here's the scenario we are trying:
> http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html
> We will upload the latest versions of wsdl/service/client as well.
> -- dims
--
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-2353) Selecting a port name / wsdl provided scenario
[ https://issues.apache.org/jira/browse/AXIS2-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485258 ] Jeff Barrett commented on AXIS2-2353: - Regarding Dim's question above... EndpointDesciptionImpl#selectWSDLPortToUse (Line 1396) says: // Per JSR-181, // - The portType name corresponds to the WebService.name annotation value, which is // returned by getName() // - The portType namespace corresponds to the WebService.targetNamespace annotation, which // is returned by getTargetNamespace() String portTypeLP = getName(); BUT, EndpointDesciptionImpl#getAnnoWebServicePortName does this: // This is the @WebService annotation path // Default value is the @WebService.name of the class or interface + "Port" // Per JSR-181 MR Sec 4.1, pg 15 annotation_PortName = getAnnoWebServiceName() + "Port"; So which is correct? Maybe I'm not understanding the issue yet, but they are both correct because they are doing different things. The first snippet is working with wsdl:portType and the second with wsdl:port. >From JSR-181 section 4.1 "Annotation: javax.jws.WebService" section 4.1.1 says >that WebService attributes: - "name" maps to "wsdl:portType" - "portName" maps to "wsdl:port" Give that, the methods on EnpointDescription (and yes, I'll update the javadocs!) do the following - getName() essentially returns WebService.name and thus "wsdl:portType". This is via delegation to getAnnoWebServiceName() - getPortQName() essentially returns WebService.portName and thus "wsdl:port" (not portType). This is via delegation to getAnnoWebServicePortName() along with some tns processing to return a QName. The code snippet from selectWSDLPortsToUse intends to gets the portType, then finds all the ports that use that portType, and then get the first one of those that has a SOAP address. Regarding Lin's comment above ... I tried to replace String portTypeLP = getName(); with String portTypeLP = getAnnoWebServicePortName(); and was able to pass this. I don't think that was a valid change (give the above explanation). I'll look at the attached WSDL and Java and see why that change was necessary to locate a port in the WSDL. More information soon ... > Selecting a port name / wsdl provided scenario > -- > > Key: AXIS2-2353 > URL: https://issues.apache.org/jira/browse/AXIS2-2353 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Davanum Srinivas > Assigned To: Jeff Barrett > Attachments: CalculatorClient.java, CalculatorService.java, > CalculatorService.wsdl > > > Port Name confusion. > EndpointDesciptionImpl#selectWSDLPortToUse (Line 1396) says: > // Per JSR-181, > // - The portType name corresponds to the WebService.name annotation > value, which is > // returned by getName() > // - The portType namespace corresponds to the > WebService.targetNamespace annotation, which > // is returned by getTargetNamespace() > String portTypeLP = getName(); > BUT, EndpointDesciptionImpl#getAnnoWebServicePortName does this: > // This is the @WebService annotation path > // Default value is the @WebService.name of the class or > interface + "Port" > // Per JSR-181 MR Sec 4.1, pg 15 > annotation_PortName = getAnnoWebServiceName() + "Port"; > So which is correct? > Here's the scenario we are trying: > http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html > We will upload the latest versions of wsdl/service/client as well. > -- dims -- 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-2353) Selecting a port name / wsdl provided scenario
[ https://issues.apache.org/jira/browse/AXIS2-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485194 ] Jeff Barrett commented on AXIS2-2353: - Looking into this now..., > Selecting a port name / wsdl provided scenario > -- > > Key: AXIS2-2353 > URL: https://issues.apache.org/jira/browse/AXIS2-2353 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Davanum Srinivas > Assigned To: Jeff Barrett > Attachments: CalculatorClient.java, CalculatorService.java, > CalculatorService.wsdl > > > Port Name confusion. > EndpointDesciptionImpl#selectWSDLPortToUse (Line 1396) says: > // Per JSR-181, > // - The portType name corresponds to the WebService.name annotation > value, which is > // returned by getName() > // - The portType namespace corresponds to the > WebService.targetNamespace annotation, which > // is returned by getTargetNamespace() > String portTypeLP = getName(); > BUT, EndpointDesciptionImpl#getAnnoWebServicePortName does this: > // This is the @WebService annotation path > // Default value is the @WebService.name of the class or > interface + "Port" > // Per JSR-181 MR Sec 4.1, pg 15 > annotation_PortName = getAnnoWebServiceName() + "Port"; > So which is correct? > Here's the scenario we are trying: > http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html > We will upload the latest versions of wsdl/service/client as well. > -- dims -- 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] Closed: (AXIS2-2286) Annotation-based support in metadata layer Doc/Lit/Bare body-based routing
[ https://issues.apache.org/jira/browse/AXIS2-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Barrett closed AXIS2-2286. --- > Annotation-based support in metadata layer Doc/Lit/Bare body-based routing > -- > > Key: AXIS2-2286 > URL: https://issues.apache.org/jira/browse/AXIS2-2286 > Project: Axis 2.0 (Axis2) > Issue Type: New Feature > Components: jaxws >Reporter: Jeff Barrett > Assigned To: Jeff Barrett > > For Doc/Lit/Bare routing of an incoming message to an operation, the input > AxisMessage element QName must be set to the part name and then the operation > needs to be added to the AxisService MessageElementQNameToOperationMapping. > This is not being done by the metadata layer for AxisOperations it created > based on annotations. -- 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]
