Re: [Axis2] jibx module changes to 1.3 branch
Please go ahead . Thanks Deepal Dennis Sosnoski wrote: > I'd like to merge this change on trunk into the 1.3 branch: > http://svn.apache.org/viewvc?view=rev&rev=559788 Anyone object? > > Thanks, > > - Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-2994) Problem when trying to move service from axis 1.4 to axis 2 1.3RC2
[ https://issues.apache.org/jira/browse/AXIS2-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515963 ] Amila Chinthaka Suriarachchi commented on AXIS2-2994: - can you attach your stub and skelton as well? > Problem when trying to move service from axis 1.4 to axis 2 1.3RC2 > -- > > Key: AXIS2-2994 > URL: https://issues.apache.org/jira/browse/AXIS2-2994 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: databinding >Affects Versions: 1.3 > Environment: XP Professional, Tomcat App server 5.5 >Reporter: Steve Kruse >Assignee: Amila Chinthaka Suriarachchi >Priority: Blocker > Fix For: 1.3 > > Attachments: TrackLiteDataHandlerWSServiceMessageReceiverInOut.java, > wsdl_schema.zip > > > I use a wsdl file which works in 1.4 and run it thru wsdl2java in axis2 > 1.3rc2 and everything builds properly. The service deploys fine and then > when I try to use the service I get the following stack trace from the soap > monitor: > > http://schemas.xmlsoap.org/soap/envelope/";> > > > soapenv:Client > org.apache.xmlbeans.impl.values.XmlComplexContentImpl > cannot be cast to > peoiws5.mdiapps.soap.HandleTrackInfoLiteEventDocument > > > org.apache.axis2.AxisFault: > org.apache.xmlbeans.impl.values.XmlComplexContentImpl cannot be cast to > peoiws5.mdiapps.soap.HandleTrackInfoLiteEventDocument > at org.apache.axis2.AxisFault.makeFault(AxisFault.java:417) > at > com.am.service.xmlbeans.TrackLiteDataHandlerWSServiceMessageReceiverInOut.fromOM(TrackLiteDataHandlerWSServiceMessageReceiverInOut.java:322) > at > com.am.service.xmlbeans.TrackLiteDataHandlerWSServiceMessageReceiverInOut.invokeBusinessLogic(TrackLiteDataHandlerWSServiceMessageReceiverInOut.java:42) > at > org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:42) > at > org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:95) > at > org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:145) > at > org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:276) > at > org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:119) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870) > at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) > at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) > at > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) > at java.lang.Thread.run(Thread.java:619) > Caused by: java.lang.ClassCastException: > org.apache.xmlbeans.impl.values.XmlComplexContentImpl cannot be cast to > peoiws5.mdiapps.soap.HandleTrackInfoLiteEventDocument > at > peoiws5.mdiapps.soap.HandleTrackInfoLiteEventDocument$Factory.parse(HandleTrackInfoLiteEventDocument.java:128) > at > com.am.service.xmlbeans.TrackLiteDataHandlerWSServiceMessageReceiverInOut.fromOM(TrackLiteDataHandlerWSServiceMessageReceiverInOut.java:220) > ... 22 more > > > > > > The wsdl I am using is below: > > xmlns:apachesoap="http://xml.apache.org/xml-soap"; > xmlns:impl="urn:soap.mdiapps.peoiws5" > xmlns:cvg="urn:data.soap.mdiapps.peoiws5" > xmlns:ce="urn:exception.soap.mdiapps.peoiws5" > xmlns:wsdl="http://schemas.xmlsoap.org/
[jira] Resolved: (AXIS2-3027) Improve Axis idea plugin wizard
[ https://issues.apache.org/jira/browse/AXIS2-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Sandakith resolved AXIS2-3027. - Resolution: Fixed Patch applied in Committed revision 560111 Thanks Shivantha. > Improve Axis idea plugin wizard > > > Key: AXIS2-3027 > URL: https://issues.apache.org/jira/browse/AXIS2-3027 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: Tools >Affects Versions: nightly > Environment: Axis2 idea plugin has some java class without apache > licensed. >Reporter: Shivantha Huruggamuwa >Priority: Minor > Fix For: nightly > > Attachments: Axis2_Idea_Plugin_Patch_AddLicensed.txt > > > Axis2 idea plugin has some java class without apache licensed. so this patch > is adding license to class which has without apache license. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-2898) Probelm of SOAP with JMS transport in axis2
[
https://issues.apache.org/jira/browse/AXIS2-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davanum Srinivas updated AXIS2-2898:
Priority: Blocker (was: Major)
Deepal,
Is this a blocker?
thanks,
dims
> Probelm of SOAP with JMS transport in axis2
> ---
>
> Key: AXIS2-2898
> URL: https://issues.apache.org/jira/browse/AXIS2-2898
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: adb
>Affects Versions: 1.2
> Environment: Deploy axis2 in tomcat6.
> Use JMS of AcitiveMQ 4.1.0.
>Reporter: lizhao chen
>Assignee: Asankha C. Perera
>Priority: Blocker
> Attachments: jms_example.zip
>
>
> I am trying to test a webservice with JMS transport. The service works
> perfectly fine with HTTP but with JMS it gives the following exception during
> unmarshling. Looks like localName is incorrect.
> 2007-07-04 10:11:08,213 DEBUG org.apache.axiom.om.impl.builder.StAXOMBuilder
> - S
> TART_ELEMENT: {tmf854.v1}TopicExpression_T:TopicExpression_T
> 2007-07-04 10:11:08,213 DEBUG
> org.apache.axiom.soap.impl.builder.StAXSOAPModelBu
> ilder - Build the OMElelment TopicExpression_TBy the StaxSOAPModelBuilder
> 2007-07-04 10:11:08,253 ERROR
> org.apache.axis2.transport.jms.JMSMessageReceiver
> - JMS Worker [JMSWorker-1] Encountered an Axis Fault :
> java.lang.RuntimeExceptio
> n: Unexpected subelement TopicExpression_T; nested exception is:
> java.lang.RuntimeException: java.lang.RuntimeException: Unexpected
> subel
> ement TopicExpression_T
> org.apache.axis2.AxisFault: java.lang.RuntimeException: Unexpected subelement
> To
> picExpression_T; nested exception is:
> java.lang.RuntimeException: java.lang.RuntimeException: Unexpected
> subel
> ement TopicExpression_T
> at org.apache.axis2.AxisFault.makeFault(AxisFault.java:367)
> at
> org.tmforum.tmf854.v1.ws.notif.NotificationConsumerMessageReceiverInO
> nly.invokeBusinessLogic(NotificationConsumerMessageReceiverInOnly.java:55)
> at
> org.apache.axis2.receivers.AbstractInMessageReceiver.receive(Abstract
> InMessageReceiver.java:35)
> at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:177)
> at
> org.apache.axis2.transport.jms.JMSMessageReceiver$Worker.run(JMSMessa
> geReceiver.java:204)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor
> ker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor
> ker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: Unexpected
> su
> belement TopicExpression_T
> at
> org.tmforum.tmf854.v1.ws.notif.NotificationConsumerMessageReceiverInO
> nly.fromOM(NotificationConsumerMessageReceiverInOnly.java:110)
> at
> org.tmforum.tmf854.v1.ws.notif.NotificationConsumerMessageReceiverInO
> nly.invokeBusinessLogic(NotificationConsumerMessageReceiverInOnly.java:42)
> ... 6 more
> Caused by: java.lang.RuntimeException: Unexpected subelement TopicExpression_T
> at org.tmforum.tmf854.v1.Notify_T$Factory.parse(Notify_T.java:540)
> at org.tmforum.tmf854.v1.Notify$Factory.parse(Notify.java:292)
> at
> org.tmforum.tmf854.v1.ws.notif.NotificationConsumerMessageReceiverInO
> nly.fromOM(NotificationConsumerMessageReceiverInOnly.java:97)
> ... 7 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-3027) Improve Axis idea plugin wizard
[ https://issues.apache.org/jira/browse/AXIS2-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shivantha Huruggamuwa updated AXIS2-3027: - Attachment: Axis2_Idea_Plugin_Patch_AddLicensed.txt this patch add license to java class which hasn't apache license. > Improve Axis idea plugin wizard > > > Key: AXIS2-3027 > URL: https://issues.apache.org/jira/browse/AXIS2-3027 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: Tools >Affects Versions: nightly > Environment: Axis2 idea plugin has some java class without apache > licensed. >Reporter: Shivantha Huruggamuwa >Priority: Minor > Fix For: nightly > > Attachments: Axis2_Idea_Plugin_Patch_AddLicensed.txt > > > Axis2 idea plugin has some java class without apache licensed. so this patch > is adding license to class which has without apache license. -- 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-2970) Improve Axis idea plugin wizard as resizable wizard (Service Archiver)
[ https://issues.apache.org/jira/browse/AXIS2-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Sandakith resolved AXIS2-2970. - Resolution: Fixed patch applied in Committed Rivision 560098 Thanks Shivantha. > Improve Axis idea plugin wizard as resizable wizard (Service Archiver) > -- > > Key: AXIS2-2970 > URL: https://issues.apache.org/jira/browse/AXIS2-2970 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement > Environment: Improve Axis idea plugin wizard as resizable wizard > (Service Archiver) >Reporter: Shivantha Huruggamuwa >Assignee: Lahiru Sandakith > Attachments: Axis2_Idea_Plugin_Patch_07_16.txt, > Axis2_Idea_Plugin_Patch_07_27.txt > > > this patch provide re-sizable wizard panels for service archive wizard. -- 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-3027) Improve Axis idea plugin wizard
Improve Axis idea plugin wizard Key: AXIS2-3027 URL: https://issues.apache.org/jira/browse/AXIS2-3027 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: Tools Affects Versions: nightly Environment: Axis2 idea plugin has some java class without apache licensed. Reporter: Shivantha Huruggamuwa Priority: Minor Fix For: nightly Axis2 idea plugin has some java class without apache licensed. so this patch is adding license to class which has without apache license. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-2970) Improve Axis idea plugin wizard as resizable wizard (Service Archiver)
[ https://issues.apache.org/jira/browse/AXIS2-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shivantha Huruggamuwa updated AXIS2-2970: - Attachment: Axis2_Idea_Plugin_Patch_07_27.txt Hi Lahiru, Above patch had some problems. so this is another patch for above jira. > Improve Axis idea plugin wizard as resizable wizard (Service Archiver) > -- > > Key: AXIS2-2970 > URL: https://issues.apache.org/jira/browse/AXIS2-2970 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement > Environment: Improve Axis idea plugin wizard as resizable wizard > (Service Archiver) >Reporter: Shivantha Huruggamuwa >Assignee: Lahiru Sandakith > Attachments: Axis2_Idea_Plugin_Patch_07_16.txt, > Axis2_Idea_Plugin_Patch_07_27.txt > > > this patch provide re-sizable wizard panels for service archive wizard. -- 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-3026) New AxisConfigurator that operates within the aar file
New AxisConfigurator that operates within the aar file -- Key: AXIS2-3026 URL: https://issues.apache.org/jira/browse/AXIS2-3026 Project: Axis 2.0 (Axis2) Issue Type: Wish Components: kernel Affects Versions: nightly Environment: Not specific Reporter: Mark Badorrek Fix For: nightly Currently there are several AxisConfigurators: FileSystemConfigurator URLBasedAxisConfigurator etc I feel that we also need an AxisConfigurator that can read an axis_client.xml file and client repository that are stored in the aar file. This would allow an axis service to make client-calls to other axis services using different configurations from the parent configuration. For example: I have an axis service 'foo' that is a plain old websevice - nothing special. Now consider that it has been invoked by a client. 'foo' must now make a couple of webservice calls of its own, but this time it will (for example) engage 'rampart' and disengage'addressing' for both of its client calls. As such each configuration will have its own rampart callback classes etc. Currently there is no way to include the required 'client1_axis2.xml', client1_repository', 'client2_axis2.xml', client2_repository', within the aar file and have them loaded. I'd like to see an 'ServiceClassloaderAxisConfigurator' to allow these artifacts to be stored within the aar file so that the entire 'foo' webservice is a single file deploy. The 'client1_AxisConfiguration' and 'client1_AxisConfiguration' should also be cached as there is a high probability that they will be required agin and again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-3017) WSDL generation error - lowercasing 1st char in element names
[
https://issues.apache.org/jira/browse/AXIS2-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davanum Srinivas updated AXIS2-3017:
Priority: Blocker (was: Major)
Deepal,
Is this a blocker?
-- dims
> WSDL generation error - lowercasing 1st char in element names
> -
>
> Key: AXIS2-3017
> URL: https://issues.apache.org/jira/browse/AXIS2-3017
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: wsdl
>Reporter: nadir amra
>Priority: Blocker
> Attachments: ConvertTemp.zip
>
>
> Here is the problem. I deploy a POJO and when AXIS2 (using nightly build
> 2007/07/25) automatically generated WSDL via ?wsdl it produces a WSDL file
> the includes the following:
>
>
> type="xs:string"/>
> type="xs:string"/>
>
>
>
>
> type="xs:string"/>
> type="xs:string"/>
>
>
> The problem is with the element names. It seems that AXIS2 is lowercasing
> the "t" in TEMPIN and TEMPOUT, which makes the service unusable. The
> CONVERTTEMPInput class is as follows:
> public class CONVERTTEMPInput implements Serializable
> {
> private static final long serialVersionUID = -884605419035002637L;
> public CONVERTTEMPInput() { }
> public void setTEMPIN( String TEMPIN )
> {
> _TEMPIN = TEMPIN;
> }
> public String getTEMPIN( )
> {
>return _TEMPIN;
> }
> public void setTEMPOUT( String TEMPOUT )
> {
> _TEMPOUT = TEMPOUT;
> }
> public String getTEMPOUT( )
> {
>return _TEMPOUT;
> }
>private String _TEMPIN = "";
>private String _TEMPOUT = "";
> }
> If I add an underscore prior to TEMPIN and TEMPOUT in the method names,
> things start to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-3025) Update documentation about builds from m1 to m2
[ https://issues.apache.org/jira/browse/AXIS2-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davanum Srinivas updated AXIS2-3025: Component/s: documentation Priority: Blocker (was: Major) > Update documentation about builds from m1 to m2 > --- > > Key: AXIS2-3025 > URL: https://issues.apache.org/jira/browse/AXIS2-3025 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: documentation >Reporter: Davanum Srinivas >Priority: Blocker > > http://marc.info/?l=axis-user&m=118531066900497&w=2 > "I actually tried to build axis2 from svn sources and found out that > the build must be done using maven 2. I think that the build > documentation also needs a brush-up before a release to > reflect the use of maven 2, e.g. in > xdocs/maven-help.xml, svn.xml, faq.xml. > - Erik" -- 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-3025) Update documentation about builds from m1 to m2
Update documentation about builds from m1 to m2 --- Key: AXIS2-3025 URL: https://issues.apache.org/jira/browse/AXIS2-3025 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Davanum Srinivas http://marc.info/?l=axis-user&m=118531066900497&w=2 "I actually tried to build axis2 from svn sources and found out that the build must be done using maven 2. I think that the build documentation also needs a brush-up before a release to reflect the use of maven 2, e.g. in xdocs/maven-help.xml, svn.xml, faq.xml. - Erik" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-3024) CodegenToolReference.html totally out of date
[ https://issues.apache.org/jira/browse/AXIS2-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davanum Srinivas updated AXIS2-3024: Component/s: documentation > CodegenToolReference.html totally out of date > - > > Key: AXIS2-3024 > URL: https://issues.apache.org/jira/browse/AXIS2-3024 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: documentation >Reporter: Davanum Srinivas >Priority: Blocker > Fix For: 1.3 > > > Ant task documentation is totally out of date. (CodegenToolReference.html). > Need to add documentation for m2 task 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] Created: (AXIS2-3024) CodegenToolReference.html totally out of date
CodegenToolReference.html totally out of date - Key: AXIS2-3024 URL: https://issues.apache.org/jira/browse/AXIS2-3024 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Davanum Srinivas Priority: Blocker Fix For: 1.3 Ant task documentation is totally out of date. (CodegenToolReference.html). Need to add documentation for m2 task 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]
Re: [Axis2] "Speak Now or Forever Hold Your Peace!"
Please add a comment there asking for the priority to be set as blocker. thanks, dims On 7/26/07, Nadir Amra <[EMAIL PROTECTED]> wrote: dims, how about http://issues.apache.org/jira/browse/AXIS2-3017 ( I even attached a very simple example that illustrates the problem). Nadir K. Amra "Davanum Srinivas" <[EMAIL PROTECTED]> wrote on 07/26/2007 07:59:30 AM: > Folks, > > We've cut 2 RC's for 1.3 release and nightlies are up and running for > the 1.3 branch as well > > *PLEASE* test your scenarios with the latest RC and/or nightly and log > a JIRA bug with all details needed to recreate your problem if you see > something wrong. > > 1.3 RC2 - http://people.apache.org/~deepal/axis2/1.3-RC2/ > 1.3 Branch & Trunk Nightly - http://people.apache.org/dist/axis2/nightly/ > JIRA - https://issues.apache.org/jira/browse/AXIS2 > > If 1.3 Final does not work for you when we cut it, it's your own fault > :) If you have a JIRA that has not gotten the attention it deserves, > please speak up and let us know. > > thanks, > dims > > -- > Davanum Srinivas :: http://davanum.wordpress.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2-3023) Performance improvement in EndpointInterfaceDescriptionImpl
[ https://issues.apache.org/jira/browse/AXIS2-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikhil Thaker closed AXIS2-3023. > Performance improvement in EndpointInterfaceDescriptionImpl > --- > > Key: AXIS2-3023 > URL: https://issues.apache.org/jira/browse/AXIS2-3023 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Nikhil Thaker >Assignee: Nikhil Thaker > > The operation lookup in > EndpointInterfaceDescriptionImpl.getDispatchableOperation(QName) performs a > bunch of terations over lists copying arrays to find the operation for the > input qName. I am adding code that will improve the performance by building > a map of operations by qName when the operation is added. Then > getDispatchableOperation can just do a lookup on hashmap for the qname this > will increase the performance. -- 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-3023) Performance improvement in EndpointInterfaceDescriptionImpl
[ https://issues.apache.org/jira/browse/AXIS2-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikhil Thaker resolved AXIS2-3023. -- Resolution: Fixed revision# 559975 > Performance improvement in EndpointInterfaceDescriptionImpl > --- > > Key: AXIS2-3023 > URL: https://issues.apache.org/jira/browse/AXIS2-3023 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Nikhil Thaker >Assignee: Nikhil Thaker > > The operation lookup in > EndpointInterfaceDescriptionImpl.getDispatchableOperation(QName) performs a > bunch of terations over lists copying arrays to find the operation for the > input qName. I am adding code that will improve the performance by building > a map of operations by qName when the operation is added. Then > getDispatchableOperation can just do a lookup on hashmap for the qname this > will increase the performance. -- 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]
Re: [Axis2] "Speak Now or Forever Hold Your Peace!"
dims, how about http://issues.apache.org/jira/browse/AXIS2-3017 ( I even attached a very simple example that illustrates the problem). Nadir K. Amra "Davanum Srinivas" <[EMAIL PROTECTED]> wrote on 07/26/2007 07:59:30 AM: > Folks, > > We've cut 2 RC's for 1.3 release and nightlies are up and running for > the 1.3 branch as well > > *PLEASE* test your scenarios with the latest RC and/or nightly and log > a JIRA bug with all details needed to recreate your problem if you see > something wrong. > > 1.3 RC2 - http://people.apache.org/~deepal/axis2/1.3-RC2/ > 1.3 Branch & Trunk Nightly - http://people.apache.org/dist/axis2/nightly/ > JIRA - https://issues.apache.org/jira/browse/AXIS2 > > If 1.3 Final does not work for you when we cut it, it's your own fault > :) If you have a JIRA that has not gotten the attention it deserves, > please speak up and let us know. > > thanks, > dims > > -- > Davanum Srinivas :: http://davanum.wordpress.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3023) Performance improvement in EndpointInterfaceDescriptionImpl
Performance improvement in EndpointInterfaceDescriptionImpl --- Key: AXIS2-3023 URL: https://issues.apache.org/jira/browse/AXIS2-3023 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Nikhil Thaker Assignee: Nikhil Thaker The operation lookup in EndpointInterfaceDescriptionImpl.getDispatchableOperation(QName) performs a bunch of terations over lists copying arrays to find the operation for the input qName. I am adding code that will improve the performance by building a map of operations by qName when the operation is added. Then getDispatchableOperation can just do a lookup on hashmap for the qname this will increase the performance. -- 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_12515816 ] Lin Sun commented on AXIS2-3011: Hi Dustin, I am caching the configurationContext object. Code is same as Jarek but doing that in geronimo (by extends the ClientConfigurationFactory). We thought of doing that because we were not sure if this change will be accepted in axis2. But with that, I am running this "Two services cannot have same name." I am thinking of the changes below in line 944 of EndpointDescriptionImpl.java -axisSvc.setName(axisSvc.getName() + this.hashCode()); +axisSvc.setName(axisSvc.getName() + this.hashCode() + System.currentTimeMillis()); But I am not sure if that will introduce any other probs? Lin > 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-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_12515817 ] Jarek Gawor commented on AXIS2-3011: It all depends what the configuration context is used for or what information is stored in it. If it contains general info such as what transport driver should be used, it should be totally fine to reuse. But if some information about a particular web service is stored in it then it cannot be shared. And if it cannot be shared (since each web service client will require its own configuration context) then the ServiceDescription caching done in DescriptionFactoryImpl must be completely removed. > 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] Updated: (AXIS2-3022) Axis2 not handle wsdl deployed to a dir that contains a space (like program files)
[ https://issues.apache.org/jira/browse/AXIS2-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated AXIS2-3022: --- Attachment: Axis2-3022.patch Please ignore the first patch. After more testing, replaceAll isn't needed. It is really the uri=url.toURI() call caused the exception when there is a space in url. Since this is not really useful and problematic, I am proposing to remove it. > Axis2 not handle wsdl deployed to a dir that contains a space (like program > files) > -- > > Key: AXIS2-3022 > URL: https://issues.apache.org/jira/browse/AXIS2-3022 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Affects Versions: 1.3 > Environment: winxp + sun jdk 1.5 >Reporter: Lin Sun >Assignee: Ann Robinson > Fix For: 1.3 > > Attachments: Axis2-3022.patch, Axis2-3022.patch > > > Here is the example I got. Testing a possible fix for this.. > 00:58:38,062 DEBUG [ExceptionFactory] stack:javax.wsdl.WSDLException: > WSDLException: faultCode=WSDL4JWrapper : : Illegal character in path at index > 16: file:/C:/Program > Files/Geronimo/org/apache/geronimo/samples/jws/Calculator/2.0/Calculator-2.0.car/CalculatorService.wsdl > at > org.apache.axis2.jaxws.util.WSDL4JWrapper.(WSDL4JWrapper.java:186) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.setupWsdlDefinition(ServiceDescriptionImpl.java:512) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.(ServiceDescriptionImpl.java:143) > at > org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.createServiceDescription(DescriptionFactoryImpl.java:101) > at > org.apache.axis2.jaxws.description.DescriptionFactory.createServiceDescription(DescriptionFactory.java:69) > at > org.apache.axis2.jaxws.spi.ServiceDelegate.(ServiceDelegate.java:87) > at > org.apache.axis2.jaxws.spi.Provider.createServiceDelegate(Provider.java:45) > at javax.xml.ws.Service.(Service.java:36) > at > org.apache.geronimo.jaxws.client.GenericService.(GenericService.java:27) > at > org.apache.geronimo.jaxws.client.GenericService$$EnhancerByCGLIB$$ba501ee.() > at > org.apache.geronimo.jaxws.client.GenericService$$EnhancerByCGLIB$$ba501ee$$FastClassByCGLIB$$cb90d621.newInstance() > at > net.sf.cglib.reflect.FastConstructor.newInstance(FastConstructor.java:40) > at > org.apache.geronimo.jaxws.client.JAXWSServiceReference.createServiceProxy(JAXWSServiceReference.java:174) > at > org.apache.geronimo.jaxws.client.JAXWSServiceReference.getContent(JAXWSServiceReference.java:129) > at > org.apache.xbean.naming.context.ContextUtil.resolve(ContextUtil.java:61) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:112) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597) > at javax.naming.InitialContext.lookup(InitialContext.java:363) > at org.apache.jsp.addResult_jsp._jspService(addResult_jsp.java:90) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:388) > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at > org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) > at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:351) > at > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at >
[jira] Assigned: (AXIS2-3022) Axis2 not handle wsdl deployed to a dir that contains a space (like program files)
[ https://issues.apache.org/jira/browse/AXIS2-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ann Robinson reassigned AXIS2-3022: --- Assignee: Ann Robinson > Axis2 not handle wsdl deployed to a dir that contains a space (like program > files) > -- > > Key: AXIS2-3022 > URL: https://issues.apache.org/jira/browse/AXIS2-3022 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Affects Versions: 1.3 > Environment: winxp + sun jdk 1.5 >Reporter: Lin Sun >Assignee: Ann Robinson > Fix For: 1.3 > > Attachments: Axis2-3022.patch > > > Here is the example I got. Testing a possible fix for this.. > 00:58:38,062 DEBUG [ExceptionFactory] stack:javax.wsdl.WSDLException: > WSDLException: faultCode=WSDL4JWrapper : : Illegal character in path at index > 16: file:/C:/Program > Files/Geronimo/org/apache/geronimo/samples/jws/Calculator/2.0/Calculator-2.0.car/CalculatorService.wsdl > at > org.apache.axis2.jaxws.util.WSDL4JWrapper.(WSDL4JWrapper.java:186) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.setupWsdlDefinition(ServiceDescriptionImpl.java:512) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.(ServiceDescriptionImpl.java:143) > at > org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.createServiceDescription(DescriptionFactoryImpl.java:101) > at > org.apache.axis2.jaxws.description.DescriptionFactory.createServiceDescription(DescriptionFactory.java:69) > at > org.apache.axis2.jaxws.spi.ServiceDelegate.(ServiceDelegate.java:87) > at > org.apache.axis2.jaxws.spi.Provider.createServiceDelegate(Provider.java:45) > at javax.xml.ws.Service.(Service.java:36) > at > org.apache.geronimo.jaxws.client.GenericService.(GenericService.java:27) > at > org.apache.geronimo.jaxws.client.GenericService$$EnhancerByCGLIB$$ba501ee.() > at > org.apache.geronimo.jaxws.client.GenericService$$EnhancerByCGLIB$$ba501ee$$FastClassByCGLIB$$cb90d621.newInstance() > at > net.sf.cglib.reflect.FastConstructor.newInstance(FastConstructor.java:40) > at > org.apache.geronimo.jaxws.client.JAXWSServiceReference.createServiceProxy(JAXWSServiceReference.java:174) > at > org.apache.geronimo.jaxws.client.JAXWSServiceReference.getContent(JAXWSServiceReference.java:129) > at > org.apache.xbean.naming.context.ContextUtil.resolve(ContextUtil.java:61) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:112) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597) > at javax.naming.InitialContext.lookup(InitialContext.java:363) > at org.apache.jsp.addResult_jsp._jspService(addResult_jsp.java:90) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:388) > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at > org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) > at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:351) > at > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) >
[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_12515780
]
Dustin Amrhein commented on AXIS2-3011:
---
Just a follow-up to explain my comments above
Suppose in a single appserver Module A, Module B, Module C, and Module D are
all deployed.
Module A and Module B both have a service client that refers to a service (say
{http://example}MyService)
Module C and Module D both contain different versions of MyService. Module A
points to the service in
Module C and Module B points to the same service in Module D. It seems that
sharing a ConfigurationContext
between the clients in Module A and Module B could be harmful. What do you
think?
> 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] Updated: (AXIS2-3022) Axis2 not handle wsdl deployed to a dir that contains a space (like program files)
[ https://issues.apache.org/jira/browse/AXIS2-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated AXIS2-3022: --- Attachment: Axis2-3022.patch Tested the code in geronimo env. I had to move the url.toURI() block to the relativePath=true if block because url.toURI() will throw exception if the url contains c:\program files... > Axis2 not handle wsdl deployed to a dir that contains a space (like program > files) > -- > > Key: AXIS2-3022 > URL: https://issues.apache.org/jira/browse/AXIS2-3022 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Affects Versions: 1.3 > Environment: winxp + sun jdk 1.5 >Reporter: Lin Sun > Fix For: 1.3 > > Attachments: Axis2-3022.patch > > > Here is the example I got. Testing a possible fix for this.. > 00:58:38,062 DEBUG [ExceptionFactory] stack:javax.wsdl.WSDLException: > WSDLException: faultCode=WSDL4JWrapper : : Illegal character in path at index > 16: file:/C:/Program > Files/Geronimo/org/apache/geronimo/samples/jws/Calculator/2.0/Calculator-2.0.car/CalculatorService.wsdl > at > org.apache.axis2.jaxws.util.WSDL4JWrapper.(WSDL4JWrapper.java:186) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.setupWsdlDefinition(ServiceDescriptionImpl.java:512) > at > org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.(ServiceDescriptionImpl.java:143) > at > org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.createServiceDescription(DescriptionFactoryImpl.java:101) > at > org.apache.axis2.jaxws.description.DescriptionFactory.createServiceDescription(DescriptionFactory.java:69) > at > org.apache.axis2.jaxws.spi.ServiceDelegate.(ServiceDelegate.java:87) > at > org.apache.axis2.jaxws.spi.Provider.createServiceDelegate(Provider.java:45) > at javax.xml.ws.Service.(Service.java:36) > at > org.apache.geronimo.jaxws.client.GenericService.(GenericService.java:27) > at > org.apache.geronimo.jaxws.client.GenericService$$EnhancerByCGLIB$$ba501ee.() > at > org.apache.geronimo.jaxws.client.GenericService$$EnhancerByCGLIB$$ba501ee$$FastClassByCGLIB$$cb90d621.newInstance() > at > net.sf.cglib.reflect.FastConstructor.newInstance(FastConstructor.java:40) > at > org.apache.geronimo.jaxws.client.JAXWSServiceReference.createServiceProxy(JAXWSServiceReference.java:174) > at > org.apache.geronimo.jaxws.client.JAXWSServiceReference.getContent(JAXWSServiceReference.java:129) > at > org.apache.xbean.naming.context.ContextUtil.resolve(ContextUtil.java:61) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:112) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597) > at javax.naming.InitialContext.lookup(InitialContext.java:363) > at org.apache.jsp.addResult_jsp._jspService(addResult_jsp.java:90) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:388) > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at > org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) > at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:351) > at > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) > at > org.apache.catalina.core.
[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_12515777 ] Dustin Amrhein commented on AXIS2-3011: --- Jarek, Suppose there are multiple J2EE modules deployed on an app server that contain numerous web service clients. If some of the clients in different modules refer to the same qualified service name, but they are actually different service implementations in separate modules, then sharing a ConfigurationContext may be undesirable. I am not sure what caching based on the context class loader would buy us in this situation. What am I missing? > 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]
Re: [Axis2] "Speak Now or Forever Hold Your Peace!"
Raghu, Did you try with Axis2 1.3 RC2? thanks, dims On 7/26/07, Raghu Upadhyayula <[EMAIL PROTECTED]> wrote: Hi Dims, I have a JIRA logged in long back Axis2-2352, the status shows as resolved, though it is not yet resolved. Thanks Raghu -Original Message- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Thursday, July 26, 2007 6:00 AM To: axis-dev@ws.apache.org; [EMAIL PROTECTED] Subject: [Axis2] "Speak Now or Forever Hold Your Peace!" Folks, We've cut 2 RC's for 1.3 release and nightlies are up and running for the 1.3 branch as well *PLEASE* test your scenarios with the latest RC and/or nightly and log a JIRA bug with all details needed to recreate your problem if you see something wrong. 1.3 RC2 - http://people.apache.org/~deepal/axis2/1.3-RC2/ 1.3 Branch & Trunk Nightly - http://people.apache.org/dist/axis2/nightly/ JIRA - https://issues.apache.org/jira/browse/AXIS2 If 1.3 Final does not work for you when we cut it, it's your own fault :) If you have a JIRA that has not gotten the attention it deserves, please speak up and let us know. thanks, dims -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - 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_12515763 ] Jarek Gawor commented on AXIS2-3011: Dustin, I'm not sure about it either but this is about caching *client* configuration context only. Which means all clients (and in any app) would use the same configuration but the web services would have their own unshared configuration. Now, if the client configuration must not be shared or should not be shared then the ClientConfigurationFactory needs to be changed to do some kind of scoping like you mentioned - maybe based on the context class loader?. Bottom line is we need to know if it is safe to share the client configuration context between all applications. If it is, then this patch should be ok. If it is not, I can write another patch/factory that does caching based on the context class loader. > 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-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_12515749 ] Dustin Amrhein commented on AXIS2-3011: --- Lin, Are you caching the AxisConfiguration object or the ConfigurationContext object? Is this done in your own version of a ClientConfigurationFactory? Do you have a code snippet or can you point me at the source? > 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] Created: (AXIS2-3022) Axis2 not handle wsdl deployed to a dir that contains a space (like program files)
Axis2 not handle wsdl deployed to a dir that contains a space (like program files) -- Key: AXIS2-3022 URL: https://issues.apache.org/jira/browse/AXIS2-3022 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Affects Versions: 1.3 Environment: winxp + sun jdk 1.5 Reporter: Lin Sun Fix For: 1.3 Here is the example I got. Testing a possible fix for this.. 00:58:38,062 DEBUG [ExceptionFactory] stack:javax.wsdl.WSDLException: WSDLException: faultCode=WSDL4JWrapper : : Illegal character in path at index 16: file:/C:/Program Files/Geronimo/org/apache/geronimo/samples/jws/Calculator/2.0/Calculator-2.0.car/CalculatorService.wsdl at org.apache.axis2.jaxws.util.WSDL4JWrapper.(WSDL4JWrapper.java:186) at org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.setupWsdlDefinition(ServiceDescriptionImpl.java:512) at org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.(ServiceDescriptionImpl.java:143) at org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.createServiceDescription(DescriptionFactoryImpl.java:101) at org.apache.axis2.jaxws.description.DescriptionFactory.createServiceDescription(DescriptionFactory.java:69) at org.apache.axis2.jaxws.spi.ServiceDelegate.(ServiceDelegate.java:87) at org.apache.axis2.jaxws.spi.Provider.createServiceDelegate(Provider.java:45) at javax.xml.ws.Service.(Service.java:36) at org.apache.geronimo.jaxws.client.GenericService.(GenericService.java:27) at org.apache.geronimo.jaxws.client.GenericService$$EnhancerByCGLIB$$ba501ee.() at org.apache.geronimo.jaxws.client.GenericService$$EnhancerByCGLIB$$ba501ee$$FastClassByCGLIB$$cb90d621.newInstance() at net.sf.cglib.reflect.FastConstructor.newInstance(FastConstructor.java:40) at org.apache.geronimo.jaxws.client.JAXWSServiceReference.createServiceProxy(JAXWSServiceReference.java:174) at org.apache.geronimo.jaxws.client.JAXWSServiceReference.getContent(JAXWSServiceReference.java:129) at org.apache.xbean.naming.context.ContextUtil.resolve(ContextUtil.java:61) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:112) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597) at javax.naming.InitialContext.lookup(InitialContext.java:363) at org.apache.jsp.addResult_jsp._jspService(addResult_jsp.java:90) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:388) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:351) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(T
[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_12515738 ] Dustin Amrhein commented on AXIS2-3011: --- Jarek, With regards to the attached patch. Is it suitable to always return the same ConfigurationContext with no scoping attached to the caching? For example, if this code is running within an app server process and there are multiple J2EE modules that have services with the exact same name, could returning the same ConfigurationContext cause a problem? I'm not sure of the answer just wanted to pose the question. > 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-3007) RESTful services invocation self induces Input Stream Closed error
[
https://issues.apache.org/jira/browse/AXIS2-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515720
]
Keith Godwin Chapman commented on AXIS2-3007:
-
This is the scenario at the moment. If the Axis Engine receives a REST request
and if it cannot find a relevant builder that matches the content-type it uses
that builder. If it cannot find a builder it uses the default.
ApplicationXMLBuilder iof the request is s POST or XformURLEncodedBuilder if
the request was a GET.
The fix is for both client and server side. Its almost impossible to detect
incorrectly typed messages untill it gets to the builder. It's the builder who
is aware as to how the message should look like. This is because the builders
are pluggable. Anybody can write a custom builder and set its relavalt
content-type to "foo". Its only the builder who knows how to build this
message. So thats the first point that we can detect an error. Afterall this is
not deep in axis. We detect the error before passing the message to the axis
engine.
Its
> RESTful services invocation self induces Input Stream Closed error
> --
>
> Key: AXIS2-3007
> URL: https://issues.apache.org/jira/browse/AXIS2-3007
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
>Affects Versions: 1.2
> Environment: Windows 2000, Eclipse IDE
>Reporter: Jason Kania
>Assignee: Keith Godwin Chapman
> Attachments: patch.txt
>
>
> When making REST GET calls to an API, Axis 2 core sets its input stream to
> null and then complains later that its stream has been closed. The following
> partial stack trace demonstrates the problem.
> ApplicationXMLBuilder.processDocument(InputStream, String, MessageContext)
> line: 49
> TransportUtils.createSOAPMessage(MessageContext, InputStream, String) line:
> 130
> RESTUtil.processURLRequest(MessageContext, OutputStream, String) line: 98
> AxisServlet$ProcessRESTRequest.processURLRequest() line: 776
> AxisServlet.doGet(HttpServletRequest, HttpServletResponse) line: 238
> AxisServlet(HttpServlet).service(HttpServletRequest, HttpServletResponse)
> line: 707
> AxisServlet(HttpServlet).service(ServletRequest, ServletResponse) line: 820
> ServletHolder.handle(ServletRequest, ServletResponse) line: 487
> ...
> In RESTUtil, method processURLRequest, the following call is made on line 98
> soapEnvelope = TransportUtils
> .createSOAPMessage(msgContext, null, contentType);
> where the null is supposed to be the input stream
> Thus, when line 49 of ApplicationXMLBuilder in method processDocument is
> encountered,
> PushbackInputStream pushbackInputStream = new
> PushbackInputStream(inputStream);
> where inputStream is null,
> the exception "java.io.IOException: Stream closed" is generated once the
> empty stream is read at line 51
> of ApplicationXMLBuilder:
>if ((b = pushbackInputStream.read()) > 0) {
> For straight Axis use, this issue is a blocker, but I have worked around the
> problem by filtering empty get methods at the servlet level and am populating
> them with content for now.
--
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]
Re: Creating a service that accepts any XML
Hi Paul!
Paul Fremantle wrote:
There was a SOAPAction, but since I want this service to accept *any*
SOAP message, I don't know what it is ahead of time. And I don't want
to have to define every possible SOAPAction - I just want all my
requests to do to the same MessageReceiver.receive() no matter what.
You can do this as follows.
1) Make sure your service has exactly one operation.
2) service.setParameter("supportSingleOperation", Boolean.TRUE)
Voila. :)
--Glen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating a service that accepts any XML
Wicked! Thanks!
On 7/26/07, Glen Daniels <[EMAIL PROTECTED]> wrote:
> Hi Paul!
>
> Paul Fremantle wrote:
> > There was a SOAPAction, but since I want this service to accept *any*
> > SOAP message, I don't know what it is ahead of time. And I don't want
> > to have to define every possible SOAPAction - I just want all my
> > requests to do to the same MessageReceiver.receive() no matter what.
>
> You can do this as follows.
>
> 1) Make sure your service has exactly one operation.
>
> 2) service.setParameter("supportSingleOperation", Boolean.TRUE)
>
> Voila. :)
>
> --Glen
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-3021) java.lang.StackOverflowError when trying to generate code for an Amazon service.
[ https://issues.apache.org/jira/browse/AXIS2-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cristian Ivascu updated AXIS2-3021: --- Description: When trying to invoke WSDL2Java.bat or use the Axis2 code to generate client code for the amazon wsdl (http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl) I get a java.lang.stackOverflowError message. It seems to go into recursion somewhere when processing the particles for a complex type, in the SchemaCompiler.java class ->processParticle() method. (was: When trying to invoke WSDL2Java.bat or use the Axis2 code to generate client code for the amazon wsdl () I get a java.lang.stackOverflowError message. It seems to go into recursion somewhere when processing the particles for a complex type, in the SchemaCompiler.java class ->processParticle() method.) Forgot the URL to the WSDL > java.lang.StackOverflowError when trying to generate code for an Amazon > service. > > > Key: AXIS2-3021 > URL: https://issues.apache.org/jira/browse/AXIS2-3021 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: adb > Environment: Windows XP SP2 / JDK 1.4.12 >Reporter: Cristian Ivascu > > When trying to invoke WSDL2Java.bat or use the Axis2 code to generate client > code for the amazon wsdl > (http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl) > I get a java.lang.stackOverflowError message. It seems to go into recursion > somewhere when processing the particles for a complex type, in the > SchemaCompiler.java class ->processParticle() method. -- 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-3021) java.lang.StackOverflowError when trying to generate code for an Amazon service.
java.lang.StackOverflowError when trying to generate code for an Amazon service. Key: AXIS2-3021 URL: https://issues.apache.org/jira/browse/AXIS2-3021 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: adb Environment: Windows XP SP2 / JDK 1.4.12 Reporter: Cristian Ivascu When trying to invoke WSDL2Java.bat or use the Axis2 code to generate client code for the amazon wsdl () I get a java.lang.stackOverflowError message. It seems to go into recursion somewhere when processing the particles for a complex type, in the SchemaCompiler.java class ->processParticle() method. -- 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]
Re: [Axis2] "Speak Now or Forever Hold Your Peace!"
Yep! On 7/26/07, robert lazarski <[EMAIL PROTECTED]> wrote: So am I correct in assuming this is branch: axis2-1.3-SNAPSHOT-war.zip axis2-1.3-SNAPSHOT-src.zip axis2-1.3-SNAPSHOT-war.zip And this is head? axis2-SNAPSHOT-bin.zip axis2-SNAPSHOT-src.zip axis2-SNAPSHOT-war.zip FYI, hope to finish testing the parts I use - spring, xmlbeans and the soapmonitor - along with some doc updates today but no later than tomorrow. Robert On 7/26/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > Folks, > > We've cut 2 RC's for 1.3 release and nightlies are up and running for > the 1.3 branch as well > > *PLEASE* test your scenarios with the latest RC and/or nightly and log > a JIRA bug with all details needed to recreate your problem if you see > something wrong. > > 1.3 RC2 - http://people.apache.org/~deepal/axis2/1.3-RC2/ > 1.3 Branch & Trunk Nightly - http://people.apache.org/dist/axis2/nightly/ > JIRA - https://issues.apache.org/jira/browse/AXIS2 > > If 1.3 Final does not work for you when we cut it, it's your own fault > :) If you have a JIRA that has not gotten the attention it deserves, > please speak up and let us know. > > thanks, > dims > > -- > Davanum Srinivas :: http://davanum.wordpress.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-3018) ServiceDescriptionImpl.updateEndpointDescription() re-creates EndpointDescription objects when portQName is not specified
[ https://issues.apache.org/jira/browse/AXIS2-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ann Robinson reassigned AXIS2-3018: --- Assignee: Ann Robinson > ServiceDescriptionImpl.updateEndpointDescription() re-creates > EndpointDescription objects when portQName is not specified > - > > Key: AXIS2-3018 > URL: https://issues.apache.org/jira/browse/AXIS2-3018 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws >Reporter: Jarek Gawor >Assignee: Ann Robinson > Attachments: AXIS2-3018.patch > > > ServiceDescriptionImpl.updateEndpointDescription() looks for existing > EndpointDescription objects only when portQName is specified. When portQName > is not specified, the updateEndpointDescription() function will create a new > EndpointDescription each time it is called. This can lead to a memory leak > when the client configuration context is reused because somehow the > EndpointDescription objects remain retained (through AxisConfiguration). I > can provide more info on that later. -- 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-3007) RESTful services invocation self induces Input Stream Closed error
[
https://issues.apache.org/jira/browse/AXIS2-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515705
]
Jason Kania commented on AXIS2-3007:
Keith,
Sorry if I am responding in an incorrect manner. I did not see how you
responded without leaving a visibile comment in the problem ticket.
Thanks for the fix. I will test shortly since I can't change code right away.
From your comments, I believe that you fixed only the client side. Does this
leave a vulnerability on the server side in that incorrectly typed messages
will get too deep into the stack before being detected? If the detection point
for the error is at the expected location, then no worries since this won't
affect my usage, but offhand, I thought that that my message had arrived
fairly deep into the stack before the stack discovered that the message would
not be able to be processed.
Thanks again,
Jason
"Keith Godwin Chapman (JIRA)" <[EMAIL PROTECTED]> wrote:
[
https://issues.apache.org/jira/browse/AXIS2-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515633
]
Keith Godwin Chapman commented on AXIS2-3007:
-
fixed in revision 559737. Commited to both trunk and branch.
Jason can you check the latest nightly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
> RESTful services invocation self induces Input Stream Closed error
> --
>
> Key: AXIS2-3007
> URL: https://issues.apache.org/jira/browse/AXIS2-3007
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
>Affects Versions: 1.2
> Environment: Windows 2000, Eclipse IDE
>Reporter: Jason Kania
>Assignee: Keith Godwin Chapman
> Attachments: patch.txt
>
>
> When making REST GET calls to an API, Axis 2 core sets its input stream to
> null and then complains later that its stream has been closed. The following
> partial stack trace demonstrates the problem.
> ApplicationXMLBuilder.processDocument(InputStream, String, MessageContext)
> line: 49
> TransportUtils.createSOAPMessage(MessageContext, InputStream, String) line:
> 130
> RESTUtil.processURLRequest(MessageContext, OutputStream, String) line: 98
> AxisServlet$ProcessRESTRequest.processURLRequest() line: 776
> AxisServlet.doGet(HttpServletRequest, HttpServletResponse) line: 238
> AxisServlet(HttpServlet).service(HttpServletRequest, HttpServletResponse)
> line: 707
> AxisServlet(HttpServlet).service(ServletRequest, ServletResponse) line: 820
> ServletHolder.handle(ServletRequest, ServletResponse) line: 487
> ...
> In RESTUtil, method processURLRequest, the following call is made on line 98
> soapEnvelope = TransportUtils
> .createSOAPMessage(msgContext, null, contentType);
> where the null is supposed to be the input stream
> Thus, when line 49 of ApplicationXMLBuilder in method processDocument is
> encountered,
> PushbackInputStream pushbackInputStream = new
> PushbackInputStream(inputStream);
> where inputStream is null,
> the exception "java.io.IOException: Stream closed" is generated once the
> empty stream is read at line 51
> of ApplicationXMLBuilder:
>if ((b = pushbackInputStream.read()) > 0) {
> For straight Axis use, this issue is a blocker, but I have worked around the
> problem by filtering empty get methods at the servlet level and am populating
> them with content for now.
--
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]
Re: [Axis2] "Speak Now or Forever Hold Your Peace!"
So am I correct in assuming this is branch: axis2-1.3-SNAPSHOT-war.zip axis2-1.3-SNAPSHOT-src.zip axis2-1.3-SNAPSHOT-war.zip And this is head? axis2-SNAPSHOT-bin.zip axis2-SNAPSHOT-src.zip axis2-SNAPSHOT-war.zip FYI, hope to finish testing the parts I use - spring, xmlbeans and the soapmonitor - along with some doc updates today but no later than tomorrow. Robert On 7/26/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > Folks, > > We've cut 2 RC's for 1.3 release and nightlies are up and running for > the 1.3 branch as well > > *PLEASE* test your scenarios with the latest RC and/or nightly and log > a JIRA bug with all details needed to recreate your problem if you see > something wrong. > > 1.3 RC2 - http://people.apache.org/~deepal/axis2/1.3-RC2/ > 1.3 Branch & Trunk Nightly - http://people.apache.org/dist/axis2/nightly/ > JIRA - https://issues.apache.org/jira/browse/AXIS2 > > If 1.3 Final does not work for you when we cut it, it's your own fault > :) If you have a JIRA that has not gotten the attention it deserves, > please speak up and let us know. > > thanks, > dims > > -- > Davanum Srinivas :: http://davanum.wordpress.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-3011) ServiceDescription caching leads to memory leak
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ann Robinson reassigned AXIS2-3011: --- Assignee: Ann Robinson > 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]
out of memory in Axis 1.4
Hi, I am getting the following error intermittently: - Exception: java.lang.OutOfMemoryError I am sending 1 MB payloads but I have enough memory heap size (512 MB), anybody knows what might be the issue? is there a parameter or setting I need to set or initialize? The failure seems to happen on the invoke method in the Axis servlet. Thanks, Firas
[jira] Created: (AXIS2-3020) Support serialization of java.util.Map when using POJO service with RPCMessageReceiver.
Support serialization of java.util.Map when using POJO service with RPCMessageReceiver. --- Key: AXIS2-3020 URL: https://issues.apache.org/jira/browse/AXIS2-3020 Project: Axis 2.0 (Axis2) Issue Type: New Feature Components: adb Reporter: Sathija Pavuluri Priority: Minor At one point serialization of java.util.Map was on Axis' TODO list but has since fallen through the cracks. When using POJO approach, Map serialization/deserialization is not supported. Would be nice to add that support. -- 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-2961) FastInfoset build failure (unit test) in JDK 1.4
[ https://issues.apache.org/jira/browse/AXIS2-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davanum Srinivas resolved AXIS2-2961. - Resolution: Fixed Fixed in svn revision 559816 (trunk) and 1.3 branch (559817) -- dims > FastInfoset build failure (unit test) in JDK 1.4 > > > Key: AXIS2-2961 > URL: https://issues.apache.org/jira/browse/AXIS2-2961 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: modules >Affects Versions: nightly > Environment: JDK 1.4.* >Reporter: Sanjaya Karunasena >Assignee: Davanum Srinivas >Priority: Critical > Attachments: FastInfoset-1.1.8.pom, patch-jdk1.4 > > > With JDK 1.4, FastInfoset jar version 1.1.* should be used. Maven2 script > need to be modified to achieved 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] 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_12515699 ] Lin Sun commented on AXIS2-3011: Looks like the message "Two services cannot have same name." happens when the code tries to add a service which has already being added to the axisconfig. This error didn't happen before since we didn't cache the axisconfig and create a new one every single time. One possible fix is when the axisserv name is set, use a unique value (in line 944 of EndpointDescriptionImpl.java). From the exception, the this.hashCode() doesn't seem to be generating a unique value. > 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 > 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]
[Axis2] "Speak Now or Forever Hold Your Peace!"
Folks, We've cut 2 RC's for 1.3 release and nightlies are up and running for the 1.3 branch as well *PLEASE* test your scenarios with the latest RC and/or nightly and log a JIRA bug with all details needed to recreate your problem if you see something wrong. 1.3 RC2 - http://people.apache.org/~deepal/axis2/1.3-RC2/ 1.3 Branch & Trunk Nightly - http://people.apache.org/dist/axis2/nightly/ JIRA - https://issues.apache.org/jira/browse/AXIS2 If 1.3 Final does not work for you when we cut it, it's your own fault :) If you have a JIRA that has not gotten the attention it deserves, please speak up and let us know. thanks, dims -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] jibx module changes to 1.3 branch
Dennis Sosnoski wrote: I'd like to merge this change on trunk into the 1.3 branch: http://svn.apache.org/viewvc?view=rev&rev=559788 +1, go for it. In general, unless it's something really serious or surprising, just go and commit stuff to the branch if you feel it needs to go into the release. The idea is to share the load so we don't gate on the group, or even the release manager, for commits. Use your discretion, and the RM or someone else will holler if there's an issue. --Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] jibx module changes to 1.3 branch
Nope. Please go ahead. On 7/26/07, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: I'd like to merge this change on trunk into the 1.3 branch: http://svn.apache.org/viewvc?view=rev&rev=559788 Anyone object? Thanks, - Dennis -- Dennis M. Sosnoski SOA and Web Services in Java Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] jibx module changes to 1.3 branch
I'd like to merge this change on trunk into the 1.3 branch: http://svn.apache.org/viewvc?view=rev&rev=559788 Anyone object? Thanks, - Dennis -- Dennis M. Sosnoski SOA and Web Services in Java Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Supporting content types in Synapse and Axiom
Hi
As Synapse is getting more interest I see a number of people looking
to use it and extend it for binary and text content types as well as
XML.
We already support those from some transports (e.g. JMS) but each
transport defines its own way of handling these things, and so I can't
be sure that a message coming in as binary/jms can go out correctly as
binary/http post.
So here is what I'd like to do:
I'd like to have explicit methods:
OMElement get/setPayload()
DataHandler get/setBytesPayload()
String get/setTextPayload()
boolean isBinary();
boolean isText();
int getPayloadType()
In order to make this work, we should have two well defined QNames -
one for binary and one for text.
For example binary payload will be in a wrapper element called:
http://ws.apache.org/commons/axiom/ns/data";>
And text payload could be in
http://ws.apache.org/commons/axiom/ns/data";>
So if I setBinaryPayload, basically what happens (under the covers is)
OMElement el = fac.createOMElement("binary", axNS);
OMText bin = fac.createOMText(dh, true);
el.addChild(bin);
getBody().setFirstChild(el);
Now I'd be very happy to do this just in Synapse, but it makes much
more sense to do it in Axiom. That would mean everyone using this
(axis2 transports, synapse mediators, etc) would inherit the same
definitions and use the data in a consistent way. Which is the point
of this.
Paul
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating a service that accepts any XML
There was a SOAPAction, but since I want this service to accept *any* SOAP message, I don't know what it is ahead of time. And I don't want to have to define every possible SOAPAction - I just want all my requests to do to the same MessageReceiver.receive() no matter what. Paul On 7/26/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: > > > Hi > > > > I was trying to create a simple service that takes any SOAP message > > and logs it. Sort of a "sink" service. Unfortunately, because the > > dispatchers are trying to figure out the operation it failed. > > > > Is there any way to do this? Note I don't want to change the default > > dispatchers because I have other services deployed as well. > > > How about sending a SOAP action ? > > Thanks > Deepal > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Paul Fremantle Co-Founder and VP of Technical Sales, WSO2 OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]Secure + Reliable with SMTP issue
On 7/26/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: > > > I did some integration tests using Rampart, Sandesha and Addressing. > for both http and smtp transports. > All those senarios successed with the latest Axis2 and Sandesha builds > with the attached Axis2.xml and Sandesha module.xml. (Chamikara helped > me a lot in doing this.) > Same tests successed with an .Net service using http transport as well. > > Therefore I belive this phase order is the most correct one to use > with full stack. > > Here we have used a new phase called > Nope we do not need this phase , and I think we can get the same behavior by putting the handler in the Dispatch phase. if you are quite sure no problem. Thanks Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Amila Suriarachchi, WSO2 Inc.
Re: Creating a service that accepts any XML
> Hi > > I was trying to create a simple service that takes any SOAP message > and logs it. Sort of a "sink" service. Unfortunately, because the > dispatchers are trying to figure out the operation it failed. > > Is there any way to do this? Note I don't want to change the default > dispatchers because I have other services deployed as well. > How about sending a SOAP action ? Thanks Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]Secure + Reliable with SMTP issue
> > > I did some integration tests using Rampart, Sandesha and Addressing. > for both http and smtp transports. > All those senarios successed with the latest Axis2 and Sandesha builds > with the attached Axis2.xml and Sandesha module.xml. (Chamikara helped > me a lot in doing this.) > Same tests successed with an .Net service using http transport as well. > > Therefore I belive this phase order is the most correct one to use > with full stack. > > Here we have used a new phase called > Nope we do not need this phase , and I think we can get the same behavior by putting the handler in the Dispatch phase. Thanks Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Creating a service that accepts any XML
Hi I was trying to create a simple service that takes any SOAP message and logs it. Sort of a "sink" service. Unfortunately, because the dispatchers are trying to figure out the operation it failed. Is there any way to do this? Note I don't want to change the default dispatchers because I have other services deployed as well. Paul -- Paul Fremantle Co-Founder and VP of Technical Sales, WSO2 OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]Secure + Reliable with SMTP issue
hi, I did some integration tests using Rampart, Sandesha and Addressing. for both http and smtp transports. All those senarios successed with the latest Axis2 and Sandesha builds with the attached Axis2.xml and Sandesha module.xml. (Chamikara helped me a lot in doing this.) Same tests successed with an .Net service using http transport as well. Therefore I belive this phase order is the most correct one to use with full stack. Here we have used a new phase called to support sandesha. So shall we put this phase as well? When considering this senario a suggestion at sometime to let modules to define there own phases came to my mind. As I remember Glen has made this proposal, I put a +1 and deepal had put a -1. If that feature was there we would have solve this problem without changing the axis2 xml file and letting modules to define their own phases and place them using phase rules. So as I can see this would be a nice to have a feature in Axis2 1.4(obviously not for Axis2 1.3). thanks, Amila. On 7/25/07, Chamikara Jayalath <[EMAIL PROTECTED]> wrote: Hi Guys, +1 For the change. There is another change I would like to propose here. Addressing comes with a AddressingValidationHandler which throws an exception if dispatching has not been done when addressing is present. If we move this to the Addressing Phase as well none of the other dispatchers will work when Addressing is present. This may be theoretically correct. But there may be scenarios where we need the other dispatchers to work even when addressing is present. For example the SequenceIDDIspatcher we introduced in Sandesha2 does the service dispatching based of the WSRM sequence ID. I think we need to have the flexibility in Axis2 to allow the addition of such features. So my proposal is the keep the addressing handlers and the dispachers in the Addressing phase. But to move the validation handler back. Somewhere after dispatchers. Either we can add this as a postCondition fo the Dispatch phase. Or we can add a new DispatchValidation Phase. Chamikara On 7/25/07, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote: > > +1 for adding a new phase and resolve the issue. > That way it clear for anybody to figure out the order > Addressing->Security->RM > -jaliya > - Original Message - > From: "Deepal Jayasinghe" < [EMAIL PROTECTED]> > To: > Sent: Tuesday, July 24, 2007 4:35 AM > Subject: Re: [Axis2]Secure + Reliable with SMTP issue > > > >I will introduce a new phase called "Addressing " and go forward , > let's > > revert that if we found and issue. > > > > Thanks > > Deepal > > > > Sanjiva Weerawarana wrote: > >> +1 ... I think we need to ship an Axis2 that can compose nicely and > >> easily with Rampart and Sandesha to make secure+RM work correctly for > >> HTTP and SMTP (basically for all transports we support). > >> > >> Sanjiva. > >> > >> Deepal Jayasinghe wrote: > >>> Hi Dims, > >>> > >>> No the issues is client side when someone tries to use RM+ Security > then > >>> he has to go and change axis2.xml. Other thing is for security to > work > >>> correctly it is required to have addressing based dispatcher before > >>> security handlers. And using a security is common case so I think > >>> default axis2.xml should support that. > >>> > >>> Thanks > >>> Deepal > Deepal, > > IMHO, This can be documented and fixed post 1.3 I can see folks who > > are working on an advanced scenario comfortable with a custom > axis2.xml. > > thanks, > dims > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Chamikara Jayalath WSO2 Inc. http://wso2.com/ http://wso2.org/ - For your Oxygen needs -- Amila Suriarachchi, WSO2 Inc. true false false false 3 false false admin axis2 false http://www.w3.org/2004/08/wsdl/in-only"; class="org.apache.axis2.receivers.RawXMLINOnlyMessageReceiver"/> http://www.w3.org/2004/08/wsdl/in-out"; class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/> http://www.w3.org/2006/01/wsdl/in-only"; class="org.apache.axis2.receivers.RawXMLINOnlyMessageReceiver"/> http://www.w3.org/2006/01/wsdl/in-out"; class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
[jira] Commented: (AXIS2-3007) RESTful services invocation self induces Input Stream Closed error
[
https://issues.apache.org/jira/browse/AXIS2-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515633
]
Keith Godwin Chapman commented on AXIS2-3007:
-
fixed in revision 559737. Commited to both trunk and branch.
Jason can you check the latest nightly.
> RESTful services invocation self induces Input Stream Closed error
> --
>
> Key: AXIS2-3007
> URL: https://issues.apache.org/jira/browse/AXIS2-3007
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
>Affects Versions: 1.2
> Environment: Windows 2000, Eclipse IDE
>Reporter: Jason Kania
>Assignee: Keith Godwin Chapman
> Attachments: patch.txt
>
>
> When making REST GET calls to an API, Axis 2 core sets its input stream to
> null and then complains later that its stream has been closed. The following
> partial stack trace demonstrates the problem.
> ApplicationXMLBuilder.processDocument(InputStream, String, MessageContext)
> line: 49
> TransportUtils.createSOAPMessage(MessageContext, InputStream, String) line:
> 130
> RESTUtil.processURLRequest(MessageContext, OutputStream, String) line: 98
> AxisServlet$ProcessRESTRequest.processURLRequest() line: 776
> AxisServlet.doGet(HttpServletRequest, HttpServletResponse) line: 238
> AxisServlet(HttpServlet).service(HttpServletRequest, HttpServletResponse)
> line: 707
> AxisServlet(HttpServlet).service(ServletRequest, ServletResponse) line: 820
> ServletHolder.handle(ServletRequest, ServletResponse) line: 487
> ...
> In RESTUtil, method processURLRequest, the following call is made on line 98
> soapEnvelope = TransportUtils
> .createSOAPMessage(msgContext, null, contentType);
> where the null is supposed to be the input stream
> Thus, when line 49 of ApplicationXMLBuilder in method processDocument is
> encountered,
> PushbackInputStream pushbackInputStream = new
> PushbackInputStream(inputStream);
> where inputStream is null,
> the exception "java.io.IOException: Stream closed" is generated once the
> empty stream is read at line 51
> of ApplicationXMLBuilder:
>if ((b = pushbackInputStream.read()) > 0) {
> For straight Axis use, this issue is a blocker, but I have worked around the
> problem by filtering empty get methods at the servlet level and am populating
> them with content for now.
--
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]
Re: Fwd: [AXIOM] Undeclare default namespace
Hi Anne,
Yes. That's what I mean. I tried to use *reqElement.declareNamespace("",
"");* but it does not undeclare the default namespace as expected.
Do you know why it does not work as expected?
Regards,
Xinjun
On 7/24/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
By "undeclare" I believe Xinjun means that he wants to declare the
default namespace as no value, e.g., xmlns="".
Anne
On 7/23/07, Xinjun Chen <[EMAIL PROTECTED]> wrote:
> Hi Chinthaka,
>
> I have an element
>
>bValue
> .
> I have another element which is created by another OMStaxBuilder.
is
> unqualified. Now I need to add to as a child of but I want
to
> remove the namespace in and make unqualified.
>
> I tried the AXIOM API to undeclare the default namespace of but
failed.
> I can only change the default namespace to another value but not empty
> string, i.e., I cannot undeclare it.
>
>
> Regards,
> Xinjun
>
>
> On 7/23/07, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > What did u mean by undeclare? If you point me what you want with some
> > code, perhaps I can answer better.
> >
> > Thanks,
> > Chinthaka
> >
> > Xinjun Chen wrote:
> > > Hi Axis2 Developers,
> > >
> > > Is it possible to undeclare a default namespace from an OMElement in
> AXIOM?
> > > I tried several ways but failed to undeclare a default namespace.
Could
> > > anyone point me a way out?
> > > Thanks.
> > >
> > > Regards,
> > > Xinjun
> > >
> > > -- Forwarded message --
> > > From: *Xinjun Chen* <[EMAIL PROTECTED] >
> > > Date: Jul 19, 2007 12:54 PM
> > > Subject: [AXIOM] Undeclare default namespace
> > > To: [EMAIL PROTECTED]
> > >
> > >
> > > Hi,
> > >
> > > I have some problem undeclaring the default namespace in an
OMElement.
> > > I have tried the following three ways but all failed. The default
> > > namespace is still in the OMElement.
> > >
> > > #1:
> > > OMElement reqElement = ;
> > > reqElement.declareDefaultNamespace ("");
> > >
> > > #2:
> > > OMElement reqElement = ;
> > > reqElement.declareNamespace("", "");
> > >
> > > #3:
> > > OMElement reqElement = ;
> > > OMFactory omFactory = reqElement.getOMFactory();
> > > OMNamespace ns = omFactory.createOMNamespace("", "");
> > > reqElement.declareNamespace(ns);
> > >
> > > Could anyone point me out what I can do to undeclare the default
> > > namespace in AXIOM? Thanks for your help in advance.
> > >
> > > Regards,
> > > Xinjun
> >
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.4.3 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> >
> iD8DBQFGo5JvjON2uBzUhh8RAlM6AJoDKg+9UJTRdIVIDgwMgrtIkcvyZQCgmVss
> > gisWSWkZr/pLyS9lRjOPGjY=
> > =zx5V
> > -END PGP SIGNATURE-
> >
> >
> -
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-2981) with JAXBRI databinding it generates the java classes in the wrong namespace
[ https://issues.apache.org/jira/browse/AXIS2-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515623 ] Denis Rachal commented on AXIS2-2981: - I believe this is similar, related or a duplicate of https://issues.apache.org/jira/browse/AXIS2-2952 This issue has attached a WSDL to duplicate the problem. If you need more info, please let me know. Denis > with JAXBRI databinding it generates the java classes in the wrong namespace > > > Key: AXIS2-2981 > URL: https://issues.apache.org/jira/browse/AXIS2-2981 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: databinding >Affects Versions: 1.2 > Environment: Windows 2000, eclipse 3.2 >Reporter: Amit Kumar Banerjee >Assignee: Amila Chinthaka Suriarachchi > > When -d jaxbri is specified with wsdl2java , it generates all the java > classes in the target namespace of the first .xsd it encounters rather then > generating the classes in there respective namespace specified -- 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-3007) RESTful services invocation self induces Input Stream Closed error
[
https://issues.apache.org/jira/browse/AXIS2-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515620
]
Deepal Jayasinghe commented on AXIS2-3007:
--
Hi Keith,
Please go ahead , and make sure you do not break any existing stuff.
Thanks
Deepal
> RESTful services invocation self induces Input Stream Closed error
> --
>
> Key: AXIS2-3007
> URL: https://issues.apache.org/jira/browse/AXIS2-3007
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
>Affects Versions: 1.2
> Environment: Windows 2000, Eclipse IDE
>Reporter: Jason Kania
>Assignee: Keith Godwin Chapman
> Attachments: patch.txt
>
>
> When making REST GET calls to an API, Axis 2 core sets its input stream to
> null and then complains later that its stream has been closed. The following
> partial stack trace demonstrates the problem.
> ApplicationXMLBuilder.processDocument(InputStream, String, MessageContext)
> line: 49
> TransportUtils.createSOAPMessage(MessageContext, InputStream, String) line:
> 130
> RESTUtil.processURLRequest(MessageContext, OutputStream, String) line: 98
> AxisServlet$ProcessRESTRequest.processURLRequest() line: 776
> AxisServlet.doGet(HttpServletRequest, HttpServletResponse) line: 238
> AxisServlet(HttpServlet).service(HttpServletRequest, HttpServletResponse)
> line: 707
> AxisServlet(HttpServlet).service(ServletRequest, ServletResponse) line: 820
> ServletHolder.handle(ServletRequest, ServletResponse) line: 487
> ...
> In RESTUtil, method processURLRequest, the following call is made on line 98
> soapEnvelope = TransportUtils
> .createSOAPMessage(msgContext, null, contentType);
> where the null is supposed to be the input stream
> Thus, when line 49 of ApplicationXMLBuilder in method processDocument is
> encountered,
> PushbackInputStream pushbackInputStream = new
> PushbackInputStream(inputStream);
> where inputStream is null,
> the exception "java.io.IOException: Stream closed" is generated once the
> empty stream is read at line 51
> of ApplicationXMLBuilder:
>if ((b = pushbackInputStream.read()) > 0) {
> For straight Axis use, this issue is a blocker, but I have worked around the
> problem by filtering empty get methods at the servlet level and am populating
> them with content for now.
--
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-2961) FastInfoset build failure (unit test) in JDK 1.4
[ https://issues.apache.org/jira/browse/AXIS2-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deepal Jayasinghe reassigned AXIS2-2961: Assignee: Davanum Srinivas (was: Deepal Jayasinghe) Hi Dims, I wont be able to upload the jar file so could you please have a look at this. Thanks Deepal > FastInfoset build failure (unit test) in JDK 1.4 > > > Key: AXIS2-2961 > URL: https://issues.apache.org/jira/browse/AXIS2-2961 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: modules >Affects Versions: nightly > Environment: JDK 1.4.* >Reporter: Sanjaya Karunasena >Assignee: Davanum Srinivas >Priority: Critical > Attachments: FastInfoset-1.1.8.pom, patch-jdk1.4 > > > With JDK 1.4, FastInfoset jar version 1.1.* should be used. Maven2 script > need to be modified to achieved 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] Commented: (AXIS-2682) wsdl2Java generates invalid empty string namespaces
[ https://issues.apache.org/jira/browse/AXIS-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515612 ] Christoph Ludwig commented on AXIS-2682: I realized after submitting the issue report that the attribute xmlns="" is used to bring the elements back into the global namespace in case an outer element changed the default namespace and can be certainly valid. Thus, the first part of my report was in fact misleading, sorry. The real problem is, though, that in my example both the data and the length element do not belong to the global namespace but to "http://www.textgrid.de/tests/bytearray/";. (By accident, I submitted the report before I was finished, therefore this is mentioned in the first comment only.) So the subject of this issue should rather read "WSDL2Java spuriously puts complex type members in the global namespace". And that *is* a bug, I think... > wsdl2Java generates invalid empty string namespaces > --- > > Key: AXIS-2682 > URL: https://issues.apache.org/jira/browse/AXIS-2682 > Project: Axis > Issue Type: Bug > Components: WSDL processing >Affects Versions: 1.4 > Environment: Eclipse 3.2 on Mac OS 10.4.10 (Intel) >Reporter: Christoph Ludwig > Attachments: bytearray.wsdl > > > I generated with WSDL2Java a service skeleton and client stubs for the > attached WSDL which I used for interoperability tests. When I investigated > errors, I found the following in the generated SOAP request: > > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > >http://www.textgrid.de/tests/bytearray/";> > SGVsbG8gV29ybGQh > 12 > > > > Note the empty namespaces in the data and length elements. The W3C > recommendation "Namespaces in XML 1.0" states explicitly: "The empty string, > though it is a legal URI reference, cannot be used as a namespace name" > (http://www.w3.org/TR/xml-names/#iri-use). -- 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-3019) JiBXDataSource looses problem details when wrapping an exception
JiBXDataSource looses problem details when wrapping an exception Key: AXIS2-3019 URL: https://issues.apache.org/jira/browse/AXIS2-3019 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: databinding Affects Versions: nightly Reporter: Dennis Sosnoski Assignee: Dennis Sosnoski Exceptions thrown during marshalling are wrapped, first in a JiBXException and then in an XMLStreamException. When stack trace details are output, such as on server errors sent back to the client, the original exception information is then missing. It appears the main problem is the XMLStreamException not chaining to the wrapped exception, but this can be partially addressed by adding the original exception message to the JiBXException message, which *is* printed in the stack trace. -- 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]
