Re: [Figleaf-developer] Proxies back in and some thoughts on the Bootstrapper

[<sam...@ma...>]

Quoting Greg Steckman <ste...@on...>:

> sam...@ma... wrote:
> 
> >Right, the InfromativeFactoryImpl now creates proxies as requested.
> >  
> >
> We've got an Introspector, InformativeFactory, and ObjectIntrospector 
> interfaces. I think that's at least 1 too many. ObjectIntrospector has a 
> method "ClassDescriptor createInformative(Object o)" that doesn't seem 
> to be right. Shouldn't it return an Informative?
> 
> Is it necessary for the ObjectIntrospector interface to have methods 
> getDescription, getDisplayName, getProperties and getProperty? Those are 
> all things that the ClassDescriptor interface provides. I think not, so 
> it then is essentially the same as Introspector.

You're right - this happened due to me having proxies then removing them. I'll
look at simplifying this.

> >By way of a proof of concept, I've written a new ConfigurableBootstrapper
> based
> >on your original code. The only difference being that it now hands-off the
> >determination of which beans to use to a new ApplicationConfiguration class
> >(more specifically a SpringApplicationCnfiguration). The only other
> difference
> >is that rather than having the user specify which bean is runnable, I've
> assumed
> >a bean called Runnable - my aim here is for things to be simple. I also
> added a
> >TransientObjectManager which will hold objects in memory, although at
> present it
> >doesn't do anything. The SimpleApplicationContext I use looks like this:
<snip>


> I guess your main objective is to get ConfigurableBootstrapper to the 
> point to where it can use something other than 
> SpringApplicationConfiguration?

Yes - so the developer can decide to use a SpringConfiguration that lets them do
fancy Spring-stuff (they may want to seed the ApplicationContext with their own
factories etc) or they may want a dead simple Java-codes configuration to get
somethong running quickly (or for testing with).

> >Next, I've created a slightly different SwingViewer - my version takes all
> >dependencies via constructors (which I think is neater than using setters
> to
> >define dependencies). I've also defined internally a default view map as I
> think
> >it's OK for us to assume default views (e.g. text entry fields) and then
> allow
> >the developer to override it. I've also changed it so the list of
> registered
> >classes to be passed in. All of this is by way of a test to see how simple
> we
> >can make application setup - I'd appreciate your comments. My
> >ConfigurableSwingViewer isn't as functional as yours - I originally based
> the
> >code on yours but then realised I didn't need to reinvent the wheel, just
> show
> >how it could be invoked.
> >
> Setters somehow seemed more flexible when using dependency injection, 
> perhaps not.

I have a few concerns with using setter-based injection - primarily the fact
that you can end up creating a bean which cannot then be used without setters
being called (sometimes in a certain, special order). A case in point would be
the FormView, where if you call setViewObject before setSwingViewer, you get a
null pointer exception. By passing in all dependencies at construction not only
do you ensure the object starts in a valid, ready to use state, but you also
make sure that setters which should not be used at any other time other that
initialisation are not exposed - what happens for example if something calls
setSwingViewer after the FormView has already been displayed?

> Do you have in mind how to allow the developer to override the default 
> view types and to provide additional view types?

Definately. A case in point would be the Image manager app I'd like to code by
way of an acceptance test - in once object you have a String which represents a
filename, but I want the GUI to provide a file browser.

> Now to the classes. We have to think about this carefully. Currently a 
> class is represented by an InformativeDescriptor instance. It includes 
> information about the class (it's class name, a display name, and a 
> description) as well as methods that can be used to do things with that 
> class, such as get a new instance of it. Of course that can be done 
> other ways as long as you have the class name. But I wanted to 
> eventually be able to associate security information with the class, 
> such as restricting which users could create a new instance of the class 
> represented by a given instance of InformativeDescriptor, who can delete 
> an instance, etc. Additionally I wanted to be able create "context 
> groups" that are collections of InformativeDescriptors. So for instance 
> if there are classes A, B, C, and D, I can assign A and B to one context 
> group and C and D to a second context group. Then I can assign one user 
> so that on startup he sees the classes in the first context group but 
> not the second, and vice-versa for a second user. A user could be 
> allowed to see multiple context groups, for example an administrator or 
> other super user would have access to all context groups.

This all sounds sensible.

> I believe this kind of complex security and relational model of classes 
> is only possible if there is a first-class object representing the 
> class. My approach was to need only 1 class seeded in the database, and 
> that was an InformativeDescriptor that describes itself. With that you 
> can create objects for all other classes needed and setup their 
> security, assign them to context groups, etc.
> 
> I think the best approach is to write a "system initializer" program 
> that would take some config file or even user input and setup the system 
> the first time. This would include classes for which to create default 
> InformativeDescptors, a super-user account, etc. Long term I think this 
> is right way to do it because user passwords should be stored in the 
> database using a 1-way hash or some other scrambling method, not in 
> clear text, which means we need to write a program to get the first user 
> in the system so they can log in and create all the others.

Which I agree with, however I want to limit the amount of system initialization
needed. Systems which require passwords for the first user will typically ship
with a default one specified which has to be changed (MySql for example).

On the security front, I'm hoping to attend a lecture in the next week or two by
 Ivan Flechais who has done a lot of research on the AEGIS security system (for
which Spring support exists). I'll feedback anything of interest. 

sam
http://www.magpiebrain.com/