ionality that users have asked for (hey, do we support
> |> consuming rpc/encoded services via ADB yet?) that would seem to me
> |> should take priority over OSGi.
> |>
> |> --
> |> Tom Jordahl
> |>
> |> -Original Message-
> |> From: Deepal jayasi
ia ADB yet?) 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 t
to:[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 that
yet?) 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 ,
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 seem
+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 exac
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 environm
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: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?
-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
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 requi
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 ;-)
-Dee
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...
-
-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 clean
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 ext
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 spa
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 cor
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,
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
-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 ab
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
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,
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
> 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
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 bund
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
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
bun
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
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 sho
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
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 t
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.
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
cated.
My two cents...
-Vinh
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
=
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 h
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 ne
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
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 chang
nghe <[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 eng
scany.
...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 you
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 , if there are users like who really need
OSGi , then we really should consider providing OSGi support out of the
box.
> I agree. Currently
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 featu
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 O
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 ha
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
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 sugges
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 t
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 understand
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 ?
Mai
-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
|> e
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 event
51 matches
Mail list logo
