|
»
« Return to Thread: Spring - DWR little contribution
Re: Spring - DWR little contribution
by XMaNIaC
::
Rate this Message:
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,
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.It doesnt lead to problems, because Spring ALREADY does that. It scans
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.
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@...
« Return to Thread: Spring - DWR little contribution
| Free embeddable forum powered by Nabble | Forum Help |
