Re: [Springframework-rcp-dev] First commit

[Peter De B. <pet...@gm...>]

Jim,

great that you're looking into that area! I'll check it out first thing next
week.

regards,

Peter

On Fri, Jul 11, 2008 at 1:18 PM, Jim Moore <moo...@gm...> wrote:

> "However, I still believe that you'll be doing a lot of XML bean definition
> (i.e. if you want two beans with different names of the same class, you
> can't
> do that with component scanning I think...)"
>
> You can give your classes any a single name you want from an
> @Component-related annotation, but not multiple.  But there's only two
> reasons you'd want to have multiple names:
>
> 1) You need multiple instances with the same configuration, in which case
> what you really need is a different scope (such as "prototype") and there's
> no need to have multiple names since the scoping differentiates the multiple
> instances.
>
> 2) You need multiple instances with different configurations, in which case
> there's no choice but to externalize the configuration anyway.  This latter
> case is almost always for "infrastructure" kinds of objects (datasources and
> the like) as opposed to the higher-level business objects that make up the
> majority of what developers write (eg, views, commands, etc).
>
> I'm currently in the process of prototyping some code for doing essentially
> what we've been talking about using ADI (Annotation Driven Injection).  If
> you want to take a look, it's in the "adi-based-views" branch.  The test
> cases (esp. DefaultApplicationWindowTests and
> DesktopAnnotationScopeMetadataResolverTests) show how it works.  (Sorry
> there's not much Javadoc right now; I'm prototyping. Hopefully the tests
> make the pieces clear, if not how everything fits together.)  I'm going to
> put together a sample app to show it in a more "complete" way.  But first I
> want to implement @Command to provide the same kind of cool sweetness of
> on-demand POJOness that @Controller gives web developers...
>
> -Jim Moore
>
>
>
> On Wed, Jul 9, 2008 at 5:20 AM, Lieven Doclo <lie...@ji...>
> wrote:
>
>> Peter,
>>
>> I've solved the problem by not using the custom ApplicationContext, but
>> just
>> the standard Spring one. I've committed the code if you want to take a
>> look.
>>
>> However, I still believe that you'll be doing a lot of XML bean definition
>> (i.e. if you want two beans with different names of the same class, you
>> can't
>> do that with component scanning I think...) and you still need to provide
>> sensible defaults (which can be hard for the beginning user to find out
>> when
>> using classpath scanning, i.e. in what package are the defaults...).
>>
>> wkg,
>>
>> Lieven
>>
>> > Hello Peter,
>> >
>> > I've just checked the code and when you're using autowiring and
>> > component scanning, a problem occurs: The ApplicationContext
>> > implementation is responsible for creating an Application, whereas I
>> > would let the container do this (annotate your Application and let the
>> > component scan handle the instantiation). However, since the
>> > ApplicationContext constructs the Spring container, one cannot inject
>> > the scanned Application into the ApplicationContext.
>> >
>> > Hence the services are injected correctly (with my annotated
>> > Application), but the ApplicationContext holds his own created
>> > Application...
>> >
>> > Can't see a solution atm...
>> >
>> > Greetz,
>> >
>> > Lieven
>>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>