-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Deepal Jayasinghe wrote:
Is there a need for axis2-optional.jar?
Well , I am bit worried about having a jar like this.
Can you please explain why?
I'm +1 for axis2-server.jar axis2-client.jar.
may be or may be not. Axis2 kernel and java2wsdl is
-
From: Lawrence Mandel [mailto:[EMAIL PROTECTED]
Sent: Friday, October 12, 2007 1:07 AM
To: axis-dev@ws.apache.org
Subject: Re: Getting axis2 transport out from the kernel
+1
I actually posted a question about all of the jars included in the Axis2
distribution on the users list
on the
page so users can easily pick what it is they want to download.
Lawrence
keith chapman [EMAIL PROTECTED]
10/14/2007 02:54 AM
Please respond to
axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
cc
Subject
Re: Getting axis2 transport out from the kernel
Is there a need
Is there a need for axis2-optional.jar?
Well , I am bit worried about having a jar like this.
I'm +1 for axis2-server.jar axis2-client.jar.
may be or may be not. Axis2 kernel and java2wsdl is the core jars that
need for bot the client side and the servers side , in addition to the
:07 AM
To: axis-dev@ws.apache.org
Subject: Re: Getting axis2 transport out from the kernel
+1
I actually posted a question about all of the jars included in the Axis2
distribution on the users list today. (See
http://marc.info/?l=axis-userm=119214746432551w=2) I counted 19 Axis2
jars and 39
-
From: Lawrence Mandel [mailto:[EMAIL PROTECTED]
Sent: Friday, October 12, 2007 1:07 AM
To: axis-dev@ws.apache.org
Subject: Re: Getting axis2 transport out from the kernel
+1
I actually posted a question about all of the jars included in the Axis2
distribution on the users list today. (See
Big big +1 ...
I strongly feel we need to reduce the number of Jars and actually
tried to voice it few times before.
To me, axis2-core.jar and axis2-optional.jar is enough for axis2 jars.
Of course we can keep the modules as it is and build two jars while
creating the distribution. We can even
of jars for users (like me) to make sense of.
Lawrence
Srinath Perera [EMAIL PROTECTED]
10/11/2007 09:39 AM
Please respond to
axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
cc
Subject
Re: Getting axis2 transport out from the kernel
Big big +1 ...
I strongly feel we need to reduce
Jordahl
From: Rajith Attapattu [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 09, 2007 1:07 PM
To: axis-dev@ws.apache.org
Subject: Re: Getting axis2 transport out from the kernel
Tom has a point. TCP and SMTP seems to be used very rarely. Perhapse 1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Jordahl wrote:
Well the best thing, IMO, is to ship the current http transport
with the release, by default and let users download others if
they want to use.
+1 - The best thing for Axis2 is for the Axis users, not for Synapse.
The fewer
What I'd like to see is axis2-server.jar and
axis2-client.jar. Then we just have to add other third party jars like
commons-etc., and we are good to go.
A big +1 on this.
This would really simplify the situation for end users.
If anything else is required they can download, but most users
After understanding the impact and the flexibility, now I am also +1 for the
change.
Rajith Attapattu
Red Hat Canada.
On 10/8/07, Deepal jayasinghe [EMAIL PROTECTED] wrote:
+1 for the moving transport to a new module.
Just out of curiosity, if you take out the http transport out of the
: [EMAIL PROTECTED]
Subject: Re: Getting axis2 transport out from the kernel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, I have couple of questions just to understand what the plan is.
Let's assume we separate out transports in to a module.
(begin
What will this module contain? Will it have
to use for users.
--
Tom Jordahl
-Original Message-
From: Eran Chinthaka [mailto:[EMAIL PROTECTED]
Sent: Monday, October 08, 2007 11:02 PM
To: axis-dev@ws.apache.org
Cc: [EMAIL PROTECTED]
Subject: Re: Getting axis2 transport out from the kernel
-BEGIN PGP SIGNED MESSAGE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, I have couple of questions just to understand what the plan is.
Let's assume we separate out transports in to a module.
(begin
What will this module contain? Will it have all the transports,
including http, smtp, tcp, etc., or will there be
What will be shipped with Axis2 release? All of them or none?
If it is none,
do you expect people to download Axis2 release AND another transport
that he/she wants to use?
else will we release the transport we have now?
if yes, then Synapse will again have the same problem.
Comments in-line
On 10/9/07, Ajith Ranabahu [EMAIL PROTECTED] wrote:
What will be shipped with Axis2 release? All of them or none?
If it is none,
do you expect people to download Axis2 release AND another
transport
that he/she wants to use?
else will we release the transport
+1 for the moving transport to a new module.
Just out of curiosity, if you take out the http transport out of the
kernel, won't that change the packages of it which will affect the
transport listing in axis2.xml which in turn will be visible to users.
Well we can move to a new module , without
manage the next release of Synapse (i.e. 1.1) the way things are
using a few tricks like putting our copy of the transport in-front of
the Axis2-kernel etc. at runtime.
Why do you need trickery? The transports are coming out of axis2.xml
.. why can you not simply put another transport in
Hi Akanka;
IMHO, depending on class loading order could lead to bugs (e.g. User
might not know about it, and screw up), and should only use as the
least resort. May be you should go to first option. Just My two
cents.
Thanks
Srinath
On 10/6/07, Asankha C. Perera [EMAIL PROTECTED] wrote:
If we are gonna rename the classes, I prefer changing the package name from
axis2 to synapse rather than changing the class name (I mean the part
without the package name)
Thanks,
Ruwan
On 10/6/07, Srinath Perera [EMAIL PROTECTED] wrote:
Hi Akanka;
IMHO, depending on class loading order
IMO defining your own transport is the right way to do it,
+1.. Having been able to specify transport implementation from the
axis2.xml is the right way of making it pluggable and we need to
follow that... IMHO using the classpath, replacing the jar files and
making the classes with same name to
Note: For some strange reason, this mail returned twice with the error:
axis-dev@ws.apache.org:
140.211.11.136 failed after I sent the message.
Remote host said: 552 spam score (5.9) exceeded threshold
and thus I am sending this as a new message instead of a reply to the thread
Hi Asankha,
I really appreciate the work the synapse community has done on the
Axis2 transports. I also think it would be reasonable to split the
transports out of axis2-kernel.
I think where I'm worried is the idea that we could do a quick .1
release with that kind of change - that's simply not
Hi David
I also think it would be reasonable to split the
transports out of axis2-kernel.
Great :-)..
I think where I'm worried is the idea that we could do a quick .1
release with that kind of change - that's simply not realistic. It's
definately something that would require a fair amount
Guys.. the confusion/problem/root cause is this.. the Synapse community
re-wrote the JMS transport initially, and checked this into the Axis2
Kernel module as other transports were in there at the time. Actually
this replaced the previous JMS transport Axis2 had.
Then we wrote a new
+1 for moving it out of the kernel module. Transports are a plug point of
Axis2 and there's no need to consider any given transport as core to the
kernel.
Sanjiva.
Ruwan Linton wrote:
Hi axis-devs,
We are getting ready for the Synapse 1.1 release and we faced to a
problem with the
Asankha C. Perera wrote:
I totally agree.. and I am not pushing for that right away.. I can
+1 for this change not being a reason to do a new release.
manage the next release of Synapse (i.e. 1.1) the way things are using a
few tricks like putting our copy of the transport in-front of the
On 10/5/07, Sanjiva Weerawarana [EMAIL PROTECTED] wrote:
Asankha C. Perera wrote:
I totally agree.. and I am not pushing for that right away.. I can
+1 for this change not being a reason to do a new release.
manage the next release of Synapse (i.e. 1.1) the way things are using a
few
While I appreciate it's not what you're asking for, would an Axis2
release depending on -alpha6 provide what you need? If the API changes
are reasonably small, that might be a simpler way to go for Axis2 for
a point release.
David
On 04/10/2007, Ruwan Linton [EMAIL PROTECTED] wrote:
Hi
Sorry to drop in late on this one..
What would be ideal is just a separation of the Axis2 transports code
into a separate module within Axis2 - i.e. outside of the Kernel.
thanks
asankha
Ruwan Linton wrote:
Hi Chinthaka,
It does have API level problems and that is why we are running in to
Can't we do this?
Write a new http transport (Http transport edited for new Http core,
impl class name should be different), and change the axis2.xml to
provide new Http implementation as implementation for http transport,
and ship synapse with new axis2.xml (make changing the class name for
new
Ruwan, Asankha,
Actually I was also wondering about the same?
Isn't that possible ??
Regards,
Rajith
On 10/4/07, Srinath Perera [EMAIL PROTECTED] wrote:
Can't we do this?
Write a new http transport (Http transport edited for new Http core,
impl class name should be different), and change
Hhmmm...
I don't think it is impossible, but at the same time, IMO it is not the
right thing to do? (although that will solve the problem).
I think it is nice to abstract out the transports from the kernel, even for
axis2. That will modularize the things, so that one can write an axis2
transport
IMO defining your own transport is the right way to do it, when Axis2
is being designed, it is designed to be pluggable so we can do this
kind of things.
If we need to move tranports out of Axis2 kernel, I belive it is a
seperate discussion and I do not belive above use case is
justification for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Just out of curiosity, if you take out the http transport out of the
kernel, won't that change the packages of it which will affect the
transport listing in axis2.xml which in turn will be visible to users.
That means, we might have to do a major
Hi Chinthaka,
It does have API level problems and that is why we are running in to issues
in the cases where the transport impl is picked from the axis2-kernel's
classes. For example;
The method org.apache.http.RequestLine.getHttpVersion() in http-core-alpha5
has been changed to
Hi axis-devs,
We are getting ready for the Synapse 1.1 release and we faced to a problem
with the transports. Synapse is going to ship with the http-core transport
version 4.0-alpha6 and we have changed synapse transport module with the
improvements for that version (4.0-alpha6-SNAPSHOT) which is
38 matches
Mail list logo
