commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject RE: [HiveMind] Selective intercepting
Date Fri, 19 Sep 2003 12:50:43 GMT
In other words, the "language" used to describe the application is extensible.

SpringFramework, like the alpha version of HiveMind, could only express creating objects and
setting
their properties.

Picocontainer forgoes having much of an assembly descriptor (it can be as simple as a Map),
and thus
is limited in what it can do; it can wire components together via their constructors and can
do a
small amount of property setting / configuration.

HiveMind goes beyond that; you can create rich new languages (via <parameters-schema>)
for
describing how your application should be constructed. More than just configuration, the interceptor
model means that significant parts of the service implementation can be constructed on the
fly at
runtime.

HiveMind itself is partially built in HiveMind; some of the basic services of HiveMind are
built
using BuilderFactory which is itself a service defined within HiveMind. This is what I mean
by
"feeding on itself".

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com

> -----Original Message-----
> From: Howard M. Lewis Ship [mailto:hlship@comcast.net] 
> Sent: Friday, September 19, 2003 8:43 AM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [HiveMind] Selective intercepting
> 
> 
> Right ... it's similar to the BuilderFactory that defines the 
> <construct> element as its parameter. This hypothetical 
> interceptor would define <method> elements as its parameter.
> 
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components 
> http://jakarta.apache.org/tapestry
> http://jakarta.apache.org/commons/sandbox/hivemind/
> http://javatapestry.blogspot.com
> 
> > -----Original Message-----
> > From: james@carmanconsulting.com [mailto:james@carmanconsulting.com]
> > Sent: Friday, September 19, 2003 8:28 AM
> > To: commons-dev@jakarta.apache.org
> > Subject: Re: [HiveMind] Selective intercepting
> > 
> > 
> > Now, HiveMind itself doesn't need to be aware of this
> > security stuff here, right?  These "method" elements are 
> > specific to this type of interceptor, right?
> > 
> > ----- Original Message -----
> > From: "Howard M. Lewis Ship" <hlship@comcast.net>
> > To: "'Jakarta Commons Developers List'" 
> > <commons-dev@jakarta.apache.org>
> > Sent: Friday, September 19, 2003 7:58 AM
> > Subject: RE: [HiveMind] Selective intercepting
> > 
> > 
> > > Actually, that's why we allow parameters to an interceptor.  I can
> > envision something like:
> > >
> > > <service-point ...
> > >   <interceptor service-id="foo.security">
> > >     <method name="read" role="system"/>
> > >     <method name="update" role="admin"/>
> > >     <method name="*" role="user"/>
> > >   </interceptor>
> > >
> > > --
> > > Howard M. Lewis Ship
> > > Creator, Tapestry: Java Web Components
> > > http://jakarta.apache.org/tapestry
> > > http://jakarta.apache.org/commons/sandbox/hivemind/
> > > http://javatapestry.blogspot.com
> > >
> > > > -----Original Message-----
> > > > From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net]
> > > > Sent: Thursday, September 18, 2003 11:56 PM
> > > > To: 'Jakarta Commons Developers List'
> > > > Subject: [HiveMind] Selective intercepting
> > > >
> > > >
> > > > Interceptors, as I know of them in HiveMind right now,
> > can only be
> > > > applied across the board to all methods in the service;
> > there is no
> > > > selectivity. But, I think, selective intercepting will be a
> > > > requirement for other kinds of interceptors (like a security 
> > > > interceptor or a transactional interceptor, for 
> example). What do 
> > > > you think? I realize this would be treading along the AOP 
> > territory;
> > > > may be this could extend
> > > > into an ultra light aspect framework too! One for all!
> > > >
> > > > -Harish
> > > >
> > > >
> > > > 
> > --------------------------------------------------------------------
> > > > -
> > > > To unsubscribe, e-mail: 
> commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > commons-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > > 
> > 
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: 
> commons-dev-help@jakarta.apache.org
> > >
> > >
> > >
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


Mime
View raw message