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.
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.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> >
>
>
