Spring and Roller

[Anil Gangolli <an...@busybuddha.org>]

I've been using basic Spring dependency injection and initialization 
(BeanFactory/ApplicationContext) functionality  in some projects at work 
and have really been happy with how it encourages clean modularization 
and helps me to get more pluggable reusable components while keeping 
almost all of the code completely unaware of Spring itself.

I think using the dependency injection pattern would really help us 
clean up interdependencies and make Roller more pluggable and 
modifiable.  Before spending time on a real proposal, I wanted to gauge 
interest in this.  Note that this is separable from any inclination to 
use Spring MVC (as Sean G is trying) or other Spring features (like the 
declarative transaction management that Matt R suggested).

Taking this path would suggest that we use Spring's xml-based 
configuration mechanisms instead of roller.properties.  It's possible 
(as Matt has done for some of the Acegi-related properties) to support 
configuration via roller.properties rather than requiring users to edit 
the xml, but I think that the approach taken by Matt for the security 
props (having code in RollerContext initialization read the roller props 
and call appropriate bean setters)  would be onerous to extend to a 
large number of properties.  What would probably work nicely (and be 
easy) is to have most of the Spring configuration refer where necessary 
(by property paths) to one bean representing the equivalent of 
roller.properties and configured in one xml file (or even a properties 
file if we initialize that one bean specially).

I think it could be entered gradually, but eventually would mean a lot 
of minor-to-moderate restructuring to really utilize the pattern, 
feeling kind-of Roller 3.0-ish.

Would there be sufficient support for seeing a proposal along these 
lines?  I probably won't embark on such a proposal unless there's some 
predisposition to move in this direction.

--a.

Re: Spring and Roller

[Sean Gilligan <se...@msgilligan.com>]

David M Johnson wrote:
> Comments below...
> 
> On Mar 5, 2006, at 12:09 PM, Anil Gangolli wrote:

>> Taking this path would suggest that we use Spring's xml-based 
>> configuration mechanisms instead of roller.properties.  It's possible 
>> (as Matt has done for some of the Acegi-related properties) to support 
>> configuration via roller.properties rather than requiring users to 
>> edit the xml, but I think that the approach taken by Matt for the 
>> security props (having code in RollerContext initialization read the 
>> roller props and call appropriate bean setters)  would be onerous to 
>> extend to a large number of properties.  What would probably work 
>> nicely (and be easy) is to have most of the Spring configuration refer 
>> where necessary (by property paths) to one bean representing the 
>> equivalent of roller.properties and configured in one xml file (or 
>> even a properties file if we initialize that one bean specially).

I had to review my Spring book a little to understand what Anil is 
talking about here.  (There is a PropertyPathFactoryBean that can peel 
off a single property from a Properties, Map, etc. for injection into 
another bean -- this allows objects configured through D.I. in the 
XML-based container to use individual properties defined in a 
.properties file without injecting the whole Properties object.)

I'm guessing the consensus will be to leave roller.properties as a 
.properties file for the foreseeable future.

> 
> I think there are three types of configuration properties in 
> roller.properties:
> 1 - implementation class names, e.g. which persistence implementation to 
> use
> 2 - configuration properties that rarely change or cannot be changed at 
> runtime
> 3 - obscure configuration properties that don't warrant a place in the UI
> 
> For  #1 type properties, I wouldn't mind asking users to edit 
> Springhetti-style XML. Folks who want to substitute their own 
> implementations clearly know what they are doing and can handle the XML. 
> Maybe we can make Roller easier to customize and perhaps all major 
> Roller sites need extensive customization. But for type #2 and #3, is it 
> really better to have folks editing XML instead of a drop-dead simple 
> properties file?

For #2 and #3 you could leave some or all of these properties in one or 
more .properties files.  Spring doesn't force you to use XML for simple 
property definitions.  You can use Anil's recommended technique above or 
several others to achive this.

-- Sean

Re: Spring and Roller

[David M Johnson <Da...@Sun.COM>]

Comments below...

On Mar 5, 2006, at 12:09 PM, Anil Gangolli wrote:
> I've been using basic Spring dependency injection and  
> initialization (BeanFactory/ApplicationContext) functionality  in  
> some projects at work and have really been happy with how it  
> encourages clean modularization and helps me to get more pluggable  
> reusable components while keeping almost all of the code completely  
> unaware of Spring itself.
>
> I think using the dependency injection pattern would really help us  
> clean up interdependencies and make Roller more pluggable and  
> modifiable.  Before spending time on a real proposal, I wanted to  
> gauge interest in this.  Note that this is separable from any  
> inclination to use Spring MVC (as Sean G is trying) or other Spring  
> features (like the declarative transaction management that Matt R  
> suggested).
>
> Taking this path would suggest that we use Spring's xml-based  
> configuration mechanisms instead of roller.properties.  It's  
> possible (as Matt has done for some of the Acegi-related  
> properties) to support configuration via roller.properties rather  
> than requiring users to edit the xml, but I think that the approach  
> taken by Matt for the security props (having code in RollerContext  
> initialization read the roller props and call appropriate bean  
> setters)  would be onerous to extend to a large number of  
> properties.  What would probably work nicely (and be easy) is to  
> have most of the Spring configuration refer where necessary (by  
> property paths) to one bean representing the equivalent of  
> roller.properties and configured in one xml file (or even a  
> properties file if we initialize that one bean specially).

I think there are three types of configuration properties in  
roller.properties:
1 - implementation class names, e.g. which persistence implementation  
to use
2 - configuration properties that rarely change or cannot be changed  
at runtime
3 - obscure configuration properties that don't warrant a place in  
the UI

For  #1 type properties, I wouldn't mind asking users to edit  
Springhetti-style XML. Folks who want to substitute their own  
implementations clearly know what they are doing and can handle the  
XML. Maybe we can make Roller easier to customize and perhaps all  
major Roller sites need extensive customization. But for type #2 and  
#3, is it really better to have folks editing XML instead of a drop- 
dead simple properties file?

But then again, maybe there are only these two type of properties:

1 - class names and configurations of said classes (perfect for  
Spring XML config)
2 - configuration properties exposed through the UI, some of which  
require restart (perfect for our XML driven runtime config system)


> I think it could be entered gradually, but eventually would mean a  
> lot of minor-to-moderate restructuring to really utilize the  
> pattern, feeling kind-of Roller 3.0-ish.
>
> Would there be sufficient support for seeing a proposal along these  
> lines?  I probably won't embark on such a proposal unless there's  
> some predisposition to move in this direction.

I'm definitely interested in seeing a proposal.

- Dave

Re: Spring and Roller

[Sean Gilligan <se...@msgilligan.com>]

Anil Gangolli wrote:
> I think using the dependency injection pattern would really help us 
> clean up interdependencies and make Roller more pluggable and 
> modifiable.

Right.  The dependency injection pattern can be used to make Roller 
pluggable and modifiable without adding a (direct) dependency on any 
framework.  If Spring were used for wiring up the objects, that would be 
a dependency on Spring for initialization/configuration, but each 
object/facade/subsystem would be free of dependencies on Spring and 
could be reusable (and testable) without dependencies on Spring or the 
rest of Roller.

>  Before spending time on a real proposal, I wanted to gauge 
> interest in this.

I'm interested,  but I see your proposal as multiple proposals (or at 
least involving multiple decisions): 1) Adopting IOS/Dependency 
Injection as a default/preferred architectural strategy, and 2-n) 
Whether/how to apply IOC/DI to solve one or more specific problems.

Given the (perceived) reluctance on the part of David and Allen to adopt 
new frameworks/dependencies, it may be best to focus  on some specific 
problems or enhancements that IOC/Spring can help with.  Although, one 
could also argue that by adopting a preference for IOC may make the 
individual decisions easier and result in greater consistency in the 
project.


> Note that this is separable from any inclination to 
> use Spring MVC (as Sean G is trying)
Agreed.  Even the Spring developers view Spring MVC as a very separable 
from using Spring in other parts of the project.  In the case of the 
Roller blog/feed presentation layer, Spring MVC brings value in view 
independence and in URL handling, and I aim to present this convincingly 
(as I find time) but they are clearly separate decisions.  More later...

  or other Spring features (like the
> declarative transaction management that Matt R suggested).

If Spring were a "one trick pony", this would probably be the trick. 
Pluggable O/R mapping is also part of the recipe.  It seems to me that 
this is an area where IOC/Spring could be helpful to Roller, especially 
given Allen's proposal to do some refactoring in this area.  This could 
also be a good test case for IOC/Spring in general.  If Allen is open to 
considering declarative transaction management with Spring, and your 
game, this would be a great way to start using IOC/Spring in the project.

> 
> Taking this path would suggest that we use Spring's xml-based 
> configuration mechanisms instead of roller.properties.

There are multiple strategies for migration/conversion, I would think. 
One idea I've toyed around with (and used in a much simpler webapp) is 
using Spring Beans to wrap configuration properties in such a way that 
they could be loaded from either JNDI or from a properties file.  This 
allows for creation of  an "immutable WAR file" that doesn't require any 
    local configuration info.  It worked well for a relatively simple 
webapp that was deployed on Tomcat (so we'd just put the config 
information for each target server in a Tomcat context.xml file.)  I 
haven't tried this with more complicated apps or with Web Containers or 
J2EE servers other than Tomcat, but this could help make Roller easier 
to deploy and manage in multi-server environments.

> 
> Would there be sufficient support for seeing a proposal along these 
> lines?  I probably won't embark on such a proposal unless there's some 
> predisposition to move in this direction.

I'm willing to help on this as much as I can, but I'm hoping to be 
focused on implementing the separate, but related, Spring MVC proposal.

Regards,

Sean

Re: Spring and Roller

[Allen Gilliland <Al...@Sun.COM>]

On Mon, 2006-03-06 at 07:11, Anil Gangolli wrote:
> Allen Gilliland wrote:
> 
> > I believe the relevant example is a case where someone looks up a bean
> > > directly rather than working through an interface or other class.  In
> > > our current implementation we expect that everyone uses
> > > Roller.getXXXManager() to get access to a manager class by working
> > > through an interface.  Using Spring someone could bypass using the
> > > Roller interface by simply calling ctx.getBean("userManager").
> > >
> > > Again, I'm not sure if this is really a problem, but it seems reasonably
> > > important to me.
> Normally, following the dependency injection pattern, a bean would have 
> a private field with the interface type (e.g. UserManager) and a setter 
> setUserManager(UserManager userManager) that would get called at 
> initialization by the BeanFactory.  Properly written, the bean never 
> knows the implementation type.  It also doesn't know how to find an 
> instance.  It just has it set by some outside entity, which is generally 
> the BeanFactory but could be something else that instantiates and 
> configures it.
> 
> Any use of  ctx.getBean("userManager") is a deviation from the 
> dependency injection pattern back to the "service locator" pattern. It 
> breaks the pattern in two ways.  It uses an explicit service lookup and 
> it makes the bean context-aware. Hence it would always be a bit suspect 
> and one should have to justify any such pattern deviations with 
> legitimate reasons (which there may be cases).  Any occurrences should 
> raise eyebrows, concerns, and requests to rewrite the offending code in 
> the same way as seeing, say, new HibernateUserManagerImpl(...) (aack!) 
> in someone's code today --okay maybe not that strong of a no-no, but 
> leaning in that same direction.

I think we are saying the same thing here.  Basically, you are suggesting that we monitor code as it goes into the repository and make sure nobody makes inappropriate calls to ctx.getBean("userManager") in places where they aren't supposed to, right?

I am still interested in seeing a full proposal, but my next question is what is to become of the Roller interface?  Right now most of the Roller.getXXXManager() methods just return the proper implementation of each Manager class.  With Spring would we replace the bodies of those methods with ctx.getBean("XXXManager")?  If so then does the Roller interface really serve a purpose moving forward?

-- Allen


> 
> --a.
> 
> 
> 
> 
> 
> 
> 
> 

Re: Spring and Roller

[Anil Gangolli <an...@busybuddha.org>]

Allen Gilliland wrote:

> I believe the relevant example is a case where someone looks up a bean
> > directly rather than working through an interface or other class.  In
> > our current implementation we expect that everyone uses
> > Roller.getXXXManager() to get access to a manager class by working
> > through an interface.  Using Spring someone could bypass using the
> > Roller interface by simply calling ctx.getBean("userManager").
> >
> > Again, I'm not sure if this is really a problem, but it seems reasonably
> > important to me.
Normally, following the dependency injection pattern, a bean would have 
a private field with the interface type (e.g. UserManager) and a setter 
setUserManager(UserManager userManager) that would get called at 
initialization by the BeanFactory.  Properly written, the bean never 
knows the implementation type.  It also doesn't know how to find an 
instance.  It just has it set by some outside entity, which is generally 
the BeanFactory but could be something else that instantiates and 
configures it.

Any use of  ctx.getBean("userManager") is a deviation from the 
dependency injection pattern back to the "service locator" pattern. It 
breaks the pattern in two ways.  It uses an explicit service lookup and 
it makes the bean context-aware. Hence it would always be a bit suspect 
and one should have to justify any such pattern deviations with 
legitimate reasons (which there may be cases).  Any occurrences should 
raise eyebrows, concerns, and requests to rewrite the offending code in 
the same way as seeing, say, new HibernateUserManagerImpl(...) (aack!) 
in someone's code today --okay maybe not that strong of a no-no, but 
leaning in that same direction.

--a.

Re: Spring and Roller

[Anil Gangolli <an...@busybuddha.org>]

Matt Raible wrote:
> [... much removed ...]
> I think Spring is great for assembling applications, but for something
> like Roller that's practically "feature complete" - I don't know that
> it makes a whole lot of sense.  Then again, if Roller's backend is
> difficult to test or maintain - using Spring would likely solve that. 
> I would say the decision to use Spring vs. don't use Spring should
> like with the folks that work on Roller the most - which is you and
> Dave.  It sounds like neither of you are very enthusiastic about using
> it - so my recommendation is simple. Don't. ;-)
>
> Matt
>
>   
I agree that Dave and Allen's consensus as well as understanding the 
pattern will be critical.  I'd like to think there are still major 
components that the other committers have and will be contributing.

I admit it constitutes somewhat of a rearchitecture, and there should be 
some feature-level drivers (like specific pluggable aspects in Roller).  
What I have gained from it in the apps I've done recently is that the 
resulting code is much more modifiable, modularized, pluggable, and I've 
found that has helped me add enhancements and changes.  The primary 
beneficiary for Roller is the developer, meaning the committers and 
especially the external non-committer enhancing/modifying Roller.  The 
indirect benefit to end-users comes when you have more developers adding 
pluggable components for different bits of Roller functionality that 
people can just pick up, plug in and use.  That's a dream and not sure 
if we will actually get there, but I think it is a good goal. Choosing 
Spring definitely doesn't get us there on its own; the hard part is 
still real architecture, but personally I've found that the dependency 
injection pattern helps me stay in the right frame of mind to achieve 
better modularity and more easily pluggable components.

--a.

Re: Spring and Roller

[Ted Husted <te...@gmail.com>]

On 3/7/06, Sean Gilligan <se...@msgilligan.com> wrote:
> I don't know the answer either -- I looked at WebWork briefly and it
> doesn't seem to have this thin-wrapper-around-Servlets subset that
> applies well to org.roller.presentation.velocity.  But I might have
> missed something.

The online documentation for WebWork doesn't do it justice, though the
new start page is an improvement.

* http://wiki.opensymphony.com/display/WW/EasyStartPage

I'm working on updating the documentation and the example applications
as part of the WebWork migration to Apache Struts, but I've only just
started on that this week.

As Matt Raible might say, WebWork has three major "sweet spots":
interceptors, result types, and UI tags.

* Inteceptors. The request processing lifecyle is built-up from a
series of "interceptors". WebWork interceptors use the same design
strategy as servlet filters. You can write one interceptor that can
pre- and post-process the request. The interceptors can be grouped
together into a stack. You can use one stack for the entire
application, or define special stacks for certain requests, or
mix-and-match stacks as needed. Interceptors are used to handle
validation, populating objects, logging, and any other "front
controller" behavior you'd like to share between actions.

By declaring which interceptors are on the stack, the developer
decides how much, or how little, the framework does. As a test-first
developer, what I like best about inceptors is that they are not just
for web applications. Business logic can use interceptors too, and
interceptor logic can be tested in isolation.

* Result Types. Unlike Struts ActionForwards, WebWork results are
reusable objects that can post-process the request, if needed. Rather
than just transfer to a resource, WebWork result types are used to
create Jasper reports and stream to Velocity templates. In a Roller
context, WebWork Results might be a good way to encapsulate the
various syndication formats.

* UI Tags. The WebWork tag library is based on templates and
stylesheets. What markup is output is determined by a FreeMarker
template (same idea as Velocity). If you want to change the output for
a given tag, you can plug in a new template for just that tag, and it
will automatically override the default. The UI tags themselves are
stylesheet driven. The stylesheet skins let you do things like use one
(count it: 1) tag to output the label, the control, and the validation
message.

And WebWork 2.2 already uses Spring under the covers. (Gotta love Spring!)

Overall, I would say that Webwork is to Struts, what Subversion is to
CVS. The same general idea, only better. Much better.

-Ted.

Re: Spring and Roller

[Max Rudman <mr...@steelbrick.com>]

I actually have a custom version of Roller running using Spring and I  
am more than willing to contribute the code I wrote or otherwise  
assist with Spring. I've been using Spring for a over a year now on  
many projects though I am by no means an expert. I think it is by far  
the best designed, most elegant library I ever used. Or maybe it's  
the design pattern it implements. :)

The main benefit I see in adopting Spring is its declarative  
transaction management. That means Roller.commit() and Roller.rollback 
() methods will no longer be necessary. I also see some benefit in  
being able to plug in various bits of Roller a little easier since  
all you'd need to do is edit XML-based config file. I've never used  
SpringMVC (the web framework part) but I know Spring has support  
classes for other presentation tier technologies (Struts, JSF and  
Velocity) allowing you to configure those components in DI fashion.

Here is what I had to do to introduce Spring into business logic tier  
(basically manager classes):

1) Wrote SpringProxyRoller which implements Roller. It loads Spring  
bean factor via BeanFactoryLocator mechanism and obtains the real  
SpringConfiguedRoller implementation which has all the collaborators  
(managers and Hibernate SessionFactory) injected by Spring. All  
methods of Roller interface are dispatched to SpringConfiguredRoller.

2) Wrote a SpringHibernatePersistenceStrategy which uses Spring- 
provided Hibernate support classes to obtain Hibernate Session  
object. Assuming manager objects are properly wired in XML file  
(wrapped by the appropriate AOP-based proxies) that gets you  
declarative transaction management.

Basically, very little, if anything, in the rest of Roller needs to  
change. The only thing is that Roller.commit() and Roller.rollback()  
are ignored, and top-level methods in Manager classes become  
transaction boundaries. By top-level methods I mean methods called  
from Struts actions.

Max

On Mar 7, 2006, at 2:42 PM, Sean Gilligan wrote:

> David M Johnson wrote:
>> True, but Anil is enthusiastic and willing to make a specific  
>> proposal. If it makes Roller easier to test, maintain or customize  
>> then it's worth considering pulling in other parts of Spring.
>> Spring is a collection of frameworks and utilities and we're  
>> already using some of that now. Plus, we're shipping the complete  
>> spring.jar with Roller (so we can use Acegi).
>> So, my first reaction -- "not another  framework" -- was really  
>> about Spring MVC. We already have a Web/MVC framework.
>
> The way that I'm thinking of using SpringMVC is extremely simple  
> and shouldn't be compared to Struts or most other MVC frameworks.   
> What I'm working on is really just a thin wrapper around the  
> Servlet interface, sort of a Servlets++.  At this point, my sandbox  
> refactoring is mixing in 3 classes and two interfaces from  
> SpringMVC into org.roller.presentation.velocity -- a total of about  
> 6 method calls to learn.  The biggest impact is that the Velocity  
> Context is being replaced by a Map/HashMap in many existing classes.
>
> I should be able to get a detailed proposal and possibly a proof-of- 
> concept (probably non-working) patch just to give you an idea of  
> how simple this is and the benefits received in flexibility and  
> view independence.
>
>  If I thought a using a
>> framework instead of our page servlets would improve Roller (maybe  
>> it does), I would be investigating the new Struts2/WorkWork stuff.
>
>
> > That
> > should (?) be the easiest migration path for our existing Struts  
> UI and
> > couldn't it do pretty much the same things as Spring/MVC for our
> > page/feed rendering code? That's an honest question -- I don't  
> know the
> > answer.
>
> I don't know the answer either -- I looked at WebWork briefly and  
> it doesn't seem to have this thin-wrapper-around-Servlets subset  
> that applies well to org.roller.presentation.velocity.  But I might  
> have missed something.
>
> Once I submit my proposal, if someone points out a way to achieve  
> similar results with Struts2/WebWork, then I'm all for it (but may  
> not commit to writing *all* of the code ;))
>
> I am enthusiastic and willing to make a specific proposal :)  I  
> just need a few more days.
>
> Regards,
>
> Sean
>

Re: Spring and Roller

[Sean Gilligan <se...@msgilligan.com>]

David M Johnson wrote:
> 
> True, but Anil is enthusiastic and willing to make a specific proposal. 
> If it makes Roller easier to test, maintain or customize then it's worth 
> considering pulling in other parts of Spring.
> 
> Spring is a collection of frameworks and utilities and we're already 
> using some of that now. Plus, we're shipping the complete spring.jar 
> with Roller (so we can use Acegi).
> 
> So, my first reaction -- "not another  framework" -- was really about 
> Spring MVC. We already have a Web/MVC framework.

The way that I'm thinking of using SpringMVC is extremely simple and 
shouldn't be compared to Struts or most other MVC frameworks.  What I'm 
working on is really just a thin wrapper around the Servlet interface, 
sort of a Servlets++.  At this point, my sandbox refactoring is mixing 
in 3 classes and two interfaces from SpringMVC into 
org.roller.presentation.velocity -- a total of about 6 method calls to 
learn.  The biggest impact is that the Velocity Context is being 
replaced by a Map/HashMap in many existing classes.

I should be able to get a detailed proposal and possibly a 
proof-of-concept (probably non-working) patch just to give you an idea 
of how simple this is and the benefits received in flexibility and view 
independence.

  If I thought a using a
> framework instead of our page servlets would improve Roller (maybe it 
> does), I would be investigating the new Struts2/WorkWork stuff.


 > That
 > should (?) be the easiest migration path for our existing Struts UI and
 > couldn't it do pretty much the same things as Spring/MVC for our
 > page/feed rendering code? That's an honest question -- I don't know the
 > answer.

I don't know the answer either -- I looked at WebWork briefly and it 
doesn't seem to have this thin-wrapper-around-Servlets subset that 
applies well to org.roller.presentation.velocity.  But I might have 
missed something.

Once I submit my proposal, if someone points out a way to achieve 
similar results with Struts2/WebWork, then I'm all for it (but may not 
commit to writing *all* of the code ;))

I am enthusiastic and willing to make a specific proposal :)  I just 
need a few more days.

Regards,

Sean

Re: Spring and Roller

[David M Johnson <Da...@Sun.COM>]

On Mar 5, 2006, at 8:11 PM, Matt Raible wrote:
> I think Spring is great for assembling applications, but for something
> like Roller that's practically "feature complete" - I don't know that
> it makes a whole lot of sense.  Then again, if Roller's backend is
> difficult to test or maintain - using Spring would likely solve that.
> I would say the decision to use Spring vs. don't use Spring should
> like with the folks that work on Roller the most - which is you and
> Dave.  It sounds like neither of you are very enthusiastic about using
> it - so my recommendation is simple. Don't. ;-)

True, but Anil is enthusiastic and willing to make a specific  
proposal. If it makes Roller easier to test, maintain or customize  
then it's worth considering pulling in other parts of Spring.

Spring is a collection of frameworks and utilities and we're already  
using some of that now. Plus, we're shipping the complete spring.jar  
with Roller (so we can use Acegi).

So, my first reaction -- "not another  framework" -- was really about  
Spring MVC. We already have a Web/MVC framework. If I thought a using  
a framework instead of our page servlets would improve Roller (maybe  
it does), I would be investigating the new Struts2/WorkWork stuff.  
That should (?) be the easiest migration path for our existing Struts  
UI and couldn't it do pretty much the same things as Spring/MVC for  
our page/feed rendering code? That's an honest question -- I don't  
know the answer.

- Dave

Re: Spring and Roller

[Matt Raible <mr...@gmail.com>]

On 3/5/06, Allen Gilliland <Al...@sun.com> wrote:
> On Sun, 2006-03-05 at 15:59, Matt Raible wrote:
> > On 3/5/06, Allen Gilliland <Al...@sun.com> wrote:
> > > On Sun, 2006-03-05 at 15:05, Anil Gangolli wrote:
> > > > Allen Gilliland wrote:
> > > > >
> > > > > My personal opinion is that we can do this without Spring using a little
> > > > > bit more of our own code.  Of course it's nice to have the work already
> > > > > done for us by Spring instead.
> > > > >
> > > > > One question I have is are there any controls on what beans someone can
> > > > > access via Spring?  i.e. if I use appfuse as an example I noticed that
> > > > > there is a bean defined for the Hibernate sessionFactory.  is there
> > > > > anything that prevents someone in the presentation layer from trying
> > > > > ctx.getBean("sessionFactory")?  that is one thing that I wasn't sure
> > > > > about.
> > > > >
> > > > We could control context population as we want.  Not all Spring beans
> > > > are necessarily exposed in the velocity context.
> > >
> > > I wasn't talking about the Velocity context actually, I sure hope nobody
> > > would have access to the Spring context in their templates.  What I mean
> > > is that it appears that any bean defined in the Spring application
> > > context is available to anyone who wants to look it up via
> > > ctx.getBean("bean").
> > >
> > > It may not really be an important problem, but I believe there is a
> > > potential for someone with access to the code to lookup a bean that they
> > > really shouldn't be allowed to access directly.
> > >
> > > I believe the relevant example is a case where someone looks up a bean
> > > directly rather than working through an interface or other class.  In
> > > our current implementation we expect that everyone uses
> > > Roller.getXXXManager() to get access to a manager class by working
> > > through an interface.  Using Spring someone could bypass using the
> > > Roller interface by simply calling ctx.getBean("userManager").
> > >
> > > Again, I'm not sure if this is really a problem, but it seems reasonably
> > > important to me.
> >
> > I don't see how using Spring is any different than the current system.
> >  If someone really wants to call a persistence class, then can, can't
> > they? We all see things when they're checked in - don't we? It's not
> > like using some new technology changes the way how we do code reviews
> > and approve checkins.
>
> You are absolutely correct that this isn't an issue if we all monitor
> the code and make sure that nobody commits code that does things the
> wrong way, but I think that is somewhat optimistic thinking.  Things
> always manage to slip through the cracks eventually.
>
> I also disagree that this is the same thing that we currently have.
> Currently you have no way of accessing classes which are meant to be
> hidden behind interfaces.  It seems to me that Spring provides an
> opportunity to bypass that and lookup beans that are possibly meant to
> only be available to classes behind interfaces.
>
> What about the example that I mentioned from appfuse?  Couldn't someone
> in the "web" module call ctx.getBean("sessionFactory") and then have
> direct access to the Hibernate session factory?  If so, then that sounds
> dangerous to me.

Absolutely.  You can it dangerous - I call it flexible.  Then again,
AppFuse is not the same thing as Roller.  It's a programming platform
in a sense - and it expects 1) developers to be smart and 2) to know
what they're doing.  Then again, it's their application, not mine. ;-)
 Roller is a bit different - but I still prefer open systems rather
than ones that are locked down.

That being said, I'm sure there's a way to prevent this (using AOP or
something) - I just don't know it off the top of my head.

I think Spring is great for assembling applications, but for something
like Roller that's practically "feature complete" - I don't know that
it makes a whole lot of sense.  Then again, if Roller's backend is
difficult to test or maintain - using Spring would likely solve that. 
I would say the decision to use Spring vs. don't use Spring should
like with the folks that work on Roller the most - which is you and
Dave.  It sounds like neither of you are very enthusiastic about using
it - so my recommendation is simple. Don't. ;-)

Matt

>
> -- Allen
>
>
> >
> > Spring is really just a simplification of a lookup mechanism.  If it
> > complicates things, I'd say we don't use it.  However, more and more
> > developers are familiar with how it works - and it might lead to more
> > participation.
> >
> > I'm +0 either way since I rarely dig into Roller's backend.  However,
> > if it was configured with Spring - I might be more inclined to do so.
> > ;-)
> >
> > Matt
> >
> > >
> > > -- Allen
> > >
> > >
> > > >
> > > > > The nice thing about using a normal Java based hierarchy for accessing
> > > > > objects is that nobody can access objects that they aren't supposed to
> > > > > know about.  Another example from appfuse would be the way that the app
> > > > > separates out a "service" and "dao" layer, what prevents someone from
> > > > > directly accessing a dao bean even though they aren't supposed to?
> > > > >
> > > > >
> > > > I'm not really familiar with AppFuse's model; I'd guess Matt R is :-)
> > > > and could answer with respect to that. Spring beans are just plain Java
> > > > classes that happen to be instantiated and configured by Spring.  We can
> > > > choose our own structure.  If we choose to use Spring MVC or some other
> > > > model in addition to basic beans, that would place more structural
> > > > constraints and choices we would be adopting as a result, but this is
> > > > independent.  I'm not advocating that but we might want to consider that
> > > > later too;  I haven't really used it in the realm of presentation.  I
> > > > have used the basic BeanFactory and ApplicationContext mechanisms quite
> > > > a bit now mostly for backend database apps that have little or no user
> > > > interface.  They're great.
> > > > >> Taking this path would suggest that we use Spring's xml-based
> > > > >> configuration mechanisms instead of roller.properties.  It's possible
> > > > >> (as Matt has done for some of the Acegi-related properties) to support
> > > > >> configuration via roller.properties rather than requiring users to edit
> > > > >> the xml, but I think that the approach taken by Matt for the security
> > > > >> props (having code in RollerContext initialization read the roller props
> > > > >> and call appropriate bean setters)  would be onerous to extend to a
> > > > >> large number of properties.  What would probably work nicely (and be
> > > > >> easy) is to have most of the Spring configuration refer where necessary
> > > > >> (by property paths) to one bean representing the equivalent of
> > > > >> roller.properties and configured in one xml file (or even a properties
> > > > >> file if we initialize that one bean specially).
> > > > >>
> > > > >
> > > > > This is the other big thing that I am concerned about with Spring in
> > > > > Roller.  I really don't want go back to making the config more
> > > > > complicated and spread out.
> > > > >
> > > > It would be just as centralized as roller.properties /
> > > > roller-custom.properties but as xml.  In fact with a bit of simple
> > > > development we could even stick with the present property file form for
> > > > the few properties that we think should be exposed to site admins, so
> > > > this wouldn't have to change.  Developers/customizers would see the full
> > > > range of Spring however.
> > > > > I'd like to see more details about the implementation before making any
> > > > > final decisions though.  It's probably not a big deal if the only use of
> > > > > the Spring appliction context is to inject special overrides for classes
> > > > > like RollerImpl, ManagerImpls, etc.  Since these classes really don't
> > > > > need to be modified by normal users we can just leave it up to advanced
> > > > > users to know how to open up the webapp and modify the Spring
> > > > > Application context to make these customizations.
> > > > >
> > > > > The roller.properties would still serve its primary purpose, which is to
> > > > > make it easy for Roller admins to easily apply settings for the things
> > > > > we expect people to want to change.
> > > > >
> > > > >
> > > > Yes, that's the intent there.
> > > > >> I think it could be entered gradually, but eventually would mean a lot
> > > > >> of minor-to-moderate restructuring to really utilize the pattern,
> > > > >> feeling kind-of Roller 3.0-ish.
> > > > >>
> > > > >> Would there be sufficient support for seeing a proposal along these
> > > > >> lines?  I probably won't embark on such a proposal unless there's some
> > > > >> predisposition to move in this direction.
> > > > >>
> > > > >
> > > > > I would definitely like to see it.
> > > > >
> > > > > -- Allen
> > > > >
> > > > >
> > > > >
> > > > >> --a.
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
>
>

Re: Spring and Roller

[Allen Gilliland <Al...@Sun.COM>]

On Sun, 2006-03-05 at 15:59, Matt Raible wrote:
> On 3/5/06, Allen Gilliland <Al...@sun.com> wrote:
> > On Sun, 2006-03-05 at 15:05, Anil Gangolli wrote:
> > > Allen Gilliland wrote:
> > > >
> > > > My personal opinion is that we can do this without Spring using a little
> > > > bit more of our own code.  Of course it's nice to have the work already
> > > > done for us by Spring instead.
> > > >
> > > > One question I have is are there any controls on what beans someone can
> > > > access via Spring?  i.e. if I use appfuse as an example I noticed that
> > > > there is a bean defined for the Hibernate sessionFactory.  is there
> > > > anything that prevents someone in the presentation layer from trying
> > > > ctx.getBean("sessionFactory")?  that is one thing that I wasn't sure
> > > > about.
> > > >
> > > We could control context population as we want.  Not all Spring beans
> > > are necessarily exposed in the velocity context.
> >
> > I wasn't talking about the Velocity context actually, I sure hope nobody
> > would have access to the Spring context in their templates.  What I mean
> > is that it appears that any bean defined in the Spring application
> > context is available to anyone who wants to look it up via
> > ctx.getBean("bean").
> >
> > It may not really be an important problem, but I believe there is a
> > potential for someone with access to the code to lookup a bean that they
> > really shouldn't be allowed to access directly.
> >
> > I believe the relevant example is a case where someone looks up a bean
> > directly rather than working through an interface or other class.  In
> > our current implementation we expect that everyone uses
> > Roller.getXXXManager() to get access to a manager class by working
> > through an interface.  Using Spring someone could bypass using the
> > Roller interface by simply calling ctx.getBean("userManager").
> >
> > Again, I'm not sure if this is really a problem, but it seems reasonably
> > important to me.
> 
> I don't see how using Spring is any different than the current system.
>  If someone really wants to call a persistence class, then can, can't
> they? We all see things when they're checked in - don't we? It's not
> like using some new technology changes the way how we do code reviews
> and approve checkins.

You are absolutely correct that this isn't an issue if we all monitor
the code and make sure that nobody commits code that does things the
wrong way, but I think that is somewhat optimistic thinking.  Things
always manage to slip through the cracks eventually.

I also disagree that this is the same thing that we currently have. 
Currently you have no way of accessing classes which are meant to be
hidden behind interfaces.  It seems to me that Spring provides an
opportunity to bypass that and lookup beans that are possibly meant to
only be available to classes behind interfaces.

What about the example that I mentioned from appfuse?  Couldn't someone
in the "web" module call ctx.getBean("sessionFactory") and then have
direct access to the Hibernate session factory?  If so, then that sounds
dangerous to me.

-- Allen


> 
> Spring is really just a simplification of a lookup mechanism.  If it
> complicates things, I'd say we don't use it.  However, more and more
> developers are familiar with how it works - and it might lead to more
> participation.
> 
> I'm +0 either way since I rarely dig into Roller's backend.  However,
> if it was configured with Spring - I might be more inclined to do so.
> ;-)
> 
> Matt
> 
> >
> > -- Allen
> >
> >
> > >
> > > > The nice thing about using a normal Java based hierarchy for accessing
> > > > objects is that nobody can access objects that they aren't supposed to
> > > > know about.  Another example from appfuse would be the way that the app
> > > > separates out a "service" and "dao" layer, what prevents someone from
> > > > directly accessing a dao bean even though they aren't supposed to?
> > > >
> > > >
> > > I'm not really familiar with AppFuse's model; I'd guess Matt R is :-)
> > > and could answer with respect to that. Spring beans are just plain Java
> > > classes that happen to be instantiated and configured by Spring.  We can
> > > choose our own structure.  If we choose to use Spring MVC or some other
> > > model in addition to basic beans, that would place more structural
> > > constraints and choices we would be adopting as a result, but this is
> > > independent.  I'm not advocating that but we might want to consider that
> > > later too;  I haven't really used it in the realm of presentation.  I
> > > have used the basic BeanFactory and ApplicationContext mechanisms quite
> > > a bit now mostly for backend database apps that have little or no user
> > > interface.  They're great.
> > > >> Taking this path would suggest that we use Spring's xml-based
> > > >> configuration mechanisms instead of roller.properties.  It's possible
> > > >> (as Matt has done for some of the Acegi-related properties) to support
> > > >> configuration via roller.properties rather than requiring users to edit
> > > >> the xml, but I think that the approach taken by Matt for the security
> > > >> props (having code in RollerContext initialization read the roller props
> > > >> and call appropriate bean setters)  would be onerous to extend to a
> > > >> large number of properties.  What would probably work nicely (and be
> > > >> easy) is to have most of the Spring configuration refer where necessary
> > > >> (by property paths) to one bean representing the equivalent of
> > > >> roller.properties and configured in one xml file (or even a properties
> > > >> file if we initialize that one bean specially).
> > > >>
> > > >
> > > > This is the other big thing that I am concerned about with Spring in
> > > > Roller.  I really don't want go back to making the config more
> > > > complicated and spread out.
> > > >
> > > It would be just as centralized as roller.properties /
> > > roller-custom.properties but as xml.  In fact with a bit of simple
> > > development we could even stick with the present property file form for
> > > the few properties that we think should be exposed to site admins, so
> > > this wouldn't have to change.  Developers/customizers would see the full
> > > range of Spring however.
> > > > I'd like to see more details about the implementation before making any
> > > > final decisions though.  It's probably not a big deal if the only use of
> > > > the Spring appliction context is to inject special overrides for classes
> > > > like RollerImpl, ManagerImpls, etc.  Since these classes really don't
> > > > need to be modified by normal users we can just leave it up to advanced
> > > > users to know how to open up the webapp and modify the Spring
> > > > Application context to make these customizations.
> > > >
> > > > The roller.properties would still serve its primary purpose, which is to
> > > > make it easy for Roller admins to easily apply settings for the things
> > > > we expect people to want to change.
> > > >
> > > >
> > > Yes, that's the intent there.
> > > >> I think it could be entered gradually, but eventually would mean a lot
> > > >> of minor-to-moderate restructuring to really utilize the pattern,
> > > >> feeling kind-of Roller 3.0-ish.
> > > >>
> > > >> Would there be sufficient support for seeing a proposal along these
> > > >> lines?  I probably won't embark on such a proposal unless there's some
> > > >> predisposition to move in this direction.
> > > >>
> > > >
> > > > I would definitely like to see it.
> > > >
> > > > -- Allen
> > > >
> > > >
> > > >
> > > >> --a.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > >
> >
> >

Re: Spring and Roller

[Matt Raible <mr...@gmail.com>]

On 3/5/06, Allen Gilliland <Al...@sun.com> wrote:
> On Sun, 2006-03-05 at 15:05, Anil Gangolli wrote:
> > Allen Gilliland wrote:
> > >
> > > My personal opinion is that we can do this without Spring using a little
> > > bit more of our own code.  Of course it's nice to have the work already
> > > done for us by Spring instead.
> > >
> > > One question I have is are there any controls on what beans someone can
> > > access via Spring?  i.e. if I use appfuse as an example I noticed that
> > > there is a bean defined for the Hibernate sessionFactory.  is there
> > > anything that prevents someone in the presentation layer from trying
> > > ctx.getBean("sessionFactory")?  that is one thing that I wasn't sure
> > > about.
> > >
> > We could control context population as we want.  Not all Spring beans
> > are necessarily exposed in the velocity context.
>
> I wasn't talking about the Velocity context actually, I sure hope nobody
> would have access to the Spring context in their templates.  What I mean
> is that it appears that any bean defined in the Spring application
> context is available to anyone who wants to look it up via
> ctx.getBean("bean").
>
> It may not really be an important problem, but I believe there is a
> potential for someone with access to the code to lookup a bean that they
> really shouldn't be allowed to access directly.
>
> I believe the relevant example is a case where someone looks up a bean
> directly rather than working through an interface or other class.  In
> our current implementation we expect that everyone uses
> Roller.getXXXManager() to get access to a manager class by working
> through an interface.  Using Spring someone could bypass using the
> Roller interface by simply calling ctx.getBean("userManager").
>
> Again, I'm not sure if this is really a problem, but it seems reasonably
> important to me.

I don't see how using Spring is any different than the current system.
 If someone really wants to call a persistence class, then can, can't
they? We all see things when they're checked in - don't we? It's not
like using some new technology changes the way how we do code reviews
and approve checkins.

Spring is really just a simplification of a lookup mechanism.  If it
complicates things, I'd say we don't use it.  However, more and more
developers are familiar with how it works - and it might lead to more
participation.

I'm +0 either way since I rarely dig into Roller's backend.  However,
if it was configured with Spring - I might be more inclined to do so.
;-)

Matt

>
> -- Allen
>
>
> >
> > > The nice thing about using a normal Java based hierarchy for accessing
> > > objects is that nobody can access objects that they aren't supposed to
> > > know about.  Another example from appfuse would be the way that the app
> > > separates out a "service" and "dao" layer, what prevents someone from
> > > directly accessing a dao bean even though they aren't supposed to?
> > >
> > >
> > I'm not really familiar with AppFuse's model; I'd guess Matt R is :-)
> > and could answer with respect to that. Spring beans are just plain Java
> > classes that happen to be instantiated and configured by Spring.  We can
> > choose our own structure.  If we choose to use Spring MVC or some other
> > model in addition to basic beans, that would place more structural
> > constraints and choices we would be adopting as a result, but this is
> > independent.  I'm not advocating that but we might want to consider that
> > later too;  I haven't really used it in the realm of presentation.  I
> > have used the basic BeanFactory and ApplicationContext mechanisms quite
> > a bit now mostly for backend database apps that have little or no user
> > interface.  They're great.
> > >> Taking this path would suggest that we use Spring's xml-based
> > >> configuration mechanisms instead of roller.properties.  It's possible
> > >> (as Matt has done for some of the Acegi-related properties) to support
> > >> configuration via roller.properties rather than requiring users to edit
> > >> the xml, but I think that the approach taken by Matt for the security
> > >> props (having code in RollerContext initialization read the roller props
> > >> and call appropriate bean setters)  would be onerous to extend to a
> > >> large number of properties.  What would probably work nicely (and be
> > >> easy) is to have most of the Spring configuration refer where necessary
> > >> (by property paths) to one bean representing the equivalent of
> > >> roller.properties and configured in one xml file (or even a properties
> > >> file if we initialize that one bean specially).
> > >>
> > >
> > > This is the other big thing that I am concerned about with Spring in
> > > Roller.  I really don't want go back to making the config more
> > > complicated and spread out.
> > >
> > It would be just as centralized as roller.properties /
> > roller-custom.properties but as xml.  In fact with a bit of simple
> > development we could even stick with the present property file form for
> > the few properties that we think should be exposed to site admins, so
> > this wouldn't have to change.  Developers/customizers would see the full
> > range of Spring however.
> > > I'd like to see more details about the implementation before making any
> > > final decisions though.  It's probably not a big deal if the only use of
> > > the Spring appliction context is to inject special overrides for classes
> > > like RollerImpl, ManagerImpls, etc.  Since these classes really don't
> > > need to be modified by normal users we can just leave it up to advanced
> > > users to know how to open up the webapp and modify the Spring
> > > Application context to make these customizations.
> > >
> > > The roller.properties would still serve its primary purpose, which is to
> > > make it easy for Roller admins to easily apply settings for the things
> > > we expect people to want to change.
> > >
> > >
> > Yes, that's the intent there.
> > >> I think it could be entered gradually, but eventually would mean a lot
> > >> of minor-to-moderate restructuring to really utilize the pattern,
> > >> feeling kind-of Roller 3.0-ish.
> > >>
> > >> Would there be sufficient support for seeing a proposal along these
> > >> lines?  I probably won't embark on such a proposal unless there's some
> > >> predisposition to move in this direction.
> > >>
> > >
> > > I would definitely like to see it.
> > >
> > > -- Allen
> > >
> > >
> > >
> > >> --a.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> >
>
>

Re: Spring and Roller

[Allen Gilliland <Al...@Sun.COM>]

On Sun, 2006-03-05 at 15:05, Anil Gangolli wrote:
> Allen Gilliland wrote:
> >
> > My personal opinion is that we can do this without Spring using a little
> > bit more of our own code.  Of course it's nice to have the work already
> > done for us by Spring instead.
> >
> > One question I have is are there any controls on what beans someone can
> > access via Spring?  i.e. if I use appfuse as an example I noticed that
> > there is a bean defined for the Hibernate sessionFactory.  is there
> > anything that prevents someone in the presentation layer from trying
> > ctx.getBean("sessionFactory")?  that is one thing that I wasn't sure
> > about.
> >   
> We could control context population as we want.  Not all Spring beans 
> are necessarily exposed in the velocity context.

I wasn't talking about the Velocity context actually, I sure hope nobody
would have access to the Spring context in their templates.  What I mean
is that it appears that any bean defined in the Spring application
context is available to anyone who wants to look it up via
ctx.getBean("bean").

It may not really be an important problem, but I believe there is a
potential for someone with access to the code to lookup a bean that they
really shouldn't be allowed to access directly.

I believe the relevant example is a case where someone looks up a bean
directly rather than working through an interface or other class.  In
our current implementation we expect that everyone uses
Roller.getXXXManager() to get access to a manager class by working
through an interface.  Using Spring someone could bypass using the
Roller interface by simply calling ctx.getBean("userManager").

Again, I'm not sure if this is really a problem, but it seems reasonably
important to me.

-- Allen


> 
> > The nice thing about using a normal Java based hierarchy for accessing
> > objects is that nobody can access objects that they aren't supposed to
> > know about.  Another example from appfuse would be the way that the app
> > separates out a "service" and "dao" layer, what prevents someone from
> > directly accessing a dao bean even though they aren't supposed to?
> >
> >   
> I'm not really familiar with AppFuse's model; I'd guess Matt R is :-) 
> and could answer with respect to that. Spring beans are just plain Java 
> classes that happen to be instantiated and configured by Spring.  We can 
> choose our own structure.  If we choose to use Spring MVC or some other 
> model in addition to basic beans, that would place more structural 
> constraints and choices we would be adopting as a result, but this is 
> independent.  I'm not advocating that but we might want to consider that 
> later too;  I haven't really used it in the realm of presentation.  I 
> have used the basic BeanFactory and ApplicationContext mechanisms quite 
> a bit now mostly for backend database apps that have little or no user 
> interface.  They're great.
> >> Taking this path would suggest that we use Spring's xml-based 
> >> configuration mechanisms instead of roller.properties.  It's possible 
> >> (as Matt has done for some of the Acegi-related properties) to support 
> >> configuration via roller.properties rather than requiring users to edit 
> >> the xml, but I think that the approach taken by Matt for the security 
> >> props (having code in RollerContext initialization read the roller props 
> >> and call appropriate bean setters)  would be onerous to extend to a 
> >> large number of properties.  What would probably work nicely (and be 
> >> easy) is to have most of the Spring configuration refer where necessary 
> >> (by property paths) to one bean representing the equivalent of 
> >> roller.properties and configured in one xml file (or even a properties 
> >> file if we initialize that one bean specially).
> >>     
> >
> > This is the other big thing that I am concerned about with Spring in
> > Roller.  I really don't want go back to making the config more
> > complicated and spread out.
> >   
> It would be just as centralized as roller.properties / 
> roller-custom.properties but as xml.  In fact with a bit of simple 
> development we could even stick with the present property file form for 
> the few properties that we think should be exposed to site admins, so 
> this wouldn't have to change.  Developers/customizers would see the full 
> range of Spring however.
> > I'd like to see more details about the implementation before making any
> > final decisions though.  It's probably not a big deal if the only use of
> > the Spring appliction context is to inject special overrides for classes
> > like RollerImpl, ManagerImpls, etc.  Since these classes really don't
> > need to be modified by normal users we can just leave it up to advanced
> > users to know how to open up the webapp and modify the Spring
> > Application context to make these customizations.
> >
> > The roller.properties would still serve its primary purpose, which is to
> > make it easy for Roller admins to easily apply settings for the things
> > we expect people to want to change.
> >
> >   
> Yes, that's the intent there.
> >> I think it could be entered gradually, but eventually would mean a lot 
> >> of minor-to-moderate restructuring to really utilize the pattern, 
> >> feeling kind-of Roller 3.0-ish.
> >>
> >> Would there be sufficient support for seeing a proposal along these 
> >> lines?  I probably won't embark on such a proposal unless there's some 
> >> predisposition to move in this direction.
> >>     
> >
> > I would definitely like to see it.
> >
> > -- Allen
> >
> >
> >   
> >> --a.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>     
> >
> >
> >   
> 

Re: Spring and Roller

[Anil Gangolli <an...@busybuddha.org>]

Allen Gilliland wrote:
> My initial opinion is still "mixed bag", but I am definitely willing to
> hear more about how you would want to integrate Spring.  I still haven't
> really done much with Spring, but I do see some ways in which it could
> be useful to Roller.
>
> On Sun, 2006-03-05 at 09:09, Anil Gangolli wrote:
>   
>> I've been using basic Spring dependency injection and initialization 
>> (BeanFactory/ApplicationContext) functionality  in some projects at work 
>> and have really been happy with how it encourages clean modularization 
>> and helps me to get more pluggable reusable components while keeping 
>> almost all of the code completely unaware of Spring itself.
>>
>> I think using the dependency injection pattern would really help us 
>> clean up interdependencies and make Roller more pluggable and 
>> modifiable.  Before spending time on a real proposal, I wanted to gauge 
>> interest in this.  Note that this is separable from any inclination to 
>> use Spring MVC (as Sean G is trying) or other Spring features (like the 
>> declarative transaction management that Matt R suggested).
>>     
>
> My personal opinion is that we can do this without Spring using a little
> bit more of our own code.  Of course it's nice to have the work already
> done for us by Spring instead.
>
> One question I have is are there any controls on what beans someone can
> access via Spring?  i.e. if I use appfuse as an example I noticed that
> there is a bean defined for the Hibernate sessionFactory.  is there
> anything that prevents someone in the presentation layer from trying
> ctx.getBean("sessionFactory")?  that is one thing that I wasn't sure
> about.
>   
We could control context population as we want.  Not all Spring beans 
are necessarily exposed in the velocity context.

> The nice thing about using a normal Java based hierarchy for accessing
> objects is that nobody can access objects that they aren't supposed to
> know about.  Another example from appfuse would be the way that the app
> separates out a "service" and "dao" layer, what prevents someone from
> directly accessing a dao bean even though they aren't supposed to?
>
>   
I'm not really familiar with AppFuse's model; I'd guess Matt R is :-) 
and could answer with respect to that. Spring beans are just plain Java 
classes that happen to be instantiated and configured by Spring.  We can 
choose our own structure.  If we choose to use Spring MVC or some other 
model in addition to basic beans, that would place more structural 
constraints and choices we would be adopting as a result, but this is 
independent.  I'm not advocating that but we might want to consider that 
later too;  I haven't really used it in the realm of presentation.  I 
have used the basic BeanFactory and ApplicationContext mechanisms quite 
a bit now mostly for backend database apps that have little or no user 
interface.  They're great.
>> Taking this path would suggest that we use Spring's xml-based 
>> configuration mechanisms instead of roller.properties.  It's possible 
>> (as Matt has done for some of the Acegi-related properties) to support 
>> configuration via roller.properties rather than requiring users to edit 
>> the xml, but I think that the approach taken by Matt for the security 
>> props (having code in RollerContext initialization read the roller props 
>> and call appropriate bean setters)  would be onerous to extend to a 
>> large number of properties.  What would probably work nicely (and be 
>> easy) is to have most of the Spring configuration refer where necessary 
>> (by property paths) to one bean representing the equivalent of 
>> roller.properties and configured in one xml file (or even a properties 
>> file if we initialize that one bean specially).
>>     
>
> This is the other big thing that I am concerned about with Spring in
> Roller.  I really don't want go back to making the config more
> complicated and spread out.
>   
It would be just as centralized as roller.properties / 
roller-custom.properties but as xml.  In fact with a bit of simple 
development we could even stick with the present property file form for 
the few properties that we think should be exposed to site admins, so 
this wouldn't have to change.  Developers/customizers would see the full 
range of Spring however.
> I'd like to see more details about the implementation before making any
> final decisions though.  It's probably not a big deal if the only use of
> the Spring appliction context is to inject special overrides for classes
> like RollerImpl, ManagerImpls, etc.  Since these classes really don't
> need to be modified by normal users we can just leave it up to advanced
> users to know how to open up the webapp and modify the Spring
> Application context to make these customizations.
>
> The roller.properties would still serve its primary purpose, which is to
> make it easy for Roller admins to easily apply settings for the things
> we expect people to want to change.
>
>   
Yes, that's the intent there.
>> I think it could be entered gradually, but eventually would mean a lot 
>> of minor-to-moderate restructuring to really utilize the pattern, 
>> feeling kind-of Roller 3.0-ish.
>>
>> Would there be sufficient support for seeing a proposal along these 
>> lines?  I probably won't embark on such a proposal unless there's some 
>> predisposition to move in this direction.
>>     
>
> I would definitely like to see it.
>
> -- Allen
>
>
>   
>> --a.
>>
>>
>>
>>
>>
>>
>>
>>     
>
>
>   

Re: Spring and Roller

[Sean Gilligan <se...@msgilligan.com>]

Sean Gilligan wrote:
> looking at Spring for distributed transactions
I mean DECLARATIVE transactions, sorry...

-- Sean

Re: Spring and Roller

[Matt Raible <mr...@gmail.com>]

On 3/6/06, Sean Gilligan <se...@msgilligan.com> wrote:
> Allen Gilliland wrote:
> > On Mon, 2006-03-06 at 15:06, Sean Gilligan wrote:
> >> Allen, I definitely recommend that you at least spend a couple of hours
> >> looking at Spring for distributed transactions and pluggable ORM layers
> >> before going ahead with your proposed refactoring of the transaction code.
> >
> > I will certainly do that, but this may be the realm where I would be least likely to start using a framework like Spring.
> In many ways, Spring is the "un-framework".  The developers try really
> hard to allow you to minimize or avoid altogether dependencies on the
> framework, as well as give you choices "a la carte" rather than
> force/push you to adopt everything.  Many commercial offerings (for
> obvious reasons) encourage you to depend on their product/API in as many
> ways as possible.  The same is true for many Open Source projects as
> well, as it is only human to want the product of your labor to solve as
> many problems as possible.  In the Spring Framework, I see a concerted
> effort and a philosophy of resisting this urge as much as possible.
>
> >  My main concern is that we would move away from our own implementation of Hibernate and into a version of Spring Hibernate, doing Hibernate the way Spring suggests.
> My (limited) understanding of how Spring works at this layer is that you
> can use Springs declarative transactions as method interceptors on top
> of just about any DAO layer or service object and that you don't have to
> use the Spring Hibernate Templates to do this.
>
> In other words, *I think* you could use Spring Declarative Transactions
> without moving away from Roller's current implementation of Hibernate.
> I'm not sure that this will work, though.  My experience has been using
> the default Spring+Hibernate+Declarative-Transactions implementation.
> Anil, Matt, do you guys have any guidance here?

We could likely continue to use Roller's transaction setup.  The main
thing you need is to have your objects (managers) instantiated by
Spring so it can proxy them and wrap interceptors around their
methods.  So we'd basically replace any manager lookup code with
Spring's DI - and be good to go.  I think the best way to go about
doing this is to prototype small chunks rather than going whole hog.

We might have to use Spring's support for Hibernate if we want to use
their OpenSessionInViewFilter, but I don't think so.  There's an
example in their documentation of just injecting a SessionFactory into
code and then using sessionFactory.getCurrentSession() to perform
operations. This provides similar functionality to what Spring
provides, save for a common exception hierarchy among persistence
frameworks.

http://static.springframework.org/spring/docs/1.2.x/reference/orm.html#d0e7576

http://tinyurl.com/fl7wt

Matt

>
> The key to using Spring Declarative Transactions is to wrap existing
> Dao/Manager/Service Objects with the "TransactionProxyFactoryBean",
> which implements the pre/post method-call magic to implement the
> transactions.  This means that whatever is using the Managers should be
> getting the implementation from BeanFactory, so this is one change that
> would be required in the Roller code.  A side benefit to this change is
> that the same mechanism used to install the proxies is the mechanism
> used to plug in other manager implementations.
>
> Now the proxies need to have a TransactionManager injected and Spring
> provides a HibernateTransactionManager, which in turn requires (via
> D.I.) a Hibernate SessionFactory.  I don't know what would be involved
> in "sharing" a SessionFactory between the current Roller code and these
> Spring components.  Anil, Matt?
>
>  >> If you really wanted to keep certain beans
> >> restricted to a particular layer or module, that module could have a
> >> private BeanFactory that the other components are not aware of.  In
> >> other words they won't be able to get access to the "ctx"
> >> variable/reference.  (In my opinion, this shouldn't be necessary.)
> >
> > Hmm.  That sounds promising to me.  I'd like to hear more about that.
>
> I've never done this before,  but believe it should be possible.  Most
> Spring apps tend to use a single (Web)ApplicationContext (which is a
> subclass of BeanFactory) that is a single context (container).  Most
> apps break up the layers (Presentation, Service, Data) into separate
> configuration files, but objects from all layers are (theoretically)
> obtainable by any component that has a context reference.  (Although, as
> Anil says, using a context reference is to be avoided in favor of DI.)
>
> So you should be able to allocate a private BeanFactory in the Business
> or Persistence layer that nothing else is aware of.  (By just choosing a
> constructor that points to a config file or resource and stuffing the
> context away somewhere.)
>
> I'm willing to look into this further if that will help you.
> >
> >>> This is the other big thing that I am concerned about with Spring in
> >>> Roller.  I really don't want go back to making the config more
> >>> complicated and spread out.
> >> This is a valid concern and one that Spring doesn't automatically
> >> address.  And there is an inherent trade-off in making components more
> >> modular vs. keeping configuration simple and in one place.  Anil (and
> >> the team) should address these issues in any proposal(s).
> >
> > I think at this point I am also just having a bit of fun giving you guys a hard time about your attempts to get Spring into Roller ;)
>
> Hah!  The camel's nose is already in the tent, via Acegi!  Resistance is
> futile! ;)
>
> Seriously, though, the Spring Framework (or un-framework) is modular and
> adopting it is not an all-or-nothing decision.  There are multiple ways
> that it could help (or hurt, if misused) Roller.  Each one should be
> carefully analyzed and discussed and the possible answers are "yes",
> "no", and "yes, but here's a better way...".  We should pay careful
> attention to issues of configuration and the trade-off between
> modularity and complexity.  It is important to distinguish between
> implementing (or refactoring) a module to use IOC/DI vs. implementing an
> interface vs. extending a class.  It's good that you're playing the role
> of the skeptic here, it will result in better designs.
>
>
> Cheers,
>
> Sean
>

Re: Spring and Roller

[Sean Gilligan <se...@msgilligan.com>]

Allen Gilliland wrote:
> On Mon, 2006-03-06 at 15:06, Sean Gilligan wrote:
>> Allen, I definitely recommend that you at least spend a couple of hours 
>> looking at Spring for distributed transactions and pluggable ORM layers 
>> before going ahead with your proposed refactoring of the transaction code.
> 
> I will certainly do that, but this may be the realm where I would be least likely to start using a framework like Spring.
In many ways, Spring is the "un-framework".  The developers try really 
hard to allow you to minimize or avoid altogether dependencies on the 
framework, as well as give you choices "a la carte" rather than 
force/push you to adopt everything.  Many commercial offerings (for 
obvious reasons) encourage you to depend on their product/API in as many 
ways as possible.  The same is true for many Open Source projects as 
well, as it is only human to want the product of your labor to solve as 
many problems as possible.  In the Spring Framework, I see a concerted 
effort and a philosophy of resisting this urge as much as possible.

>  My main concern is that we would move away from our own implementation of Hibernate and into a version of Spring Hibernate, doing Hibernate the way Spring suggests.
My (limited) understanding of how Spring works at this layer is that you 
can use Springs declarative transactions as method interceptors on top 
of just about any DAO layer or service object and that you don't have to 
use the Spring Hibernate Templates to do this.

In other words, *I think* you could use Spring Declarative Transactions 
without moving away from Roller's current implementation of Hibernate. 
I'm not sure that this will work, though.  My experience has been using 
the default Spring+Hibernate+Declarative-Transactions implementation. 
Anil, Matt, do you guys have any guidance here?

The key to using Spring Declarative Transactions is to wrap existing 
Dao/Manager/Service Objects with the "TransactionProxyFactoryBean", 
which implements the pre/post method-call magic to implement the 
transactions.  This means that whatever is using the Managers should be 
getting the implementation from BeanFactory, so this is one change that 
would be required in the Roller code.  A side benefit to this change is 
that the same mechanism used to install the proxies is the mechanism 
used to plug in other manager implementations.

Now the proxies need to have a TransactionManager injected and Spring 
provides a HibernateTransactionManager, which in turn requires (via 
D.I.) a Hibernate SessionFactory.  I don't know what would be involved 
in "sharing" a SessionFactory between the current Roller code and these 
Spring components.  Anil, Matt?

 >> If you really wanted to keep certain beans
>> restricted to a particular layer or module, that module could have a 
>> private BeanFactory that the other components are not aware of.  In 
>> other words they won't be able to get access to the "ctx" 
>> variable/reference.  (In my opinion, this shouldn't be necessary.)
> 
> Hmm.  That sounds promising to me.  I'd like to hear more about that.

I've never done this before,  but believe it should be possible.  Most 
Spring apps tend to use a single (Web)ApplicationContext (which is a 
subclass of BeanFactory) that is a single context (container).  Most 
apps break up the layers (Presentation, Service, Data) into separate 
configuration files, but objects from all layers are (theoretically) 
obtainable by any component that has a context reference.  (Although, as 
Anil says, using a context reference is to be avoided in favor of DI.)

So you should be able to allocate a private BeanFactory in the Business 
or Persistence layer that nothing else is aware of.  (By just choosing a 
constructor that points to a config file or resource and stuffing the 
context away somewhere.)

I'm willing to look into this further if that will help you.
> 
>>> This is the other big thing that I am concerned about with Spring in
>>> Roller.  I really don't want go back to making the config more
>>> complicated and spread out.
>> This is a valid concern and one that Spring doesn't automatically 
>> address.  And there is an inherent trade-off in making components more 
>> modular vs. keeping configuration simple and in one place.  Anil (and 
>> the team) should address these issues in any proposal(s).
> 
> I think at this point I am also just having a bit of fun giving you guys a hard time about your attempts to get Spring into Roller ;)

Hah!  The camel's nose is already in the tent, via Acegi!  Resistance is 
futile! ;)

Seriously, though, the Spring Framework (or un-framework) is modular and 
adopting it is not an all-or-nothing decision.  There are multiple ways 
that it could help (or hurt, if misused) Roller.  Each one should be 
carefully analyzed and discussed and the possible answers are "yes", 
"no", and "yes, but here's a better way...".  We should pay careful 
attention to issues of configuration and the trade-off between 
modularity and complexity.  It is important to distinguish between 
implementing (or refactoring) a module to use IOC/DI vs. implementing an 
interface vs. extending a class.  It's good that you're playing the role 
of the skeptic here, it will result in better designs.


Cheers,

Sean

Re: Spring and Roller

[Allen Gilliland <Al...@Sun.COM>]

On Mon, 2006-03-06 at 15:06, Sean Gilligan wrote:
> Allen Gilliland wrote:
> > My initial opinion is still "mixed bag", but I am definitely willing to
> > hear more about how you would want to integrate Spring.  I still haven't
> > really done much with Spring, but I do see some ways in which it could
> > be useful to Roller.
> Allen, I definitely recommend that you at least spend a couple of hours 
> looking at Spring for distributed transactions and pluggable ORM layers 
> before going ahead with your proposed refactoring of the transaction code.
> 
> I'm far from a guru on this subject, but am in alpha testing on an app 
> that using Spring+Hibernate, so I'm willing to answer any questions to 
> the best of my ability.

I will certainly do that, but this may be the realm where I would be least likely to start using a framework like Spring.  My main concern is that we would move away from our own implementation of Hibernate and into a version of Spring Hibernate, doing Hibernate the way Spring suggests.

This stems from a belief that frameworks are good at making things easier for people who don't want to dig into the details, but they aren't particularly as good when someone wants full control over what's happening.  This is very common in engineering of all sorts, the inverse relationship between simplicity or ease of use and control/performance.  Sure there is always middle ground, but in most cases you must give up control in order get simplicity and I'm not always convinced that is a trade off I want to make.

> 
> > 
> > One question I have is are there any controls on what beans someone can
> > access via Spring?  i.e. if I use appfuse as an example I noticed that
> > there is a bean defined for the Hibernate sessionFactory.  is there
> > anything that prevents someone in the presentation layer from trying
> > ctx.getBean("sessionFactory")?  that is one thing that I wasn't sure
> > about.
> 
> I think Anil has answered this question fairly well, but I believe there 
> is another option.  If you really wanted to keep certain beans 
> restricted to a particular layer or module, that module could have a 
> private BeanFactory that the other components are not aware of.  In 
> other words they won't be able to get access to the "ctx" 
> variable/reference.  (In my opinion, this shouldn't be necessary.)

Hmm.  That sounds promising to me.  I'd like to hear more about that.

> 
> > 
> > This is the other big thing that I am concerned about with Spring in
> > Roller.  I really don't want go back to making the config more
> > complicated and spread out.
> This is a valid concern and one that Spring doesn't automatically 
> address.  And there is an inherent trade-off in making components more 
> modular vs. keeping configuration simple and in one place.  Anil (and 
> the team) should address these issues in any proposal(s).

I think at this point I am also just having a bit of fun giving you guys a hard time about your attempts to get Spring into Roller ;)

-- Allen


> 
> -- Sean

Re: Spring and Roller

[Sean Gilligan <se...@msgilligan.com>]

Allen Gilliland wrote:
> My initial opinion is still "mixed bag", but I am definitely willing to
> hear more about how you would want to integrate Spring.  I still haven't
> really done much with Spring, but I do see some ways in which it could
> be useful to Roller.
Allen, I definitely recommend that you at least spend a couple of hours 
looking at Spring for distributed transactions and pluggable ORM layers 
before going ahead with your proposed refactoring of the transaction code.

I'm far from a guru on this subject, but am in alpha testing on an app 
that using Spring+Hibernate, so I'm willing to answer any questions to 
the best of my ability.

> 
> One question I have is are there any controls on what beans someone can
> access via Spring?  i.e. if I use appfuse as an example I noticed that
> there is a bean defined for the Hibernate sessionFactory.  is there
> anything that prevents someone in the presentation layer from trying
> ctx.getBean("sessionFactory")?  that is one thing that I wasn't sure
> about.

I think Anil has answered this question fairly well, but I believe there 
is another option.  If you really wanted to keep certain beans 
restricted to a particular layer or module, that module could have a 
private BeanFactory that the other components are not aware of.  In 
other words they won't be able to get access to the "ctx" 
variable/reference.  (In my opinion, this shouldn't be necessary.)

> 
> This is the other big thing that I am concerned about with Spring in
> Roller.  I really don't want go back to making the config more
> complicated and spread out.
This is a valid concern and one that Spring doesn't automatically 
address.  And there is an inherent trade-off in making components more 
modular vs. keeping configuration simple and in one place.  Anil (and 
the team) should address these issues in any proposal(s).

-- Sean

Re: Spring and Roller

[Allen Gilliland <Al...@Sun.COM>]

My initial opinion is still "mixed bag", but I am definitely willing to
hear more about how you would want to integrate Spring.  I still haven't
really done much with Spring, but I do see some ways in which it could
be useful to Roller.

On Sun, 2006-03-05 at 09:09, Anil Gangolli wrote:
> I've been using basic Spring dependency injection and initialization 
> (BeanFactory/ApplicationContext) functionality  in some projects at work 
> and have really been happy with how it encourages clean modularization 
> and helps me to get more pluggable reusable components while keeping 
> almost all of the code completely unaware of Spring itself.
> 
> I think using the dependency injection pattern would really help us 
> clean up interdependencies and make Roller more pluggable and 
> modifiable.  Before spending time on a real proposal, I wanted to gauge 
> interest in this.  Note that this is separable from any inclination to 
> use Spring MVC (as Sean G is trying) or other Spring features (like the 
> declarative transaction management that Matt R suggested).

My personal opinion is that we can do this without Spring using a little
bit more of our own code.  Of course it's nice to have the work already
done for us by Spring instead.

One question I have is are there any controls on what beans someone can
access via Spring?  i.e. if I use appfuse as an example I noticed that
there is a bean defined for the Hibernate sessionFactory.  is there
anything that prevents someone in the presentation layer from trying
ctx.getBean("sessionFactory")?  that is one thing that I wasn't sure
about.

The nice thing about using a normal Java based hierarchy for accessing
objects is that nobody can access objects that they aren't supposed to
know about.  Another example from appfuse would be the way that the app
separates out a "service" and "dao" layer, what prevents someone from
directly accessing a dao bean even though they aren't supposed to?

> 
> Taking this path would suggest that we use Spring's xml-based 
> configuration mechanisms instead of roller.properties.  It's possible 
> (as Matt has done for some of the Acegi-related properties) to support 
> configuration via roller.properties rather than requiring users to edit 
> the xml, but I think that the approach taken by Matt for the security 
> props (having code in RollerContext initialization read the roller props 
> and call appropriate bean setters)  would be onerous to extend to a 
> large number of properties.  What would probably work nicely (and be 
> easy) is to have most of the Spring configuration refer where necessary 
> (by property paths) to one bean representing the equivalent of 
> roller.properties and configured in one xml file (or even a properties 
> file if we initialize that one bean specially).

This is the other big thing that I am concerned about with Spring in
Roller.  I really don't want go back to making the config more
complicated and spread out.

I'd like to see more details about the implementation before making any
final decisions though.  It's probably not a big deal if the only use of
the Spring appliction context is to inject special overrides for classes
like RollerImpl, ManagerImpls, etc.  Since these classes really don't
need to be modified by normal users we can just leave it up to advanced
users to know how to open up the webapp and modify the Spring
Application context to make these customizations.

The roller.properties would still serve its primary purpose, which is to
make it easy for Roller admins to easily apply settings for the things
we expect people to want to change.

> 
> I think it could be entered gradually, but eventually would mean a lot 
> of minor-to-moderate restructuring to really utilize the pattern, 
> feeling kind-of Roller 3.0-ish.
> 
> Would there be sufficient support for seeing a proposal along these 
> lines?  I probably won't embark on such a proposal unless there's some 
> predisposition to move in this direction.

I would definitely like to see it.

-- Allen


> 
> --a.
> 
> 
> 
> 
> 
> 
>