On 3/5/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
> On Sun, 2006-03-05 at 15:59, Matt Raible wrote:
> > On 3/5/06, Allen Gilliland <[EMAIL PROTECTED]> 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.
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
>
>
