|
Spring - DWR little contribution
|
|
Re: Spring - DWR little contribution
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@...
|
|
Re: Spring - DWR little contribution
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,
> <
> .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@...
|
|
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,
> <
> .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@...
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=" http://www.springframework.org/schema/beans"
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"
xmlns:p=" http://www.springframework.org/schema/p"
xmlns:dwr=" http://www.directwebremoting.org/schema/spring-dwr"
xmlns:context=" http://www.springframework.org/schema/context"
xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.directwebremoting.org/schema/spring-dwr http://www.directwebremoting.org/schema/spring-dwr-2.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd">
<!-- DWR -->
<dwr:controller id="dwrController" debug="true" />
<dwr:configuration />
<bean class="org.directwebremoting.spring.DwrServicePostProcessor" />
<bean class="org.directwebremoting.spring.DwrHandlerMapping" />
</beans> <?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance" xmlns=" http://java.sun.com/xml/ns/javaee" xmlns:web=" http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation=" http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">
<display-name>DWR-SpringAnnotationConfiguration</display-name>
<servlet>
<servlet-name>dispatcher</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>2</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>dispatcher</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>dispatcher</servlet-name>
<url-pattern>/dwr/*</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app> ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
|
|
Re: Spring - DWR little contribution
Hi, I've created a JIRA issue at http://jira.springframework.org/browse/SPR-4377. It would help to simplify our implementation a little. Regards,
2008/1/23 Jose Noheda < jose.noheda@...>:
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,
> <
> .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@...
|
|
Re: Spring - DWR little contribution
Hi Jose,
I'm still not convinced that scanning is a good idea ;)
Lets take another example, JPA annotations (think of these as
analogous to DWR annotations). You have some metadata on a bean that
you need to act on.
So the 'Spring' way (until 2.5) is to specify the beans you want in
spring.xml (or register them programmatically), and then to register a
post processor that goes through the beans looking for annotations and
decides what to do with them. Notice that there's no scanning
involved, Spring forced you to explicitly list all the beans that you
want processed.
In 2.5, the mechanism is actually exactly the same. The only
difference is that they have a new optional step up front, which does
scanning for you in a specific package, as far as the post processor
is concerned though everything is exactly the same; it goes through
all beans finding annotations and does something with them.
On Jan 22, 2008, at 7:26 PM, Jose Noheda wrote:
>
> 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.
It doesnt lead to problems, because Spring ALREADY does that. It scans
every bean (if you're using spring annotations, or even just the tx
annotations).
DWR annotations are NOT equivalent to @Service or @Controller, they're
completely orthogonal.
The idea is that I should be able to take any spring bean, and expose
it through dwr. Beans exposed this way often have multiple roles,
they're not exclusively dwr beans (like your code assumes) nor do they
live in a dwr specific package.
ALL that's needed in my opinion is a nicer format for @RemoteProxy, so
currently, we have to do this:
@RemoteProxy(creator = SpringCreator.class, creatorParams =
@Param(name = "beanName", value = "MyJSManager"), name = "MyManager")
Instead, we'd like to do this:
@RemoteService(name = "MyJSManager")
And in spring.xml, instead of specifying the AnnotationsConfigurator
bean, to specify some other version that detects the above Spring
friendly syntax (rather than the overgeneric RemoteProxy format).
Does this make sense to anyone, or am I completely misunderstanding
something?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
|
|
Re: Spring - DWR little contribution
Hi, We cannot use a BeanPostProcessor (which would save us a lot of trouble) because by that time DWR may be already configured (in the DWRController initialization code). We would have to hack the factory so DwrController is the LAST bean instantiated, that way we would be sure that all the other candidate beans have been proxied and registered in the Configurator by then. I mean we would need to automatically add a dependency (depends-on?) between DWRController and all the remoted beans (which, by the way, we don't know who they are). It seemed too complicated at the time.
Otherwise a BeanFactoryPostProcessor is the only option we have left. Unfortunately, this kind of post processor is not executed against a bean (what makes checking for an annotation trivial) but it receives the whole BeanFactory so you can modify the definitions in it. Now, you have to retrieve ALL BeanDefinitions (not beans yet!) and scan them (which means loading each class because at this point only the classname is available), checking for the annotation. That's why I said it could be quite expensive.
On the other hand the scanner will detect the candidate beans for us directly so we're processing just the ones we need. Once registered by the scanner there's no difference between this beans and any other Spring bean, they can just be used/injected/autowired/whatever.
I hope I was more clear this time :-) Regards, On Jan 23, 2008 3:37 PM, Hani Suleiman < hani@...> wrote:
Hi Jose,
I'm still not convinced that scanning is a good idea ;)
Lets take another example, JPA annotations (think of these as
analogous to DWR annotations). You have some metadata on a bean that
you need to act on.
So the 'Spring' way (until 2.5) is to specify the beans you want in
spring.xml (or register them programmatically), and then to register a
post processor that goes through the beans looking for annotations and
decides what to do with them. Notice that there's no scanning
involved, Spring forced you to explicitly list all the beans that you
want processed.
In 2.5, the mechanism is actually exactly the same. The only
difference is that they have a new optional step up front, which does
scanning for you in a specific package, as far as the post processor
is concerned though everything is exactly the same; it goes through
all beans finding annotations and does something with them.
On Jan 22, 2008, at 7:26 PM, Jose Noheda wrote:
>
> 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.
It doesnt lead to problems, because Spring ALREADY does that. It scans
every bean (if you're using spring annotations, or even just the tx
annotations).
DWR annotations are NOT equivalent to @Service or @Controller, they're
completely orthogonal.
The idea is that I should be able to take any spring bean, and expose
it through dwr. Beans exposed this way often have multiple roles,
they're not exclusively dwr beans (like your code assumes) nor do they
live in a dwr specific package.
ALL that's needed in my opinion is a nicer format for @RemoteProxy, so
currently, we have to do this:
@RemoteProxy(creator = SpringCreator.class, creatorParams =
@Param(name = "beanName", value = "MyJSManager"), name = "MyManager")
Instead, we'd like to do this:
@RemoteService(name = "MyJSManager")
And in spring.xml, instead of specifying the AnnotationsConfigurator
bean, to specify some other version that detects the above Spring
friendly syntax (rather than the overgeneric RemoteProxy format).
Does this make sense to anyone, or am I completely misunderstanding
something?
|
|
Re: Spring - DWR little contribution
Forgot to mention, from the @RemoteProxy annotation only the name is checked. The creator is always Spring and the parameters are not taken into account. So basically it mimics the behavior of your annotation (or the one I formerly proposed).
Regards, On Jan 23, 2008 3:37 PM, Hani Suleiman < hani@...> wrote:
Hi Jose,
I'm still not convinced that scanning is a good idea ;)
Lets take another example, JPA annotations (think of these as
analogous to DWR annotations). You have some metadata on a bean that
you need to act on.
So the 'Spring' way (until 2.5) is to specify the beans you want in
spring.xml (or register them programmatically), and then to register a
post processor that goes through the beans looking for annotations and
decides what to do with them. Notice that there's no scanning
involved, Spring forced you to explicitly list all the beans that you
want processed.
In 2.5, the mechanism is actually exactly the same. The only
difference is that they have a new optional step up front, which does
scanning for you in a specific package, as far as the post processor
is concerned though everything is exactly the same; it goes through
all beans finding annotations and does something with them.
On Jan 22, 2008, at 7:26 PM, Jose Noheda wrote:
>
> 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.
It doesnt lead to problems, because Spring ALREADY does that. It scans
every bean (if you're using spring annotations, or even just the tx
annotations).
DWR annotations are NOT equivalent to @Service or @Controller, they're
completely orthogonal.
The idea is that I should be able to take any spring bean, and expose
it through dwr. Beans exposed this way often have multiple roles,
they're not exclusively dwr beans (like your code assumes) nor do they
live in a dwr specific package.
ALL that's needed in my opinion is a nicer format for @RemoteProxy, so
currently, we have to do this:
@RemoteProxy(creator = SpringCreator.class, creatorParams =
@Param(name = "beanName", value = "MyJSManager"), name = "MyManager")
Instead, we'd like to do this:
@RemoteService(name = "MyJSManager")
And in spring.xml, instead of specifying the AnnotationsConfigurator
bean, to specify some other version that detects the above Spring
friendly syntax (rather than the overgeneric RemoteProxy format).
Does this make sense to anyone, or am I completely misunderstanding
something?
|
|
Re: Spring - DWR little contribution
On Jan 23, 2008, at 10:01 AM, Jose Noheda wrote:
> Hi,
>
> We cannot use a BeanPostProcessor (which would save us a lot of
> trouble) because by that time DWR may be already configured (in the
> DWRController initialization code). We would have to hack the
> factory so DwrController is the LAST bean instantiated, that way we
> would be sure that all the other candidate beans have been proxied
> and registered in the Configurator by then. I mean we would need to
> automatically add a dependency (depends-on?) between DWRController
> and all the remoted beans (which, by the way, we don't know who they
> are). It seemed too complicated at the time.
>
Right, this seems to me to be a problem in dwr, and there should be
some refactoring there to enable you to add beans to the controller
after its been initialized, rather than it expecting everything to be
ready for it up front.
> Otherwise a BeanFactoryPostProcessor is the only option we have
> left. Unfortunately, this kind of post processor is not executed
> against a bean (what makes checking for an annotation trivial) but
> it receives the whole BeanFactory so you can modify the definitions
> in it. Now, you have to retrieve ALL BeanDefinitions (not beans
> yet!) and scan them (which means loading each class because at this
> point only the classname is available), checking for the annotation.
> That's why I said it could be quite expensive.
>
Yes, but you're already taking that hit if you have *any* annotation
scanning! If you're the kind of person who wants to use dwr
annotations, you're probably also using jpa, spring annotations, etc.
You're not scared of using them ;)
> On the other hand the scanner will detect the candidate beans for us
> directly so we're processing just the ones we need. Once registered
> by the scanner there's no difference between this beans and any
> other Spring bean, they can just be used/injected/autowired/whatever.
>
Well, maybe if I explain my use case, you can let me know if your
solution will work...
I have a bunch of random spring beans using various annotations, some
of these are also exposed as dwr proxies. I have my own scanner than
scans for @Stateless annotation (using asm) that I feed into spring.
So in my case, I take care of the scanning myself and dont want anyone
else to do it, but I do want to be able to use a 'nicer' form of dwr
annotation than the currently annoying @RemoteProxy/SpringCreator stuff.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
|
|
Re: Spring - DWR little contribution
On Jan 23, 2008 4:15 PM, Hani Suleiman < hani@...> wrote:
On Jan 23, 2008, at 10:01 AM, Jose Noheda wrote:
> Hi,
>
> We cannot use a BeanPostProcessor (which would save us a lot of
> trouble) because by that time DWR may be already configured (in the
> DWRController initialization code). We would have to hack the
> factory so DwrController is the LAST bean instantiated, that way we
> would be sure that all the other candidate beans have been proxied
> and registered in the Configurator by then. I mean we would need to
> automatically add a dependency (depends-on?) between DWRController
> and all the remoted beans (which, by the way, we don't know who they
> are). It seemed too complicated at the time.
>
>some refactoring there to enable you to add beans to the controller
>after its been initialized, rather than it expecting everything to be
>ready for it up front. A hot deploy context..
> Otherwise a BeanFactoryPostProcessor is the only option we have
> left. Unfortunately, this kind of post processor is not executed
> against a bean (what makes checking for an annotation trivial) but
> it receives the whole BeanFactory so you can modify the definitions
> in it. Now, you have to retrieve ALL BeanDefinitions (not beans
> yet!) and scan them (which means loading each class because at this
> point only the classname is available), checking for the annotation.
> That's why I said it could be quite expensive.
>
>Yes, but you're already taking that hit if you have *any* annotation
>scanning! If you're the kind of person who wants to use dwr
>annotations, you're probably also using jpa, spring annotations, etc.
>You're not scared of using them ;)
Yes, probably you're taking the hit anyway. The scanner just saved trouble doing the work.
> On the other hand the scanner will detect the candidate beans for us
> directly so we're processing just the ones we need. Once registered
> by the scanner there's no difference between this beans and any
> other Spring bean, they can just be used/injected/autowired/whatever.
>
>Well, maybe if I explain my use case, you can let me know if your
>solution will work...
>I have a bunch of random spring beans using various annotations, some
>of these are also exposed as dwr proxies. I have my own scanner than
>scans for @Stateless annotation (using asm) that I feed into spring.
>So in my case, I take care of the scanning myself and dont want anyone
>else to do it, but I do want to be able to use a 'nicer' form of dwr
>annotation than the currently annoying @RemoteProxy/SpringCreator stuff.
In theory, the scanner when trying to register a BeanDefinition it checks before for compatible definitions (same class, same name) already registered. We have three scenarios here: * The bean is not compatible (same name, different class): This throws an exception.
* Another bean is created (same class, different name): This happens, for example, if both annotations give different names to the bean * The bean is compatible: It won't be registered but the process would continue so the Creator proxy can be registered as well
I'm not sure the first case should ever happen. It can only happen (given that we're scanning annotated classes and not XML) if ASM is changing the class on the fly (!?). The second is or is not (it may be desired behavior) an error of the configuration (blame the user). The third is just something to test in depth but I'm pretty sure we can handle it as of now. Anyway, all of them are pretty corner cases IMO. For the other 99% I think we have a working solution.
Now, I don't see a problem creating another BeanFactoryPostProcessor (or even the same) that checks all the BeanDefinitions in the registry. This can work side-by-side with the scanner or independently. It would be a matter of configuration.
Regards,
|
|
Re: Spring - DWR little contribution
Just a quick update, the Spring team will fix it for version 2.5.2 or so it seems On Jan 23, 2008 1:27 PM, Jose Noheda < jose.noheda@...> wrote:
Hi,
I've created a JIRA issue at
http://jira.springframework.org/browse/SPR-4377. It would help to simplify our implementation a little.
Regards,
2008/1/23 Jose Noheda < jose.noheda@...>:
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,
> <
> .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@...
|
RemotedBean.java (688 bytes) Download Attachment
