You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2004/03/14 19:28:19 UTC
excalibur pool update
Have just committed some changes in the excalibur pool package:
1. create an api/impl/instrumented package separation
- stripped out instrumentable support in
ResourceLimitingPool
- added InstrumentedResourceLimitingPool under
instrumented package
2. removed deprecated Loggable reference, all LogKit
references and references to the deprecated Component
references
3. removed dependence on excalibur component testcase
by importing a local copy of BufferLogger to the
unit test sources
4. set version on all artifacts to SNAPSHOT
The original source and build content remains unchanged. Following
validation against a updated thread package I'm planning on validating
the suite against an updated cornerstone threads package as part of the
process of synchronizing cornerstone with recent excalibur updates.
Assuming that process goes reasonably smoothly I'll probably raise the
subject of releasing this content under version 2.0.
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: excalibur pool update
Posted by Stephen McConnell <mc...@apache.org>.
Leif Mortenson wrote:
> Stephen,
> What are the reasons for breaking instrumentation out of the
> ResourceLimitingPool?
Hi Leif:
The reason I broke is out is partly to get back to a clean separation of
concerns, and partly to deal with elimination of "optional classes"
notion (which just plays hell if your doing anything automatically). On
the other hand I put in place the equivalent structure under the
instrumented package so that the instrument pool could be deal with full
and completely (which means getting to a fully maintainable instrumented
pool with all functional dependencies in place and testable).
> The only requirement is the instrument jar which is intentionally lite
> weight.
I understand.
> By breaking out the class, this will break the instrumentation support
> in several applications that I have working.
The updates I have made do not change the /src directory. I have
specifically moved the "breaking" content to separate directories and
set the version to SNAPSHOT with an intention of establishing a 2.0
(i.e. major version bump). Irrespective of instrumentation - the
removal of deprecated references in the API immediately means that I'm
proposing something that is *not* backward compatible.
From this context there is an opportunity to sort out the
instrumentable relationship and implementation strategy - the first step
in this direction is the creation of the
InstrumentedResourceLimitingPool under the instrumented package.
> If you want another pool without the
> instrumentation dependency then you should create a new class there.
Yep this is possible. We could rename the impl package
ResourceLimitingPool to something else and rename the instrumented
package InstrumentedResourceLimitingPool to ResourceLimitingPool. I
though about this at the time and decided that given that I was
intentionally breaking things - now was moment to reposition an
instrumented pool as something supplementary to a non-instrumented pool.
Either way - I thing the better solution is to update the
ResourceLimitingPool in impl to provide protected hooks so that an
instrumented pool can either extend or wrap the core pool.
> I am still using Fortress in all of my applications.
Fortress support is not on my agenda concerning a 2.0 release. Getting
rid of deprecated content is - and in turn bringing the package into
something that is more easily maintainable.
> Does Merlin make use of
> Instrumentation or is this not a feature that is being included over
> there.
Merlin does not use the instrumented package for the following reasons:
(a) dependence of AltRMI is not (IMO) viable
(b) design decisions concerning plugin JMX management
still a work in progress
(c) unsure about the instrumented package road map
> With the
> talk of deprecating Fortress, I was planning to take a look at Merlin
> for my next
> project. But I make heavy use of Instrumentation. Doing a search of
> the Merlin
> source tree I don't see any reference to Instrumentation so it does not
> look like
> it is supported.
What I'm trying to on the instrumentation side is to figure out the
right way to expose the necessary plugin points that will allow the
association of different controllers. The composition api package
provides a lot of information but its still a work-in-progress (in
particular the addition of events arrising from model change). The idea
is that it should be possible to add a controller without modifying
composition and activation APIs and from that enable JMX based
management or alternative strategies.
My feeling is that there is a part of the instrumentation package that
makes sense in the definition of the overall model and parts that are
implementation issues. Currently my impression is that the the
instrumentation package could provide a gateway providing an alternative
industry standard transport implementation is established. From here I
think that the instrumentation tools can be viewed as client handlers
and in this respect are on the same plane as a JMX adapter.
> I know the documentation is fairly light. But the
> instrument and
> instrument-manager jars are actually very solid. The HTTP connector to the
> instrument manager removes any need for the Altrmi dependencies.
I need to go digging into the status of instrumentation - havn't looked
at it for at least six months. Perhaps there is an opportunity to
resolve the way that optional dependencies are managed by using the
repository package - similar to the avalon-logging package handles
plugins, and plugins load plugins, etc.
All in all it would be really great if we can figure out the the
instrumentation story.
Cheers, Stephen.
> Although
> that is still supported as a way to connect from the instrument-client.
>
> Cheers,
> Leif
>
> Stephen McConnell wrote:
>
>>
>> Have just committed some changes in the excalibur pool package:
>>
>> 1. create an api/impl/instrumented package separation
>> - stripped out instrumentable support in
>> ResourceLimitingPool
>> - added InstrumentedResourceLimitingPool under
>> instrumented package
>> 2. removed deprecated Loggable reference, all LogKit
>> references and references to the deprecated Component
>> references
>> 3. removed dependence on excalibur component testcase
>> by importing a local copy of BufferLogger to the
>> unit test sources
>> 4. set version on all artifacts to SNAPSHOT
>>
>> The original source and build content remains unchanged. Following
>> validation against a updated thread package I'm planning on validating
>> the suite against an updated cornerstone threads package as part of
>> the process of synchronizing cornerstone with recent excalibur
>> updates. Assuming that process goes reasonably smoothly I'll probably
>> raise the subject of releasing this content under version 2.0.
>>
>> Cheers, Stephen.
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: excalibur pool update
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Stephen,
What are the reasons for breaking instrumentation out of the
ResourceLimitingPool?
The only requirement is the instrument jar which is intentionally lite
weight.
By breaking out the class, this will break the instrumentation support
in several
applications that I have working. If you want another pool without the
instrumentation
dependency then you should create a new class there.
I am still using Fortress in all of my applications. Does Merlin make
use of
Instrumentation or is this not a feature that is being included over
there. With the
talk of deprecating Fortress, I was planning to take a look at Merlin
for my next
project. But I make heavy use of Instrumentation. Doing a search of
the Merlin
source tree I don't see any reference to Instrumentation so it does not
look like
it is supported. I know the documentation is fairly light. But the
instrument and
instrument-manager jars are actually very solid. The HTTP connector to the
instrument manager removes any need for the Altrmi dependencies. Although
that is still supported as a way to connect from the instrument-client.
Cheers,
Leif
Stephen McConnell wrote:
>
> Have just committed some changes in the excalibur pool package:
>
> 1. create an api/impl/instrumented package separation
> - stripped out instrumentable support in
> ResourceLimitingPool
> - added InstrumentedResourceLimitingPool under
> instrumented package
> 2. removed deprecated Loggable reference, all LogKit
> references and references to the deprecated Component
> references
> 3. removed dependence on excalibur component testcase
> by importing a local copy of BufferLogger to the
> unit test sources
> 4. set version on all artifacts to SNAPSHOT
>
> The original source and build content remains unchanged. Following
> validation against a updated thread package I'm planning on validating
> the suite against an updated cornerstone threads package as part of
> the process of synchronizing cornerstone with recent excalibur
> updates. Assuming that process goes reasonably smoothly I'll probably
> raise the subject of releasing this content under version 2.0.
>
> Cheers, Stephen.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org