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 Donald <pe...@apache.org> on 2002/11/08 03:16:05 UTC
Fortress Backwards Compat
Hi,
Theres a few anomalies in Fortress that I would like to change but they will
break backwards compatability - so I guess I want to see if anyone objects.
The Container work interface extends ContainerConstants which is something we
have discussed in the past and decided is a bad pattern that can lead to
abuse.
The other problem is that the Container work interface extends Initializable
and Disposable where generally we try to separate lifecycle and work
interfaces.
The question is - do we fix them and break backwards compatability or do we
leave them as is?
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Religion is what the common people see as true, the |
| wise people see as false, and the rulers see as |
| useful" --Seneca |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fortress Backwards Compat
Posted by Peter Royal <pr...@apache.org>.
On Thursday, November 7, 2002, at 09:16 PM, Peter Donald wrote:
> The question is - do we fix them and break backwards compatability or
> do we
> leave them as is?
Fix now before its really too late.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fortress Backwards Compat
Posted by Peter Royal <pr...@apache.org>.
On Friday, November 8, 2002, at 11:55 AM, Peter Donald wrote:
> On Sat, 9 Nov 2002 03:41, Peter Royal wrote:
>> On Friday, November 8, 2002, at 11:41 AM, Peter Donald wrote:
>>>> That works, but I'd like to be able to pass in an array of
>>>> interfaces
>>>> to the ComponentFactory then to tell the ComponentProxyGenerator
>>>> what
>>>> to proxy for.
>>>
>>> Where do I get this array of interefaces from?
>>
>> Good question :) How were you going to handle this?
>
> I wasn't ;)
>
> I was basically going to proxy every interface that could reasonably
> considered a potential Work interface. The main reason being that
> Fortress
> does not know about exposed services as such - hence we add em all in
> by
> default. Maybe too generous but in theory it should not break backwards
> compat (unless people cast to an implementation).
Gotcha. You still need an array of interfaces to proxy by the time you
call the Proxy.newInstance method though.. that's what I was getting at
:)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fortress Backwards Compat
Posted by Peter Donald <pe...@apache.org>.
On Sat, 9 Nov 2002 03:41, Peter Royal wrote:
> On Friday, November 8, 2002, at 11:41 AM, Peter Donald wrote:
> >> That works, but I'd like to be able to pass in an array of interfaces
> >> to the ComponentFactory then to tell the ComponentProxyGenerator what
> >> to proxy for.
> >
> > Where do I get this array of interefaces from?
>
> Good question :) How were you going to handle this?
I wasn't ;)
I was basically going to proxy every interface that could reasonably
considered a potential Work interface. The main reason being that Fortress
does not know about exposed services as such - hence we add em all in by
default. Maybe too generous but in theory it should not break backwards
compat (unless people cast to an implementation).
--
Cheers,
Peter Donald
------------------------------------
The two secrets to success:
1- Don't tell anyone everything.
------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fortress Backwards Compat
Posted by Peter Royal <pr...@apache.org>.
On Friday, November 8, 2002, at 11:41 AM, Peter Donald wrote:
>> That works, but I'd like to be able to pass in an array of interfaces
>> to the ComponentFactory then to tell the ComponentProxyGenerator what
>> to proxy for.
>
> Where do I get this array of interefaces from?
Good question :) How were you going to handle this? In your original
message you said you were going to proxy all interfaces EXCEPT for:
* Lifecycle interfaces
* Lifestyle interfaces
* certain jdk interfaces (like java.io.Serializable)
So I figured there would be a static util method somewhere
getProxyableInterfaces( Class class ) or such. Other systems
(merlin/phoenix) know the service interface of the component beforehand
and could be more intelligent about this. (Assuming that this code
would have a life beyond fortress)
> That works aswell. If we want to be completely tight about it we could
> have a
>
> DefaultComponentFactory
> ProxyComponentFactory
> ProxyGenerator
>
> and the ProxyComponentFactory would delegate to
> DefaultComponentFactory and
> use the ProxyGenerator
sounds good to me :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fortress Backwards Compat
Posted by Peter Donald <pe...@apache.org>.
On Sat, 9 Nov 2002 03:30, Peter Royal wrote:
> On Friday, November 8, 2002, at 11:08 AM, Peter Donald wrote:
> >> Could we separate that into two pieces? A ComponentFactory and a
> >> ComponentProxyGenerator?
> >
> > Simple enough. But do you mind if it is still ComponentFactory that
> > calls
> > ComponentProxyGenerator and olny returns proxied instances?
>
> That works, but I'd like to be able to pass in an array of interfaces
> to the ComponentFactory then to tell the ComponentProxyGenerator what
> to proxy for.
Where do I get this array of interefaces from?
> I was actually thinking of a layered approach in the opposite
> direction. The CompoentFactory is really just an ObjectFactory. Why not
> have the ComponentProxyGenerator just be another ObjectFactory that
> takes another ObjectFactory and proxies the objects from the other
> factory? So usage might be like:
>
> ComponentFactory cf = new ComponentFactory(...);
> ComponentProxyGenerator cpg = new ComponentProxyGenerator( cf, new
> Class[] { ... } );
>
> cpg.newInstance();
>
> One could then use the ProxyGenerator wherever ObjectFactory's were
> used...
That works aswell. If we want to be completely tight about it we could have a
DefaultComponentFactory
ProxyComponentFactory
ProxyGenerator
and the ProxyComponentFactory would delegate to DefaultComponentFactory and
use the ProxyGenerator
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Religion is what the common people see as true, the |
| wise people see as false, and the rulers see as |
| useful" --Seneca |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fortress Backwards Compat
Posted by Peter Royal <pr...@apache.org>.
On Friday, November 8, 2002, at 11:08 AM, Peter Donald wrote:
>> Could we separate that into two pieces? A ComponentFactory and a
>> ComponentProxyGenerator?
>
> Simple enough. But do you mind if it is still ComponentFactory that
> calls
> ComponentProxyGenerator and olny returns proxied instances?
That works, but I'd like to be able to pass in an array of interfaces
to the ComponentFactory then to tell the ComponentProxyGenerator what
to proxy for.
I was actually thinking of a layered approach in the opposite
direction. The CompoentFactory is really just an ObjectFactory. Why not
have the ComponentProxyGenerator just be another ObjectFactory that
takes another ObjectFactory and proxies the objects from the other
factory? So usage might be like:
ComponentFactory cf = new ComponentFactory(...);
ComponentProxyGenerator cpg = new ComponentProxyGenerator( cf, new
Class[] { ... } );
cpg.newInstance();
One could then use the ProxyGenerator wherever ObjectFactory's were
used...
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fortress Backwards Compat
Posted by Peter Donald <pe...@apache.org>.
On Sat, 9 Nov 2002 01:59, Peter Royal wrote:
> On Thursday, November 7, 2002, at 11:15 PM, Peter Donald wrote:
> > One more thing. I was thinking of making ComponentFactory do all the
> > proxying
> > of services. Essentially it would only return proxies. The advantage
> > of this
> > is that all the proxying would be in one place and consistent. The
> > disadvantage is that we don't know which interfaces need to be proxied
> > so we
> > will pretty much have to proxy all of them except for ones we
> > recognize as
> > being non-proxyable. ie
> >
> > * Lifecycle interfaces
> > * Lifestyle interfaces
> > * certain jdk interfaces (like java.io.Serializable)
> >
> > It means there may be a little more exposed than strictly necessary
> > but it is
> > still better than what we have now. Thoughts?
>
> Could we separate that into two pieces? A ComponentFactory and a
> ComponentProxyGenerator?
Simple enough. But do you mind if it is still ComponentFactory that calls
ComponentProxyGenerator and olny returns proxied instances?
--
Cheers,
Peter Donald
*----------------------------------------------------------*
The phrase "computer literate user" really means the person
has been hurt so many times that the scar tissue is thick
enough so he no longer feels the pain.
-- Alan Cooper, The Inmates are Running the Asylum
*----------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fortress Backwards Compat
Posted by Peter Royal <pr...@apache.org>.
On Thursday, November 7, 2002, at 11:15 PM, Peter Donald wrote:
> One more thing. I was thinking of making ComponentFactory do all the
> proxying
> of services. Essentially it would only return proxies. The advantage
> of this
> is that all the proxying would be in one place and consistent. The
> disadvantage is that we don't know which interfaces need to be proxied
> so we
> will pretty much have to proxy all of them except for ones we
> recognize as
> being non-proxyable. ie
>
> * Lifecycle interfaces
> * Lifestyle interfaces
> * certain jdk interfaces (like java.io.Serializable)
>
> It means there may be a little more exposed than strictly necessary
> but it is
> still better than what we have now. Thoughts?
Could we separate that into two pieces? A ComponentFactory and a
ComponentProxyGenerator?
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fortress Backwards Compat
Posted by Peter Donald <pe...@apache.org>.
One more thing. I was thinking of making ComponentFactory do all the proxying
of services. Essentially it would only return proxies. The advantage of this
is that all the proxying would be in one place and consistent. The
disadvantage is that we don't know which interfaces need to be proxied so we
will pretty much have to proxy all of them except for ones we recognize as
being non-proxyable. ie
* Lifecycle interfaces
* Lifestyle interfaces
* certain jdk interfaces (like java.io.Serializable)
It means there may be a little more exposed than strictly necessary but it is
still better than what we have now. Thoughts?
--
Cheers,
Peter Donald
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fortress Backwards Compat
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
>
> On Fri, 8 Nov 2002 14:53, Berin Loritsch wrote:
> > > -----Original Message-----
> > > From: Peter Donald [mailto:peter@apache.org]
> > > Sent: Thursday, November 07, 2002 10:58 PM
> > > To: Avalon Developers List
> > > Subject: Re: Fortress Backwards Compat
> > >
> > > On Fri, 8 Nov 2002 14:15, Berin Loritsch wrote:
> > > > I know you have already put a lot of work into Fortress already.
> > > > I don't have time to document anything, so if you can
> live without
> > > > that for the time being it might be OK. In the mean time, we
> > > > might want to filter out the Kernel portion for compile time
> > > > because it is not finished yet. I have the concept of being
> > > > able to discover containers in Jars using the Fortress Kernel,
> > > > but the specifics are not yet finished.
> > > >
> > > > If you are happy with the working code, we can aim for a very
> > > > soon release, and we will put a feature freeze on Fortress.
> > >
> > > Kool. So if I create a new source tree (src/ng) and move all
> > > kernel/meta
> > > stuff into it (And possibly the jar stuff from container?)
> > > then we should be
> > > able to release it?
> >
> > yep.
> >
> > BTW, the Meta stuff is filtered out by default. It is only
> > compiled when you set a certain property (I'd have to look
> > at the ANT file to tell you what it is).
>
> Kool - btw do you mind if I re-add Kernel stuff into the new
> tree. I would
> prefer to have the source around - at least to look at for
> future reference?
go for it. Here is the source file... just to make it easier
for you.
Re: Fortress Backwards Compat
Posted by Peter Donald <pe...@apache.org>.
On Fri, 8 Nov 2002 14:53, Berin Loritsch wrote:
> > -----Original Message-----
> > From: Peter Donald [mailto:peter@apache.org]
> > Sent: Thursday, November 07, 2002 10:58 PM
> > To: Avalon Developers List
> > Subject: Re: Fortress Backwards Compat
> >
> > On Fri, 8 Nov 2002 14:15, Berin Loritsch wrote:
> > > I know you have already put a lot of work into Fortress already.
> > > I don't have time to document anything, so if you can live without
> > > that for the time being it might be OK. In the mean time, we
> > > might want to filter out the Kernel portion for compile time
> > > because it is not finished yet. I have the concept of being
> > > able to discover containers in Jars using the Fortress Kernel,
> > > but the specifics are not yet finished.
> > >
> > > If you are happy with the working code, we can aim for a very
> > > soon release, and we will put a feature freeze on Fortress.
> >
> > Kool. So if I create a new source tree (src/ng) and move all
> > kernel/meta
> > stuff into it (And possibly the jar stuff from container?)
> > then we should be
> > able to release it?
>
> yep.
>
> BTW, the Meta stuff is filtered out by default. It is only
> compiled when you set a certain property (I'd have to look
> at the ANT file to tell you what it is).
Kool - btw do you mind if I re-add Kernel stuff into the new tree. I would
prefer to have the source around - at least to look at for future reference?
--
Cheers,
Peter Donald
----------------------------------------
Whatever you do will be insignificant,
but it is very important that you do it.
--Gandhi
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fortress Backwards Compat
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Thursday, November 07, 2002 10:58 PM
> To: Avalon Developers List
> Subject: Re: Fortress Backwards Compat
>
>
> On Fri, 8 Nov 2002 14:15, Berin Loritsch wrote:
> > I know you have already put a lot of work into Fortress already.
> > I don't have time to document anything, so if you can live without
> > that for the time being it might be OK. In the mean time, we
> > might want to filter out the Kernel portion for compile time
> > because it is not finished yet. I have the concept of being
> > able to discover containers in Jars using the Fortress Kernel,
> > but the specifics are not yet finished.
> >
> > If you are happy with the working code, we can aim for a very
> > soon release, and we will put a feature freeze on Fortress.
>
> Kool. So if I create a new source tree (src/ng) and move all
> kernel/meta
> stuff into it (And possibly the jar stuff from container?)
> then we should be
> able to release it?
yep.
BTW, the Meta stuff is filtered out by default. It is only
compiled when you set a certain property (I'd have to look
at the ANT file to tell you what it is).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fortress Backwards Compat
Posted by Peter Donald <pe...@apache.org>.
On Fri, 8 Nov 2002 14:15, Berin Loritsch wrote:
> I know you have already put a lot of work into Fortress already.
> I don't have time to document anything, so if you can live without
> that for the time being it might be OK. In the mean time, we
> might want to filter out the Kernel portion for compile time
> because it is not finished yet. I have the concept of being
> able to discover containers in Jars using the Fortress Kernel,
> but the specifics are not yet finished.
>
> If you are happy with the working code, we can aim for a very
> soon release, and we will put a feature freeze on Fortress.
Kool. So if I create a new source tree (src/ng) and move all kernel/meta
stuff into it (And possibly the jar stuff from container?) then we should be
able to release it?
--
Cheers,
Peter Donald
---------------------------------------------------
"Wise men don't need advice. Fools don't take it."
-Benjamin Franklin
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fortress Backwards Compat
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
> >
> > It has not been released yet. I have been sidetracked getting
> > used to a new job.
>
> kool ;)
>
> Do you think it will be released in the near future. I was
> planning on
> adopting it for a project starting in about three weeks and
> if there was a
> release by then ... well that would be great ;)
I wish I had the time to devote to it. I wanted to establish
the Kernel concept like it is established in Pheonix and Merlin.
The core difference of course is in what the kernel does. All
the Fortress Kernel would do is create the container/root
containers and handle JNDI published components (JNDI planned
for a future version).
The reason I want to make the change is to clarify what goes
in the Context and what goes in the ServiceManager. When I
started Fortress, the ServiceManager was not yet written (talked
about but not written). As a result, I chose to pass certain
services that I deemed Container-only services. Those services
did not implement the much maligned Component interface.
Considering all the complexity in the ContextManager/ContextBuilder,
I wanted to simplify that completely. I wanted to have a
ContextBuilder that would allow me to create a context for
my containers based on a number of parameters--or even based
on other contexts like the javax.servlet.ServletContext.
As it stands, I started the work while I was in Oregon on a
temporary assignment. I probably would be done with it by
now if I had one more week out there. Currently, I am
now a paid employee with a permanent job and sufficient income
but no time. I am planning on backing out some code I did
not intentionally commit (I will have that done tomorrow) to
DataSource.
I know you have already put a lot of work into Fortress already.
I don't have time to document anything, so if you can live without
that for the time being it might be OK. In the mean time, we
might want to filter out the Kernel portion for compile time
because it is not finished yet. I have the concept of being
able to discover containers in Jars using the Fortress Kernel,
but the specifics are not yet finished.
If you are happy with the working code, we can aim for a very
soon release, and we will put a feature freeze on Fortress.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fortress Backwards Compat
Posted by Peter Donald <pe...@apache.org>.
On Fri, 8 Nov 2002 13:18, Berin Loritsch wrote:
> > From: Peter Donald [mailto:peter@apache.org]
> >
> > Hi,
> >
> > Theres a few anomalies in Fortress that I would like to
> > change but they will
> > break backwards compatability - so I guess I want to see if
> > anyone objects.
> >
> > The Container work interface extends ContainerConstants which
> > is something we
> > have discussed in the past and decided is a bad pattern that
> > can lead to
> > abuse.
>
> Yep, separate them.
done.
> > The other problem is that the Container work interface
> > extends Initializable
> > and Disposable where generally we try to separate lifecycle and work
> > interfaces.
> >
> > The question is - do we fix them and break backwards
> > compatability or do we
> > leave them as is?
>
> It has not been released yet. I have been sidetracked getting
> used to a new job.
kool ;)
Do you think it will be released in the near future. I was planning on
adopting it for a project starting in about three weeks and if there was a
release by then ... well that would be great ;)
--
Cheers,
Peter Donald
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fortress Backwards Compat
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
> Hi,
>
> Theres a few anomalies in Fortress that I would like to
> change but they will
> break backwards compatability - so I guess I want to see if
> anyone objects.
>
> The Container work interface extends ContainerConstants which
> is something we
> have discussed in the past and decided is a bad pattern that
> can lead to
> abuse.
Yep, separate them.
> The other problem is that the Container work interface
> extends Initializable
> and Disposable where generally we try to separate lifecycle and work
> interfaces.
>
> The question is - do we fix them and break backwards
> compatability or do we
> leave them as is?
It has not been released yet. I have been sidetracked getting
used to a new job.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>