To: axis-dev@ws.apache.org
Subject: Re: Extensions to Axis2/Java deployment engine
After reading all the mails , I still in the position that , YES we need
to support OSGi. But , its better if we can do that without changing the
core module. So I will help my best to write a OSGi based Axis
| should take priority over OSGi.
|
| --
| Tom Jordahl
|
| -Original Message-
| From: Deepal jayasinghe [mailto:[EMAIL PROTECTED]
| Sent: Friday, June 13, 2008 5:26 AM
| To: axis-dev@ws.apache.org
| Subject: Re: Extensions to Axis2/Java deployment engine
|
| After reading all the mails , I still
: Deepal jayasinghe [mailto:[EMAIL PROTECTED]
| Sent: Friday, June 13, 2008 5:26 AM
| To: axis-dev@ws.apache.org
| Subject: Re: Extensions to Axis2/Java deployment engine
|
| After reading all the mails , I still in the position that , YES we need
|
| to support OSGi. But , its better if we can do
Agreed.
Michele
On 16 Jun 2008, at 03:19, Asankha C. Perera wrote:
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
Saminda Abeyruwan wrote:
=
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
I think the ideal outcome would be this:
* Firstly we allow Axis2 to work cleanly in a OSGi environment.
* We also allow Axis2 to work in a non-OSGi environment (full
backwards compatibility).
* We define an extension to Axis2 that is available as a separate JAR
that enables OSGi
* If the OSGi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul,
That's exactly that's being done so far on the osgi module in various stages of
completion :) [Except for the last item]
thansk,
dims
Paul Fremantle wrote:
| I think the ideal outcome would be this:
|
| * Firstly we allow Axis2 to work
Ruwan Linton wrote:
Also just wanted to make sure, what is the advantage of being OSGi
with Java 7 which promises to provide versionning via JAM (Java
Application Modules)
How long would it be before everyone adopts 1.7?
Samisa...
Ruwan Linton wrote:
Also just wanted to make sure, what is the advantage of being OSGi
with Java 7 which promises to provide versionning via JAM (Java
Application Modules)
How long would it be before everyone adopts 1.7?
I think same answer can be applied for the OSGi as well ;-)
Deepal
I think you completely missed the point.
Changes to the Java VM require users to migrate. That can be
difficult. Many users are still on JDK 1.4 for core systems because
they are on App Servers certified on that model. OSGi has been
designed to work *with* any JVM and therefore avoid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Guys,
Sun is promising full interop JAM-OSGi [1]. They are trying to pull in Peter
[2] to help. Gory details here [3]. Sun
folks are playing politics it seems [4].
Bottom line, 277 may be farther away than you think. Since GlassFish has
already
On Mon, Jun 16, 2008 at 5:29 AM, Ruwan Linton [EMAIL PROTECTED]
wrote:
Saminda,
Can you please answer to these question directly (yes/no)?
Will this change preserve backward compatibility?
Will we be able to use axis2 as it is, without OSGi?
Will the current behavior be preserved?
Yes to
Hi Dims all
This discussion about OSGi is very interesting.
I agree that OSGi benefits are maybe not directly visible for the
end-user but maybe more for the deployer/assembler.
We did exactly what you want to do with Axis with our EJB3 container
(EasyBeans) a year ago:
* Having OSGi as an
On Mon, Jun 16, 2008 at 5:26 PM, Paul Fremantle [EMAIL PROTECTED] wrote:
I think the ideal outcome would be this:
* Firstly we allow Axis2 to work cleanly in a OSGi environment.
Axis2 need to lax the tight dependency between modules and services. This
should be done only in OSGi environment,
+1
Saminda
On Mon, Jun 16, 2008 at 7:17 PM, Guillaume Sauthier
[EMAIL PROTECTED] wrote:
Hi Dims all
This discussion about OSGi is very interesting.
I agree that OSGi benefits are maybe not directly visible for the end-user
but maybe more for the deployer/assembler.
We did exactly what
On Mon, Jun 16, 2008 at 6:41 PM, Davanum Srinivas [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Guys,
Sun is promising full interop JAM-OSGi [1]. They are trying to pull in
Peter [2] to help. Gory details here [3]. Sun
folks are playing politics it seems [4].
?) that would seem to me
should take priority over OSGi.
--
Tom Jordahl
-Original Message-
From: Deepal jayasinghe [mailto:[EMAIL PROTECTED]
Sent: Friday, June 13, 2008 5:26 AM
To: axis-dev@ws.apache.org
Subject: Re: Extensions to Axis2/Java deployment engine
After reading all the mails , I still
Hi Saminda,
=
In Synapse point of view.
1. Mediators can be written as OSGi bundles.
What is the value addition?
When you start the bundle, the proper factory is called and build the
relevant object model.
Even now it does very
Would OSGi would be more useful to end users or to those who want to
embed and bundle Axis2?
Samisa...
Asankha C. Perera wrote:
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,
Hi All,
w.r.t OSGi, at the end of the day prior points will boil down to version,
modularity and life-cycle support. OSGi has established its ways to be a
good modular system for Java.
This extension wouldn't break any backward compatibility. But in order to
embed this extension properly, few
Axis2 itself being an OSGi bundle wouldn't provide any added advantage.
Axis2 needs its deployment units to be OSGi enabled as well to get the
proper usage of OSGi. These deployment units are bundles and it will be seen
by end users. There are many tools available from Eclipse/Maven2 to create
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
Hi Saminda,
You have mentioned rampart as a famous example. rampart.mar contains
only the module.xml. All other 3rd party jars has to be put into root lib.
Rampart folks has done this, in order to prevent class delegation problems.
With OSGi, one would need only to copy the relevant bundles
The reason Rampart jars need to go in to Axis2 lib is the Sun Service
Provider Interface problem. rampart-core.jar and rampart-policy.jar
registers some assertion builders using Sun SPI and those builders to be
used by neethi factory classes they should be in the classpath of those
neethi
On Mon, Jun 16, 2008 at 1:03 AM, Saminda Abeyruwan [EMAIL PROTECTED]
wrote:
The reason Rampart jars need to go in to Axis2 lib is the Sun Service
Provider Interface problem. rampart-core.jar and rampart-policy.jar
registers some assertion builders using Sun SPI and those builders to be
used
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Asankha,
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?
As saminda mentions, the idea is to add a few OSGi Activators,
Saminda,
Can you please answer to these question directly (yes/no)?
Will this change preserve backward compatibility?
Will we be able to use axis2 as it is, without OSGi?
Will the current behavior be preserved?
Thanks,
Ruwan
On Mon, Jun 16, 2008 at 4:11 AM, Davanum Srinivas [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ruwan,
Personally if the answers are no, then we should *NOT* go ahead.
thanks,
dims
Ruwan Linton wrote:
| Saminda,
|
| Can you please answer to these question directly (yes/no)?
|
| Will this change preserve backward compatibility?
| Will we be
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.
Dims,
Yes exactly. If we can give Yes as the answers for these three, I don't have
any objection at all.
Thanks,
Ruwan
On Mon, Jun 16, 2008 at 6:04 AM, Davanum Srinivas [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ruwan,
Personally if the answers are no, then we
Correct. Deployment units of Axis2 will be aar/mar. What we are looking for
an extension from Axis2 kernel, which would allow to inject services and
modules as bundles. In order to achieve this, there are few deployment
semantics that needed to be addressed in kernel, it to be fully flexible.
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
Hi Deepal,
I know decisions were made about various things before I was on the
scene, but nothing is unchangable, and what Saminda is suggesting
sounds really cool and useful. If we want to expand Axis2 useage, this
sounds like the kind of forward looking change that would help.
I don't
Hi Deepal,
I know decisions were made about various things before I was on the
scene,
;-)
And we did not know about OSGi when we design Axis2.
but nothing is unchangable, and what Saminda is suggesting
sounds really cool and useful.
I agree, but I do not like to change Axis2 fundamentals
On Fri, Jun 13, 2008 at 7:56 AM, Deepal Jayasinghe [EMAIL PROTECTED] wrote:
Hi Deepal,
I know decisions were made about various things before I was on the
scene,
;-)
And we did not know about OSGi when we design Axis2.
but nothing is unchangable, and what Saminda is suggesting
sounds
Hi David ,
Hi Deepal,
I know decisions were made about various things before I was on the
scene,
I agree with you that when Axis2 was designed you were not there. But
there were number of very experienced people (to be honest , at that
stage I did not know much about Web services so I do not
OK, so I disagree with this position. Yes, we get lots of downloads,
but those are of releases,
Yes, they download the release , because they happy what Axis2 does. If
they need any more feature they will ask about that. And I know a number
of users have asked about various things and they
On Fri, Jun 13, 2008 at 12:56 PM, David Illsley [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 7:56 AM, Deepal Jayasinghe [EMAIL PROTECTED] wrote:
Hi Deepal,
I know decisions were made about various things before I was on the
scene,
;-)
And we did not know about OSGi when we design
Hi Venkat,
I really appreciate your post , if there are users like who really need
OSGi , then we really should consider providing OSGi support out of the box.
I agree. Currently I'm evaluating Axis2.0 for embedding it in one of
our products which is built on equinox platform. If Axis2.0
@ws.apache.org
To
axis-dev@ws.apache.org
cc
Subject
Re: Extensions to Axis2/Java deployment engine
Hi Venkat,
I really appreciate your post , if there are users like who really need
OSGi , then we really should consider providing OSGi support out of the
box.
I agree. Currently I'm evaluating
.
...ant
*Deepal Jayasinghe [EMAIL PROTECTED]*
13/06/2008 10:06
Please respond to
axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
cc
Subject
Re: Extensions to Axis2/Java deployment engine
Hi Venkat,
I really appreciate your post
Subject
Re: Extensions to Axis2/Java deployment engine
Hi Venkat,
I really appreciate your post , if there are users like who really need
OSGi , then we really should consider providing OSGi support out of the
box.
I agree. Currently I'm evaluating Axis2.0 for embedding
Hi All,
Writing an OSGi based AxisConfigurtor sounds reasonable. But this is
not the only change that would require. AxisService builder has to
change too.
The association between modules and services are handle their. These
builders are reside in kernel. This means, kernel has to
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
After reading through the thread here is my 2 cents.
I totally agree that OSGi based configurator is a good idea. So +1 for that.
However making that the default , tinkering with the kernal or changing
default architectural properties of axis2 is not a good idea in my opinion.
Whatever it is we
=
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.
2. We will be able to
From: Saminda Abeyruwan [mailto:[EMAIL PROTECTED]
Sent: Friday, June 13, 2008 8:30 AM
To: axis-dev@ws.apache.org
Subject: Re: Extensions to Axis2/Java deployment engine
=
1. When aar/mar behavior is mimicked in an OSGi bundle, these bundles be
able
Just want to make sure that the current deployment method for mars and web
services (aar structure) is unchangedyou just want add additional
feature which is support of OSGI, right?
Nadir Amra
David Illsley [EMAIL PROTECTED] wrote on 06/13/2008 02:26:42 AM:
On Fri, Jun 13, 2008 at 7:56
Hi Devs,
Dims has started the work on providing the OSGi extension to Axis2. This
extension is a single bundle which consist of all the jars needed to run
axis2. It uses OSGi Bundle events to update AxisConfiguration. Main aspect
of OSGi is version and modularity. In order to get the full
Sounds good. +1
David
On Thu, Jun 12, 2008 at 5:27 PM, Saminda Abeyruwan [EMAIL PROTECTED] wrote:
Hi Devs,
Dims has started the work on providing the OSGi extension to Axis2. This
extension is a single bundle which consist of all the jars needed to run
axis2. It uses OSGi Bundle events to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
+1 Go for it!
- -- dims
David Illsley wrote:
| Sounds good. +1
| David
|
| On Thu, Jun 12, 2008 at 5:27 PM, Saminda Abeyruwan [EMAIL PROTECTED] wrote:
| Hi Devs,
|
| Dims has started the work on providing the OSGi extension to Axis2. This
|
Hi Devs,
Dims has started the work on providing the OSGi extension to Axis2.
This extension is a single bundle which consist of all the jars needed
to run axis2. It uses OSGi Bundle events to update AxisConfiguration.
So does that mean Dims has written a OSGi based Axis configurator ?
52 matches
Mail list logo
