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
13 matches
Mail list logo
