Greets

["n. alex rupp" <ru...@umn.edu>]

Hello, all.

I've been meaning to drop in for quite a while.  I've been following Struts for
a couple of years and using it with few complaints or questions.  Earlier this
year I hit some roadblocks in an application design, downloaded and read the
entirety of the source code and took some issues with the architecture.
However, since Struts' feature offering is top-notch and since the servlet
framework community is rife with division, I decided not to be an ass and
complain about it unless I was willing to back it up with some CODE.  Instead, I
went shopping.  I checked out webwork, read the entirety of Rickard's code, and
even forked off a small branch for my purposes, but came to similar conclusions
about the design.

But again, I didn't think it would be productive or polite to force the issue to
either of your two communities.  It's been my experience that a lot of people
will gripe and criticize other people's software--especially the most popular
and used software, but they'll never add a lick of positive, constructive
feedback in the form of living code, the ultimate contribution to our little
society.  Code speaks louder than words.

So anyway, while working on clientware for the MX4J and Geronimo projects this
autumn, I designed and wrote a servlet framework from scratch to handle my
needs.  It has an aspect-oriented workflow engine that can add crosscutting
system logic (like form processing, L10N, security, logging, etc) dynamically at
runtime (without having to mess around with the bytecode).  It can trade actions
across classloader boundaries, enabling web applications to span across multiple
.WAR files.  This allows users to drop in a new .WAR with new metadata and new
actions, which updates the application workflow at runtime across all modules in
the application namespace.  It handles workflow versioning and version rollback
(in case you make changes you come to regret).  It does instance pooling of all
components and sequences.  Every aspect of the system can be managed with JMX at
runtime.  To my knowledge, it should work with every type of Presentation
technology.  The concerns of the underlying framework are separated from those
of the feature platform.  Almost every component in the core framework and the
corresponding feature platform ultimately implement one of three interfaces:
DataSource, Workflow or Action; I didn't even try to reconcile with the MVC
antipattern because I don't think it reflects the needs of the technology.

All end-user interaction with the framework is done through a simple client
package.  The configuration file is dirt-simple and is processed into metadata
beans in the framework which are pooled and used to direct workflow.

Basically, it's just really neat and I'm having a lot of fun working on it  : )

The reason I'm telling you all this is because I designed it so you could
implement your entire feature platform (form processing & validation, i18n,
resource bundles, whatever) on top of it, without much difficulty.  Of course, I
don't *expect* you guys to do this, but it's possible and probably wouldn't be
that tough.  Same goes for WW and other frameworks.  So now (surprise) you have
even *more* options.

(I also noticed that you guys are working on a chaining implementation.  Since
my core framework performs this, I thought I should finally get in touch.)

It's licensed under the Academic Free License (the ultimate business-friendly OS
license), and I've got the beginnings of a web page up for it at
http://shocks.sf.net.  There are API docs and sample code available, although
the framework is in alpha and I'm still refactoring the core components.  (Oh
yeah--the core is pluggable, too, in case we decide to hate it later on ; )

If this interests any of you, please drop me a line.  I've got some test
applications running successfully against it, and I'll be using it to build a
management console for Geronimo.  If there is any way I can help you guys out,
please let me know.  If not, good luck and

Kind Regards,
--
N. Alex  Rupp (n_alex_rupp@users.sf.net)


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

Re: Greets

["n. alex rupp" <ru...@umn.edu>]

Yeah, I was pretty excited when I read about them earlier this month, but also
wondered "where the heck have these guys been for the last six months?!"  If I'd
known what they were up to, I'd have pitched in.  I think there are appreciable
differences that have yet to be realized between the two (I haven't read their
code at all), but definitely a lot of conceptual crossover.  I'm not worried
about it though, and don't want to create an adversarial vibe with anyone.  I'm
convinced that if anything, there's more room for collaboration these days
between the different groups, and not less.

I don't talk about IoC as a selling point, but it's in there.  On the Shocks
website, there's a commented out section in the navigation called "Marketecture"
which will include a link to a "buzzword compliance" page.  There I'll address
things like IoC, AOP, "pointcutting" and the like.  Actions (be they application
specific or systemwide) do what they do when told; the container uses metadata
to build sequences, and that metadata is very simple to alter at runtime (given
the right tools it could be made effortless).  It gives you extremely
fine-grained control over the application design, and the IoC helps promote
pluggable components.  Of course you can make your actions dependent upon
information from other actions through the different contexts (effectively
overriding the IoC), but the nature of the platform does not encourage this
behavior.

: )

--
N. Alex Rupp (n_alex_rupp@users.sf.net)




----- Original Message ----- 
From: "Martin Cooper" <ma...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Monday, November 17, 2003 2:14 PM
Subject: Re: Greets


> It sounds like you might have re-invented (aspects of) Spring:
>
> http://www.springframework.org/
>
> Perhaps without the explicit IoC part, though. ;-)
>
> --
> Martin Cooper
>
>
>
> On Mon, 17 Nov 2003, n. alex rupp wrote:
>
> > Hello, all.
> >
> > I've been meaning to drop in for quite a while.  I've been following Struts
for
> > a couple of years and using it with few complaints or questions.  Earlier
this
> > year I hit some roadblocks in an application design, downloaded and read the
> > entirety of the source code and took some issues with the architecture.
> > However, since Struts' feature offering is top-notch and since the servlet
> > framework community is rife with division, I decided not to be an ass and
> > complain about it unless I was willing to back it up with some CODE.
Instead, I
> > went shopping.  I checked out webwork, read the entirety of Rickard's code,
and
> > even forked off a small branch for my purposes, but came to similar
conclusions
> > about the design.
> >
> > But again, I didn't think it would be productive or polite to force the
issue to
> > either of your two communities.  It's been my experience that a lot of
people
> > will gripe and criticize other people's software--especially the most
popular
> > and used software, but they'll never add a lick of positive, constructive
> > feedback in the form of living code, the ultimate contribution to our little
> > society.  Code speaks louder than words.
> >
> > So anyway, while working on clientware for the MX4J and Geronimo projects
this
> > autumn, I designed and wrote a servlet framework from scratch to handle my
> > needs.  It has an aspect-oriented workflow engine that can add crosscutting
> > system logic (like form processing, L10N, security, logging, etc)
dynamically at
> > runtime (without having to mess around with the bytecode).  It can trade
actions
> > across classloader boundaries, enabling web applications to span across
multiple
> > .WAR files.  This allows users to drop in a new .WAR with new metadata and
new
> > actions, which updates the application workflow at runtime across all
modules in
> > the application namespace.  It handles workflow versioning and version
rollback
> > (in case you make changes you come to regret).  It does instance pooling of
all
> > components and sequences.  Every aspect of the system can be managed with
JMX at
> > runtime.  To my knowledge, it should work with every type of Presentation
> > technology.  The concerns of the underlying framework are separated from
those
> > of the feature platform.  Almost every component in the core framework and
the
> > corresponding feature platform ultimately implement one of three interfaces:
> > DataSource, Workflow or Action; I didn't even try to reconcile with the MVC
> > antipattern because I don't think it reflects the needs of the technology.
> >
> > All end-user interaction with the framework is done through a simple client
> > package.  The configuration file is dirt-simple and is processed into
metadata
> > beans in the framework which are pooled and used to direct workflow.
> >
> > Basically, it's just really neat and I'm having a lot of fun working on it
: )
> >
> > The reason I'm telling you all this is because I designed it so you could
> > implement your entire feature platform (form processing & validation, i18n,
> > resource bundles, whatever) on top of it, without much difficulty.  Of
course, I
> > don't *expect* you guys to do this, but it's possible and probably wouldn't
be
> > that tough.  Same goes for WW and other frameworks.  So now (surprise) you
have
> > even *more* options.
> >
> > (I also noticed that you guys are working on a chaining implementation.
Since
> > my core framework performs this, I thought I should finally get in touch.)
> >
> > It's licensed under the Academic Free License (the ultimate
business-friendly OS
> > license), and I've got the beginnings of a web page up for it at
> > http://shocks.sf.net.  There are API docs and sample code available,
although
> > the framework is in alpha and I'm still refactoring the core components.
(Oh
> > yeah--the core is pluggable, too, in case we decide to hate it later on ; )
> >
> > If this interests any of you, please drop me a line.  I've got some test
> > applications running successfully against it, and I'll be using it to build
a
> > management console for Geronimo.  If there is any way I can help you guys
out,
> > please let me know.  If not, good luck and
> >
> > Kind Regards,
> > --
> > N. Alex  Rupp (n_alex_rupp@users.sf.net)
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

Re: Greets

[Martin Cooper <ma...@apache.org>]

It sounds like you might have re-invented (aspects of) Spring:

http://www.springframework.org/

Perhaps without the explicit IoC part, though. ;-)

--
Martin Cooper



On Mon, 17 Nov 2003, n. alex rupp wrote:

> Hello, all.
>
> I've been meaning to drop in for quite a while.  I've been following Struts for
> a couple of years and using it with few complaints or questions.  Earlier this
> year I hit some roadblocks in an application design, downloaded and read the
> entirety of the source code and took some issues with the architecture.
> However, since Struts' feature offering is top-notch and since the servlet
> framework community is rife with division, I decided not to be an ass and
> complain about it unless I was willing to back it up with some CODE.  Instead, I
> went shopping.  I checked out webwork, read the entirety of Rickard's code, and
> even forked off a small branch for my purposes, but came to similar conclusions
> about the design.
>
> But again, I didn't think it would be productive or polite to force the issue to
> either of your two communities.  It's been my experience that a lot of people
> will gripe and criticize other people's software--especially the most popular
> and used software, but they'll never add a lick of positive, constructive
> feedback in the form of living code, the ultimate contribution to our little
> society.  Code speaks louder than words.
>
> So anyway, while working on clientware for the MX4J and Geronimo projects this
> autumn, I designed and wrote a servlet framework from scratch to handle my
> needs.  It has an aspect-oriented workflow engine that can add crosscutting
> system logic (like form processing, L10N, security, logging, etc) dynamically at
> runtime (without having to mess around with the bytecode).  It can trade actions
> across classloader boundaries, enabling web applications to span across multiple
> .WAR files.  This allows users to drop in a new .WAR with new metadata and new
> actions, which updates the application workflow at runtime across all modules in
> the application namespace.  It handles workflow versioning and version rollback
> (in case you make changes you come to regret).  It does instance pooling of all
> components and sequences.  Every aspect of the system can be managed with JMX at
> runtime.  To my knowledge, it should work with every type of Presentation
> technology.  The concerns of the underlying framework are separated from those
> of the feature platform.  Almost every component in the core framework and the
> corresponding feature platform ultimately implement one of three interfaces:
> DataSource, Workflow or Action; I didn't even try to reconcile with the MVC
> antipattern because I don't think it reflects the needs of the technology.
>
> All end-user interaction with the framework is done through a simple client
> package.  The configuration file is dirt-simple and is processed into metadata
> beans in the framework which are pooled and used to direct workflow.
>
> Basically, it's just really neat and I'm having a lot of fun working on it  : )
>
> The reason I'm telling you all this is because I designed it so you could
> implement your entire feature platform (form processing & validation, i18n,
> resource bundles, whatever) on top of it, without much difficulty.  Of course, I
> don't *expect* you guys to do this, but it's possible and probably wouldn't be
> that tough.  Same goes for WW and other frameworks.  So now (surprise) you have
> even *more* options.
>
> (I also noticed that you guys are working on a chaining implementation.  Since
> my core framework performs this, I thought I should finally get in touch.)
>
> It's licensed under the Academic Free License (the ultimate business-friendly OS
> license), and I've got the beginnings of a web page up for it at
> http://shocks.sf.net.  There are API docs and sample code available, although
> the framework is in alpha and I'm still refactoring the core components.  (Oh
> yeah--the core is pluggable, too, in case we decide to hate it later on ; )
>
> If this interests any of you, please drop me a line.  I've got some test
> applications running successfully against it, and I'll be using it to build a
> management console for Geronimo.  If there is any way I can help you guys out,
> please let me know.  If not, good luck and
>
> Kind Regards,
> --
> N. Alex  Rupp (n_alex_rupp@users.sf.net)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org