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
Asankha C. Perera wrote:
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 :-) !..
Very cool indeed!
Axis2 transports also needs a few more changes though.. and I'm
re-thinking about
+1 to this proposal
Paul
On Wed, Apr 23, 2008 at 5:11 AM, Sanjiva Weerawarana
[EMAIL PROTECTED] wrote:
Wow, miss this list for a few days and boom!
Here's my attempt at a summary position:
- First of all, Asankha, why synapse-transports.jar?? That makes no sense
to me- so if you have a
On 23 Apr 2008, at 05:11, 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.
Java provides packages for that. There's no need
Hey Sanjiva:
Sanjiva Weerawarana wrote:
- 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
+1
And while we're at it (separate conversation though), perhaps
transports should be deployable as easily as services/modules...
conf/
modules/
services/
transports/
nhttp.tsp
jms.tsp
...with transport.xml inside *.tsp/META-INF
This is just a matter of writing a new
Deepal Jayasinghe wrote:
And while we're at it (separate conversation though), perhaps
transports should be deployable as easily as services/modules...
conf/
modules/
services/
transports/
nhttp.tsp
jms.tsp
...with transport.xml inside *.tsp/META-INF
This is just a matter of
Hi Michele:
Michele Mazzucco 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.
Java provides packages for that. There's no need to have tons of
Glen,
I disagree, each transport is composed by just a few classes, not
megs of code.
I can't see really see where the problem is if you put JMS and SMTP
transports into the same jar file.
Michele
On 23 Apr 2008, at 13:09, Glen Daniels wrote:
Hi Michele:
Michele Mazzucco wrote:
- First
Michele, its about making it easy to maintain and use. We gain nothing by
putting them into the same jar file.
With respect to your comment earlier saying
So you end up increasing the limits for files/sockets on you linux box
HUH?? What are you talking about?? This has nothing to do with limits
On 23 Apr 2008, at 14:24, Sanjiva Weerawarana wrote:
Michele, its about making it easy to maintain and use. We gain
nothing by putting them into the same jar file.
With respect to your comment earlier saying
So you end up increasing the limits for files/sockets on you linux
box
HUH?? What
Michele Mazzucco wrote:
Yes, since every jar file adds 1 to the number of files opened by a
process (your JVM is a process itself). The default limit for files +
socket that can be opened by a process is 1024.
Um in toy systems maybe .. but this a tunable kernel parameter and in any
real
On 23 Apr 2008, at 18:20, Sanjiva Weerawarana wrote:
Michele Mazzucco wrote:
Yes, since every jar file adds 1 to the number of files opened by
a process (your JVM is a process itself). The default limit for
files + socket that can be opened by a process is 1024.
Um in toy systems maybe
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
Who will run all the transports in a single server? I like the ability to pick
and choose what I want. May be you will ship one or two key transports as
part of Axis2 and that is sufficient for most of the users.
This way if there is a bug in a particular transport that can be fixed and
As we discussed in the mailing list I created a prototype deployer
(TransportDeployer) for transport deployment. With the deployer I wrote
we can deploy transport as we deploy service or module. The only thing
we need to do is to add a descriptor file called “transport.xml” into
the META-INF
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Folks,
Let's move JMS and Async NIO transports out of Axis2 into Synapse. There's no
point keeping a stale copy in Axis2.
WDYT?
Thanks,
dims
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
I agree there isn't any point keeping stale copies in Axis2. What
about building a separate module or even commons-transports?
Paul
On Tue, Apr 22, 2008 at 1:32 PM, Davanum Srinivas [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Folks,
Let's move JMS and Async
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Under synapse...Sure. Perfect.
- -- dims
Paul Fremantle wrote:
| I agree there isn't any point keeping stale copies in Axis2. What
| about building a separate module or even commons-transports?
|
| Paul
|
| On Tue, Apr 22, 2008 at 1:32 PM, Davanum
+1 for me.
Michele
On 22 Apr 2008, at 13:37, Davanum Srinivas wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Under synapse...Sure. Perfect.
- -- dims
Paul Fremantle wrote:
| I agree there isn't any point keeping stale copies in Axis2. What
| about building a separate module or even
-1 from me to move them to 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 there should be a single place for them, but that place
should be in Axis2, not somewhere else.
I'd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Glen,
If it is not maintained in Axis2, there's absolutely no point keeping it here.
Right?
- -- dims
Glen Daniels wrote:
| -1 from me to move them to Synapse.
|
| These transports (JMS, NIO, whatever) are going to be generally useful
| to any
Dims,
a separate module would probably be better then.
Michele
On 22 Apr 2008, at 14:29, Davanum Srinivas wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Glen,
If it is not maintained in Axis2, there's absolutely no point
keeping it here. Right?
- -- dims
Glen Daniels wrote:
|
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michele,
2 thoughts.
- - there should not be stale copies
- - people who work on them should work where they want to.
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
Let me rephrase succinctly. :)
There should be a single place where generally applicable Axis2
transports get stored. It's fine for other projects to work on
transports, but the ideal situation is for those transports (assuming
they're generic enough) to migrate into the WS PMC as their
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
Asankha C. Perera wrote:
Dims
- there should not be stale copies
- people who work on them should work where they want to.
+1 to both!
Agreed - I'd just prefer people wanted to work on them under WS/Axis. :)
I'd like to maintain these under Synapse.. We wrote these transports
primarily for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Glen,
At this point, Can we please agree that it's better for the people who actually
work on it have their way :)
thanks,
dims
Glen Daniels wrote:
| Asankha C. Perera wrote:
| Dims
| - there should not be stale copies
| - people who work on them
This seems like an inevitable, if unfortunate result of spinning
Synapse off as a separate TLP.
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', or is it more cultural that
Hi Dims, Glen and all,
On Tue, Apr 22, 2008 at 10:48 PM, Davanum Srinivas [EMAIL PROTECTED]
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Glen,
At this point, Can we please agree that it's better for the people who
actually work on it have their way :)
+1 for this idea ... and
I forgot to mention that, of cause one can use these transports with knowing
the limitations and issues of those, when working directly with axis2
Thanks,
Ruwan
On Tue, Apr 22, 2008 at 11:16 PM, Ruwan Linton [EMAIL PROTECTED]
wrote:
Hi Dims, Glen and all,
On Tue, Apr 22, 2008 at 10:48 PM,
My biggest concern with putting these in Synapse is the dependency
chain. Since the APIs are defined as part of Axis2, I think it makes
more sense for these to live in the WS space. So my preference would
be to have these (and others) in commons/transports
Paul
On Tue, Apr 22, 2008 at 6:49 PM,
Hi Ruwan:
If a given transport really only has relevance in the Synapse
environment, then of course that transport has no need to exist outside
Synapse. But if a transport is generically useful, I'd prefer to see it
somewhere in WS space as opposed to specifically within Synapse. And if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I agree with Glen, but would add another wrinkle. Let's make a decision and
stick to it!!! Now, who wants to start a
VOTE? :)
- -- dims
Glen Daniels wrote:
| Hi Ruwan:
|
| If a given transport really only has relevance in the Synapse
|
Glen,
I agree with you. But my concern is the history. That is, when ever we
(synapse) wanted some transport specific feature for synapse to be added to
axis2 transports axis2 community was not accepting them due to many reasons
most of them are valid for web services, but from the synapse point
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ruwan,
How about a pointer to a public discussion on why SMTP Transport changes were
debated? :)
- -- dims
Ruwan Linton wrote:
| Glen,
|
| I agree with you. But my concern is the history. That is, when ever we
| (synapse) wanted some transport
Dims,
I couldn't find this on the axis2 mail archives, that thread was having the
subject Improvement to mail transport from a Synapse use case and posted
by saminda to the axis-dev.
Here is the relevant thread on Synapse [
Hi Ruwan:
Be careful to reply all so that [EMAIL PROTECTED] gets cc'ed...
Ruwan Linton wrote:
I agree with you. But my concern is the history. That is, when ever we
(synapse) wanted some transport specific feature for synapse to be added
to axis2 transports axis2 community was not accepting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
Ruwan Linton wrote:
| Dims,
|
| I couldn't find
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Agreed that this is definitely a problem.
Next question, is do you want do this in Synapse Commons (do you have one?) or
WS Commons?
- -- dims
Ruwan Linton wrote:
| Dims,
|
| I agree there is no -1, but at the same time we couldn't get those
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
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
Davanum Srinivas wrote:
Agreed that this is definitely a problem.
Next question, is do you want do this in Synapse Commons (do you have
one?) or WS Commons?
We already have all the transports in a separate Maven module, which is
published to Apache snapshots and Central repo.. As far as I am
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Cool. I'll cleanup whatever stale transports are in Axis2.
thanks,
dims
Asankha C. Perera wrote:
|
| Davanum Srinivas wrote:
| Agreed that this is definitely a problem.
|
| Next question, is do you want do this in Synapse Commons (do you have
|
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Asankha,
FWIW,
1) I see a +1 from Deepal and Dr. Sanjiva
2) No one did a -1
3) There was no VOTE
So, where's the beef? AFAICT, No one objected to someone else doing the work :)
So all i can see is an implicit and not to mention unilateral
Dims,
If the axis2 community had agreed to do that then one of the core members of
the axis2 team should do that, (we don't want to move the code inside axis2
and mess with your project, would you like me moving the transports out from
axis2 kernel??? also with the objections in that thread), but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ruwan,
I was not around, i can't speak for others. I did not participate in that
thread. Let's treat it as water under the bridge.
I'll go ahead and get rid of stale code in Axis2 and let's be done with it.
Synapse committers can do what they
Ruwan, no one is going to (or even ABLE to, for that matter) force the
Synapse team to do anything. We're trying to work together here, and
build a system of interacting parts that work well together for the
largest possible number of satisfied users (sounds like some companies I
know :)).
Hey Asankha:
Just wanted to quickly reply to this.
Asankha C. Perera wrote:
So if we are going to have a vote on this 'topic' on axis-dev, I am +1
to deleting the stale copies of the transports currently in Axis2.
+1, for sure.
But if you are going to call for a vote on [EMAIL PROTECTED] to
Wow, miss this list for a few days and boom!
Here's my attempt at a summary position:
- 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
Glen Daniels wrote:
-1 from me to move them to 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 there should be a single place for them, but that place
should be in Axis2,
51 matches
Mail list logo
