|
»
« Return to Thread: Spring - DWR little contribution
Re: Spring - DWR little contribution
by Hani Suleiman
::
Rate this Message:
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@...
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@...
« Return to Thread: Spring - DWR little contribution
| Free embeddable forum powered by Nabble | Forum Help |
