Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 66960 invoked from network); 9 Oct 2007 17:09:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Oct 2007 17:09:43 -0000 Received: (qmail 85079 invoked by uid 500); 9 Oct 2007 17:07:58 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 85032 invoked by uid 500); 9 Oct 2007 17:07:58 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 85018 invoked by uid 99); 9 Oct 2007 17:07:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Oct 2007 10:07:57 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rajith77@gmail.com designates 64.233.182.188 as permitted sender) Received: from [64.233.182.188] (HELO nf-out-0910.google.com) (64.233.182.188) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Oct 2007 17:07:59 +0000 Received: by nf-out-0910.google.com with SMTP id e27so1280989nfd for ; Tue, 09 Oct 2007 10:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=Or0EFfvH5RXY8tWwaRvWBPKNJQ8NULQiO20psqgeYPM=; b=NidZgfOZ0Ikopqu3AQJRfsS6JoHQ0keBSG8+dZkYMD0O3hq3zzvJT/nDtILfrjKrpiYTK7QcIOZnlDg2a7rP9hf0QiajBNlVjKohCN9Q/vz3ysIy7oipHB6L90zJzGcarM29B5sg5UggXTs201RORA9HssYF9BMAWZLb+d1gRGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=IzF2UbZLQ3rKOckoajWovWyHPKJbbXiWdo7xRU9epqLcKTxIBOqALw3Ts+C3NalSgfh0Gdug7sI8ym6p0WHAWmOZgyHNsKNQpdME6owBtZ8uiqmNjyPedWvZ1pqK3P6hdtUofNT+mxI9tzTw35SYgIb/f9c8WuVtiMWWPl2euIM= Received: by 10.78.140.17 with SMTP id n17mr645339hud.1191949638738; Tue, 09 Oct 2007 10:07:18 -0700 (PDT) Received: by 10.78.172.15 with HTTP; Tue, 9 Oct 2007 10:07:18 -0700 (PDT) Message-ID: Date: Tue, 9 Oct 2007 13:07:18 -0400 From: "Rajith Attapattu" To: axis-dev@ws.apache.org Subject: Re: Getting axis2 transport out from the kernel In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8346_2214055.1191949638733" References: <4705E8DC.3020506@wso2.com> <470AEF19.8060405@opensource.lk> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_8346_2214055.1191949638733 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Tom has a point. TCP and SMTP seems to be used very rarely. Perhapse < 1%. JMS seems to be more popular. But I still think we should to put transports in a separate module. When we make the axis2 standard distribution can we not just simply make two jars out of the transport module? One jar containing the http transport (which can be included in the axis2 standard bin) And another jar containing the rest of the transports. Is this possible with maven? This way we can allow people to download the additional transports only if they want to. Synapse folks are happy bcos they can easily import only the axis2 kernal and bundle their own HTTP transport. Does this sound reasonable? Regards, Rajith Attapattu Red Hat. On 10/9/07, 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 jar files the better as well. The core of Axis2 should have > the 'standard' HTTP transport - anything else is just noise to 90+% of > users. > > Keep your eyes on the target: making Axis2 easy to use for users. > > -- > Tom Jordahl > > > -----Original Message----- > From: Eran Chinthaka [mailto:chinthaka@opensource.lk] > Sent: Monday, October 08, 2007 11:02 PM > To: axis-dev@ws.apache.org > Cc: synapse-dev@ws.apache.org > 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 all the transports, > including http, smtp, tcp, etc., or will there be modules for each and > every transport? > > 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. > > What will be inside default axis2.xml? > > 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. > The intuition is that most of the time the transport will be http and > will make the life easier for about 90% of the users. > > Also I'd like to evaluate the impact of this on the HTTP binding > implementation that we have now. I think that also will go out of > Kernel. > > ) > Just my 2 cents. > > Thanks, > Chinthaka > > Srinath Perera wrote: > >> 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 non-blocking http/s transport, and kept this > within > >> Synapse. After some time there was a suggestion from Axis2 that we > >> should check this code into Axis2 instead to make it available to a > >> wider audience for usage, testing and improving overall quality as > well. > >> Thus we checked this into Axis2 [Kernel :-(] > > +1 yes that is right way to go > > > >> Now the problem is this.. The JMS transport was implemented for JMS > 1.1, > >> and the ESB community encountered users who wanted to deploy > production > >> apps using JMS 1.0.2. We also had a few bug fixes going into the NIO > >> transport - where we couldn't wait for "the next axis2" release. We > also > >> developed a Apache VFS based file/ftp/sftp/.. transport lately. We > would > >> like to give this code to all Axis2 users for sure, but not within > the > >> Axis2-kernel module - as it would create issues for us to make never > >> versions of these same classes for our use. > >> > >> As you may be already aware, Synapse is very close to transports - > i.e. > >> we want the maximum out of them, and would encounter most users who > >> would be looking for custom transports etc. We also do lots of load > >> testing for concurrency and NIO related issues.. and we want to stay > >> upto-date with the latest HttpCore release. Now since we committed > our > >> initial transport code into Axis2-kernel, we are in a fix on making > safe > >> updates as and when required for Synapse releases. > >> > >> All we ask for is for Axis2 to create a module for transports and > take > >> transports out from the kernel. > > > > > > OK you convinced me. I am +1 on creating module for transports. > > However as David pointed out we have to do it in Axis2 major release. > > > > One middle ground would be to create a transport module and first add > > additional transports while leaving what ever we have in kernel as it > > is for now. At a major release you can move other transports out as > > well. (May be you can leave http transport in the core for testing > > reasons, but that we can decide later). That way we can ship > > additional transports with minor release without adding them to > > axis2.xml, and synapse can add them via custom axis2.xml. > > > > Thanks > > Srinath > > > > > >> asankha > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org > >> For additional commands, e-mail: axis-dev-help@ws.apache.org > >> > >> > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHCu8ZjON2uBzUhh8RAmbkAJ9fom4XImV2+x+7iPmBrF+rzC+l/ACcCckk > Z3saNc4pBfUWn7OsV/pFzGo= > =wlxq > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org > For additional commands, e-mail: axis-dev-help@ws.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org > For additional commands, e-mail: axis-dev-help@ws.apache.org > > ------=_Part_8346_2214055.1191949638733 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Tom has a point. TCP and SMTP seems to be used very rarely. Perhapse < 1%.
JMS seems to be more popular.

But I still think we should to put transports in a separate module.
When we make the axis2 standard distribution can we not just simply make two jars out of the transport module?
One jar containing the http transport (which can be included in the axis2 standard bin)
And another jar containing the rest of the transports.
Is this possible with maven?

This way we can allow people to download the additional transports only if they want to.
Synapse folks are happy bcos they can easily import only the axis2 kernal and bundle their own HTTP transport.

Does this sound reasonable?

Regards,

Rajith Attapattu
Red Hat.

On 10/9/07, Tom Jordahl <tjordahl@adobe.com> 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 jar files the better as well.  The core of Axis2 should have
the 'standard' HTTP transport - anything else is just noise to 90+% of
users.

Keep your eyes on the target: making Axis2 easy to use for users.

--
Tom Jordahl


-----Original Message-----
From: Eran Chinthaka [mailto:chinthaka@opensource.lk]
Sent: Monday, October 08, 2007 11:02 PM
To: axis-dev@ws.apache.org
Cc: synapse-dev@ws.apache.org
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 all the transports,
including http, smtp, tcp, etc., or will there be modules for each and
every transport?

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.

What will be inside default axis2.xml?

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.
The intuition is that most of the time the transport will be http and
will make the life easier for about 90% of the users.

Also I'd like to evaluate the impact of this on the HTTP binding
implementation that we have now. I think that also will go out of
Kernel.

)
Just my 2 cents.

Thanks,
Chinthaka

Srinath Perera wrote:
>> 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 non-blocking http/s transport, and kept this
within
>> Synapse. After some time there was a suggestion from Axis2 that we
>> should check this code into Axis2 instead to make it available to a
>> wider audience for usage, testing and improving overall quality as
well.
>> Thus we checked this into Axis2 [Kernel :-(]
> +1 yes that is right way to go
>
>> Now the problem is this.. The JMS transport was implemented for JMS
1.1,
>> and the ESB community encountered users who wanted to deploy
production
>> apps using JMS 1.0.2. We also had a few bug fixes going into the NIO
>> transport - where we couldn't wait for "the next axis2" release. We
also
>> developed a Apache VFS based file/ftp/sftp/.. transport lately. We
would
>> like to give this code to all Axis2 users for sure, but not within
the
>> Axis2-kernel module - as it would create issues for us to make never
>> versions of these same classes for our use.
>>
>> As you may be already aware, Synapse is very close to transports -
i.e.
>> we want the maximum out of them, and would encounter most users who
>> would be looking for custom transports etc. We also do lots of load
>> testing for concurrency and NIO related issues.. and we want to stay
>> upto-date with the latest HttpCore release. Now since we committed
our
>> initial transport code into Axis2-kernel, we are in a fix on making
safe
>> updates as and when required for Synapse releases.
>>
>> All we ask for is for Axis2 to create a module for transports and
take
>> transports out from the kernel.
>
>
> OK you convinced me. I am +1 on creating module for transports.
> However as David pointed out we have to do it in Axis2 major release.
>
> One middle ground would be to create a transport module and first add
> additional transports while leaving what ever we have in kernel as it
> is for now. At a major release you can move other transports out as
> well. (May be you can leave http transport in the core for testing
> reasons, but that we can decide later). That way we can ship
> additional transports with minor release without adding them to
> axis2.xml, and synapse can add them via custom axis2.xml.
>
> Thanks
> Srinath
>
>
>> asankha
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHCu8ZjON2uBzUhh8RAmbkAJ9fom4XImV2+x+7iPmBrF+rzC+l/ACcCckk
Z3saNc4pBfUWn7OsV/pFzGo=
=wlxq
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


------=_Part_8346_2214055.1191949638733--