from:"Asankha C. Perera"


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

Asankha C. Perera resolved AXIS2-3460.
--

Resolution: Won't Fix
  Assignee: Asankha C. Perera

HTTP/S NIO is not within the Axis2 project anymore. If there is any issue, 
please use the latest version from Synapse

 AxisFault in ClientHandler (http NIO sender)
 

 Key: AXIS2-3460
 URL: https://issues.apache.org/jira/browse/AXIS2-3460
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: transports
Affects Versions: 1.3
 Environment: java 1.5, axis2 1.3, linux, tomcat 5.5
Reporter: Michele Mazzucco
Assignee: Asankha C. Perera
Priority: Critical

 http://www.mail-archive.com/axis-u...@ws.apache.org/msg37314.html

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

[jira] Resolved: (AXIS2-3473) HTTP NIO fails to process response


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

Asankha C. Perera resolved AXIS2-3473.
--

Resolution: Won't Fix
  Assignee: Asankha C. Perera

HTTP/S NIO is not within the Axis2 project anymore. If there is any issue, 
please use the latest version from Synapse

 HTTP NIO fails to process response
 --

 Key: AXIS2-3473
 URL: https://issues.apache.org/jira/browse/AXIS2-3473
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: transports
Affects Versions: 1.3
 Environment: axis2 1.3, linux, sun jdk 1.5
Reporter: Michele Mazzucco
Assignee: Asankha C. Perera
Priority: Critical

 ERROR 11:26:53,700 (ClientWorker.java:176) - Fault processing response 
 message through Axis2
 org.apache.axis2.AxisFault: Cannot identify correct Callback object. 
 RelatesTo is null
 at 
 org.apache.axis2.util.CallbackReceiver.receive(CallbackReceiver.java:62)
 at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:145)
 at 
 org.apache.axis2.transport.nhttp.ClientWorker.run(ClientWorker.java:174)
 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)
 The error is thrown at message arrival.

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

[jira] Resolved: (AXIS2-2993) the async message receiver could use NIO


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

Asankha C. Perera resolved AXIS2-2993.
--

Resolution: Won't Fix
  Assignee: Asankha C. Perera  (was: Deepal Jayasinghe)

HTTP/S NIO is not within the Axis2 project anymore. If there is any issue, 
please use the latest version from Synapse

 the async message receiver could use NIO
 

 Key: AXIS2-2993
 URL: https://issues.apache.org/jira/browse/AXIS2-2993
 Project: Axis 2.0 (Axis2)
  Issue Type: Improvement
  Components: kernel
Affects Versions: 1.2
 Environment: all
Reporter: Michele Mazzucco
Assignee: Asankha C. Perera

 AbstractMessageReceiver does the job of deciding (based on the 
 AbstractMessageReceiver.DO_ASYNC property) whether or not to spin up a thread 
 to do the work of invokeBusinessLogic(MessageContext). What about using NIO 
 instead?

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

[jira] Resolved: (AXIS2-3309) NPE throws when starting axis2server if NIO https transport is enabled in axis2.xml

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

Asankha C. Perera resolved AXIS2-3309.
--

Resolution: Won't Fix

HTTP/S NIO is not within the Axis2 project anymore. If there is any issue,
please use the latest version from Synapse

NPE throws when starting axis2server if NIO https transport is enabled in
axis2.xml
---

Key: AXIS2-3309
URL: https://issues.apache.org/jira/browse/AXIS2-3309
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Affects Versions: 1.3
Environment: winxp, jdk15
Reporter: Charitha Kankanamge
Assignee: Asankha C. Perera
Priority: Critical

- Uncomment !-- the non-blocking https transport sender based on HttpCore +
NIO SSL extensions-- section and NIO https transport receiver section in
axis2.xml
- Restart Axis2 server
Startup fails with the following exception.
[FATAL] [SimpleAxisServer] Shutting down. Error starting SimpleAxisServer
java.lang.NullPointerException
at
org.apache.axis2.transport.nhttp.HttpCoreNIOSSLSender.getSSLContext(HttpCoreNIOSSLSender.
java:81)
at
org.apache.axis2.transport.nhttp.HttpCoreNIOSender.init(HttpCoreNIOSender.java:96)
at
org.apache.axis2.context.ConfigurationContextFactory.initTransportSenders(ConfigurationCo
ntextFactory.java:270)
at
org.apache.axis2.context.ConfigurationContextFactory.init(ConfigurationContextFactory.jav
a:201)
at
org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(Configura
tionContextFactory.java:76)
at
org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContextFromFileSy
stem(ConfigurationContextFactory.java:180)
at
org.apache.axis2.transport.SimpleAxis2Server.init(SimpleAxis2Server.java:50)
at
org.apache.axis2.transport.SimpleAxis2Server.main(SimpleAxis2Server.java:101)
[SimpleAxisServer] Shutting down. Error starting SimpleAxisServer
in this case, Axis2server cannot be started due to absence of the default
trust store and keystore files. However the error does not indicate anything
about the actual reason.

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

[jira] Resolved: (AXIS2-3428) NullPointerException in HttpCoreNIOSender


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

Asankha C. Perera resolved AXIS2-3428.
--

Resolution: Won't Fix
  Assignee: Asankha C. Perera

HTTP/S NIO is not within the Axis2 project anymore. If there is any issue, 
please use the latest version from Synapse

  NullPointerException in HttpCoreNIOSender
 --

 Key: AXIS2-3428
 URL: https://issues.apache.org/jira/browse/AXIS2-3428
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: kernel
Affects Versions: 1.3
 Environment: java 1.5, mac os x, axis2 1.3 (embedded)
Reporter: Michele Mazzucco
Assignee: Asankha C. Perera
Priority: Critical
 Attachments: AXIS2-3428.patch, axis2.xml, TestCaseAXIS2_3428.java, 
 TestMultipleAsync.tar.gz


 Exception in thread HttpCoreNIOSender java.lang.NullPointerException
   at 
 org.apache.axis2.transport.nhttp.HttpCoreNIOSender$2.handleError(HttpCoreNIOSender.java:442)
   at 
 org.apache.axis2.transport.nhttp.HttpCoreNIOSender$2.failed(HttpCoreNIOSender.java:412)
   at 
 org.apache.http.impl.nio.reactor.SessionRequestImpl.failed(SessionRequestImpl.java:139)
   at 
 org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.processEvent(DefaultConnectingIOReactor.java:151)
   at 
 org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.processEvents(DefaultConnectingIOReactor.java:131)
   at 
 org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.execute(DefaultConnectingIOReactor.java:112)
   at 
 org.apache.axis2.transport.nhttp.HttpCoreNIOSender.executeClientEngine(HttpCoreNIOSender.java:127)
   at 
 org.apache.axis2.transport.nhttp.HttpCoreNIOSender.access$000(HttpCoreNIOSender.java:69)
   at 
 org.apache.axis2.transport.nhttp.HttpCoreNIOSender$1.run(HttpCoreNIOSender.java:102)
   at java.lang.Thread.run(Thread.java:613)

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

[jira] Resolved: (AXIS2-3496) org.apache.axis2.transport.nhttp.ServerWorker - Error processing POST request when the service throws an exception


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

Asankha C. Perera resolved AXIS2-3496.
--

Resolution: Won't Fix

HTTP/S NIO is not within the Axis2 project anymore. If there is any issue, 
please use the latest version from Synapse

 org.apache.axis2.transport.nhttp.ServerWorker  - Error processing POST 
 request when the service throws an exception
 ---

 Key: AXIS2-3496
 URL: https://issues.apache.org/jira/browse/AXIS2-3496
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: transports
Affects Versions: 1.3
 Environment: axis2 1.3, java 1.5, linux
Reporter: Michele Mazzucco
Assignee: Asankha C. Perera
Priority: Critical
 Attachments: axis2.xml, EchoAsyncStateful.java, 
 TestCaseAxis2_3496.java, UtilServer.java


 MEP: in/out (both synchronous and asynchronous), NIO transport
 scenario: the service throws an exception
 effect: axis2 fails

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

[jira] Resolved: (AXIS2-3661) ClientHandler prints the full stack trace if the client shuts down the connection


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

Asankha C. Perera resolved AXIS2-3661.
--

Resolution: Won't Fix
  Assignee: Asankha C. Perera

HTTP/S NIO is not within the Axis2 project anymore. If there is any issue, 
please use the latest version from Synapse

 ClientHandler prints the full stack trace if the client shuts down the 
 connection
 -

 Key: AXIS2-3661
 URL: https://issues.apache.org/jira/browse/AXIS2-3661
 Project: Axis 2.0 (Axis2)
  Issue Type: Improvement
Affects Versions: 1.3
 Environment: axis2 1.3, http nio
Reporter: Michele Mazzucco
Assignee: Asankha C. Perera
Priority: Minor

 ERROR 11:46:34,770 (ClientHandler.java:218) - I/O error : Connection reset by 
 peer
 java.io.IOException: Connection reset by peer
 at sun.nio.ch.FileDispatcher.read0(Native Method)
 at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21)
 at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233)
 at sun.nio.ch.IOUtil.read(IOUtil.java:206)
 at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207)
 at 
 org.apache.axis2.transport.nhttp.LoggingIOSession$LoggingByteChannel.read(LoggingIOSession.java:180)
 at 
 org.apache.http.impl.nio.reactor.SessionInputBuffer.fill(SessionInputBuffer.java:82)
 at 
 org.apache.http.impl.nio.codecs.HttpMessageParser.fillBuffer(HttpMessageParser.java:95)
 at 
 org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(DefaultNHttpClientConnection.java:93)
 at 
 org.apache.axis2.transport.nhttp.PlainClientIOEventDispatch.inputReady(PlainClientIOEventDispatch.java:71)
 at 
 org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:68)
 at 
 org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:160)
 at 
 org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:145)
 at 
 org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:127)
 at 
 org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:162)
 at java.lang.Thread.run(Thread.java:595)
 Is it possible to take any better action? If no, logging the full stack trace 
 is useless.

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

[jira] Resolved: (AXIS2-3514) HttpCoreNIOSender throws NullPointerException


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

Asankha C. Perera resolved AXIS2-3514.
--

Resolution: Won't Fix
  Assignee: Asankha C. Perera

HTTP/S NIO is not within the Axis2 project anymore. If there is any issue, 
please use the latest version from Synapse

 HttpCoreNIOSender throws NullPointerException
 -

 Key: AXIS2-3514
 URL: https://issues.apache.org/jira/browse/AXIS2-3514
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: transports
Affects Versions: 1.3
 Environment: java 1.5, linux, axis2 1.3
Reporter: Michele Mazzucco
Assignee: Asankha C. Perera
Priority: Critical

 After a couple of minutes of use the system failed with the following error
 ERROR 10:04:09,557 (ClientHandler.java:348) - Received an internal server 
 error : Internal Server Error
 ERROR 10:04:09,557 (ClientHandler.java:348) - Received an internal server 
 error : Internal Server Error
 ERROR 10:04:09,557 (ClientHandler.java:348) - Received an internal server 
 error : Internal Server Error
 Exception in thread HttpCoreNIOSender java.lang.NullPointerException
 at 
 org.apache.axis2.transport.nhttp.ClientHandler.inputReady(ClientHandler.java:236)
 at 
 org.apache.axis2.transport.nhttp.LoggingNHttpClientHandler.inputReady(LoggingNHttpClientHandler.java:113)
 at 
 org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(DefaultNHttpClientConnection.java:111)
 at 
 org.apache.axis2.transport.nhttp.PlainClientIOEventDispatch.inputReady(PlainClientIOEventDispatch.java:71)
 at 
 org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:68)
 at 
 org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:160)
 at 
 org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:145)
 at 
 org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:127)
 at 
 org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:162)
 at java.lang.Thread.run(Thread.java:595)
 line 236 is
 sink.write(inbuf);

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

[jira] Resolved: (AXIS2-4188) JMSSender not extendable


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

Asankha C. Perera resolved AXIS2-4188.
--

Resolution: Won't Fix
  Assignee: Asankha C. Perera

If a patch is contributed, we could consider for inclusion into the new 
WS-Commons JMS transport

 JMSSender not extendable
 

 Key: AXIS2-4188
 URL: https://issues.apache.org/jira/browse/AXIS2-4188
 Project: Axis 2.0 (Axis2)
  Issue Type: Improvement
  Components: transports
Affects Versions: 1.5, 1.4.1, 1.4
 Environment: All
Reporter: Ben Reif
Assignee: Asankha C. Perera
   Original Estimate: 0.03h
  Remaining Estimate: 0.03h

 We need to extend the org.apache.axis2.transport.jms.JMSSender class so that 
 we can add some custom properties to the JMS Message (most likely via the 
 MessageContext. However, the class is full of private methods which must be 
 copied into a sub-class, and it also uses other classes such as 
 JMSOutTransportInfo that only have package protected constructors. 
 This class is clearly meant to be extended because you can redefine the 
 implementation class in the axis2.xml. But rather then just extending it and 
 overridding a method, you have to jump through hoops and copy a bunch of code 
 to do so. 
 In my opinion this is one of the most frustrating things about using open 
 source code. Many Apache (and Sun projects as well) have a bad habit of 
 coding everything private, package protected, or sometimes even making things 
 final! Most open source projects these days are designed to be extended, but 
 coding things in this way defeats that purpose.  
 Sorry for the long rant and rave, overall I think Axis2 is really great, but 
 could you keep this in mind moving forward :) , and at least maybe make these 
 methods protected in the next release:
 JMSSender - 
 private Message createJMSMessage(MessageContext msgContext, Session session)  
 throws JMSException {
 }
 private void setProperty(Message message, MessageContext msgCtx, String key){
 }
 private String getProperty(MessageContext mc, String key) {
 }
 private static void handleException(String s) {
 }
 private static void handleException(String s, Exception 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-4088) Async msg processing/ callback for msg ID not found


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

Asankha C. Perera resolved AXIS2-4088.
--

Resolution: Won't Fix
  Assignee: Asankha C. Perera

HTTP/S NIO is not within the Axis2 project anymore. If there is any issue, 
please use the latest version from Synapse

 Async msg processing/ callback for msg ID not found
 ---

 Key: AXIS2-4088
 URL: https://issues.apache.org/jira/browse/AXIS2-4088
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: kernel
Affects Versions: 1.4.1, 1.4, 1.3
 Environment: Axis2 1.3, JDK 1.5
Reporter: Michele Mazzucco
Assignee: Asankha C. Perera
Priority: Critical
 Fix For: 1.5


 http://www.mail-archive.com/axis-u...@ws.apache.org/msg43664.html
 Axis2 1.4.1 is affected by the same problem

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

Re: Is there a nightly build / Maven repo, for the Axis2 1.5 branch?

2009-02-26 Thread Asankha C. Perera


Hi Glen

Is there a nightly build off [1] or a Maven repo where nightly snapshots
are published? If no, are there any plans to set this up?


Nope, no nightly of the 1.5 branch, though such a thing could certainly
be set up if you want to do it.  I'm hoping the release itself happens
pretty soon, as it's been kind of dragging (mostly my fault for not
having cycles to push it through) - 
The version on the pom states 1.5-beta-2 and effectively even if we 
include this into a maven repo will prevent updates from being seen by 
users below. Is there a possibility to make this 1.5-SNAPSHOT ? so that 
anyone could publish them to the Apache snapshot repo, and others can 
then pull back updates?

at this point we just need to get
the transports 1.0 release out, and I think we're ready to go with an RC
and then the actual release.
  
I think I can help here.. and am going through the list of transport 
issues we need to fix in the JIRA's.. If there is anything critical that 
needs to be fixed for transports 1.0 (that would ship with Axis2 1.5) 
please mark it a blocker, and assign to me


thanks
asankha

--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com

[jira] Resolved: (AXIS2-4025) Using JMSMessageID as correlationID for JMS messages

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

Asankha C. Perera resolved AXIS2-4025.
--

Resolution: Won't Fix
Assignee: Asankha C. Perera

The JMS transport is not within the Axis2 project anymore. If there is any
issue, please use the latest version from WS-Commons

Using JMSMessageID as correlationID for JMS messages

Key: AXIS2-4025
URL: https://issues.apache.org/jira/browse/AXIS2-4025
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: kernel, transports
Environment: OS: Windows XP Pro 2002 Service Pack 2
Reporter: Cathal Callaghan
Assignee: Asankha C. Perera
Fix For: 1.4

Attachments: JMSMessageReceiver.java, JMSSender.java

The correlationID solution currently in place in Axis2 version 1.4 does not
work.
Currently the option is available to specify a correlationID but when the
MessageConsumer is created no MessageSelector is specified. This means that
the MessageConsumer will take any message off the queue.
Also, currently the only way to use a correlationID is to explicity specify
an ID via the JMSConstants.JMS_COORELATION_ID property. This is very
restrictive for those who wish to use the option of using the JMSMessageID of
the message as the correlationID.
I have attached a proposed solution which firstly ensures that the
MessageConsumer is created using a MessageSelector. Also i have given the
user a choice, if they explicity specify a correlationID then this will be
used otherwise the JMSMessageID of the message will be used as the
correlationID.
Thanks,
Cathal

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

[jira] Commented: (AXIS2-2993) the async message receiver could use NIO


[ 
https://issues.apache.org/jira/browse/AXIS2-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12677236#action_12677236
 ] 

Asankha C. Perera commented on AXIS2-2993:
--

Hi Deepal

Lets take this concrete case as an example, why would one want to invoke the 
business logic in another thread when the transports are built to inject 
messages with worker threads designed to do the work. I think I should have 
marked this issue as invalid instead?

thanks
asankha

 the async message receiver could use NIO
 

 Key: AXIS2-2993
 URL: https://issues.apache.org/jira/browse/AXIS2-2993
 Project: Axis 2.0 (Axis2)
  Issue Type: Improvement
  Components: kernel
Affects Versions: 1.2
 Environment: all
Reporter: Michele Mazzucco
Assignee: Asankha C. Perera

 AbstractMessageReceiver does the job of deciding (based on the 
 AbstractMessageReceiver.DO_ASYNC property) whether or not to spin up a thread 
 to do the work of invokeBusinessLogic(MessageContext). What about using NIO 
 instead?

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

[jira] Resolved: (AXIS2-1381) Need to enhance code generation from WSDL to support JMS extensions


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

Asankha C. Perera resolved AXIS2-1381.
--

   Resolution: Fixed
Fix Version/s: 1.4.1

This issue is very old.. AFAIK this is working with 1.4.x etc..please feel free 
to re-open if there is any issue pending

 Need to enhance code generation from WSDL to support JMS extensions
 ---

 Key: AXIS2-1381
 URL: https://issues.apache.org/jira/browse/AXIS2-1381
 Project: Axis 2.0 (Axis2)
  Issue Type: New Feature
  Components: codegen
Affects Versions: 1.1
 Environment: All
Reporter: Brennan Spies
 Fix For: 1.4.1

 Attachments: files.zip, patch.zip


 Currently, there is no support for JMS WSDL extensions in Axis 2.0. Code 
 generation for a WSDL service with JMS bindings succeeds, but the client stub 
 is missing a default JMS endpoint reference, and transport elements and 
 appropriate properties from jms:address should be placed into the generated 
 services.xml file.
 To do this, the appropriate extension elements for JMS in the WSDL must be 
 recognized. This requires adding them to WSDL4J's extensibility mechanism. 
 The appropriate implementations already exist in the Apache WSIF project: 
 http://ws.apache.org/wsif/providers/wsdl_extensions/jms_extension.html.

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

Is there a nightly build / Maven repo, for the Axis2 1.5 branch?

2009-02-24 Thread Asankha C. Perera


Hi All

Is there a nightly build off [1] or a Maven repo where nightly snapshots 
are published? If no, are there any plans to set this up?


thanks
asankha

[1] https://svn.apache.org/repos/asf/webservices/axis2/branches/java/1_5
[2] http://people.apache.org/repo/m2-snapshot-repository

--
Asankha C. Perera
http://adroitlogic.org

http://esbmagic.blogspot.com

Re: Axis2 doesn't play nice with PFP (payflow, paypal)

2009-02-12 Thread Asankha C. Perera


Hi Grover
Before answering your questions, I will add a new development: 
yesterday we switched our soap communication method to use Axis 1.4 
(Axis 1) instead of Axis2 1.4.1.  Making this change did resolve the 
issue and PFP does not break Axis 1 communication.  At this point we 
are satisfied with this solution and have decided to move forward with 
Axis 1.

Thats good to hear!


One other thing I should mention is that the soap server we are using 
Axis to communicate with requires basic authentication to connect, so 
simple telnet commands do get connection refused.


Hmm.. that should not happen, since a basic auth failure (which has a 
HTTP response) is different from a connection refused - which means that 
the remote host did not accept the message over the selected port.


However, ngrep does show packets going to and from xyz.com when 
attempting the telnet connection, even when we are in the broken 
communication state.


I am not much familiar with ngrep.. but if communication takes place, 
that means you have network level connectivity. What would be 
interesting to see is the output of tcpdump for the manual telnet vs the 
Axis2 connection attempt.. anyway, leave that to the next time you want 
to revisit Axis2


cheers
asankha

--
Asankha C. Perera
http://adroitlogic.org

http://esbmagic.blogspot.com

Re: Axis2 doesn't play nice with PFP (payflow, paypal)

2009-02-10 Thread Asankha C. Perera


Hi Grover
Once this state is entered, the only way to re-establish successful 
Axis2 soap communication is to restart the appserver (jboss). This 
almost seems like a system resource contention issue. However, making 
Axis2 soap calls first does not break the PFP call.  Any ideas as to 
what might be happening or how to work around this issue would be 
appreciated.
What is the software making this 'PFP' call? is it doing something with 
the SSL socket factories to your knowledge?

  A partial stack trace of the connection refused exception follows.



2009-01-29 19:09:00,844 [http-0.0.0.0-8080-10] INFO  
[org.apache.axis2.transport.http.HTTPSender] Unable to sendViaPost to 
url[https://www.xyz.com/911form/wsdl/e911/soap_server2.php]


java.net.ConnectException: Connection refused

At this stage, from a command line on the same JBoss server, can you try 
telnet www.xyz.com 443 and see what happens?


cheers
asankha

--
Asankha C. Perera
http://adroitlogic.org

http://esbmagic.blogspot.com

[jira] Closed: (AXIS2-4213) Dead Letter Queue Based Recovery

2009-01-18 Thread Asankha C. Perera (JIRA)

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

Asankha C. Perera closed AXIS2-4213.

Resolution: Won't Fix
Assignee: Asankha C. Perera

Hi Karthick

The JMS transport no longer lives in the Axis2 (Kernel) codebase, but in the
transports module of WS-Commons. Please check the latest code, and consider
your changes accordingly

thanks
asankha

Dead Letter Queue Based Recovery

Key: AXIS2-4213
URL: https://issues.apache.org/jira/browse/AXIS2-4213
Project: Axis 2.0 (Axis2)
Issue Type: Improvement
Components: kernel
Affects Versions: 1.3
Reporter: Karthick Sankarachary
Assignee: Asankha C. Perera
Fix For: 1.3

Attachments: dead-letter-queue.patch

Currently, when the server receives a JMS message that cannot be delivered to
a service, it simply drops it. By the same token, when the server fails to
deliver a JMS message to an external service, it is lost forever. This leaves
users guessing as to what was in that message and why the delivery failed.
Furthermore, there is no way for them to manually retry the delivery, even if
they have the know-how to correct the problem.
Typically, message brokers employ a dead letter queue, in which to store
undeliverable messages. This allows users to not only track such messages,
but also retry delivery of some of them. A few brokers even go to the extent
of customizing the dead letter queue based on who is sending or receiving the
message. This way, users can quickly identify the messages that they are
specifically interested in.
Let us try to apply these concepts to Axis2. Strictly speaking, the JMS
transport of Axis2 is not a JMS broker, but it does create JMS consumers and
producers, which have to handle delivery failures, as you might imagine. In
the event of such failures, the message should be sent to a default dead
letter queue, the scope of which is system-wide. If so desired, the user may
override the default location of the dead letter queue by specifying a
message context property or client option. For more details, please refer to
the patch that is attached here.

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

Re: svn commit: r734201 - in /webservices/axis2/trunk/java/modules: addressing/pom.xml saaj/pom.xml

2009-01-14 Thread Asankha C. Perera


Hi Jarek

I agree with changing the transport dependencies to test scope but in
general I'm a little concerned about the circular dependency between
axis2 and axis2-transport modules. Because of that circular dependency
I think we have to release axis2 and axis2-transport at the same time
(at least the base, local, tcp and http transport modules) and I
thought the idea behind splitting transport code from Axis2 was to
release the transport modules independently from Axis2.
  
Yes, for some reason some of the existing pom.xml's creates problems for 
projects down the line, with these issues. Its important to set the 
dependencies for runtime and testing etc correct. Also to fix the 
dependencies to avoid any circular dependencies. I firmly believe that 
transports need to be released separately, and its just a matter of time..


thanks
asankha


On Wed, Jan 14, 2009 at 4:48 AM, Andreas Veithen
andreas.veit...@gmail.com wrote:
  

Asankha,

I agree with your changes and I share your point of view that we
should reduce dependencies an the transports to a minimum. From what
I've seen, the problem is simply that some modules depending on
addressing, clustering and/or saaj (the ones you changed) implicitly
rely on the fact that they depend on the transports. Probably it is
just a matter of adding them as dependencies in scope test in the
right places (jaxws, metadata, etc.). I would have corrected that
myself yesterday if it were not for the fact that it takes 50 min to
build the whole Axis2 project :-)

Andreas

On Wed, Jan 14, 2009 at 04:38, Asankha C. Perera asan...@apache.org wrote:


Hi Andreas
  

I had to revert this change (and the previous one) because they cause
the Axis2 build to fail (not in the modules you changed, but in
modules depending on those, e.g. jaxws and metadata).



Thanks.. and I am sorry I couldn't run the full build of Axis2.. but I did
test the modules I changed, and still think that they should not make the
local and tcp transports required dependencies unless they are required at
runtime

Having unwanted dependencies just makes it difficult for these to be used by
other projects.. I will try to fix this in Axis2 again, or exclude them from
the Synapse build which will just make its pom larger :(

thanks
asankha
  



--
Asankha C. Perera
http://adroitlogic.org

http://esbmagic.blogspot.com

Re: svn commit: r734201 - in /webservices/axis2/trunk/java/modules: addressing/pom.xml saaj/pom.xml

2009-01-13 Thread Asankha C. Perera


Hi Andreas

I had to revert this change (and the previous one) because they cause
the Axis2 build to fail (not in the modules you changed, but in
modules depending on those, e.g. jaxws and metadata).
  
Thanks.. and I am sorry I couldn't run the full build of Axis2.. but I 
did test the modules I changed, and still think that they should not 
make the local and tcp transports required dependencies unless they are 
required at runtime


Having unwanted dependencies just makes it difficult for these to be 
used by other projects.. I will try to fix this in Axis2 again, or 
exclude them from the Synapse build which will just make its pom larger :(


thanks
asankha

On Tue, Jan 13, 2009 at 19:03,  asan...@apache.org wrote:
  

Author: asankha
Date: Tue Jan 13 10:02:54 2009
New Revision: 734201

URL: http://svn.apache.org/viewvc?rev=734201view=rev
Log:
make transport dependencies valid only for the testing scope in maven



--
Asankha C. Perera
http://adroitlogic.org

http://esbmagic.blogspot.com

[jira] Created: (AXIS2-4196) AxisEngine meddles with concerns of the transports, and creates a thread when sending out a message

2009-01-07 Thread Asankha C. Perera (JIRA)

AxisEngine meddles with concerns of the transports, and creates a thread when 
sending out a message
---

 Key: AXIS2-4196
 URL: https://issues.apache.org/jira/browse/AXIS2-4196
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: kernel
Affects Versions: nightly
Reporter: Asankha C. Perera
Priority: Critical


One of the most used widely methods of Axis2, the AxisEngine.send() method 
contains the following code, which causes the send operation to execute within 
another thread.

// This boolean property only used in client side fireAndForget 
invocation
//It will set a property into message context and if some one 
has set the
//property then transport sender will invoke in a diffrent 
thread
Object isTransportNonBlocking = 
msgContext.getProperty(MessageContext.TRANSPORT_NON_BLOCKING);
if (isTransportNonBlocking != null  ((Boolean) 
isTransportNonBlocking).booleanValue()) {

msgContext.getConfigurationContext().getThreadPool().execute(
new 
TransportNonBlockingInvocationWorker(msgContext, sender));
} else {
sender.invoke(msgContext);
}
//REVIEW: In the case of the 
TransportNonBlockingInvocationWorker, does this need to wait until that 
finishes?

In addition, the OutOnlyAxisOperation, in its executeImpl() method does:

// ship it out
if (!block) {
mc.setProperty(MessageContext.TRANSPORT_NON_BLOCKING, Boolean.TRUE);
}

The MessageContext defines this property as:
/**
 * To invoke fireAndforget method we have to hand over transport sending 
logic to a thread
 * other wise user has to wait till it get transport response (in the case 
of HTTP its HTTP
 * 202)
 */
public static final String TRANSPORT_NON_BLOCKING = transportNonBlocking;


The AxisEngine code creates a new thread if the transport is non-blocking 
which seems weired. AFAIK, the Kernel code should not be creating any threads 
like this, nor an AxisOperation set a property on the message about the 
transport. A transport blocking or non-blocking is outside of the purview of 
the Axis2 kernel, as even the Axis2 HTTP transports has already been 
implemented in both blocking and non-blocking manner.

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

[jira] Resolved: (AXIS2-3662) Can't use JMS transport from axis2.war on WebSphere Application Server 6.1

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

Asankha C. Perera resolved AXIS2-3662.
--

Resolution: Fixed

Fixed with WS-Commons transport revision 724432

The JMS transport does not use JEE prohibited APIs anymore.

Can't use JMS transport from axis2.war on WebSphere Application Server 6.1
--

Key: AXIS2-3662
URL: https://issues.apache.org/jira/browse/AXIS2-3662
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: kernel
Affects Versions: 1.3
Environment: WebSphere Application Server 6.1, Axis2 war deployment
Reporter: George Marrows

From
http://www.nabble.com/setMessageListener-not-permitted-in-Websphere-td15306747.html:

We are currently deploying axis2 in Websphere 6.1. We wish to
use the jms transport. However axis2 fails to start because
it uses forbidden api's.

On startup axis2's JMSConnectionFactory class calls the
listenOnDestination(String destinationJndi) method. Here it
creates a MessageConsumer and calls the
MessageConsumer.setMessageListener(MessageListener listener)
method. This causes failure and the exception thrown is as follows:
javax.jms.IllegalStateException: Method setMessageListener
not permitted

On looking through docs online it is clear that IBM have
stuck to the J2EE
1.4 specification. This states that the
MessageConsumer.setMessageListener(MessageListener listener)
method can not be called in a Web or EJB container. See
http://www.ibm.com/developerworks/library/j-getmess/ for details.
[See http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf, section 6.6 for the
actual spec reference.]
This means that the only way of deploying Axis2 with JMS transport on WAS is
to use the standalone axis server. This works, but a deployment within the
application server would be greatly preferable.

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Assigned: (AXIS2-3662) Can't use JMS transport from axis2.war on WebSphere Application Server 6.1

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

Asankha C. Perera reassigned AXIS2-3662:

Assignee: Asankha C. Perera

Can't use JMS transport from axis2.war on WebSphere Application Server 6.1
--

From
http://www.nabble.com/setMessageListener-not-permitted-in-Websphere-td15306747.html:

We are currently deploying axis2 in Websphere 6.1. We wish to
use the jms transport. However axis2 fails to start because
it uses forbidden api's.

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2-545) WSDL port address for JMS


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

Asankha C. Perera resolved AXIS2-545.
-

Resolution: Fixed
  Assignee: Asankha C. Perera

Probably fixed ages ago.. if not.. its now fixed with WS-Commons transport 
revision 724432 :)

 WSDL port address for JMS
 -

 Key: AXIS2-545
 URL: https://issues.apache.org/jira/browse/AXIS2-545
 Project: Axis 2.0 (Axis2)
  Issue Type: Improvement
  Components: wsdl
Reporter: rnell
Assignee: Asankha C. Perera

 A WSDL port's address specified as jms:/destination where destination is a 
 queue or topic is a bit limiting. I can't connect to mulitple JMS servers 
 because there only one JMS Connection Factory is supported.
 IBM uses:
 jms:address
 destinationStyle=queue  
 jmsVendorURI=http://ibm.com/ns/mqseries;
 initialContextFactory=com.ibm.NamingFactory
 jndiProviderURL=iiop://something:900/wherever
 jndiConnectionFactoryName=orange
 jndiDestinationName=fred
 /
 see:
 http://publib.boulder.ibm.com/infocenter/wasinfo/v5r1//index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/twsf_prsjwe.html

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2-4164) Allow to specify JMS username and password directly via properties in JMS Transport.

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

Asankha C. Perera resolved AXIS2-4164.
--

Resolution: Fixed
Fix Version/s: 1.5
Assignee: Asankha C. Perera

Fixed with WS-Commons transport revision 724432

Introduced two new parameters
transport.jms.UserName
transport.jms.Password

Allow to specify JMS username and password directly via properties in JMS
Transport.

Key: AXIS2-4164
URL: https://issues.apache.org/jira/browse/AXIS2-4164
Project: Axis 2.0 (Axis2)
Issue Type: Improvement
Components: transports
Environment: Axis2 1.4.1 with Tibco EMS.
Reporter: Gabor Herr
Assignee: Asankha C. Perera
Fix For: 1.5

Attachments: axis141-jms-user.patch, axis141-jms-user.patch2

Original Estimate: 0.5h
Remaining Estimate: 0.5h

Currently the JMS Transport on client side allows to specify username and
password for JNDI access via URL properties. In production environments
typically the JMS server also secured with username and password. There has
been an improvement to allow to specify JMS username passwords *indirectly*
by referring to corresponding JNDI entries
- transport.jms.ConnectionFactoryJNDIUser
- transport.jms.ConnectionFactoryJNDIPass
For a client only setup, where the JNDI content cannot be configured with
these indirect values, it would be useful to set these values directly via
the URL.
The attached patch extends the current code to obtain these values from the
properties
- transport.jms.ConnectionFactoryUser
- transport.jms.ConnectionFactoryPass
If these are not set, it falls back to the previous JNDI values.
The second patch implements the same mechanism for JMSListener on the server
side. In this case the properties will be used from axis2.xml similar to the
JNDI approach.
I would appreciate, if you could include this improvement into the next
release.

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2-3088) Set header fields of JMS message


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

Asankha C. Perera resolved AXIS2-3088.
--

   Resolution: Fixed
Fix Version/s: 1.5

Please set transport level headers as necessary

 Set header fields of JMS message
 

 Key: AXIS2-3088
 URL: https://issues.apache.org/jira/browse/AXIS2-3088
 Project: Axis 2.0 (Axis2)
  Issue Type: Improvement
Affects Versions: 1.2
 Environment: Windows XP
Reporter: Dominik Erni
Assignee: Asankha C. Perera
 Fix For: 1.5


 I need to set the two JMS message header fields Content_type and 
 Mime_Version. I achieved to set the content type with:
  Options options = stub._getServiceClient().getOptions();
  options.setProperty(org.apache.axis2.Constants.Configuration.CONTENT_TYPE, 
 application/xml; charset=\iso-8859-1\  );
 Shouldn't this also be possible for the Mime Version?
 I read the workaround proposed by you to replace the JMSSender class by a 
 copy where these two properties are set with a string property in the class 
 itself, but this is not an option for me.
 Regards,
 Dominik

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2-1665) JMS destination should not be dedicated to only a single service


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

Asankha C. Perera resolved AXIS2-1665.
--

   Resolution: Fixed
Fix Version/s: 1.5

Partly resolved with WS-Commons transport revision 724432

We now support JMS message selectors. Thus it is possible to define two 
services to listen for messages over the same destination etc

 JMS destination should not be dedicated to only a single service
 

 Key: AXIS2-1665
 URL: https://issues.apache.org/jira/browse/AXIS2-1665
 Project: Axis 2.0 (Axis2)
  Issue Type: Improvement
  Components: transports
 Environment: Not important
Reporter: Ali Sadik Kumlali
Assignee: Asankha C. Perera
Priority: Minor
 Fix For: 1.5


 I'm creating this issue to address the improvements of JMS destination usage 
 discussed in the axis-dev [1].
 Here is the summary:
 Requirements
 ---
 - A single destination can be used for messages of different services
 - Multiple destinations can be used for messages of the same service
 Proposal
 ---
 At client side:
- Including the service name in the EPR (JMS URL)
- Adding service name to the JMS message header before sending it (the 
 same approach used for transferring SOAPAction)
 At service side:
   - Setting to field of the MC to the value of service name field retrieved 
 from JMS message header.
   - Setting soapAction field of the MC to the value of SOAPAction field 
 retrieved from JMS message header (this is already done with the current 
 implementation).
 Advantages of the proposal 
 ---
 - Being more consistent with the other tranports, as all of them include 
 service name to EPR
 - No need for an association between destination and service, thus no need 
 destination-service association in services.xml
 - Being able to use a single destination for multiple services
 - Being able to dispatch messages come from different destionations to the 
 same service
 [1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg24261.html

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2-4025) Using JMSMessageID as correlationID for JMS messages

[
https://issues.apache.org/jira/browse/AXIS2-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654506#action_12654506
]

Asankha C. Perera commented on AXIS2-4025:
--

Hi Cathal

We have updated the JMS transport quite a bit recently.. could you check if the
issue still persists? If so, you are encouraged to offer a patch to further
enhance

thanks
asankha

Using JMSMessageID as correlationID for JMS messages

Attachments: JMSMessageReceiver.java, JMSSender.java

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2-3774) WSDL is not getting generated with SOAP Over JMS


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

Asankha C. Perera resolved AXIS2-3774.
--

   Resolution: Fixed
Fix Version/s: 1.5
 Assignee: Asankha C. Perera

Should certainly be fixed with WS-Commons transport revision 724432

 WSDL is not getting generated with SOAP Over JMS
 

 Key: AXIS2-3774
 URL: https://issues.apache.org/jira/browse/AXIS2-3774
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: samples
Affects Versions: 1.3
 Environment: axis 1.3, Jboss 4.0.4  TIBCO BW
Reporter: Ramakrishna
Assignee: Asankha C. Perera
 Fix For: 1.5

   Original Estimate: 6h
  Remaining Estimate: 6h

 I am developing a web service over TIBCO JMS with axis 1.3. My service is 
 installed in jboss 4.0.4. My problem is the wsdl is not getting created for 
 this. In the service list(http://localhost:8080/axis2/services/listServices) 
 it is showing active status. but when I visit go to 
 http://localhost:8080/axis2/services/echoservice?wsdl it gives me following 
 error. Please help me on this.  
 Exception:
 java.lang.ArrayIndexOutOfBoundsException: 0
   org.apache.axis2.description.AxisService.getWSDL(AxisService.java:1137)
   
 org.apache.axis2.description.AxisService.printWSDL(AxisService.java:1077)
   
 org.apache.axis2.transport.http.ListingAgent.processListService(ListingAgent.java:280)
 Axis2.xml entries
 transportReceiver name=jms 
 class=org.apache.axis2.transport.jms.JMSListener
 parameter name=TibcoQueueConnectionFactory locked=false 
 parameter name=java.naming.factory.initial 
 locked=falsecom.tibco.tibjms.naming.TibjmsInitialContextFactory/parameter
 parameter name=java.naming.provider.url 
 locked=falsetibjmsnaming://localhost:7222/parameter 
 parameter name=transport.jms.ConnectionFactoryJNDIName 
 locked=falseQueueConnectionFactory/parameter 
 /parameter
 /transportReceiver
 transportSender name=jms class=org.apache.axis2.transport.jms.JMSSender/
 My service class:
 public class EchoService {
   private Logger logger = null;
   public String echoString(String in) {
 return in+(new Date());
   }
 }
 and the service.xml entries are
 service name=echoservice
 transports
   transportjms/transport
 /transports
 descriptionEcho2 Service/description
 messageReceivers
   messageReceiver mep=http://www.w3.org/2004/08/wsdl/in-only;
 class=org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver/
   messageReceiver mep=http://www.w3.org/2004/08/wsdl/in-out;
 class=org.apache.axis2.rpc.receivers.RPCMessageReceiver/ 
 /messageReceivers
 parameter name=ServiceClass 
 locked=truecom.ge.nbc.media.service.jms.webservice.EchoService/parameter
 parameter name=transport.jms.ConnectionFactory 
 locked=trueTibcoQueueConnectionFactory/parameter
 parameter name=transport.jms.Destination 
 locked=truemy.queue/parameter
   /service
 Ramakrishna

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2-3485) Failure to start JMS listener badly reported


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

Asankha C. Perera resolved AXIS2-3485.
--

   Resolution: Fixed
Fix Version/s: 1.5

Fixed with WS-Commons transport revision 724432

 Failure to start JMS listener badly reported
 

 Key: AXIS2-3485
 URL: https://issues.apache.org/jira/browse/AXIS2-3485
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: kernel
Affects Versions: 1.3
 Environment: JBoss 4.0.5, Windows XP
Reporter: George Marrows
Assignee: Asankha C. Perera
Priority: Minor
 Fix For: 1.5


 1. In ListenerManager.start() exceptions are reported using log.info(); 
 log.error would be more appropriate
 2. ClassCastExceptions in JMSConnectionFactory.connect() (and presumably 
 elsewhere under ListenerManager.start()) are badly reported as eg 
 14:04:33,633 INFO  [ListenerManager] 
 org.jboss.resource.adapter.jms.JmsConnectionFactoryImpl
 They should be better handled by ListenerManager.start(), or perhaps by 
 exception code in the connect() method.
 Background: when deploying a JMS-enabled Axis2 war on JBoss 4.0.5, the line 
   conFactory = (ConnectionFactory) context.lookup(jndiName);
 in JMSConnectionFactory.connect() throws a ClassCastException, which is 
 caused by javax.jms.ConnectionFactory being loaded twice by different class 
 loaders. This is easily fixed by removing 
 WEB-INF/lib/geronimo-jms_1.1_spec-1.1.jar, once the underlying problem has 
 been identified. Unfortunately the combination of problems 1 and 2 mean that 
 I was only able to see what was going wrong by stepping through the code.
 See also https://issues.apache.org/jira/browse/AXIS2-3377

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2-3238) Encoding of text messages using SOAP over JMS


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

Asankha C. Perera resolved AXIS2-3238.
--

   Resolution: Fixed
Fix Version/s: 1.5

The problematic area reported has been fixed sometime back

Please check with WS-Commons transport revision 724432

 Encoding of text messages using SOAP over JMS
 -

 Key: AXIS2-3238
 URL: https://issues.apache.org/jira/browse/AXIS2-3238
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
Reporter: Leo Huber
Assignee: Asankha C. Perera
 Fix For: 1.5


 Hi,
 I am new to axis2 and jms. We are sending soap messages over JMS 
 textmessages. We are struggling with a encoding issue and 
 I tried to find the source of the problem. I found that the class JMSSender 
 handles receiving jms text messages like any other message and creates a 
 bytestream using the getInputStream method in JMSUtils. However, the 
 bytestream is either encoded with the encoding set in 
 the message or with the default encoding of the operating system (see the 
 copy of the method below). Later this bytestream is
 used to create a SOAP Message object using the encoding set in 
 Constants.Configuration.CONTENT_TYPE. This leads to an encoding
 issue if the encoding used to create the byte stream and the encoding to read 
 the byte stream (create the soap message)
 are not the same. 
 We are developing on windows machines but are testing on linux machines which 
 both have different default encoding set in the jvm. Therefore, because of 
 the 
 behaviour described above axis2 behaves differently on linux and windows. 
 However, I don't see why axis creates a byte stream with a possibly different 
 encoding
 than creating the soap message with that stream.
 Regards
 Leo
 /**
  * Get an InputStream to the message
  *
  * @param message the JMS message
  * @return an InputStream
  */
 public static InputStream getInputStream(Message message) {
 try {
 // get the incoming msg content into a byte array
 if (message instanceof BytesMessage) {
 byte[] buffer = new byte[8 * 1024];
 ByteArrayOutputStream out = new ByteArrayOutputStream();
 BytesMessage byteMsg = (BytesMessage) message;
 for (int bytesRead = byteMsg.readBytes(buffer); bytesRead != 
 -1;
  bytesRead = byteMsg.readBytes(buffer)) {
 out.write(buffer, 0, bytesRead);
 }
 return new ByteArrayInputStream(out.toByteArray());
 } else if (message instanceof TextMessage) {
 TextMessage txtMsg = (TextMessage) message;
 String contentType = 
 message.getStringProperty(JMSConstants.CONTENT_TYPE);
 if (contentType != null) {
 return
 new ByteArrayInputStream(
 txtMsg.getText().getBytes(
 
 BuilderUtil.getCharSetEncoding(contentType)));
 } else {
 return
 new 
 ByteArrayInputStream(txtMsg.getText().getBytes());
 }
 } else {
 handleException(Unsupported JMS message type :  +
 message.getClass().getName());
 }
 } catch (JMSException e) {
 handleException(JMS Exception getting InputStream into message, 
 e);
 } catch (UnsupportedEncodingException e) {
 handleException(Encoding exception getting InputStream into 
 message, e);
 }
 return null;
 }

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Enhancements to the JMS transport in WS-Commons / Transports

2008-12-08 Thread Asankha C. Perera

Hi All

We have updated the new unified JMS transport code shared between Apache
Axis2 and Apache Synapse. This code now lives in WS-Commons, transport
module. The new enhancements allows JMS services to support both local
JMS and distributed JTA transactions. In addition, we have also moved
away from the use of asynchronous message receiving API into a polling
model, which should allow the code to run within or outside of any JEE
servers without conflicts. Please do test your scenarios with the
updated transport, and report back any issues, before we cut the first
release of this code sometime early next year.

Some of the new parameters supported are described in the package
documentation in the SVN [1], and also copied here for easy reference:
http://adroitlogic.org/knowledge-base-axis2/9-the-enhanced-jms-transport.html

A simple Axis2 sample illustrating a POJO service over JMS and the
generation of a client for SOAP/JMS is detailed here:
http://adroitlogic.org/knowledge-base-axis2/10-soap-over-jms-with-apache-axis2.html

Synapse ESB examples will soon follow, and illustrate some of the
advanced concepts. Your feedback is appreciated and most welcome.

cheers
asankha

[1]
http://svn.apache.org/viewvc/webservices/commons/trunk/modules/transport/modules/jms/src/main/java/org/apache/axis2/transport/jms/package.html?revision=724432content-type=text%2Fhtml

--
Asankha C. Perera
http://adroitlogic.org

http://esbmagic.blogspot.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Committing patch contributed for MIME message parser and serializer based on Apache mime4j [WSCOMMONS-387]

2008-11-22 Thread Asankha C. Perera


Dims

The package org.apache.axiom.mime defines the interfaces, and the 
package org.apache.axiom.mime.impl which implements these using Mime4J. 
I don't see why anyone else cannot implement these interfaces with any 
other implementation..


Is your view on this still based on the following?
/One problem from my personal point of view is that for JAXWS support 
we need javamail :( to be compliant to the spec/ [1]


asankha

[1] http://markmail.org/message/kfs3mpfkkwvwbdb2


without using MIME4J.

thanks,
dims

On Sat, Nov 22, 2008 at 7:27 AM, Oleg Kalnichevski [EMAIL PROTECTED] wrote:
  

On Thu, 2008-11-20 at 11:34 -0500, Davanum Srinivas wrote:


Oleg,

I totally agreed with you if you scroll back a few emails. Yes, we
need to fix *that*. Any patch to do that will be *very* welcome.

  

Ironically enough, this is precisely what the patch does.

Oleg


--
Asankha C. Perera
http://adroitlogic.org

http://esbmagic.blogspot.com

Re: [VOTE] Axis2 as TLP

2008-11-21 Thread Asankha C. Perera


I am -1 (binding) on this proposal as it is.

I am not for, or against Axis2 becoming a TLP, but I am strongly opposed 
to moving the transports to within Axis2, as it would make it difficult 
to develop and release new versions of them independently of the Axis2 
trunk and release cycles - which are known to be long and painful.


Apache Synapse folks developed some of these transports as they are 
highly dependent on these, and they frequently require quick fixes at 
transport level to be able to add new features and handle various 
issues. Thus the ability to get a new version of the transports released 
when needed is immensely important for Apache Synapse among other 
issues. In addition as a developer, I have to admit that I hate to build 
Axis2 trunk each time I want to commit changes to a transport, as it 
takes ages to build and fills up the M2 repo and finally fails many 
times due to various issues. The interface between a transport and 
anything else is clear, and you do not need to stick it deep into a 
parent codebase to keep both working.


We also have had length discussions on this for a long time, and 
agreement from *all* the key players involved in this discussion, to 
make the new WS-transports sub project outside of Axis2 - with 
independent release cycles etc. I do not want to make this VOTE thread a 
discussion, but wanted everyone to be aware on the effect of these 
actions on those who develop and use this piece of software.


asankha

[1] http://markmail.org/message/uvhz22bqnkjq3wmf
[2] http://markmail.org/message/fr73nj32lchlgbxi
[3] http://markmail.org/message/okzimikvmbhimflr

Glen Daniels wrote:

Folks:

Discussion seems to have died down about the TLP proposal, and I think 
we heard a lot of valuable viewpoints during the conversation.  At 
this point, I think it's time to VOTE on the idea and see where we're at.


I've described what we're voting on on the wiki page [1], and will 
include it here as well:


* Restructure Axis2 as an independent TLP, containing subprojects that 
*directly* relate to Axis2 - these include all the Modules and 
Transports. This ends up being a reasonably sized and well-focused 
project.


* Once Axis2 is split out, we'll move the sub-sub-projects inside 
WS-Commons (Axiom, Neethi, XmlSchema) up to be WS subprojects. This 
will also involve making sure that the SVN authorizations are 
appropriately granular.


* We'll then do a review of the remaining projects inside WS and based 
on that, decide whether any further action is needed. Such actions 
might include promoting more projects to TLPs, or retiring stagnant 
codebases.


Please chime in with your VOTE on this (and indicate 
binding/non-binding depending on whether you are a PMC member).


Here's my +1 (binding).

Thanks,
--Glen

[1] http://wiki.apache.org/ws/FrontPage/Proposals/Axis2TLPProposal


--
Asankha C. Perera
http://adroitlogic.org

http://esbmagic.blogspot.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Committing patch contributed for MIME message parser and serializer based on Apache mime4j [WSCOMMONS-387]

2008-11-19 Thread Asankha C. Perera


Hi Dims

I am not clear on this.. what you are suggesting is to just move the new 
code to another maven module only? or to make it available as an option 
to someone who wants to use it? If the new implementation has drawbacks 
I understand, but if its better, why not just switch? or are we looking 
for more performance test results to decide on this?


asankha

On Tue, 2008-11-18 at 22:50 -0500, Davanum Srinivas wrote:
  

Asankha,

Please check in ONLY if the new MIME4J dependent code is in another
maven module.

thanks,
dims




Asankha et al

The patch was meant as a replacement for the existing implementation. It
is pointless to have two MIME frameworks in Axiom. Just forget about the
patch.

Oleg


  

On Tue, Nov 18, 2008 at 9:46 PM, Asankha C. Perera [EMAIL PROTECTED] wrote:


Hi all

Last night I noticed that the patch contributed by Oleg for better MIME
parsing [1] has not yet been committed after 2 months

The patch is still valid against the trunk, but I am not in the best
position to analyze it at an Axiom level, but I am very confident of its
benefits, and thus would like to request someone more capable to review it
ASAP, failing which I will commit it shortly

thanks
asankha

[1] https://issues.apache.org/jira/browse/WSCOMMONS-387

Mime4j can handle very complex MIME messages, is reasonably fast, and, most
importantly, can stream complex MIME messages in and out with a predictable
memory footprint (using just a small internal buffer of a constant length).
This patch expects to allow Axiom to provide an alternative API based on a
fully streamable model.
  
  



--
Asankha C. Perera
http://adroitlogic.org

http://esbmagic.blogspot.com

Re: Cluttering of debug logs for each Parameter add

2008-11-15 Thread Asankha C. Perera


Hi All

I have changed the call stack prints I found to TRACE level, on both 
Axis2 and Axiom. I also saw the code creating a RuntimeException just to 
dump the stack trace, which could be replaced by 
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#dumpStack()


I hope in future, we will better use the many available log levels for 
the benefit of all


asankha

Eran Chinthaka wrote:

Hi  Asankha,

I don't think having callstack printed on debug level is a good thing. 
Of course you can set your log level to a higher one, but even at 
debug level, printing call stacks might be cumbersome.


So +1 for the suggestion.

With Mettha,
Eran Chinthaka


Health is the greatest gift; contentment is the greatest wealth; 
trusting is the best relationship; nirvana is the highest joy. - 
Dhammapada



On Thu, Nov 13, 2008 at 11:04 PM, Asankha C. Perera 
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:


Hi All

I am seeing loads and loads of the following log message, which
dumps the thread stack whenever a Parameter was added.. This
severely clutters the log files, and makes it difficult to
troubleshoot any other problems.

Although this level of debug information would be valuable to nail
down some issues local to this area, I do not think this should be
left enabled when Axis2 log level is debug.. ideally this could be
only at a TRACE level, probably when another switch is turned on
as well.

asankha

720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl
- ==
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl
-  Parameter add on object
[EMAIL PROTECTED]
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl
-   Key =hotdeployment
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl
-   Value =true
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl
-   Value Class = java.lang.String
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl
-   Value Classloader = null
721 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl
- Call Stack = DEBUG_FRAME =
org.apache.axis2.util.JavaUtils.callStackToString(JavaUtils.java:564)
  DEBUG_FRAME =

org.apache.axis2.description.ParameterIncludeImpl.debugParameterAdd(ParameterIncludeImpl.java:315)
  DEBUG_FRAME =

org.apache.axis2.description.ParameterIncludeImpl.addParameter(ParameterIncludeImpl.java:106)
  DEBUG_FRAME =

org.apache.axis2.description.AxisDescription.addParameter(AxisDescription.java:102)
  DEBUG_FRAME =

org.apache.axis2.deployment.DescriptionBuilder.processParameters(DescriptionBuilder.java:568)
  DEBUG_FRAME =

org.apache.axis2.deployment.AxisConfigBuilder.populateConfig(AxisConfigBuilder.java:101)
  DEBUG_FRAME =

org.apache.axis2.deployment.DeploymentEngine.populateAxisConfiguration(DeploymentEngine.java:707)
  ...
  ... ## TRUNCATED ## ..
  ...



--
Asankha C. Perera
http://adroitlogic.org

http://esbmagic.blogspot.com

Cluttering of debug logs for each Parameter add

2008-11-13 Thread Asankha C. Perera


Hi All

I am seeing loads and loads of the following log message, which dumps 
the thread stack whenever a Parameter was added.. This severely clutters 
the log files, and makes it difficult to troubleshoot any other problems.


Although this level of debug information would be valuable to nail down 
some issues local to this area, I do not think this should be left 
enabled when Axis2 log level is debug.. ideally this could be only at a 
TRACE level, probably when another switch is turned on as well.


asankha

720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl - 
==
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -  
Parameter add on object 
[EMAIL PROTECTED]
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -   
Key =hotdeployment
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -   
Value =true
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -   
Value Class = java.lang.String
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -   
Value Classloader = null
721 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl - 
Call Stack = DEBUG_FRAME = 
org.apache.axis2.util.JavaUtils.callStackToString(JavaUtils.java:564)
   DEBUG_FRAME = 
org.apache.axis2.description.ParameterIncludeImpl.debugParameterAdd(ParameterIncludeImpl.java:315)
   DEBUG_FRAME = 
org.apache.axis2.description.ParameterIncludeImpl.addParameter(ParameterIncludeImpl.java:106)
   DEBUG_FRAME = 
org.apache.axis2.description.AxisDescription.addParameter(AxisDescription.java:102)
   DEBUG_FRAME = 
org.apache.axis2.deployment.DescriptionBuilder.processParameters(DescriptionBuilder.java:568)
   DEBUG_FRAME = 
org.apache.axis2.deployment.AxisConfigBuilder.populateConfig(AxisConfigBuilder.java:101)
   DEBUG_FRAME = 
org.apache.axis2.deployment.DeploymentEngine.populateAxisConfiguration(DeploymentEngine.java:707)

   ...
   ... ## TRUNCATED ## ..
   ...

--
Asankha C. Perera
http://adroitlogic.org

http://esbmagic.blogspot.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cluttering of debug logs for each Parameter add

2008-11-13 Thread Asankha C. Perera



Usually logging frameworks support configuring different levels of logging at 
different package levels. While I am +1 for having a clear separation of 
TRACE level messages vs DEBUG level messages

Sanjaya

Actually this problem is not local to parameter manipulation... it 
exists in Axiom as well and maybe elsewhere..


e.g.
1816 [Axis2 Task] DEBUG org.apache.axiom.om.impl.MTOMXMLStreamWriter - 
Call Stack =DEBUG_FRAME = 
org.apache.axiom.om.util.CommonUtils.callStackToString(CommonUtils.java:80)
   DEBUG_FRAME = 
org.apache.axiom.om.impl.MTOMXMLStreamWriter.init(MTOMXMLStreamWriter.java:91)
   DEBUG_FRAME = 
org.apache.axiom.om.impl.llom.OMNodeImpl.serialize(OMNodeImpl.java:462)
   DEBUG_FRAME = 
org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:77)


Also consider this fragment:

743 [main] DEBUG org.apache.axiom.om.impl.llom.OMElementImpl - There are 
no child elements that match the unqualifed name: module
743 [main] DEBUG org.apache.axiom.om.impl.llom.OMElementImpl - Now 
looking for child elements that have the same local name.
743 [main] DEBUG org.apache.axiom.om.impl.llom.OMElementImpl - There are 
no child elements that match the unqualifed name: transportSender
743 [main] DEBUG org.apache.axiom.om.impl.llom.OMElementImpl - Now 
looking for child elements that have the same local name.
743 [main] DEBUG org.apache.axiom.om.impl.llom.OMElementImpl - There are 
no child elements that match the unqualifed name: transportReceiver



Stack traces as strings and these types of very low level messages I 
think should be at TRACE..

.. that type of a configuration could help reduce too many unrelated log 
messages in the log when troubleshooting a problem.
  
The problem is that the log level is inherited by the Axis2 log level.. 
and it wont be nice to expect users to explicitly exclude this category


asankha

On Friday 14 November 2008, Asankha C. Perera wrote:
  

Hi All

I am seeing loads and loads of the following log message, which dumps
the thread stack whenever a Parameter was added.. This severely clutters
the log files, and makes it difficult to troubleshoot any other problems.

Although this level of debug information would be valuable to nail down
some issues local to this area, I do not think this should be left
enabled when Axis2 log level is debug.. ideally this could be only at a
TRACE level, probably when another switch is turned on as well.

asankha

720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -
==
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -
Parameter add on object
[EMAIL PROTECTED]
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -
Key =hotdeployment
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -
Value =true
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -
Value Class = java.lang.String
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -
Value Classloader = null
721 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -
Call Stack = DEBUG_FRAME =
org.apache.axis2.util.JavaUtils.callStackToString(JavaUtils.java:564)
DEBUG_FRAME =
org.apache.axis2.description.ParameterIncludeImpl.debugParameterAdd(Paramet
erIncludeImpl.java:315) DEBUG_FRAME =
org.apache.axis2.description.ParameterIncludeImpl.addParameter(ParameterInc
ludeImpl.java:106) DEBUG_FRAME =
org.apache.axis2.description.AxisDescription.addParameter(AxisDescription.j
ava:102) DEBUG_FRAME =
org.apache.axis2.deployment.DescriptionBuilder.processParameters(Descriptio
nBuilder.java:568) DEBUG_FRAME =
org.apache.axis2.deployment.AxisConfigBuilder.populateConfig(AxisConfigBuil
der.java:101) DEBUG_FRAME =
org.apache.axis2.deployment.DeploymentEngine.populateAxisConfiguration(Depl
oymentEngine.java:707) ...
... ## TRUNCATED ## ..
...




  

--
Asankha C. Perera
http://adroitlogic.org

http://esbmagic.blogspot.com

Re: [Axis2] Moving all the transports into a common modules

2008-09-22 Thread Asankha C. Perera


Hi all

I will be moving the Mail, JMS and the Base Transport abstraction into 
the WS Commons project now.


Then on WS-Commons dev list (CC:ing axis2-dev), I will be calling for a 
vote for commit rights to Andreas, so that he can help maintain the codebase


We will consider moving other transports on a case-by-case basis, if 
there will be an advantage for them for plain Axis2 as well.


asankha

Andreas Veithen wrote:

Amila,

Please don't move anything for the moment. We need to make sure that 
this is well coordinated before doing anything. I will come back on 
this later.


Andreas

Amila Suriarachchi wrote:



On Sun, Sep 21, 2008 at 2:59 PM, Andreas Veithen 
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:


Deepal,

Before we can move anything from Synapse to the new commons
module, we need to decide which transports we move (all or only a
subset) and based on that, we need to make sure that all the
people involved in the maintenance of these transports have commit
access to the new module.


As a starting point I'll put the synapse SMTP transport to commons 
transport and try to test with Axis2.


thanks,
Amila.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Andreas Veithen as a WS committer

2008-09-22 Thread Asankha C. Perera


Folks

Andreas Veithen has been an active committer of the Apache Synapse 
project from February, and has helped improve, add and enhance the 
transport implementations that grew under the Synapse project for Apache 
Axis2. Now as we move some of these transports into WS-Commons, I 
propose that Andreas be granted Karma in the WS project to help continue 
this work


asankha


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Andreas Veithen as a WS committer

2008-09-22 Thread Asankha C. Perera


+1 from me
asankha

Asankha C. Perera wrote:

Folks

Andreas Veithen has been an active committer of the Apache Synapse 
project from February, and has helped improve, add and enhance the 
transport implementations that grew under the Synapse project for 
Apache Axis2. Now as we move some of these transports into WS-Commons, 
I propose that Andreas be granted Karma in the WS project to help 
continue this work


asankha




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Understanding asynchrounous request processing in Apache Synapse/Axis2/Http Core NIO

2008-07-20 Thread Asankha C. Perera


Hi Eric

Oleg Kalnichevski wrote:

On Sun, 2008-07-20 at 16:39 +0200, Hubert, Eric wrote:
  

Hi devs,

we are facing an issue in Apache Synapse where HttpClientWorkers are in
the process of writing a response back to the client using
HttpCoreNIOSender.sendAsyncResponse(), but are then waiting at
org.apache.http.nio.util.SharedOutputBuffer.flushContent() to get
notified by someone...

I'd like to take this issue as a start to gather more knowledge about
the internal working of Apache Synapse and http core nio in general.
Could someone please point me to some documentation, which describes,
how the request/response processing is working. 



Eric,

I am very sorry but we currently have almost nothing in terms of
documentation for HttpCore. I am planning to start working on an
HttpCore tutorial in August. 


Asankha knows best about the Synapse NIO transport. I'll happily chip
in information about HttpCore internal stuff

...
  
I know that ideally I should have made more documentation available on 
the NIO transport implementation, but due to other work I am involved 
with, this has gone down in my TODO list.. I will try to come back to 
this in the near future.. However, HttpCore/NIO is where the really cool 
code exists, and Synapse/Axis2 is merely using it..

The response is processed by the ClientWorker who delegates the response
processing to Axis2 (again the blackbox of AxisEngine.receive,
AxisEngine.send) and then the response shall be send back to the client
over the MessageFormatter which again uses some NIO buffer. Here we have
the trouble that the code in
org.apache.http.nio.util.SharedOutputBuffer.flushContent() is waiting
for some notification. Who is responsible for that notification? 



It expects a notification from the I/O reactor it is ready to accept
more output.
This is because we recently enhanced the way we converted from NIO 
channels to Java streams, using the shared buffers available in 
HttpCore/NIO. In addition, we now throttle the connection, and suspend 
IO on the socket when the corresponding buffer is filled up - and 
prevents out of memory errors, and allows the transport to operate with 
constant memory.

The
HttpCoreNIOSender.reactor? I couldn't find any useful API-doc on this.
I'm also looking for some httpcore-nio-4.0-beta1-sources.jar from any
Maven Repo to attach to my synapse-IDE project.

Does anybody know something about possible causes for not getting such a
notification?

I was able to reproduce a 'simulated' case of what you experienced, and 
this was caused by a connection close while the worker thread was 
writing data and waiting on the flushContent() for a large response. 
Once you confirm the temporary fix I provided you, I will check it into 
the trunk with a JIRA so that it goes into the next release


asankha

--
Asankha C. Perera

WSO2 - http://wso2.org
http://esbmagic.blogspot.com

Re: next axis2 release with healthy JMS support

2008-07-09 Thread Asankha C. Perera


Michael

I am in the process of updating the JMS transport to be much better.. 
actually we have quite a list of enhancements like, support for 
deployment in JEE 1.4 and standalone, support for JMS 1.0.x and 1.1, 
support for the proposed SOAP/JMS spec and its IRI - while maintaining 
backwards compatibility, Supporting transacted messages both within and 
outside a container, supporting more than one service with one JMS 
destination, handling duplicates, redelivery and better support for JMS 
headers, debugging/trace, TTL, TTD, Support for Map messages etc..


This will take some time to complete and stabilize, and we will develop 
this transport outside of Synapse and Axis2 - under a new module in WS 
commons. I cannot give you an ETA right now as I am still studying 
options and designing support, but will make these available on a wiki 
and will ask for public comments once that phase is done.


asankha

keith chapman wrote:

Hi Micheal,

The Synapse guys are very active when it comes to Transports for 
Axis2. Asankha has been doing numerous improvements on this. So I 
suggest that you get the synapse-transports jar and drop it into your 
lib directory and use the JMS transport included in that jar.


Thanks,
Keith.

On Tue, Jul 8, 2008 at 11:25 PM, Wagner, Michael 
[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


Hallo,

(Sorry for my question) but when do you expect to release a new
version
with a healthy JMS support. I could not find anything regarding JMS
support in the trunc. So I am a little bit concerned about using
Axis2,
since JMS is a major issue for me. I have only seen a commit comment
like stale JMS code dumped see axis-dev.

For sure, the old implementation had some issues (creating always a
queue indtead of the topic I need).=20

Can you give me any insight on the time schedule, please?

Thanks,
 Michael


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]




--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/

blog: http://www.keith-chapman.org 


--
Asankha C. Perera

WSO2 - http://wso2.org
http://esbmagic.blogspot.com

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

2008-07-08 Thread Asankha C. Perera




Nandana,

+1 from me for you to be the Release Manager for 1.4.1


+1 for Nandana as the release manager

Nandana
I would also like to suggest 
https://issues.apache.org/jira/browse/AXIS2-3887 for inclusion, as this 
prevents Synapse from using the servlet transport effectively, since it 
sends faults always using an HTTP 200 instead of 500. This is a 10 line 
fix, and I can commit it to the 1.4.1 branch if you approve this


thanks
asankha

[jira] Created: (AXIS2-3887) The servlet transport does not set the HTTP response code to 500 when a SOAP fault is returned (unless an exception was thrown)

2008-07-03 Thread Asankha C. Perera (JIRA)

The servlet transport does not set the HTTP response code to 500 when a SOAP 
fault is returned (unless an exception was thrown)
---

 Key: AXIS2-3887
 URL: https://issues.apache.org/jira/browse/AXIS2-3887
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: transports
Affects Versions: 1.4
Reporter: Asankha C. Perera
Assignee: Asankha C. Perera


Steps:
Edit axis2-1.4/samples/userguide/src/userguide/example1/MyService.java and make 
it look like shown below:

package userguide.example1;
import org.apache.axiom.om.OMElement;

import org.apache.axis2.AxisFault;


import javax.xml.stream.XMLStreamException;




public class MyService {

public OMElement echo(OMElement element) throws XMLStreamException {
return 
org.apache.axiom.om.OMAbstractFactory.getSOAP11Factory().getDefaultFaultEnvelope().getBody().getFirstElement();

}



public void ping(OMElement element) throws XMLStreamException {

//Do some processing

}

public void pingF(OMElement element) throws AxisFault{

throw new AxisFault(Fault being thrown);

}

}

Invoking the echo service now returns:
HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Content-Type: text/xml;charset=UTF-8

Transfer-Encoding: chunked

Date: Thu, 03 Jul 2008 08:42:40 GMT



fd

?xml version='1.0' encoding='UTF-8'?
   soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
  soapenv:Body
 soapenv:Fault
faultcode/faultcode
faultstring/faultstring
detail /
 /soapenv:Fault
  /soapenv:Body
   /soapenv:Envelope
0




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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2-3887) The servlet transport does not set the HTTP response code to 500 when a SOAP fault is returned (unless an exception was thrown)

2008-07-03 Thread Asankha C. Perera (JIRA)


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

Asankha C. Perera resolved AXIS2-3887.
--

   Resolution: Fixed
Fix Version/s: nightly

fixed

 The servlet transport does not set the HTTP response code to 500 when a SOAP 
 fault is returned (unless an exception was thrown)
 ---

 Key: AXIS2-3887
 URL: https://issues.apache.org/jira/browse/AXIS2-3887
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: transports
Affects Versions: 1.4
Reporter: Asankha C. Perera
Assignee: Asankha C. Perera
 Fix For: nightly


 Steps:
 Edit axis2-1.4/samples/userguide/src/userguide/example1/MyService.java and 
 make it look like shown below:
 package userguide.example1;
 import org.apache.axiom.om.OMElement;
 import org.apache.axis2.AxisFault;
 import javax.xml.stream.XMLStreamException;
 public class MyService {
 public OMElement echo(OMElement element) throws XMLStreamException {
 return 
 org.apache.axiom.om.OMAbstractFactory.getSOAP11Factory().getDefaultFaultEnvelope().getBody().getFirstElement();
 }
 public void ping(OMElement element) throws XMLStreamException {
 //Do some processing
 }
 public void pingF(OMElement element) throws AxisFault{
 throw new AxisFault(Fault being thrown);
 }
 }
 Invoking the echo service now returns:
 HTTP/1.1 200 OK
 Server: Apache-Coyote/1.1
 Content-Type: text/xml;charset=UTF-8
 Transfer-Encoding: chunked
 Date: Thu, 03 Jul 2008 08:42:40 GMT
 fd
 ?xml version='1.0' encoding='UTF-8'?
soapenv:Envelope 
 xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
   soapenv:Body
  soapenv:Fault
 faultcode/faultcode
 faultstring/faultstring
 detail /
  /soapenv:Fault
   /soapenv:Body
/soapenv:Envelope
 0

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extensions to Axis2/Java deployment engine

2008-06-15 Thread Asankha C. Perera


Saminda

In general I feel most of the points you suggest would not be really 
used by actual end users most of the time (if not all the time) - 
especially those who use Axis2 in production. Shall we take this 
discussion to the user list as well and see if these use cases you 
describe would be really useful to the end users? If they agree with a 
majority vote, we can then go ahead with the OSGi changes. As for the 
points you mentioned about Synapse, I guess you see that it really 
doesn't add much value as things are right now..


asankha

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extensions to Axis2/Java deployment engine

2008-06-15 Thread Asankha C. Perera


Dims
Would you object even if changes are incremental and don't affect 
existing use cases / scenarios? Specifically, in a

non-osgi environment existing functionality is kept as-is?
No I will not object.. as long as the core code is not dependent on OSGi 
libraries/API's etc as well (i.e. Synapse should be able to ship without 
a bunch of OSGi dependency libraries or dependencies), and backwards 
compatibility with what we have as Axis2 1.4 is maintained at the code 
level.


Hopefully this will also mean than an OSGi dummy like me can continue to 
update, maintain and debug the code without worrying about OSGi


thanks
asankha

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extensions to Axis2/Java deployment engine

2008-06-14 Thread Asankha C. Perera


Saminda

Thanks for the detailed reply.. Please see my comments below, I will 
only take the top 5 points for each list I asked for to keep this 
discussion short, as I believe these are in the order of importance/use
1. When aar/mar behavior is mimicked in an OSGi bundle, these bundles 
be able to live in different class spaces.
   ex: If the bundles needed different hibernate versions they can be 
easily plug into different class spaces.

I see this as a good use for the end users!


2. We will be able to have multiple version of Axis2 instancres 
running inside same JVM.

   This require the need of minimizing System properties.
But you really will need to change ports/queues etc to really run two 
axis2 versions. (i.e. there is no way two instances can share the same 
http/s port, or the JMS queue or check for email on the same account 
etc..). So the probability of this use and the value would be less. So 
this is not a good candidate for position # 2.

3. Axis2 will be able to initiate same transport with different versions.
   This will require proper integration of OSGi services. I haven't 
touched this area yet, otherwise whole situation will be overwhelming.
See comment above.. again this is not something and end user will see 
much value in.. its like being able to deploy the same transport twice - 
at the same time. Also transports would be tied to axis2 versions, and 
if you have a newer version, its probably much better than a previous 
one anyway.. so again I don't see this as a good candidate for position # 3
4.  OSGi life-cycle support. This will give the ability to 
start/stop/install/update/uninstall bundles.
ex: I have myModule.jar which would mimic myModule.mar. We will be 
able use the above actions to to manipulate the AxisModule as we need.
What most end users would do is write services.. and I believe they 
already can do some amount of life cycle management.. can you tell me 
what new improvements this will give?
5.  Once a user has written a bundle (which mimic 
aar/mar/transport/etc), they just need to upload them into a Axis2 
bundle repository, where the community can search them and install 
them into there system, without shutting down the running system.
Typically a user written aar file is not really shared AFAIK.. but 
this is possible even as they are already.. as for the mar's - the most 
famous ones are rampart, sandesha/mercury etc.. which are released.



=
In Synapse point of view.

1. Mediators can be written as OSGi bundles. When you start the 
bundle, the proper factory is called and build the relevant object model.
This is irrelevant, you will not just add a mediator at runtime.. but 
you can configure or update your sequence etc at runtime, and you can do 
it now itself (e.g. WSO2 ESB)
2. Different version of same mediator is highly possible. i.e two 
mediator can live in two different class spaces.
Again, this is highly unlikely, since a newer version is better improved 
or fixes a bug of an older version, also you will not be able to 
configure two mediators as they register a unique QName in the 
configuration.
3. You will be able to remove Sun service providers facility of 
loading extension to bundles, which will be support in all Java 
implementations.
This maybe good, but does not itself show much advantage, as we can do 
the Sun service provider with a bit of custom code in any JDK anyway..

4. Synapse guys like embedded devices ?
Not me.. but Synapse is being embedded.. but I don't see how this has 
relevance


thanks
asankha

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extensions to Axis2/Java deployment engine

2008-06-13 Thread Asankha C. Perera


Saminda

Main  aspect of  OSGi  is version and modularity
Can you list the top 5 advantages for Axis2 end users (who develop 
services, or develop clients that consume services), and the top 5 
advantages for those who embed Axis2 (such as Apache Synapse etc). I 
think this would be very valuable information for me to consider your 
suggestion, and assess the impact on Apache Synapse

I am really appreciate if Axis2 folks comment on prior.

Looking forward to your reply to comment further

asankha

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Sample i/p message for Axis2 JMS

2008-06-09 Thread Asankha C. Perera

Hi 


Can some one provide me the sample i/p message or Client program to 
put message in to Message Queue. I have almost tried all combinations.


Have you looked at 
http://svn.apache.org/viewvc/synapse/trunk/java/modules/samples/src/main/java/samples/userguide/GenericJMSClient.java?view=markup


Basically, the JMS transport is able to read any text/binary JMS message 
(with a SOAP/XML, plain text or binary payload) as a request message or 
response.


While working on Axis2 services with JMS I am getting “Exception in 
thread JMSWorker-1 java.lang.NullPointerException . I don’t see any 
suggestions for this, so started debugging Axis2 engine. I realized 
the issue is with expected input message. When I added 
outMessage_.setJMSReplyTo(outQueue)_in client program;  then this 
issue is fixed,  do have exception else where at  
msgContext.setEnvelope(JMSUtils./getSOAPEnvelope/(message, msgContext, 
in)); -- NullPointerException. 


I have 2 issues here.

  1. Adding  parameter name=transport.jms.ReplyDestination 
locked=trueTestme/parameter in services.xml / axis2.xml is not 
considered in JMSMessageReceiver.java (  *if* (replyTo == *null*) 
{Parameter param = 
msgContext.getAxisService().getParameter(JMSConstants./REPLY_PARAM/);) 
why is it expecting client message to have 
“outMessage_.setJMSReplyTo(outQueue);__” _ Any suggestions on this please.


The JMS transport in the Axis2 project is deprecated, and scheduled for 
removal. All new development/bug fixes only takes place on the version 
currently hosted here 
(http://svn.apache.org/viewvc/synapse/trunk/java/modules/transports/src/main/java/org/apache/synapse/transport/jms/)


  2. Can you provide me sample Client program to put message with 
all JMS constants required for JMSMessageReceiver. I have almost spent 
more than 2 weeks to fix these issues.


If you would like to get development support for this with Axis2, let me 
know personally


asankha

Re: Issue talking to Axis2/C on IIS

2008-06-08 Thread Asankha C. Perera


Supun
To get the POST request working we need to register a mime type with 
the IIS server i.e asp, php etc. But we don't have a mime type in our 
service URLs and requests to our services comes without an extension 
part. Because of this IIS rejects the requests at a very early stage. 
I thing the service URLs for .Net services has a extension part (.svc) 
and they are associated with their ISAPI application.
What you say wrt to .Net may be true.. but if the POST comes as a 
relative path (e.g. /services/myservice) even *without* the extension, 
then Axis2/C works - which contradicts your observation.


asankha


On Wed, Jun 4, 2008 at 10:09 PM, Asankha C. Perera [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


Supun

I think this is a known issue in IIS 5. Please refer the links
below

http://support.microsoft.com/kb/216493
http://www.somacon.com/p126.php


Sorry but I don't understand the logical relevance of the above
with the issue I report.. if .net services understands http 1.1,
why doesn't axis2/c on IIS ?


asankha

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]

Re: Issue talking to Axis2/C on IIS

2008-06-04 Thread Asankha C. Perera


Supun

I think this is a known issue in IIS 5. Please refer the links below

http://support.microsoft.com/kb/216493
http://www.somacon.com/p126.php


Sorry but I don't understand the logical relevance of the above with the 
issue I report.. if .net services understands http 1.1, why doesn't 
axis2/c on IIS ?


asankha

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Issue talking to Axis2/C on IIS


Hi All

When I talk to Axis2/C hosted on IIS, it returns a method not allowed 
exception as shown below.. however, if the POST only uses the path 
segment, the call succeeds.. Is this a bug with IIS or Axis2/C ?


If the message fails due to a Content-Length error etc, Axis2/C returns 
a smiley Unknown Error :( in the SOAP fault.. which I think is not 
appropriate.


asankha

_Smiley in the error message_

soapenv:Envelope 
xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope;soapenv:Header 
xmlns:wsa=http://www.w3.org/2005/08/addressing;wsa:Actionhttp://ws.apache.org/axis2/c/samples/echoString/wsa:Actionwsa:MessageID24998111-fa1e-4a8f-944a-d5e504400bd1/wsa:MessageIDwsa:RelatesTo 
wsa:RelationshipType=http://www.w3.org/2005/08/addressing/reply; 
xmlns:wsa=http://www.w3.org/2005/08/addressing;192274ef-5497-49c0-aa93-23d967e12e1e/wsa:RelatesTo/soapenv:Headersoapenv:Bodysoapenv:Faultsoapenv:Codesoapenv:Valuesoapenv:Sender/soapenv:Value/soapenv:Codesoapenv:Reasonsoapenv:Text 
xml:lang=en*Unknown Error 
:(*/soapenv:Text/soapenv:Reasonsoapenv:DetailEchoServiceErrorEcho 
service failed 
/EchoServiceError/soapenv:Detail/soapenv:Fault/soapenv:Body/soapenv:Envelope


_Successful request_

[EMAIL PROTECTED]:~/perf$ telnet 10.100.1.228 8081
Trying 10.100.1.228...
Connected to 10.100.1.228.
Escape character is '^]'.
POST /axis2/services/echo HTTP/1.1
Host: 127.0.0.1:8081
Content-Length: 590
Content-Type: application/soap+xml; charset=UTF-8
User-Agent: Axis2/C

HTTP/1.1 100 Continue
Server: Microsoft-IIS/5.1
Date: Tue, 03 Jun 2008 08:32:27 GMT

soapenv:Envelope xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope;
  soapenv:Header xmlns:wsa=http://www.w3.org/2005/08/addressing;
 wsa:Tohttp://localhost:8081/axis2/services/echo/wsa:To
 
wsa:Actionhttp://ws.apache.org/axis2/c/samples/echoString/wsa:Action

 wsa:MessageID192274ef-5497-49c0-aa93-23d967e12e1e/wsa:MessageID
  /soapenv:Header
  soapenv:Body
 ns1:echoString xmlns:ns1=http://ws.apache.org/axis2/services/echo;
textHello World!/text
 /ns1:echoString
  /soapenv:Body/soapenv:Envelope



HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Tue, 03 Jun 2008 08:32:35 GMT
Content-Type: application/soap+xml;charser:UTF-8
Content-Length: 721

soapenv:Envelope 

_Failure Request_

[EMAIL PROTECTED]:~/perf$ telnet 10.100.1.228 8081
Trying 10.100.1.228...
Connected to 10.100.1.228.
Escape character is '^]'.
POST *http://10.100.1.228:8081*/axis2/services/echo HTTP/1.1
Host: 10.100.1.228:8081
Content-Length: 590
Content-Type: application/soap+xml;charset=UTF-8

HTTP/1.1 100 Continue
Server: Microsoft-IIS/5.1
Date: Tue, 03 Jun 2008 08:33:02 GMT

soapenv:Envelope xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope;
  soapenv:Header xmlns:wsa=http://www.w3.org/2005/08/addressing;
 wsa:Tohttp://localhost:8081/axis2/services/echo/wsa:To
 
wsa:Actionhttp://ws.apache.org/axis2/c/samples/echoString/wsa:Action

 wsa:MessageID192274ef-5497-49c0-aa93-23d967e12e1e/wsa:MessageID
  /soapenv:Header
  soapenv:Body
 ns1:echoString xmlns:ns1=http://ws.apache.org/axis2/services/echo;
textHello World!/text
 /ns1:echoString
  /soapenv:Body/soapenv:Envelope



HTTP/1.1 405 Method not allowed
Server: Microsoft-IIS/5.1
Date: Tue, 03 Jun 2008 08:33:08 GMT
Connection: close
Allow: OPTIONS, TRACE, GET, HEAD
Content-Length: 3923
Content-Type: text/html

!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2 Final//EN

Re: Issue talking to Axis2/C on IIS


Supun / Samisa
We have send a request using the full URL with  the POST method. But 
it seems that IIS discards the request before it give the control to 
the IIS module. So it seems like it is a bug in the IIS itself.


Apparently. the full URL works for GET but not for POST with IIS.
AFAIK, the full URL in the POST and the HTTP 1.1 Host header are used 
when messages travel via proxies.. and also according to some tests done 
with .Net, IIS does seem to work with the full URL (however I didn't see 
this myself, but Ruwan will be able to share this info).. maybe you can 
check against .Net and see if there is a difference..


asankha

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Issue talking to Axis2/C on IIS


Samisa
We have send a request using the full URL with  the POST method. 
But it seems that IIS discards the request before it give the 
control to the IIS module. So it seems like it is a bug in the IIS 
itself.


Apparently. the full URL works for GET but not for POST with IIS.
AFAIK, the full URL in the POST and the HTTP 1.1 Host header are 
used when messages travel via proxies.. and also according to some 
tests done with .Net, IIS does seem to work with the full URL 
(however I didn't see this myself, but Ruwan will be able to share 
this info).. maybe you can check against .Net and see if there is a 
difference..


What is the client you guys are using to send the full URL in the 
request? We used tcpmon to resend the message wit had modified URL. We 
also used telnet to test this. But a hint on the client you are using 
would be helpful to debug.
We used Apache Synapse.. you can also telnet manually as shown on my 
initial mail.. if you manually telnet, make sure about the 
Content-Length header correctless


asankha

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Issue talking to Axis2/C on IIS



Telnetting is a pain when debugging. If we proxy Axis2/C echo sample 
with Synapse, I hope we should be able to recreate this. Correct?
Yes, this should be fine.. let me know if you need any help setting up 
Synapse..


asankha

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2 1.3] SimpleMailListener denys SOAP11 content-ype

2008-05-29 Thread Asankha C. Perera


Christopher

You can try the Mail transport implementation we have developed for 
Apache Synapse. This can be made to replace the Axis2 Mail transport, 
but dropping the JAR file [1] into your lib directory, and updating your 
axis2.xml as follows:


[1] 
http://repo1.maven.org/maven2/org/apache/synapse/synapse-transports/1.1.2/synapse-transports-1.1.2.jar


   transportReceiver name=mailto 
class=org.apache.synapse.transport.mail.MailTransportListener

   !-- configure any optional POP3/IMAP properties
   check com.sun.mail.pop3 and com.sun.mail.imap package 
documentation for more details--

   /transportReceiver
   
   !-- Uncomment and configure the SMTP server information
   check com.sun.mail.smtp package documentation for descriptions of 
properties
   transportSender name=mailto 
class=org.apache.synapse.transport.mail.MailTransportSender

   parameter name=mail.smtp.hostsmtp.gmail.com/parameter
   parameter name=mail.smtp.port587/parameter
   parameter name=mail.smtp.starttls.enabletrue/parameter
   parameter name=mail.smtp.authtrue/parameter
   parameter name=mail.smtp.usersynapse.demo.0/parameter
   parameter name=mail.smtp.passwordmailpassword/parameter
   parameter 
name=mail.smtp.from[EMAIL PROTECTED]/parameter

   /transportSender--

Now for each of your services, you can configure the mail properties on 
the services.xml using the following properties:


e.g.

parameter name=transport.mail.Address[EMAIL PROTECTED]/parameter
   parameter name=transport.mail.Protocolpop3/parameter
   parameter name=transport.PollInterval5/parameter
   parameter name=mail.pop3.hostpop.gmail.com/parameter
   parameter name=mail.pop3.port995/parameter
   parameter name=mail.pop3.usersynapse.demo.1/parameter
   parameter name=mail.pop3.passwordmailpassword/parameter
   parameter 
name=mail.pop3.socketFactory.classjavax.net.ssl.SSLSocketFactory/parameter
   parameter name=mail.pop3.socketFactory.fallbackfalse/parameter
   parameter name=mail.pop3.socketFactory.port995/parameter

With the new mail transport, you can have multiple services listening on 
different email accounts with their own separate polling schedules etc.. 
and message can be within the body, an attachment etc, and the subject 
can be changed, or copies CC, BCC'ed etc.. This documentation is still 
not in a good format, but you can refer to the code 
http://svn.apache.org/viewvc/synapse/trunk/java/modules/transports/src/main/java/org/apache/synapse/transport/mail/ 
and the Synapse samples http://synapse.apache.org for a better 
understanding.


asankha



[EMAIL PROTECTED] wrote:

Hi Team,
I have to send my SOAP-messages with SOAP11. But the server does not accept 
mails with the content-type text/xml:

[ERROR] According to the mail sepec, mail transport should support only 
application/soap+xml
[ERROR] Error in SimpleMailListener - processing mail
org.apache.axis2.AxisFault: According to the mail sepec, mail transport should 
support only application/soap+xml
at 
org.apache.axis2.transport.mail.SimpleMailListener.buildSOAPEnvelope(SimpleMailListener.java:470)
...



Unfortunately this check is hardcoded into the SimpleMailListener:



if (contentType.indexOf(SOAP12Constants.SOAP_12_CONTENT_TYPE)  -1) {
TransportUtils
.processContentTypeForAction(contentType, 
msgContext);
} else {...

Is there any way around or did I simply miss some property to be set?

Thanks for helping,
Christopher

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using Webservice via SMTP: SOAP message in body

2008-05-06 Thread Asankha C. Perera

Andreas Veithen wrote:

Christopher,

I think the mail transport implementation in Apache Synapse has
support for this. You can use this transport as a replacement for the
mail transport distributed with Axis2.

Yes, you just need to drop the JAR file found here
http://repo1.maven.org/maven2/org/apache/synapse/synapse-transports/1.1.2/synapse-transports-1.1.2.jar
into your classpath, and then configure the mail transport in your
axis2.xml as per this link
http://svn.apache.org/viewvc/synapse/trunk/java/repository/conf/axis2.xml?view=markup

Now, for a particular service, you can refer to the parameters defined
in this Synapse sample
http://synapse.apache.org/Synapse_Samples.html#Sample256 and define
them on your services.xml. This transport allows you to use pop3, imap,
smtp, and also configure an email address and a polling
duration/schedule per service. It also support customization of the
subject etc, and allows you to use the body or attachment to carry the
SOAP payload

asankha

*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
*Sent:* mardi 6 mai 2008 14:14
*To:* axis-dev@ws.apache.org
*Subject:* Using Webservice via SMTP: SOAP message in body

Hi,
I am looking for a easy way to send the SOAP-Message via SMTP NOT as
an email attachment, but in the mail-body itself.
In my case the communication between client and server is routed
through a firewall which does not allow any attachments.

In all Axis2-Examples the SMTP communication was realized by attaching
the SOAP-Request to an email and I found no further information on
this issue on the web.

If possible I would like to avoid any changes in the source-code.
Maybe it is just a simple configuration I just missed.

Thanks in advance,
Christopher

---

Christopher Rölle mailto:[EMAIL PROTECTED]
sdm AG http://www.sdm.de
software design management
Carl-Wery-Str. 42, 81739 Muenchen, Germany
Tel +49 89 63812-286 Fax -272

Vorstand: Edmund Kuepper (Vorsitzender), Burkhard Kehrbusch,
Ruediger Azone, Dr. Uwe Dumslaff, Kai Grambow, Dr. Michael Rading
Aufsichtsrat: Pierre Hessler (Vorsitzender)
Sitz und Amtsgericht: Muenchen HRB 126057

Re: [Axis2][Proposal] Move JMS / Async NIO transports out of Axis2 into Synapse

2008-04-24 Thread Asankha C. Perera


Deepal
As we discussed in the mailing list I created a prototype deployer 
(TransportDeployer) for transport deployment..

This is cool and boy you are fast :-) !..

Axis2 transports also needs a few more changes though.. and I'm 
re-thinking about the suggestion made by Sanjiva on moving the core 
API's out of Axis2 as well.. for example, TransportSender needs a 
start() method, just like the Listeners, as there can be Senders that 
requires initialization, and explicit start/stop behavior.. Else, at 
ConfigurationContext creation itself, the Senders start through the 
init() call which is not what you want.. also if you stop a transport, 
you cannot restart.. Another example is with the AxisServlet listener 
which must handle its stop()  call etc, and refuse to handle any 
messages through Axis2 if the transport was shutdown.. else if a service 
does not implement the ServiceLifeCycle interface, it may still be 
accessible over the servlet transport even if the lister manager was 
shutdown etc..


So I think its better to *first* work on moving out the current 
transports from Axis2 as proposed, so that we can focus and review the 
transports and the design again, and make any improvements for issues we 
see. I do not think this is something we could try to do in a hurry.. we 
should also focus on good API documentation that will help anyone write 
a new transport easily etc


asankha


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2][Proposal] Move JMS / Async NIO transports out of Axis2 into Synapse

2008-04-23 Thread Asankha C. Perera


Sanjiva

Sanjiva Weerawarana wrote:
- First of all, Asankha, why synapse-transports.jar?? That makes no 
sense to me- so if you have a bug in the VFS code you'll rev all the 
stuff? Why? There should be one jar per transport. Yes, lots of jar 
files but so what?


- Asankha, you seem to think that the only place transports that 
Synapse finds interesting are being done is in Synapse. What about 
CORBA? The code is in Axis2 (and Eranga is still waiting for his 
commit rights to come thru to finish that off) and of course 
supporting CORBA is very interesting for Synapse. So you're not 
solving whatever problem you perceive by saying keep everything I 
care about in Synapse.


- I agree with that Axis2 transports should NOT be in the kernel jar. 
Can we finally agree (forget the history please) to that now and 
create new maven modules for each transport and put each one into its 
own jar? This is for the transports that are (or will remain) in 
ws/axis2.


- Given that these transports are usable by anyone building on Axis2 
(and not just Synapse) and that they depend on Axis2 APIs, I believe 
they should be in a project which releases those transports against 
given versions of Axis2 APIs. My preference is that it should be in 
ws/commons/transports or a new sub-project called ws/transports. 
Asankha, what problem do you see in that approach? I think everyone 
would +1 you being the RM for this project ;-).

+1 to all above

- How about the following compromise position:
  - we create a new ws/transports project and move http and any other 
transports out of axis2 into that.

  - we kill the old NHTTP and JMS tranports in axis2
+1, lets get someone from Axis2 to do this as the first step. I will not 
be able to work on this at least into the next few weeks..

  - move JMS and SMTP out of synapse into the new project
  - as a general rule, if Axis2 and Synapse are both going to ship the 
transport in their default distros, then we move the code here
  - for other transports we strongly encourage people to put them here 
to enable easier wider use
  - this project publishes each transport as a separate jar with a 
naming convention that identifies the axis2 (API) version it 
corresponds to. of course trunk will correspond to trunk as always
+1, Will move out the non Synapse specific transports into the new 
module once the above project is created, and Axis2 moves out its http/s..
  - I'm ok with going one step further and even moving the Axis2 
transport APIs into the project and for Axis2 to just use them. This 
is like what Axis2 does with Axiom for example.
I maybe wrong.. but I don't see this as required or gives us additional 
benefits..


asankha

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2][Proposal] Move JMS / Async NIO transports out of Axis2 into Synapse


Dims

- there should not be stale copies
- people who work on them should work where they want to.

+1 to both!
Right now it's Asankha and co. So we should just make Status Quo 
permanent. It can be under Axis2 as a maven module or
under WS-Commons or maven module under synapse. I really don't care, 
as long as people who maintain it make the decision

and do it in one spot.
I'd like to maintain these under Synapse.. We wrote these transports 
primarily for use by Synapse, and now we have JMS, NIO-HTTP/S, Mail, VFS 
(File), FIX and AMQP already.. These belong to a separate Maven module 
thats published to the Apache snapshots and Maven Central repos, and 
this JAR does not depend on the Synapse codebase at all. Anyone who 
wishes to use these can do so without any problems whatsoever, and raise 
JIRA's for bugs/enhancements where the code is actually maintained.


Glen

| | -1 from me to move them to Synapse.
The transports JMS, NIO-HTTP/S and others are already [developed and 
maintained] within Synapse..
| | These transports (JMS, NIO, whatever) are going to be generally 
useful to any Axis2 user, so why make them go look in Synapse's 
codebase for them?
I agree,.. however these transports were written by the Synapse 
community for primary use by them. So instead of asking them to maintain 
the code they write somewhere else - for the convenience of the 
secondary users, why not clearly document the available options under 
Axis2 and where one could download these extension transports developed 
by the Synapse community?


asankha

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2][Proposal] Move JMS / Async NIO transports out of Axis2 into Synapse


David

Asankha, is there something about doing this work in Axis2 that is
difficult for you and easily changed e.g. having a separate release
schedule for the 'extra transports', 
One of the main issues here to consider is how easily we can fix issues, 
create patches and release versions of the transports when Synapse wants 
them.. remember that we are the primary users of these transports with 
customers using these in production..


First of all, having the code only in axis2 trunk would mean that 
sometimes we may not be even able to compile it when required ;-) , or 
having to download many many more JARs each time we want to build.. and 
also somehow get through the common build breaks! We will also exposed 
to all changes taking place on the axis2 trunk, and forced to comply to 
keep compatibility at trunk with Axis2. Usually [if not always] Synapse 
depends on the last Axis2 released version. For example, we were using 
Axis2 1.3 for many months, until we were ready to move to Axis2 1.4 
now... and we wanted our transports to remain on Axis2 1.3 until then.


Synapse is very much dependent on transports, esp when it comes to 
legacy transports other than http/s. Most of the time we need to make 
changes to transports to fix bugs and/or perform enhancements. I also 
believe that the NIO http/s transports is one of the most valuable and 
complicated pieces of code on which Synapse relies heavily.. I don't 
understand the argument that you want to make it easier for a casual 
user of Axis2 to use these transports, putting the Synapse team that 
develops these and uses these much more, into the difficult position?


If anyone wants to use any of the Synapse transports, they:
(1) Do not need to download Synapse
(2) Learn about or know Synapse
(3) Be dependent on the Synapse core JARs

All they need to do is put an entry into the pom.xml of their project to 
point to the synapse-transports.jar! Technically this is no different 
than a separate module in Axis2, or WS commons.. Of course they will 
need to understand how each transport operates (e.g. FIX, VFS etc..) 
before trying to use them.. but this is not solved by where the code 
lies, but in providing documentation

or is it more cultural that you're doing all your work in Synapse now?
  

Not at all! ..

asankha

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2][Proposal] Move JMS / Async NIO transports out of Axis2 into Synapse

Check this thread 
http://mail-archives.apache.org/mod_mbox/synapse-dev/200710.mbox/[EMAIL PROTECTED] 
as well titled Getting axis2 transport out from the kernel


asankha

Davanum Srinivas wrote:

Ruwan,

All i see is some discussion, which happens on a topic

http://marc.info/?t=11968468036r=1w=3

- Where is the push back? From who?
- Where is the VOTE?
- Where is a -1?

thanks,
dims

Re: [Axis2][Proposal] Move JMS / Async NIO transports out of Axis2 into Synapse