[jira] Commented: (AXIS2-4337) Missing org.apache.axis2.transport.tcp.TCPTransportSender into Axis2 1.5 WAR

[Glen Daniels (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835315#action_12835315
 ] 

Glen Daniels commented on AXIS2-4337:
-

Hi Norbert - you can go to 
http://www.apache.org/dist/ws/commons/transport/1_0_0/ and grab the TCP 
transport jar there.  Drop it into your repository under transports/ and you 
should be all set.

Moving forward we're continuing to release the TCP transport as an add-on, but 
won't enable it by default.


> Missing org.apache.axis2.transport.tcp.TCPTransportSender into Axis2 1.5 WAR
> 
>
> Key: AXIS2-4337
> URL: https://issues.apache.org/jira/browse/AXIS2-4337
> Project: Axis2
>  Issue Type: Bug
>Affects Versions: 1.5, nightly
>Reporter: Dobri Kitipov
>Assignee: Glen Daniels
>
> Hi everybody,
> I found out that we are missing the 
> org.apache.axis2.transport.tcp.TCPTransportSender class into the 
> distribution. You can check the impact pretty easy. You should go and modify 
> the axis2\WEB-INF\conf\axis2.xml and uncomment the:
>  class="org.apache.axis2.transport.tcp.TCPTransportSender"/>
> Deploy the axis2-1.5-war in Tomcat.
> Then when you start the server you will get the following 
> java.lang.ClassNotFoundException: 
> org.apache.axis2.transport.tcp.TCPTransportSender:
> [ERROR] org.apache.axis2.transport.tcp.TCPTransportSender 
> org.apache.axis2.deployment.DeploymentException: 
> org.apache.axis2.transport.tcp.TCPTransportSender at 
> org.apache.axis2.deployment.AxisConfigBuilder.processTransportSenders(AxisConfigBuilder.java:694)
>  at 
> org.apache.axis2.deployment.AxisConfigBuilder.populateConfig(AxisConfigBuilder.java:121)
>  at 
> org.apache.axis2.deployment.DeploymentEngine.populateAxisConfiguration(DeploymentEngine.java:707)
>  at 
> org.apache.axis2.deployment.WarBasedAxisConfigurator.(WarBasedAxisConfigurator.java:157)
>  at 
> org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:525)
>  at org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:443) at 
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1139)
>  at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:966) 
> at 
> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3956)
>  at org.apache.catalina.core.StandardContext.start(StandardContext.java:4230) 
> at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
>  at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740) 
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544) at 
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:927) 
> at 
> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:890) 
> at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492) at 
> org.apache.catalina.startup.HostConfig.start(HostConfig.java:1150) at 
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
>  at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022) at 
> org.apache.catalina.core.StandardHost.start(StandardHost.java:736) at 
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at 
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at 
> org.apache.catalina.core.StandardService.start(StandardService.java:448) at 
> org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at 
> org.apache.catalina.startup.Catalina.start(Catalina.java:552) at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>  at java.lang.reflect.Method.invoke(Method.java:585) at 
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at 
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433) Caused by: 
> java.lang.ClassNotFoundException: 
> org.apache.axis2.transport.tcp.TCPTransportSender at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1386)
>  at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1232)
>  at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at 
> java.lang.Class.forName0(Native Method) at 
> java.lang.Class.forName(Class.java:164) at 
> org.apache.axis2.util

Board reports for January (WS and Axis)

[Glen Daniels]

Hi all:

I've put a template board report in place for January [1].  Both the new Axis
PMC and the Web Services PMC will be reporting.  I'll write up the Axis PMC
report directly, describing the split and that we're still in the midst of
infra discussions for project setup.

The WS report will cover the last quarter of 2009, so if you as project
leads/devs have anything to contribute, please add it to the wiki page.  I've
started and will fill in more in the next few days.

I'll plan to submit this report by EOD Friday for the board meeting next
week.  Please try to get any info in before then.

Thanks,
--Glen

[1] http://wiki.apache.org/ws/ReportForJan2010

[ANNOUNCE] Axis Top Level Project!

[Glen Daniels]

Hi all:

Just wanted to officially (and a bit belatedly) announce that as of the
December board meeting, we've agreed to create a new Top Level Project for
Axis1, Axis2, all the modules (i.e. Rampart, Sandesha, Kandua, Savan), and
the commons transports.  In other words, everything that has to do with Axis
will now live under "axis.apache.org" instead of "ws.apache.org".

I'll follow up with a more detailed note in a day or two, including a FAQ and
descriptions of the logistics.  We're going to do our best to make sure that
the community is disrupted as little as possible during the transition, and
you'll get warning before we do the actual moves of things like SVN and the
mailing lists.

I'm going to temporarily be the chair for both projects.  The rest of the
subprojects under Web Services are going to be reviewed over the next few
months and we'll decide their dispositions - the plan is basically to promote
the active ones to TLPs, and retire the inactive ones to the Attic.  It's
possible that the WS project itself may remain to house a few subprojects
into the future, or that it will disappear after everything has been moved.
Stay tuned.  In the meanwhile, business as usual for all the non-Axis projects.

This is a great step forward towards focusing the development effort and
community around Axis, and thanks to everyone who helped to discuss and vote
upon this resolution over the past year or so.

Regards,
--Glen

[jira] Commented: (AXIS2-2883) CLOSE_WAIT slowly building up over the period of time.

[Glen Daniels (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784044#action_12784044
 ] 

Glen Daniels commented on AXIS2-2883:
-

Hi Brecht:

I did not actually test this with https, so it is technically possible there's 
still an issue there... I won't likely be able to set up a harness to test with 
for a few days.  Let us know if you see further symptoms.

--Glen

> CLOSE_WAIT slowly building up over the period of time.
> --
>
> Key: AXIS2-2883
> URL: https://issues.apache.org/jira/browse/AXIS2-2883
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: client-api
>Affects Versions: 1.1
> Environment: Operating System : Solaris 
> Axis2 Version : 1.1
> Application Server : weblogic 8.1 SP6
> Using with Cocoon and weblogic DSP
>Reporter: Lakshmanan Venkatachalam
>Assignee: Glen Daniels
>Priority: Critical
> Fix For: 1.5.1
>
>
> I am experiencing theconstant increase in close wait in the production 
> environment over the period 7 days. 
> We are using Synchronous webservices and we are calling two webservices 24 
> times every day. We have allocated the maximum of 1.5 GB per application 
> instance and we have two application instances. We are utilizing maximum of 
> 250 - 300 MB in average. So Full GC never runs in our environment.
> It seems like the client API ServiceClient.java is not cleaning up the 
> resources associated with this component. We are creating the new 
> ServiceClient component on every call we have for webservices. Though we have 
> called the cleanup() method at the end of every call to the webservices. At 
> times its not getting executed.
> But when we force garabage collection from the application, it was able to 
> clear all the CLOSE_WAIT components. Since we have similar cleanup() call on 
> finalize() method, it is able to do proper clean up when GC is collecting 
> these objects.
> Forcing GC cannot be a solution, I like to hear from axis2 experts on how we 
> can resolve this problem properly and what could be the cause for this 
> happening.
> Below is our client code for your reference.
> private WebServiceResponse invokeWebservice(OMElement inputElement,
>   Options options) throws WebServiceInvokerException {
>   ServiceClient serviceClient = null;
>   try {
>   serviceClient = new ServiceClient();
>   serviceClient.setOptions(options);
>   // This following line of code is used when we are using
>   // WS-Addressing. User has to make sure the addressing 
> MAR file in
>   // class path before enable the following line of code
>   //
>   // serviceClient.engageModule(new QName(
>   // org.apache.axis2.Constants.MODULE_ADDRESSING));
>   // Invoking synchrounous webservice
>   //
>   OMElement result = 
> serviceClient.sendReceive(inputElement);
>   
>   OMNode firstOMChild = result.getFirstOMChild();
>   // Conver the OMelements to XML String
>   //
>   Writer stringWriter = new StringWriter();
>   firstOMChild.serialize(stringWriter);
> serviceClient.cleanup();
>   stringWriter.flush();
>   // Return the Axis2WebserviceResponse
>   //
>   return new 
> Axis2WebServiceResponse(stringWriter.toString());
>   } catch (AxisFault afe) {
>   throw new WebServiceInvokerException(afe);
>   } catch (XMLStreamException xse) {
>   throw new WebServiceInvokerException(xse);
>   } catch (IOException ioe) {
>   throw new WebServiceInvokerException(ioe);
>   } finally {
>   try {
>   serviceClient.cleanup();
> serviceClient=null;
>   } catch (AxisFault axisFault) {
>   //
>   }
>   }
>   }
> }
> options are:
> Options options = new Options();
>   options.setTo(targetEPR);
>   options.setUseSeparateListener(false);
> 

Re: [Axis2] Re: svn commit: r835113 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/ServiceClient.java

[Glen Daniels]

Hi Bill, Andreas, all:

Just circling around to this.  Thanks, Andreas, for your catch here.  The
default for AUTO_OPERATION_CLEANUP was definitely intended to be true,
specifically to make avoiding the connection starvation problem as effortless
(and backwards compatible) as possible.  Please revert that part of the
change if you would, Roy?

ServiceClients (and by association Stubs) are *not* meant to be thread-safe.
 There were a number of discussions about this in 2006, 2007, 2008... if the
docs aren't crystal-clear on this then I definitely agree we should fix them.

Re: the JavaDoc on cleanupTransport(), that's my bad - we do NOT build() the
full Axiom tree by default with AUTO_OPERATION_CLEANUP, only when
options.isCallTransportCleanup() is true.  The build() actually happens in
sendReceive() and the JavaDoc discussing it should be there, not on
cleanupTransport().  I apologize for not neatening that up when I made the fix.

I'd like to open a separate discussion as to how to make this whole cleanup
issue work *right* for Axis2 1.6 (*), and deprecate the ways we've been doing
it up until now, but for now we have three options - 1) use
AUTO_OPERATION_CLEANUP by default which cleans up the *last* OperationContext
each time you make a new one, 2) use options.setCallTransportCleanup(), which
cleans up the *current* OperationContext at the end, accepting the build()
limitations, and 3) shut off both of the above and clean up manually.

Thanks,
--Glen

(*) IMHO there should be a way to have Axiom auto-trigger a cleanup if we
reach the end of the inputStream, and if we don't ever read to the end for a
given operation, we'll still need some automatic mechanism involving timeouts
or heuristics

Bill Nagy wrote:
> Ignoring the performance degradation for a moment, the
> AUTO_OPERATION_CLEANUP feature had removed thread-safety from the
> ServiceClient (i.e. if two threads invoke
> serviceclient.createClient(...), there is the distinct possibility that,
> before Roy's modification, the code would have cleaned up the transport
> before the first invoking thread had finished.)
> 
> If the ServiceClient is not meant to be thread-safe, then this needs to
> be explicitly stated in the JavaDoc and the JAX-WS code will need to be
> reworked to take this into account.
> 
> If the ServiceClient is supposed to be thread-safe, then either the
> default should remain as Roy has set it (i.e. to be 'false') or the
> cleanup code needs to be rewritten so as not to cause threading issues.
> 
> -Bill
> 
> 
> On Thu, 2009-11-12 at 17:44 -0600, Roy Wood wrote:
>> Andreas, 
>> Yes, I agree...thanks for the correction. I went back and did a quick
>> search on AUTO_OPERATION_CLEANUP and didn't find any intent on what
>> the 
>> actual default should be, other than the original code using a default
>> of 'true'. 
>>
>> This property came to our attention when we ran into a threading
>> problem in one of our test cases. By setting the default to false,
>> thus disabling the call to 
>> 'cleanupTransport' in createClient, the threading problem disappeared.
>> I'm also a bit concerned about the performance warning in
>> cleanupTransport 
>> javadocs. For that reason, as well as, providing a degree backwards
>> compatability,  I would like to propose that the default for this
>> property be 'false'. 
>>
>> Roy A. Wood, Jr.
>> WebSphere Development - Web Services
>> wood...@us.ibm.com
>> 512-286-9307  T/L:363-9307
>> 11501 Burnet Road,  Austin TX   78758 (Internal ZIP: 9372) 
>>
>>
>>
>> Re: svn commit: r835113
>> - 
>> /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/ServiceClient.java
>>
>> Andreas
>> Veithen 
>> to: 
>> axis-dev 
>> 11/12/2009 03:30 PM
>>
>> Cc: 
>> Glen
>> Daniels
>>
>> Please respond to
>> axis-dev 
>>
>>
>>
>>
>>
>>
>> __
>>
>>
>>
>> That is not correct. The entire Javadoc of the cleanupTransport method
>> was written before the introduction of the AUTO_OPERATION_CLEANUP
>> property. It only refers to "callTransportCleanup", which is a
>> different property. Since the AUTO_OPERATION_CLEANUP feature is
>> something that has been recently introduced by Glen for the 1.5.1
>> release, it would be good to start a discussion to get his feedback if
>> you think that the default value should be different for the next
>> release.
>>
>> Andreas
>>
>> On Wed, Nov 11, 2009 at 23:54,   wrote:
>>> Author:

[RESOLUTION] Axis2 TLP

[Glen Daniels]

Hi folks:

The VOTE on the Axis2 TLP proposal has passed with many +1s and no -1s.

I'll hold off for a few days before submitting it to the board, to give
others a chance to sign themselves up for the new PMC.

After the resolution passes, we'll need to figure out the logistics of the
mailing lists, source code repo, website, Nexus, Hudson, etc.  I'll plan to
make the initial committers list the same as the PMC list, and if any
committer from the WS project ends up wanting to join Axis2 after that, we'll
just make it happen with no vote necessary.  In other words, all WS
committers are "grandfathered" in as Axis2 committers if they want to be.

Thanks to everyone for this step in the right direction!

Regards,
--Glen

[jira] Resolved: (AXIS2-4404) MessageContext.getEnvelope() returning NoSuchElementException

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-4404.
-

Resolution: Invalid

Closing this for now, since we've had no test case or stack trace since the 
last comment in August.  Ramya, if you are still having this problem, please 
feel free to reopen the issue and PLEASE give us more information so we can 
reproduce it if so.  Thanks.


> MessageContext.getEnvelope() returning NoSuchElementException
> -
>
> Key: AXIS2-4404
> URL: https://issues.apache.org/jira/browse/AXIS2-4404
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: adb, client-api, codegen, Tools, wsdl
>Affects Versions: 1.4.1
> Environment: Axis2 1.4.1, Tomcat5.5, JDK1.5, Eclipse 3.4.2
>Reporter: Ramya
>Priority: Blocker
> Fix For: 1.6
>
>   Original Estimate: 0.02h
>  Remaining Estimate: 0.02h
>
> Hello,
> I have a serious issue with getting hold of the incoming SOAP Envelope from 
> MessageContext.
> The reason I need the envelope is to be able to get the SOAP Header section, 
> read data from it, create a new header section for the response, populate it 
> in the response Header along with the Soap body data.
> I am doing this in the Skeleton.
> The following is the piece of code that throws a NoSuchElementException.
> The wierd thing is that the error happens only on our test server (Windows 
> 2003- SP2 machine with jre1.5.0_13). On our dev server (Windows XP-SP3 
> running jdk1.5.0_06) here we dont get this error.
> SOAPEnvelope envelope = 
> MessageContext.getCurrentMessageContext().getEnvelope();
> MessageContext.getCurrentMessageContext().getEnvelope().serialize(System.out);
> System.out.println(envelope);
> SOAPHeader header = envelope.getHeader();
> if (header != null)
>  wfContextElem = 
> header.getFirstChildWithName(BntService2007Stub.WFContext.MY_QNAME);
>  
> MessageContext inMsgContext = MessageContext.getCurrentMessageContext();
>  OperationContext operationContext =   inMsgContext.getOperationContext();
>  MessageContext outMessageContext = 
> operationContext.getMessageContext(WSDLConstants.MESSAGE_LABEL_IN_VALUE);
>  outMessageContext.setEnvelope(createSOAPEnvelope());
>   System.out.println("outenv in 
> outcontext="+outMessageContext.getEnvelope());
> response = ServiceDAO.getResponse(...);
>  OMElement omElement = 
> response.getOMElement(GetBankerNotesResponse.MY_QNAME,OMAbstractFactory.getOMFactory());
> String omElementString = 
> omElement.getBuilder().getDocumentElement().toStringWithConsume();
> System.out.println("Response xml in skeleton="+omElementString);  
> private SOAPEnvelope createSOAPEnvelope() {   
> SOAPFactory fac = OMAbstractFactory.getSOAP11Factory();   
> SOAPEnvelope envelope = fac.getDefaultEnvelope();
> OMNamespace xsi = 
> fac.createOMNamespace("http://www.w3.org/2001/XMLSchema-instance";, "xsi");
> envelope.declareNamespace(xsi);
> return envelope;
> }
> Your quick reply is highly appreciated as this is a Blocker and we are not 
> able to proceed further.
> Thanks!
> wsnewbie

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AXIS2-4337) Missing org.apache.axis2.transport.tcp.TCPTransportSender into Axis2 1.5 WAR

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels updated AXIS2-4337:


Priority: Major  (was: Blocker)

1) This isn't really a "blocker", so downgrading.

2) Here's my proposal for dealing with this.  First, let's remove the TCP 
transport section from the default axis2.xml entirely, and replace it with a 
comment describing how to find the transports project, and referring the reader 
to the transport documentation.  At that point we can close this issue and open 
another one to make sure we augment each transport release (transport release? 
when's that? :)) with the correct documentation.


> Missing org.apache.axis2.transport.tcp.TCPTransportSender into Axis2 1.5 WAR
> 
>
> Key: AXIS2-4337
> URL: https://issues.apache.org/jira/browse/AXIS2-4337
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>Affects Versions: 1.5, nightly
>    Reporter: Dobri Kitipov
>Assignee: Glen Daniels
>
> Hi everybody,
> I found out that we are missing the 
> org.apache.axis2.transport.tcp.TCPTransportSender class into the 
> distribution. You can check the impact pretty easy. You should go and modify 
> the axis2\WEB-INF\conf\axis2.xml and uncomment the:
>  class="org.apache.axis2.transport.tcp.TCPTransportSender"/>
> Deploy the axis2-1.5-war in Tomcat.
> Then when you start the server you will get the following 
> java.lang.ClassNotFoundException: 
> org.apache.axis2.transport.tcp.TCPTransportSender:
> [ERROR] org.apache.axis2.transport.tcp.TCPTransportSender 
> org.apache.axis2.deployment.DeploymentException: 
> org.apache.axis2.transport.tcp.TCPTransportSender at 
> org.apache.axis2.deployment.AxisConfigBuilder.processTransportSenders(AxisConfigBuilder.java:694)
>  at 
> org.apache.axis2.deployment.AxisConfigBuilder.populateConfig(AxisConfigBuilder.java:121)
>  at 
> org.apache.axis2.deployment.DeploymentEngine.populateAxisConfiguration(DeploymentEngine.java:707)
>  at 
> org.apache.axis2.deployment.WarBasedAxisConfigurator.(WarBasedAxisConfigurator.java:157)
>  at 
> org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:525)
>  at org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:443) at 
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1139)
>  at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:966) 
> at 
> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3956)
>  at org.apache.catalina.core.StandardContext.start(StandardContext.java:4230) 
> at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
>  at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740) 
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544) at 
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:927) 
> at 
> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:890) 
> at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492) at 
> org.apache.catalina.startup.HostConfig.start(HostConfig.java:1150) at 
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
>  at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022) at 
> org.apache.catalina.core.StandardHost.start(StandardHost.java:736) at 
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at 
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at 
> org.apache.catalina.core.StandardService.start(StandardService.java:448) at 
> org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at 
> org.apache.catalina.startup.Catalina.start(Catalina.java:552) at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>  at java.lang.reflect.Method.invoke(Method.java:585) at 
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at 
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433) Caused by: 
> java.lang.ClassNotFoundException: 
> org.apache.axis2.transport.tcp.TCPTransportSender at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1386)
>  at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:

Re: [ApacheCon] Axis2 JIRA Walkthrough at 5:30PM *PST*

[Glen Daniels]

Uh.. that's PACIFIC time... sorry for the confusion!

Glen Daniels wrote:
> Hey y'all:
> 
> Those of us here at ApacheCon, let's grab a table in the main ballroom in
> order to do some JIRA bashing (prioritizing, targeting, assigning) at 5:30PM
> today, after Nandana's talk ending the WS track.
> 
> For those not physically here, we'll hop on #apache-axis.  I should think
> we'll spend an hour or so.
> 
> Thanks,
> --Glen

[ApacheCon] Axis2 JIRA Walkthrough at 5:30PM EST

[Glen Daniels]

Hey y'all:

Those of us here at ApacheCon, let's grab a table in the main ballroom in
order to do some JIRA bashing (prioritizing, targeting, assigning) at 5:30PM
today, after Nandana's talk ending the WS track.

For those not physically here, we'll hop on #apache-axis.  I should think
we'll spend an hour or so.

Thanks,
--Glen

[ANNOUNCE] Axis2 1.5.1

[Glen Daniels]

Hi all:

The Apache Axis2 team is pleased to announce the release of Axis2 version 1.5.1.

Major Changes Since 1.5:

*  Fix for the dreaded "CLOSE_WAIT" problem (JIRA issues 935, 2883, etc).
We now share an instance of HTTPClient across each ConfigurationContext (i.e.
each Axis2 server or ServiceClient) - connection reuse is now automatic. This
means the REUSE_HTTP_CLIENT flag is no longer necessary or useful, nor is
creating your own MultithreadedHttpConnectionManager.  We also now throw a
useful exception after 30 seconds if you DO run into connection starvation
issues.

* Transport deployer is now actually functional, and getListenerManager()
in ConfigurationContext now creates a new LM if there isn't one already.

* Fix for AXIS2-4034, module versions now support real versions like "1.5.1"

* NPE problem (see AXIS2-4114) fixed in MessageContext while retrieving
policy.

You can find the new version at the usual location:
  http://ws.apache.org/axis2

(please note that it may be an hour or two before all the mirrors update)

Please report any issues via JIRA:
  http://issues.apache.org/jira/browse/AXIS2.

As always, we welcome any and all feedback at:
  axis-dev@ws.apache.org - for developer-related questions/concerns
  axis-u...@ws.apache.org - for general questions, usage, etc.

Also, don't forget that ApacheCon 2009 is around the corner, November 2-6 in
Oakland CA!  Many of the Axis2 / Apache Web Services developers will be on
hand, and we're running a track day for the project on Thursday.  We hope to
see you there.

Sign up today at http://us.apachecon.com/c/acus2009/

Thanks for your interest in Apache Axis2!

--Glen Daniels

Re: [VOTE] Axis2 1.5.1 - final vote (I hope :) )

[Glen Daniels]

I'm going to call this VOTE, with eight binding +1s, two non-binding +1s, and
no -1s.  Will post the release later today and update the website.

Tom, we'll fix the issue you note below in the next release.

Thanks,
--Glen

Tom Jordahl wrote:
> +1 (binding) with the following observation/bug:
> 
> The README.txt in the bin distro has the instructions for bootstrapping the 
> maven plugins but the README-std-src.txt in the source distro does NOT have 
> these instructions, which is bad.  The other thing that is bad is there is no 
> build.xml in the top level to perform option 1, so you have to do option 2.
> 
> =
> IMPORTANT: the *first* time you build a given version of Axis2, you will not
> be able to do a regular "mvn install" from the top level - this is because
> we have a couple of custom Maven plugins that (due to some dependency-
> resolution issues in Maven) must be built and installed in your local
> repository before a build will succeed.  This means you need to do one
> of the following:
> 
>   1) Use ant (http://ant.apache.org) to build the first time.  There is
>  a build.xml at the top level which automatically builds the plugins
>  first and then runs a regular "mvn install".
>  
>   2) Manually "mvn install" both of the plugins in the following places:
>  
>  modules/tool/axis2-mar-maven-plugin
>  modules/tool/axis2-aar-maven-plugin
> =========
> 
> Tom Jordahl
> 
> -Original Message-
> From: Glen Daniels [mailto:g...@thoughtcraft.com] 
> Sent: Tuesday, October 20, 2009 10:49 AM
> To: Axis-Dev
> Subject: [VOTE] Axis2 1.5.1 - final vote (I hope :) )
> 
> OK, after adding the default 30-second timeout for connection starvation
> issues, and confirming that Rampart now works fine with 1.5.1, let's try this
> one more time.  Please VOTE on releasing 1.5.1 - then we can get moving on 
> 1.6!
> 
> 
> You can find the distribution files in here:
> 
> http://people.apache.org/~gdaniels/stagingRepo/org/apache/axis2/distribution/1.5.1/
> 
> And the M2 repository with everything is at:
> 
> http://people.apache.org/~gdaniels/stagingRepo
> 
> The SVN tag is:
> 
> http://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.5.1RC3
> 
> ...and I'll add a proper "v1.5.1" tag as soon as this release goes final.
> 
> Please offer your VOTE (and indicate binding/non-binding).
> 
> Here's my +1 (binding).
> 
> Many thanks,
> --Glen

[VOTE] Axis2 1.5.1 - final vote (I hope :) )

[Glen Daniels]

OK, after adding the default 30-second timeout for connection starvation
issues, and confirming that Rampart now works fine with 1.5.1, let's try this
one more time.  Please VOTE on releasing 1.5.1 - then we can get moving on 1.6!


You can find the distribution files in here:

http://people.apache.org/~gdaniels/stagingRepo/org/apache/axis2/distribution/1.5.1/

And the M2 repository with everything is at:

http://people.apache.org/~gdaniels/stagingRepo

The SVN tag is:

http://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.5.1RC3

...and I'll add a proper "v1.5.1" tag as soon as this release goes final.

Please offer your VOTE (and indicate binding/non-binding).

Here's my +1 (binding).

Many thanks,
--Glen

[jira] Created: (AXIS2-4526) Modules should have an easy way to specify Axis2 version compatibility

[Glen Daniels (JIRA)]

Modules should have an easy way to specify Axis2 version compatibility
--

 Key: AXIS2-4526
 URL: https://issues.apache.org/jira/browse/AXIS2-4526
 Project: Axis 2.0 (Axis2)
  Issue Type: New Feature
  Components: modules
Reporter: Glen Daniels


I don't think this is already there, but correct me if I'm wrong.

We could use the capability to express Axis2 version compatibility in the 
module.xml file.  Something like:


 ...


Where you could specify "version" for an exact version, or "version+" for any 
version including or after the specified one.

This would prevent people from deploying modules that rely on later Axis2 
features on earlier versions.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[axis2] Status on Axis2 1.5.1 and Rampart 1.5

[Glen Daniels]

Hi folks!

OK, so here are the results of my weekend investigations.  The lockup when
running the Rampart 1.5 tests with Axis2 1.5.1 was due to http connection
starvation.  I've fixed two issues and everything works now, but I'd like to
respin both Axis2 1.5.1 and Rampart 1.5 as a result.  Details below.

First, a quick summary of a major change in Axis2 1.5.1 : we were formerly
creating new MultithreadedHTTPConenctionManagers all the time in the HTTP
sender code.  In typical usage you'd never see connection pool starvation
(since each new MHCM had a new pool), but two major problems occurred.  1)
Connection reuse wasn't really possible, and 2) we would eventually (in
high-volume situations) run into the OS limits for open sockets.  So I fixed
this so that 1.5.1 now re-uses a single MHCM for each ConfigurationContext,
which allows for sharing connections across ServiceClient instances.

The bigger problem *behind* the problem above is that users of the commons
HTTPClient library (like Axis2) need to call releaseConnection() on each and
every HTTPMethod after they are finished.  The
ServiceClient.cleanupTransport() call does this, but since we never told
people to call that explicitly, no one was in the habit of doing it.  A
number of bugs about connection starvation came up, and we put in the
Options.setCallTransportCleanup() option, which automatically calls
cleanupTransport() after each call, but at a cost - since we're releasing
connection resources you need to make sure you've read everything, which
means building the whole Axiom tree.  Bye-bye, streaming.  So I also added a
different connection cleanup option which automatically cleans up the *last*
operation as you're setting up the next one.

So, to make the Rampart story very short, the problem was this: a new
ServiceClient gets created to deal with SecureConversation interactions (see
STSClient.getServiceClient()).  This SC shares the same ConfigurationContext
with the outer (i.e. user) SC, so it shares a MHCM and a connection pool.
The problem is since the STS operations happen inside a user-level operation,
the record of the "last operation" gets overwritten, and as a result my
automatic cleanup mechanism can't catch both!  So we lose one connection each
time we go through the STS process, and that causes a hard lock.

SOLUTION


I did two things to fix this, both of which I think should be reflected in
the released code.  First, in Rampart, I added a call to
setCallTransportCleanup(true) in STSClient - this means that the STS
operations will be forced to build the complete Axiom tree (see above), but
solves the connection starvation issue.  Second, in Axis2, I added a default
30-second timeout while waiting for new connections - this doesn't change the
functionality at all, but it does mean that we can no longer get into
situations where the system just locks up forever.  With that change, we'll
now at least get an Exception if there's a starvation issue, which can then
be debugged.

Nandana/all, can you check what I did in Rampart and let me know if you
foresee any problems with it?  I'm going to respin Axis2 1.5.1 with this and
one other fix, and we should respin Rampart 1.5 as well.

Thoughts/comments?

Thanks,
--Glen

ApacheCon - who's around?

[Glen Daniels]

Hey folks!

So who is going to be at ApacheCon?  I'm hoping once again that we can get
some good work done on Axis2 and other WS projects while we're there.

What we work on will depend on who's there, so in the interest of planning
ahead, who's going to be around when?

I'm arriving on Tuesday, probably about noon, and will be there through the
rest of the week.

Thanks,
--Glen

Re: [VOTE] [axis2] Release Axis2 1.5.1 (take 2)

[Glen Daniels]

Hi all:

I'm currently seeing some build failures with Rampart and 1.5.1, which I'd
like to resolve before actually putting this out. :(

4350 does also seem pretty serious, and it's clearly a regression, so I'm
good with fixing that in 1.5.1 as well.

As such, I'm going to try and look into these items and re-spin the release
next week.  Argh.  Sorry for the inconvenience.

Thanks,
--Glen

Pétur Runólfsson wrote:
> Hi,
> 
> May I suggest that http://issues.apache.org/jira/browse/AXIS2-4350 be fixed 
> before the release?
> 
> The effect of this bug is that web services that use ADB and use a wsdl 
> provided by the user (not generated on the server) simply don't work at all. 
> The fix is simple, and can be found in a comment on the issue.
> 
> http://issues.apache.org/jira/browse/AXIS2-4471 seems to be a duplicate of 
> this bug.
> 
> Regards,
> 
> Pétur Runólfsson
> 
> From: Glen Daniels [g...@thoughtcraft.com]
> Sent: Wednesday, October 07, 2009 13:36
> To: axis-dev@ws.apache.org
> Subject: Re: [VOTE] [axis2] Release Axis2 1.5.1 (take 2)
> 
> Ping!  Please VOTE... or comment?
> 
> --G
> 
> Glen Daniels wrote:
>> Hi Axis Developers,
>>
>> After fixing the documentation and a few other small issues since the last
>> attempt at 1.5.1, I think we're ready to try again.  I've also addressed the
>> "forced build of Axiom" issue with the CLOSE_WAIT fix - we now by default
>> clean up the last operation context each time we build a new one inside
>> ServiceClient.
>>
>> While there may still be a few things we need to address (still waiting for
>> transports / Rampart / Sandesha for instance), I think it's important to get
>> this out ASAP since there were clearly some serious issues with 1.5 -
>> including the failed JavaDoc build and the persistent CLOSE_WAIT issues that
>> are fixed in 1.5.1.
>>
>> As a reminder, fixes include:
>>
>> *  Fix for the dreaded "CLOSE_WAIT" problem (JIRA issues 935, 2883, etc).
>> We now share an instance of HTTPClient across each ConfigurationContext (i.e.
>> each Axis2 server or ServiceClient) - connection reuse is now automatic. This
>> means the REUSE_HTTP_CLIENT flag is no longer necessary or useful, nor is
>> creating your own MultithreadedHttpConnectionManager.
>> * Transport deployer is now actually functional, and getListenerManager()
>> in ConfigurationContext now creates a new LM if there isn't one already.
>> * Fix for AXIS2-4034, module versions now support real versions like 
>> "1.5.1"
>> * NPE problem (see AXIS2-4114) fixed in MessageContext while retrieving
>> policy.
>> * Fix for JavaDoc build problem.
>>
>> I'd like to kick off a VOTE for the release, with the usual 72-hour window
>> for votes.
>>
>> You can find the distribution files in here:
>>
>> http://people.apache.org/~gdaniels/stagingRepo/org/apache/axis2/distribution/1.5.1/
>>
>> And the M2 repository with everything is at:
>>
>> http://people.apache.org/~gdaniels/stagingRepo
>>
>> The SVN tag is:
>>
>> https://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.5.1RC2
>>
>> ...and I'll add a proper "v1.5.1" tag as soon as this release goes final.
>>
>> Please offer your VOTE (and indicate binding/non-binding).
>>
>> Here's my +1 (binding).
>>
>> Many thanks,
>> --Glen
>>
> 
> The content of this e-mail, together with any of its attachments, is for the 
> exclusive and confidential use of the named addressee(s) and it may contain 
> legally privileged and confidential information and/or copyrighted material. 
> Any other distribution, use or reproduction without the sender's prior 
> consent is unauthorized and strictly prohibited. If you have by coincidence, 
> mistake or without specific authorization received this e-mail in error, 
> please notify the sender by e-mail immediately, uphold strict confidentiality 
> and neither read, copy, transfer, disseminate, disclose nor otherwise make 
> use of its content in any way and delete the material from your computer.
> 
> The content of the e-mail and its attachments is the liability of the 
> individual sender, if it does not relate to the affairs of Betware.
> Betware does not assume any civil or criminal liability should the e-mail or 
> it´s attachments be virus infected.

Re: [VOTE] [axis2] Release Axis2 1.5.1 (take 2)

[Glen Daniels]

Ping!  Please VOTE... or comment?

--G

Glen Daniels wrote:
> Hi Axis Developers,
> 
> After fixing the documentation and a few other small issues since the last
> attempt at 1.5.1, I think we're ready to try again.  I've also addressed the
> "forced build of Axiom" issue with the CLOSE_WAIT fix - we now by default
> clean up the last operation context each time we build a new one inside
> ServiceClient.
> 
> While there may still be a few things we need to address (still waiting for
> transports / Rampart / Sandesha for instance), I think it's important to get
> this out ASAP since there were clearly some serious issues with 1.5 -
> including the failed JavaDoc build and the persistent CLOSE_WAIT issues that
> are fixed in 1.5.1.
> 
> As a reminder, fixes include:
> 
> *  Fix for the dreaded "CLOSE_WAIT" problem (JIRA issues 935, 2883, etc).
> We now share an instance of HTTPClient across each ConfigurationContext (i.e.
> each Axis2 server or ServiceClient) - connection reuse is now automatic. This
> means the REUSE_HTTP_CLIENT flag is no longer necessary or useful, nor is
> creating your own MultithreadedHttpConnectionManager.
> * Transport deployer is now actually functional, and getListenerManager()
> in ConfigurationContext now creates a new LM if there isn't one already.
> * Fix for AXIS2-4034, module versions now support real versions like 
> "1.5.1"
> * NPE problem (see AXIS2-4114) fixed in MessageContext while retrieving
> policy.
> * Fix for JavaDoc build problem.
> 
> I'd like to kick off a VOTE for the release, with the usual 72-hour window
> for votes.
> 
> You can find the distribution files in here:
> 
> http://people.apache.org/~gdaniels/stagingRepo/org/apache/axis2/distribution/1.5.1/
> 
> And the M2 repository with everything is at:
> 
> http://people.apache.org/~gdaniels/stagingRepo
> 
> The SVN tag is:
> 
> https://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.5.1RC2
> 
> ...and I'll add a proper "v1.5.1" tag as soon as this release goes final.
> 
> Please offer your VOTE (and indicate binding/non-binding).
> 
> Here's my +1 (binding).
> 
> Many thanks,
> --Glen
> 

[jira] Resolved: (AXIS2-4163) ServiceClient - finalize() method calls super.finalize() too early

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-4163.
-

   Resolution: Fixed
Fix Version/s: 1.5.1
   1.6

Fixed on 1.5 branch and trunk.

> ServiceClient - finalize() method calls super.finalize() too early
> --
>
> Key: AXIS2-4163
> URL: https://issues.apache.org/jira/browse/AXIS2-4163
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: client-api
>Affects Versions: 1.4.1
>Reporter: Erik-Berndt Scheper
> Fix For: 1.6, 1.5.1
>
> Attachments: stacktrace.txt
>
>
> The finalize() method in ServiceClient.java incorrectly calls 
> super.finalize() before cleaning up:
> protected void finalize() throws Throwable {
> super.finalize();
> cleanup();
> }
> This leads to EJBClassLoader errors in GlassFish when the garbage collector 
> runs. To fix this, it should be changed to:
> // Manual finalizer chaining
> @Override protected void finalize() throws Throwable {
> try {
> // Finalize subclass state
> cleanup();
> } finally {
> super.finalize();
> }
> }
> See attached stack trace for details.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[VOTE] [axis2] Release Axis2 1.5.1 (take 2)

[Glen Daniels]

Hi Axis Developers,

After fixing the documentation and a few other small issues since the last
attempt at 1.5.1, I think we're ready to try again.  I've also addressed the
"forced build of Axiom" issue with the CLOSE_WAIT fix - we now by default
clean up the last operation context each time we build a new one inside
ServiceClient.

While there may still be a few things we need to address (still waiting for
transports / Rampart / Sandesha for instance), I think it's important to get
this out ASAP since there were clearly some serious issues with 1.5 -
including the failed JavaDoc build and the persistent CLOSE_WAIT issues that
are fixed in 1.5.1.

As a reminder, fixes include:

*  Fix for the dreaded "CLOSE_WAIT" problem (JIRA issues 935, 2883, etc).
We now share an instance of HTTPClient across each ConfigurationContext (i.e.
each Axis2 server or ServiceClient) - connection reuse is now automatic. This
means the REUSE_HTTP_CLIENT flag is no longer necessary or useful, nor is
creating your own MultithreadedHttpConnectionManager.
* Transport deployer is now actually functional, and getListenerManager()
in ConfigurationContext now creates a new LM if there isn't one already.
* Fix for AXIS2-4034, module versions now support real versions like "1.5.1"
* NPE problem (see AXIS2-4114) fixed in MessageContext while retrieving
policy.
* Fix for JavaDoc build problem.

I'd like to kick off a VOTE for the release, with the usual 72-hour window
for votes.

You can find the distribution files in here:

http://people.apache.org/~gdaniels/stagingRepo/org/apache/axis2/distribution/1.5.1/

And the M2 repository with everything is at:

http://people.apache.org/~gdaniels/stagingRepo

The SVN tag is:

https://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.5.1RC2

...and I'll add a proper "v1.5.1" tag as soon as this release goes final.

Please offer your VOTE (and indicate binding/non-binding).

Here's my +1 (binding).

Many thanks,
--Glen

[jira] Resolved: (AXIS2-4501) Documentation links on Axis2 1.4.1 page, left pane, are broken - Related to issue AXIS2-4497

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-4501.
-

Resolution: Fixed

> Documentation links on Axis2 1.4.1 page, left pane,  are broken - Related to 
> issue AXIS2-4497
> -
>
> Key: AXIS2-4501
> URL: https://issues.apache.org/jira/browse/AXIS2-4501
> Project: Axis 2.0 (Axis2)
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 1.4.1
>Reporter: Anand Sastry
>
> When I go to http://ws.apache.org/axis2/download/1_4_1/download.cgi and click 
> on the Documentation links on the left pane, they are broken.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AXIS2-4434) JavaDocs broken both on site and in distribution

[Glen Daniels (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12756892#action_12756892
 ] 

Glen Daniels commented on AXIS2-4434:
-

This was caused by the JAXWS metadata module, which added annotations that 
weren't reflected as dependencies in the documentation module - as such, the 
JavaDoc tool failed because of this:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6442982

I've corrected this on the trunk - am about to merge over to the 1.5 branch, 
then I'll update the website and see about respinning the 1.5 documentation 
release.

Will leave this open until that's done.


> JavaDocs broken both on site and in distribution
> 
>
> Key: AXIS2-4434
> URL: https://issues.apache.org/jira/browse/AXIS2-4434
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 1.5
>    Reporter: Dennis Sosnoski
>Assignee: Glen Daniels
>
> The online link to the JavaDocs is broken for 1.5. From page 
> http://ws.apache.org/axis2/ this link points at 
> http://ws.apache.org/1_5/api/index.html but this page does not exist.
> Furthermore, the axis2-1.5-docs.zip has only a frameless view of the 
> documentation, making it very difficult to find items and navigate.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (AXIS2-4497) axis2 1.4.1 download link is incorrect

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-4497.
-

Resolution: Fixed

Fixed, changes should be up shortly.

> axis2 1.4.1 download link is incorrect
> --
>
> Key: AXIS2-4497
> URL: https://issues.apache.org/jira/browse/AXIS2-4497
> Project: Axis 2.0 (Axis2)
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 1.4.1
>Reporter: Anand Sastry
>
> On the website http://ws.apache.org/axis2/download.cgi . There is a problem 
> with a few of the links :
> 1)If you click on 1.4.1 in the main panel,  it takes you to a page to 
> download 1.5. This is a significant issue as 1.4.1 cannot be downloaded.
> 2)The documentation links on the left panel are broken.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AXIS2-3919) Temp folder being filled with files. Running out of disk space.

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels updated AXIS2-3919:


Fix Version/s: 1.6

We've replaced the referenced code with a TempFileManager class that does two 
things - 1) puts all files for a particular instance of Axis2 into a specific 
subdirectory of tmp_file_dir, and 2) ensures that old directories are cleaned 
up each time a new instance starts.  This will solve the problem for the case 
where you're spinning up and down Axis2 instances... but not for a long running 
process (since the cleanup code is in a static block that gets initialized at 
JVM startup).

The right long-term solution is to periodically clean up the temporary files 
when they are no longer needed - I think if we just store references to them in 
the appropriate context objects, we should be able to clean them up when the 
contexts are destroyed.   I've targeted this for 1.6.

> Temp folder being filled with files. Running out of disk space.
> ---
>
> Key: AXIS2-3919
> URL: https://issues.apache.org/jira/browse/AXIS2-3919
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: kernel, modules
>Affects Versions: 1.4, 1.3, 1.2, 1.1.1, 1.1, 1.0
> Environment: Windows XP, Linux
>Reporter: Sujay Chauhan
> Fix For: 1.6
>
>
> Hi
> We are seeing an issue and it is holding us up from moving to production as 
> our production servers would run out of disk space.
> This is in regards to a client that we are trying to implement using 
> axis2-1.4 and rampart-1.3.
> We have a folder structure
> clientProjectFolder
>   --otherFolders
>   --
>   --
>   --axis2
>   --conf
> --axis2.xml
>--modules
>  --rampart1.3.mar
> our axis2.xml file contains the global module 
> In our client code, we make use of the fileSytemConfigurator to configure the 
> client stub before making the call to our service.
> Every time we are calling the service, files are added to the TEMP folder 
> (see below)
> C:\TEMP\_axis2>dir
>  Directory of C:\TEMP\_axis2
> 07/16/2008 08:36 AM  .
> 07/16/2008 08:36 AM  ..
> 07/16/2008 08:36 AM 2,704 axis2473rampart-1.3.mar
>1 File(s) 2,704 bytes
>2 Dir(s) 103,722,340,352 bytes free
> The same issue is being duplicated on our prod servers which are not windows 
> based but linux based. the files get put in /tmp/_axis2 folder.
> Any advice on if there is a workaround for this?
> Thanks,
> Sujay 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Axis2]multiple service in same archive

[Glen Daniels]

One of the main reasons we designed service groups was precisely to allow
people to deploy related web services in a convenient package.  The
services.xml format works fine with this IIRC - can't Zooz just merge the
files manually and put both  elements under a single ?

Providing a script for this would be easy, but perhaps too trivial to be
worth doing.

--Glen

Zooz Bee wrote:
> No particular reason, just wanted to make one .aar file for my web
> application. Its a very small application, in terms of request it will
> receive, serving couple services.
> 
> -zooz
> 
> 
> *From:* Sanjiva Weerawarana 
> *To:* axis-dev@ws.apache.org
> *Sent:* Saturday, August 29, 2009 12:50:43 PM
> *Subject:* Re: [Axis2]multiple service in same archive
> 
> Are you wanting to put them into a single .aar file for a particular
> reason? If its just to deploy multiple services then, unlike in Axis1,
> you don't need to put them into one file - just copy all the aar files
> to the repository.
> 
> Sanjiva.
> 
> On Sun, Aug 30, 2009 at 1:05 AM, Zooz Bee  > wrote:
> 
> Thanks Azeez  for response.
> 
> Since multiple services can be deployed inside the service group. I
> thought Axis2 should provide a tool to merge different service.xml
> inside service group.
> 
> -Zooz
> 
> 
> 
> 
> *From:* Afkham Azeez mailto:afk...@gmail.com>>
> *To:* axis-dev@ws.apache.org 
> *Sent:* Saturday, August 29, 2009 11:34:24 AM
> *Subject:* Re: [Axis2]multiple service in same archive
> 
> wsdl2java only recognizes services. It is not aware about service
> groups. You could write an ant/maven plugin that combines the
> generated code or the services XML files
> 
> Azeez
> 
> On Sat, Aug 29, 2009 at 8:34 AM, Zooz Bee  > wrote:
> 
> Hi,
> 
> I want to deploy multiple services in same archive. I generated
> the code from first WSDL. It generates the service.xml file.
> I generated the code for second WSDL. It also generated the
> service.xml file. Both service.xml are in format
> 
> First service.xml
> 
> 
>
> 
> 
> 
> 
> secondt service.xml
> 
> 
>
> 
> 
> 
> 
> Like in Axis1.X using deploy.wsdd file can be used to merge
> different wsdd  files?
> My querstion is how can i combine these two service.xml files
> into one. Is there a tool to combine both files in one xml file.
> 
> Thanks,
> Zooz
> 
> 
> 
> 
> 
> 
> -- 
> Thanks
> Afkham Azeez
> 
> Blog: http://afkham.org
> Developer Portal: http://www.wso2.org
> WSAS Blog: http://wso2wsas.blogspot.com
> Company: http://wso2.com
> GPG Fingerprint: 643F C2AF EB78 F886 40C9  B2A2 4AE2 C887 665E 0760
> 
> 
> 
> 
> -- 
> Sanjiva Weerawarana, Ph.D.
> Founder, Director & Chief Scientist; Lanka Software Foundation;
> http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> 
> Blog: http://sanjiva.weerawarana.org/
> 

Re: Axis2 1.5.1 and the default HttpClient reuse

[Glen Daniels]

Hi Dobri!

Sorry for the delay on responding to this.  Comments inline.

Dobri Kitipov wrote:
> "We now share an instance of HTTPClient across each ConfigurationContext
> (i.e.
> each Axis2 server or ServiceClient) - connection reuse is now automatic.
> This
> means the REUSE_HTTP_CLIENT flag is no longer necessary or useful, nor is
> creating your own MultithreadedHttpConnectionManager."
> 
> Since I have done some research and patches in HttpClient reuse area
> (ref. https://issues.apache.org/jira/browse/AXIS2-4288) I want to ask
> for some more information - like JIRAs involved or mail threads
> explaining this change.

The relevant JIRAs are pretty much anything that had to do with
TIME_WAIT/CLOSE_WAIT:

935, 2883, 4330, 2593, 2945, etc.

The description of the change is in the SVN commit message for r790721, but
there wasn't really any subsequent discussion until now.

> I glimpsed at part of the changes in the code related to this and some
> questions popped up in my mind:
> 
> 1) Did we test this for the asynchronous invocation use case? IMHO it is
> not that easy to reuse one HttpClient instance in this case. I am pretty
> sure there are some JIRAs that discuss this topic.

Yup, I tested async.  I've attached a little test harness to this email.  If
you run this while you have a SimpleAxisServer running on port 6060 (it uses
the Version service to test), you can see that each of the three
(synchronous, async blocking, async non-blocking) patterns it tests will
happily run many thousands of requests without building up CLOSE_WAITs or
locking up.  Note that the setCallTransportCleanup() call is necessary to
make the synchronous version work - but NOT for the async.  In the async code
path, we now (at HTTPSender.java:208) automatically release the connection
after sending - but only if we're using a separate listener.

> 2) As explained in https://issues.apache.org/jira/browse/AXIS2-4288 we
> can have some unwanted behaviour if we cannot associate an explicite
> HttpState when we invoke:
> 
> httpClient.executeMethod(config, method);
> 
> Since this commit is not part of the RC we need to document this.

I think we're ok here since 4288 wasn't fixed in 1.5, so it's OK that the fix
didn't make it into 1.5.1.  We've got it in 1.6 and should confirm that it
works in an intuitive and comfortable way for all the use-cases.

> 3) Anyway, depending on 1) we may need to have a property that could be
> configured so a separate HttpClient instance is created and used per
> call - if needed?
> 
> What do you think?

I think having the option might be a good idea... but if you think about it,
the way it works now ties a single HTTPClient instance to a single
ServiceClient (i.e. ConfigurationContext).  That seems pretty natural - and
if you want different HTTPClient instances, you can just use different
ServiceClient (or stub) instances and things should work as expected.

So I'm fairly comfortable with the way things are for 1.5.1 - if there's
anything you think we should really change right now, let me know.

Thanks,
--Glen
/*
 * Copyright (c) 2007, WSO2 Inc. (http://www.wso2.org) All Rights Reserved.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

import org.apache.axiom.om.OMAbstractFactory;
import org.apache.axiom.om.OMElement;
import org.apache.axiom.soap.SOAPFactory;
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.client.Options;
import org.apache.axis2.client.ServiceClient;
import org.apache.axis2.client.async.AxisCallback;
import org.apache.axis2.context.ConfigurationContext;
import org.apache.axis2.context.ConfigurationContextFactory;
import org.apache.axis2.context.MessageContext;
import org.apache.axis2.context.OperationContext;
import org.apache.axis2.description.Parameter;
import org.apache.commons.httpclient.ConnectionPoolTimeoutException;
import org.apache.commons.httpclient.HostConfiguration;
import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.HttpConnection;
import org.apache.commons.httpclient.MultiThreadedHttpConnectionManager;
import org.apache.commons.httpclient.methods.PostMethod;
import org.apache.commons.httpclient.methods.RequestEntity;
import org.apache.commons.httpclient.methods.StringRequestEntity;

import javax.xml.namespace.QName;

public class TestHTTPClientPatterns {
/** How many completed requests have we made? */
static Integer counter = 0;

/** Synchronization helper */
static final Object lock

[jira] Updated: (AXIS2-1556) DeploymentException with segmented wsdl files

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels updated AXIS2-1556:


Fix Version/s: 1.6

Targeting for 1.6.

> DeploymentException with segmented wsdl files
> -
>
> Key: AXIS2-1556
> URL: https://issues.apache.org/jira/browse/AXIS2-1556
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>Affects Versions: 1.1
> Environment: Axis2 1.1 (Oct. 30 nightly build)
> Tomcat version 5.5.17
> Java 1.5
> Linux Redhat
>Reporter: Gul Onural
>Priority: Blocker
> Fix For: 1.6
>
> Attachments: SimpleService.zip, ws.zip
>
>
> The attachement ws.zip can be used to reproduce the issue explained below.
> Gul
> I am getting org.apache.axis2.deployment.DeploymentException (entire 
> exception stack trace is down below in the e-mail) from the service I am 
> trying to deploy to Tomcat version 5.5.17, using the Axis2 nightly (Oct 30).
> This service worked with Axis2 release version. The only difference I have is 
> that I have got the SimpleService.wsdl splitted into several wsdl files (one 
> for the service definitions, one for the bindings and one for the port type 
> definitions).
> The following is my services.xml. 
> My .aar file contains multiple service implementation classes but, I removed 
> them from the services.xml file below, for simplicity.
> The name of the wsdl file containing the service definitions has the same 
> name as the name of the .aar file.  The .aar file contains all the wsdl files 
> under META-INF directory.
> That's all I can verify, since the exception stack trace doesn't tell that 
> much to go further.
> Can anyone help me to understand what would be wrong ?
> Thanks,
> Gul
> Services.xml
> =
> 
>
>   
>  http://www.w3.org/2004/08/wsdl/in-out"; 
> class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
>  http://www.w3.org/2004/08/wsdl/robust-in-only"; 
> class="org.apache.axis2.receivers.RawXMLINOnlyMessageReceiver"/>
>   
>locked="false">com.test.example.SimpleService
>   true
>mep="http://www.w3.org/2004/08/wsdl/in-out";>
>  urn:createSimpleExample
>  
> urn:mycompany.com:web-services:SimpleServicePortType:createSimpleExample
>   
>
> 
> Exception Stack trace :
> ==
> Error: org.apache.axis2.deployment.DeploymentException: null; nested 
> exception is: java.lang.NullPointerException; nested exception is: 
> org.apache.axis2.AxisFault: null; nested exception is: 
> java.lang.NullPointerException; nested exception is: 
> org.apache.axis2.deployment.DeploymentException: null; nested exception is: 
> java.lang.NullPointerException; nested exception is: 
> org.apache.axis2.AxisFault: null; nested exception is: 
> java.lang.NullPointerException at 
> org.apache.axis2.deployment.repository.util.ArchiveReader.processWSDLs(ArchiveReader.java:307)
>  at 
> org.apache.axis2.deployment.DeploymentEngine.doDeploy(DeploymentEngine.java:513)
>  at 
> org.apache.axis2.deployment.repository.util.WSInfoList.update(WSInfoList.java:196)
>  at 
> org.apache.axis2.deployment.RepositoryListener.update(RepositoryListener.java:203)
>  at 
> org.apache.axis2.deployment.RepositoryListener.checkServices(RepositoryListener.java:150)
>  at 
> org.apache.axis2.deployment.RepositoryListener.startListener(RepositoryListener.java:195)
>  at 
> org.apache.axis2.deployment.scheduler.SchedulerTask.checkRepository(SchedulerTask.java:61)
>  at 
> org.apache.axis2.deployment.scheduler.SchedulerTask.run(SchedulerTask.java:68)
>  at 
> org.apache.axis2.deployment.scheduler.Scheduler$SchedulerTimerTask.run(Scheduler.java:76)
>  at java.util.TimerThread.mainLoop(Timer.java:512) at 
> java.util.TimerThread.run(Timer.java:462) Caused by: 
> org.apache.axis2.deployment.DeploymentException: null; nested exception is: 
> java.lang.NullPointerException; nested exception is: 
> org.apache.axis2.AxisFault: null; nested exception is: 
> java.lang.NullPointerException at 
> org.apache.axis2.deployment.repository.util.ArchiveReader.processWSDLFile(ArchiveReader.java:202)
>  at 
> org.apache.axis2.deployment.repository.util.ArchiveReader.processWSDLs(ArchiveReader.java:287)
>  ... 10 more Caused by: org.apache.axis2.AxisFault: null; nested exception 
> is: java.lang.NullPointerException at 
> org.apache.axis2.description.WSDL11ToAxisServiceBuilder.populateService(WSDL11ToAxisServiceBuilder.java:253)
>

[jira] Resolved: (AXIS2-3781) ComplexDataTypesDocLitBareTest fails

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-3781.
-

   Resolution: Fixed
Fix Version/s: 1.5.1

This appears to work fine now, so am uncommenting the exclude and closing the 
bug.

> ComplexDataTypesDocLitBareTest fails
> 
>
> Key: AXIS2-3781
> URL: https://issues.apache.org/jira/browse/AXIS2-3781
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: Integration
>Reporter: Davanum Srinivas
>Assignee: Davanum Srinivas
>Priority: Blocker
> Fix For: 1.5.1
>
>
> ---
> Test set: org.apache.axis2.rpc.complex.ComplexDataTypesDocLitBareTest
> ---
> Tests run: 34, Failures: 0, Errors: 11, Skipped: 0, Time elapsed: 75.937 sec 
> <<< FAILURE!
> testretArrayInt1D(org.apache.axis2.rpc.complex.ComplexDataTypesDocLitBareTest)
>   Time elapsed: 2.703 sec  <<< ERROR!
> org.apache.axis2.AxisFault: org.apache.axis2.databinding.ADBException: 
> Unsupported type null org.tempuri.complex.data.arrays.ArrayOfint
>   at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
>   at 
> org.tempuri.complex.ComplexDataTypesDocLitBareStub.fromOM(ComplexDataTypesDocLitBareStub.java:48033)
>   at 
> org.tempuri.complex.ComplexDataTypesDocLitBareStub.retArrayInt1D(ComplexDataTypesDocLitBareStub.java:4910)
>   at 
> org.apache.axis2.rpc.complex.ComplexDataTypesDocLitBareTest.testretArrayInt1D(ComplexDataTypesDocLitBareTest.java:108)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at junit.framework.TestCase.runTest(TestCase.java:168)
>   at junit.framework.TestCase.runBare(TestCase.java:134)
>   at junit.framework.TestResult$1.protect(TestResult.java:110)
>   at junit.framework.TestResult.runProtected(TestResult.java:128)
>   at junit.framework.TestResult.run(TestResult.java:113)
>   at junit.framework.TestCase.run(TestCase.java:124)
>   at junit.framework.TestSuite.runTest(TestSuite.java:232)
>   at junit.framework.TestSuite.run(TestSuite.java:227)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.framework.TestResult.runProtected(TestResult.java:128)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
>   at 
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>   at 
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
>   at 
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
>   at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at 
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
>   at 
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993)
> Caused by: java.lang.Exception: org.apache.axis2.databinding.ADBException: 
> Unsupported type null org.tempuri.complex.data.arrays.ArrayOfint
>   at 
> org.tempuri.complex.ComplexDataTypesDocLitBareStub$ArrayOfint$Factory.parse(ComplexDataTypesDocLitBareStub.java:40444)
>   at 
> org.tempuri.complex.ComplexDataTypesDocLitBareStub$RetArrayInt1DResult$Factory.parse(ComplexDataTypesDocLitBareStub.java:45228)
>   at 
> org.tempuri.complex.ComplexDataTypesDocLitBareStub.fromOM(ComplexDataTypesDocLitBareStub.java:48027)
>   ... 29 more
> Caused by: org.apache.axis2.databinding.ADBException: Unsupported type null 
> org.tempuri.complex.data.arrays.ArrayOfint
>   at 
> org.tempuri.complex.ComplexDataTypesDocLitBareStub$ExtensionMapper.getTypeObject(ComplexDataTypesDocLitBareStub.java:

[jira] Updated: (AXIS2-3723) AXIS2 is not aware of "is" methods when generating soap messages from JAXB java beans

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-3723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels updated AXIS2-3723:


Fix Version/s: (was: nightly)
   1.6

Targeting this at 1.6.

> AXIS2 is not aware of "is" methods when generating soap messages from JAXB 
> java beans
> -
>
> Key: AXIS2-3723
> URL: https://issues.apache.org/jira/browse/AXIS2-3723
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: databinding
>Affects Versions: nightly
> Environment: Win XP Pro, JDK 6_04, Tomcat 5.5.26, JAXB 2.1.6
>Reporter: Glen Verran
>Assignee: Amila Chinthaka Suriarachchi
>Priority: Blocker
> Fix For: 1.6
>
> Attachments: 20080522_00.diff
>
>
> I have an XSD which contains an element of type xs:boolean.  This element is 
> called "redirect".  I use JAXB 2.1.6 to generate the java beans from the XSD. 
> The methods for the "redirect" variable in the java bean are isRedirect and 
> setRedirect.
> I created a web service with the method below:
>   public RetrieveConfigurationDataResponse 
> retrieveConfigurationData(RetrieveConfigurationDataRequest req) {
> RetrieveConfigurationDataResponse rsp = new 
> RetrieveConfigurationDataResponse();
> rsp.setData("1234");
> rsp.setDataEncodingType(req.getDataEncodingType());
> rsp.setEchoData(req.getEchoData());
> rsp.setIdentifier(req.getIdentifier());
> rsp.setIdentifierType(req.getIdentifierType());
> rsp.setRedirect(Boolean.FALSE);
> rsp.setResponseCode("00");
> rsp.setRevision(req.getRevision());
> return rsp;
>   }
> Both the (RetrieveConfigurationDataRequest  and 
> RetrieveConfigurationDataResponse are JAXB generated java beans.  The 
> RetrieveConfigurationDataResponse class is the one that contains this 
> redirect variable.  I generated the client code and went on to test this 
> method to the web service.
> I got the following AxisFault saying that it could not find the read method 
> for "redirect".
> Exception in thread "main" org.apache.axis2.AxisFault: 
> org.apache.axis2.AxisFault: can not find read method for : redirect
>   at 
> org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:486)
>   at 
> org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:343)
>   at 
> org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389)
>   at 
> org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211)
>   at 
> org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
>   at 
> com.traderoot.webservices.configurationdistribwebservice.ConfigurationDistribWebServiceStub.retrieveConfigurationData(ConfigurationDistribWebServiceStub.java:172)
>   at Test.main(Test.java:23)
> To confirm my assumptions, I went into the JAXB code and changed the 
> isRedirect method to getRedirect.  This fault did not occure.
> I do not consider this a workaround since JAXB classes are to be untouched.  
> It seems that AXIS2 is not looking for "is" methods when binding the java 
> bean.
> This is an absoluate blocker and prevents us from being able to use AXIS2.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AXIS2-3947) EJB provider run only once

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-3947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels updated AXIS2-3947:


Fix Version/s: 1.6

Targeting 1.6.

> EJB provider run only once
> --
>
> Key: AXIS2-3947
> URL: https://issues.apache.org/jira/browse/AXIS2-3947
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: rpc
>Affects Versions: 1.4, 1.3
> Environment: Weblogic 10.0MP1 (10.0.1.0)
> JDK 1.5.0_15-b04
> Windows XP SP2, Solaris 10
>Reporter: Jean-Philippe HAUTIN
>Assignee: sumedha rubasinghe
>Priority: Blocker
> Fix For: 1.6
>
> Attachments: ejbModuleWebServices.zip, WebServicesEJB.zip
>
>
> I made a simple web service towards an EJB using Axis2 1.3, following the 
> tutorial at this URL http://ws.apache.org/axis2/1_2/ejb-provider.html
> It works fine once (the first run) but when I try to run it a second time in 
> a row, I have this response in SOAP UI
>  
> http://schemas.xmlsoap.org/soap/envelope/";>
>
>   
>  soapenv:Server
>  object is not an instance of declaring 
> class
>  
> org.apache.axis2.AxisFault: object is not an instance 
> of declaring class
> at org.apache.axis2.AxisFault.makeFault(AxisFault.java:417)
> at 
> org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:156)
> at 
> org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
> at 
> org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:96)
> at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:145)
> at 
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
> at 
> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:120)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at 
> weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
> at 
> weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
> at 
> weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
> at 
> weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
> at 
> weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3370)
> at 
> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
> at weblogic.security.service.SecurityManager.runAs(Unknown Source)
> at 
> weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2117)
> at 
> weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2023)
> at 
> weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1359)
> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
> at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
> Caused by: java.lang.IllegalArgumentException: object is not an instance of 
> declaring class
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at 
> org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:194)
> at 
> org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:98)
> ... 19 more
>  
>   
>
> 
> I investigated a bit. I found out a problem within the « caching system » 
> used to prevent introspection to resolve which Java method/class to call.
> Here is a simple of 
> org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic() :
> Object obj = getTheImplementationObject(inMessage);
> Class ImplClass = obj.getClass();
> AxisOperation op = 
> inMessage.getOperationContext().getAxisOperation();
> method = (Method)(op.getParameterValue("myMethod&q

[jira] Updated: (AXIS2-4050) client proxy authentication failed, screwed up http headers

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels updated AXIS2-4050:


Fix Version/s: (was: nightly)
   1.6

Targeting 1.6 for a final fix for this... 

> client proxy authentication failed, screwed up http headers
> ---
>
> Key: AXIS2-4050
> URL: https://issues.apache.org/jira/browse/AXIS2-4050
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: transports
>Affects Versions: 1.4
> Environment: Linux debian etch
>Reporter: Stefan Lischke
>Assignee: Dimuthu Leelarathne
>Priority: Blocker
> Fix For: 1.6
>
>
> (see also http://markmail.org/message/lvabtbivnwuptfm2)
> trying to connect an Axis2 Client to a Web Service through a proxy with 
> authentication. 
> Tried with 
> System.setProperty("http
> and also with 
> HttpTransportProperties.ProxyProperties..
> I see those configuration enables proxy, but does screw up the 
> proxy-authentication. Here is the Request HTTP POST
> POST http://x HTTP/1.0\r\n
> Request Method: POST
> Request URI: http://x
> Request Version: HTTP/1.0
> Content-Type: text/xml; charset=UTF-8\r\n
> SOAPAction: "http://x"\r\n
> User-Agent: Axis2\r\n
> Proxy-Connection: Keep-Alive\r\n
> Content-Length: 5098
> Proxy-Authorization: Basic Og==\r\n
> Credentials: :
> Host: x:4711\r\n
> \r\n

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AXIS2-4197) Issue with toEnvelope(..) and toOm(..) in Axis 2 generated code for toOM taking in same paramter types

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels updated AXIS2-4197:


Fix Version/s: 1.6

Targeting for 1.6

> Issue with toEnvelope(..) and toOm(..) in Axis 2 generated code for toOM 
> taking in same paramter types
> --
>
> Key: AXIS2-4197
> URL: https://issues.apache.org/jira/browse/AXIS2-4197
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: codegen
> Environment: Windows XP. 
>Reporter: Vijeya Aravindan
>Priority: Blocker
> Fix For: 1.6
>
> Attachments: To_AXIS_JIRA.rar, To_AXIS_JIRA.zip
>
>   Original Estimate: 360h
>  Remaining Estimate: 360h
>
> Issue with Steps to re-produce:
> Say, I have 3 (could be 'n') operations in my wsdl. All 3 take the same param 
> type (say CustomParamterType) but internally have different business logic. 
> Step1- I take the wsdl and run the Axis 2 code gen as follows:
> Step 2- There would be '3' different public accessor methods generated in the 
> stub (which is good and expected) take in the same parameter type, then the 
> respective toOM() method generated. Say:
> public  com.ebay.trinity.identityservice.pres.wsdl.LinkIdentitiesResponseType 
> CreateLinkedIdentities(com.ebay.trinity.identityservice.pres.wsdl.LinkIdentitiesType
>  linkIdentities150) throws java.rmi.RemoteException
> public  com.ebay.trinity.identityservice.pres.wsdl.ModifyLinkResponseType 
> ModifyLink
> (com.ebay.trinity.identityservice.pres.wsdl.LinkIdentitiesType modifyLink140) 
> throws java.rmi.RemoteException
> public  com.ebay.trinity.identityservice.pres.wsdl.RemoveLinkResponseType 
> RemoveLink
> (com.ebay.trinity.identityservice.pres.wsdl.LinkIdentitiesType removeLink132) 
> throws java.rmi.RemoteException
> All the above take LinkIdentitiesType param.
> In side each of the method, an envolope is formed as follows (auto gen code 
> further)
> env = 
> toEnvelope(getFactory(_operationClient.getOptions().getSoapVersionURI()), 
> linkIdentities150,optimizeContent(new javax.xml.namespace.QName("", 
> "CreateLinkedIdentities")))
> private org.apache.axiom.soap.SOAPEnvelope 
> toEnvelope(org.apache.axiom.soap.SOAPFactory factory, 
> com.ebay.trinity.identityservice.pres.wsdl.LinkIdentitiesType param, boolean 
> optimizeContent) throws org.apache.axis2.AxisFault {
>  org.apache.axiom.soap.SOAPEnvelope envelope = factory.getDefaultEnvelope();
> envelope.getBody().addChild(toOM(param, optimizeContent));
> return envelope;
> } 
>  
> private org.apache.axiom.om.OMElement 
> toOM(com.ebay.trinity.identityservice.pres.wsdl.LinkIdentitiesType param, 
> boolean optimizeContent)
> throws org.apache.axis2.AxisFault {
> try {
> -some code---
>  JaxbRIDataSource source = new JaxbRIDataSource( 
> com.ebay.trinity.identityservice.pres.wsdl.LinkIdentitiesType.class,
>param,
>marshaller,
>"
> ",
>"removeLink"); /// CULPRIT 
> //
>  org.apache.axiom.om.OMNamespace namespace = factory.createOMNamespace("",
>   null);
>  return factory.createOMElement(source, "removeLink", namespace); 
> /// CULPRIT 
> //
> } catch (javax.xml.bind.JAXBException bex){
>  throw org.apache.axis2.AxisFault.makeFault(bex);
> }
> }
>  
> The above mehods are called by the following calls:
>  
> So whenever we make any af the above  *Link call, it used to form the 
> envelope as follows:
>  
>  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";> xmlns:axis2ns1="">1.2  /// CULPRIT 
> //
> So all calls finally landing to the Server were being processed for 
> removeLink. 
>  
> For now, I can fix the aut-generated code for the above methods which takes a 
> extra parameter called apiName which can be passed around without stuff like 
> removeLink  & createIdentity being hardcoded. The DISADVANTGE IS THAT we need 
> to have a static stub version which is checked in our code base which can be 
> used in our build time. This is AVOID us from integrating codeGen within our 
> ANT script.
> As a dev persion, the problem seems to be:
>  
> Lets 

[jira] Commented: (AXIS2-4279) Local File Inclusion Vulnerability on parsing WSDL related XSD Files

[Glen Daniels (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-4279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744096#action_12744096
 ] 

Glen Daniels commented on AXIS2-4279:
-

Isn't this already resolved in 1.5?  I don't have time to test this right now, 
but will later.

> Local File Inclusion Vulnerability on parsing WSDL related XSD Files
> 
>
> Key: AXIS2-4279
> URL: https://issues.apache.org/jira/browse/AXIS2-4279
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: transports
>Affects Versions: 1.4.1
> Environment: Tomcat 5.5
> Axis2 1.4.1
>Reporter: Wolfram Kluge
>Priority: Blocker
> Fix For: nightly
>
>
> Hello
> i dont know if it is a vulnerability or it is an issue of missconfiguration.
> The problem occur by doing the following things,
> http://localhost:8080/InsaneService/services/WSInsane?xsd=/../../../WEB-INF/conf/axis2.xml
> i was able to get these files displayed by the web browser. Once i tried 
> this, 
> furthermore i was also able to get public and private keystore/truststore 
> located in the WEB-IN dir as well.
> So please let me know if it is a missconfiguration, and tell me how i can 
> configure more securely.
> If its a bug please let me also know!
> Thank you in advance!
> Wolfram

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AXIS2-4319) CLONE -WSDL2Java: minOccurs and maxOccurs in / are not respected.

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels updated AXIS2-4319:


Fix Version/s: 1.6

Targeting this at 1.6

> CLONE -WSDL2Java: minOccurs and maxOccurs in / are not 
> respected.
> ---
>
> Key: AXIS2-4319
> URL: https://issues.apache.org/jira/browse/AXIS2-4319
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: adb
>Affects Versions: 1.1
> Environment: WinXP
>Reporter: Gopalakrishnan
>Assignee: Amila Chinthaka Suriarachchi
>Priority: Blocker
> Fix For: 1.6
>
>
> The following is a valid wsdl code:
> type="tns:ClaimMultipleElementsResultType"/>
>
>
> maxOccurs="1" minOccurs="1"/>
> minOccurs="1"/>
>
>
> This means, the ClaimMultipleElementsResultType can contain zero or more 
> pairs of Element / ElementId.
> However, the stub class ClaimMultipleElementsResultType created by WSDL2Java 
> provides
> only access for *one* pair of Element / ElementId. 
> I'm not sure whether this is a duplicate of issue AXIS2-840.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AXIS2-4337) Missing org.apache.axis2.transport.tcp.TCPTransportSender into Axis2 1.5 WAR

[Glen Daniels (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744093#action_12744093
 ] 

Glen Daniels commented on AXIS2-4337:
-

I don't agree with adding the "extra" transports (tcp, jms, etc) to the 
standard war.  We should definitely improve the documentation, and put clear 
pointers to the transport releases (after we have transport releases :)).

I'd be OK with putting out a "full" release with all the transports in a war, 
but it should be a separate (new) artifact.

Leaving this open for now until at least the docs get clarified.

> Missing org.apache.axis2.transport.tcp.TCPTransportSender into Axis2 1.5 WAR
> 
>
> Key: AXIS2-4337
> URL: https://issues.apache.org/jira/browse/AXIS2-4337
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>Affects Versions: 1.5, nightly
>Reporter: Dobri Kitipov
>Priority: Blocker
>
> Hi everybody,
> I found out that we are missing the 
> org.apache.axis2.transport.tcp.TCPTransportSender class into the 
> distribution. You can check the impact pretty easy. You should go and modify 
> the axis2\WEB-INF\conf\axis2.xml and uncomment the:
>  class="org.apache.axis2.transport.tcp.TCPTransportSender"/>
> Deploy the axis2-1.5-war in Tomcat.
> Then when you start the server you will get the following 
> java.lang.ClassNotFoundException: 
> org.apache.axis2.transport.tcp.TCPTransportSender:
> [ERROR] org.apache.axis2.transport.tcp.TCPTransportSender 
> org.apache.axis2.deployment.DeploymentException: 
> org.apache.axis2.transport.tcp.TCPTransportSender at 
> org.apache.axis2.deployment.AxisConfigBuilder.processTransportSenders(AxisConfigBuilder.java:694)
>  at 
> org.apache.axis2.deployment.AxisConfigBuilder.populateConfig(AxisConfigBuilder.java:121)
>  at 
> org.apache.axis2.deployment.DeploymentEngine.populateAxisConfiguration(DeploymentEngine.java:707)
>  at 
> org.apache.axis2.deployment.WarBasedAxisConfigurator.(WarBasedAxisConfigurator.java:157)
>  at 
> org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:525)
>  at org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:443) at 
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1139)
>  at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:966) 
> at 
> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3956)
>  at org.apache.catalina.core.StandardContext.start(StandardContext.java:4230) 
> at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
>  at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740) 
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544) at 
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:927) 
> at 
> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:890) 
> at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492) at 
> org.apache.catalina.startup.HostConfig.start(HostConfig.java:1150) at 
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
>  at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022) at 
> org.apache.catalina.core.StandardHost.start(StandardHost.java:736) at 
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at 
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at 
> org.apache.catalina.core.StandardService.start(StandardService.java:448) at 
> org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at 
> org.apache.catalina.startup.Catalina.start(Catalina.java:552) at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>  at java.lang.reflect.Method.invoke(Method.java:585) at 
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at 
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433) Caused by: 
> java.lang.ClassNotFoundException: 
> org.apache.axis2.transport.tcp.TCPTransportSender at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1386)
>  at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1232)
>  at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:

[jira] Assigned: (AXIS2-4337) Missing org.apache.axis2.transport.tcp.TCPTransportSender into Axis2 1.5 WAR

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels reassigned AXIS2-4337:
---

Assignee: Glen Daniels

> Missing org.apache.axis2.transport.tcp.TCPTransportSender into Axis2 1.5 WAR
> 
>
> Key: AXIS2-4337
> URL: https://issues.apache.org/jira/browse/AXIS2-4337
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>Affects Versions: 1.5, nightly
>Reporter: Dobri Kitipov
>Assignee: Glen Daniels
>Priority: Blocker
>
> Hi everybody,
> I found out that we are missing the 
> org.apache.axis2.transport.tcp.TCPTransportSender class into the 
> distribution. You can check the impact pretty easy. You should go and modify 
> the axis2\WEB-INF\conf\axis2.xml and uncomment the:
>  class="org.apache.axis2.transport.tcp.TCPTransportSender"/>
> Deploy the axis2-1.5-war in Tomcat.
> Then when you start the server you will get the following 
> java.lang.ClassNotFoundException: 
> org.apache.axis2.transport.tcp.TCPTransportSender:
> [ERROR] org.apache.axis2.transport.tcp.TCPTransportSender 
> org.apache.axis2.deployment.DeploymentException: 
> org.apache.axis2.transport.tcp.TCPTransportSender at 
> org.apache.axis2.deployment.AxisConfigBuilder.processTransportSenders(AxisConfigBuilder.java:694)
>  at 
> org.apache.axis2.deployment.AxisConfigBuilder.populateConfig(AxisConfigBuilder.java:121)
>  at 
> org.apache.axis2.deployment.DeploymentEngine.populateAxisConfiguration(DeploymentEngine.java:707)
>  at 
> org.apache.axis2.deployment.WarBasedAxisConfigurator.(WarBasedAxisConfigurator.java:157)
>  at 
> org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:525)
>  at org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:443) at 
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1139)
>  at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:966) 
> at 
> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3956)
>  at org.apache.catalina.core.StandardContext.start(StandardContext.java:4230) 
> at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
>  at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740) 
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544) at 
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:927) 
> at 
> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:890) 
> at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492) at 
> org.apache.catalina.startup.HostConfig.start(HostConfig.java:1150) at 
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
>  at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022) at 
> org.apache.catalina.core.StandardHost.start(StandardHost.java:736) at 
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at 
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at 
> org.apache.catalina.core.StandardService.start(StandardService.java:448) at 
> org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at 
> org.apache.catalina.startup.Catalina.start(Catalina.java:552) at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>  at java.lang.reflect.Method.invoke(Method.java:585) at 
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at 
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433) Caused by: 
> java.lang.ClassNotFoundException: 
> org.apache.axis2.transport.tcp.TCPTransportSender at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1386)
>  at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1232)
>  at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at 
> java.lang.Class.forName0(Native Method) at 
> java.lang.Class.forName(Class.java:164) at 
> org.apache.axis2.util.Loader.loadClass(Loader.java:261) at 
> org.apache.axis2.deployment.AxisConfigBuilder.processTransportSenders(AxisConfigBuilder.java:669)
>  ... 31 more
> As you may guess this is because it is missing from the classpath of the WAR. 
> I suppose axis2-transport-tcp.jar should be adde

[jira] Updated: (AXIS2-4353) ServiceClient can not resolve WSDL with imported schemas

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels updated AXIS2-4353:


Fix Version/s: 1.6

Targeting for 1.6

> ServiceClient can not resolve WSDL with imported schemas
> 
>
> Key: AXIS2-4353
> URL: https://issues.apache.org/jira/browse/AXIS2-4353
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: client-api
>Affects Versions: 1.4.1, 1.4
> Environment: all
>Reporter: Ben Reif
>Assignee: Andreas Veithen
>Priority: Blocker
> Fix For: 1.6
>
> Attachments: ResolveXSDTestCase.zip
>
>
> I am using the ServiceClient to invoke a Web Service, but the WSDL file and 
> imported schema files are located within a jar file that is in the Classpth. 
> I can get the Definition object, and I set the DocumentBaseURI to the proper 
> URL pointing inside the jar file, but when I pass it to the ServiceClient I 
> get an error saying that it can't resolve the imported schema files. This 
> happens when it calls AxisService.createClientSideAxisService().
> It looks like a fix was put in the WSDLToAxisServiceBuilder class (the 
> addition of the setCustomResolver() method) so that you can set a custom 
> URIResolver to resolve imported schema files. This gets inherited by the 
> WSDL11ToAxisServiceBuilder, however the problem is that this setter is not 
> exposed to the ServiceClient, so I can never use it.  The ServiceClient 
> constructors and the AxisService.createClientSideAxisService() methods should 
> take in an additional argument so that calling code can pass in the right 
> URIResolver instance which would get set on the WSDL11ToAxisServiceBuilder 
> instance.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AXIS2-4404) MessageContext.getEnvelope() returning NoSuchElementException

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels updated AXIS2-4404:


Fix Version/s: 1.6

Targeting this for 1.6.

Also, reminder to Ramya - please update this with a stack trace, and ideally a 
minimal test case (if you can make one) that demonstrates the problem.

> MessageContext.getEnvelope() returning NoSuchElementException
> -
>
> Key: AXIS2-4404
> URL: https://issues.apache.org/jira/browse/AXIS2-4404
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: adb, client-api, codegen, Tools, wsdl
>Affects Versions: 1.4.1
> Environment: Axis2 1.4.1, Tomcat5.5, JDK1.5, Eclipse 3.4.2
>Reporter: Ramya
>Priority: Blocker
> Fix For: 1.6
>
>   Original Estimate: 0.02h
>  Remaining Estimate: 0.02h
>
> Hello,
> I have a serious issue with getting hold of the incoming SOAP Envelope from 
> MessageContext.
> The reason I need the envelope is to be able to get the SOAP Header section, 
> read data from it, create a new header section for the response, populate it 
> in the response Header along with the Soap body data.
> I am doing this in the Skeleton.
> The following is the piece of code that throws a NoSuchElementException.
> The wierd thing is that the error happens only on our test server (Windows 
> 2003- SP2 machine with jre1.5.0_13). On our dev server (Windows XP-SP3 
> running jdk1.5.0_06) here we dont get this error.
> SOAPEnvelope envelope = 
> MessageContext.getCurrentMessageContext().getEnvelope();
> MessageContext.getCurrentMessageContext().getEnvelope().serialize(System.out);
> System.out.println(envelope);
> SOAPHeader header = envelope.getHeader();
> if (header != null)
>  wfContextElem = 
> header.getFirstChildWithName(BntService2007Stub.WFContext.MY_QNAME);
>  
> MessageContext inMsgContext = MessageContext.getCurrentMessageContext();
>  OperationContext operationContext =   inMsgContext.getOperationContext();
>  MessageContext outMessageContext = 
> operationContext.getMessageContext(WSDLConstants.MESSAGE_LABEL_IN_VALUE);
>  outMessageContext.setEnvelope(createSOAPEnvelope());
>   System.out.println("outenv in 
> outcontext="+outMessageContext.getEnvelope());
> response = ServiceDAO.getResponse(...);
>  OMElement omElement = 
> response.getOMElement(GetBankerNotesResponse.MY_QNAME,OMAbstractFactory.getOMFactory());
> String omElementString = 
> omElement.getBuilder().getDocumentElement().toStringWithConsume();
> System.out.println("Response xml in skeleton="+omElementString);  
> private SOAPEnvelope createSOAPEnvelope() {   
> SOAPFactory fac = OMAbstractFactory.getSOAP11Factory();   
> SOAPEnvelope envelope = fac.getDefaultEnvelope();
> OMNamespace xsi = 
> fac.createOMNamespace("http://www.w3.org/2001/XMLSchema-instance";, "xsi");
> envelope.declareNamespace(xsi);
> return envelope;
> }
> Your quick reply is highly appreciated as this is a Blocker and we are not 
> able to proceed further.
> Thanks!
> wsnewbie

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (AXIS2-4376) java.lang.UnsupportedClassVersionError: org/apache/axis2/AxisFault (Unsupported major.minor version 49.0)

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-4376.
-

Resolution: Invalid

Resolving this, and I promise to update the main page with the new JDK 
restriction! 

> java.lang.UnsupportedClassVersionError: org/apache/axis2/AxisFault 
> (Unsupported major.minor version 49.0)
> -
>
> Key: AXIS2-4376
> URL: https://issues.apache.org/jira/browse/AXIS2-4376
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 1.5
> Environment: JDK 1.4.2_19
>Reporter: sebastien chatel
>Priority: Blocker
>
> There was no problem using Axis2 1.4.1 with Sun JDK 1.4.2_19
> But 1.5 version depends on JDK 1.5.
> java.lang.UnsupportedClassVersionError: org/apache/axis2/AxisFault 
> (Unsupported major.minor version 49.0)
>   at java.lang.ClassLoader.defineClass0(Native Method)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
>   at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
>   at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
>   at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AXIS2-4408) the problem of In-only method with throw exception

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels updated AXIS2-4408:


Fix Version/s: 1.6

Targeting this for 1.6


> the problem of In-only method with throw exception
> --
>
> Key: AXIS2-4408
> URL: https://issues.apache.org/jira/browse/AXIS2-4408
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: wsdl
>Affects Versions: 1.4.1
> Environment: jdk1.4
>Reporter: qilin
>Priority: Blocker
> Fix For: 1.6
>
> Attachments: PrintService.java, PrintService.xml, services.xml
>
>
> 1.The Service Code:
> public class PrintService {
>   public void print(String aMessage) throws Exception{
>   System.out.println(aMessage);
>   }
> }
> 2.The Service.xml:
> 
>   
>   Please Type your service description here
>   
>   
>   http://www.w3.org/2004/08/wsdl/in-only"; 
> class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver" />
>   http://www.w3.org/2004/08/wsdl/in-out";  
> class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>
>   
>   
>locked="false">soap.test.PrintService
>   
>
> 
> 3. generate clent code by wsdl2java and run test
> I get the exception
>java.lang.UnsupportedOperationException: An access occurred that is not 
> valid.
>   at 
> org.apache.axis2.description.InOnlyAxisOperation.getMessage(InOnlyAxisOperation.java:109)
>   at 
> org.apache.axis2.util.MessageContextBuilder.createOutMessageContext(MessageContextBuilder.java:190)
>   at 
> org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:37)
>   at 
> org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:100)
>   at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176)
>   at 
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
>   at 
> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:133)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:199)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:145)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
>   at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
>   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:955)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:139)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
>   at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
>   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:955)
>   at 
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2460)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:133)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
>   at 
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:119)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594)
>   at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
>   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:955)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:127)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
>   at 
> org.apache.catalina.core.StandardPipeline.i

Re: [VOTE] [axis2] Release Axis2 1.5.1 (status)

[Glen Daniels]

:-)

So regarding this release - we don't seem to have many +1's yet.  As such, my
plan is to rejigger it as Dennis suggests and re-publish this content (with
only minor tweaks) as 1.5RC later today.  Hopefully we can get that out to
the world ASAP while trying to quickly resolve the documentation, etc.

--Glen

Andreas Veithen wrote:
> Stop complaining and do something :-)
> 
> Andreas
> 
> On Mon, Aug 17, 2009 at 06:37, Dennis Sosnoski wrote:
>> I'd think at least this Jira should be addressed before a 1.5.1 release:
>> https://issues.apache.org/jira/browse/AXIS2-4434 Another documentation issue
>> is that the documentation on transports is no longer accurate, and should
>> either be corrected (presumably by pointing to the transports project
>> location... if there is one) or deleted.
>>
>> My personal preference would also be to make Axis2 1.5.1 available as an RC
>> rather than a full release until at least preliminary builds of transports
>> and Rampart are available to work with 1.5.1. Otherwise, the Axis2 download
>> page should warn users that the release has limited functionality until
>> these other projects are available.
>>
>>  - Dennis
>>
>>
>> Glen Daniels wrote:
>>> (resend with corrected URL)
>>>
>>> Hi Axis Developers,
>>>
>>> I've put up what will hopefully be our 1.5.1 release, with a few key fixes
>>> as
>>> follows:
>>>
>>>*  Fix for the dreaded "CLOSE_WAIT" problem (JIRA issues 935, 2883,
>>> etc).
>>> We now share an instance of HTTPClient across each ConfigurationContext
>>> (i.e.
>>> each Axis2 server or ServiceClient) - connection reuse is now automatic.
>>> This
>>> means the REUSE_HTTP_CLIENT flag is no longer necessary or useful, nor is
>>> creating your own MultithreadedHttpConnectionManager.
>>>* Transport deployer is now actually functional, and
>>> getListenerManager()
>>> in ConfigurationContext now creates a new LM if there isn't one already.
>>>* Fix for AXIS2-4034, module versions now support real versions like
>>> "1.5.1"
>>>* NPE problem (see AXIS2-4114) fixed in MessageContext while retrieving
>>> policy.
>>>
>>> This mail kicks off a VOTE for the release, with the usual 72-hour window
>>> for
>>> votes.
>>>
>>> You can find the distribution files in here:
>>>
>>>
>>> http://people.apache.org/~gdaniels/stagingRepo/org/apache/axis2/distribution/1.5.1/
>>>
>>> And the M2 repository with everything is at:
>>>
>>> http://people.apache.org/~gdaniels/stagingRepo
>>>
>>> The SVN tag is:
>>>
>>> https://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.5.1RC
>>>
>>> ...and I'll add a proper "v1.5.1" tag as soon as this release goes final.
>>>
>>> Please offer your VOTE(and indicate binding/non-binding).
>>>
>>> Here's my +1 (binding).
>>>
>>> Many thanks,
>>> --Glen
>>>
>>>

[VOTE] [axis2] Release Axis2 1.5.1

[Glen Daniels]

(resend with corrected URL)

Hi Axis Developers,

I've put up what will hopefully be our 1.5.1 release, with a few key fixes as
follows:

*  Fix for the dreaded "CLOSE_WAIT" problem (JIRA issues 935, 2883, etc).
We now share an instance of HTTPClient across each ConfigurationContext (i.e.
each Axis2 server or ServiceClient) - connection reuse is now automatic. This
means the REUSE_HTTP_CLIENT flag is no longer necessary or useful, nor is
creating your own MultithreadedHttpConnectionManager.
* Transport deployer is now actually functional, and getListenerManager()
in ConfigurationContext now creates a new LM if there isn't one already.
* Fix for AXIS2-4034, module versions now support real versions like "1.5.1"
* NPE problem (see AXIS2-4114) fixed in MessageContext while retrieving
policy.

This mail kicks off a VOTE for the release, with the usual 72-hour window for
votes.

You can find the distribution files in here:

http://people.apache.org/~gdaniels/stagingRepo/org/apache/axis2/distribution/1.5.1/

And the M2 repository with everything is at:

http://people.apache.org/~gdaniels/stagingRepo

The SVN tag is:

https://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.5.1RC

...and I'll add a proper "v1.5.1" tag as soon as this release goes final.

Please offer your VOTE(and indicate binding/non-binding).

Here's my +1 (binding).

Many thanks,
--Glen

[VOTE] [axis2] Release Axis2 1.5.1

[Glen Daniels]

Hi Axis Developers,

I've put up what will hopefully be our 1.5.1 release, with a few key fixes as
follows:

*  Fix for the dreaded "CLOSE_WAIT" problem (JIRA issues 935, 2883, etc).
We now share an instance of HTTPClient across each ConfigurationContext (i.e.
each Axis2 server or ServiceClient) - connection reuse is now automatic. This
means the REUSE_HTTP_CLIENT flag is no longer necessary or useful, nor is
creating your own MultithreadedHttpConnectionManager.
* Transport deployer is now actually functional, and getListenerManager()
in ConfigurationContext now creates a new LM if there isn't one already.
* Fix for AXIS2-4034, module versions now support real versions like "1.5.1"
* NPE problem (see AXIS2-4114) fixed in MessageContext while retrieving
policy.

This mail kicks off a VOTE for the release, with the usual 72-hour window for
votes.

You can find the distribution files in here:

http://people.apache.org/~gdaniels/stagingRepo/org/apache/axis2/distribution/1.5/

And the M2 repository with everything is at:

http://people.apache.org/~gdaniels/stagingRepo

The SVN tag is:

https://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.5.1RC

...and I'll add a proper "v1.5.1" tag as soon as this release goes final.

Please offer your VOTE(and indicate binding/non-binding).

Here's my +1 (binding).

Many thanks,
--Glen

Re: [axis2] Releasing 1.5.1

[Glen Daniels]

Hi Deepal:

Deepal Jayasinghe wrote:
>> So, there are currently no JIRAs left targeted for 1.5.1, and there were at
>> least a few major fixes (in particular the CLOSE_WAIT issues, transport
>> deployer fix, and the module versioning stuff) since 1.5 that I for one would
>> really like to get out into the world ASAP.
> 
> But we have 17 blockers? so are we going to keep them as it is or are
> we going address them. As I remember correct we do not do releases
> when we have blockers. Either we fix them or down grade them.

I think the fixes we've already done are pretty critical to get out, and
since we already released 1.5 with these, I'm leaning towards just targeting
the current blocker list to 1.6, and letting those be our blockers for the
next major release (which could be right after ApacheCon?).  WDYT?

If people think this is OK, I'll try to get a release wrapped up tonight if
possible (I'm at a client today so won't be able to do Apache work during the
day).

Thanks,
--Glen

Re: [Axis2] JABRI: Multiple JAXBContext creation

[Glen Daniels]

Hi Sebastian:

Sebastian Just - RÖPERWEISE Systems wrote:
> On Thu, 06 Aug 2009 09:44:16 -0400, Glen Daniels 
>> Would you mind merging this fix over to the 1.5 branch so it can get into
>> 1.5.1?
> So will it be in 1.5.1 release?
> Or will it be in some other release (can you say which one?)?

Yes. :)

It will be in both 1.5.1 (soon) and 1.6 (no set date as yet).

Thanks,
--Glen

Re: [Axis2] JABRI: Multiple JAXBContext creation

[Glen Daniels]

Thanks, dims!

Would you mind merging this fix over to the 1.5 branch so it can get into 1.5.1?

--Glen

Davanum Srinivas wrote:
> Checked in svn revision 801630.
> 
> thanks,
> dims
> 
> On 08/06/2009 08:45 AM, Sebastian Just - RÖPERWEISE Systems wrote:
>> Hi !
>> On Thu, 6 Aug 2009 06:58:22 -0400, Davanum Srinivas
>> wrote:
>>> Please create a new issue and upload your XSLT there. Please mark the
>>> JIRA issue as a blocker.
>>
>> Done: AXIS2-4458
>>
>>
>> Best regards,
>> Sebastian

[axis2] Releasing 1.5.1

[Glen Daniels]

Hi folks:

So, there are currently no JIRAs left targeted for 1.5.1, and there were at
least a few major fixes (in particular the CLOSE_WAIT issues, transport
deployer fix, and the module versioning stuff) since 1.5 that I for one would
really like to get out into the world ASAP.

What needs to happen before we release 1.5.1?  We need to do a transports
release for sure, but that doesn't absolutely need to block 1.5.1, right?
Ditto with Rampart / Sandesha - we should get those out ASAP (and the teams
are working on it IIRC) but again putting out 1.5.1 shouldn't be gated on that.

I'll clean up the docs a bit, but aside from that are people OK if I get the
release train rolling to get these fixes out?

Thanks,
--Glen

[jira] Resolved: (AXIS2-2945) Connections are not released promply

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-2945.
-

   Resolution: Fixed
Fix Version/s: 1.5.1

Marking this as resolved for now, based on testing by several people who were 
seeing this and now aren't.

If the problem persists for you, please feel free to reopen and detail.

> Connections are not released promply
> 
>
> Key: AXIS2-2945
> URL: https://issues.apache.org/jira/browse/AXIS2-2945
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>Affects Versions: 1.1.1
> Environment: linux SMP kernel 2.6.14, java 1.5, axis2 1.1.1 nighlty, 
> tomcat 5.5.20
>Reporter: Michele Mazzucco
>Priority: Critical
> Fix For: 1.5.1
>
>
> Using netstat -na I see a huge number of connections in TIME_WAIT state 
> (tomcat is configured with a timeout of 20 seconds). I don't know whether 
> this issue is related to the server (kernel) or the client api (the server 
> sends messages as well)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (AXIS2-4330) axis2 client machine has many CLOSE_WAIT tcp

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-4330.
-

   Resolution: Fixed
Fix Version/s: 1.5.1

This has been fixed (see http://svn.apache.org/viewvc?rev=790721&view=rev) for 
1.5.1 and on the trunk.


> axis2  client machine has many CLOSE_WAIT tcp
> -
>
> Key: AXIS2-4330
> URL: https://issues.apache.org/jira/browse/AXIS2-4330
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: client-api
>Affects Versions: 1.4.1
> Environment: solaris
>Reporter: jenny anderson
> Fix For: 1.5.1
>
> Attachments: TuxedoWebServiceStub.java
>
>
> My application is using axis2 web service. It  invokes web service thousand 
> times per second. We observed thousand CLOSE_WAIT connection after the 
> application is run for less than 10 hours.  I checked even I set 
> REUSE_HTTP_CLIENT to false, it still gets CLOSE_WAIT.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (AXIS2-2883) CLOSE_WAIT slowly building up over the period of time.

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-2883.
-

   Resolution: Fixed
Fix Version/s: 1.5.1

Hi all.

This long-standing problem is now fixed.  See 
http://svn.apache.org/viewvc?rev=790721&view=rev.

When sharing a single ServiceClient, you need to either call 
client.transportCleanup() after each call or (easier) just use 
options.setCallTransportCleanup(true) to do it automatically (each call cleans 
up the last one).  

The fix is in the 1.5 branch and the trunk, and we're hoping to release 1.5.1 
in the near future to get this into a released version.  Also hoping to produce 
a somewhat better resource management/release pattern for 1.6.

Please test (with the SVN versions or 1.5.1 when it's out) and let us know if 
you have any further problems.

> CLOSE_WAIT slowly building up over the period of time.
> --
>
> Key: AXIS2-2883
> URL: https://issues.apache.org/jira/browse/AXIS2-2883
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: client-api
>Affects Versions: 1.1
> Environment: Operating System : Solaris 
> Axis2 Version : 1.1
> Application Server : weblogic 8.1 SP6
> Using with Cocoon and weblogic DSP
>Reporter: Lakshmanan Venkatachalam
>Assignee: Glen Daniels
>Priority: Critical
> Fix For: 1.5.1
>
>
> I am experiencing theconstant increase in close wait in the production 
> environment over the period 7 days. 
> We are using Synchronous webservices and we are calling two webservices 24 
> times every day. We have allocated the maximum of 1.5 GB per application 
> instance and we have two application instances. We are utilizing maximum of 
> 250 - 300 MB in average. So Full GC never runs in our environment.
> It seems like the client API ServiceClient.java is not cleaning up the 
> resources associated with this component. We are creating the new 
> ServiceClient component on every call we have for webservices. Though we have 
> called the cleanup() method at the end of every call to the webservices. At 
> times its not getting executed.
> But when we force garabage collection from the application, it was able to 
> clear all the CLOSE_WAIT components. Since we have similar cleanup() call on 
> finalize() method, it is able to do proper clean up when GC is collecting 
> these objects.
> Forcing GC cannot be a solution, I like to hear from axis2 experts on how we 
> can resolve this problem properly and what could be the cause for this 
> happening.
> Below is our client code for your reference.
> private WebServiceResponse invokeWebservice(OMElement inputElement,
>   Options options) throws WebServiceInvokerException {
>   ServiceClient serviceClient = null;
>   try {
>   serviceClient = new ServiceClient();
>   serviceClient.setOptions(options);
>   // This following line of code is used when we are using
>   // WS-Addressing. User has to make sure the addressing 
> MAR file in
>   // class path before enable the following line of code
>   //
>   // serviceClient.engageModule(new QName(
>   // org.apache.axis2.Constants.MODULE_ADDRESSING));
>   // Invoking synchrounous webservice
>   //
>   OMElement result = 
> serviceClient.sendReceive(inputElement);
>   
>   OMNode firstOMChild = result.getFirstOMChild();
>   // Conver the OMelements to XML String
>   //
>   Writer stringWriter = new StringWriter();
>   firstOMChild.serialize(stringWriter);
> serviceClient.cleanup();
>   stringWriter.flush();
>   // Return the Axis2WebserviceResponse
>   //
>   return new 
> Axis2WebServiceResponse(stringWriter.toString());
>   } catch (AxisFault afe) {
>   throw new WebServiceInvokerException(afe);
>   } catch (XMLStreamException xse) {
>   throw new WebServiceInvokerException(xse);
>   } catch (IOException ioe) {
>   throw new WebServiceInvokerException(ioe);
>   } finally {
>   try {
>   serviceClient.cl

[jira] Resolved: (AXIS2-4377) Exception thrown in MessageContext.findBindingMessage

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-4377.
-

Resolution: Fixed

Just fixed this on the branch.  Still needs a test case, but leaving 4114 open 
for that.

> Exception thrown in MessageContext.findBindingMessage
> -
>
> Key: AXIS2-4377
> URL: https://issues.apache.org/jira/browse/AXIS2-4377
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 1.5
> Environment: Java 1.5.0_16-b02 on XP SP3, Axis2 1.5 GA, Tomcat 6.0.18
>Reporter: Jonas Buys
> Fix For: 1.5.1
>
>
> I have a module to enforce some custom policies when invoking a dummy service 
> and it worked completely well on Axis2 1.4.1.
> Yet, when I am throwing an AxisFault SOAP fault, 1.5.1 throws this exception:
> SEVERE: Servlet.service() for servlet AxisServlet threw exception
> java.lang.NullPointerException
> at 
> org.apache.axis2.context.MessageContext.findBindingMessage(MessageContext.java:1609)
> at 
> org.apache.axis2.context.MessageContext.getEffectivePolicy(MessageContext.java:1581)
> at 
> be.ac.ua.pats.adss.handlers.LoggingHandler.invoke(LoggingHandler.java:42)
> at org.apache.axis2.engine.Phase.invoke(Phase.java:318)
> at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:251)
> at org.apache.axis2.engine.AxisEngine.sendFault(AxisEngine.java:481)
> at 
> org.apache.axis2.transport.http.AxisServlet.handleFault(AxisServlet.java:423)
> at 
> org.apache.axis2.transport.http.AxisServlet.processAxisFault(AxisServlet.java:386)
> at 
> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:176)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 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:233)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
> at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:595)
> Apparantly, the axisMessage is null on line 1609 (String direction = 
> axisMessage.getDirection();).  Weird thing is that it works for operation 
> with policy I attached in module.xml and always reproduces this error for any 
> operation with policies on my service.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AXIS2-4114) Problem to retrieve the effective policy from MessageContext when we have policy attachment at binding level

[Glen Daniels (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738176#action_12738176
 ] 

Glen Daniels commented on AXIS2-4114:
-

Hi all - I just checked in NPE protection code (similar to Mary's patch) on the 
1.5 branch.  I'm hesitant to mark this fixed until we have a test case... would 
anyone be willing to put a small one together?

> Problem to retrieve the effective policy from MessageContext when we have 
> policy attachment at binding level
> 
>
> Key: AXIS2-4114
> URL: https://issues.apache.org/jira/browse/AXIS2-4114
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: kernel
>Reporter: Dobri Kitipov
>Assignee: Nandana Mihindukulasooriya
> Attachments: MessageContext_effectivePolicy.patch
>
>
> Hi,
> I have a problem when I try to get the effective policy from a MessageContext 
> when I have a policy attached at the binding level of a Web Service. I am 
> using Axis2 1.4.0
> Let me explain a little bit the scenario I have. I am using an AAR that has 
> into its services.xml:
> true
> and a PolicyAttachment at its service level:
>  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";>
> 
> 
> 
> 
>  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"; 
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>...
> 
> As a result the WSDL generated has the policy specified and policy reference 
> at the binding subject level. Here is an excerpt from the wsdl for the 
> SOAP11Binding:
> 
>  transport="http://schemas.xmlsoap.org/soap/http"/>
> 
> At client side I have a dynamic client. So the issue is that when I invoke 
> the service and the WSDL is read and the corresponding AxisService object is 
> crated at the client side I have some modules' handlers that take palce. One 
> of them is a custom one in which I have the following invocation:
> Policy policy = msgCtx.getEffectivePolicy();
> The problem is that this returns "null"! I debugged this and it came out that 
> msgCtx is not null. When the method is invoked it tries to calculate the 
> effective policy as given below.
>  AxisBindingMessage bindingMessage =
>  (AxisBindingMessage)
>  getProperty(Constants.AXIS_BINDING_MESSAGE);
>  if (bindingMessage != null) {
>  return bindingMessage.getEffectivePolicy();
>  } else {
>  if (axisMessage != null) {
>  return axisMessage.getEffectivePolicy();
>  } else {
>  return null;
>  }
>  }
> where bindingMessage  is null and axisMessage.getEffectivePolicy(); returns 
> null, too. When I dig through the AxisService -> AxisEndpoint -> AxisBinding 
> -> here the PolicySubject is in fact a PolicyReference to the Policy that is 
> set into the AxisService policyMap. So as a result 
> axisMessage.getEffectivePolicy() returns null and I can not get the Policy I 
> need.
> I saw that I need something like the AxisDescription.getApplicablePolicy in 
> order to locate the real Policy of a given PolicyReference.
> You can see the patch applied that I have tested and seem to me that works 
> fine.
> Thank you in advance,
> Dobri

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AXIS2-4348) Service is not generating proper bindings for all ports

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels updated AXIS2-4348:


Fix Version/s: (was: 1.4.1)
   1.6

Re-targeting to 1.6.

> Service is not generating proper bindings for all ports
> ---
>
> Key: AXIS2-4348
> URL: https://issues.apache.org/jira/browse/AXIS2-4348
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: databinding
>Affects Versions: 1.4.1
> Environment: Windows XP SP2, Eclipse Europa 3.3, Tomcat 5.5.15
>Reporter: Jitendra Bahadur Verma
>Priority: Blocker
> Fix For: 1.6
>
> Attachments: sample.zip
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> Axis 2-1.3 is generating services for all ports on deployment and generate 
> soap address with specific ip. 
> But Axis2-1.4 is not generating all the bindings and also soap address is not 
> updating from localhost to specific ip.
> Attaching the wsdl for both.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AXIS2-3967) JDk5 Enum Support in AXIS2

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-3967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels updated AXIS2-3967:


Fix Version/s: (was: 1.4)
   1.6

Re-targeting for 1.6 - we'll evaluate again during the dev cycle.

> JDk5 Enum Support in AXIS2 
> ---
>
> Key: AXIS2-3967
> URL: https://issues.apache.org/jira/browse/AXIS2-3967
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: wsdl
>Affects Versions: 1.4
> Environment: AXIS2.1.4
>Reporter: Kamalakar
> Fix For: 1.6
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Our Organizaton want to use Java level enumeration support or WSDL level 
> enumeration support for implementing it in the WSDL

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AXIS2-4185) Web documentation for the wsdl2code plugin have not been updated since 1.3v and are missing MANY options

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels updated AXIS2-4185:


Fix Version/s: (was: 1.4.1)
   (was: 1.4)
   (was: 1.3)
   1.6

Moving all old targets to 1.6 for now.

> Web documentation for the wsdl2code plugin have not been updated since 1.3v 
> and are missing MANY options
> 
>
> Key: AXIS2-4185
> URL: https://issues.apache.org/jira/browse/AXIS2-4185
> Project: Axis 2.0 (Axis2)
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 1.4.1, 1.4, 1.3
>Reporter: Gil Tzadikevitch
> Fix For: 1.6
>
>
> The documentation in 1.2, 1.4 and 1.4.1 are not updated for wsdl2code.
> There for its misleading, causing people to think its impossible to use the 
> plugin with JIBX (that needs those extra options)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AXIS2-4426) axis2 responds on all endpoint urls, but delivers using the selected binding

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels updated AXIS2-4426:


Fix Version/s: (was: 1.5.1)
   1.6

Retargeting this at 1.6, since it's not a critical bug-fix for 1.5.1

> axis2 responds on all endpoint urls, but delivers using the selected binding
> 
>
> Key: AXIS2-4426
> URL: https://issues.apache.org/jira/browse/AXIS2-4426
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
> Environment: fedora 11, openjdk 1.6 tomcat 6
>Reporter: Christoph Höger
> Fix For: 1.6
>
>
> When I use the following POJO:
> @WebService(name="counterService", 
> targetNamespace="http://www.umpa-net.de/services/counterService";)
> @BindingType(value=HTTPBinding.HTTP_BINDING)
> public class Service {
>   
>   @WebMethod(operationName = "echoMethod")
>   public String echoString(@WebParam(name="stringIn")String s){
>   return s;
>   }
>   
>   @WebMethod(operationName = "greeting")
>   public String sendGreeting() {
>   return "Hello from a webservice, Mareike!";
>   }
> }
> I get SOAP11, SOAP12 and an HTTP endpoint in the wsdl.
> If I issue that endpoint by GETing e.g.: 
> http://192.168.2.106:8080/axis2/services/ServiceService.ServiceServiceHttpSoap12Endpoint/greeting
> I would expect an 404 or a "wrong protocoll" message, but it is handled via 
> http and I get the response.
> Is that expectation wrong?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Axis2] Is Axis2 dying?

[Glen Daniels]

Hi Dennis:

Dennis Sosnoski wrote:
>> I'm going to try and get 1.5.1 out the door ASAP, and will commit to
>> at least
>> the transports happening along with that.
> 
> Sounds great, Glen! But Axis2 really requires compatible Rampart and
> probably Sandesha releases since these implement functionally which is
> crucial to Axis2's intended usage. The lagging releases of these other
> projects have been problems with past Axis2 releases, too. Is there
> anything we can do to assure that users get a fully-functioning web
> services stack based on Axis2 as part of a release?
> 
> Perhaps in the future there should be a single release manager for at
> least Axis2, transports, and Rampart, with no official release of Axis2
> until the other essential components are also ready for release?

IMO, this would be a bad idea.  The goal of the kind of modularity we have,
or at least one of the goals, is to enable the components to version and
release at different rates.  Unless there were incompatible API changes
(which certainly do happen) we should be able to release several Axis2
versions during a single Rampart release cycle, or vice versa.  In reality,
at least so far, we have needed to rev at least Rampart (Sandesha 1.3 works
fine with Axis2 1.4 - not sure about 1.5) for compatibility.

I'd like to continue pushing for this kind of "loose" coupling between the
various pieces, but I do want us to be sensitive to incompatible changes as
well - I think there might be a call here for a slightly richer versioning
system, but I don't think we need to make the stack all release in lock-step.

Thanks,
--Glen

Re: [Axis2] Is Axis2 dying?

[Glen Daniels]

Hi Dennis:

Dennis Sosnoski wrote:
> Whether officially led by WSO2 or not, certainly most of the direction
> of the project has come from people associated with WSO2 and/or the Sri
> Lanka university. Glen is, I believe, the current chair of the PMC, and
> was also the release manager for the 1.5 release.

I agree re: most of the committership having historically been from WSO2, but
also IBM.  You may not be aware that I'm no longer associated with WSO2 as of
January; these days I'm an independent consultant.

> As to Axis2 status, you don't see a problem in pointing people at a
> latest Axis2 release which only supports HTTP transport and does not
> have any corresponding Rampart release? Some delay in getting these
> other components out is understandable, since they are separate projects
> (wisely so or not), but it's been a month and a half since Axis2 1.5 was
> released and there's been no noticeable move toward releasing these
> essential components.

(Note - all the transports are usable with Axis2 1.5, there just hasn't been
an official release.  It's not as if Axis2 1.5 "only" supports HTTP.)

Although of course this is a team effort, I'll step up to take this one since
as release manager I should have at least been pushing harder to get the
transports release happening in parallel.  I did ping the Rampart guys, but
everyone has been pretty busy (including me).

I'm going to try and get 1.5.1 out the door ASAP, and will commit to at least
the transports happening along with that.

> I don't know all the details of how Apache works - is this something
> which should be addressed by the PMC?

This is a volunteer effort, as always.  The PMC can certainly indicate
problems and discuss them, but they can't force committers to actually do any
work.

One thing I think we might suggest to improve the situation is a "JIRA-thon",
where we get committers to pledge that they'll fix a certain number of JIRA
issues (10 might be a good start) over a certain period of time, say two
weeks.  It would be great if we could release 1.6 with a LOT of problems fixed.

Part of the problem is that we're not communicating well enough as a team,
and not keeping track of what really needs doing.  I don't actually fully
agree with Sanjiva's assertion that Axis2 is "essentially done", because 1)
we REALLY shouldn't have hundreds and hundreds of JIRAs - sure, some are
frivolous but many are real issues causing real problems (case in point the
incorrect use of the HTTP connection manager I fixed recently), and 2) every
time I dive in there I see some really poor code somewhere.  Not that we're
the only project to have less-than-perfect code, but I'm worried that
thinking too much along the lines of "we're a mature project" might lead to
complacency about fixing some of these problems.

Thanks,
--Glen

PMC Reorganization and July board report

[Glen Daniels]

Hi everyone:

Once again, I'm cc'ing all the -dev lists to make absolutely sure everyone
sees this note.  Future mails will just go to gene...@.

It's time to get this discussion going, and hopefully bring it to some kind
of a place from which we can affect change as a community.  We're going to
submit a report to the board in July, and I'd really like to be able to say
something other than "radio silence on the PMC reorg front". :)

Can we talk some more about this in the near term?  As you know, there is a
wiki page at:

http://wiki.apache.org/ws/FrontPage/WebServicesPMCReorg

One proposal there has four supporters so far, and other proposals, comments,
thoughts, etc., are very welcome.

Please, people, chime in.  Either put your thoughts on the wiki, or continue
the discussion via email at gene...@ws.apache.org - please try and keep the
discussion about this topic on that list and not on the individual project
lists, since this is clearly a community-wide topic.

Thanks,
--Glen

[jira] Commented: (AXIS2-2945) Connections are not released promply

[Glen Daniels (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12726945#action_12726945
 ] 

Glen Daniels commented on AXIS2-2945:
-

Michele, I just checked in what I think is a fix for this into the 1.5 branch - 
I'll be updating the version to 1.5.1 and putting out some nightlies soon, but 
in the meanwhile could you try building the 1.5 branch and seeing if it 
resolves the problem?  The main difference is that we're now sharing a single 
HTTPClient instance across each ConfigurationContext, as recommended by the 
HTTPClient docs.

> Connections are not released promply
> 
>
> Key: AXIS2-2945
> URL: https://issues.apache.org/jira/browse/AXIS2-2945
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>Affects Versions: 1.1.1
> Environment: linux SMP kernel 2.6.14, java 1.5, axis2 1.1.1 nighlty, 
> tomcat 5.5.20
>Reporter: Michele Mazzucco
>Priority: Critical
>
> Using netstat -na I see a huge number of connections in TIME_WAIT state 
> (tomcat is configured with a timeout of 20 seconds). I don't know whether 
> this issue is related to the server (kernel) or the client api (the server 
> sends messages as well)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Work started: (AXIS2-2883) CLOSE_WAIT slowly building up over the period of time.

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on AXIS2-2883 started by Glen Daniels.

> CLOSE_WAIT slowly building up over the period of time.
> --
>
> Key: AXIS2-2883
> URL: https://issues.apache.org/jira/browse/AXIS2-2883
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: client-api
>Affects Versions: 1.1
> Environment: Operating System : Solaris 
> Axis2 Version : 1.1
> Application Server : weblogic 8.1 SP6
> Using with Cocoon and weblogic DSP
>Reporter: Lakshmanan Venkatachalam
>Assignee: Glen Daniels
>Priority: Critical
>
> I am experiencing theconstant increase in close wait in the production 
> environment over the period 7 days. 
> We are using Synchronous webservices and we are calling two webservices 24 
> times every day. We have allocated the maximum of 1.5 GB per application 
> instance and we have two application instances. We are utilizing maximum of 
> 250 - 300 MB in average. So Full GC never runs in our environment.
> It seems like the client API ServiceClient.java is not cleaning up the 
> resources associated with this component. We are creating the new 
> ServiceClient component on every call we have for webservices. Though we have 
> called the cleanup() method at the end of every call to the webservices. At 
> times its not getting executed.
> But when we force garabage collection from the application, it was able to 
> clear all the CLOSE_WAIT components. Since we have similar cleanup() call on 
> finalize() method, it is able to do proper clean up when GC is collecting 
> these objects.
> Forcing GC cannot be a solution, I like to hear from axis2 experts on how we 
> can resolve this problem properly and what could be the cause for this 
> happening.
> Below is our client code for your reference.
> private WebServiceResponse invokeWebservice(OMElement inputElement,
>   Options options) throws WebServiceInvokerException {
>   ServiceClient serviceClient = null;
>   try {
>   serviceClient = new ServiceClient();
>   serviceClient.setOptions(options);
>   // This following line of code is used when we are using
>   // WS-Addressing. User has to make sure the addressing 
> MAR file in
>   // class path before enable the following line of code
>   //
>   // serviceClient.engageModule(new QName(
>   // org.apache.axis2.Constants.MODULE_ADDRESSING));
>   // Invoking synchrounous webservice
>   //
>   OMElement result = 
> serviceClient.sendReceive(inputElement);
>   
>   OMNode firstOMChild = result.getFirstOMChild();
>   // Conver the OMelements to XML String
>   //
>   Writer stringWriter = new StringWriter();
>   firstOMChild.serialize(stringWriter);
> serviceClient.cleanup();
>   stringWriter.flush();
>   // Return the Axis2WebserviceResponse
>   //
>   return new 
> Axis2WebServiceResponse(stringWriter.toString());
>   } catch (AxisFault afe) {
>   throw new WebServiceInvokerException(afe);
>   } catch (XMLStreamException xse) {
>   throw new WebServiceInvokerException(xse);
>   } catch (IOException ioe) {
>   throw new WebServiceInvokerException(ioe);
>   } finally {
>   try {
>   serviceClient.cleanup();
> serviceClient=null;
>   } catch (AxisFault axisFault) {
>   //
>   }
>   }
>   }
> }
> options are:
> Options options = new Options();
>   options.setTo(targetEPR);
>   options.setUseSeparateListener(false);
>   options.setAction(wsRequest.getAction());
>   options.setTimeOutInMilliSeconds(60);
>   options.setTransportInProtocol("http");
>   
> options.setProperty(org.apache.axis2.context.MessageContextConstants.CHUNKED, 
> org.apache.axis2.transport.http.HTTPConstants.HEADER_TRANSFER_ENCODING);
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (AXIS2-2883) CLOSE_WAIT slowly building up over the period of time.

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels reassigned AXIS2-2883:
---

Assignee: Glen Daniels  (was: Deepal Jayasinghe)

> CLOSE_WAIT slowly building up over the period of time.
> --
>
> Key: AXIS2-2883
> URL: https://issues.apache.org/jira/browse/AXIS2-2883
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: client-api
>Affects Versions: 1.1
> Environment: Operating System : Solaris 
> Axis2 Version : 1.1
> Application Server : weblogic 8.1 SP6
> Using with Cocoon and weblogic DSP
>Reporter: Lakshmanan Venkatachalam
>Assignee: Glen Daniels
>Priority: Critical
>
> I am experiencing theconstant increase in close wait in the production 
> environment over the period 7 days. 
> We are using Synchronous webservices and we are calling two webservices 24 
> times every day. We have allocated the maximum of 1.5 GB per application 
> instance and we have two application instances. We are utilizing maximum of 
> 250 - 300 MB in average. So Full GC never runs in our environment.
> It seems like the client API ServiceClient.java is not cleaning up the 
> resources associated with this component. We are creating the new 
> ServiceClient component on every call we have for webservices. Though we have 
> called the cleanup() method at the end of every call to the webservices. At 
> times its not getting executed.
> But when we force garabage collection from the application, it was able to 
> clear all the CLOSE_WAIT components. Since we have similar cleanup() call on 
> finalize() method, it is able to do proper clean up when GC is collecting 
> these objects.
> Forcing GC cannot be a solution, I like to hear from axis2 experts on how we 
> can resolve this problem properly and what could be the cause for this 
> happening.
> Below is our client code for your reference.
> private WebServiceResponse invokeWebservice(OMElement inputElement,
>   Options options) throws WebServiceInvokerException {
>   ServiceClient serviceClient = null;
>   try {
>   serviceClient = new ServiceClient();
>   serviceClient.setOptions(options);
>   // This following line of code is used when we are using
>   // WS-Addressing. User has to make sure the addressing 
> MAR file in
>   // class path before enable the following line of code
>   //
>   // serviceClient.engageModule(new QName(
>   // org.apache.axis2.Constants.MODULE_ADDRESSING));
>   // Invoking synchrounous webservice
>   //
>   OMElement result = 
> serviceClient.sendReceive(inputElement);
>   
>   OMNode firstOMChild = result.getFirstOMChild();
>   // Conver the OMelements to XML String
>   //
>   Writer stringWriter = new StringWriter();
>   firstOMChild.serialize(stringWriter);
> serviceClient.cleanup();
>   stringWriter.flush();
>   // Return the Axis2WebserviceResponse
>   //
>   return new 
> Axis2WebServiceResponse(stringWriter.toString());
>   } catch (AxisFault afe) {
>   throw new WebServiceInvokerException(afe);
>   } catch (XMLStreamException xse) {
>   throw new WebServiceInvokerException(xse);
>   } catch (IOException ioe) {
>   throw new WebServiceInvokerException(ioe);
>   } finally {
>   try {
>   serviceClient.cleanup();
> serviceClient=null;
>   } catch (AxisFault axisFault) {
>   //
>   }
>   }
>   }
> }
> options are:
> Options options = new Options();
>   options.setTo(targetEPR);
>   options.setUseSeparateListener(false);
>   options.setAction(wsRequest.getAction());
>   options.setTimeOutInMilliSeconds(60);
>   options.setTransportInProtocol("http");
>   
> options.setProperty(org.apache.axis2.context.MessageContextConstants.CHUNKED, 
> org.apache.axis2.transport.http.HTTPConstants.HEADER_TRANSFER_ENCODING);
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (AXIS2-3084) Should make inflow/outflow (at least) case insensitive in module.xml

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-3084.
-

Resolution: Fixed

Fixed in rev 784574.  Please check it out and Andreas, if you feel strongly 
this isn't the right thing to do, let's discuss and I can revert if necessary.


> Should make inflow/outflow (at least) case insensitive in module.xml
> 
>
> Key: AXIS2-3084
> URL: https://issues.apache.org/jira/browse/AXIS2-3084
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: deployment
>Reporter: Glen Daniels
>Assignee: Glen Daniels
>Priority: Minor
>
> Currently the  and  elements in module.xml must read EXACTLY 
> that way - in particular  and  will not be recognized.
> We should make the read of these elements (ModuleBuilder:160 onwards) 
> case-insensitive, IMO, to make things easier on the developer.   or 
>  shouldn't fail silently.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AXIS2-3084) Should make inflow/outflow (at least) case insensitive in module.xml

[Glen Daniels (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719151#action_12719151
 ] 

Glen Daniels commented on AXIS2-3084:
-

I can relate to your way of thinking, Andreas, but in this case I still think 
doing a case-insensitive search would be better for our users.  Clearly there 
have already been at least a few occasions (even in some of our own stuff) 
where we've stumbled across this, and it makes simple typing/memory errors when 
editing config files much less egregious.  Let me ask it another way - what's 
the downside to allowing "" as well as ""?

This is pretty much "be liberal in what you receive" except this time it's what 
we're receiving from the config file rather than a wire message.


> Should make inflow/outflow (at least) case insensitive in module.xml
> 
>
> Key: AXIS2-3084
> URL: https://issues.apache.org/jira/browse/AXIS2-3084
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: deployment
>Reporter: Glen Daniels
>Assignee: Glen Daniels
>Priority: Minor
>
> Currently the  and  elements in module.xml must read EXACTLY 
> that way - in particular  and  will not be recognized.
> We should make the read of these elements (ModuleBuilder:160 onwards) 
> case-insensitive, IMO, to make things easier on the developer.   or 
>  shouldn't fail silently.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (AXIS2-2969) AXIS2 generates only one EPR for a web service in admin console

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels reopened AXIS2-2969:
-


This wasn't "fixed" - it should be either "invalid", "won't fix", or we should 
continue discussing it...

> AXIS2 generates only one EPR for a web service in admin console
> ---
>
> Key: AXIS2-2969
> URL: https://issues.apache.org/jira/browse/AXIS2-2969
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: admin console
>Affects Versions: 1.2
> Environment: AXIS2 1.2 with Tomcat or IBM Websphere6.
>Reporter: Pierre Casenove
>Assignee: Deepal Jayasinghe
>
> Though multiple EPR are defined in the wsdl , at the server side Axis2 will 
> ignore all those and generate its own epr based on
>  - Available transports
>  - IP and Port
> - Service name
> Extract of the wsdl:
>   
>  binding="tns:WebServiceTestSoapBinding">
>location="http://192.168.31.156:9080/Dev/services/ServiceTest"/>
> 
>  binding="tns:WebServiceTestSoapBinding">
>location="http://192.168.31.156:9080/Dev/serverAuthent/ServiceTest"/>
> 
>  binding="tns:WebServiceTestSoapBinding">
>location="http://192.168.31.156:9080/Dev/clientAuthent/ServiceTest"/>
> 
>   
> Generated EPR (returned by function AxisServlet.getEPRsForService(String 
> ServiceName,String IP)):
> http://localhost:9080/fsaDev/services/ServiceTest
> Axis-user mailing list thread: 
> http://marc.info/?l=axis-user&m=118457435121917&w=2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AXIS2-3084) Should make inflow/outflow (at least) case insensitive in module.xml

[Glen Daniels (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719142#action_12719142
 ] 

Glen Daniels commented on AXIS2-3084:
-

We just need to iterate over the child elements of moduleElement and find the 
flows in a case-insensitive way.  Easy fix, just hasn't been done yet.


> Should make inflow/outflow (at least) case insensitive in module.xml
> 
>
> Key: AXIS2-3084
> URL: https://issues.apache.org/jira/browse/AXIS2-3084
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: deployment
>Reporter: Glen Daniels
>Assignee: Glen Daniels
>Priority: Minor
>
> Currently the  and  elements in module.xml must read EXACTLY 
> that way - in particular  and  will not be recognized.
> We should make the read of these elements (ModuleBuilder:160 onwards) 
> case-insensitive, IMO, to make things easier on the developer.   or 
>  shouldn't fail silently.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (AXIS2-3084) Should make inflow/outflow (at least) case insensitive in module.xml

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels reopened AXIS2-3084:
-


Not fixed.

> Should make inflow/outflow (at least) case insensitive in module.xml
> 
>
> Key: AXIS2-3084
> URL: https://issues.apache.org/jira/browse/AXIS2-3084
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: deployment
>    Reporter: Glen Daniels
>Assignee: Glen Daniels
>Priority: Minor
>
> Currently the  and  elements in module.xml must read EXACTLY 
> that way - in particular  and  will not be recognized.
> We should make the read of these elements (ModuleBuilder:160 onwards) 
> case-insensitive, IMO, to make things easier on the developer.   or 
>  shouldn't fail silently.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (AXIS2-2819) Faulty handling of JMS asynchronous calls

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels reopened AXIS2-2819:
-


We don't know this is "fixed"

> Faulty handling of JMS asynchronous calls
> -
>
> Key: AXIS2-2819
> URL: https://issues.apache.org/jira/browse/AXIS2-2819
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: Addressing
>Affects Versions: 1.2
> Environment: Windows XP / Active MQ 4.1.1 / Tomcat 5.5.17
>Reporter: Mathieu Chauvin
>Assignee: Asankha C. Perera
>
> When a JMS client gets its response from the reply queue, addressing module 
> fails with the following Exception:
> Exception in thread "JMSWorker-1" java.lang.UnsupportedOperationException
>   at java.util.AbstractList.add(AbstractList.java:151)
>   at java.util.AbstractList.add(AbstractList.java:89)
>   at org.apache.axis2.client.Options.addRelatesTo(Options.java:835)
>   at 
> org.apache.axis2.handlers.addressing.AddressingInHandler.extractRelatesToInformation(AddressingInHandler.java:248)
>   at 
> org.apache.axis2.handlers.addressing.AddressingInHandler.extractAddressingInformation(AddressingInHandler.java:169)
>   at 
> org.apache.axis2.handlers.addressing.AddressingInHandler.invoke(AddressingInHandler.java:95)
>   at org.apache.axis2.engine.Phase.invoke(Phase.java:383)
>   at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:203)
>   at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:131)
>   at 
> org.apache.axis2.transport.jms.JMSMessageReceiver$Worker.run(JMSMessageReceiver.java:249)
>   at 
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
>   at 
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
>   at java.lang.Thread.run(Thread.java:595)
> It seems that the wsa:RelatesTo header (that is, by the way, already set in 
> the relationships field of the Options class...) is beeing inserted in a List 
> that cannot be modified.
> The Exception is raised from within the JMS listener thread, and can 
> therefore not be caught nor handled in another Thread, which is, actually, 
> another problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (AXIS2-2819) Faulty handling of JMS asynchronous calls

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-2819.
-

Resolution: Incomplete

Need a test case, if this is indeed still a problem (in which case please 
attach one and reopen).

> Faulty handling of JMS asynchronous calls
> -
>
> Key: AXIS2-2819
> URL: https://issues.apache.org/jira/browse/AXIS2-2819
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: Addressing
>Affects Versions: 1.2
> Environment: Windows XP / Active MQ 4.1.1 / Tomcat 5.5.17
>Reporter: Mathieu Chauvin
>Assignee: Asankha C. Perera
>
> When a JMS client gets its response from the reply queue, addressing module 
> fails with the following Exception:
> Exception in thread "JMSWorker-1" java.lang.UnsupportedOperationException
>   at java.util.AbstractList.add(AbstractList.java:151)
>   at java.util.AbstractList.add(AbstractList.java:89)
>   at org.apache.axis2.client.Options.addRelatesTo(Options.java:835)
>   at 
> org.apache.axis2.handlers.addressing.AddressingInHandler.extractRelatesToInformation(AddressingInHandler.java:248)
>   at 
> org.apache.axis2.handlers.addressing.AddressingInHandler.extractAddressingInformation(AddressingInHandler.java:169)
>   at 
> org.apache.axis2.handlers.addressing.AddressingInHandler.invoke(AddressingInHandler.java:95)
>   at org.apache.axis2.engine.Phase.invoke(Phase.java:383)
>   at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:203)
>   at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:131)
>   at 
> org.apache.axis2.transport.jms.JMSMessageReceiver$Worker.run(JMSMessageReceiver.java:249)
>   at 
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
>   at 
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
>   at java.lang.Thread.run(Thread.java:595)
> It seems that the wsa:RelatesTo header (that is, by the way, already set in 
> the relationships field of the Options class...) is beeing inserted in a List 
> that cannot be modified.
> The Exception is raised from within the JMS listener thread, and can 
> therefore not be caught nor handled in another Thread, which is, actually, 
> another problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (AXIS2-3195) AXIOM parser's throwing NullPointerException if OMElement.getParent() is instance of OMDocument and Rampart is engaged

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels reopened AXIS2-3195:
-


Not "fixed"

> AXIOM parser's throwing NullPointerException if OMElement.getParent() is 
> instance of OMDocument and Rampart is engaged
> --
>
> Key: AXIS2-3195
> URL: https://issues.apache.org/jira/browse/AXIS2-3195
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
> Environment: Windows XP SP2, Axis2 1.2, Tomcat 6.0.13
>Reporter: Christopher Weiss
>Assignee: Ruchith Udayanga Fernando
> Attachments: BugDemoConfigFiles.zip, RampartBugDemo.zip
>
>
> Please see attached project to demonstrate the issue. With the axis2-1.2 
> release and earlier, the AXIOM parser throws a NullPointerException when 
> processing requests using Rampart:
> Thread [main] (Suspended (exception NullPointerException)) 
>  OMStAXWrapper.updateNextNode() line: 981 
>  OMStAXWrapper.updateLastNode() line: 950 
>  OMStAXWrapper.next() line: 913 
>  StAXSOAPModelBuilder(StAXOMBuilder).next() line: 111 
>  SOAPEnvelopeImpl(NodeImpl).build() line: 469 
>  SOAPMessageImpl(DocumentImpl).build() line: 476 
>  Axis2Util.getDocumentFromSOAPEnvelope(SOAPEnvelope, boolean) line: 107 
>  RampartMessageData.(MessageContext, boolean) line: 146 
>  MessageBuilder.build(MessageContext) line: 56 
>  RampartSender.invoke(MessageContext) line: 59 
>  Phase.invoke(MessageContext) line: 382 
>  AxisEngine.invoke(MessageContext) line: 522 
>  AxisEngine.send(MessageContext) line: 655 
>  OutInAxisOperationClient.send(MessageContext) line: 237 
>  OutInAxisOperationClient.execute(boolean) line: 202 
>  EchoStub.EchoOperation(OMElement) line: 127 
>  Client.main(String[]) line: 47 
> The cause of the exception is the AXIOM parser's setting the boolean variable 
> needToThrowEndDocument in the DOMStAXWrapper to true if the current node 
> being parsed has a parent node of type OMDocument..
> Temp fix: In the code, when creating an AXIOM compatible schema, we did the 
> following:
>  
> try {
>   // Get the schema is it is already AXIOM compatible, or convert it if it 
> isn't.
>   OMElement schema = docSchema instanceof OMDocument ? (OMElement) docSchema
> .getDocumentElement() : 
> org.apache.axis2.util.XMLUtils.toOM(docSchema.getDocumentElement());
>   
>   // Workaround to fix an issue with the building the OMElement if the
>   // parent is an OMDocument. Detach the element from the parent Document...
>   if (schema.getParent() != null && schema.getParent() instanceof OMDocument) 
> {
> schema.detach();
>   }
>   
> elementList.add(org.apache.axis2.databinding.utils.Constants.OM_ELEMENT_KEY);
>   elementList.add(schema);
> } catch (Exception e) {
>   throw new java.lang.RuntimeException("Can't convert schema to AXIOM!", e);
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (AXIS2-3195) AXIOM parser's throwing NullPointerException if OMElement.getParent() is instance of OMDocument and Rampart is engaged

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-3195.
-

Resolution: Invalid

If this is actually still a problem with Axiom or Rampart, please let's reopen 
or open a new issue.

> AXIOM parser's throwing NullPointerException if OMElement.getParent() is 
> instance of OMDocument and Rampart is engaged
> --
>
> Key: AXIS2-3195
> URL: https://issues.apache.org/jira/browse/AXIS2-3195
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
> Environment: Windows XP SP2, Axis2 1.2, Tomcat 6.0.13
>Reporter: Christopher Weiss
>Assignee: Ruchith Udayanga Fernando
> Attachments: BugDemoConfigFiles.zip, RampartBugDemo.zip
>
>
> Please see attached project to demonstrate the issue. With the axis2-1.2 
> release and earlier, the AXIOM parser throws a NullPointerException when 
> processing requests using Rampart:
> Thread [main] (Suspended (exception NullPointerException)) 
>  OMStAXWrapper.updateNextNode() line: 981 
>  OMStAXWrapper.updateLastNode() line: 950 
>  OMStAXWrapper.next() line: 913 
>  StAXSOAPModelBuilder(StAXOMBuilder).next() line: 111 
>  SOAPEnvelopeImpl(NodeImpl).build() line: 469 
>  SOAPMessageImpl(DocumentImpl).build() line: 476 
>  Axis2Util.getDocumentFromSOAPEnvelope(SOAPEnvelope, boolean) line: 107 
>  RampartMessageData.(MessageContext, boolean) line: 146 
>  MessageBuilder.build(MessageContext) line: 56 
>  RampartSender.invoke(MessageContext) line: 59 
>  Phase.invoke(MessageContext) line: 382 
>  AxisEngine.invoke(MessageContext) line: 522 
>  AxisEngine.send(MessageContext) line: 655 
>  OutInAxisOperationClient.send(MessageContext) line: 237 
>  OutInAxisOperationClient.execute(boolean) line: 202 
>  EchoStub.EchoOperation(OMElement) line: 127 
>  Client.main(String[]) line: 47 
> The cause of the exception is the AXIOM parser's setting the boolean variable 
> needToThrowEndDocument in the DOMStAXWrapper to true if the current node 
> being parsed has a parent node of type OMDocument..
> Temp fix: In the code, when creating an AXIOM compatible schema, we did the 
> following:
>  
> try {
>   // Get the schema is it is already AXIOM compatible, or convert it if it 
> isn't.
>   OMElement schema = docSchema instanceof OMDocument ? (OMElement) docSchema
> .getDocumentElement() : 
> org.apache.axis2.util.XMLUtils.toOM(docSchema.getDocumentElement());
>   
>   // Workaround to fix an issue with the building the OMElement if the
>   // parent is an OMDocument. Detach the element from the parent Document...
>   if (schema.getParent() != null && schema.getParent() instanceof OMDocument) 
> {
> schema.detach();
>   }
>   
> elementList.add(org.apache.axis2.databinding.utils.Constants.OM_ELEMENT_KEY);
>   elementList.add(schema);
> } catch (Exception e) {
>   throw new java.lang.RuntimeException("Can't convert schema to AXIOM!", e);
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (AXIS2-2790) Having a problem with the JavaScript call (of Google Analytics) on axis2 html after a maven site build

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-2790.
-

Resolution: Won't Fix

If this is still an issue, please feel free to reopen.

> Having a problem with the JavaScript call (of Google Analytics) on axis2 html 
> after a maven site build
> --
>
> Key: AXIS2-2790
> URL: https://issues.apache.org/jira/browse/AXIS2-2790
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: documentation, samples, build,site
> Environment: Windows XP/JDK1.5/Firefox 2.x
>Reporter: Chatra Nakkawita
>Assignee: sumedha rubasinghe
>
> The JavaScript call [1] to track a download on click is not correctly 
> displayed after a maven build site using Maven1.x.
> See 
> https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/xdocs/download/1_2/download.html
> Here you will find 
>  title="[preferred]/ws/axis2/1_2/axis2-1.2.zip" 
> onClick="javascript:urchinTracker ('/downloads/axis2-1.2.zip'); ">zip
> After a maven site build the JavaScript call will read as :
>  title="[preferred]/ws/axis2/1_2/axis2-1.2.zip" 
> onclick="javascript:urchinTracker ('/downloads/axis2-1.2.zip'); 
> ">zip
> Diff : 
> onClick="javascript:urchinTracker ('/downloads/axis2-1.2.zip'); " |
> onclick="javascript:urchinTracker ('/downloads/axis2-1.2.zip'); "
> Note that the single quotes ( ' ) in the function is converted to '
> How can we make the call remain as : onClick="javascript:urchinTracker 
> ('/downloads/axis2-1.2.zip'); "
> This is required for the tracking of downloads of Google Analytics [2]
> Thanks,
> Chatra
> [1]http://www.google.com/support/analytics/bin/answer.py?answer=27242&topic=7292
> [2]http://www.google.com/support/analytics/bin/answer.py?answer=26908

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (AXIS2-2790) Having a problem with the JavaScript call (of Google Analytics) on axis2 html after a maven site build

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels reopened AXIS2-2790:
-


Not "fixed"

> Having a problem with the JavaScript call (of Google Analytics) on axis2 html 
> after a maven site build
> --
>
> Key: AXIS2-2790
> URL: https://issues.apache.org/jira/browse/AXIS2-2790
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: documentation, samples, build,site
> Environment: Windows XP/JDK1.5/Firefox 2.x
>Reporter: Chatra Nakkawita
>Assignee: sumedha rubasinghe
>
> The JavaScript call [1] to track a download on click is not correctly 
> displayed after a maven build site using Maven1.x.
> See 
> https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/xdocs/download/1_2/download.html
> Here you will find 
>  title="[preferred]/ws/axis2/1_2/axis2-1.2.zip" 
> onClick="javascript:urchinTracker ('/downloads/axis2-1.2.zip'); ">zip
> After a maven site build the JavaScript call will read as :
>  title="[preferred]/ws/axis2/1_2/axis2-1.2.zip" 
> onclick="javascript:urchinTracker ('/downloads/axis2-1.2.zip'); 
> ">zip
> Diff : 
> onClick="javascript:urchinTracker ('/downloads/axis2-1.2.zip'); " |
> onclick="javascript:urchinTracker ('/downloads/axis2-1.2.zip'); "
> Note that the single quotes ( ' ) in the function is converted to '
> How can we make the call remain as : onClick="javascript:urchinTracker 
> ('/downloads/axis2-1.2.zip'); "
> This is required for the tracking of downloads of Google Analytics [2]
> Thanks,
> Chatra
> [1]http://www.google.com/support/analytics/bin/answer.py?answer=27242&topic=7292
> [2]http://www.google.com/support/analytics/bin/answer.py?answer=26908

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (AXIS2-3274) Axis2 kernel logging on WAS 6.1

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels reopened AXIS2-3274:
-


Not "fixed"

> Axis2 kernel logging on WAS 6.1
> ---
>
> Key: AXIS2-3274
> URL: https://issues.apache.org/jira/browse/AXIS2-3274
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 1.3
> Environment: Axis2 1.3 under Websphere 6.1
>Reporter: Pierre Casenove
>Assignee: Charitha Kankanamge
>Priority: Minor
>
>  When deploying Axis2 based application, websphere tries to instantiates 
> AxisServlet and throws following exception:
>  Caused by: org.apache.commons.logging.LogConfigurationException:
>  java.lang.ClassNotFoundException:
>  org.apache.commons.logging.impl.Log4jFactory
>at 
> org.apache.commons.logging.LogFactory$2.run(LogFactory.java:609)
>at 
> java.security.AccessController.doPrivileged(AccessController.java:193)
>at 
> org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:561)
>at 
> org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:352)
>at 
> org.apache.commons.logging.LogFactory.getLog(LogFactory.java:395)
>at
>  org.apache.axis2.transport.http.AxisServlet.(AxisServlet.java:79)
>  The root cause is explained here :
>  
> http://wiki.apache.org/jakarta-commons/Logging/FrequentlyAskedQuestions?highlight=%28websphere%29
>  In order to get everything works, I had to modify axis2-kernel.jar to add a 
> commons-logging.properties containing:
>  priority=1
>  
> org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl
>  org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
> I tried to first put this file in my web app classpath but it didn't work.
> The only solution was to put it in Axis2 Kernel jar.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (AXIS2-3274) Axis2 kernel logging on WAS 6.1

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-3274.
-

Resolution: Cannot Reproduce

Correct resolution.

> Axis2 kernel logging on WAS 6.1
> ---
>
> Key: AXIS2-3274
> URL: https://issues.apache.org/jira/browse/AXIS2-3274
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 1.3
> Environment: Axis2 1.3 under Websphere 6.1
>Reporter: Pierre Casenove
>Assignee: Charitha Kankanamge
>Priority: Minor
>
>  When deploying Axis2 based application, websphere tries to instantiates 
> AxisServlet and throws following exception:
>  Caused by: org.apache.commons.logging.LogConfigurationException:
>  java.lang.ClassNotFoundException:
>  org.apache.commons.logging.impl.Log4jFactory
>at 
> org.apache.commons.logging.LogFactory$2.run(LogFactory.java:609)
>at 
> java.security.AccessController.doPrivileged(AccessController.java:193)
>at 
> org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:561)
>at 
> org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:352)
>at 
> org.apache.commons.logging.LogFactory.getLog(LogFactory.java:395)
>at
>  org.apache.axis2.transport.http.AxisServlet.(AxisServlet.java:79)
>  The root cause is explained here :
>  
> http://wiki.apache.org/jakarta-commons/Logging/FrequentlyAskedQuestions?highlight=%28websphere%29
>  In order to get everything works, I had to modify axis2-kernel.jar to add a 
> commons-logging.properties containing:
>  priority=1
>  
> org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl
>  org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
> I tried to first put this file in my web app classpath but it didn't work.
> The only solution was to put it in Axis2 Kernel jar.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (AXIS2-4040) Web Service with Java generic type

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-4040.
-

Resolution: Invalid

> Web Service with Java generic type
> --
>
> Key: AXIS2-4040
> URL: https://issues.apache.org/jira/browse/AXIS2-4040
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: wsdl
>Affects Versions: 1.4.1
> Environment: JDK 1.5
>Reporter: Antonio Mantuano
>Priority: Blocker
>
> Hi,
> in my application i want expose my spring bean's as a Web Service.
> i have a problem with java generic type.
> Example:
> //generic Inteface of my class
> //the method execute receive a Request object
> public interface IService {
>//the method execute receive a Request object
>public void execute(Request request);
> }
> public class Request {
>private Input parameter;
>public void setParameter(Input parameter) {
>   this.parameter = parameter;
>}
>public Input getParameter() {
>   return parameter;
>}
> }
> The implementation of IService specify the correct type of the fiels 
> parameter:
> public class HelloWorldService implements IService {
>public void execute(Request request) {
>   // implementation //
>}
> }
> The wsdl generated have'nt references to the HelloInput class
> In the wsdl the field paramater is declared as anyType
> 
>
>type="xs:anyType" /> 
>
> 
> 
>
>   
>  
>  type="xs:anyType" /> 
>  
>   
>
> 
> How is possible to obtain a wsdl with the correct type HelloInput?
> You can help me?
> thank you

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (AXIS2-4040) Web Service with Java generic type

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels reopened AXIS2-4040:
-


"fixed" was an inappropriate resolution.

> Web Service with Java generic type
> --
>
> Key: AXIS2-4040
> URL: https://issues.apache.org/jira/browse/AXIS2-4040
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: wsdl
>Affects Versions: 1.4.1
> Environment: JDK 1.5
>Reporter: Antonio Mantuano
>Priority: Blocker
>
> Hi,
> in my application i want expose my spring bean's as a Web Service.
> i have a problem with java generic type.
> Example:
> //generic Inteface of my class
> //the method execute receive a Request object
> public interface IService {
>//the method execute receive a Request object
>public void execute(Request request);
> }
> public class Request {
>private Input parameter;
>public void setParameter(Input parameter) {
>   this.parameter = parameter;
>}
>public Input getParameter() {
>   return parameter;
>}
> }
> The implementation of IService specify the correct type of the fiels 
> parameter:
> public class HelloWorldService implements IService {
>public void execute(Request request) {
>   // implementation //
>}
> }
> The wsdl generated have'nt references to the HelloInput class
> In the wsdl the field paramater is declared as anyType
> 
>
>type="xs:anyType" /> 
>
> 
> 
>
>   
>  
>  type="xs:anyType" /> 
>  
>   
>
> 
> How is possible to obtain a wsdl with the correct type HelloInput?
> You can help me?
> thank you

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (AXIS2-2856) Module Config Changes

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels reopened AXIS2-2856:
-


This has certainly not been fixed, and should remain open until it's actually 
resolved.

> Module Config Changes
> -
>
> Key: AXIS2-2856
> URL: https://issues.apache.org/jira/browse/AXIS2-2856
> Project: Axis 2.0 (Axis2)
>  Issue Type: Improvement
>Reporter: Davanum Srinivas
>    Assignee: Glen Daniels
>Priority: Critical
>
> Discussion here - http://marc.info/?t=11813227841&r=1&w=2
> thanks,
> dims

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

One more thing..

[Glen Daniels]

If you'd like to discuss the PMC reorganization issue, please keep that
thread on gene...@ws instead of any of the project-specific lists.

Thanks!

--Glen

Board report for June, and splitting the project

[Glen Daniels]

Hi all!

Two things.  First off, it's of course that time again.  Kurt (thanks Kurt)
has been kind enough to set up the template report at

http://wiki.apache.org/ws/ReportForJun2009

Some content has already been added, but please feel encouraged to add your
project's status/highlights, or anything you feel needs to be communicated up
to the board level.

In particular, I was hoping to have more conversation and consensus around
the "splitting the project" idea, but that has been slow to get going.  As a
reminder, please visit the wiki page for this discussion at:

http://wiki.apache.org/ws/FrontPage/WebServicesPMCReorg

There are proposals and comments there - please feel free to add more, or to
add yourself as a supporter to any of the proposals there currently.

Unfortunately there was a bit of a date snafu with the automated reminder
system this time around, and so I thought we had another week and a half
before the report was due... but actually it's due by the 15th, which is
Monday.  Since I do not think we're going to have enough time for an adequate
discussion before then, I am planning to ask the board to allow us to report
at next month's meeting instead (we'll stay on our regular Mar/Jun/Sept/Dec
schedule, just move this one report).

Thanks,
--Glen
  Your Friendly Neighborhood PMC Chair

Re: [ANNOUNCE] Axis2 1.5

[Glen Daniels]

Hi Andreas:

Good catch - I just added it to svn.

https://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.5/

Thanks,
--Glen

Andreas Veithen wrote:
> Glen, where is the Subversion tag for this release?
> 
> Andreas
> 
> On Tue, Jun 9, 2009 at 14:36, Glen Daniels wrote:
>> Hi all:
>>
>> The Apache Axis2 team is pleased to announce the release of Axis2 version 
>> 1.5.
>>
>> Major Changes Since 1.4.1:
>> - Refactored, pluggable transports (separate jars, with deployer)
>> - Clustering improvements (works with EC2)
>> - Over 100 JIRA issues resolved
>>
>> You can find the new version at the usual location:
>>  http://ws.apache.org/axis2
>>
>> Please report any issues via JIRA:
>>  http://issues.apache.org/jira/browse/AXIS2.
>>
>> As always, we welcome any and all feedback at:
>>  axis-dev@ws.apache.org - for developer-related questions/concerns
>>  axis-u...@ws.apache.org - for general questions, usage, etc.
>>
>> Thanks for your interest in Apache Axis2!
>>
>> --Glen Daniels
>>

[jira] Commented: (AXIS2-4371) Unable to compile class for JSP: axis2-web/viewphases.jsp

[Glen Daniels (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718205#action_12718205
 ] 

Glen Daniels commented on AXIS2-4371:
-

+1, Andreas.  Can you merge your fixes over to the branch and I'll update the 
version number over there?

I'm going to try and nail the ever-popular CLOSE_WAIT/too-many-open-files issue 
in the next week or so as well.


> Unable to compile class for JSP: axis2-web/viewphases.jsp
> -
>
> Key: AXIS2-4371
> URL: https://issues.apache.org/jira/browse/AXIS2-4371
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: admin console
>Affects Versions: 1.5
> Environment: Java 5, tomcat 5
>Reporter: Alexis Midon
>Assignee: Andreas Veithen
>Priority: Critical
> Fix For: 1.6
>
> Attachments: AXIS2-4371.log.txt
>
>
> Compilation errors in axis-admin console.
> To reproduce:
>  . go the axis2/axis2-admin
>  . click "Available phases"   (axis2/axis2-admin/listPhases)
>  . traces appear in the server console
> Below is one of the error messages, see the attached log file for more.
> An error occurred at line: 28 in the jsp file: /axis2-web/viewphases.jsp
> Type mismatch: cannot convert from List to ArrayList
> 25:  <%
> 26:  PhasesInfo phases = 
> (PhasesInfo)request.getSession().getAttribute(Constants.PHASE_LIST);
> 27:  request.getSession().setAttribute(Constants.PHASE_LIST,null);
> 28:  ArrayList tempList = phases.getGlobalInflow();
> 29:  %>System Pre-defined Phases
> 30:  InFlow Up to Dispatcher
> 31:  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AXIS2-4371) Unable to compile class for JSP: axis2-web/viewphases.jsp

[Glen Daniels (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718171#action_12718171
 ] 

Glen Daniels commented on AXIS2-4371:
-

I agree re: considering a quick 1.5.1, Deepal.


> Unable to compile class for JSP: axis2-web/viewphases.jsp
> -
>
> Key: AXIS2-4371
> URL: https://issues.apache.org/jira/browse/AXIS2-4371
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: admin console
>Affects Versions: 1.5
> Environment: Java 5, tomcat 5
>Reporter: Alexis Midon
>Assignee: Andreas Veithen
>Priority: Critical
> Fix For: 1.6
>
> Attachments: AXIS2-4371.log.txt
>
>
> Compilation errors in axis-admin console.
> To reproduce:
>  . go the axis2/axis2-admin
>  . click "Available phases"   (axis2/axis2-admin/listPhases)
>  . traces appear in the server console
> Below is one of the error messages, see the attached log file for more.
> An error occurred at line: 28 in the jsp file: /axis2-web/viewphases.jsp
> Type mismatch: cannot convert from List to ArrayList
> 25:  <%
> 26:  PhasesInfo phases = 
> (PhasesInfo)request.getSession().getAttribute(Constants.PHASE_LIST);
> 27:  request.getSession().setAttribute(Constants.PHASE_LIST,null);
> 28:  ArrayList tempList = phases.getGlobalInflow();
> 29:  %>System Pre-defined Phases
> 30:  InFlow Up to Dispatcher
> 31:  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[ANNOUNCE] Axis2 1.5

[Glen Daniels]

Hi all:

The Apache Axis2 team is pleased to announce the release of Axis2 version 1.5.

Major Changes Since 1.4.1:
- Refactored, pluggable transports (separate jars, with deployer)
- Clustering improvements (works with EC2)
- Over 100 JIRA issues resolved

You can find the new version at the usual location:
  http://ws.apache.org/axis2

Please report any issues via JIRA:
  http://issues.apache.org/jira/browse/AXIS2.

As always, we welcome any and all feedback at:
  axis-dev@ws.apache.org - for developer-related questions/concerns
  axis-u...@ws.apache.org - for general questions, usage, etc.

Thanks for your interest in Apache Axis2!

--Glen Daniels

1.5 release status

[Glen Daniels]

Hi folks.

Just FYI - I haven't officially announced the 1.5 release yet because I'm
doing a few changes to the site (and hopefully the process around the site as
well).  The artifacts are in Maven already, however, and the dist is where
you'd expect. :)

I'll do the actual announcement tonight or tomorrow.

Thanks for your patience,
--Glen

Re: svn commit: r776555 - in /webservices/axis2/trunk/java/modules: jaxws/src/org/apache/axis2/jaxws/framework/ kernel/src/org/apache/axis2/ kernel/src/org/apache/axis2/deployment/ kernel/src/org/apac

[Glen Daniels]

Andreas Veithen wrote:
> Amila,
> 
> Can you fix the typo in the value of the
> ENABLE_CHILD_FIRST_CLASS_LOADING constant? (there is an "i" missing)

While we're at it, what do you think of changing it to simply
"ChildFirstClassLoading"?  The "Enable" part seems redundant and only leads
to more typing

true

--Glen

[RESOLVE] Release Axis2 1.5

[Glen Daniels]

Hey folks!

Axis2 1.5 release vote passes with 8 +1's (7 binding) and no -1's.

I'll be doing the actual release tomorrow after I get home from my current
biz trip.

Thanks,
--Glen

Re: [axis2] AxisConfiguration.getService() and inactive services

[Glen Daniels]

Hi Deepal:

Deepal jayasinghe wrote:
> Yes, there is a difference. One method is for management other method is
> for dispatching.
> So at the runtime when a message receive we call getService, and if we
> want to activate, inactivate we call other method.

Throwing an exception to do this is (IMHO) bad code.  It's expensive, slower,
non-intuitive (what would you expect "getService()" to do?) and just plain
annoying for people calling this method.

getService(name) should return the AxisService matching the name if there is
one, period, end of story, just like all the other accessors like it do.

If you don't want the dispatch code to call "isActive()" on the resulting
service (which IMHO isn't that egregious), a getActiveService(name) utility
method would be fine, which would simply return null if there was a service
by the specified name that was inactive.  No exceptions necessary.

Thoughts?

--Glen

P.S.  This is all not to mention that "getServiceForActivation()" is a
terrible name for a method that simply returns you a service.

> Deepal
>> Hi y'all:
>>
>> So I'm cleaning up a little code and javadoc, and happened to come across
>> AxisConfiguration.getService()... which *throws an Exception* if you ask for
>> an inactive service.
>>
>> ...which is why we have a second method called "getServiceForActivation()"
>> that simply avoids the check and the exception.
>>
>> Does this make sense?  Why?
>>
>> --Glen
>>
>>   
> 
> 

Re: svn commit: r776172 - in /webservices/axis2/trunk/java/modules: jaxws/src/org/apache/axis2/jaxws/handler/SOAPHeadersAdapter.java kernel/src/org/apache/axis2/deployment/DeploymentEngine.java kernel

[Glen Daniels]

Hi Andreas:

Andreas Veithen wrote:
> What do you mean by JDK 1.5 can't compile @Override annotations???

In JDK 1.5, @Override is supported only for superclass methods, and using it
on an interface method produces a compiler error. :(  This sucks, but until
we move off 1.5 that's what we seem stuck with.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5008260

--Glen

[axis2] AxisConfiguration.getService() and inactive services

[Glen Daniels]

Hi y'all:

So I'm cleaning up a little code and javadoc, and happened to come across
AxisConfiguration.getService()... which *throws an Exception* if you ask for
an inactive service.

...which is why we have a second method called "getServiceForActivation()"
that simply avoids the check and the exception.

Does this make sense?  Why?

--Glen

Web Services PMC - Organization and futures

[Glen Daniels]

[PLEASE KEEP REPLIES TO THIS THREAD ON "gene...@ws". If you're not on it and
interested, please subscribe.]

Hi all:

June approaches, and with it another WS PMC board report.  After the March
report, we were again asked by the board what's up with our project's
organization.  As such, I'd like to re-open this discussion here, in hopes
that we can achieve a real consensus this time around, whatever the outcome.

PLEASE NOTE - we all have opinions, and while we certainly would like to sway
others to our point of view, let's make sure that we keep the conversation
respectful and considerate of each other's ideas (no matter how totally
insane they might sound to us. :) ).

Toward this end I've spun up a wiki page:

http://wiki.apache.org/ws/FrontPage/WebServicesPMCReorg

I'd like to record the proposals here, as well as a bullet-item list of
points that people think are important to consider in the discussion.  I did
a very quick start of a couple of items, please feel free to jump in and add
/ edit stuff.

If it looks like we're heading towards some kind of agreement in the next
couple of weeks, that's awesome.  If it appears we can't reach consensus, I'd
love to hear ideas as to how we should proceed - but for now, let's just talk
about it again and see what comes up.

Thanks,
--Glen
  Your friendly neighborhood PMC chair

[VOTE] Release Axis2 1.5

[Glen Daniels]

Hi Axis Developers:

The 1.5 release candidate has been stable for a couple of weeks now, and thus
I'd like to kick off a VOTE to officially release 1.5.  The usual 72 hour
window applies.

You can find the distribution files in here:

http://people.apache.org/~gdaniels/stagingRepo/org/apache/axis2/distribution/1.5/

And the M2 repository with everything is at:

http://people.apache.org/~gdaniels/stagingRepo

The SVN tag is:

https://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.5RC

...and I'll add a proper "v1.5" tag as soon as this release goes final.

Please offer your VOTE (and indicate binding/non-binding).

Here's my +1 (binding).

Many thanks,
--Glen

Re: Axis2 API design issue, Should we fix it?

[Glen Daniels]

Amila Suriarachchi wrote:
> Hm - it seems like you didn't actually get my point.  We CAN'T
> return the
> actual allServices map because that would be breaking the abstraction
> boundary provided by the class.
>
> As I remember this change was done to avoid concurrent modifications to
> service map[1].

Right - before this change we were doing something actively bad/wrong, i.e.
returning the internal map.  After the change we were returning a cloned copy
of the map (though not using clone() for some reason), which is good in that
it prevented people from misusing it.

> At that time services map was a HashMap and could not fix the issue by
> changing it to a ConcurrentHashMap since API method returns a HashMap.
> 
> Currently anyone can get a copy of internal map (I think we can not use
> clone() method since internal implementation is ConcurrentHashMap and we
> need to return a HashMap). And if they want to add or remove service
> they have to use addService and removeService respectively.
>
> Keith, if you really need the internal map IMHO best way is to add a new
> API method.

Ah, no.  The "best way" is NOT TO OFFER ACCESS TO THE INTERNAL MAP.

Keith's suggestion is to change the API so that it returns a Map - this would
be much more correct since it increases the level of abstraction for the
method, and would therefore let us, the implementors, freely decide how this
should work internally.  Right now we have problems because someone made this
method overly specific, and this is what we should fix.  (I was incorrect
earlier when I said this wouldn't break people, btw - I was thinking about
stuff like getServices().get("MyService"), but of course "HashMap foo =
getServices()" would fail.  I still think we should fix it.)

My comment is that we should not only return a Map, we should change the
implementation to make sure the Map is immutable, and make sure the JavaDoc
explains what is going on.

Make sense?

--Glen

Re: Axis2 API design issue, Should we fix it?

[Glen Daniels]

keith chapman wrote:
> Um - we aren't currently returning the actual Map, we're returning a
> clone of
> it (just done manually instead of using clone()).  You had suggested
> returning the actual Map itself, which is what I was reacting to
> above.  I'm
> not saying the API should go away.
> 
> The reason we have implemented a clone is the limitation in the API. If
> the return type was Map we could have returned the allServices map.
> Wouldn't this clone be expensive when there are lots of services deployed?

Hm - it seems like you didn't actually get my point.  We CAN'T return the
actual allServices map because that would be breaking the abstraction
boundary provided by the class.  There is (and should be) a contract about
how you add and remove services - if you don't follow the contract, then
stuff like engaging global modules doesn't happen.  In our case this stuff
lives in the code in addServiceGroup() (whether or not that's where it should
live is debatable, but the point is that it exists).  If someone were to mess
around with the actual contents of allServices, that would produce undefined
results.

This is basic OOP - don't expose the inner workings of your class by offering
mutable references to private data.

Instead of cloning, we could just use Collections.unmodifiableMap() for
speed, but we'd need to be clear (in the code and the JavaDoc) whether we're
returning a "moment in time" (i.e. a clone()) or a "live view" (which is I
think what unmodifiableMap() gives you) - i.e. if some other thread deploys a
service while I have the reference, can I see the new service or not?

--Glen

Re: Axis2 API design issue, Should we fix it?

[Glen Daniels]

keith chapman wrote:
> > In my view this is highly inefficient, especially if you have
> plenty of
> > services in the system. Wouldn't it be better to fix the API and
> return
> > a Map instead of a HashMap? If we did that we could simple return
> > allServices instead of returning a copy of it.
> 
> You don't want to return an actual reference to a mutable object
> that backs a
> significant data model - otherwise people could just get that Map and
> (mistakenly or maliciously) randomly add and delete services.
>  
> Agreed. But now that we've been doing it people may have code that
> expect it to be there. So we need a mechanism for returning this map.

Um - we aren't currently returning the actual Map, we're returning a clone of
it (just done manually instead of using clone()).  You had suggested
returning the actual Map itself, which is what I was reacting to above.  I'm
not saying the API should go away.


Of course, if we had any kind of reasonable JavaDoc, there would be a clear
indication in the API docs that the returned HashMap was in fact a clone and
that inserting or removing things from it would have no effect on the system.


Thanks,
--Glen

Re: Axis2 API design issue, Should we fix it?

[Glen Daniels]

Hi Keith!

keith chapman wrote:
> Due to a design issue in the Axis2 API we have implemented the
> getServices() method as follows,
> 
> public HashMap getServices() {
> HashMap hashMap = new HashMap AxisService>(this.allServices.size());
> String key;
> for (Iterator iter =
> this.allServices.keySet().iterator(); iter.hasNext();){
> key = iter.next();
> hashMap.put(key, this.allServices.get(key));
> }
> return hashMap;
> }
> 
> In my view this is highly inefficient, especially if you have plenty of
> services in the system. Wouldn't it be better to fix the API and return
> a Map instead of a HashMap? If we did that we could simple return
> allServices instead of returning a copy of it.

You don't want to return an actual reference to a mutable object that backs a
significant data model - otherwise people could just get that Map and
(mistakenly or maliciously) randomly add and delete services.

However, your point about the HashMap in the API is entirely right - we
should make it a Map (which shouldn't break anyone already using it in it's
more specific form).  Also, I'm not sure why we're not just returning
allServices.clone()... NIH? :)

> If we are making this change I propose that we fix this for modules,
> transports as well.

Sure.

--Glen

[ANNOUNCE] Axis2 1.5 Release Candidate refreshed and ready for testing

[Glen Daniels]

Hi all!

New version of Axis2 1.5 Release Candidate is ready, including a)
NOTICE/LICENSE files in the jars, b) some JiBX fixes from Dennis, c) some
fixes from Amila, d) a README which is more clear about building from
scratch.  Please check it out if you get a chance, and let me know if there
are any issues.  If I don't hear anything back I'll start a VOTE early next
week to accept these bits as 1.5 proper.

You can find the distribution files in here:

http://people.apache.org/~gdaniels/stagingRepo/org/apache/axis2/distribution/1.5/

And the M2 repository with everything is of course:

http://people.apache.org/~gdaniels/stagingRepo

Thanks,
--Glen

[jira] Resolved: (AXIS2-4313) Some MTOMPolicy module improvements are not merged to Axis2 1.5 branch

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2-4313.
-

Resolution: Fixed

Patch applied and tested.  Thanks Nandana.

> Some MTOMPolicy module improvements are not merged to Axis2 1.5 branch
> --
>
> Key: AXIS2-4313
> URL: https://issues.apache.org/jira/browse/AXIS2-4313
> Project: Axis 2.0 (Axis2)
>  Issue Type: Improvement
>  Components: mtompolicy
> Environment: Axis2 1.5 RC
>Reporter: Nandana Mihindukulasooriya
>    Assignee: Glen Daniels
> Fix For: 1.5
>
> Attachments: MTOMPolicy.patch
>
>
> Some of the improvements done on the Axis2 trunk  after  branching are not 
> merged to Axis2 1.5 branch. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: MTOM Policy in Axis2 1.5

[Glen Daniels]

Just read your note more carefully, and noticed the patch.  I'll go apply it!

--Glen

Glen Daniels wrote:
> Hi Nandana!
> 
> Turns out there were a few other issues with the 1.5 RC, so we're going to do
> another one anyway.  As such, please do go ahead and apply your fixes to the
> branch if you're confident they're solid.  I was hoping to roll out another
> RC today but it looks like it might be Monday.
> 
> Thanks,
> --Glen
> 
> Nandana Mihindukulasooriya wrote:
>> Hi Dobri,
>>  Sorry I was on vacation, just noticed the mail. It seems we have
>> some improvements in the trunk which are not there in the 1.5 branch. I
>> created an issue and attached the patch that is needed to bring those
>> improvements to Axis2 1.5 branch.But as this is the last minute change,
>> I think it's Glen's call whether to apply these to 1.5 branch or not. I
>> tested locally with changes and everything was fine and these changes
>> doesn't have any cross cutting issues. But let's wait for Glen's opinion.
>>
>> thanks,
>> Nandana
>>
>> [1] - https://issues.apache.org/jira/browse/AXIS2-4313  
>>
>> On Mon, Apr 13, 2009 at 6:55 PM, Dobri Kitipov
>> mailto:kdobrik.ax...@googlemail.com>> wrote:
>>
>> Hi Nandana,
>> do you plan to include MTOM policy functionality into Axis2 1.5?
>>
>> Thank you,
>> Dobri
>>
>>
>>
>>

Re: MTOM Policy in Axis2 1.5

[Glen Daniels]

Hi Nandana!

Turns out there were a few other issues with the 1.5 RC, so we're going to do
another one anyway.  As such, please do go ahead and apply your fixes to the
branch if you're confident they're solid.  I was hoping to roll out another
RC today but it looks like it might be Monday.

Thanks,
--Glen

Nandana Mihindukulasooriya wrote:
> Hi Dobri,
>  Sorry I was on vacation, just noticed the mail. It seems we have
> some improvements in the trunk which are not there in the 1.5 branch. I
> created an issue and attached the patch that is needed to bring those
> improvements to Axis2 1.5 branch.But as this is the last minute change,
> I think it's Glen's call whether to apply these to 1.5 branch or not. I
> tested locally with changes and everything was fine and these changes
> doesn't have any cross cutting issues. But let's wait for Glen's opinion.
> 
> thanks,
> Nandana
> 
> [1] - https://issues.apache.org/jira/browse/AXIS2-4313  
> 
> On Mon, Apr 13, 2009 at 6:55 PM, Dobri Kitipov
> mailto:kdobrik.ax...@googlemail.com>> wrote:
> 
> Hi Nandana,
> do you plan to include MTOM policy functionality into Axis2 1.5?
> 
> Thank you,
> Dobri
> 
> 
> 
>