« Return to Thread: Spring - DWR little contribution

Re: Spring - DWR little contribution

by XMaNIaC :: Rate this Message:

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.
>
>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.

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,

« Return to Thread: Spring - DWR little contribution