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 mapWith 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
