I'm kind of glad we're having this discussion here - it's not really
off-topic since I'm still half-wanting to be convinced that I could
use Spring in this project :D
So, you're saying I don't *have* to wire classes together w/ XML in
Spring but I could use
GenericApplicationContext.registerBeanDefinition() programmatically
instead? What are the drawbacks (besides the obvious -
externalization.)
I looked into Spring 2.0 yesterday shortly...it looks like they've
done some work to be JPA (EJB 3 persistence) friendly...but I have to
admit I really wasn't crazy about what I was seeing there - just
"template" support for JPA.
On 6/15/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>
> On 6/15/06, John Patterson <[EMAIL PROTECTED]> wrote:
> >
> >
> > Igor, sorry to turn this into a Spring Q&A! I understand if you don't
> want to discuss Spring on this list but it is hard to get an unbiased
> opinion on theirs.
>
>
> i dont mind but maybe you should spin any future messages into a different
> thread.
>
> also it is not going to really work comparing pico and spring because spring
> is sooo much more then just ioc.
>
> >
> >
> >
> > I have only briefly looked at Springs IoC and was put off by the amount of
> configuration XML I would have to write. I use Picocontainer which is very
> simple to configure in Java alone because it makes lots of default
> assumptions about how to build an object without me having to specify.
>
>
> first of all let me say that spring's xml config drives java classes, at
> least from what i have seen and i havent looked very hard. so if you want to
> use spring without xml that should be doable. see
> GenericApplicationContext.registerBeanDefinition()
>
> spring can "autowire" dependencies just like pico, it would go something
> like this if you are using xml:
>
> <bean class="foo.Bar" autowire="byType"/> analogous to pico setter injection
>
> or
>
> <bean class="foo.Bar" autowire="constructor"/> analogous to pico constructor
> injection
>
> and there you have it. i dont know if semantics are exactly the same but
> they should be pretty close since there isnt that much playroom. something
> for you to experiment with.
>
>
> >
> >
> >
> >
> > Do you have any insight about how easily Spring can be configured in
> comparison to Pico? I could see that the examples were almost exclusively
> using setter injection but I much prefer to use constructors.
>
>
> yeah, it seems like setter injection is the preferred way in spring. i guess
> what setter injection gives you that constructor injection doesnt is the
> name of the setter itself, so it gives your config more context:
>
> <bean ...>
> <constructor-arg index="0" ref="dep0"/>
> <constructor-arg index="1" ref="dep1"/>
> </bean>
>
> this doesnt convey as much information as
>
> <bean ....>
> <property name="userManager" ref="dep0"/>
> <property name="securityManager" ref="dep1"/>
> </bean>
>
> and this is what the spring xml configuration is all about. one) it gives
> you a big overview of how the services are connected - there is a nice
> eclipse plugin that creates a cool graph from the xml file that gives you a
> birds eye of the infrastructure of your app - something not really possible
> to do when configuring in code, and two) the configuration is externalized -
> these things tend to be the things that would change from deployment to
> deployment so you really dont want them to be configured in code - ie
> swapping a HibernateUserDao for a LdapUserDao because one company wants you
> to hook in to their ldap dir, and this is where setter injection is also
> very useful ...
>
> <bean id="userdao" calss="com.foo.user.HibernateUserDao">
> <property name="sessionFactory" ref="hsf"/>
> </bean>
>
> vs
>
> <bean id="userdao" class=" com.foo.user.LdapUserDao">
> <property name="server" value="foo"/>
> <property name="username" value="user"/>
> <property name="password" value="pass"/>
> </bean>
>
> see, not only can you switch things out between deployments but you can also
> configure them. if you wanted this func then you would have to maintain your
> own property file that ldapdao would have to read, etc, etc. this way things
> are in a single place.
>
>
> >
> >
> >
> >
> >
> > Also, how easy is it to set up containers that manage object life-cycle at
> different scopes?
>
>
> i havent used this pattern in a long time and havent tried it with spring so
> i dont know. creating container from xml file is pretty simple, new
> FileSystemXmlApplicationContext(" file.xml") is all it
> takes
>
> but to summarize the whole thing:
>
> if you dont care about externalizing your config or having visibility into
> how things are wired and all you need is ioc then pico is def the way to go.
> its best of breed for lightweight ioc containers, and the factory interface
> makes it pretty darn easy to customize how beans are managed inside the
> container.
>
> if you do want externalizable config (the pico addon projects that provide
> this kinda suck imho) or you want a good base to build infrastructure for
> then spring is the way to go. it has a bunch of very well integrated modules
> that you might not need in the beginning of the project but you might need
> later like remoting, mail, jmx, jms, aop, event system for services, etc.
> these modules have saved me a ton of time on more then one occasion when i
> didnt think id need them but later - woops , and i can drop them in with
> just a few lines of xml. and having a global overview of how things are
> wired is also nice i think. i really hate xml, but if you use spring for a
> while you figure out shortcuts that save you from writing a lot of it. and
> in 2.0 they have different schemas for different modules which is pretty
> darn cool, it cuts down on xml and makes the xml itself more domain specific
> so its much more readable.
>
> pfew, this ended up longer then i wanted. i dont know how unbiased this is,
> i really like spring. on the other hand i have used both so there is
> something to be said for that. take it anyway you want :)
>
> -Igor
>
>
>
>
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>
>
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
