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