On Tue, Jan 6, 2009 at 2:33 AM, Raif S. Naffah <[email protected]>wrote:
> beanA = some.fully.qualified.ClassA > > beanA.property1 = Hello World > > > > myBean = some.fully.qualified.Class > > myBean.propertyA = $beanA > > ...so something similar to PropertyUtilsBean in Apache Commons BeanUtils. > ' Exactly. We use PropertyUtils under the hood, but we have to do more than just what PU provides, for example, object references via '$' and some other minor things. > i was hoping for a document that describes the available/possible > properties > etc... of what can be configured more so than how it is configured. Just as with PropertyUtils or Spring, that would be any Class's JavaDoc. Any setter on any Class serves as the indicator of what can be injected. is it safe then to assume that the javadoc of the above class describes all > the possible options? No - the JavaDoc in JSecurityFilter is just an example bean configuration for filter chains and other things. You could essentially put any class instance declaration and configure its properties like any other bean. Anything that BeanUtils supports. > > It has been a desire of mine for a long time to maybe found another open > > source project, say, "OGDL" that specified an "Object Graph Definition > > Language" as a companion to OGNL. It would be the most concise way to > > configure any DI framework - Spring, Guice, whatever. > > ...[edited] > > no thanks :-) i'm more interested in configuration correctness than > mechanisms, and de-coupling the configuration from the other life-cycle > states of the objects/components. for me a schema based xml offers the > best > guarantees hence the question. Understood. At the moment, pretty much everyone who wants that kind of correctness, i.e. backing by an XML Schema definition, uses Spring or some other XML bean configuration mechanism. Currently the JSecurity team defers to those other more robust mechanisms instead of writing our own, since they're all incredibly powerful already - it sounds like quite a bit of work to provide what they do - bean injection, managing lifecycles, circular dependency detection, etc. My 'OGDL' idea was one for an alternate light-weight configuration mechanism for people who didn't want XML or schema correctness. If they want XML, there are a ton of frameworks out there that provide bean configuration via XML, including even, the JDK. In any event, the JSecurityFilter supports a 'configClassName' init-param. You can specify any fully-qualified class name implementation of the Configuration interface ( http://www.jsecurity.org/api/org/jsecurity/config/Configuration.html). The JSecurityFilter will use the default no-arg constructor of that class and then immediately acquire the SecurityManager instance. This allows you to configure the SecurityManager however you wish in case one of our default methods might not be suitable for you. But then, if you'd like to contribute an XML mechanism that works, please start another thread to discuss it. I'm not sure if that's a road we want to go down, but we're certainly open to your feedback and suggestions. Best regards, Les
