You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2003/06/23 01:25:31 UTC
[RT] The Next Big Component Architecture
Hi gang,
some ramblings of a madman before I head off to bed.
cheers,
- LSD
Looking back a little
---------------------
A few years ago [0], the web application world was a mess. We had
servlets [1], which involved embedding html inside java code, and we had
jsps, which involved custom markup that was just as ugly. The business
component world was just as messy, with EJB 1.0 out [2] but very little
actual support and buggy, pricy servers. We also had applets which
allowed us to circumvent all that ugly stuff by circumventing the entire
http/html layer and writing ugly binary socket-based protocols. The
latter got unpractical as netscape lost the browser war and Swing
arrived on the scene too late.
Still, there was a good JDK [3], including one for linux, and the JFC
were shaping up pretty nicely. We jumped to java en masse. Booming business.
"This is a mess. Lets fix it."
------------------------------
So we had JServ 1.0, JBoss 1.0, something called "tomcat" no-one
actually used, lots of crappy code, and not much potential for reuse.
Several lessons were learned in developing all of that stuff, and
several projects formed all around the open source world that fixed
various pieces of the puzzles and scratched various itches.
Lessons learned
---------------
Let's look at some of the things we've figured out along the way....
Java works: Well duh! It was clear to many that there was a good base
platform here that got most details reasonably right (even if
Stack inherited cruft from Vector).
XML works, too: A, the beauty of a simple markup language both
machine-readable and human-readable!
language mixing sucks: embedding markup language or scripting language
inside inside programming language quickly becomes unreadable.
Parsers or templating technologies make life easier.
decouple: I won't seriously consider programming big applications in a
language that doesn't have the keyword 'interface' these days
big design is bad: one acronym - EJB. Ugh.
open source wins: in 2003, almost every important component for building
server side software is open source. Except for a JDK, for some
reason.
unit tests: More Important Than Interfaces. The various parts of XP
methodology are slowly saturating the java world.
...and one could go on and on. The landscape is still improving.
Sharing Is Hard
---------------
look at the number of "web application frameworks" out there. Dozens of
them. Look at the lack of common ground they have. Missed potential. It
takes an extreme amount of energy to figure out a way to encapsulate
some basic functionality so that it can successfully be shared even
across a limited problem domain.
One of the things avalon is supposed to enable is reuse within a problem
domain, or even across problem domains. However, we have not succeeded
in making this so easy and obvious that the average java bloke can
figure out in an afternoon how to do it. Sharing remains hard.
In practice, the only clean form of sharing occurs on a large scale is
when someone succeeds in totally isolating a cross-cutting concern into
an appropriately partitioned vessel. Like log4j.jar or JAXP, or GUI
javabeans. These are the exception rather than the rule, especially as
partitioning grows.
There are exceptions, where inferior or all-encompassing tech still
manages to become a standard, usually grown out of a standards body
(DOM) or corporate backing (EJB), but those usually get competition from
people who've scratched their itch and improved on the concept (JDOM, EOB).
So, some statements summed up
-----------------------------
The java platform works, but frameworks like avalon remain complex, too
complex for the average joe user (or the average professional with only
a day or two to spend [5]) to actually gain critical mass without
corporate backing. Therefore, basic software architecture is still being
re-invented on a daily basis and sharing remains very hard.
The winning concepts
--------------------
* IoC
* COP
* Api/Impl seperation
* KISS
* XP, test first
* asynced events, pipelining
* aspects
* attributes
* scriptability
* pluggability
* strong typing
Avalon has IoC, COP, Api/Impl seperation. Attributes are coming. Various
stuff is easily added. The main thing it misses is KISS. The other main
thing is pluggability. Avalon is _not_ pluggable. Components written
using avalon are pluggable inside other components written using avalon.
Applying avalon to an existing system often requires a big overhaul and
lots of refactoring. Applying avalon to an existing programmer takes a
week at least.
Avalon4 Just Doesn't Cut It
---------------------------
I've been slowly forming this opinion over several months of looking at
many many avalon-related technologies. Take a look at phoenix, ecm,
fortress, microcontainer, tweety, merlin, plexus, eob, guiapp, cocoon.
Each and every one of these requires too much work for every component
you write because there are *so many strict contracts*. Contracts are
good, but they need to be intuitive, too.
The challenge
-------------
Lose the baggage. Make it simpler. Make it smaller. Encapsulate the
dynamism in a single place. KISS. Yes, Paul & friends figured it out
already [6].
The Next Big Component Architecture will be about Small Architecture.
What it might look like
-----------------------
Here's a not-attribute-aware, jython-scripted, api/impl seperated,
IoC/COP, aspect-oriented, strongly typed bean. It is also a regular
javabean that can run in any simple java2 environment.
--- Parser.java ---
/** a basic work interface */
public interface Parser
{
Node parse( Source source );
}
--- SomeParser.java ---
/**
* a basic bean with some system-level needs (logging), some
* configuration requirements and a dependency on another
* component.
*/
public class SomeParser implements Parser
{
private Log m_log = null;
private boolean m_validate = false;
private XmlReader m_XmlReader = null;
//////////////////////////////
/// work interface: Parser ///
//////////////////////////////
public void parse( Source source )
{
m_log.debug( "source url: " + source.getURL() );
/* ... */
if( m_validate )
validate( source );
/* ... */
}
//////////////////////
/// required stuff ///
//////////////////////
public void setLog( Log log )
{
m_log = log;
}
public void setValidate( boolean validate )
{
m_validate = validate;
}
public void setXmlReader( XmlReader reader )
{
m_XmlReader = reader;
}
///////////////////////
/// utility methods ///
///////////////////////
protected validate( Source source ) { /* ... */ }
}
--- MyAppDefaultInit.py ---
# a common jython script that adds basic custom configuration
# support, AOP interceptors and an event interceptor
instance.log = container.getLog( config.attrs.name )
instance.log.logLevel = config.elems.log-level
# time method calls
if( config.elems.instrument )
interceptors.add( method="*", on="preCall",
action="context.parse.startTime=System.currentTimeMillis()" )
interceptors.add( method="*", on="postCall",
action={
context.parse.endTime=System.currentTimeMillis()
timeTaken = context.parse.startTime - context.parse.endTime
properties.log.debug( "time taken for " \
+ currentMethod + "call: " timeTaken )
} )
# enable hot reconfiguration
interceptors.add( event="reconfigure"
action={
instance.log = container.getLog( event.config.attrs.name )
instance.log.logLevel = event.config.elems.log-level
} )
--- SomeParserInit.py ---
# a class-specific jython script that extends the behaviour from
# the above script
container.call( "MyAppDefaultInit.py" )
instance.xmlReader = container.getComponent( "xml-reader" )
# update validate property before parsing to allow for
# runtime reconfiguration
interceptors.add( method="parse", on="preCall",
"instance.validate=config.elems.validate" )
# enable hot reconfiguration
interceptors.add( event="reconfigure"
action={
instance.validate = event.config.elems.validate
} )
--- WEB-INF/components.config.xml ---
# a sample xml configuration file, might be passed in using
# configure( Configuration conf ) or configure( Node node )
# or by using a jython script
<components>
<defaults>
<config>
<instrument>false</instrument>
<log-level>DEBUG</log-level>
</config>
</defaults>
<component name="xml-reader"
class="org.sf.xml-utils.XmlReader"
lifestyle="threadsafe"/>
<component name="parser"
class="SomeParser"
lifestyle="pooled">
<config>
<validate>true</validate>
<instrument>true</instrument>
</config>
</component>
</components>
--- MyBean.java ---
/**
* doesn't care about configurations, scripts, or whatever,
* but understands what setXXX() implies.
*/
public class MyBean
{
private Parser m_parser;
public MyBean()
{
m_parser = new SomeParser();
m_parser.setLog( new SimpleLog( "parser" ) );
m_parser.setValidate( true );
m_parser.setXmlReader( new XmlReader() );
}
public void doStuff()
{
m_parser.parse( /* ... */ );
}
}
--- MyComponent.java ---
/**
* client component; similarly might have an init
* script and/or configuration
*/
public class MyComponent implements Something
{
private Parser m_parser;
public void setParser( Parser parser )
{
m_parser = parser;
}
}
--- WEB-INF/plugins.conf.xml ---
<plugins>
<plugin id="improved-pool" version="1.1-dev">
<config>
<initialSize>5</initialSize>
</config>
</plugin>
<plugin id="jelly-scripting-support" version="1.0"/>
</plugin>
</plugins>
--- $PLUGINS/improved-pool-1.1-dev.jar/plugin.py ---
instance = new ImprovedPoolManager()
instance.initialSize = config.elems.initialSize
container.pool = instance
--- $PLUGINS/jelly-scripting-support/plugin.py ---
instance = new JellyScriptManager()
container.addScriptingSupport( instance, "*.jelly" )
Just Do It already!
-------------------
I've been playing with some of this stuff. I'm wondering whether I
should bring it over here or make it public elsewhere, or not at all.
Comments?
References
----------
[0] - http://web.archive.org/web/19980110194101/http://java.apache.org/
[1] -
http://web.archive.org/web/20000303060921/java.sun.com/products/servlet/index.html
[2] -
http://web.archive.org/web/19980215013218/java.sun.com/pr/1997/dec/pr971210-01.html
[3] -
http://web.archive.org/web/19980214234112/java.sun.com/products/jdk/1.1/index.html
[4] - http://web.archive.org/web/19980110194101/http://java.apache.org/
[5] - http://jeremy.zawodny.com/blog/archives/cat_java.html
[6] - http://www.picocontainer.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Next Big Component Architecture
Posted by Leo Simons <le...@apache.org>.
Leo Simons wrote:
> I've been playing with some of this stuff. I'm wondering whether I
> should bring it over here or make it public elsewhere, or not at all.
> Comments?
After thinking about all this a lot more, I believe that it is not a
good idea to invest a lot of energy right now here @ avalon into the
"next big component architecture". We already have a solid base that
works for many, many, many usecases, and we're identifying many areas
where that base can be improved in an evolutionary manner.
We don't need a revolution.
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Next Big Component Architecture
Posted by Ulrich Mayring <ul...@denic.de>.
Leo Simons wrote:
>
> Do you think avalon should provide declarative-style stuff? Why? How?
I think yes. The "why-question" is easily answered: because it's easier
to use and maintain. There is a reason that XSLT has become a success.
The "how-question" is not so easily answered.
I think the first step is to ask what in Avalon do we want to specify in
a declarative way? In my eyes the assembly process, where different
components are taken and assembled to a larger application, is a candidate.
The next thing is that there should be some kind of generic and implicit
mapping from Avalon components to an XML representation. The XML then
should be used as a replacement for scripting and it should be processed
in a declarative way so that the Java component is called and does the work.
I know this is pretty vague at this point :)
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Next Big Component Architecture
Posted by Leo Simons <le...@apache.org>.
Ulrich Mayring wrote:
> Leo Simons wrote:
>> language mixing sucks: embedding markup language or scripting language
>> inside inside programming language quickly becomes unreadable.
>> Parsers or templating technologies make life easier.
>
> I agree emphatically with this statement and want to remark that Avalon
> provides zero support for templating (an alternative term would be
> declarative notions). Not even cutting-edge technologies like Cocoon
> have a clean and simple solution.
Taking that a little further, the java world as a whole has bad support
for templating. It's a difficult thing to get right, apparently.
Do you think avalon should provide declarative-style stuff? Why? How?
often at least one solution becomes obvious immediately after finding
the problem, but not here :D
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Next Big Component Architecture
Posted by Ulrich Mayring <ul...@denic.de>.
Leo Simons wrote:
> Hi gang,
>
> language mixing sucks: embedding markup language or scripting language
> inside inside programming language quickly becomes unreadable.
> Parsers or templating technologies make life easier.
I agree emphatically with this statement and want to remark that Avalon
provides zero support for templating (an alternative term would be
declarative notions). Not even cutting-edge technologies like Cocoon
have a clean and simple solution.
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Next Big Component Architecture
Posted by Leo Simons <le...@apache.org>.
I wrote:
<snip/>
> Just Do It already!
Putting my money where my mouth is....
....some more docs now up at
http://lsd.student.utwente.nl/jicarilla/
and some code up at sourceforge. I think code is now of a level that
allows me to say "we can make it work if we want it to work". Among the
features is (provided things actually work as I couldn't be bothered to
write tests for what is basically mock code) full support for
Pico-style, XWork-style, and Avalon-style components, as well as a
mixture of those and some extra options as well.
Also implemented are the ComponentFactory idea (as per pico and Berin's
latest RTs) though I just called 'em Factory, AOP-style interceptors
(very basic; a realistic implementation might be nanning-based) using
jdk proxying, and I put in the start of jython-based scriptable components.
There's a nice mix of simplicity and possibility imho though the default
dependency management stuff might need to be beefed up,
ComponentDescriptions expanded and everything rewritten from scratch
just for the fun of it.
---
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/jicarilla login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/jicarilla co
jicarilla-sandbox
cd jicarilla-sandbox/platform
cd components/collections
maven
cd ../../framework
maven
cd ../container
maven
---
Don't bother looking at the "collections" or "framework" stuff, that's
not actually used (you just needed the CascadingExceptions 'n stuff from
framework, and framework depends on collections).
Fire up the class DemoMain in your debugger to get to grips with the
package. Important difference between this package and our existing
containers is that the assumption is not that the container will ever
read any config files, rather there will be a layer around the container
(call it kernel if you want) that does that. See the JicarillaWiki for
some sketches.
Do you guys consider it worthwile to start working on a setup like this
over here @ avalon?
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Next Big Component Architecture
Posted by Robert McIntosh <ro...@bull-enterprises.com>.
Speaking as a user of avalon/fortress, I agree completely on the
usability and complexity aspects of your statements. I still have a hard
time getting across to coworkers just exactly avalon is. For the longest
time my boss thought it was an xml config tool. After about the 8th time
of saying "the config is just one small portion of it", he finally got
it. It seems to me at this point in Avalon's life that it can be used by
really smart people, or those who want to invest a lot of time in
learning how to use it, to help out other people. In other words, guru 1
can setup phoenix/merlin/whatever with some services and allow non-guru
2-10 to use them easily. Make sense?
The hardest thing as a user to get or understand is the roles config.
Last time I looked (a few months or so), there was almost no docs on how
to set this stuff up. I first went by examples, but they were outdated
and nothing worked. I eventually got it, but it wasn't trivial. Your
mention of the declarative side of things is really interesting to me,
cause that is what our product is geared towards. We use avalon/fortress
to help facilitate the services side of things, but what we do is allow
the developer the option of decalaring, through the config of our
components, most if not all aspects of an applications domain model and
processes.
Robert
Leo Simons wrote:
> Hi gang,
>
> some ramblings of a madman before I head off to bed.
>
> cheers,
>
> - LSD
>
> Looking back a little
> ---------------------
> A few years ago [0], the web application world was a mess. We had
> servlets [1], which involved embedding html inside java code, and we
> had jsps, which involved custom markup that was just as ugly. The
> business component world was just as messy, with EJB 1.0 out [2] but
> very little actual support and buggy, pricy servers. We also had
> applets which allowed us to circumvent all that ugly stuff by
> circumventing the entire http/html layer and writing ugly binary
> socket-based protocols. The latter got unpractical as netscape lost
> the browser war and Swing arrived on the scene too late.
>
> Still, there was a good JDK [3], including one for linux, and the JFC
> were shaping up pretty nicely. We jumped to java en masse. Booming
> business.
>
> "This is a mess. Lets fix it."
> ------------------------------
> So we had JServ 1.0, JBoss 1.0, something called "tomcat" no-one
> actually used, lots of crappy code, and not much potential for reuse.
> Several lessons were learned in developing all of that stuff, and
> several projects formed all around the open source world that fixed
> various pieces of the puzzles and scratched various itches.
>
> Lessons learned
> ---------------
> Let's look at some of the things we've figured out along the way....
>
> Java works: Well duh! It was clear to many that there was a good base
> platform here that got most details reasonably right (even if
> Stack inherited cruft from Vector).
>
> XML works, too: A, the beauty of a simple markup language both
> machine-readable and human-readable!
>
> language mixing sucks: embedding markup language or scripting language
> inside inside programming language quickly becomes unreadable.
> Parsers or templating technologies make life easier.
>
> decouple: I won't seriously consider programming big applications in a
> language that doesn't have the keyword 'interface' these days
>
> big design is bad: one acronym - EJB. Ugh.
>
> open source wins: in 2003, almost every important component for building
> server side software is open source. Except for a JDK, for some
> reason.
>
> unit tests: More Important Than Interfaces. The various parts of XP
> methodology are slowly saturating the java world.
>
> ...and one could go on and on. The landscape is still improving.
>
> Sharing Is Hard
> ---------------
> look at the number of "web application frameworks" out there. Dozens
> of them. Look at the lack of common ground they have. Missed
> potential. It takes an extreme amount of energy to figure out a way to
> encapsulate some basic functionality so that it can successfully be
> shared even across a limited problem domain.
>
> One of the things avalon is supposed to enable is reuse within a
> problem domain, or even across problem domains. However, we have not
> succeeded in making this so easy and obvious that the average java
> bloke can figure out in an afternoon how to do it. Sharing remains hard.
>
> In practice, the only clean form of sharing occurs on a large scale is
> when someone succeeds in totally isolating a cross-cutting concern
> into an appropriately partitioned vessel. Like log4j.jar or JAXP, or
> GUI javabeans. These are the exception rather than the rule,
> especially as partitioning grows.
>
> There are exceptions, where inferior or all-encompassing tech still
> manages to become a standard, usually grown out of a standards body
> (DOM) or corporate backing (EJB), but those usually get competition
> from people who've scratched their itch and improved on the concept
> (JDOM, EOB).
>
> So, some statements summed up
> -----------------------------
> The java platform works, but frameworks like avalon remain complex,
> too complex for the average joe user (or the average professional with
> only a day or two to spend [5]) to actually gain critical mass without
> corporate backing. Therefore, basic software architecture is still
> being re-invented on a daily basis and sharing remains very hard.
>
> The winning concepts
> --------------------
> * IoC
> * COP
> * Api/Impl seperation
> * KISS
> * XP, test first
> * asynced events, pipelining
> * aspects
> * attributes
> * scriptability
> * pluggability
> * strong typing
>
> Avalon has IoC, COP, Api/Impl seperation. Attributes are coming.
> Various stuff is easily added. The main thing it misses is KISS. The
> other main thing is pluggability. Avalon is _not_ pluggable.
> Components written using avalon are pluggable inside other components
> written using avalon. Applying avalon to an existing system often
> requires a big overhaul and lots of refactoring. Applying avalon to an
> existing programmer takes a week at least.
>
> Avalon4 Just Doesn't Cut It
> ---------------------------
> I've been slowly forming this opinion over several months of looking
> at many many avalon-related technologies. Take a look at phoenix, ecm,
> fortress, microcontainer, tweety, merlin, plexus, eob, guiapp, cocoon.
> Each and every one of these requires too much work for every component
> you write because there are *so many strict contracts*. Contracts are
> good, but they need to be intuitive, too.
>
> The challenge
> -------------
> Lose the baggage. Make it simpler. Make it smaller. Encapsulate the
> dynamism in a single place. KISS. Yes, Paul & friends figured it out
> already [6].
>
> The Next Big Component Architecture will be about Small Architecture.
>
> What it might look like
> -----------------------
> Here's a not-attribute-aware, jython-scripted, api/impl seperated,
> IoC/COP, aspect-oriented, strongly typed bean. It is also a regular
> javabean that can run in any simple java2 environment.
>
> --- Parser.java ---
>
> /** a basic work interface */
> public interface Parser
> {
> Node parse( Source source );
> }
>
> --- SomeParser.java ---
>
> /**
> * a basic bean with some system-level needs (logging), some
> * configuration requirements and a dependency on another
> * component.
> */
> public class SomeParser implements Parser
> {
> private Log m_log = null;
> private boolean m_validate = false;
> private XmlReader m_XmlReader = null;
>
> //////////////////////////////
> /// work interface: Parser ///
> //////////////////////////////
>
> public void parse( Source source )
> {
> m_log.debug( "source url: " + source.getURL() );
>
> /* ... */
>
> if( m_validate )
> validate( source );
> /* ... */
> }
>
> //////////////////////
> /// required stuff ///
> //////////////////////
>
> public void setLog( Log log )
> {
> m_log = log;
> }
> public void setValidate( boolean validate )
> {
> m_validate = validate;
> }
> public void setXmlReader( XmlReader reader )
> {
> m_XmlReader = reader;
> }
>
> ///////////////////////
> /// utility methods ///
> ///////////////////////
>
> protected validate( Source source ) { /* ... */ }
> }
>
> --- MyAppDefaultInit.py ---
>
> # a common jython script that adds basic custom configuration
> # support, AOP interceptors and an event interceptor
>
> instance.log = container.getLog( config.attrs.name )
> instance.log.logLevel = config.elems.log-level
>
> # time method calls
> if( config.elems.instrument )
> interceptors.add( method="*", on="preCall",
> action="context.parse.startTime=System.currentTimeMillis()" )
> interceptors.add( method="*", on="postCall",
> action={
> context.parse.endTime=System.currentTimeMillis()
> timeTaken = context.parse.startTime - context.parse.endTime
> properties.log.debug( "time taken for " \
> + currentMethod + "call: " timeTaken )
> } )
>
> # enable hot reconfiguration
> interceptors.add( event="reconfigure"
> action={
> instance.log = container.getLog( event.config.attrs.name )
> instance.log.logLevel = event.config.elems.log-level
> } )
>
> --- SomeParserInit.py ---
>
> # a class-specific jython script that extends the behaviour from
> # the above script
>
> container.call( "MyAppDefaultInit.py" )
>
> instance.xmlReader = container.getComponent( "xml-reader" )
>
> # update validate property before parsing to allow for
> # runtime reconfiguration
> interceptors.add( method="parse", on="preCall",
> "instance.validate=config.elems.validate" )
>
> # enable hot reconfiguration
> interceptors.add( event="reconfigure"
> action={
> instance.validate = event.config.elems.validate
> } )
>
> --- WEB-INF/components.config.xml ---
>
> # a sample xml configuration file, might be passed in using
> # configure( Configuration conf ) or configure( Node node )
> # or by using a jython script
> <components>
> <defaults>
> <config>
> <instrument>false</instrument>
> <log-level>DEBUG</log-level>
> </config>
> </defaults>
> <component name="xml-reader"
> class="org.sf.xml-utils.XmlReader"
> lifestyle="threadsafe"/>
>
> <component name="parser"
> class="SomeParser"
> lifestyle="pooled">
>
> <config>
> <validate>true</validate>
> <instrument>true</instrument>
> </config>
> </component>
> </components>
>
> --- MyBean.java ---
>
> /**
> * doesn't care about configurations, scripts, or whatever,
> * but understands what setXXX() implies.
> */
> public class MyBean
> {
> private Parser m_parser;
>
> public MyBean()
> {
> m_parser = new SomeParser();
> m_parser.setLog( new SimpleLog( "parser" ) );
> m_parser.setValidate( true );
> m_parser.setXmlReader( new XmlReader() );
> }
> public void doStuff()
> {
> m_parser.parse( /* ... */ );
> }
> }
>
> --- MyComponent.java ---
>
> /**
> * client component; similarly might have an init
> * script and/or configuration
> */
> public class MyComponent implements Something
> {
> private Parser m_parser;
>
> public void setParser( Parser parser )
> {
> m_parser = parser;
> }
> }
>
> --- WEB-INF/plugins.conf.xml ---
>
> <plugins>
> <plugin id="improved-pool" version="1.1-dev">
> <config>
> <initialSize>5</initialSize>
> </config>
> </plugin>
> <plugin id="jelly-scripting-support" version="1.0"/>
> </plugin>
> </plugins>
>
> --- $PLUGINS/improved-pool-1.1-dev.jar/plugin.py ---
>
> instance = new ImprovedPoolManager()
> instance.initialSize = config.elems.initialSize
> container.pool = instance
>
> --- $PLUGINS/jelly-scripting-support/plugin.py ---
>
> instance = new JellyScriptManager()
> container.addScriptingSupport( instance, "*.jelly" )
>
> Just Do It already!
> -------------------
> I've been playing with some of this stuff. I'm wondering whether I
> should bring it over here or make it public elsewhere, or not at all.
> Comments?
>
> References
> ----------
> [0] - http://web.archive.org/web/19980110194101/http://java.apache.org/
> [1] -
> http://web.archive.org/web/20000303060921/java.sun.com/products/servlet/index.html
>
> [2] -
> http://web.archive.org/web/19980215013218/java.sun.com/pr/1997/dec/pr971210-01.html
>
> [3] -
> http://web.archive.org/web/19980214234112/java.sun.com/products/jdk/1.1/index.html
>
> [4] - http://web.archive.org/web/19980110194101/http://java.apache.org/
> [5] - http://jeremy.zawodny.com/blog/archives/cat_java.html
> [6] - http://www.picocontainer.org/
>
>
>
> ---------------------------------------------------------------------
> 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] The Next Big Component Architecture
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Just Do It already!
> -------------------
> I've been playing with some of this stuff. I'm wondering whether I
> should bring it over here or make it public elsewhere, or not at all.
> Comments?
I'll give you 8 out of 10 for spin.
Stick in in sandbox and lets working through those itty-bitty details
from there!
:-)
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org