Re: Spring - DWR little contribution

Hi,

It seems I was quite a bit confused. Here's a polished version. I have removed the annotation and now it uses the usual @RemoteProxy. It scans the whole classpath looking for beans annotated with it and that belong to a package that contains dwr in the name. This can be configured easily.

The post-processor is still needed because we need a way to stop before beans are created and access to a bean registry.

Regards,

On Jan 22, 2008 9:10 PM, Jose Noheda < jose.noheda@...> wrote:

Hi,

The @Component is needed by Spring. Otherwise the scanner won't detect it as a bean. See @Controller or @Service as examples.

Thinking a little about the post-processor it may be redundant. In fact, the scanner is doing everything. Thank you for pointing out :-)

Currently we cannot use Spring's auto-discovery features. Well, we could but we would need a post-processor later to manage the creators (that's why the post-processor was added indeed). Unfortunately, the post-processor doesn't know what beans are annotated so it would need to process all of them to check it (*). This could lead to several "problems" (performance, jndi, factory beans...). That's why I decided to scan them and perform the operations right there. Actually, the good solution is to file a JIRA issue and ask Spring Source to provide a way to modify that definitions on-the-fly.

Regards,

(*) I don't know how the @Controller annotation is identified. May be something similar could be devised.

On Jan 22, 2008 7:14 PM, Hani Suleiman < hani@...> wrote:

Hi Jose,

Great start!

Just one thing (correct me if I'm wrong...) but why do you need to do
any scanning yourself in DwrServicePostProcessor? I think this isnt
the job of dwr (or any dwr extension) as its the role of the spring
container. So without it, people can list their beans explicitly in
xml and still use dwr annotations. Also, if you're using spring with
annotations chances are you're already using bean auto-discovery, so
the dwr post processor should just process the beans registered in
spring, rather than try to discover them.

I'd also suggest that DwrService take a name parameter (instead of
javascript) as that's a bit clearer, as well as removing the spring
specific @Component annotation from it.

On Jan 22, 2008, at 11:07 AM, Jose Noheda wrote:

> Hi,
>
> It seems a lot of people still have problems configuring DWR inside
> Spring. Looking for a way to improve it I tried to mix annotations
> with Spring. This is the result.
>
> The code needs to be polished a lot (consider it a proof-of-concept
> as always). Basically, you only have to define this beans in the XML:
>
> <dwr:configuration />
> <dwr:controller id="dwrController" />
> <bean class="org.directwebremoting.spring.DwrServicePostProcessor "
> p:basePackages="..." />
> <bean class=" org.directwebremoting.spring.DwrHandlerMapping" />
>
> And it will automatically remote any spring beans annotated with
> DwrService / RemoteMethod. I think it's a good start.
>
> Next steps involve:
>
> * Extending the schema. Something like <dwr:annotation-configured /
> >. I didn't want to mess with DWR code if at all possible. Adding it
> should be pretty straightforward.
> * Refactoring (it shares some code with DwrNamespaceHandler)
> * Add some convention with package names and bypass the basePackages
> property (I tried it but Package.getPackages() keep forgetting the
> WEB-INF/classes packages for some reason beyond my knowledge)
> * Getting a little help from SpringSource so we don't need to extend
> some classes. Good extension points in
> ClassPathBeanDefinitionScanner would save us lots of trouble
>
> Comments are welcomed!
>
> Regards,
> <

> RemotedBean
> .java
> >
> <
> DwrHandlerMapping
> .java
> >
> <
> DwrService
> .java
> ><DwrServicePostProcessor.java><DwrServiceScanner.java><dispatcher-
> servlet
> .xml
> >

> <
> web
> .xml
> >
> <
> index
> .jsp
> >---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...