You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Glen Daniels <gl...@thoughtcraft.com> on 2007/05/30 23:54:33 UTC
[axis2] More Modules and classpaths
I'd like to be able to deploy a Module by just putting it on the
classpath...
CLASSPATH=...; addressing.mar; ...
This is pretty easy to implement, seems highly convenient, and goes
along with some other deployment-related stuff I'm thinking about, but I
wanted to run it past folks first. It would work with either exploded
module directories or mars.
Can I get a +1?
--Glen
P.S. This does not work at present, although we do some weird
classpath-related stuff - a future message will analyze and critique
said stuff.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Rajith Attapattu <ra...@gmail.com>.
Glen,
I thought this is already implemented (However I stand to be corrected)
--Rajith
On 5/30/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
>
> I'd like to be able to deploy a Module by just putting it on the
> classpath...
>
> CLASSPATH=...; addressing.mar; ...
>
> This is pretty easy to implement, seems highly convenient, and goes
> along with some other deployment-related stuff I'm thinking about, but I
> wanted to run it past folks first. It would work with either exploded
> module directories or mars.
>
> Can I get a +1?
>
> --Glen
>
> P.S. This does not work at present, although we do some weird
> classpath-related stuff - a future message will analyze and critique
> said stuff.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [axis2] More Modules and classpaths
Posted by Saminda Abeyruwan <sa...@gmail.com>.
Hi All,
After the
http://svn.apache.org/viewvc?view=rev&rev=542835
Log:
Revision 542835 of trunk, we weren't able to load service archive inside the
module archive. This feature has been a handy way to archive services inside
modules. Now this feature is broke with the following exception,
org.apache.axis2.AxisFault: The system is attempting to engage a module that
is not available: wso2statistics
at org.apache.axis2.engine.AxisConfiguration.engageModule(
AxisConfiguration.java:407)
at org.apache.axis2.deployment.DeploymentEngine.engageModules(
DeploymentEngine.java:597)
at org.wso2.wsas.deployment.ServerConfigurator.engageGlobalModules(
ServerConfigurator.java:273)
at
org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext
(ConfigurationContextFactory.java:73)
Should I file a JIRA.
Thank you
Saminda
On 6/1/07, Deepal Jayasinghe <de...@opensource.lk> wrote:
>
> Hi Glen,
>
> I implemented that feature more than a year ago and it work perfectly
> you do not need to do anything. please have a look at the following faq
> as well.
>
> http://wso2.org/library/182
>
> Thanks
> Deepal
>
> Glen Daniels wrote:
> > I'd like to be able to deploy a Module by just putting it on the
> > classpath...
> >
> > CLASSPATH=...; addressing.mar; ...
> >
> > This is pretty easy to implement, seems highly convenient, and goes
> > along with some other deployment-related stuff I'm thinking about, but
> > I wanted to run it past folks first. It would work with either
> > exploded module directories or mars.
> >
> > Can I get a +1?
> >
> > --Glen
> >
> > P.S. This does not work at present, although we do some weird
> > classpath-related stuff - a future message will analyze and critique
> > said stuff.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
> >
>
> --
> Thanks,
> Deepal
> ................................................................
> "The highest tower is built one brick at a time"
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Saminda Abeyruwan
Software Engineer
WSO2 Inc. - www.wso2.org
Re: [axis2] More Modules and classpaths
Posted by Paul Fremantle <pz...@gmail.com>.
Actually (as David made me realize) I'm -0 at this stage. I was
exagerating before.
Paul
On 6/4/07, Paul Fremantle <pz...@gmail.com> wrote:
> I'm the idiot who suggested fixing the RM problem :-)
>
> Given the choice between re-architecting modules to insert their own
> phases - or just adding the RMPhase to the standard phases you can
> guess which is my proposal. I vote for the really really simple
> option.
>
> [In fact I we don't even need that. We already have OperationInPhase
> (for example) where the RM handlers could go. But it would be clearer
> or nicer to add the RMPhases into the default XML]
>
> However, as a solution to a general problem, I don't think we need the
> ability for modules to insert phases. There is already plenty of scope
> for any module writer to add their handlers into the right places
> using the existing phases that are hard-coded plus the capabilities to
> do partial ordering of handlers that exist today.
>
> I'm -1 on doing a lot of coding to change the handler/phase/module
> architecture when the solution to this problem is using a text editor
> to add <phase name="RMPhase"/> in about 4 places.
>
> Paul
>
>
>
> On 6/4/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> > Glen Daniels wrote:
> > >
> > > Hm. While the current system technically works, the old Axis1
> > > Phase-less way of deploying ordered Handlers worked too, as long as you
> > > were sufficiently careful and correct. :)
> > >
> > > Modules right now aren't really pluggable components. To use a Module
> > > which uses non-standard phases in your service, you need to a) read the
> > > Module documentation and understand WHICH phases you need to add to the
> > > global configuration, AND in what order (this seems like EXACTLY the
> > > kind of stuff we were trying to move from documentation to config/code
> > > for Axis2), b) change axis2.xml accordingly, and c) deploy the module
> > > globally. That's a pain, and I think it's kind of ironic that it's
> > > exactly this kind of configuration we were avoiding for Handlers.
> >
> > The problem I have with this proposal is that we're trying to come up with
> > an automatic solution to a *problem we have*. That is, security and RM are
> > really core parts of what we're trying to do. If we had *users* saying
> > that our phase insertion architecture is too limited I'd be fully
> > convinced but here we have essentially core bits of the WS-* stack folks
> > requiring that we insert another string into axis2.xml and the proposed
> > solution is a major feature improvement. I'm not convinced by such
> > arguments - features need to be coming from users .. not from us. This is
> > like the argument for cloning the handler chain; we did it and we don't
> > need it at all .. YAGNI.
> >
> > So, I'm with Deepal in opposing this approach.
> >
> > Also, I'd even like to reconsider the decision to make Rampart into a
> > separate project. As we noticed with the 1.2 release, users need Rampart
> > to be available *with* the axis2 releases. Same goes for Sandesha. So if
> > those projects are ok I think its best to move them back in as maven
> > modules of axis2. Yes I know this is a big change of heart for me but I've
> > learnt from the experience that we made a mistake. As a major proponent of
> > the split into multiple projects, I admit I was wrong!
> >
> > > It's like we've gone halfway, and I would really like to go the rest of
> > > the way so that Modules can just work together without the intervention
> > > of skilled human technicians modifying global configuration files. IMHO
> > > the only times you should be REQUIRED to touch config files as an
> > > "assembler" of prebuilt components should be to resolve a conflict.
> >
> > Again, this is a theoretical argument. If there were *users* beating down
> > our door saying "dudes, this stuff is so cool but you are killing me with
> > this lack of recursiveness for phases" then I'd be convinced. When we're
> > trying to do this as a solution to the problem of "can we add the RM phase
> > to axis2.xml" I don't accept it.
> >
> > > (While we're on the subject I also continue to think that we should
> > > allow packaging Modules in Service archives - i.e.
> > > services/MyService/modules/foo.mar. It's a very analogous situation.)
> >
> > ARGH! A major -1 for this!
> >
> > This is COMPLETELY YAGNI and further brings into Axis2 a feature of Axis1
> > which I personally fought to keep out: allowing user code to extend the
> > system runtime. Modules are not some random bit of code to run- they are
> > system extensions. As such, user services have no business extending the
> > system! I opposed adding handlers in services.xml for the same reason. I
> > lost that argument but AFAICT we don't have a single *user* usecase for
> > that yet. Making that even more functional is not the thing we should be
> > putting our time and effort into at this stage.
> >
> > In any case, we have the ability to have a module and have only one
> > service engage it. All our approach forces is that the service runtime
> > admin be aware of what modules they're running. That's goodness, not a
> > limitation.
> >
> > Axis2 is *full* of cool features. What Axis2 needs is stability,
> > consistency and completion of those features. We don't need more features
> > right now (which will likely end up as YAGNI) - let's get what we have to
> > work exactly right, wait for users to demand more features and *then* add
> > them.
> >
> > >> May be we can add that for Axis3 (if we are planing to do so :) )
> > >
> > > Deepal, I would be kind of bummed if we had to do an Axis3. It would
> > > mean we didn't get it right in Axis2.
> >
> > I agree. We've now built pretty much the entire WS-* core platform for
> > Axis2 and the architecture is holding up just fine. So I see no reason to
> > think we'll need an Axis3.
> >
> > Sanjiva.
> > --
> > Sanjiva Weerawarana, Ph.D.
> > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > Director; Open Source Initiative; http://www.opensource.org/
> > Member; Apache Software Foundation; http://www.apache.org/
> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Rajith Attapattu wrote:
>
> On 6/4/07, *Sanjiva Weerawarana* <sanjiva@opensource.lk
> <ma...@opensource.lk>> wrote:
>
> Glen Daniels wrote:
> That was a different time- we were architecting a new Axis version
> and OF
> COURSE we need to create stuff. We're NOT doing that now. Our users need
> stability, not creativity from us, especially when no one has asked
> for it.
>
>
> To be fair this comment is not just for what Glen is suggesting but
> rather a general comment about our ever increasing appetite for
> introducing new things.
I agree; I'm not picking on Glen only .. sorry Glen if it comes across
that way!
It applies for all of us, including me! I think the rule should go for
everyone at this stage- let's not innovate unmotivated. If something is
broken then definitely we need to fix it. Otherwise, if there's proven
user demand for it let's fix it. However, if its just an improvement to
make things better let's not .. because "better" is not well defined there.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Rajith Attapattu <ra...@gmail.com>.
On 6/4/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
> Glen Daniels wrote:
> That was a different time- we were architecting a new Axis version and OF
> COURSE we need to create stuff. We're NOT doing that now. Our users need
> stability, not creativity from us, especially when no one has asked for
> it.
>
To be fair this comment is not just for what Glen is suggesting but rather a
general comment about our ever increasing appetite for introducing new
things.
If we want axis2 to be production ready then we should focus more on
stability than adding more features , unless something is critically wrong.
If we can add phases by modifying the axis2.xml, then we shouldn't worry
about making things more elegant and instead focus our time and energy on
getting other nagging issues fixed.
Most people will prefer a more stable product than a product with a lot of
*cool* features. Every product has a lifecycle and as a community we should
evaluate where we are. Are we still in the growth phase or are we trying to
stabilize things?
It's ok to be innovative and creative at the beginning but then priority
should be *shifting* to stability and reliability once we pass the growth
stage.
I am not suggesting that innovation should be stifled for the sake of
stability, but rather a more intelligent approach of striking the right
balance and managing our priorities to address the users demand. If we don't
give the users what they want in a timely manner then people will slowly but
surely move away.
If I develop on Axis2, whats the point if I need to wait for 3 months to
deploy in production bcos the current release is full of cool yet untested
features (and especially when I have no use for them) !!!
Regards,
Rajith
Re: [axis2] More Modules and classpaths
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi Paul
>> Paul, next time just add it and commit!
>
> Committed revision 544308.
>
You need to add that to kernal/axis2.xml not to integration module.
Thanks
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi all,
> Paul Fremantle wrote:
>>> Paul, next time just add it and commit!
>>
>> Committed revision 544308.
>
> I'm not going to -1 this (especially if I'm in the minority, or a
> minority of one!), but a) I don't particularly like it, b) note that
> anyone using a non-default axis2.xml will still need to manually add
> this themselves, and c) what about Kandula? Are we going to pre-add
> every phase we'll ever need to the default axis2.xml? That will
> certainly help with making sure they're in the right order! :)
This is second time I am suggesting this ,
As Sanjiva mentioned let's add a set of meaning full phases into
axis2.xml so that module authors can use them
FYI : We have already have phase called "Security" so why not RM ? :)
Thanks
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Paul Fremantle <pz...@gmail.com>.
> I'm not going to -1 this (especially if I'm in the minority, or a
> minority of one!), but
> a) I don't particularly like it,
You've never complained abouit the security phase which has been there
for a year!
b) note that > anyone using a non-default axis2.xml will still need to
manually add
> this themselves,
Yep, I agree.
> and c) what about Kandula? Are we going to pre-add
> every phase we'll ever need to the default axis2.xml?
If it got out of hand, we could certainly do some simplification from
where we are. However, I think there is a sweet spot around the RASP
profile.
> That will
> certainly help with making sure they're in the right order! :)
You seem to imply this would be a bad thing! I think having a
reasonably comprehensive default set of phases that support most users
would be a perfectly good idea.
Paul
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Paul Fremantle wrote:
>> Paul, next time just add it and commit!
>
> Committed revision 544308.
I'm not going to -1 this (especially if I'm in the minority, or a
minority of one!), but a) I don't particularly like it, b) note that
anyone using a non-default axis2.xml will still need to manually add
this themselves, and c) what about Kandula? Are we going to pre-add
every phase we'll ever need to the default axis2.xml? That will
certainly help with making sure they're in the right order! :)
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Paul Fremantle <pz...@gmail.com>.
> Paul, next time just add it and commit!
Committed revision 544308.
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Glen Daniels wrote:
> Working on classpath stuff right now, but a few quick responses to
> points you raise here:
>
> 1) The idea for Modules, for instance, did not come from our users - I
> should know, because (IIRC) I was the first one to mention it back in
> 2002! :) There is a longer conversation here but I most definitely do
> NOT agree (esp in terms of infrastructure software like Axis) that we
That was a different time- we were architecting a new Axis version and OF
COURSE we need to create stuff. We're NOT doing that now. Our users need
stability, not creativity from us, especially when no one has asked for it.
> shouldn't do useful stuff because users haven't asked for it
> specifically. Do you think IDEA would have all the cool refactoring
> that it does today if they'd only implemented stuff that was
> specifically asked for? As the experts in a particular area (Java
> infra development, WS, etc) the developers of a given project are often
> the source of the best ideas for making their software easier and more
> effective to use. It's a balance.
Yes of course I know that. However, there's a time for everything. I'm
happy to say we'll do this for a future version but I'm very concerned
about taking on more changes at this stage given that we've made lots of
changes already. So I'm taking a different view from David on that- just
because we've made all these changes is hardly a reason to make more changes!
Every change needs to be rationalized by what problem it solves. With all
due respect Glen you were checked out of Axis2 development for a long
time. As you know "he who does the work makes the decisions" in open
source and so we are where we are now. I have no objection to fixing
what's broken. I have no problem with us dealing with the 400+ pending
JIRAs *RAISED BY OUR USERS*. I do have a problem with changing things just
because there's a different way to do it. I do have a problem with
creating more grand solutions to problems that are not real problems of
our users. If we didn't have 400+ pending JIRAs and a series of known real
problems I'd feel differently about every new cool feature.
> As for cloning the handler chain, if I'm interpreting you correctly we
> absolutely did need to do that to support consistent processing
> semantics in the face of potential hot-deployments while messages are
> flowing, no?
No, not at all. We DO NOT allow hot deployment of modules and that means
the chain cannot change at runtime. So the feature cannot be affected
unless you have code that dynamically does it. Its possible but no one has
done it yet: YAGNI. I'm not arguing to remove it; I just want a switch to
say turn it off and leave it off by default. If someone wants it they can
ask for it and voila they have it.
> 2) If you want to end up with a monolithic JAR which does RM and
> Security and Addressing and that's it, then fine we can just stop now.
I didn't suggest that; I suggested having mars for both of them but have
them available in the axis2 core as that's what users want. Just observe
the number of questions about "when will rampart be available for axis2
1.2?".
> But I thought we were building a world-class WS-focused processing
> framework that scales from embeddable up through enterprise. If so, we
> need to make it sufficiently robust that it will not need major
> rearchitecting in the future. Also, I personally want it to be dead
WHAT? Are you claiming you won't come up with cool new features in the
future?? No way :). Of course we'll have to keep tweaking it .. people are
still tweaking httpd right?
BTW are you contradicting yourself by saying this is a major rearch? Later
you say "it's not that much code" ..
> simple to engage transactions, or to allow someone's WS-CAF extensions
> to work, or some company-internal extension using headers. New stuff
> is NOT going to stop coming down the pipe. Our stuff will either be
> sufficiently easy to evolve, or it won't.
It works now Glen. Let our *real users* (not the extensions we write;
those that the users write) tell us they need a certain feature and we'll
add it.
> 3) Any time you deploy a *service* you're already allowing user code to
> extend the system runtime. Come to mention it, I could just build my
> own handler framework inside my service implementation, couldn't I?
> Wouldn't that be the same thing? Also, services have access to the
> AxisConfiguration and can muck with it as much as they want.
Yes that last bit is a problem we need to deal with (and we've talked
about it but never did it; its about protection of the system). I am not
for making something that can be done now worse just because it would be
cool to do it. Can you point me to threads on the user list (or a real
customer case you were directly involved with) which has asked for modules
to be deployed in a service? How many blogs have you read which said
"Axis2 is great, but I really wish it was more flexible in blah"?
I feel the same way about service-specific handlers.
I wish the IBM guys were around (they seem to have checked out; they've
gone radio silent and don't see the commits going either). I know one of
the major concerns they had about Axis1 (and one of the reasons they left
it) was exactly this reason: that it allowed arbitrary extensions to be
deployed by users without having the app server have control over such
things.
> Oh, and 4) it's not that much code, and wouldn't break existing stuff.
Sorry, that's NEVER a good reason to do it for a system we're trying to
make into a mature product. What known PROBLEM does it solve? We're
wasting all this time because we're refusing to add *ONE MORE STRING* to
axis2.xml. Paul, next time just add it and commit! (And call the phases
A/B/C/D so that no one can complain.)
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Working on classpath stuff right now, but a few quick responses to
points you raise here:
1) The idea for Modules, for instance, did not come from our users - I
should know, because (IIRC) I was the first one to mention it back in
2002! :) There is a longer conversation here but I most definitely do
NOT agree (esp in terms of infrastructure software like Axis) that we
shouldn't do useful stuff because users haven't asked for it
specifically. Do you think IDEA would have all the cool refactoring
that it does today if they'd only implemented stuff that was
specifically asked for? As the experts in a particular area (Java infra
development, WS, etc) the developers of a given project are often the
source of the best ideas for making their software easier and more
effective to use. It's a balance.
As for cloning the handler chain, if I'm interpreting you correctly we
absolutely did need to do that to support consistent processing
semantics in the face of potential hot-deployments while messages are
flowing, no?
2) If you want to end up with a monolithic JAR which does RM and
Security and Addressing and that's it, then fine we can just stop now.
But I thought we were building a world-class WS-focused processing
framework that scales from embeddable up through enterprise. If so, we
need to make it sufficiently robust that it will not need major
rearchitecting in the future. Also, I personally want it to be dead
simple to engage transactions, or to allow someone's WS-CAF extensions
to work, or some company-internal extension using headers. New stuff is
NOT going to stop coming down the pipe. Our stuff will either be
sufficiently easy to evolve, or it won't.
3) Any time you deploy a *service* you're already allowing user code to
extend the system runtime. Come to mention it, I could just build my
own handler framework inside my service implementation, couldn't I?
Wouldn't that be the same thing? Also, services have access to the
AxisConfiguration and can muck with it as much as they want.
Oh, and 4) it's not that much code, and wouldn't break existing stuff.
More later,
--Glen
Sanjiva Weerawarana wrote:
> Glen Daniels wrote:
>>
>> Hm. While the current system technically works, the old Axis1
>> Phase-less way of deploying ordered Handlers worked too, as long as
>> you were sufficiently careful and correct. :)
>>
>> Modules right now aren't really pluggable components. To use a Module
>> which uses non-standard phases in your service, you need to a) read
>> the Module documentation and understand WHICH phases you need to add
>> to the global configuration, AND in what order (this seems like
>> EXACTLY the kind of stuff we were trying to move from documentation to
>> config/code for Axis2), b) change axis2.xml accordingly, and c) deploy
>> the module globally. That's a pain, and I think it's kind of ironic
>> that it's exactly this kind of configuration we were avoiding for
>> Handlers.
>
> The problem I have with this proposal is that we're trying to come up
> with an automatic solution to a *problem we have*. That is, security and
> RM are really core parts of what we're trying to do. If we had *users*
> saying that our phase insertion architecture is too limited I'd be fully
> convinced but here we have essentially core bits of the WS-* stack folks
> requiring that we insert another string into axis2.xml and the proposed
> solution is a major feature improvement. I'm not convinced by such
> arguments - features need to be coming from users .. not from us. This
> is like the argument for cloning the handler chain; we did it and we
> don't need it at all .. YAGNI.
>
> So, I'm with Deepal in opposing this approach.
>
> Also, I'd even like to reconsider the decision to make Rampart into a
> separate project. As we noticed with the 1.2 release, users need Rampart
> to be available *with* the axis2 releases. Same goes for Sandesha. So if
> those projects are ok I think its best to move them back in as maven
> modules of axis2. Yes I know this is a big change of heart for me but
> I've learnt from the experience that we made a mistake. As a major
> proponent of the split into multiple projects, I admit I was wrong!
>
>> It's like we've gone halfway, and I would really like to go the rest
>> of the way so that Modules can just work together without the
>> intervention of skilled human technicians modifying global
>> configuration files. IMHO the only times you should be REQUIRED to
>> touch config files as an "assembler" of prebuilt components should be
>> to resolve a conflict.
>
> Again, this is a theoretical argument. If there were *users* beating
> down our door saying "dudes, this stuff is so cool but you are killing
> me with this lack of recursiveness for phases" then I'd be convinced.
> When we're trying to do this as a solution to the problem of "can we add
> the RM phase to axis2.xml" I don't accept it.
>
>> (While we're on the subject I also continue to think that we should
>> allow packaging Modules in Service archives - i.e.
>> services/MyService/modules/foo.mar. It's a very analogous situation.)
>
> ARGH! A major -1 for this!
>
> This is COMPLETELY YAGNI and further brings into Axis2 a feature of
> Axis1 which I personally fought to keep out: allowing user code to
> extend the system runtime. Modules are not some random bit of code to
> run- they are system extensions. As such, user services have no business
> extending the system! I opposed adding handlers in services.xml for the
> same reason. I lost that argument but AFAICT we don't have a single
> *user* usecase for that yet. Making that even more functional is not the
> thing we should be putting our time and effort into at this stage.
>
> In any case, we have the ability to have a module and have only one
> service engage it. All our approach forces is that the service runtime
> admin be aware of what modules they're running. That's goodness, not a
> limitation.
>
> Axis2 is *full* of cool features. What Axis2 needs is stability,
> consistency and completion of those features. We don't need more
> features right now (which will likely end up as YAGNI) - let's get what
> we have to work exactly right, wait for users to demand more features
> and *then* add them.
>
>>> May be we can add that for Axis3 (if we are planing to do so :) )
>>
>> Deepal, I would be kind of bummed if we had to do an Axis3. It would
>> mean we didn't get it right in Axis2.
>
> I agree. We've now built pretty much the entire WS-* core platform for
> Axis2 and the architecture is holding up just fine. So I see no reason
> to think we'll need an Axis3.
>
> Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Deepal Jayasinghe <de...@opensource.lk>.
>
> ARGH! A major -1 for this!
>
> This is COMPLETELY YAGNI and further brings into Axis2 a feature of
> Axis1 which I personally fought to keep out: allowing user code to
> extend the system runtime. Modules are not some random bit of code to
> run- they are system extensions. As such, user services have no
> business extending the system! I opposed adding handlers in
> services.xml for the same reason. I lost that argument but AFAICT we
> don't have a single *user* usecase for that yet. Making that even more
> functional is not the thing we should be putting our time and effort
> into at this stage.
Nope you won :) , we do not have handlers in service aar or the
services.xml. We can have handles only in axis2.xml and module.xml
Thanks
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Paul Fremantle <pz...@gmail.com>.
I'm the idiot who suggested fixing the RM problem :-)
Given the choice between re-architecting modules to insert their own
phases - or just adding the RMPhase to the standard phases you can
guess which is my proposal. I vote for the really really simple
option.
[In fact I we don't even need that. We already have OperationInPhase
(for example) where the RM handlers could go. But it would be clearer
or nicer to add the RMPhases into the default XML]
However, as a solution to a general problem, I don't think we need the
ability for modules to insert phases. There is already plenty of scope
for any module writer to add their handlers into the right places
using the existing phases that are hard-coded plus the capabilities to
do partial ordering of handlers that exist today.
I'm -1 on doing a lot of coding to change the handler/phase/module
architecture when the solution to this problem is using a text editor
to add <phase name="RMPhase"/> in about 4 places.
Paul
On 6/4/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> Glen Daniels wrote:
> >
> > Hm. While the current system technically works, the old Axis1
> > Phase-less way of deploying ordered Handlers worked too, as long as you
> > were sufficiently careful and correct. :)
> >
> > Modules right now aren't really pluggable components. To use a Module
> > which uses non-standard phases in your service, you need to a) read the
> > Module documentation and understand WHICH phases you need to add to the
> > global configuration, AND in what order (this seems like EXACTLY the
> > kind of stuff we were trying to move from documentation to config/code
> > for Axis2), b) change axis2.xml accordingly, and c) deploy the module
> > globally. That's a pain, and I think it's kind of ironic that it's
> > exactly this kind of configuration we were avoiding for Handlers.
>
> The problem I have with this proposal is that we're trying to come up with
> an automatic solution to a *problem we have*. That is, security and RM are
> really core parts of what we're trying to do. If we had *users* saying
> that our phase insertion architecture is too limited I'd be fully
> convinced but here we have essentially core bits of the WS-* stack folks
> requiring that we insert another string into axis2.xml and the proposed
> solution is a major feature improvement. I'm not convinced by such
> arguments - features need to be coming from users .. not from us. This is
> like the argument for cloning the handler chain; we did it and we don't
> need it at all .. YAGNI.
>
> So, I'm with Deepal in opposing this approach.
>
> Also, I'd even like to reconsider the decision to make Rampart into a
> separate project. As we noticed with the 1.2 release, users need Rampart
> to be available *with* the axis2 releases. Same goes for Sandesha. So if
> those projects are ok I think its best to move them back in as maven
> modules of axis2. Yes I know this is a big change of heart for me but I've
> learnt from the experience that we made a mistake. As a major proponent of
> the split into multiple projects, I admit I was wrong!
>
> > It's like we've gone halfway, and I would really like to go the rest of
> > the way so that Modules can just work together without the intervention
> > of skilled human technicians modifying global configuration files. IMHO
> > the only times you should be REQUIRED to touch config files as an
> > "assembler" of prebuilt components should be to resolve a conflict.
>
> Again, this is a theoretical argument. If there were *users* beating down
> our door saying "dudes, this stuff is so cool but you are killing me with
> this lack of recursiveness for phases" then I'd be convinced. When we're
> trying to do this as a solution to the problem of "can we add the RM phase
> to axis2.xml" I don't accept it.
>
> > (While we're on the subject I also continue to think that we should
> > allow packaging Modules in Service archives - i.e.
> > services/MyService/modules/foo.mar. It's a very analogous situation.)
>
> ARGH! A major -1 for this!
>
> This is COMPLETELY YAGNI and further brings into Axis2 a feature of Axis1
> which I personally fought to keep out: allowing user code to extend the
> system runtime. Modules are not some random bit of code to run- they are
> system extensions. As such, user services have no business extending the
> system! I opposed adding handlers in services.xml for the same reason. I
> lost that argument but AFAICT we don't have a single *user* usecase for
> that yet. Making that even more functional is not the thing we should be
> putting our time and effort into at this stage.
>
> In any case, we have the ability to have a module and have only one
> service engage it. All our approach forces is that the service runtime
> admin be aware of what modules they're running. That's goodness, not a
> limitation.
>
> Axis2 is *full* of cool features. What Axis2 needs is stability,
> consistency and completion of those features. We don't need more features
> right now (which will likely end up as YAGNI) - let's get what we have to
> work exactly right, wait for users to demand more features and *then* add
> them.
>
> >> May be we can add that for Axis3 (if we are planing to do so :) )
> >
> > Deepal, I would be kind of bummed if we had to do an Axis3. It would
> > mean we didn't get it right in Axis2.
>
> I agree. We've now built pretty much the entire WS-* core platform for
> Axis2 and the architecture is holding up just fine. So I see no reason to
> think we'll need an Axis3.
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Director; Open Source Initiative; http://www.opensource.org/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Glen Daniels wrote:
>
> Hm. While the current system technically works, the old Axis1
> Phase-less way of deploying ordered Handlers worked too, as long as you
> were sufficiently careful and correct. :)
>
> Modules right now aren't really pluggable components. To use a Module
> which uses non-standard phases in your service, you need to a) read the
> Module documentation and understand WHICH phases you need to add to the
> global configuration, AND in what order (this seems like EXACTLY the
> kind of stuff we were trying to move from documentation to config/code
> for Axis2), b) change axis2.xml accordingly, and c) deploy the module
> globally. That's a pain, and I think it's kind of ironic that it's
> exactly this kind of configuration we were avoiding for Handlers.
The problem I have with this proposal is that we're trying to come up with
an automatic solution to a *problem we have*. That is, security and RM are
really core parts of what we're trying to do. If we had *users* saying
that our phase insertion architecture is too limited I'd be fully
convinced but here we have essentially core bits of the WS-* stack folks
requiring that we insert another string into axis2.xml and the proposed
solution is a major feature improvement. I'm not convinced by such
arguments - features need to be coming from users .. not from us. This is
like the argument for cloning the handler chain; we did it and we don't
need it at all .. YAGNI.
So, I'm with Deepal in opposing this approach.
Also, I'd even like to reconsider the decision to make Rampart into a
separate project. As we noticed with the 1.2 release, users need Rampart
to be available *with* the axis2 releases. Same goes for Sandesha. So if
those projects are ok I think its best to move them back in as maven
modules of axis2. Yes I know this is a big change of heart for me but I've
learnt from the experience that we made a mistake. As a major proponent of
the split into multiple projects, I admit I was wrong!
> It's like we've gone halfway, and I would really like to go the rest of
> the way so that Modules can just work together without the intervention
> of skilled human technicians modifying global configuration files. IMHO
> the only times you should be REQUIRED to touch config files as an
> "assembler" of prebuilt components should be to resolve a conflict.
Again, this is a theoretical argument. If there were *users* beating down
our door saying "dudes, this stuff is so cool but you are killing me with
this lack of recursiveness for phases" then I'd be convinced. When we're
trying to do this as a solution to the problem of "can we add the RM phase
to axis2.xml" I don't accept it.
> (While we're on the subject I also continue to think that we should
> allow packaging Modules in Service archives - i.e.
> services/MyService/modules/foo.mar. It's a very analogous situation.)
ARGH! A major -1 for this!
This is COMPLETELY YAGNI and further brings into Axis2 a feature of Axis1
which I personally fought to keep out: allowing user code to extend the
system runtime. Modules are not some random bit of code to run- they are
system extensions. As such, user services have no business extending the
system! I opposed adding handlers in services.xml for the same reason. I
lost that argument but AFAICT we don't have a single *user* usecase for
that yet. Making that even more functional is not the thing we should be
putting our time and effort into at this stage.
In any case, we have the ability to have a module and have only one
service engage it. All our approach forces is that the service runtime
admin be aware of what modules they're running. That's goodness, not a
limitation.
Axis2 is *full* of cool features. What Axis2 needs is stability,
consistency and completion of those features. We don't need more features
right now (which will likely end up as YAGNI) - let's get what we have to
work exactly right, wait for users to demand more features and *then* add
them.
>> May be we can add that for Axis3 (if we are planing to do so :) )
>
> Deepal, I would be kind of bummed if we had to do an Axis3. It would
> mean we didn't get it right in Axis2.
I agree. We've now built pretty much the entire WS-* core platform for
Axis2 and the architecture is holding up just fine. So I see no reason to
think we'll need an Axis3.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by David Illsley <da...@gmail.com>.
> (While we're on the subject I also continue to think that we should
> allow packaging Modules in Service archives - i.e.
> services/MyService/modules/foo.mar. It's a very analogous situation.)
>
> > So I am -1 on this proposal.
>
> I'd like to hear what others think. If I'm the only one advocating
> this, then I'll back off. If there's a lot of support for this idea,
> perhaps we can get you on board with it with some further discussion.
>
> What do others think?
Sounds like a reasonable idea to me. Given many of the other ongoing
changes, I don't think this is a line we cannot or should not cross,
regardless of previous (potentially out of date) discussions.
David
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Davanum Srinivas <da...@gmail.com>.
Glen,
For my sake, could you please post a "[Proposal]"? Please don't make
me read the whole thread :)
thanks,
dims
On 6/4/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Deepal:
>
> > When we start Axis2 we had a long discussing on phase , phase rule and
> > there we finally decided not to allow add phases by modules. If some one
> > want to add a phase then he/she needs to go and add that to axis2.xml.
> > So please do not introduce such features at this moment. As I think
> > Axis2 is a stable product and a number of applications are using Axis2.
> > And none of them requested such a features in the list , so as
> > developers we should not introduce unwanted features . I strongly
> > believe what we have at the moment more than enough to satisfy our goal.
>
> Hm. While the current system technically works, the old Axis1
> Phase-less way of deploying ordered Handlers worked too, as long as you
> were sufficiently careful and correct. :)
>
> Modules right now aren't really pluggable components. To use a Module
> which uses non-standard phases in your service, you need to a) read the
> Module documentation and understand WHICH phases you need to add to the
> global configuration, AND in what order (this seems like EXACTLY the
> kind of stuff we were trying to move from documentation to config/code
> for Axis2), b) change axis2.xml accordingly, and c) deploy the module
> globally. That's a pain, and I think it's kind of ironic that it's
> exactly this kind of configuration we were avoiding for Handlers.
>
> It's like we've gone halfway, and I would really like to go the rest of
> the way so that Modules can just work together without the intervention
> of skilled human technicians modifying global configuration files. IMHO
> the only times you should be REQUIRED to touch config files as an
> "assembler" of prebuilt components should be to resolve a conflict.
>
> (While we're on the subject I also continue to think that we should
> allow packaging Modules in Service archives - i.e.
> services/MyService/modules/foo.mar. It's a very analogous situation.)
>
> > So I am -1 on this proposal.
>
> I'd like to hear what others think. If I'm the only one advocating
> this, then I'll back off. If there's a lot of support for this idea,
> perhaps we can get you on board with it with some further discussion.
>
> What do others think?
>
> > May be we can add that for Axis3 (if we are planing to do so :) )
>
> Deepal, I would be kind of bummed if we had to do an Axis3. It would
> mean we didn't get it right in Axis2.
>
> Thanks,
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Deepal:
> When we start Axis2 we had a long discussing on phase , phase rule and
> there we finally decided not to allow add phases by modules. If some one
> want to add a phase then he/she needs to go and add that to axis2.xml.
> So please do not introduce such features at this moment. As I think
> Axis2 is a stable product and a number of applications are using Axis2.
> And none of them requested such a features in the list , so as
> developers we should not introduce unwanted features . I strongly
> believe what we have at the moment more than enough to satisfy our goal.
Hm. While the current system technically works, the old Axis1
Phase-less way of deploying ordered Handlers worked too, as long as you
were sufficiently careful and correct. :)
Modules right now aren't really pluggable components. To use a Module
which uses non-standard phases in your service, you need to a) read the
Module documentation and understand WHICH phases you need to add to the
global configuration, AND in what order (this seems like EXACTLY the
kind of stuff we were trying to move from documentation to config/code
for Axis2), b) change axis2.xml accordingly, and c) deploy the module
globally. That's a pain, and I think it's kind of ironic that it's
exactly this kind of configuration we were avoiding for Handlers.
It's like we've gone halfway, and I would really like to go the rest of
the way so that Modules can just work together without the intervention
of skilled human technicians modifying global configuration files. IMHO
the only times you should be REQUIRED to touch config files as an
"assembler" of prebuilt components should be to resolve a conflict.
(While we're on the subject I also continue to think that we should
allow packaging Modules in Service archives - i.e.
services/MyService/modules/foo.mar. It's a very analogous situation.)
> So I am -1 on this proposal.
I'd like to hear what others think. If I'm the only one advocating
this, then I'll back off. If there's a lot of support for this idea,
perhaps we can get you on board with it with some further discussion.
What do others think?
> May be we can add that for Axis3 (if we are planing to do so :) )
Deepal, I would be kind of bummed if we had to do an Axis3. It would
mean we didn't get it right in Axis2.
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi Glen
> Hi Amila!
>
> Amila Suriarachchi wrote:
>> <module name="Security">
>> <InFlow>
>> <!-- Add Decrypt phase if not already present. If it's
>> there -->
>> <!-- already, just confirm that it matches these rules (
>> i.e. -->
>> <!-- after
>> Transport) -->
>> <phase name="Decrypt" after="Transport">
>> <handler name="DecryptionHandler" class="..."/>
>> </phase>
>> <handler name="OtherHandler" class="...">
>> <order phase="Dispatch"/>
>> </handler>
>> </InFlow>
>> ...
>> </module>
When we start Axis2 we had a long discussing on phase , phase rule and
there we finally decided not to allow add phases by modules. If some one
want to add a phase then he/she needs to go and add that to axis2.xml.
So please do not introduce such features at this moment. As I think
Axis2 is a stable product and a number of applications are using Axis2.
And none of them requested such a features in the list , so as
developers we should not introduce unwanted features . I strongly
believe what we have at the moment more than enough to satisfy our goal.
So I am -1 on this proposal.
May be we can add that for Axis3 (if we are planing to do so :) )
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Amila Suriarachchi wrote:
>
>
> On 6/2/07, *Glen Daniels* <glen@thoughtcraft.com
> <ma...@thoughtcraft.com>> wrote:
>
> Hi Amila!
>
> Amila Suriarachchi wrote:
> > <module name="Security">
> > <InFlow>
> > <!-- Add Decrypt phase if not already present. If it's
> there -->
> > <!-- already, just confirm that it matches these rules
> ( i.e. -->
> > <!-- after
> Transport) -->
> > <phase name="Decrypt" after="Transport">
> > <handler name="DecryptionHandler" class="..."/>
> > </phase>
> > <handler name="OtherHandler" class="...">
> > <order phase="Dispatch"/>
> > </handler>
> > </InFlow>
> > ...
> > </module>
> >
> >
> > I am not sure the practical limitations of doing this but,
> > +1 for adding Phases in InFlow and OutFlow and placing them
> using the
> > phase order rules like
> > in handlers. I belive this would allow us to develop modules as real
> > pluggable components.
>
> This is relatively easy to do (I've already written the code
> once), and
> I agree 100% this is what is needed to make Modules sufficiently...
> well, modular. :) This was absolutely the design center that I had in
> mind even from the outset of the Axis2 discussions.
>
> Essentially you have a list of Constraints - a Constraint is like "A
> must come before B" or "A must be in Phase Q". Whenever you deploy a
> thing (Handler or Phase) with Constraints, you check its Constraints
> against the current state of the ExecutionChain. If everything is
> either satisfied or "open" (we'll come back to this in a sec) then
> that
> deployment was successful. "Open" means that one of the referents of
> the Constraint didn't exist at the time - so for instance if we're
> deploying "A" and it says "A before B" but there's no "B" yet, we can
> put A in and it works.
>
>
> As I understood We have set of phases order of which determines by the
> phase rules (eg. before, after) and within a phase we have set of
> handlers . Agian order of the handlers within the phase is determined
> by the handler rules. (eg. before, after).
Amila , I am sorry I could not able to find the mail archives , but I
100% sure we discussed all those when we were finalizing phase and
phase rules.
Thanks
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Jaliya Ekanayake <jn...@gmail.com>.
----- Original Message -----
From: "Ajith Ranabahu" <aj...@gmail.com>
To: <ax...@ws.apache.org>
Sent: Sunday, June 03, 2007 3:23 PM
Subject: Re: [axis2] More Modules and classpaths
> Hi,
>>
>> We want to allow people to express constraints on things that may or may
>> not be deployed yet, because that enables constellations of related
>> Modules to be developed without requiring that they all be deployed at
>> once.
>>
>
> May be we can add a flag 'skipUnknownPhases' (as an attribute with
> either true or false values) to the phase rule and make it explicit
> and obvious ?
IMHO these will yield to more "confused" users.
-jaliya
> --
> Ajith Ranabahu
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi,
>
> We want to allow people to express constraints on things that may or may
> not be deployed yet, because that enables constellations of related
> Modules to be developed without requiring that they all be deployed at once.
>
May be we can add a flag 'skipUnknownPhases' (as an attribute with
either true or false values) to the phase rule and make it explicit
and obvious ?
--
Ajith Ranabahu
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Amila!
Amila Suriarachchi wrote:
> As I understood We have set of phases order of which determines by the
> phase rules (eg. before, after) and within a phase we have set of
> handlers . Agian order of the handlers within the phase is determined by
> the handler rules. (eg. before, after).
Right.
> So lets say we have a phase rule like this,
> <phase name="Decrypt" after="WrongPhaseName">
> <handler name="DecryptionHandler" class="..."/>
> </phase>
>
> if the WrongPhaseName phase does not exists why shouldn't it throw an
> exception?
> Later some one may or may not deploy a phase as given. we can not sure.
Exactly - the trick is we should *remember* the constraint that
"Decrypt" must come after "WrongPhaseName". I think this deployment
should work fine, with no Exception. If no one ever deploys
WrongPhaseName, no problem. But if someone DOES deploy it, we notice
the open constraint, and we need to make sure WrongPhaseName gets
inserted before "Decrypt" - otherwise at that time there IS an Exception
(if another constraint would have forced WrongPhaseName to be after
Decrypt).
We want to allow people to express constraints on things that may or may
not be deployed yet, because that enables constellations of related
Modules to be developed without requiring that they all be deployed at once.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Amila Suriarachchi <am...@gmail.com>.
On 6/2/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
>
> Hi Amila!
>
> Amila Suriarachchi wrote:
> > <module name="Security">
> > <InFlow>
> > <!-- Add Decrypt phase if not already present. If it's there
> -->
> > <!-- already, just confirm that it matches these rules ( i.e
> . -->
> > <!-- after Transport)
> -->
> > <phase name="Decrypt" after="Transport">
> > <handler name="DecryptionHandler" class="..."/>
> > </phase>
> > <handler name="OtherHandler" class="...">
> > <order phase="Dispatch"/>
> > </handler>
> > </InFlow>
> > ...
> > </module>
> >
> >
> > I am not sure the practical limitations of doing this but,
> > +1 for adding Phases in InFlow and OutFlow and placing them using the
> > phase order rules like
> > in handlers. I belive this would allow us to develop modules as real
> > pluggable components.
>
> This is relatively easy to do (I've already written the code once), and
> I agree 100% this is what is needed to make Modules sufficiently...
> well, modular. :) This was absolutely the design center that I had in
> mind even from the outset of the Axis2 discussions.
>
> Essentially you have a list of Constraints - a Constraint is like "A
> must come before B" or "A must be in Phase Q". Whenever you deploy a
> thing (Handler or Phase) with Constraints, you check its Constraints
> against the current state of the ExecutionChain. If everything is
> either satisfied or "open" (we'll come back to this in a sec) then that
> deployment was successful. "Open" means that one of the referents of
> the Constraint didn't exist at the time - so for instance if we're
> deploying "A" and it says "A before B" but there's no "B" yet, we can
> put A in and it works.
As I understood We have set of phases order of which determines by the phase
rules (eg. before, after) and within a phase we have set of handlers .
Agian order of the handlers within the phase is determined by the handler
rules. (eg. before, after).
So lets say we have a phase rule like this,
<phase name="Decrypt" after="WrongPhaseName">
<handler name="DecryptionHandler" class="..."/>
</phase>
if the WrongPhaseName phase does not exists why shouldn't it throw an
exception?
Later some one may or may not deploy a phase as given. we can not sure.
Then later if we deploy "B", there is a check at
> that time for any open Constraints involving B. If we find one that
> says "A before B" we'll know we have to satisfy that as well as whatever
> B's native Constraints are in order to succeed.
>
> This process isn't that computationally expensive, since our
> handler/phase chains aren't ever going to be that long (I would guess it
> will be VERY rare to see even a 20-Handler chain, let alone hundreds)
> and the code can be written quite efficiently.
>
> I also believe this will result in cleaner and more comprehensible
> Handler-wrangling code.
>
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [axis2] More Modules and classpaths
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Amila!
Amila Suriarachchi wrote:
> <module name="Security">
> <InFlow>
> <!-- Add Decrypt phase if not already present. If it's there -->
> <!-- already, just confirm that it matches these rules ( i.e. -->
> <!-- after Transport) -->
> <phase name="Decrypt" after="Transport">
> <handler name="DecryptionHandler" class="..."/>
> </phase>
> <handler name="OtherHandler" class="...">
> <order phase="Dispatch"/>
> </handler>
> </InFlow>
> ...
> </module>
>
>
> I am not sure the practical limitations of doing this but,
> +1 for adding Phases in InFlow and OutFlow and placing them using the
> phase order rules like
> in handlers. I belive this would allow us to develop modules as real
> pluggable components.
This is relatively easy to do (I've already written the code once), and
I agree 100% this is what is needed to make Modules sufficiently...
well, modular. :) This was absolutely the design center that I had in
mind even from the outset of the Axis2 discussions.
Essentially you have a list of Constraints - a Constraint is like "A
must come before B" or "A must be in Phase Q". Whenever you deploy a
thing (Handler or Phase) with Constraints, you check its Constraints
against the current state of the ExecutionChain. If everything is
either satisfied or "open" (we'll come back to this in a sec) then that
deployment was successful. "Open" means that one of the referents of
the Constraint didn't exist at the time - so for instance if we're
deploying "A" and it says "A before B" but there's no "B" yet, we can
put A in and it works. Then later if we deploy "B", there is a check at
that time for any open Constraints involving B. If we find one that
says "A before B" we'll know we have to satisfy that as well as whatever
B's native Constraints are in order to succeed.
This process isn't that computationally expensive, since our
handler/phase chains aren't ever going to be that long (I would guess it
will be VERY rare to see even a 20-Handler chain, let alone hundreds)
and the code can be written quite efficiently.
I also believe this will result in cleaner and more comprehensible
Handler-wrangling code.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Amila Suriarachchi <am...@gmail.com>.
On 6/1/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
>
> Hi folks!
>
> Deepal Jayasinghe wrote:
> > Paul Fremantle wrote:
> >> Yes that wasn't the behaviour I was expecting!
>
> Me neither, and I think the current way of doing things is both
> unexpected and potentially dangerous. Consider this:
>
> CLASSPATH=/dev/axis2.jar;/otherStuff
>
> where we have
>
> /dev
> axis2.jar
> unused-module.mar
>
> The normal expectation here is that the user gets exactly what she puts
> on the classpath - axis2.jar IS on the classpath, so of course classes
> from that JAR will be loaded. The mar file in /dev, however, is NOT in
> fact on the classpath, and in this case the user has dropped an unused
> (perhaps experimental) mar file in their development directory. With
> our current code, all of a sudden that module is active in the Axis2
> installation, which seems very inappropriate to me. Also, what if the
> user WANTS a module on the classpath, but doesn't have write access to
> the directory where axis2.jar lives?
>
> Java classpath management is tricky enough already without suddenly
> loading classes from places that the user did NOT specify just because
> Axis2 decided that "parallel" mars are now fair game. Had I noticed
> this behavior when it went in, I'm pretty sure I'd have -1'ed it at the
> time.
>
> I would much rather see us respecting explicit additions of modules to
> the classpath, which lets them live anywhere the user wants to put them,
> than continue the current behavior.
>
> >> The idea of putting modules in the classpath was motivated by the
> >> following scenario:
> >>
> >> I have a client, I don't want to set up a "repository" because I'm
> >> just deploying this client somewhere on someone's filesystem, so I
> >> can't point to a modules directory easily. So I can just stick
> >> addressing.mar into the client classpath to enable addressing.
> > Yes , agreed.
>
> Hm, the scenario Paul is talking about is exactly what I want to do...
> have you changed your mind? :)
>
> >> However, this only works in the case where the modules don't require
> >> changes to the Axis2.conf. Unfortunately, the Sandesha2 module
> >> requires the axis2.conf to have some phases added. Now personally, I
> >> think it might make sense to add the RM phases into the default
> >> Axis2.conf, but nonetheless, maybe we should also address how to make
> >> it easy to supply an axis2.conf as well that replaces the inbuilt one.
> > +1 for adding RM and Security related phases into axis2.xml
>
> -1 to adding RM phases into axis2.xml. (Don't we already have a
> "Security" phase in there, though?)
>
> +1 for allowing module configurations to add Phases as easily as they
> add Handlers, which neatly solves this problem.
>
> <module name="Security">
> <InFlow>
> <!-- Add Decrypt phase if not already present. If it's there -->
> <!-- already, just confirm that it matches these rules (i.e. -->
> <!-- after Transport) -->
> <phase name="Decrypt" after="Transport">
> <handler name="DecryptionHandler" class="..."/>
> </phase>
> <handler name="OtherHandler" class="...">
> <order phase="Dispatch"/>
> </handler>
> </InFlow>
> ...
> </module>
I am not sure the practical limitations of doing this but,
+1 for adding Phases in InFlow and OutFlow and placing them using the phase
order rules like
in handlers. I belive this would allow us to develop modules as real
pluggable components.
thanks,
Amila.
Cheers,
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [axis2] More Modules and classpaths
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi folks!
Deepal Jayasinghe wrote:
> Paul Fremantle wrote:
>> Yes that wasn't the behaviour I was expecting!
Me neither, and I think the current way of doing things is both
unexpected and potentially dangerous. Consider this:
CLASSPATH=/dev/axis2.jar;/otherStuff
where we have
/dev
axis2.jar
unused-module.mar
The normal expectation here is that the user gets exactly what she puts
on the classpath - axis2.jar IS on the classpath, so of course classes
from that JAR will be loaded. The mar file in /dev, however, is NOT in
fact on the classpath, and in this case the user has dropped an unused
(perhaps experimental) mar file in their development directory. With
our current code, all of a sudden that module is active in the Axis2
installation, which seems very inappropriate to me. Also, what if the
user WANTS a module on the classpath, but doesn't have write access to
the directory where axis2.jar lives?
Java classpath management is tricky enough already without suddenly
loading classes from places that the user did NOT specify just because
Axis2 decided that "parallel" mars are now fair game. Had I noticed
this behavior when it went in, I'm pretty sure I'd have -1'ed it at the
time.
I would much rather see us respecting explicit additions of modules to
the classpath, which lets them live anywhere the user wants to put them,
than continue the current behavior.
>> The idea of putting modules in the classpath was motivated by the
>> following scenario:
>>
>> I have a client, I don't want to set up a "repository" because I'm
>> just deploying this client somewhere on someone's filesystem, so I
>> can't point to a modules directory easily. So I can just stick
>> addressing.mar into the client classpath to enable addressing.
> Yes , agreed.
Hm, the scenario Paul is talking about is exactly what I want to do...
have you changed your mind? :)
>> However, this only works in the case where the modules don't require
>> changes to the Axis2.conf. Unfortunately, the Sandesha2 module
>> requires the axis2.conf to have some phases added. Now personally, I
>> think it might make sense to add the RM phases into the default
>> Axis2.conf, but nonetheless, maybe we should also address how to make
>> it easy to supply an axis2.conf as well that replaces the inbuilt one.
> +1 for adding RM and Security related phases into axis2.xml
-1 to adding RM phases into axis2.xml. (Don't we already have a
"Security" phase in there, though?)
+1 for allowing module configurations to add Phases as easily as they
add Handlers, which neatly solves this problem.
<module name="Security">
<InFlow>
<!-- Add Decrypt phase if not already present. If it's there -->
<!-- already, just confirm that it matches these rules (i.e. -->
<!-- after Transport) -->
<phase name="Decrypt" after="Transport">
<handler name="DecryptionHandler" class="..."/>
</phase>
<handler name="OtherHandler" class="...">
<order phase="Dispatch"/>
</handler>
</InFlow>
...
</module>
Cheers,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Paul Fremantle wrote:
> Yes that wasn't the behaviour I was expecting!
>
> The idea of putting modules in the classpath was motivated by the
> following scenario:
>
> I have a client, I don't want to set up a "repository" because I'm
> just deploying this client somewhere on someone's filesystem, so I
> can't point to a modules directory easily. So I can just stick
> addressing.mar into the client classpath to enable addressing.
Yes , agreed.
>
> However, this only works in the case where the modules don't require
> changes to the Axis2.conf. Unfortunately, the Sandesha2 module
> requires the axis2.conf to have some phases added. Now personally, I
> think it might make sense to add the RM phases into the default
> Axis2.conf, but nonetheless, maybe we should also address how to make
> it easy to supply an axis2.conf as well that replaces the inbuilt one.
+1 for adding RM and Security related phases into axis2.xml
Thanks
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Paul Fremantle <pz...@gmail.com>.
Yes that wasn't the behaviour I was expecting!
The idea of putting modules in the classpath was motivated by the
following scenario:
I have a client, I don't want to set up a "repository" because I'm
just deploying this client somewhere on someone's filesystem, so I
can't point to a modules directory easily. So I can just stick
addressing.mar into the client classpath to enable addressing.
However, this only works in the case where the modules don't require
changes to the Axis2.conf. Unfortunately, the Sandesha2 module
requires the axis2.conf to have some phases added. Now personally, I
think it might make sense to add the RM phases into the default
Axis2.conf, but nonetheless, maybe we should also address how to make
it easy to supply an axis2.conf as well that replaces the inbuilt one.
Paul
On 6/1/07, David Illsley <da...@gmail.com> wrote:
> Deepal, I took a look at that page and my understanding of what Glen
> is going to do is support modules anywhere on the classpath, not just
> when they are in the same directory as the other axis2 jars.
>
> I personally think, having read that page, that we doi't currently
> support loading modules from the classpath, rather we support loading
> modules from the same directory as axis2 jars on the classpath. I
> think this is an important distinction and one that I'd guess has been
> confusing to users (I know it surprised me just now).
> David
>
> On 01/06/07, Deepal Jayasinghe <de...@opensource.lk> wrote:
> > Hi Glen,
> >
> > I implemented that feature more than a year ago and it work perfectly
> > you do not need to do anything. please have a look at the following faq
> > as well.
> >
> > http://wso2.org/library/182
> >
> > Thanks
> > Deepal
> >
> > Glen Daniels wrote:
> > > I'd like to be able to deploy a Module by just putting it on the
> > > classpath...
> > >
> > > CLASSPATH=...; addressing.mar; ...
> > >
> > > This is pretty easy to implement, seems highly convenient, and goes
> > > along with some other deployment-related stuff I'm thinking about, but
> > > I wanted to run it past folks first. It would work with either
> > > exploded module directories or mars.
> > >
> > > Can I get a +1?
> > >
> > > --Glen
> > >
> > > P.S. This does not work at present, although we do some weird
> > > classpath-related stuff - a future message will analyze and critique
> > > said stuff.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> > >
> >
> > --
> > Thanks,
> > Deepal
> > ................................................................
> > "The highest tower is built one brick at a time"
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> David Illsley - IBM Web Services Development
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Glen Daniels <gl...@thoughtcraft.com>.
+1. I already built this locally and it works a treat.
Note that this would also allow easier maven dependency management -
i.e. if one maven module (integration say) depended on a "mar" module,
that mar would automatically get added to the classpath and the
(Axis2)Module would be accessible to the (Maven)module without manually
copying mar files into multiple test repositories, etc.
--G
Davanum Srinivas wrote:
> Enumeration enumeration =
> URLClassLoader.findResource("META-INF/modules.xml");
>
> On 6/4/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>> How exactly are you proposing to discover modules on the classpath?
>>
>> Sanjiva.
>>
>> Glen Daniels wrote:
>> > Catching up on other msgs in this thread:
>> >
>> > David Illsley wrote:
>> >> But surely you're still resolving that issue now... what if there's a
>> >> copy on the classpath in the same directory as an axis2 jar and a copy
>> >> in the modules directory?
>> >
>> > +1. All we need here is a clear precedence mechanism, just like
>> > classpaths in general. IMO, we should be using the contents of the
>> > modules/ directory FIRST, and THEN looking on the classpath for
>> modules.
>> > For a given module, if you already have a module of that name loaded,
>> > you log a WARNING about it and continue without loading it again.
>> Since
>> > we have isolation for Modules, we just need to make sure that each
>> > AxisModule object is correctly initialized with the appropriate
>> > ClassLoader, and we should be all set.
>> >
>> > Incidentally, I believe we also should have an option to turn off
>> > loading modules from the classpath (although I do think it should
>> > default to on).
>> >
>> > --Glen
>> >
>> >> On 01/06/07, Deepal Jayasinghe <de...@opensource.lk> wrote:
>> >>> hi David
>> >>> > Deepal, I took a look at that page and my understanding of what
>> Glen
>> >>> > is going to do is support modules anywhere on the classpath, not
>> just
>> >>> > when they are in the same directory as the other axis2 jars.
>> >>> Initially we had that way , but when we have both the ways (class
>> path +
>> >>> modules directory) I faced conflicting situation. Say for an
>> instance
>> >>> we have module in class path and we have a new module in the module
>> >>> directory , there I had issues of which one to use. Therefore I
>> think if
>> >>> some one can create a configuration context from a file system
>> then he
>> >>> can definitely put his modules into modules directory and then
>> create
>> >>> the configuration context. As I can see loading modules from class
>> path
>> >>> is really useful in the client side not in the server side.
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> >>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: axis-dev-help@ws.apache.org
>> >
>> >
>>
>> --
>> Sanjiva Weerawarana, Ph.D.
>> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>> Director; Open Source Initiative; http://www.opensource.org/
>> Member; Apache Software Foundation; http://www.apache.org/
>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Davanum Srinivas <da...@gmail.com>.
Enumeration enumeration = URLClassLoader.findResource("META-INF/modules.xml");
On 6/4/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> How exactly are you proposing to discover modules on the classpath?
>
> Sanjiva.
>
> Glen Daniels wrote:
> > Catching up on other msgs in this thread:
> >
> > David Illsley wrote:
> >> But surely you're still resolving that issue now... what if there's a
> >> copy on the classpath in the same directory as an axis2 jar and a copy
> >> in the modules directory?
> >
> > +1. All we need here is a clear precedence mechanism, just like
> > classpaths in general. IMO, we should be using the contents of the
> > modules/ directory FIRST, and THEN looking on the classpath for modules.
> > For a given module, if you already have a module of that name loaded,
> > you log a WARNING about it and continue without loading it again. Since
> > we have isolation for Modules, we just need to make sure that each
> > AxisModule object is correctly initialized with the appropriate
> > ClassLoader, and we should be all set.
> >
> > Incidentally, I believe we also should have an option to turn off
> > loading modules from the classpath (although I do think it should
> > default to on).
> >
> > --Glen
> >
> >> On 01/06/07, Deepal Jayasinghe <de...@opensource.lk> wrote:
> >>> hi David
> >>> > Deepal, I took a look at that page and my understanding of what Glen
> >>> > is going to do is support modules anywhere on the classpath, not just
> >>> > when they are in the same directory as the other axis2 jars.
> >>> Initially we had that way , but when we have both the ways (class path +
> >>> modules directory) I faced conflicting situation. Say for an instance
> >>> we have module in class path and we have a new module in the module
> >>> directory , there I had issues of which one to use. Therefore I think if
> >>> some one can create a configuration context from a file system then he
> >>> can definitely put his modules into modules directory and then create
> >>> the configuration context. As I can see loading modules from class path
> >>> is really useful in the client side not in the server side.
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: axis-dev-help@ws.apache.org
> >>>
> >>>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Director; Open Source Initiative; http://www.opensource.org/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
How exactly are you proposing to discover modules on the classpath?
Sanjiva.
Glen Daniels wrote:
> Catching up on other msgs in this thread:
>
> David Illsley wrote:
>> But surely you're still resolving that issue now... what if there's a
>> copy on the classpath in the same directory as an axis2 jar and a copy
>> in the modules directory?
>
> +1. All we need here is a clear precedence mechanism, just like
> classpaths in general. IMO, we should be using the contents of the
> modules/ directory FIRST, and THEN looking on the classpath for modules.
> For a given module, if you already have a module of that name loaded,
> you log a WARNING about it and continue without loading it again. Since
> we have isolation for Modules, we just need to make sure that each
> AxisModule object is correctly initialized with the appropriate
> ClassLoader, and we should be all set.
>
> Incidentally, I believe we also should have an option to turn off
> loading modules from the classpath (although I do think it should
> default to on).
>
> --Glen
>
>> On 01/06/07, Deepal Jayasinghe <de...@opensource.lk> wrote:
>>> hi David
>>> > Deepal, I took a look at that page and my understanding of what Glen
>>> > is going to do is support modules anywhere on the classpath, not just
>>> > when they are in the same directory as the other axis2 jars.
>>> Initially we had that way , but when we have both the ways (class path +
>>> modules directory) I faced conflicting situation. Say for an instance
>>> we have module in class path and we have a new module in the module
>>> directory , there I had issues of which one to use. Therefore I think if
>>> some one can create a configuration context from a file system then he
>>> can definitely put his modules into modules directory and then create
>>> the configuration context. As I can see loading modules from class path
>>> is really useful in the client side not in the server side.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Glen Daniels wrote:
> Catching up on other msgs in this thread:
>
> David Illsley wrote:
>> But surely you're still resolving that issue now... what if there's a
>> copy on the classpath in the same directory as an axis2 jar and a copy
>> in the modules directory?
No David we are not loading the both , what we are doing is
- If someone create a ConfigurationContext without giving repository
location then only we load modules from the class path
- If he/she gives us a repo location then we do not load modules from
the class path
So there want be any conflicts.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Catching up on other msgs in this thread:
David Illsley wrote:
> But surely you're still resolving that issue now... what if there's a
> copy on the classpath in the same directory as an axis2 jar and a copy
> in the modules directory?
+1. All we need here is a clear precedence mechanism, just like
classpaths in general. IMO, we should be using the contents of the
modules/ directory FIRST, and THEN looking on the classpath for modules.
For a given module, if you already have a module of that name loaded,
you log a WARNING about it and continue without loading it again. Since
we have isolation for Modules, we just need to make sure that each
AxisModule object is correctly initialized with the appropriate
ClassLoader, and we should be all set.
Incidentally, I believe we also should have an option to turn off
loading modules from the classpath (although I do think it should
default to on).
--Glen
> On 01/06/07, Deepal Jayasinghe <de...@opensource.lk> wrote:
>> hi David
>> > Deepal, I took a look at that page and my understanding of what Glen
>> > is going to do is support modules anywhere on the classpath, not just
>> > when they are in the same directory as the other axis2 jars.
>> Initially we had that way , but when we have both the ways (class path +
>> modules directory) I faced conflicting situation. Say for an instance
>> we have module in class path and we have a new module in the module
>> directory , there I had issues of which one to use. Therefore I think if
>> some one can create a configuration context from a file system then he
>> can definitely put his modules into modules directory and then create
>> the configuration context. As I can see loading modules from class path
>> is really useful in the client side not in the server side.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by David Illsley <da...@gmail.com>.
But surely you're still resolving that issue now... what if there's a
copy on the classpath in the same directory as an axis2 jar and a copy
in the modules directory?
David
On 01/06/07, Deepal Jayasinghe <de...@opensource.lk> wrote:
> hi David
> > Deepal, I took a look at that page and my understanding of what Glen
> > is going to do is support modules anywhere on the classpath, not just
> > when they are in the same directory as the other axis2 jars.
> Initially we had that way , but when we have both the ways (class path +
> modules directory) I faced conflicting situation. Say for an instance
> we have module in class path and we have a new module in the module
> directory , there I had issues of which one to use. Therefore I think if
> some one can create a configuration context from a file system then he
> can definitely put his modules into modules directory and then create
> the configuration context. As I can see loading modules from class path
> is really useful in the client side not in the server side.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Deepal Jayasinghe <de...@opensource.lk>.
hi David
> Deepal, I took a look at that page and my understanding of what Glen
> is going to do is support modules anywhere on the classpath, not just
> when they are in the same directory as the other axis2 jars.
Initially we had that way , but when we have both the ways (class path +
modules directory) I faced conflicting situation. Say for an instance
we have module in class path and we have a new module in the module
directory , there I had issues of which one to use. Therefore I think if
some one can create a configuration context from a file system then he
can definitely put his modules into modules directory and then create
the configuration context. As I can see loading modules from class path
is really useful in the client side not in the server side.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by David Illsley <da...@gmail.com>.
Deepal, I took a look at that page and my understanding of what Glen
is going to do is support modules anywhere on the classpath, not just
when they are in the same directory as the other axis2 jars.
I personally think, having read that page, that we doi't currently
support loading modules from the classpath, rather we support loading
modules from the same directory as axis2 jars on the classpath. I
think this is an important distinction and one that I'd guess has been
confusing to users (I know it surprised me just now).
David
On 01/06/07, Deepal Jayasinghe <de...@opensource.lk> wrote:
> Hi Glen,
>
> I implemented that feature more than a year ago and it work perfectly
> you do not need to do anything. please have a look at the following faq
> as well.
>
> http://wso2.org/library/182
>
> Thanks
> Deepal
>
> Glen Daniels wrote:
> > I'd like to be able to deploy a Module by just putting it on the
> > classpath...
> >
> > CLASSPATH=...; addressing.mar; ...
> >
> > This is pretty easy to implement, seems highly convenient, and goes
> > along with some other deployment-related stuff I'm thinking about, but
> > I wanted to run it past folks first. It would work with either
> > exploded module directories or mars.
> >
> > Can I get a +1?
> >
> > --Glen
> >
> > P.S. This does not work at present, although we do some weird
> > classpath-related stuff - a future message will analyze and critique
> > said stuff.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
> >
>
> --
> Thanks,
> Deepal
> ................................................................
> "The highest tower is built one brick at a time"
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] More Modules and classpaths
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi Glen,
I implemented that feature more than a year ago and it work perfectly
you do not need to do anything. please have a look at the following faq
as well.
http://wso2.org/library/182
Thanks
Deepal
Glen Daniels wrote:
> I'd like to be able to deploy a Module by just putting it on the
> classpath...
>
> CLASSPATH=...; addressing.mar; ...
>
> This is pretty easy to implement, seems highly convenient, and goes
> along with some other deployment-related stuff I'm thinking about, but
> I wanted to run it past folks first. It would work with either
> exploded module directories or mars.
>
> Can I get a +1?
>
> --Glen
>
> P.S. This does not work at present, although we do some weird
> classpath-related stuff - a future message will analyze and critique
> said stuff.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
--
Thanks,
Deepal
................................................................
"The highest tower is built one brick at a time"
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org