You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Royal <pr...@apache.org> on 2002/05/15 22:05:41 UTC
[altrmi] adding components to assist in connection pooling..
I've thouroughly beat upon my components to handle connection pooling +
general ECM-friendly integration of altrmi and I'm ready to commit them.
Catch is, this would introduce a dependency upon framework to altrmi, which
is something we probably don't want to do. So i'm not sure where this stuff
should go...
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Move instrument core to framework. (Was Re: [altrmi] adding components to assist in connection pooling..)
Posted by Peter Donald <pe...@apache.org>.
On Fri, 9 Aug 2002 19:48, Leif Mortenson wrote:
> Peter Donald wrote:
> >I would prefer to keep it out of framework for the simple reason that it
> > is not directly associated with commissioning or decommissiong a
> > component. It can standalone inside another excalibur component.
> >
> >FYI I also think that poolable threadsafe and friends should not be in
> >framework.
>
> Ok. That is fine. So do you have an opinion on whether it should be
> split back up again or not?
not knowledgable enough to have an opinion and don't really know the
dependencies well enough. If the API can be kept with implementation without
to much coupling then I would do that. I recall there is Instrumenting ECM
which I would put with ECM. No idea really ;)
--
Cheers,
Peter Donald
------------------------------------------------
"No. Try not. Do. Or do not. There is no try."
-- Yoda
------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Move instrument core to framework. (Was Re: [altrmi]
adding components to assist in connection pooling..)
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Berin Loritsch wrote:
>Now, part of the reason that I like Instrument living in one place is
>because it makes it a lot easier to manage a dependency. I understand
>that manager/client might use other packages which in turn are
>instrumented,
>but I can't help thinking there is a better way of doing things in
>general.
>
Yes but most code only has a dependency on the core instrument classes.
It was carefully designed
so that only containers would need to have a dependency on the
instrument manager.
It is very similar to the way ComponentManager exists in Framework while
the actual
implementations of ComponentManagers like the ECM exist over in
Excalibur. Most
classes only need to know about the interface. The implementation is,
as it should be,
irrelevant to them.
Likewise, the only code that most classes will ever need to use exist in
the instrument package.
The implementation is in the instrument.manager package.
I tried to make the DefaultInstrumentManager implementation work as well
as possible.
But like the ECM, I am sure that me or someone else will come up with a
better
implementation at some point in the future. When that happens,
hopefully the core
instrument classes will be able to be used as is, making it possible to
cleaning start
using the InstrumentManager implementation.
Likewise, the Instrument client is just one possible implementation. I
already have ideas
for a servlet and soap based instrument clients rolling around in the
back of my head for
example. The current GUI still needs a lot of work. But I can see
parts of it hopefully
making it into the future Phoenix admin tool as well.
Point is that while the 3 packages shared a name, they are really 3
different projects.
Look at how the build has already divided them up again even though they
are in the
same directory. We can make it work that way, but the build file is
quite a bit different
than those of other projects. That is going to hurt maintainability.
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Move instrument core to framework. (Was Re: [altrmi] adding components to assist in connection pooling..)
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leif Mortenson [mailto:leif@tanukisoftware.com]
>
> Peter Donald wrote:
>
> >I would prefer to keep it out of framework for the simple
> reason that
> >it is
> >not directly associated with commissioning or decommissiong
> a component. It
> >can standalone inside another excalibur component.
> >
> >FYI I also think that poolable threadsafe and friends should
> not be in
> >framework.
> >
> >
> Ok. That is fine. So do you have an opinion on whether it should be
> split back up again or not?
> I think that it would be best to return it to the following directory
> structure for the reasons
> that I already covered. With the new short package names of course.
>
> excalibur/
> component/
> instrument/
> instrument-manager/ (client could live here as well)
> instrument-client/
> zip/
> etc./
>
> I think this would be much more maintainable than the
> following as was
> suggested by Stephen :
> excalibur/
> component/
> instrument/
> core/
> manager/
> client/
> zip/
> etc./
>
> Berin, you had merged them so if you have any input, I am listening.
As far as maintainability is concerned, it is maintainable no matter
where you put it. The question is the dependency system. I personally
am not happy with the dependency system--sure it automagically and
recursively builds stuff, but I am not sure that is best.
Take for instance the Maven way of doing things--jars are uploaded to
a repository (it can even be automated to be a nightly release), and
you update your local repository periodically.
Things like where something lives is irrelevant.
Now, part of the reason that I like Instrument living in one place is
because it makes it a lot easier to manage a dependency. I understand
that manager/client might use other packages which in turn are
instrumented,
but I can't help thinking there is a better way of doing things in
general.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Move instrument core to framework. (Was Re: [altrmi]
adding components to assist in connection pooling..)
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Peter Donald wrote:
>I would prefer to keep it out of framework for the simple reason that it is
>not directly associated with commissioning or decommissiong a component. It
>can standalone inside another excalibur component.
>
>FYI I also think that poolable threadsafe and friends should not be in
>framework.
>
>
Ok. That is fine. So do you have an opinion on whether it should be
split back up again or not?
I think that it would be best to return it to the following directory
structure for the reasons
that I already covered. With the new short package names of course.
excalibur/
component/
instrument/
instrument-manager/ (client could live here as well)
instrument-client/
zip/
etc./
I think this would be much more maintainable than the following as was
suggested by Stephen :
excalibur/
component/
instrument/
core/
manager/
client/
zip/
etc./
Berin, you had merged them so if you have any input, I am listening.
Cheers
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Move instrument core to framework. (Was Re: [altrmi] adding components to assist in connection pooling..)
Posted by Peter Donald <pe...@apache.org>.
I would prefer to keep it out of framework for the simple reason that it is
not directly associated with commissioning or decommissiong a component. It
can standalone inside another excalibur component.
FYI I also think that poolable threadsafe and friends should not be in
framework.
On Fri, 9 Aug 2002 01:17, Leif Mortenson wrote:
> Today the instrument build got complicated to make a circular
> depencency between instrument
> pool and altrmi work correctly. Now the instrument build contains two
> seperate builds. One to
> build the core classes, and a second to build the instrument manager and
> client. This was exactly
> the reason why I had wanted to have the projects split up originally.
>
> The core instrument classes are very simple and have absolutely no
> dependency on anything
> else. Where as the manager and client are much more complicated
> involving lots of dependencies.
>
> The core instrument classes by design are used by lots of other
> packages. Where as the manager
> is only used by containers. The client is a seperate application.. It
> doesn't really matter where it
> lives.
>
> What would you think of moving the core instrument classes over to
> framework? That would
> make it easier to integrate it more fully into various avalon components
> without having to worry
> about dependency issues. Another option would be to move the
> instrument manager and client
> classes back into a seperate instrument-manager package.
>
> Thoughts?
>
> As things are now, the instrument build file has to get called
> twice. It works now, but I can us
> getting into a situation again soon where it won't.
>
> Cheers,
> Leif
>
> Peter Royal wrote:
> >On Wednesday 15 May 2002 04:05 pm, Peter Royal wrote:
> >>I've thouroughly beat upon my components to handle connection pooling +
> >>general ECM-friendly integration of altrmi and I'm ready to commit them.
> >>
> >>Catch is, this would introduce a dependency upon framework to altrmi,
> >> which is something we probably don't want to do. So i'm not sure where
> >> this stuff should go...
> >
> >These components have been committed. Altrmi already had a framework dep.
> >-pete
--
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Move instrument core to framework. (Was Re: [altrmi]
adding components to assist in connection pooling..)
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Stephen McConnell wrote:
> Peter Royal wrote:
>
>> I had a long message ranting about the split written but decided not
>> to send it :)
>
I don't understand what the rant would be about???
>> Pushing the core into framework would work, but I think splitting the
>> core and the client/mgr back into separate excacalibur subprojects
>> might be best.
>
> Any reason why this can't live as one excalibur project that happens
> to have three subprojects within it?
Do you mean like this?
excalibur/
component/
instrument/
core/
manager/
client/
zip/
etc./
That would work. But it would make instrument different than all of the
other projects. It seems like
that would just cause headaches for things like depchecker. Most
projects would refer to other
projects via ${basedir}/../component But instrument subprojects would
be ${basedir}/../../component
Personally, I thought it was better to keep the subprojects looking
exactly like other projects. Even
if that means 1 or 2 more projects.
excalibur/
component/
instrument/
instrument-manager/ (client could live here as well)
instrument-client/
zip/
etc./
My reason for thinking of moving the instrument core into framework is
that those classes are really
very similar to things like Startable or Loggable in how they are used.
Those classes have also
remained perfectly stable since they were first created. I think the
only changes have been with
javadocs.
Placing them over there would allow us to have only one instrument
project in Excalibur.
Furthermore. A growing number of projects in Excalibur depend on
Instrument either directly
or due to their usage of other subprojects like pool etc. Those
projects also almost all already
use framework.
The drawback to placing instrument core into framework is that it ties
the Instrument core to
framework. Currently, the core instrument classes have 0 dependencies
so they can be used
pretty much anywhere.
As far as code stability. All three projects are currently at version
0.3 to keep them aligned. But
I would give the core a stable version of 1.0. manager is pretty
stable. But the client is stull under
heavy development and needs more work.
Thoughts
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Move instrument core to framework. (Was Re: [altrmi]
adding components to assist in connection pooling..)
Posted by Stephen McConnell <mc...@apache.org>.
Peter Royal wrote:
>On Thursday 08 August 2002 11:17 am, Leif Mortenson wrote:
>
>
>> What would you think of moving the core instrument classes over to
>>framework? That would
>>make it easier to integrate it more fully into various avalon components
>>without having to worry
>>about dependency issues. Another option would be to move the
>>instrument manager and client
>>classes back into a seperate instrument-manager package.
>>
>> Thoughts?
>>
>>
>
>I had a long message ranting about the split written but decided not to send
>it :)
>
>Pushing the core into framework would work, but I think splitting the core and
>the client/mgr back into separate excacalibur subprojects might be best.
>-pete
>
>
Any reason why this can't live as one excalibur project that happens to
have three subprojects within it?
Steve.
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Move instrument core to framework. (Was Re: [altrmi] adding components to assist in connection pooling..)
Posted by Peter Royal <pr...@apache.org>.
On Thursday 08 August 2002 11:17 am, Leif Mortenson wrote:
> What would you think of moving the core instrument classes over to
> framework? That would
> make it easier to integrate it more fully into various avalon components
> without having to worry
> about dependency issues. Another option would be to move the
> instrument manager and client
> classes back into a seperate instrument-manager package.
>
> Thoughts?
I had a long message ranting about the split written but decided not to send
it :)
Pushing the core into framework would work, but I think splitting the core and
the client/mgr back into separate excacalibur subprojects might be best.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[VOTE] Move instrument core to framework. (Was Re: [altrmi] adding
components to assist in connection pooling..)
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Today the instrument build got complicated to make a circular
depencency between instrument
pool and altrmi work correctly. Now the instrument build contains two
seperate builds. One to
build the core classes, and a second to build the instrument manager and
client. This was exactly
the reason why I had wanted to have the projects split up originally.
The core instrument classes are very simple and have absolutely no
dependency on anything
else. Where as the manager and client are much more complicated
involving lots of dependencies.
The core instrument classes by design are used by lots of other
packages. Where as the manager
is only used by containers. The client is a seperate application.. It
doesn't really matter where it
lives.
What would you think of moving the core instrument classes over to
framework? That would
make it easier to integrate it more fully into various avalon components
without having to worry
about dependency issues. Another option would be to move the
instrument manager and client
classes back into a seperate instrument-manager package.
Thoughts?
As things are now, the instrument build file has to get called
twice. It works now, but I can us
getting into a situation again soon where it won't.
Cheers,
Leif
Peter Royal wrote:
>On Wednesday 15 May 2002 04:05 pm, Peter Royal wrote:
>
>
>>I've thouroughly beat upon my components to handle connection pooling +
>>general ECM-friendly integration of altrmi and I'm ready to commit them.
>>
>>Catch is, this would introduce a dependency upon framework to altrmi, which
>>is something we probably don't want to do. So i'm not sure where this stuff
>>should go...
>>
>>
>
>These components have been committed. Altrmi already had a framework dep.
>-pete
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] adding components to assist in connection pooling..
Posted by Peter Royal <pr...@apache.org>.
On Wednesday 15 May 2002 04:05 pm, Peter Royal wrote:
> I've thouroughly beat upon my components to handle connection pooling +
> general ECM-friendly integration of altrmi and I'm ready to commit them.
>
> Catch is, this would introduce a dependency upon framework to altrmi, which
> is something we probably don't want to do. So i'm not sure where this stuff
> should go...
These components have been committed. Altrmi already had a framework dep.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] adding components to assist in connection pooling..
Posted by Vinay Chandran <vi...@yahoo.com>.
Peter,
--- Peter Royal <pr...@apache.org> wrote:
> Vinay, I may do some simple cleaning / javadocing
> and send to you for some
> finishes if you like. But repackaging is so easy
> with IDEA.
No problem , eclipse also does it job well enuf:)
So do sent it to me ,I shall give the finishes .
Regards,
Vinay
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] adding components to assist in connection pooling..
Posted by Peter Royal <pr...@apache.org>.
On Sunday 23 June 2002 05:11 pm, Paul Hammant wrote:
> What's happening here? I've missed the thread because of my extended
> dialup misery at the hands of BT.
>
> Peter Royal (?) : Is this what we talked about in May ? :-)
Yes, I've been very busy. I still have the thread nagging me in my inbox and
(shockingly) i may squeeze it in this week. My boss has a habit of making our
customers happy a higher priority than repackaging code for apache :)
Vinay, I may do some simple cleaning / javadocing and send to you for some
finishes if you like. But repackaging is so easy with IDEA. My main focus is
wanting to write valid docs for it, otherwise I fear its use would be limited.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] adding components to assist in connection pooling..
Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay, Peter,
What's happening here? I've missed the thread because of my extended
dialup misery at the hands of BT.
Peter Royal (?) : Is this what we talked about in May ? :-)
- Paul
>Peter,
>
>
>>I've thouroughly beat upon my components to handle
>>connection pooling +
>>general ECM-friendly integration of altrmi and I'm
>>ready to commit them.
>>
>>
>>
>Still waiting :-)
>Hopefully you can you sent it across to me or commit
>it within altrmi/ folder since then we shall have all
>'altrmi' infected code in one place.
>
>Thanks,
>V i n a y
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! - Official partner of 2002 FIFA World Cup
>http://fifaworldcup.yahoo.com
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] adding components to assist in connection pooling..
Posted by Vinay Chandran <vi...@yahoo.com>.
Peter,
> I've thouroughly beat upon my components to handle
> connection pooling +
> general ECM-friendly integration of altrmi and I'm
> ready to commit them.
>
Still waiting :-)
Hopefully you can you sent it across to me or commit
it within altrmi/ folder since then we shall have all
'altrmi' infected code in one place.
Thanks,
V i n a y
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>