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 2003/02/11 06:06:32 UTC
[Proposal] Avalon Framework 4.1.4 RC 3
I have improved the framework build some, so that the announcements are
built again. The changes are also back in. I want to provide ample
time for anyone to bring up issues with the build. PLEASE, find any and
all issues and bring them up now--no matter how minor.
It looks like LogKit 1.2 rc7 will be on schedule for a new release on
Monday Feb. 17, 2003. After that I want to focus my full attention on
the Framework release. If we can get Framework ready for vote by the
end of next week at the latest, I would be *really* happy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> I have improved the framework build some, so that the announcements are
> built again. The changes are also back in. I want to provide ample
> time for anyone to bring up issues with the build. PLEASE, find any and
> all issues and bring them up now--no matter how minor.
systematically going through everything right now. I'll be patching docs
for the next two days or so I guess (don't plan on changing anything not
between /** ... */).
The only things that could possibly be marked as major (looking at `cvs
diff -u -r Avalon_4_1_3 src/java`) include:
- WrapperComponentManager/Selector (new, but I think we voted 'em in)
- WrapperServiceManager/Selector (new, same comment)
- Logkit2AvalonLoggerAdapter (new, not voted upon, but highly needed and
usable. No testcase but it works correctly; been verified to do so in
production env)
- deprecation warnings (we've agreed to replace some of those with
"soft" deprecation warnings, up for decision are the ones on those
relating to the suspension part of the lifecycle)
I want to take one more look at the buildfiles, too. Will be done by
monday though.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote, On 11/02/2003 6.09:
> Berin Loritsch wrote:
>
>> I have improved the framework build some, so that the announcements are
>> built again. The changes are also back in. I want to provide ample
>> time for anyone to bring up issues with the build. PLEASE, find any and
>> all issues and bring them up now--no matter how minor.
>>
>> It looks like LogKit 1.2 rc7 will be on schedule for a new release on
>> Monday Feb. 17, 2003. After that I want to focus my full attention on
>> the Framework release. If we can get Framework ready for vote by the
>> end of next week at the latest, I would be *really* happy.
>
>
> Ok. I found my first issue. The changes.xml document is being
> referenced somewhere in the XDocs, and it does not fit the Forrest
> DTDs. We need to fix this. I will look at it tomorrow unless someone
> beats me to it.
I can fix it pretty easily in the next hours (have a meeting now).
Also the "developing with Avalon" are working on my HD with docbook,
we'll do a release in these days and then I'll commit the docbook
additions later. It's a big change (at least from a feature-set view) so
we want to release other fixes first.
> However, along with the rest of my family, I am sick--so I am not sure
> how quickly I can do it.
:-(
Get better!
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
> I have improved the framework build some, so that the announcements are
> built again. The changes are also back in. I want to provide ample
> time for anyone to bring up issues with the build. PLEASE, find any and
> all issues and bring them up now--no matter how minor.
>
> It looks like LogKit 1.2 rc7 will be on schedule for a new release on
> Monday Feb. 17, 2003. After that I want to focus my full attention on
> the Framework release. If we can get Framework ready for vote by the
> end of next week at the latest, I would be *really* happy.
Ok. I found my first issue. The changes.xml document is being
referenced somewhere in the XDocs, and it does not fit the Forrest
DTDs. We need to fix this. I will look at it tomorrow unless someone
beats me to it.
However, along with the rest of my family, I am sick--so I am not sure
how quickly I can do it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 12 Feb 2003 22:56, Peter Royal wrote:
> Yup, thats all I'm asking. And we can point users towards a more
> full-featured (proxying) wrapper in the documentation also :)
Or not given that the three avalon users of the Wrapper stuff have different
policys for proxying.
--
Cheers,
Peter Donald
---------------------------------------------------
"It is easy to dodge our responsibilities, but we
cannot dodge the consequences of dodging our
responsibilities." -Josiah Stamp
---------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Peter Royal <pr...@apache.org>.
On Wednesday, February 12, 2003, at 03:21 AM, Stephen McConnell wrote:
> Ok - looks like I'm in the minority on this one :-)
> Conclusion - the the class in question "WrapperComponetManager" needs
> some supplimentary documentation detaililing that fact that lookups
> may only be applied that will result in resolution of a object that
> implements the Component interface. I.e. no attempt is made to wrap
> non-Component instances as Component.
>
> Sounds reasonable?
Yup, thats all I'm asking. And we can point users towards a more
full-featured (proxying) wrapper in the documentation also :)
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Stephen McConnell <mc...@apache.org>.
Peter Royal wrote:
> On Tuesday, February 11, 2003, at 01:49 PM, Stephen McConnell wrote:
>
>> 1. Fortress appears to be assuming that the will correctly
>> handling the Component proxy case and as far as I can see it
>> will fail when used in a real migration scenario (refer
>> ComponentFactory usage).
>
>
> Not a problem, as that that ComponentFactory is wrapped with a
> ProxyObjectFactory that puts Component on.
>
>> 2. The Phoenix case will result in container specific code because
>> authors are assuming that the container will automatically
>> proxy everything to Component.
>
>
> I'm not assuming that, I'm leveraging that. If I was writing
> container-agnostic code I would use a proxying wrapper.
> -pete
Ok - looks like I'm in the minority on this one :-)
Conclusion - the the class in question "WrapperComponetManager" needs
some supplimentary documentation detaililing that fact that lookups may
only be applied that will result in resolution of a object that
implements the Component interface. I.e. no attempt is made to wrap
non-Component instances as Component.
Sounds reasonable?
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: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, February 11, 2003, at 01:49 PM, Stephen McConnell wrote:
> 1. Fortress appears to be assuming that the will correctly
> handling the Component proxy case and as far as I can see it
> will fail when used in a real migration scenario (refer
> ComponentFactory usage).
Not a problem, as that that ComponentFactory is wrapped with a
ProxyObjectFactory that puts Component on.
> 2. The Phoenix case will result in container specific code because
> authors are assuming that the container will automatically
> proxy everything to Component.
I'm not assuming that, I'm leveraging that. If I was writing
container-agnostic code I would use a proxying wrapper.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Stephen McConnell wrote:
>
>> Wrapper classes (major)
>> -----------------------
>>
>> The wrapper classes that that exist in framework are broken. The
>> WrapperComponentManager takes a ServiceManager as a constructor argument
>> and when lookup invocations are made against the wrapper, the wrapper
>> returns Component instance "if and only if the object returned from a
>> lookup on the service manager is an instance of Component". The wrapper
>> makes no attempt to proxy an Object as a Component.
>
>
> I like this behaviour. It is quite simple and deterministic.
Read on ...
> I use these classes in code that is "pseudo-avalon", where there is no
> "real" container. I recognize the need for proxies in many
> applications, but the setup provided by these wrappers needs to be
> provided as well.
>
> I prefer to have them in a seperate jar (in addition to the main jar)
> so that they can be used without upgrading avalon-framework.jar. In
> fact, I have such a (custom-built) jar in daily use. Dunno how
> widespread the need for something like that is though.
Have been doing a little looking around and it seems what's using
WrapperComponentManager (which is the offending class) what what
assumptions are being made.
1. Fortress appears to be assuming that the will correctly
handling the Component proxy case and as far as I can see it
will fail when used in a real migration scenario (refer
ComponentFactory usage).
2. The Phoenix case will result in container specific code because
authors are assuming that the container will automatically
proxy everything to Component. The behaviour in Phoniex is
equivalent to what it would be if we were handling the case
properly in the WrapperComponentManager - except in this
case we have a solution that is partly in Phoneix and partly
in the wrapper class.
Still seems to me that this needs some cleaning up or moving before
releasing 4.1.4.
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: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> Wrapper classes (major)
> -----------------------
>
> The wrapper classes that that exist in framework are broken. The
> WrapperComponentManager takes a ServiceManager as a constructor argument
> and when lookup invocations are made against the wrapper, the wrapper
> returns Component instance "if and only if the object returned from a
> lookup on the service manager is an instance of Component". The wrapper
> makes no attempt to proxy an Object as a Component.
I like this behaviour. It is quite simple and deterministic. I use these
classes in code that is "pseudo-avalon", where there is no "real"
container. I recognize the need for proxies in many applications, but
the setup provided by these wrappers needs to be provided as well.
I prefer to have them in a seperate jar (in addition to the main jar) so
that they can be used without upgrading avalon-framework.jar. In fact, I
have such a (custom-built) jar in daily use. Dunno how widespread the
need for something like that is though.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
>
> Documetation Updates (minor)
> ----------------------------
>
> The framework documentation concerning COP uses several examples of how
> a container supplies resources to a component. These examples all use
> the
> deprecated CM and CS classes. I recommend we get that cleaned up by
> simply
> upgrading the documentation to the corresponding service package class
> and
> interface names.
Fixed.
--
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: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Cocoon running as a servlet inside of Sevak inside of Phoenix.
Keep in mind that we'd like to be able to run Cocoon inside of James, too,
even if we have converted James to the new APIs.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, February 11, 2003, at 11:20 AM, Stephen McConnell wrote:
> Not sure what you use-case is - but my understanding of the purpose of
> these classes is to aid migration from CM -> SM.
That is the purpose. My use case is thus:
Cocoon running as a servlet inside of Sevak inside of Phoenix.
Cocoon is ECM-based and thus needs a parent ComponentManager, not
ServiceManager. Since the services it will be accessing are all other
phoenix blocks, which have the Component interface already added via a
dynamic proxy, there is no need for anything beyond what the current
implementation does.
> Do you have a problem with these classes moving out of the framework
> and into a seperate jar? At least if we do that we can make sure we
> have a complete migration solution.
Yes. As long as the current classes are documented as to their
behavior, I do not believe they pose a problem. I have no problem with
a separate jar providing a more robust wrapper though. I just do not
see the need to remove the current, simple, wrappers.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Stephen McConnell <mc...@apache.org>.
Peter Royal wrote:
> On Tuesday, February 11, 2003, at 01:06 AM, Stephen McConnell wrote:
>
>> Wrapper classes (major)
>> -----------------------
>>
>> The wrapper classes that that exist in framework are broken. The
>> WrapperComponentManager takes a ServiceManager as a constructor argument
>> and when lookup invocations are made against the wrapper, the wrapper
>> returns Component instance "if and only if the object returned from a
>> lookup on the service manager is an instance of Component". The wrapper
>> makes no attempt to proxy an Object as a Component.
>
>
> I have no problem with the wrappers the way they are. What you mention
> is indeed a limitation, but they have known deterministic behavior. We
> can create another project with proxying wrappers as you suggest if
> needed.
> -pete
Pete:
Not sure what you use-case is - but my understanding of the purpose of
these classes is to aid migration from CM -> SM. This means existing
clients that implement Composable would be supplied with a
WrapperComponentManager. As different components move from CM to SM,
they are going to appear as non-Component components - and with the
current implementation - it will fail. I don't think this is a very
satisfactory solution because the behavior of the wrapper will be
inconsistent with the behavior of a DefaultComponentManager or any other
ComponentManager implementation.
Do you have a problem with these classes moving out of the framework and
into a seperate jar? At least if we do that we can make sure we have a
complete migration solution.
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: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
> On Tuesday, February 11, 2003, at 01:06 AM, Stephen McConnell wrote:
>
>> Wrapper classes (major)
>> -----------------------
>>
>> The wrapper classes that that exist in framework are broken. The
>> WrapperComponentManager takes a ServiceManager as a constructor argument
>> and when lookup invocations are made against the wrapper, the wrapper
>> returns Component instance "if and only if the object returned from a
>> lookup on the service manager is an instance of Component". The wrapper
>> makes no attempt to proxy an Object as a Component.
>
>
> I have no problem with the wrappers the way they are. What you mention
> is indeed a limitation, but they have known deterministic behavior. We
> can create another project with proxying wrappers as you suggest if needed.
> -pete
We can make it very plainly stated that these wrappers do not perform
proxying.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, February 11, 2003, at 01:06 AM, Stephen McConnell wrote:
> Wrapper classes (major)
> -----------------------
>
> The wrapper classes that that exist in framework are broken. The
> WrapperComponentManager takes a ServiceManager as a constructor
> argument
> and when lookup invocations are made against the wrapper, the wrapper
> returns Component instance "if and only if the object returned from a
> lookup on the service manager is an instance of Component". The
> wrapper
> makes no attempt to proxy an Object as a Component.
I have no problem with the wrappers the way they are. What you mention
is indeed a limitation, but they have known deterministic behavior. We
can create another project with proxying wrappers as you suggest if
needed.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> I have improved the framework build some, so that the announcements are
> built again. The changes are also back in. I want to provide ample
> time for anyone to bring up issues with the build. PLEASE, find any and
> all issues and bring them up now--no matter how minor.
One major issue, one minor issue:
1. wrapper classes issue needs to be resolved
2. documentation update needed (ComponentManager to ServiceManager)
Wrapper classes (major)
-----------------------
The wrapper classes that that exist in framework are broken. The
WrapperComponentManager takes a ServiceManager as a constructor argument
and when lookup invocations are made against the wrapper, the wrapper
returns Component instance "if and only if the object returned from a
lookup on the service manager is an instance of Component". The wrapper
makes no attempt to proxy an Object as a Component.
The above problem resulted in failure when testing against the James
platform. This problem was resolved by putting in place a working version
under the assembly package that automatically generated a Component
using the JDK 1.3 Proxy class.
Refer:
org.apache.avalon.assembly.lifecyycle.context.WrapperComponentManager
I'm presuming that the Proxy from Object to Component was not included in
the framework due to the JDK version dependency. I recommend that we move
the wrapper classes out of framework and into an Excalibur utility package
such as Excalibur/legacy.
Documetation Updates (minor)
----------------------------
The framework documentation concerning COP uses several examples of how
a container supplies resources to a component. These examples all use the
deprecated CM and CS classes. I recommend we get that cleaned up by simply
upgrading the documentation to the corresponding service package class and
interface names.
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: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Leo Simons <le...@apache.org>.
Pete:
>>>I don't recall whether we have separated out impl and
>>interfaces yet.
Steve:
>>
>>I agree.
>>
>>How do others feel about getting this in place now?
>
Leo:
> If this means no changes to package names, and that we'll have
>
> avalon-framework.jar
> avalon-framework-impl.jar
>
> then I'm fine with that.
+1
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>>
>> The thing is that doing the separation in A4 would cause more problems
>> than it would solve. Consider the mess we have with "soft" deprecation
>> already. Now compound that with having to deprecate all the current
>> implementations and point others to where they are newly implemented.
>> It is a logistical nightmare.
>
> As I understand things - this is simply a question of breaking out the
> implementation classes that have strong dependencies and putting them
> into a separate jar file. The impact on users is to include two jar
> files instead of one (although an combined jar is still a possible
> option). This has nothing to do with deprecation (soft or otherwise). I
> really don't follow your reasoning on this.
> Can you explain your concerns more fully?
I do prefer having a combined jar, along with the broken up jars. That
way folks who want the status quo aren't inconvenienced, and folks who
want the flexibility of the new can take advantage of it.
>> Already, Cocoon had problems with our
>> zealous deprecation of the component.* package. Forcing all our users
>> to change package names just for the sake of separation of
>> implementation and interface without a major version change will cause
>> more Public Relations (PR) damage than solving technical problems.
>
> Nobody is suggesting any package name change. What is being suggested
> is the separation of classes that have strong implementation
> dependencies from those that are self contained within the framework.
> In my earlier reply I presented an example - the AvalonFormatter. This
> is an example of a class that has a strong dependency on LogKit. The
> existence of this class in the framework creates a strong dependency on
> LogKit. The suggestion is that such "implementation" classes be moved
> to an "implementation jar file that can coexist along side a client
> framework jar file.
And that was the source of the confusion.
>> The reality is that Merlin and Phoenix are doing more things with the
>> classloaders and other detailed things that most programmers don't
>> delve into. The problems they face aren't the problems the majority
>> of us face.
>
>
> This is where things get dangerous.
>
> Your putting forward an assumption that may be true in your environment
> - but is not true in my environment. Your positioning yourself as
> representing a majority and delegating the "minority-view" to anyone
> more aligned to the Phoenix/Merlin view of management (a.k.a. != your
> view). You came up with similar justification on the LogKit release as
> to why things should not change - and that lead nowhere. Maybe we
> should avoid this style of rationalization and instead focus on the
> assumption that the priorities and interests of everyone here are equal?
I think you are reading more into what I said than what is there. All
I was saying is that for Merlin and Phoenix (the two larger, more
powerful containers) they do more with the ClassLoader than the other
containers we have. This is truth, is it not?
Most Java developers that have not delved into the areas we deal with
as container writers are intimidated by classloaders. Perhaps this
is a trend that I alone see here in the East Coast of the U.S.?
Read nothing more into it than that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> What do you think?
I think Berin's comments were based on the assumption that
packages would be renamed.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>>
>> Peter Donald wrote:
>>
>>> On Tue, 11 Feb 2003 16:06, Berin Loritsch wrote:
>>>
>>>
>>>> I have improved the framework build some, so that the announcements
>>>> are
>>>> built again. The changes are also back in. I want to provide ample
>>>> time for anyone to bring up issues with the build. PLEASE, find
>>>> any and
>>>> all issues and bring them up now--no matter how minor.
>>>>
>>>
>>>
>>>
>>> I don't recall whether we have separated out impl and interfaces
>>> yet. At bare minimum we have to be able to have all
>>> xalan/xerces/logkit/log4j/etc classes in separate jars
>>>
>>
>> I agree. The current packaging complicates life if you trying to
>> construct
>> clean classloader hierachies (you end up duplicating the framework
>> jar on both internal and external loaders because the framework
>> classes have implementation dependencies - e.g. use of AvalonFormatter
>> requires LogKit in the classloader hierachy at or above AvalonFormatter
>> which means that you canot share the framework jar).
>>
>> How do others feel about getting this in place now? If we are going to
>> do it we kind of need to to do ASAP otherwise we should put it down as
>> an action item for the subseequent release.
>
>
> The thing is that doing the separation in A4 would cause more problems
> than it would solve. Consider the mess we have with "soft" deprecation
> already. Now compound that with having to deprecate all the current
> implementations and point others to where they are newly implemented.
> It is a logistical nightmare.
As I understand things - this is simply a question of breaking out the
implementation classes that have strong dependencies and putting them
into a separate jar file. The impact on users is to include two jar
files instead of one (although an combined jar is still a possible
option). This has nothing to do with deprecation (soft or otherwise). I
really don't follow your reasoning on this.
Can you explain your concerns more fully?
> Already, Cocoon had problems with our
> zealous deprecation of the component.* package. Forcing all our users
> to change package names just for the sake of separation of
> implementation and interface without a major version change will cause
> more Public Relations (PR) damage than solving technical problems.
Nobody is suggesting any package name change. What is being suggested
is the separation of classes that have strong implementation
dependencies from those that are self contained within the framework.
In my earlier reply I presented an example - the AvalonFormatter. This
is an example of a class that has a strong dependency on LogKit. The
existence of this class in the framework creates a strong dependency on
LogKit. The suggestion is that such "implementation" classes be moved
to an "implementation jar file that can coexist along side a client
framework jar file.
> The reality is that Merlin and Phoenix are doing more things with the
> classloaders and other detailed things that most programmers don't
> delve into. The problems they face aren't the problems the majority
> of us face.
This is where things get dangerous.
Your putting forward an assumption that may be true in your environment
- but is not true in my environment. Your positioning yourself as
representing a majority and delegating the "minority-view" to anyone
more aligned to the Phoenix/Merlin view of management (a.k.a. != your
view). You came up with similar justification on the LogKit release as
to why things should not change - and that lead nowhere. Maybe we
should avoid this style of rationalization and instead focus on the
assumption that the priorities and interests of everyone here are equal?
I think we need to step back - throw away the notion that there is a
right point of view - and think about this in terms of the "real"
issues. The real issue is "do-we-want-to-do-this-now" as opposed to
"doing-it-later". The answer to that question is independent of the
"world-view". It is dependent on the priorities that we the commiters
have. I can confirm that the current structure of the framework jar
file has caused me problems. I'm guessing that I'm probably not alone.
I'm confident that Pete has experienced some of the same concerns that I
have - and I know that some of the guys on the user list have run into
trouble in this area as well.
So - to the question - do it now or do it later? I think its a good
idea to do it now. I figure it will take a couple of days to get the
changes to the build in place and a couple of days for validation. I
also think we could provide a bundled jar that includes the client and
the implementation classes that could be used by users such as Cocoon
et. al. I.e. I don't think there is a user conflict argument here - in
fact I think there is simply a win-win-scenario.
What do you think?
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: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>Forcing all our users to change package names
>
>
> No!
>
> The proposal was just regarding what classes go into what JAR
> files. No package renaming.
Whew!
You had me scared for a moment. If we offer that option,
still offer the "monolithic" option as well. It is a popular
feature for ECM and Fortress to include all the Excalibur
code they need to operate into one big JAR. It is convenient.
Also it is something that does require some additional documentation.
I don't think we would really have the time to put that all in place
before a release. You are welcome to prove me wrong, though.
What bothers me most about the proposed separation of JARs is really
that we have to almost specify class by class what gets included in
which JAR. Certain packages are all interfaces, but others have a
mixture. It isn't really intuitive when or where those separations
would occur. That is with my "user" hat on.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Forcing all our users to change package names
No!
The proposal was just regarding what classes go into what JAR
files. No package renaming.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Peter Donald wrote:
>
>> On Tue, 11 Feb 2003 16:06, Berin Loritsch wrote:
>>
>>
>>> I have improved the framework build some, so that the announcements are
>>> built again. The changes are also back in. I want to provide ample
>>> time for anyone to bring up issues with the build. PLEASE, find any and
>>> all issues and bring them up now--no matter how minor.
>>>
>>
>>
>> I don't recall whether we have separated out impl and interfaces yet.
>> At bare minimum we have to be able to have all
>> xalan/xerces/logkit/log4j/etc classes in separate jars
>>
>
> I agree.
> The current packaging complicates life if you trying to construct
> clean classloader hierachies (you end up duplicating the framework
> jar on both internal and external loaders because the framework
> classes have implementation dependencies - e.g. use of AvalonFormatter
> requires LogKit in the classloader hierachy at or above AvalonFormatter
> which means that you canot share the framework jar).
>
> How do others feel about getting this in place now? If we are going to
> do it we kind of need to to do ASAP otherwise we should put it down as
> an action item for the subseequent release.
The thing is that doing the separation in A4 would cause more problems
than it would solve. Consider the mess we have with "soft" deprecation
already. Now compound that with having to deprecate all the current
implementations and point others to where they are newly implemented.
It is a logistical nightmare. Already, Cocoon had problems with our
zealous deprecation of the component.* package. Forcing all our users
to change package names just for the sake of separation of
implementation and interface without a major version change will cause
more Public Relations (PR) damage than solving technical problems.
The reality is that Merlin and Phoenix are doing more things with the
classloaders and other detailed things that most programmers don't
delve into. The problems they face aren't the problems the majority
of us face.
Would we like the separation in the future? Absolutely! But I fear
that it would be best to put that off into A5 instead of any A4 release.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Peter Donald wrote:
>>
>>
>>
>>>On Tue, 11 Feb 2003 16:06, Berin Loritsch wrote:
>>>
>>>
>>>
>>>
>>>>I have improved the framework build some, so that the announcements
>>>>are built again. The changes are also back in. I want to provide
>>>>ample time for anyone to bring up issues with the build.
>>>>
>>>>
>>PLEASE, find
>>
>>
>>>>any and all issues and bring them up now--no matter how minor.
>>>>
>>>>
>>>>
>>>>
>>>I don't recall whether we have separated out impl and
>>>
>>>
>>interfaces yet.
>>
>>
>>>At bare
>>>minimum we have to be able to have all
>>>
>>>
>>xalan/xerces/logkit/log4j/etc classes
>>
>>
>>>in separate jars
>>>
>>>
>>>
>>I agree.
>>
>>The current packaging complicates life if you trying to
>>construct clean classloader hierachies (you end up
>>duplicating the framework jar on both internal and external
>>loaders because the framework classes have implementation
>>dependencies - e.g. use of AvalonFormatter requires LogKit in
>>the classloader hierachy at or above AvalonFormatter which
>>means that you canot share the framework jar).
>>
>>How do others feel about getting this in place now? If we
>>are going to do it we kind of need to to do ASAP otherwise we
>>should put it down as an action item for the subseequent release.
>>
>>Cheers, Steve.
>>
>>
>
>If this means no changes to package names, and that we'll have
>
> avalon-framework.jar
> avalon-framework-impl.jar
>
>then I'm fine with that.
>
No need to change package names - just some fine-grain selective
reasoning in the build file.
Cheers, Steve.
>
>/LS
>
>
>---------------------------------------------------------------------
>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: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Peter Donald wrote:
>
> >On Tue, 11 Feb 2003 16:06, Berin Loritsch wrote:
> >
> >
> >>I have improved the framework build some, so that the announcements
> >>are built again. The changes are also back in. I want to provide
> >>ample time for anyone to bring up issues with the build.
> PLEASE, find
> >>any and all issues and bring them up now--no matter how minor.
> >>
> >>
> >
> >I don't recall whether we have separated out impl and
> interfaces yet.
> >At bare
> >minimum we have to be able to have all
> xalan/xerces/logkit/log4j/etc classes
> >in separate jars
> >
>
> I agree.
>
> The current packaging complicates life if you trying to
> construct clean classloader hierachies (you end up
> duplicating the framework jar on both internal and external
> loaders because the framework classes have implementation
> dependencies - e.g. use of AvalonFormatter requires LogKit in
> the classloader hierachy at or above AvalonFormatter which
> means that you canot share the framework jar).
>
> How do others feel about getting this in place now? If we
> are going to do it we kind of need to to do ASAP otherwise we
> should put it down as an action item for the subseequent release.
>
> Cheers, Steve.
If this means no changes to package names, and that we'll have
avalon-framework.jar
avalon-framework-impl.jar
then I'm fine with that.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Tue, 11 Feb 2003 16:06, Berin Loritsch wrote:
>
>
>>I have improved the framework build some, so that the announcements are
>>built again. The changes are also back in. I want to provide ample
>>time for anyone to bring up issues with the build. PLEASE, find any and
>>all issues and bring them up now--no matter how minor.
>>
>>
>
>I don't recall whether we have separated out impl and interfaces yet. At bare
>minimum we have to be able to have all xalan/xerces/logkit/log4j/etc classes
>in separate jars
>
I agree.
The current packaging complicates life if you trying to construct
clean classloader hierachies (you end up duplicating the framework
jar on both internal and external loaders because the framework
classes have implementation dependencies - e.g. use of AvalonFormatter
requires LogKit in the classloader hierachy at or above AvalonFormatter
which means that you canot share the framework jar).
How do others feel about getting this in place now? If we are going to
do it we kind of need to to do ASAP otherwise we should put it down as
an action item for the subseequent release.
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: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 11 Feb 2003 16:06, Berin Loritsch wrote:
> I have improved the framework build some, so that the announcements are
> built again. The changes are also back in. I want to provide ample
> time for anyone to bring up issues with the build. PLEASE, find any and
> all issues and bring them up now--no matter how minor.
I don't recall whether we have separated out impl and interfaces yet. At bare
minimum we have to be able to have all xalan/xerces/logkit/log4j/etc classes
in separate jars
--
Cheers,
Peter Donald
------------------------------------------------------
Mark Twain: "In the real world, the right thing never
happens in the right place at the right time. It is
the task of journalists and historians to rectify
this error."
------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> Leo Sutic wrote:
>
> We do have a contract for these interfaces (at
> http://avalon.apache.org/framework/reference-the-lifecycle.html, and
> codified in excalibur-utils ComponentStateValidator), even if
> underspecified. There is just not a container that makes use of them.
> Note that the Re* contract _is_ supported: the re*() methods are not
> guaranteed to be called, so they are simply not called :D
So in practice, they are not supported ;P
>
> I guess it has been shown in real life that most components managed by
> an avalon container are either inexpensive enough that it is a good
> option to just recreate them, or there is never a need to suspend
> long-running services, or some other mechanism is used for reconfiguring
> those.
Yep.
>
> The question that comes to mind is whether someone somewhere has indeed
> found a need for Re* and is using them. Dunno. How sure are we that
> there is no real-life use for the suspension concept?
Suspension, Probably. THe Re*? I haven't run into anyone.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Leo Simons <le...@apache.org>.
Leo Sutic wrote:
> 1. Marker interfaces ThreadSafe, SingleThreaded: How about doing a
> "soft" deprecation
> of them in the same way as we did for component manager et al?
sounds good.
> 2. Recomposable is (softly) deprecated with the text:
>
> The Reconfigurable interface is a legacy interface with no
> concrete contracts.
>
> Reconfigurable has no deprecation warning at all. Should we softly
> deprecate
> all Re* interfaces, like Reconfigurable and Recontextualizable?
>
> The typo (reconfigurable instead of recomposable) should be fixed
> anyway,
> and I have done that.
We do have a contract for these interfaces (at
http://avalon.apache.org/framework/reference-the-lifecycle.html, and
codified in excalibur-utils ComponentStateValidator), even if
underspecified. There is just not a container that makes use of them.
Note that the Re* contract _is_ supported: the re*() methods are not
guaranteed to be called, so they are simply not called :D
I guess it has been shown in real life that most components managed by
an avalon container are either inexpensive enough that it is a good
option to just recreate them, or there is never a need to suspend
long-running services, or some other mechanism is used for reconfiguring
those.
The question that comes to mind is whether someone somewhere has indeed
found a need for Re* and is using them. Dunno. How sure are we that
there is no real-life use for the suspension concept?
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> 1. Marker interfaces ThreadSafe, SingleThreaded: How about doing a
> "soft" deprecation
> of them in the same way as we did for component manager et al?
>
> 2. Recomposable is (softly) deprecated with the text:
>
> The Reconfigurable interface is a legacy interface with no
> concrete contracts.
>
> Reconfigurable has no deprecation warning at all. Should we softly
> deprecate
> all Re* interfaces, like Reconfigurable and Recontextualizable?
>
> The typo (reconfigurable instead of recomposable) should be fixed
> anyway,
> and I have done that.
As to the marker interfaces, +1 to soft deprecation.
For the Re* interfaces, I personally would make them hard-deprecated.
But, I will let the community decide. We never really had any sensible
plan for using those. We kept them in for legacy's sake, and in hind-
sight, I think that was a mistake.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [Proposal] Avalon Framework 4.1.4 RC 3
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
1. Marker interfaces ThreadSafe, SingleThreaded: How about doing a
"soft" deprecation
of them in the same way as we did for component manager et al?
2. Recomposable is (softly) deprecated with the text:
The Reconfigurable interface is a legacy interface with no
concrete contracts.
Reconfigurable has no deprecation warning at all. Should we softly
deprecate
all Re* interfaces, like Reconfigurable and Recontextualizable?
The typo (reconfigurable instead of recomposable) should be fixed
anyway,
and I have done that.
/LS
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Subject: [Proposal] Avalon Framework 4.1.4 RC 3
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org