You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2004/01/06 16:22:38 UTC
[RT] Changing Meta Package
In order to solve "model" issues much easier and much more flexibly, I propose
to use the work that Leo did a while back with the Attributes embedded in the
class file itself. It is a much more flexible way of doing things which will
not require future modifications to the meta model to take care of enhancements.
In order to make this change, we need to create an ANT task that will make the
translation from the currently declared attributes to the form that Leo's
library will accept. On the client side, we would have preserved the existing
contracts so people don't have to rush around altering their code immediately.
Behind the scenes (and within Merlin/Composition) the system would be refactored
to use the Attribute objects instead of the current hard coded meta model.
Framework would then be extended to include the "official" Attributes that would
be used in components, which will also allow us to use normal OO techniques to
maintain backwards compatibility as we may need to add new features later on.
From a container perspective, we can look at matching these attributes to the
plugins that need them--or trust the developer to put things together correctly.
Anyway, this is a refactoring I think can be made without sacrificing current
abilities, while simultaneously heading off some of the API scalability issues
that exhibit themselves from time to time.
Essentially the whole "meta-model" system would become merely a tool for
backwards user compatibility, with the future based on Leo's less strict model.
This will help the effort to bring in new features and improve Merlin as a
whole.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> On Wednesday 07 January 2004 00:15, Niclas Hedhman wrote:
>
>>Sorry Berin, I think you missed the target - Why do it in the first place?
>
>
> Typo...
>
> Sorry Berin, I think you missed the target - Why do I need it in the first
> place?
Sometimes new features need new meta info to help fine tune those features.
For instance, dynamic generation of intrumentation points, or JMX control
points. It would be easier to handle these with a less strict meta model
than the one under the Meta system.
(copied form other email).
Also, to make things like Avalon PI a reality, we need something that is
flexible enough to handle non-Avalon specific attributes.
The major reason for it though is to make the development of plug-ins or
enhancements to the container architecture easier. It is not necessarily
something that would benifit the core system immediately--but something
that will benefit others in the future. By forcing hard and inflexible
object models that are concrete and not alterable, you lose out on a whole
host of other enhancements that don't fit that model.
The current model feels like I am painted into a corner--and it is difficult
to merge into Fortress which makes it hard to upgrade it. Whereas the more
flexible Attributes package will fit both environments pretty well.
One is custom made for Merlin, while the other allows for a wider variety
of environments.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 07 January 2004 00:15, Niclas Hedhman wrote:
> Sorry Berin, I think you missed the target - Why do it in the first place?
Typo...
Sorry Berin, I think you missed the target - Why do I need it in the first
place?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 07 January 2004 00:05, Berin Loritsch wrote:
> Niclas Hedhman wrote:
> > Open for arguments...
I see a list of "why not, not do it" (I just love double negation), which
doesn't imply "why to do it".
Let's see in detail what we can dig out of these arguments;
> I understand the concerns, but currently the model we have has to be
> altered, which also may require alterations to the composition package
> (speculation here).
"Has to be altered"? Please provide some info about this requirement.
> Not to mention that the Merlin is not currently geared
> for the JDK 1.5 approach.
This is against an alternative approach.
> Our utility would be able to function--even in a
> 1.5 environment.
This is a "feature" that is only relevant after the decision to 'roll our
own'.
> Not to mention, if there are changes that need to be done
> to the Attribute classes, that refactoring would be easy to accomplish.
Not sure what you are referring to here. The Attribute classes, are the ones
that would exist after the fact. Still no news on why to do it in the first
place.
> Not to mention JDK 1.5 availability rolls out in stages, usually on
> WIndows/Sun platforms first, followed by a few months later with Linux, and
> even later OpenBSD and Mac. We would be able to maintain users forced to
> remain on 1.4 for the forseeable future.
Again, an argument between two alternate solutions, of I see no remarkable
evidence I need in the first place.
Sorry Berin, I think you missed the target - Why do it in the first place?
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Niclas Hedhman wrote:
>
>> On Tuesday 06 January 2004 23:22, Berin Loritsch wrote:
>>
>>> In order to solve "model" issues much easier and much more flexibly, I
>>> propose to use the work that Leo did a while back with the Attributes
>>> embedded in the class file itself.
>>
>>
>>
>> Without knowing too much (as usual) about the subject, I would ask "Is
>> it that clever to 'roll your own', instead of awaiting the JDK1.5 in a
>> couple of months?"
>> If one can't wait for 1.5 to be available to all platforms, would it
>> still not make sense to "wait" and keep what we have meanwhile?
>>
>> Open for arguments...
>
>
> I understand the concerns, but currently the model we have has to be
> altered,
Has to be altered ... why?
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> On Tuesday 06 January 2004 23:22, Berin Loritsch wrote:
>
>>In order to solve "model" issues much easier and much more flexibly, I
>>propose to use the work that Leo did a while back with the Attributes
>>embedded in the class file itself.
>
>
> Without knowing too much (as usual) about the subject, I would ask "Is it that
> clever to 'roll your own', instead of awaiting the JDK1.5 in a couple of
> months?"
> If one can't wait for 1.5 to be available to all platforms, would it still not
> make sense to "wait" and keep what we have meanwhile?
>
> Open for arguments...
I understand the concerns, but currently the model we have has to be altered,
which also may require alterations to the composition package (speculation
here). Not to mention that the Merlin is not currently geared for the JDK 1.5
approach. Our utility would be able to function--even in a 1.5 environment.
Not to mention, if there are changes that need to be done to the Attribute
classes, that refactoring would be easy to accomplish.
Not to mention JDK 1.5 availability rolls out in stages, usually on WIndows/Sun
platforms first, followed by a few months later with Linux, and even later
OpenBSD and Mac. We would be able to maintain users forced to remain on 1.4 for
the forseeable future.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Leo Simons <le...@apache.org>.
Niclas Hedhman wrote:
> On Tuesday 06 January 2004 23:22, Berin Loritsch wrote:
>
>>In order to solve "model" issues much easier and much more flexibly, I
>>propose to use the work that Leo did a while back with the Attributes
>>embedded in the class file itself.
>
> Without knowing too much (as usual) about the subject, I would ask "Is it that
> clever to 'roll your own', instead of awaiting the JDK1.5 in a couple of
> months?"
> If one can't wait for 1.5 to be available to all platforms, would it still not
> make sense to "wait" and keep what we have meanwhile?
I've discussed this with Leo before. Basically, what we want to make
sure is that the runtime api is completely interface-based and
completely non-intrusive. That way, once jdk 1.5 comes out, it should be
possible to create a seperate version of the attributes runtime api that
utilizes the jdk 1.5 attribute support.
Just like we did with logging, regular expressions, non-blocking I/O, etc.
The tricky part is figuring out what exactly jdk 1.5 will support.
Note this principle applies whether we stick with "what we have" or a
migration to any different package is done.
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://lsd.student.utwente.nl/jicarilla/Articles
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 06 January 2004 23:22, Berin Loritsch wrote:
> In order to solve "model" issues much easier and much more flexibly, I
> propose to use the work that Leo did a while back with the Attributes
> embedded in the class file itself.
Without knowing too much (as usual) about the subject, I would ask "Is it that
clever to 'roll your own', instead of awaiting the JDK1.5 in a couple of
months?"
If one can't wait for 1.5 to be available to all platforms, would it still not
make sense to "wait" and keep what we have meanwhile?
Open for arguments...
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Jonathan Hawkes wrote:
>
>> I've heard Leo's work with Attributes mentioned a lot in this group. For
>> those of us coming in late in the game, do you have an
>> example/illustration?
>>
>> Thanks!
>> Jonathan Hawkes
>>
>
> The basic principle doesn't change. You still have to declare them via a
> javadoc comment, but the syntax is a bit different. Essentially you are
> coding a constructor. For example, instead of the current way to declare
> a component:
>
> @avalon.component version=1.1
>
> It would be written in this manner:
>
> @AvalonComponent(1.1)
I disagree about any changes to @avalon tags - there is no reason why
the ant task (responsible for persistent meta-info generation) cannot
read of the established tag specification.
http://avalon.apache.org/meta/tools/tags/index.html
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Berin Loritsch <bl...@apache.org>.
Jonathan Hawkes wrote:
> I've heard Leo's work with Attributes mentioned a lot in this group. For
> those of us coming in late in the game, do you have an example/illustration?
>
> Thanks!
> Jonathan Hawkes
>
The basic principle doesn't change. You still have to declare them via a
javadoc comment, but the syntax is a bit different. Essentially you are
coding a constructor. For example, instead of the current way to declare
a component:
@avalon.component version=1.1
It would be written in this manner:
@AvalonComponent(1.1)
Another essential difference is that the attributes are encoded into the class
itself instead of as a separate XML, serialized object, or other format file.
This protects the system from broken classloaders that don't allow you to pull
resources from a JAR file (only classes). It also protects you from format
changes to the said XML, serialized object, etc. files.
I believe the work is over at Jakarta Commons, but I need to double check.
We can ensure that Avalon components have a consistent format for the necessary
attributes by including them in the framework package and requiring their use.
It is a very simple, yet powerful concept. If you want to pull an attribute
from a method, no problem. Look up the method and ask for its attributes.
You use normal reflection calls to get at the members you need, and the
utilities will return you a set of real objects with a real queriable interface.
The same spirit behind the current meta model without the biggest limitations.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Jonathan Hawkes <jh...@adsnm.com>.
I've heard Leo's work with Attributes mentioned a lot in this group. For
those of us coming in late in the game, do you have an example/illustration?
Thanks!
Jonathan Hawkes
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Avalon Developers List" <de...@avalon.apache.org>
Sent: Tuesday, January 06, 2004 8:22 AM
Subject: [RT] Changing Meta Package
> In order to solve "model" issues much easier and much more flexibly, I
propose
> to use the work that Leo did a while back with the Attributes embedded in
the
> class file itself. It is a much more flexible way of doing things which
will
> not require future modifications to the meta model to take care of
enhancements.
>
> In order to make this change, we need to create an ANT task that will make
the
> translation from the currently declared attributes to the form that Leo's
> library will accept. On the client side, we would have preserved the
existing
> contracts so people don't have to rush around altering their code
immediately.
> Behind the scenes (and within Merlin/Composition) the system would be
refactored
> to use the Attribute objects instead of the current hard coded meta model.
>
> Framework would then be extended to include the "official" Attributes that
would
> be used in components, which will also allow us to use normal OO
techniques to
> maintain backwards compatibility as we may need to add new features later
on.
>
> From a container perspective, we can look at matching these attributes to
the
> plugins that need them--or trust the developer to put things together
correctly.
> Anyway, this is a refactoring I think can be made without sacrificing
current
> abilities, while simultaneously heading off some of the API scalability
issues
> that exhibit themselves from time to time.
>
> Essentially the whole "meta-model" system would become merely a tool for
> backwards user compatibility, with the future based on Leo's less strict
model.
> This will help the effort to bring in new features and improve Merlin as a
> whole.
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 07 January 2004 02:56, Timothy Bennett wrote:
> Berin Loritsch wrote:
> > Tone it down big guy. I am juggling three different thought processes
> > currently, and I am not in a position to give a more clear answer just
> > yet. Maybe later, but right now I am juggling too many things and quite
> > frankly the ones that pay me have higher priority.
>
> !!??!!??
>
> With all due respect and full understanding that I'm probably the least
> on the totem pole around here, I think it's a bit unfair to post nearly
> a score of message across several different threads raising the level of
> concerns that you have about existing packages to finally basically say,
> "I don't have time to get into detail right now."
I second this assessment.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Timothy Bennett <ex...@comcast.net>.
Berin Loritsch wrote:
>
> Tone it down big guy. I am juggling three different thought processes
> currently, and I am not in a position to give a more clear answer just
> yet. Maybe later, but right now I am juggling too many things and quite
> frankly the ones that pay me have higher priority.
>
!!??!!??
With all due respect and full understanding that I'm probably the least
on the totem pole around here, I think it's a bit unfair to post nearly
a score of message across several different threads raising the level of
concerns that you have about existing packages to finally basically say,
"I don't have time to get into detail right now."
I mean, you raised these issues to begin with, presumably understanding
all work-stuff items your juggling. No doubt you've spent a couple of
hours crafting the posts, and responding to them, and thinking about the
issues. Maybe you should spend the time wrapping up your work items
first, then come back ready to engage the developer community with the
details of your issues. You owe Steve and the rest of the community
that much if you want real discussion on the topic that leads to some
consensus and agreement. We all have a ton of stuff to do internal and
external to the Avalon community, and to be baited into discussions of
this magnitude with no real intention of seeing them through is a bit
inconsiderate IMO.
Again, I'm not trying to be harsh or unrespectful, but it seems to me a
bit more wisdom is in order regarding the timing of raising issues like
this.
I'll go back to my hole now and the hot items that pay my bills too...
Timothy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>> Berin Loritsch wrote:
>>
>>>
>>> Tone it down big guy. I am juggling three different thought processes
>>> currently, and I am not in a position to give a more clear answer just
>>> yet. Maybe later, but right now I am juggling too many things and quite
>>> frankly the ones that pay me have higher priority.
>>
>>
>>
>> Oh, OK, so you have not actually tried to use what is already there.
>> Gosh, I thought that maybe you were dealing with a real problem.
>>
>> My apologies.
>
>
> I accept your appology for the tone in the message. All I said was that I
> am too busy right now to formulate what you would consider a plausable
> answer (if that is indeed possible considering the defense you raise
> toward anything you develop). I never said I didn't try to use it.
> Patience is a virtue, have it if you can.
My apology was specifically related to the fact that I had made the
incorrect assumption that you had identified a problem that clearly and
unambiguously justified breaking changes to a released avalon product.
Based on your comments you have not actually got to a point of being
able to articulate the problem, but, you have been able to articulate
the solution (and for that, I'm impressed). I kind of figured that one
should come before the other, but I'm probably too old fashioned.
Anyway, when you figure out what the problem that you are dealing with
actually is please post a note.
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>
>>
>> Tone it down big guy. I am juggling three different thought processes
>> currently, and I am not in a position to give a more clear answer just
>> yet. Maybe later, but right now I am juggling too many things and quite
>> frankly the ones that pay me have higher priority.
>
>
> Oh, OK, so you have not actually tried to use what is already there.
> Gosh, I thought that maybe you were dealing with a real problem.
>
> My apologies.
I accept your appology for the tone in the message. All I said was that I
am too busy right now to formulate what you would consider a plausable answer
(if that is indeed possible considering the defense you raise toward anything
you develop). I never said I didn't try to use it. Patience is a virtue,
have it if you can.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>> Berin Loritsch wrote:
>>
>>> Stephen McConnell wrote:
>>>
>>>
>>>> Stephen McConnell wrote:
>>>> >> No. I didn't ask for the ramifications .. I just asked you
>>>> >> what your underlying reasons were. Presumably you are trying
>>>> >> to do *something* and its not easy to do.
>>>> >>
>>>> >> What is that *something*?
>>>>
>>>> What is it that you are trying to do and cannot do with the existing
>>>> attributes specification?
>>>
>>>
>>>
>>>
>>> Integrate with Fortress easily.
>>
>>
>>
>>
>> Specifically what? Can you try and expand just a little? Something
>> concrete would go a long way in clarifying your desire to change a
>> perfectly good package. As things stand you have only presented the
>> desire but the rationalization sucks big time. Let's stop the
>> discussion on solutions to an undeclared problem - and get down to the
>> actual declaration of the problem - your statement "Integrate with
>> Fortress easily" does not provide me with anything useful.
>>
>> You still have not answered the question .... are you using
>> attributes? If so, what are the limitations you have? If not, why no?
>
>
> Tone it down big guy. I am juggling three different thought processes
> currently, and I am not in a position to give a more clear answer just
> yet. Maybe later, but right now I am juggling too many things and quite
> frankly the ones that pay me have higher priority.
Oh, OK, so you have not actually tried to use what is already there.
Gosh, I thought that maybe you were dealing with a real problem.
My apologies.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>
>> Stephen McConnell wrote:
>>
>>
>>> Stephen McConnell wrote:
>>> >> No. I didn't ask for the ramifications .. I just asked you
>>> >> what your underlying reasons were. Presumably you are trying
>>> >> to do *something* and its not easy to do.
>>> >>
>>> >> What is that *something*?
>>>
>>> What is it that you are trying to do and cannot do with the existing
>>> attributes specification?
>>
>>
>>
>> Integrate with Fortress easily.
>
>
>
> Specifically what? Can you try and expand just a little? Something
> concrete would go a long way in clarifying your desire to change a
> perfectly good package. As things stand you have only presented the
> desire but the rationalization sucks big time. Let's stop the
> discussion on solutions to an undeclared problem - and get down to the
> actual declaration of the problem - your statement "Integrate with
> Fortress easily" does not provide me with anything useful.
>
> You still have not answered the question .... are you using attributes?
> If so, what are the limitations you have? If not, why no?
Tone it down big guy. I am juggling three different thought processes
currently, and I am not in a position to give a more clear answer just
yet. Maybe later, but right now I am juggling too many things and quite
frankly the ones that pay me have higher priority.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>
>> Stephen McConnell wrote:
>> >> No. I didn't ask for the ramifications .. I just asked you
>> >> what your underlying reasons were. Presumably you are trying
>> >> to do *something* and its not easy to do.
>> >>
>> >> What is that *something*?
>>
>> What is it that you are trying to do and cannot do with the existing
>> attributes specification?
>
>
> Integrate with Fortress easily.
Specifically what? Can you try and expand just a little? Something
concrete would go a long way in clarifying your desire to change a
perfectly good package. As things stand you have only presented the
desire but the rationalization sucks big time. Let's stop the
discussion on solutions to an undeclared problem - and get down to the
actual declaration of the problem - your statement "Integrate with
Fortress easily" does not provide me with anything useful.
You still have not answered the question .... are you using attributes?
If so, what are the limitations you have? If not, why no?
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> Stephen McConnell wrote:
> >> No. I didn't ask for the ramifications .. I just asked you
> >> what your underlying reasons were. Presumably you are trying
> >> to do *something* and its not easy to do.
> >>
> >> What is that *something*?
>
> What is it that you are trying to do and cannot do with the existing
> attributes specification?
Integrate with Fortress easily.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>
>> Can you point me to some concrete examples where third party
>> classloaders cannot access resources in a jar file? It's not a
>> problem I'm seeing. In fact I would be really surprised if this was a
>> real problem as it would negate just about any real application out
>> there.
>>
>
> It definitely used to be a problem with IBM WebSphere, hopefully they have
> since fixed it.
OK - I don't use WebSphere.
Irrespective of that, can we can back to the question:
Stephen McConnell wrote:
>> No. I didn't ask for the ramifications .. I just asked you
>> what your underlying reasons were. Presumably you are trying
>> to do *something* and its not easy to do.
>>
>> What is that *something*?
What is it that you are trying to do and cannot do with the existing
attributes specification?
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> Can you point me to some concrete examples where third party
> classloaders cannot access resources in a jar file? It's not a problem
> I'm seeing. In fact I would be really surprised if this was a real
> problem as it would negate just about any real application out there.
>
It definitely used to be a problem with IBM WebSphere, hopefully they have
since fixed it.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>> Berin Loritsch wrote:
>>
>>> In order to solve "model" issues much easier and much more flexibly,
>>
>>
>> What "model" issues are your referring to?
>
>
> Sometimes new features need new meta info to help fine tune those features.
> For instance, dynamic generation of intrumentation points, or JMX control
> points. It would be easier to handle these with a less strict meta model
> than the one under the Meta system.
Have you tried using attributes which are part of the model definition.
On those occasions where I need supplementary info I just add a single
attribute which I use to flag a component as having additional
collocated info. Using this approach I can basically do what I want
without breaking any apis or serial forms.
> I also do view and always have viewed the keeping of the meta info in
> separate files from the class as a weakness in the system. I have
> worked with too many third party classloaders that were broken to make
> that not work. Not to mention the serialized meta info would be broken
> if passed between different JVMs.
Can you point me to some concrete examples where third party
classloaders cannot access resources in a jar file? It's not a problem
I'm seeing. In fact I would be really surprised if this was a real
problem as it would negate just about any real application out there.
>>
>> Keep in mind that the Avalon Meta package is about meta-info
>> associated with component types and service definitions. There are no
>> issues with this that I am aware of. Certainly nothing has been
>> posted to the list on this subject.
>
>
> Only that the storage in XML is not a good thing and the inflexibility of
> that model stifles innovation without breaking the system.
So what we are actually talking about is the XML format (and the related
internalization and externalization processes)? If extensibility of the
XML format is the issue - then that something that can be addressed
without breaking the existing format - but that's not the same as what
your proposing.
>>> I propose to use the work that Leo did a while back with the
>>> Attributes embedded in the class file itself. It is a much more
>>> flexible way of doing things which will not require future
>>> modifications to the meta model to take care of enhancements.
>>
>>
>> The only enhancement I am aware of is the discussion concerning code
>> security. That could be easily addresses under the current approach
>> by extending the definition without breaking any existing component
>> meta-info definitions.
>
>
> It is a refactoring primarily, which will allow for more creative solutions
> in the future. The current model and way of accessing it is not very
> friendly to incorporating into any other existing container (AKA Fortress).
> These are true concerns.
Have you experimented with the declaration of attributes using the
existing meta info model?
http://avalon.apache.org/meta/meta/info/attributes/index.html
>
>> Can we go back to the underlying reason for the proposal, and
>> secondly, how the proposal will ensure that existing XML and serial
>> representations are supported.
>
>
> The current meta package would have to be kept for a while until all have
> migrated to the newer format. The actual objects created and accessed by
> Merlin would be consistent with the new attribute system, but we would have
> to maintain the current XML representations. The serial representations
> are problematic for other JVM and classloader reasons.
No. I didn't ask for the ramifications .. I just asked you what your
underlying reasons were. Presumably you are trying to do *something*
and its not easy to do.
What is that *something*?
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>
>> In order to solve "model" issues much easier and much more flexibly,
>
> What "model" issues are your referring to?
Sometimes new features need new meta info to help fine tune those features.
For instance, dynamic generation of intrumentation points, or JMX control
points. It would be easier to handle these with a less strict meta model
than the one under the Meta system.
I also do view and always have viewed the keeping of the meta info in separate
files from the class as a weakness in the system. I have worked with too many
third party classloaders that were broken to make that not work. Not to
mention the serialized meta info would be broken if passed between different
JVMs.
>
> Keep in mind that the Avalon Meta package is about meta-info associated
> with component types and service definitions. There are no issues with
> this that I am aware of. Certainly nothing has been posted to the list
> on this subject.
Only that the storage in XML is not a good thing and the inflexibility of
that model stifles innovation without breaking the system.
>> I propose to use the work that Leo did a while back with the
>> Attributes embedded in the class file itself. It is a much more
>> flexible way of doing things which will not require future
>> modifications to the meta model to take care of enhancements.
>
> The only enhancement I am aware of is the discussion concerning code
> security. That could be easily addresses under the current approach by
> extending the definition without breaking any existing component
> meta-info definitions.
It is a refactoring primarily, which will allow for more creative solutions
in the future. The current model and way of accessing it is not very friendly
to incorporating into any other existing container (AKA Fortress). These
are true concerns.
> Can we go back to the underlying reason for the proposal, and secondly,
> how the proposal will ensure that existing XML and serial
> representations are supported.
The current meta package would have to be kept for a while until all have
migrated to the newer format. The actual objects created and accessed by
Merlin would be consistent with the new attribute system, but we would have
to maintain the current XML representations. The serial representations are
problematic for other JVM and classloader reasons.
The main thing is to migrate from rigid to firm. This will also help us
prepare for the migration to JDK 1.5 when it comes.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Changing Meta Package
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> In order to solve "model" issues much easier and much more flexibly,
What "model" issues are your referring to?
Keep in mind that the Avalon Meta package is about meta-info associated
with component types and service definitions. There are no issues with
this that I am aware of. Certainly nothing has been posted to the list
on this subject.
> I propose to use the work that Leo did a while back with the
> Attributes embedded in the class file itself. It is a much
> more flexible way of doing things which will not require future
> modifications to the meta model to take care of enhancements.
The only enhancement I am aware of is the discussion concerning code
security. That could be easily addresses under the current approach by
extending the definition without breaking any existing component
meta-info definitions.
Can we go back to the underlying reason for the proposal, and secondly,
how the proposal will ensure that existing XML and serial
representations are supported.
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org