You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2003/02/21 22:47:29 UTC
[release plan] ECM and dependencies
Hi all,
sort-of "went through" ECM and dependencies. They look sort-of okay,
except for instrumentation doc, which has some big "TODO" holes. I'm not
too thrilled with the amount of docs for these packages but I don't
think anyone actually cares for either reading or writing them so I
don't feel like spending a lot of time thinking about that; it's not a
showstopper for release if you ask me.
what we need now is documentation of all changes since the previous
release (which was a long time ago ;), version number upping, and then
some good ol' regression testing to see we haven't broken anything. I
suggest Berin cuts an RC of ECM and friends as soon as framework is
released, and cocooners and ECM users spend some time testing those. And
I hope to get some gump runs working :/
Besides fixing the weird doc generation problem (if you gen docs for one
project, all other docs you gen after that for other cocoon projects
actually turn out to be the docs of that first project; I guess I broke
that yesterday) and any broken links, we need to figure out how we want
to do build our distributions. We could go for jar-only releases for
stuff like i18n (which is just two classes, after all), otherwise the
buildfiles need some updating. It's a bit difficult to ship a
../depchecker.xml :D
Last big issue is with altrmi. We can either break our no-alpha-jars
policy and ship v0.9.1 (which works quite well, mind you :D), or we can
not ship the altrmi classes in instrument-manager and essentially have
useless instrumentation packages. Or, perhaps altrmi is ripe for 1.0.
I can find arguments pro and con for all options; I'm not sure which is
best.
Finally, this is our "last chance" to move the instrument package into
org.apache.avalon.framework space, if we want to do that. Last time we
talked about it we didn't want to IIRC. Anything changed? From the
perspective of the instrument package, it makes sense.
I don't plan to be behind my computer again till monday, so have a nice
weekend :D
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Change Strategy (was Re: [VOTE] Instrument package into Framework
namespace)
Posted by Leo Simons <le...@apache.org>.
Noel J. Bergman wrote:
> If you want an example, fine, but the specifics aren't as important as the
> approach. One example of classes that are either removed or intended to be
> removed are the file repositories that Peter Donald (surname to qualify the
> overloaded reference) asked James to pull into our module because they
> weren't (and wouldn't be) supported by Avalon. As an instance, it is no big
> deal. We're happy to support them. As a philosophy, it points to caution
> that you had better be prepared to support things before you make them part
> of your release.
Noel,
policywise, these classes (in cornerstone) are unreleased alpha code. So
the example is flawed (then again, almost all examples are contrived by
definition ;).
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Change Strategy (was Re: [VOTE] Instrument package into Framework namespace)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Berin,
You asked for comments on change strategy. I wasn't addressing a particular
case, e.g., Instrument packaging, in my reply to you. I was giving a broad
overview of thoughts on what is and is not OK to do.
If you want an example, fine, but the specifics aren't as important as the
approach. One example of classes that are either removed or intended to be
removed are the file repositories that Peter Donald (surname to qualify the
overloaded reference) asked James to pull into our module because they
weren't (and wouldn't be) supported by Avalon. As an instance, it is no big
deal. We're happy to support them. As a philosophy, it points to caution
that you had better be prepared to support things before you make them part
of your release.
Likewise, I wasn't saying that you wouldn't properly handle migrating from
an Avalon package to a Commons package. I was just outlining some issues
related to a Change Strategy, as you had asked.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Change Strategy (was Re: [VOTE] Instrument package into Framework
namespace)
Posted by Berin Loritsch <bl...@apache.org>.
Noel J. Bergman wrote:
>>Please enlighten me how we can manage the balance
>>between too much change and stagnation.
>
>
> My $0.02 (you can lookup the exchange rate if you care ;-)) is that
> interfaces do not change in incompatible ways within a major release number.
> It is OK to add, but not to change or remove. And Avalon must be careful
> about things that it adds if Avalon isn't sure that they are going to stay.
> I will accept change in nightly builds, but once the Community votes to
> release the class, it'd better be prepared to support it long term.
This particular vote was to add. We finally decided against it though.
>>>From that perspective, Avalon has both changed interfaces (the infamous
> Component issue), and entire sets of classes are either removed or under
> discussion. Those should have required a major version rev, and a supported
> branch using the older interfaces.
The Component is still supported--just deprecated. Which classes are
removed? I am not aware of a case for this.
> What percentage of developers using Avalon do you believe follow discussions
> here? Avalon can't just take a local vote to remove things that people may
> depend upon.
Well we weren't voting to remove anything in this instance.
> Now, let's consider something like replacing an Avalon package with a
> Commons package. That could be viewed as a good thing to do. The way to do
> it would be to deprecate the existing classes with comments telling us what
> the specific code is that replaces the deprecated code. And the deprecated
> classes could be rewritten as a wrapper around the new package.
>
So far, we have done this. We will continue to do this as we move
forward and remove support for a large number of utility libraries that
need a new home.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Change Strategy (was Re: [VOTE] Instrument package into Framework namespace)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Please enlighten me how we can manage the balance
> between too much change and stagnation.
My $0.02 (you can lookup the exchange rate if you care ;-)) is that
interfaces do not change in incompatible ways within a major release number.
It is OK to add, but not to change or remove. And Avalon must be careful
about things that it adds if Avalon isn't sure that they are going to stay.
I will accept change in nightly builds, but once the Community votes to
release the class, it'd better be prepared to support it long term.
>From that perspective, Avalon has both changed interfaces (the infamous
Component issue), and entire sets of classes are either removed or under
discussion. Those should have required a major version rev, and a supported
branch using the older interfaces.
What percentage of developers using Avalon do you believe follow discussions
here? Avalon can't just take a local vote to remove things that people may
depend upon.
Now, let's consider something like replacing an Avalon package with a
Commons package. That could be viewed as a good thing to do. The way to do
it would be to deprecate the existing classes with comments telling us what
the specific code is that replaces the deprecated code. And the deprecated
classes could be rewritten as a wrapper around the new package.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Change Strategy (was Re: [VOTE] Instrument package into Framework
namespace)
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
> Leo Simons wrote:
>
>> Leo Sutic wrote:
>>
>>> 1. The interfaces from the instrument package should move into the
>>> org.apache.avalon.framework namespace.
>>
>>
>>
>> +1
>
>
> Maybe there will be one day when avalon packages will be rock solid and
> won't change every 6 months.
>
> Or one day cocoon will finally pass a Gump run without having avalon
> dependencies broken.
>
> Or one day I'll run out of patience as I did with Tomcat and remove
> dependencies to the bear minimum.
>
> Just keep in mind that everytime you feel you are seeking elegance and
> order, you are, in fact, increasing the enthropy of the system anyway.
Stefano, can you please just come right out and say what you mean?
You are a member of the Avalon community so a simple -1 with an
explanation might be better than this "One day" crap.
You have only had perceived problems with Avalon Framework--IOW, no
change in Framework (the core jar you are using) has made Cocoon
cease to work. Instrument is a new feature, that grew up in Excalibur.
The question now is whether to support the Instrument interfaces in
Framework, or keep it a part of Excalibur.
It is obvious you are against this. Why? Adding functionality to
Framework does not break Cocoon. What it does is make us have to
handle legacy in the InstrumentManager. That may be reason enough
not to do the change. We are trying balance many things here.
THe dependency tree for some of the Avalon packages is potentially
circular, or very complex. The proposal solves one of the causes
of the unnecessary complexity. Granted, it is something that is
beyond *just* components, so we need to balance that fact with
incorporating Instrument into Framework.
Also keep in mind that as we learn, it affects what we percieve
Avalon to be. Managing that change is a difficult task. I welcome
any input from you as to how best to change.
Constant major version changes are really bad. Noone complains about
bug fixes. But what about refining the contracts? Can you help us
all to understand what a decent change strategy is?
I thought we were doing an exemplary job of managing change at the
Framework level. Please enlighten me how we can manage the balance
between too much change and stagnation. I really would like to know.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Leo Simons <le...@apache.org>.
Stefano,
just get off your soapbox, stop the FUD, and give an argumented answer
to the question. You're not helping anyone this way.
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [VOTE] Instrument package into Framework namespace
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Leo Simons wrote:
> > Leo Sutic wrote:
> >
> >> 1. The interfaces from the instrument package should move into the
> >> org.apache.avalon.framework namespace.
> >
> >
> > +1
>
> Maybe there will be one day when avalon packages will be rock
> solid and won't change every 6 months.
>
> Or one day cocoon will finally pass a Gump run without having avalon
> dependencies broken.
>
> Or one day I'll run out of patience as I did with Tomcat and remove
> dependencies to the bear minimum.
>
> Just keep in mind that everytime you feel you are seeking
> elegance and order, you are, in fact, increasing the enthropy of
> the system anyway.
>
> Food for thought.
Stefano, let's look at the situation here:
1. Instrument has never been released - it is still sandbox code.
2. Cocoon has a dependency on Instrument via the ECM.
3. Instrument is used in Cocoon.java and CocoonServlet.java.
Did I sum up your points correctly above? I'm mostly guessing as
you're not giving me much to go on. Let me know what I'm missing.
Regarding (1), well, shit, that sucks. We're trying to get Avalon in
order
right now so people can start working with Avalon releases and not
having
to do the:
c:\apache\avalon>ant checkout-from-cvs
c:\apache\avalon>ant build
c:\apache\avalon>cd ..\xml-cocoon2
c:\apache\xml-cocoon2>ant build-Cocoon
c:\apache\xml-cocoon2>ant pray-it-works
routine that I, for one, hate. LogKit is released, and we're moving
on to Framework.
Regarding (2), that will be handled internally to Avalon.
Regarding (3), you can make 2 one line changes or suffer two
deprecation warnings. Stefano, I'll volunteer to send you
patches.
Finally, Stefano, I get the image of you throwing your hands up in
despair over a constantly changing dependency. Please don't. As you
saw with regards to the @deprecation of ComponentManager etc., you
can talk to us, and we're usually willing to listen.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Simons wrote:
> Leo Sutic wrote:
>
>> 1. The interfaces from the instrument package should move into the
>> org.apache.avalon.framework namespace.
>
>
> +1
Maybe there will be one day when avalon packages will be rock solid and
won't change every 6 months.
Or one day cocoon will finally pass a Gump run without having avalon
dependencies broken.
Or one day I'll run out of patience as I did with Tomcat and remove
dependencies to the bear minimum.
Just keep in mind that everytime you feel you are seeking elegance and
order, you are, in fact, increasing the enthropy of the system anyway.
Food for thought.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Leo Simons <le...@apache.org>.
Leo Sutic wrote:
> 1. The interfaces from the instrument package should move into the
> org.apache.avalon.framework namespace.
+1
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [VOTE] Instrument package into Framework namespace
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>
> Leo Simons wrote:
> > Leo Sutic wrote:
> >
> >> 1. The interfaces from the instrument package should move into the
> >> org.apache.avalon.framework namespace.
> >
> > +1
>
> change to -1. Jason changed my mind :D
Not counting any more... Jason changed my mind as well.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Leo Simons <le...@apache.org>.
Leo Simons wrote:
> Leo Sutic wrote:
>
>> 1. The interfaces from the instrument package should move into the
>> org.apache.avalon.framework namespace.
>
> +1
change to -1. Jason changed my mind :D
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>>
>>Finally, this is our "last chance" to move the instrument
>>package into
>>org.apache.avalon.framework space, if we want to do that.
>>Last time we
>>talked about it we didn't want to IIRC. Anything changed? From the
>>perspective of the instrument package, it makes sense.
>
>
> OK, let's run a quick vote for this in order to gauge consensus.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Leo Simons <le...@apache.org>.
Jason van Zyl wrote:
>> 1. The interfaces from the instrument package should move into the
>> org.apache.avalon.framework namespace.
>
> Why would you make instrumentation part of the core of Avalon? That
> seems very wrong to me. I would rather see some flexible extension
> mechanism where things like instrumentation and management can be added
> easily. But wiring the notion of instrumentation in at the framework
> level doesn't seem right.
>
> Why do you have interfaces for instrumentation anyway? I've never
> understood this myself. I have either used bytecode instrumentation, or
> now I can actually load a 30 line aspect dynamically if I want to
> profile apps in production. But I think you can effectively do the same
> with something like cglib.
yup. In many ways, avalon can be viewed as a "poor man's AspectJ"
(though not really a fair comparison, as you get a level of control and
transparency difficult to ensure in large aspect-based systems). Instead
of the dynamic approach, avalon basically picks out a few common aspects
and uses the more "normal/conventional" setup with interfaces.
The question is when your interfaces are becoming so uncommon they're
either not worth the trouble or don't justify the 3 or 4k they add to
the jarfile.
> Are you trying to formalize instrumentation
> usage? What's to stop things Management and who knows what else from
> going into the core.
good point.
> I think the core is great, if the default
> implmentatations were removed it would be even better. No down side to
> splitting them up as you can package your distributions in any fashion
> you like to provide convenience yet let more savvy users package as they
> please.
we talked about doing it for 4.1.4; not happening now but probably for
4.1.5. Of course it is trivial to downsize the jar if you're a "savvy user":
<exclude name="**/*Default*.java"/>
<exclude name="**/Util.java"/>
<exclude name="**/*SAX*.java"/>
<exclude name="**/Wrapper.java"/>
<exclude name="**/thread/**"/>
(and don't put the optional deps like logkit on the classpath)
> I just think it becomes harder and harder to use the same base container
> when behaviour like async component management, instrumentation and
> component management are present at the core levels. Things get complex,
> no doubt, but the complexity should be optional.
yep. One way of looking at this is what you need is a way to
modify/extend the lifecycle aspect of the code. Which is where the
lifecycle extension work comes into play. Alternative setups include
interceptors, chaining/buses, event-controlled IoC,
big-ball-of-dynamic-mud or something like AspectJ. Most of those result
in looser coupling (ie more of the "optional"), but also in more of the
"complex".
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Stephen McConnell <mc...@apache.org>.
Jason van Zyl wrote:
>On Mon, 2003-02-24 at 04:29, Leo Sutic wrote:
>
>
>>>From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>>>
>>>Finally, this is our "last chance" to move the instrument
>>>package into
>>>org.apache.avalon.framework space, if we want to do that.
>>>Last time we
>>>talked about it we didn't want to IIRC. Anything changed? From the
>>>perspective of the instrument package, it makes sense.
>>>
>>>
>>OK, let's run a quick vote for this in order to gauge consensus.
>>
>>Proposal:
>>
>> 1. The interfaces from the instrument package should move into the
>> org.apache.avalon.framework namespace.
>>
>>
>
>Why would you make instrumentation part of the core of Avalon? That
>seems very wrong to me. I would rather see some flexible extension
>mechanism where things like instrumentation and management can be added
>easily. But wiring the notion of instrumentation in at the framework
>level doesn't seem right.
>
This exists - "The Lifecycle Extension Package" - its supported by both
Merlin and Fortress and it in the avalon-sandbox/lifecycle package. The
package provides explicit support for the addition of a lifecycle stage
handler - and I'm confident that the instrumentation implementation could
easily be adapter to support this mechanism.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Stephen McConnell wrote:
>
>> On CVS
>>
>> avalon-sandbox
>>
>> Because its early, needs more work on doc, more structural
>> separation, and probably one alternative transport to AltRMI - but
>> these things can be addressed in a release early and often pattern.
>> Being in sandbox should not prevent a release - its simply positions
>> the product as new and emerging and not at final release status (at
>> least this is what I would like to see).
>
>
> uhm, fortress has a dependency on instrument, ecm too. You can't be
> serious about releasing those and having instrument in sandbox, can you?
Hi Leo:
I'm not concerned about the place so much as the status of the product.
Personally I don't see any problem with a beta product release of
something in sandbox. I do see a problem if we release as is without
going through a beta period. That beta period would enable us to move
forward on the items I mentioned above. For example - I would envisage
a non-beta release of the instrument suite corresponding to something
documented and deployable on a backbone of released products. If
getting a non-beta release out is critical (which is not my impression)
I could look at putting an IIOP transport connector in place.
>
> that said, we could look at removing the deps, if it makes people happy.
What about updating Fortress and ECM to make instrumentation a soft
dependency - i.e. if its not present in the build or runtime classloader
- then its not build/loaded? There is also the potential for seperating
the instrument package into a lifecycle extension and handler which
would make the soft dependency approach relatively easy.
Cheers, Steve.
>
> cheers,
>
> - Leo
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> On CVS
>
> avalon-sandbox
>
> Because its early, needs more work on doc, more structural separation,
> and probably one alternative transport to AltRMI - but these things can
> be addressed in a release early and often pattern. Being in sandbox
> should not prevent a release - its simply positions the product as new
> and emerging and not at final release status (at least this is what I
> would like to see).
uhm, fortress has a dependency on instrument, ecm too. You can't be
serious about releasing those and having instrument in sandbox, can you?
that said, we could look at removing the deps, if it makes people happy.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>I see something like instrumentation as an "extension" as it provides
>>the classic client contract interface and the container side
>>management
>>aspects.
>>
>>
>
>Agree completely, but where do we put the instrument package then?
>
>So we put it in a completely separate package
>(org.apache.excalibur.instrument,
>or similar), or do we put it into some kind of "extensions endorsed by
>Avalon" package org.apache.avalon.extensions.instrument?
>
>I completely agree on the problem - that while instrument has
>framework-like interfaces, it isn't part of framework proper -
>but well, where do we put it?
>
On package names - the following make sence to me as the
org.apache.avalon.instrument
The current instrument package.
org.apache.avalon.instrument.manager
The current instrument manager package
excluding the two AltRMI classes.
org.apache.avalon.instrument.<transport>
Top level package for a particular plug-in
transport solution. For example, you could
imagine "org.apache.avalon.instrument.iiop" or
"org.apache.avalon.instrument.altrmi".
Based on my current understanding of the
instrument client package I would place this
under "org.apache.avalon.instrument.altrmi.client".
org.apache.avalon.instrument.client
Transport independent presentation API.
On CVS
avalon-sandbox
Because its early, needs more work on doc, more structural separation,
and probably one alternative transport to AltRMI - but these things can
be addressed in a release early and often pattern. Being in sandbox
should not prevent a release - its simply positions the product as new
and emerging and not at final release status (at least this is what I
would like to see).
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [VOTE] Instrument package into Framework namespace
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> I see something like instrumentation as an "extension" as it provides
> the classic client contract interface and the container side
> management
> aspects.
Agree completely, but where do we put the instrument package then?
So we put it in a completely separate package
(org.apache.excalibur.instrument,
or similar), or do we put it into some kind of "extensions endorsed by
Avalon" package org.apache.avalon.extensions.instrument?
I completely agree on the problem - that while instrument has
framework-like interfaces, it isn't part of framework proper -
but well, where do we put it?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>Jason,
>
>a very good argument against moving it to framework level.
>
>It would seem that we can only move it to framework level if
>Instrument is a correct formalization of instrumentation -
>which it isn't, if I understand your argument.
>
>I see these solutions for the instrument interfaces:
>
> 1. Don't move them into framework.
>
> 2. Move them into framework, but *always* provide them in a
> separate jar. (avalon-framework-ext-instrument.jar or
> somesuch.)
>
> 3. Move them into some org.apache.avalon.framework.ext.instrument
> package, always bundle in separate jar.
>
>For now, I'm +1 on 2 or 3. Having the instrument package at a
>framework level makes sense, dependency-wise, although not
>from a formal POV, as you say.
>
Hi Leo:
I think there is a mix-up in the above between "packaging" and
"technology". From a technology point of view the instrument package
can be considered as an optional extension to a component lifecycle.
However, the framework is not and should not be dependent on the notion
of instrumentation. Much closer to the framework technical abstraction
are the meta and lifecycle-extension concerns. These packages both
address the means through which we facilities such as instrumentation
(or other functional extensions) can be introduced into the framework
without disruption.
The packaging point of view concerns the separation of things in Avalon
that are "core" (referred to in this thread as framework-level),
"facilities" (a lot of the stuff in Excalibur), "components" (stuff in
Cornerstone and to some degree in Avalon Apps) and "extensions"
(something largely not considered to-date). I personally think of the
"core" or "framework" level as two distinct groups - (a) the client
contract (largely what we have today in framework.jar) together with
lifecycle extensions and meta info, and (b) the containment facilities.
I see something like instrumentation as an "extension" as it provides
the classic client contract interface and the container side management
aspects.
Cheers, Steve.
>
>Does any of the above make sense?
>
>/LS
>
>
>
>>From: Jason van Zyl [mailto:jason@zenplex.com]
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [VOTE] Instrument package into Framework namespace
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Jason,
a very good argument against moving it to framework level.
It would seem that we can only move it to framework level if
Instrument is a correct formalization of instrumentation -
which it isn't, if I understand your argument.
I see these solutions for the instrument interfaces:
1. Don't move them into framework.
2. Move them into framework, but *always* provide them in a
separate jar. (avalon-framework-ext-instrument.jar or
somesuch.)
3. Move them into some org.apache.avalon.framework.ext.instrument
package, always bundle in separate jar.
For now, I'm +1 on 2 or 3. Having the instrument package at a
framework level makes sense, dependency-wise, although not
from a formal POV, as you say.
Does any of the above make sense?
/LS
> From: Jason van Zyl [mailto:jason@zenplex.com]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Jason van Zyl <ja...@zenplex.com>.
On Mon, 2003-02-24 at 04:29, Leo Sutic wrote:
> > From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
> >
> > Finally, this is our "last chance" to move the instrument
> > package into
> > org.apache.avalon.framework space, if we want to do that.
> > Last time we
> > talked about it we didn't want to IIRC. Anything changed? From the
> > perspective of the instrument package, it makes sense.
>
> OK, let's run a quick vote for this in order to gauge consensus.
>
> Proposal:
>
> 1. The interfaces from the instrument package should move into the
> org.apache.avalon.framework namespace.
Why would you make instrumentation part of the core of Avalon? That
seems very wrong to me. I would rather see some flexible extension
mechanism where things like instrumentation and management can be added
easily. But wiring the notion of instrumentation in at the framework
level doesn't seem right.
Why do you have interfaces for instrumentation anyway? I've never
understood this myself. I have either used bytecode instrumentation, or
now I can actually load a 30 line aspect dynamically if I want to
profile apps in production. But I think you can effectively do the same
with something like cglib. Are you trying to formalize instrumentation
usage? What's to stop things Management and who knows what else from
going into the core. I think the core is great, if the default
implmentatations were removed it would be even better. No down side to
splitting them up as you can package your distributions in any fashion
you like to provide convenience yet let more savvy users package as they
please.
I'm just thinking of using the same container for micro devices being
able to run at a level like phoenix by layering functionality over a
small core and the core seems to be getting bigger as instrumentation
and management seem to be getting close reaching the core level.
I just think it becomes harder and harder to use the same base container
when behaviour like async component management, instrumentation and
component management are present at the core levels. Things get complex,
no doubt, but the complexity should be optional.
> 2. The instrument package may be release separately or bundled
> with the framework jar. We don't decide on this now.
My non-binding +1
> Regarding exactly which interfaces in (1), let's postpone that as
> well - I just want to know if there's any consensus to put
> instrument in framework. We can decide on the exact way of putting
> it there later.
>
> /LS
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Leo Simons <le...@apache.org>.
Peter Donald wrote:
> On Tue, 25 Feb 2003 07:24, Peter Royal wrote:
>
>>On Monday, February 24, 2003, at 05:52 AM, Peter Donald wrote:
>>
>>>I don't actually use it but hear it is good :) - if we want to get more
>>>components/containers supporting that I think we could achieve that by
>>>releasing it and upgrading all the containers to at least provide basic
>>>support for it.
>>
>>its coming to phoenix :)
>
> woohoo!
I'll second that: whoo-hooh-hooh!
been wanting to do some fine-grained profiling on phoenix for a long time...
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [phoenix] now supporting instrumentable applications
Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 17 Mar 2003 14:52, Peter Royal wrote:
> This has landed. I thought there was some sort of changelog as part of
> the documentation, but I didn't see it (or i'm blind).
It got moved to status.xml
> I have not added any counters to phoenix itself yet, I'm not sure what
> all would be interesting to instrument internally. Publishing
> instruments via JMX would be cool though :)
:)
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[phoenix] now supporting instrumentable applications
Posted by Peter Royal <pr...@apache.org>.
On Monday, February 24, 2003, at 03:49 PM, Peter Donald wrote:
> On Tue, 25 Feb 2003 07:24, Peter Royal wrote:
>> On Monday, February 24, 2003, at 05:52 AM, Peter Donald wrote:
>>> I don't actually use it but hear it is good :) - if we want to get
>>> more
>>> components/containers supporting that I think we could achieve that
>>> by
>>> releasing it and upgrading all the containers to at least provide
>>> basic
>>> support for it.
>>
>> its coming to phoenix :)
>
> woohoo!
This has landed. I thought there was some sort of changelog as part of
the documentation, but I didn't see it (or i'm blind).
I have not added any counters to phoenix itself yet, I'm not sure what
all would be interesting to instrument internally. Publishing
instruments via JMX would be cool though :)
-pete
--
peter royal -> proyal@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 25 Feb 2003 07:24, Peter Royal wrote:
> On Monday, February 24, 2003, at 05:52 AM, Peter Donald wrote:
> > I don't actually use it but hear it is good :) - if we want to get more
> > components/containers supporting that I think we could achieve that by
> > releasing it and upgrading all the containers to at least provide basic
> > support for it.
>
> its coming to phoenix :)
woohoo!
--
Cheers,
Peter Donald
--------------------------------------------------
"An intellectual is someone who has been educated
beyond their intelligence."
--------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Peter Royal <pr...@apache.org>.
On Monday, February 24, 2003, at 05:52 AM, Peter Donald wrote:
> I don't actually use it but hear it is good :) - if we want to get more
> components/containers supporting that I think we could achieve that by
> releasing it and upgrading all the containers to at least provide basic
> support for it.
its coming to phoenix :)
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Peter Donald <pe...@realityforge.org>.
It doesn't really elong in framework. It is an othogonal concern to components
lifecycle and shouldn't be in framework (much like persistence and other
concerns).
I don't actually use it but hear it is good :) - if we want to get more
components/containers supporting that I think we could achieve that by
releasing it and upgrading all the containers to at least provide basic
support for it.
On Mon, 24 Feb 2003 20:29, Leo Sutic wrote:
> > From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
> >
> > Finally, this is our "last chance" to move the instrument
> > package into
> > org.apache.avalon.framework space, if we want to do that.
> > Last time we
> > talked about it we didn't want to IIRC. Anything changed? From the
> > perspective of the instrument package, it makes sense.
>
> OK, let's run a quick vote for this in order to gauge consensus.
>
> Proposal:
>
> 1. The interfaces from the instrument package should move into the
> org.apache.avalon.framework namespace.
>
> 2. The instrument package may be release separately or bundled
> with the framework jar. We don't decide on this now.
>
> Regarding exactly which interfaces in (1), let's postpone that as
> well - I just want to know if there's any consensus to put
> instrument in framework. We can decide on the exact way of putting
> it there later.
>
> /LS
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
--
Cheers,
Peter Donald
----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Stephen,
>
>Reading quickly because I've got a Willy Wonka schedule today, but if your
>argument is that things like Instrument are non-core extensions, sort of an
>javax type thing, then I agree. Scalable extensibility starts at the
>framework level. There are core interfaces and standard extensions.
>
Hi Noel:
Yes. These are the parallels I'm referring to. Something like the
instrumentation suite is an extension - and to handle that properly we
need an extension mechanism. A framework extension mechanism exists in
the sandbox. Another alternative is to handle framework extension via
meta but that would take longer. At the end of the day the two
mechanisms (lifecycle extensions and meta info) can coexist. In terms
of immediate requirements relating to Fortress and ECM dependencies
relative to Instrument, I would put the release of the lifecycle;
extensions ahead of instrument, then update instrument to use the
lifecycle extensions. This enables a good separation of framework from
extension mechanisms and has no negative impact on APIs.
Cheers, Steve.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [VOTE] Instrument package into Framework namespace
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stephen,
Reading quickly because I've got a Willy Wonka schedule today, but if your
argument is that things like Instrument are non-core extensions, sort of an
javax type thing, then I agree. Scalable extensibility starts at the
framework level. There are core interfaces and standard extensions.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Stephen McConnell <mc...@apache.org>.
Hi Leo:
See notes in-line...
Leo Sutic wrote:
>
>
>>From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>>
>>Finally, this is our "last chance" to move the instrument
>>package into org.apache.avalon.framework space, if we want
>>to do that.
>>Last time we talked about it we didn't want to IIRC. Anything
>>changed? From the perspective of the instrument package, it
>>makes sense.
>>
>>
>
>OK, let's run a quick vote for this in order to gauge consensus.
>
>Proposal:
>
> 1. The interfaces from the instrument package should move into the
> org.apache.avalon.framework namespace.
>
>
-1
On the question of positioning:
a) I think that the instrument package belongs at the framework
"level" as do things like the mata info APIs and lifecycle
extension mechanisms because they concern the contract between
the component and the container
b) I do not think that instrumentation should be included into
"the" framework level via package name inference.
> 2. The instrument package may be release separately or bundled
> with the framework jar. We don't decide on this now.
>
I would like to see a release of the instrumentation package once
we have (a) a client and server implementation working in the same
virtual machine independently of a plugin transport, and (b)
separation of transport out of the client package as it stands or
if not possible - moving the instrument client to altrmi. I would
be positive towards a separately packaged framework "level" release
(where "level" simply addresses the abstract notion of positioning
within the broad spectrum of Avalon content).
I would be opposed to bundling with the framework before some real
consideration of how lifecycle extensions could be apply this
functionality without requiring modification to framework
contracts at this level of granularity.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] Instrument package into Framework namespace
Posted by Peter Royal <pr...@apache.org>.
On Monday, February 24, 2003, at 04:29 AM, Leo Sutic wrote:
> 1. The interfaces from the instrument package should move into the
> org.apache.avalon.framework namespace.
>
> 2. The instrument package may be release separately or bundled
> with the framework jar. We don't decide on this now.
+1
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[VOTE] Instrument package into Framework namespace
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>
> Finally, this is our "last chance" to move the instrument
> package into
> org.apache.avalon.framework space, if we want to do that.
> Last time we
> talked about it we didn't want to IIRC. Anything changed? From the
> perspective of the instrument package, it makes sense.
OK, let's run a quick vote for this in order to gauge consensus.
Proposal:
1. The interfaces from the instrument package should move into the
org.apache.avalon.framework namespace.
2. The instrument package may be release separately or bundled
with the framework jar. We don't decide on this now.
Regarding exactly which interfaces in (1), let's postpone that as
well - I just want to know if there's any consensus to put
instrument in framework. We can decide on the exact way of putting
it there later.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org