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 then are there , because over 50K download taking place per month due to fact that people out there happy what Axis2 does now. So why worry of changing that. Thats the only worry I have. Just because OSGi is there and it is cool , we should not change our code base to support those. As I mentioned I have no objection on implementing new AxisConfigurator based on OSGi and do what ever we want , but I do not like changing the current core code base to support OSGi. Because I do not see a value of doing that.
If we want to expand Axis2 useage, this
sounds like the kind of forward looking change that would help.
Yes. I agree.
I don't understand what your problem is with making a change to allow
hot module deployment beyond the fact it's not how Axis2 works today.
Is it your view that no new function that affects the kernel design is
acceptable from now on, because that's what your e-mail seemed to
suggest?
Nope I did not mean that. You can do changes to the kernel but not major , critical changes like above does not need for kernel. Which may arise a number of issues, and might break the existing users and might affect the backward compatibility as well. Mature project like Axis2 should not do those. If we make our services and modules are OSGi bundle then the amount of work that a service author has to do is very high compared to now (I got to know that from Saminda). That is why I reluctant to change the current kernel code base.


Thank you!
Deepal


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to