[jira] [Commented] (AXIS2-5115) debug log level makes the EndpointInterfaceDescriptionImpl not initialized correctly
[
https://issues.apache.org/jira/browse/AXIS2-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085002#comment-13085002
]
Ivan commented on AXIS2-5115:
-
Hi, Andreas, the changes fix the issue, please help to port it to 1.6, too.
Thanks.
> debug log level makes the EndpointInterfaceDescriptionImpl not initialized
> correctly
>
>
> Key: AXIS2-5115
> URL: https://issues.apache.org/jira/browse/AXIS2-5115
> Project: Axis2
> Issue Type: Bug
> Components: jaxws
>Affects Versions: 1.6.0
>Reporter: Ivan
> Labels: Geronimo
>
> While constructing the EndpointInterfaceDescriptionImpl instance from WSDL on
> the line 1222 of EndpointDescriptionImpl, if the log level is configured with
> debug, some internal variable like soapParameterStyle is initialized, and
> even after updating the SEI in the following codes, they will not be
> re-initialized again.
> {code}
> endpointInterfaceDescription = new EndpointInterfaceDescriptionImpl(this);
> // Update the EndpointInterfaceDescription created
> with WSDL with information from the
> // annotations in the SEI
>
> ((EndpointInterfaceDescriptionImpl)endpointInterfaceDescription)
>
> .updateWithSEI(composite.getCorrespondingClass());
> {code}
> {code}
> EndpointInterfaceDescriptionImpl(EndpointDescriptionImpl parent) {
> parentEndpointDescription = parent;
> dbc = new DescriptionBuilderComposite();
> AxisService axisService = parentEndpointDescription.getAxisService();
> if (axisService != null) {
> ArrayList publishedOperations =
> axisService.getPublishedOperations();
> Iterator operationsIterator = publishedOperations.iterator();
> while (operationsIterator.hasNext()) {
> AxisOperation axisOperation =
> (AxisOperation)operationsIterator.next();
> addOperation(new OperationDescriptionImpl(axisOperation,
> this));
> }
> }
> }
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
[jira] [Commented] (AXIS2-5062) Connection is not released while using JAXWS client API
[
https://issues.apache.org/jira/browse/AXIS2-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085008#comment-13085008
]
Hudson commented on AXIS2-5062:
---
Integrated in axis2-1.6 #70 (See [https://builds.apache.org/job/axis2-1.6/70/])
AXIS2-5062: Merged r1157517 and r1157535 to the 1.6 branch.
veithen :
Files :
*
/axis/axis2/java/core/branches/1_6/modules/jaxws-integration/test/org/apache/axis2/jaxws/dispatch/SOAPMessageDispatchTests.java
*
/axis/axis2/java/core/branches/1_6/modules/jaxws/src/org/apache/axis2/jaxws/client/dispatch/BaseDispatch.java
* /axis/axis2/java/core/branches/1_6
> Connection is not released while using JAXWS client API
> ---
>
> Key: AXIS2-5062
> URL: https://issues.apache.org/jira/browse/AXIS2-5062
> Project: Axis2
> Issue Type: Bug
> Components: jaxws, transports
>Affects Versions: 1.6.0
>Reporter: Ivan
> Labels: Geronimo
> Attachments: AXIS2-5062-Dispatch.patch, AXIS2-5062-Port.patch
>
>
> 1. Using Dispatch API
> A bit more description for my case, the server side is a simple web service,
> for the client side, the codes are something like :
> --->
> Service service = new HelloService();
> Dispatch dispatchJaxb = service.createDispatch(PORT_QNAME,
> JAXBContext.newInstance(org.test.ObjectFactory.class),
> javax.xml.ws.Service.Mode.PAYLOAD);
> dispatchJaxb.invokeOneWay(new HelloRequest());
> <---
> After adding some code fragments in the finally block of
> BaseDispatch.invokeOneWay method, it looks to me work fine.
> --->
> try {
> if (requestMsgCtx != null &&
> requestMsgCtx.getAxisMessageContext() != null) {
> org.apache.axis2.context.MessageContext axisMsgCtx =
> requestMsgCtx.getAxisMessageContext();
> if (axisMsgCtx.getTransportOut() != null &&
> axisMsgCtx.getTransportOut().getSender() != null) {
>
> axisMsgCtx.getTransportOut().getSender().cleanup(axisMsgCtx);
> }
> }
> } catch (Exception ignore) {
> }
> <---
> I also googled this issue, and do found a lot of information for the same
> timeout exception, also read some related codes
> a. In the HttpSender, there is a method named cleanup, which is used to
> release the connection, but it has the precondition to configure the
> AUTO_RELEASE_CONNECTION. And actually I did not see other setting
> configurations in the Axis2 codes, and think that it should be configured by
> the users in the Options ?
> b. Some posts in the mail list recommended to call the
> getTransport().cleanup() in the Axis2 specific client codes. And in the
> testing scenario above, since the standard JAX-WS API is used, suppose that
> Axis2 should do this ?
> And very appreciated with any comment ? Thanks.
> 2. I might find another connection leak while using JAXWS API on client side.
> In the scenario below :
> For the server side, it requires basic authentication.
> The client codes are something like :
> HelloPort helloPort = (HelloPort)service.getPort(HelloPort.class);
> helloPort.echo("hello");
> The client codes did not set the user name and password by the
> BindingProvider interface, so the server return a 404 to the client side,
> then the method HttpSender.handleResponse will enter the fourth block :
> private void handleResponse(MessageContext msgContext,
> HttpMethodBase method) throws IOException {
> int statusCode = method.getStatusCode();
> log.trace("Handling response - " + statusCode);
> if (statusCode == HttpStatus.SC_OK) {
> // Save the HttpMethod so that we can release the connection when
> cleaning up
> msgContext.setProperty(HTTPConstants.HTTP_METHOD, method);
> processResponse(method, msgContext);
> } else if (statusCode == HttpStatus.SC_ACCEPTED) {
> /* When an HTTP 202 Accepted code has been received, this will
> be the case of an execution
>* of an in-only operation. In such a scenario, the HTTP
> response headers should be returned,
>* i.e. session cookies. */
> obtainHTTPHeaderInformation(method, msgContext);
> // Since we don't expect any content with a 202 response, we
> must release the connection
> method.releaseConnection();
> } else if (statusCode == HttpStatus.SC_INTERNAL_SERVER_ERROR ||
> statusCode == HttpStatus.SC_BAD_REQUEST) {
> // Save the HttpMethod so that we can release the connection when
> cleaning up
> msgContext.setProperty(HTTPConstants.HTTP_METHOD, method);
> Header contenttypeHeader =
>
> method.getResponseHeader(HTTPConstants.HEADER_CONT
[jira] [Resolved] (AXIS2-5062) Connection is not released while using JAXWS client API
[
https://issues.apache.org/jira/browse/AXIS2-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen resolved AXIS2-5062.
Resolution: Fixed
Fix Version/s: 1.7.0
1.6.1
Assignee: Andreas Veithen
> Connection is not released while using JAXWS client API
> ---
>
> Key: AXIS2-5062
> URL: https://issues.apache.org/jira/browse/AXIS2-5062
> Project: Axis2
> Issue Type: Bug
> Components: jaxws, transports
>Affects Versions: 1.6.0
>Reporter: Ivan
>Assignee: Andreas Veithen
> Labels: Geronimo
> Fix For: 1.6.1, 1.7.0
>
> Attachments: AXIS2-5062-Dispatch.patch, AXIS2-5062-Port.patch
>
>
> 1. Using Dispatch API
> A bit more description for my case, the server side is a simple web service,
> for the client side, the codes are something like :
> --->
> Service service = new HelloService();
> Dispatch dispatchJaxb = service.createDispatch(PORT_QNAME,
> JAXBContext.newInstance(org.test.ObjectFactory.class),
> javax.xml.ws.Service.Mode.PAYLOAD);
> dispatchJaxb.invokeOneWay(new HelloRequest());
> <---
> After adding some code fragments in the finally block of
> BaseDispatch.invokeOneWay method, it looks to me work fine.
> --->
> try {
> if (requestMsgCtx != null &&
> requestMsgCtx.getAxisMessageContext() != null) {
> org.apache.axis2.context.MessageContext axisMsgCtx =
> requestMsgCtx.getAxisMessageContext();
> if (axisMsgCtx.getTransportOut() != null &&
> axisMsgCtx.getTransportOut().getSender() != null) {
>
> axisMsgCtx.getTransportOut().getSender().cleanup(axisMsgCtx);
> }
> }
> } catch (Exception ignore) {
> }
> <---
> I also googled this issue, and do found a lot of information for the same
> timeout exception, also read some related codes
> a. In the HttpSender, there is a method named cleanup, which is used to
> release the connection, but it has the precondition to configure the
> AUTO_RELEASE_CONNECTION. And actually I did not see other setting
> configurations in the Axis2 codes, and think that it should be configured by
> the users in the Options ?
> b. Some posts in the mail list recommended to call the
> getTransport().cleanup() in the Axis2 specific client codes. And in the
> testing scenario above, since the standard JAX-WS API is used, suppose that
> Axis2 should do this ?
> And very appreciated with any comment ? Thanks.
> 2. I might find another connection leak while using JAXWS API on client side.
> In the scenario below :
> For the server side, it requires basic authentication.
> The client codes are something like :
> HelloPort helloPort = (HelloPort)service.getPort(HelloPort.class);
> helloPort.echo("hello");
> The client codes did not set the user name and password by the
> BindingProvider interface, so the server return a 404 to the client side,
> then the method HttpSender.handleResponse will enter the fourth block :
> private void handleResponse(MessageContext msgContext,
> HttpMethodBase method) throws IOException {
> int statusCode = method.getStatusCode();
> log.trace("Handling response - " + statusCode);
> if (statusCode == HttpStatus.SC_OK) {
> // Save the HttpMethod so that we can release the connection when
> cleaning up
> msgContext.setProperty(HTTPConstants.HTTP_METHOD, method);
> processResponse(method, msgContext);
> } else if (statusCode == HttpStatus.SC_ACCEPTED) {
> /* When an HTTP 202 Accepted code has been received, this will
> be the case of an execution
>* of an in-only operation. In such a scenario, the HTTP
> response headers should be returned,
>* i.e. session cookies. */
> obtainHTTPHeaderInformation(method, msgContext);
> // Since we don't expect any content with a 202 response, we
> must release the connection
> method.releaseConnection();
> } else if (statusCode == HttpStatus.SC_INTERNAL_SERVER_ERROR ||
> statusCode == HttpStatus.SC_BAD_REQUEST) {
> // Save the HttpMethod so that we can release the connection when
> cleaning up
> msgContext.setProperty(HTTPConstants.HTTP_METHOD, method);
> Header contenttypeHeader =
>
> method.getResponseHeader(HTTPConstants.HEADER_CONTENT_TYPE);
> String value = null;
> if (contenttypeHeader != null) {
> value = contenttypeHeader.getValue();
> }
> OperationContext opContext = msgContext.getOperationContext();
> if(opContext!=null){
> M
[jira] [Commented] (AXIS2-3470) AAR maven2 plugin: request to change default location of service.xml
[ https://issues.apache.org/jira/browse/AXIS2-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085011#comment-13085011 ] David Bull commented on AXIS2-3470: --- To be honest, moved on to a different project, but your suggestions seems reasonable to me > AAR maven2 plugin: request to change default location of service.xml > > > Key: AXIS2-3470 > URL: https://issues.apache.org/jira/browse/AXIS2-3470 > Project: Axis2 > Issue Type: Improvement > Components: Tools >Affects Versions: 1.3 > Environment: Maven 2.0.8 > Cygwin 1.5.24 running on Windows XP >Reporter: David Bull > > The plugin guide states that "By default, it is assumed that [services.xml] > is already present in classesDirectory/META-INF". classesDirectory is the > location of the compiled classes and, as such, will be deleted whenever clean > is invoked. > Could you please consider conforming to the usual maven behaviour of copying > configuration files from the src directory: my suggestion would be something > like; > src->main->aar > (c.f. src->main->webapps etc.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org For additional commands, e-mail: java-dev-h...@axis.apache.org
[jira] [Commented] (AXIS2-5115) debug log level makes the EndpointInterfaceDescriptionImpl not initialized correctly
[
https://issues.apache.org/jira/browse/AXIS2-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085033#comment-13085033
]
Hudson commented on AXIS2-5115:
---
Integrated in axis2-1.6 #71 (See [https://builds.apache.org/job/axis2-1.6/71/])
AXIS2-5115: Merged r1157373, r1157415 and r1157424 to the 1.6 branch.
veithen :
Files :
*
/axis/axis2/java/core/branches/1_6/modules/metadata/src/org/apache/axis2/jaxws/description/impl/EndpointInterfaceDescriptionImpl.java
*
/axis/axis2/java/core/branches/1_6/modules/jaxws-integration/test/org/apache/axis2/jaxws/jaxb/string/JAXBStringUTF16Tests.java
*
/axis/axis2/java/core/branches/1_6/modules/metadata/src/org/apache/axis2/jaxws/description/impl/OperationDescriptionImpl.java
*
/axis/axis2/java/core/branches/1_6/modules/jaxws-integration/test/org/apache/axis2/jaxws/framework/AbstractTestCase.java
* /axis/axis2/java/core/branches/1_6
> debug log level makes the EndpointInterfaceDescriptionImpl not initialized
> correctly
>
>
> Key: AXIS2-5115
> URL: https://issues.apache.org/jira/browse/AXIS2-5115
> Project: Axis2
> Issue Type: Bug
> Components: jaxws
>Affects Versions: 1.6.0
>Reporter: Ivan
> Labels: Geronimo
>
> While constructing the EndpointInterfaceDescriptionImpl instance from WSDL on
> the line 1222 of EndpointDescriptionImpl, if the log level is configured with
> debug, some internal variable like soapParameterStyle is initialized, and
> even after updating the SEI in the following codes, they will not be
> re-initialized again.
> {code}
> endpointInterfaceDescription = new EndpointInterfaceDescriptionImpl(this);
> // Update the EndpointInterfaceDescription created
> with WSDL with information from the
> // annotations in the SEI
>
> ((EndpointInterfaceDescriptionImpl)endpointInterfaceDescription)
>
> .updateWithSEI(composite.getCorrespondingClass());
> {code}
> {code}
> EndpointInterfaceDescriptionImpl(EndpointDescriptionImpl parent) {
> parentEndpointDescription = parent;
> dbc = new DescriptionBuilderComposite();
> AxisService axisService = parentEndpointDescription.getAxisService();
> if (axisService != null) {
> ArrayList publishedOperations =
> axisService.getPublishedOperations();
> Iterator operationsIterator = publishedOperations.iterator();
> while (operationsIterator.hasNext()) {
> AxisOperation axisOperation =
> (AxisOperation)operationsIterator.next();
> addOperation(new OperationDescriptionImpl(axisOperation,
> this));
> }
> }
> }
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
Processing instructions are not allowed within SOAP messages
Hi there,
Im trying to login with username and password to a webService url but i get
this:
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: org.xml.sax.SAXException: Processing instructions are not
allowed within SOAP messages
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:org.xml.sax.SAXException:
Processing instructions are not allowed within SOAP messages
at
org.apache.axis.encoding.DeserializationContext.startDTD(DeserializationContext.java:1161)
at org.apache.xerces.parsers.SAXParser.startDTD(SAXParser.java:911)
at
org.apache.xerces.framework.XMLDTDScanner.scanDoctypeDecl(XMLDTDScanner.java:1120)
at
org.apache.xerces.framework.XMLDocumentScanner.scanDoctypeDecl(XMLDocumentScanner.java:2201)
at
org.apache.xerces.framework.XMLDocumentScanner.access$0(XMLDocumentScanner.java:2156)
at
org.apache.xerces.framework.XMLDocumentScanner$PrologDispatcher.dispatch(XMLDocumentScanner.java:887)
at
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1035)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
at
org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
at org.apache.axis.Message.getSOAPEnvelope(Message.java:435)
at
org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at
za.co.vine.webServiceHandler.com.sforce.soap.enterprise.SoapBindingStub.login(SoapBindingStub.java:3379)
at
za.co.vine.webServiceHandler.WSDLInterfaceSoapSender.doLogin(WSDLInterfaceSoapSender.java:217)
at
za.co.vine.webServiceHandler.WSDLInterfaceSoapSender.(WSDLInterfaceSoapSender.java:63)
at
za.co.vine.webServiceHandler.BaseMessageCollector.initialise(BaseMessageCollector.java:89)
at
za.co.vine.webServiceHandler.BaseMessageCollector.(BaseMessageCollector.java:64)
at
za.co.vine.webServiceHandler.MessageCollector.(MessageCollector.java:43)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
za.co.vine.classMapper.VineComponent.setClassName(VineComponent.java:68)
at
za.co.vine.classMapper.VineComponent.setClassName(VineComponent.java:57)
at
za.co.vine.distributionEngine.SynchronousCollector.configure(SynchronousCollector.java:37)
at
za.co.vine.distributionEngine.CollectorIF.reconfigure(CollectorIF.java:121)
at
za.co.vine.distributionEngine.CollectorIF.initialise(CollectorIF.java:77)
at
za.co.vine.distributionEngine.CollectionHandler.reconfigure(CollectionHandler.java:137)
at
za.co.vine.distributionEngine.CollectionHandler.initialise(CollectionHandler.java:48)
at
za.co.vine.distributionEngine.CollectionHandlerStartup.start(CollectionHandlerStartup.java:25)
at
za.co.vine.distributionEngine.CollectionHandlerStartup.main(CollectionHandlerStartup.java:41)
Any idea?
Thanks,
Luane
--
View this message in context:
http://old.nabble.com/Processing-instructions-are-not-allowed-within-SOAP-messages-tp32263762p32263762.html
Sent from the Axis - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
[jira] [Resolved] (AXIS2-5115) debug log level makes the EndpointInterfaceDescriptionImpl not initialized correctly
[
https://issues.apache.org/jira/browse/AXIS2-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen resolved AXIS2-5115.
Resolution: Fixed
Fix Version/s: 1.7.0
1.6.1
Assignee: Andreas Veithen
> debug log level makes the EndpointInterfaceDescriptionImpl not initialized
> correctly
>
>
> Key: AXIS2-5115
> URL: https://issues.apache.org/jira/browse/AXIS2-5115
> Project: Axis2
> Issue Type: Bug
> Components: jaxws
>Affects Versions: 1.6.0
>Reporter: Ivan
>Assignee: Andreas Veithen
> Labels: Geronimo
> Fix For: 1.6.1, 1.7.0
>
>
> While constructing the EndpointInterfaceDescriptionImpl instance from WSDL on
> the line 1222 of EndpointDescriptionImpl, if the log level is configured with
> debug, some internal variable like soapParameterStyle is initialized, and
> even after updating the SEI in the following codes, they will not be
> re-initialized again.
> {code}
> endpointInterfaceDescription = new EndpointInterfaceDescriptionImpl(this);
> // Update the EndpointInterfaceDescription created
> with WSDL with information from the
> // annotations in the SEI
>
> ((EndpointInterfaceDescriptionImpl)endpointInterfaceDescription)
>
> .updateWithSEI(composite.getCorrespondingClass());
> {code}
> {code}
> EndpointInterfaceDescriptionImpl(EndpointDescriptionImpl parent) {
> parentEndpointDescription = parent;
> dbc = new DescriptionBuilderComposite();
> AxisService axisService = parentEndpointDescription.getAxisService();
> if (axisService != null) {
> ArrayList publishedOperations =
> axisService.getPublishedOperations();
> Iterator operationsIterator = publishedOperations.iterator();
> while (operationsIterator.hasNext()) {
> AxisOperation axisOperation =
> (AxisOperation)operationsIterator.next();
> addOperation(new OperationDescriptionImpl(axisOperation,
> this));
> }
> }
> }
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
To which extent axis2 supports REST?
Hi,
Can you please tell me to which extent axis2 supports REST? I mean is
it possible to implement the following requirements in axis2?
and how to define it in wsdl?
method name: /bookdelivery/${isbn}/status
HTTP method: GET
returns: 200 ok and xml
If yes, how to do it? any sample code/tutorial?
Thanks
-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
Re: To which extent axis2 supports REST?
Hi Denise,
The article [1] describes how to write a RESTful web service in Axis2.
[1] http://wso2.org/library/3726
Hope this helps.
Thanks,
Hasini.
On Mon, Aug 15, 2011 at 7:38 PM, Denise Wu wrote:
> Hi,
>
> Can you please tell me to which extent axis2 supports REST? I mean is
> it possible to implement the following requirements in axis2?
> and how to define it in wsdl?
>
> method name: /bookdelivery/${isbn}/status
> HTTP method: GET
> returns: 200 ok and xml
>
> If yes, how to do it? any sample code/tutorial?
>
>
> Thanks
>
> -
> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
> For additional commands, e-mail: java-dev-h...@axis.apache.org
>
>
[jira] [Commented] (AXIS2-5110) Compatibility with WebSphere Application Server on z/OS
[
https://issues.apache.org/jira/browse/AXIS2-5110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085164#comment-13085164
]
William Walsh commented on AXIS2-5110:
--
Andreas, Sorry for my confusion on this. Addressing this from the standpoint
of more correctly managing the threads makes sense. But, since I had compared
execution of Axis2 on distributed vs. z/OS and saw it equivalent in its thread
processing I had taken the information IBM had provided me and chose to pursue
a solution in my environment that addresses this based on those platform
differences.
It's not that I'm refusing to do an upgrade, I just don't have time budgeted in
the project to do one right now; we will get to that eventually (this is a
non-trivial activity for us). Since I don't see anything in AXIS2-4263 that
looked like it was making specific changes in this area it would be hard for us
to justify taking on a new Axis2 version for this one issue.
Perhaps we should close this JIRA, we can use our temporary fix for the time
being, and then investigate this area further when we take on a later Axis2
version. How does that sound?
Thanks for your feedback and time on this.
> Compatibility with WebSphere Application Server on z/OS
> ---
>
> Key: AXIS2-5110
> URL: https://issues.apache.org/jira/browse/AXIS2-5110
> Project: Axis2
> Issue Type: Improvement
> Components: kernel
>Affects Versions: 1.5.1
> Environment: WebSphere on z/OS V7
>Reporter: William Walsh
>Priority: Minor
>
> In using Axis2 with WebSphere across multiple platforms we have found that
> once we invoked a web service against Axis2 on WebSphere for z/OS that the
> application server would not shutdown properly. (The architecture on z/OS is
> very different than other platforms - it uses a number of address spaces to
> host WebSphere and the control and servant address spaces would not
> terminate.) We asked IBM about this and it has to do with differences in how
> the JVM is implemented and started by WebSphere on z/OS. The long and the
> short of this is that Timer threads must be defined as daemon to allow
> WebSphere to terminate properly on z/OS.
> I'd like to propose a patch for this and would like to know/confirm:
> Are these classes where I saw non-daemon threads created the appropriate
> places for change?
> /org/apache/axis2/util/threadpool/ThreadPool.java
> /org/apache/axis2/util/threadpool/DefaultThreadFactory.java
> /org/apache/axis2/transport/http/server/DefaultThreadFactory.java
> I would propose adding conditional code to force daemon threads when running
> on z/OS:
> if (System.getProperty("os.name").equals("z/OS")
> Would this be appropriate, or do you feel the check needs to be more
> explicit; also checking for WebSphere?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
[ FWD] Release Axis2 Transport -1.6.0
Hi,
I was pointed out that,
"The build of Axis2 Transport -1.6.0 produces three different source
releases:
https://repository.apache.org/content/repositories/orgapacheaxis2-003/org/apache/axis2/axis2-transport-all/1.6.0/axis2-transport-all-1.6.0-source-release.zip
https://repository.apache.org/content/repositories/orgapacheaxis2-003/org/apache/axis2/axis2-transport-all/1.6.0/axis2-transport-all-1.6.0-src.zip
https://repository.apache.org/content/repositories/orgapacheaxis2-003/org/apache/axis2/axis2-transports/1.6.0/axis2-transports-1.6.0-source-release.zip
Some of them contain files (target directory) they should not, and at
least one is broken (${project.version} in the directory name). I
think we need to clean this up."
I am to resolve this in the coming up week and need few clarifications
regarding this.
I built the Transport project and It is creating a target folder for each
and every module and sub-module. Inside target folder it is creating two
jars including source and class files separately. Can you clarify me whether
whole this folder is not necessary or should jar files exist? Is there any
place I can refer to check the standard of this?
Also in the module "all" there is a read me file stating that
"Why parent module
The only reason behind having this module to do a small trick to build
a single jar from all the sub-modules. If you know a way to fix this
in a better manner , then please remove the parent module."
So grateful for any clue on this.
--
*Regards,*
Pushpalanka Jayawardhana,
Undergraduate,
Computer Science and Engineering Department,
University of Moratuwa,
Sri Lanka.
Blog : http://pushpalankajaya.blogspot.com/
