Problems with multiple <dwr:configuration/> entries

[krause ()]

I'm getting an "object is not an instance of declaring class" error from DWR... but not always:
This problem presents depending on the actual order in which the spring's xml file is listed in the web.xml file (using the contextConfigLocation param). If I put my springDwr.xml file at the very end, everything works ok. If I put it somewhere in between I'm getting the described error.

The exception is being thrown at ExecuteAjaxFilter class, which recieves as parameters an Object obj, and a Method method (among others).
I set a breakpoint in ExecuteAjaxFilter and found out the following:

When everything works ok, the debugger shows the following:

obj $Proxy63  (id=138)
        h JdkDynamicAopProxy  (id=165)

method Method  (id=147)
        clazz Class<T> ($Proxy63) (id=139)
        name "getClientDetails"
        returnType Class<T> (com.xxx.ClientDetails) (id=185)

But when the problem presents itself, I get the following:

obj $Proxy54  (id=105)
        h JdkDynamicAopProxy  (id=153)

method Method  (id=111)
        clazz Class<T> (mx.xxx.RetrieveAccountInfoImpl) (id=68)
        name "getClientDetails"
        returnType Class<T> (com.xxx.ClientDetails) (id=201)

As you can see (see bold text) the problem is that the class of the method object does not match the class of the actual object.  In the first case both classes are $Proxy, while in the second case the object is a $Proxy but the method points to mx.xxx.RetrieveAccountInfoImpl  (which is the proxied class).

I have tried to replicate this problem in a small sample so that I can attach it, but haven't been able to reproduce this in a small scale.

I don't understand why the position of the file in the web.xml file can affect this behaviour since Spring is supposed to load the complete context formed by all listed files, and once this is done it then processes the whole context resolving dependencies, creating proxies, injecting stuff, etc.  Why not put the file at the end and stop complaining?... well actually, that is what we are doing but gets a little more complex since we have multiple dwr files for the different modules of the system.

I would appreciate any pointers you can give regarding this issue.

NOTE: I changed the original subject text to a more appropriate one.

[XMaNIaC]

Let me guess...you're not implementing an interface?

On Thu, May 29, 2008 at 1:26 AM, krause <pablokrause@...> wrote:

I'm getting an "object is not an instance of declaring class" error from
DWR... but not always:
This problem presents depending on the actual order in which the spring's
xml file is listed in the web.xml file (using the contextConfigLocation
param). If I put my springDwr.xml file at the very end, everything works ok.
If I put it somewhere in between I'm getting the described error.

The exception is being thrown at ExecuteAjaxFilter class, which recieves as
parameters an Object obj, and a Method method (among others).
I set a breakpoint in ExecuteAjaxFilter and found out the following:

When everything works ok, the debugger shows the following:

obj     $Proxy63  (id=138)
       h       JdkDynamicAopProxy  (id=165)

method  Method  (id=147)
       clazz   Class<T> ($Proxy63) (id=139)
       name    "getClientDetails"
       returnType      Class<T> (com.xxx.ClientDetails) (id=185)

But when the problem presents itself, I get the following:

obj     $Proxy54  (id=105)
       h       JdkDynamicAopProxy  (id=153)

method  Method  (id=111)
       clazz   Class<T> (mx.xxx.RetrieveAccountInfoImpl) (id=68)
       name    "getClientDetails"
       returnType      Class<T> (com.xxx.ClientDetails) (id=201)

As you can see (see bold text) the problem is that the class of the method
object does not match the class of the actual object.  In the first case
both classes are $Proxy, while in the second case the object is a $Proxy but
the method points to mx.xxx.RetrieveAccountInfoImpl  (which is the proxied
class).

I have tried to replicate this problem in a small sample so that I can
attach it, but haven't been able to reproduce this in a small scale.

I don't understand why the position of the file in the web.xml file can
affect this behaviour since Spring is supposed to load the complete context
formed by all listed files, and once this is done it then processes the
whole context resolving dependencies, creating proxies, injecting stuff,
etc.  Why not put the file at the end and stop complaining?... well
actually, that is what we are doing but gets a little more complex since we
have multiple dwr files for the different modules of the system.

I would appreciate any pointers you can give regarding this issue.
--
View this message in context: http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17524227.html
Sent from the DWR - Users mailing list archive at Nabble.com.


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

[krause ()]

Yes I am implementing an interface (required for JDK proxies).
The class mx.xxx.RetrieveAccountInfoImpl implements the interface mx.xxx.RetrieveAccountInfo.
As you can see from the original post the problem ONLY presents itself depending on the position of where it is listed inside web.xml.

XMaNIaC wrote:

Let me guess...you're not implementing an interface?

On Thu, May 29, 2008 at 1:26 AM, krause  wrote:

>
> I'm getting an "object is not an instance of declaring class" error from
> DWR... but not always:
> This problem presents depending on the actual order in which the spring's
> xml file is listed in the web.xml file (using the contextConfigLocation
> param). If I put my springDwr.xml file at the very end, everything works
> ok.
> If I put it somewhere in between I'm getting the described error.
>
> The exception is being thrown at ExecuteAjaxFilter class, which recieves as
> parameters an Object obj, and a Method method (among others).
> I set a breakpoint in ExecuteAjaxFilter and found out the following:
>
> When everything works ok, the debugger shows the following:
>
> obj     $Proxy63  (id=138)
>        h       JdkDynamicAopProxy  (id=165)
>
> method  Method  (id=147)
>        clazz   Class<T> ($Proxy63) (id=139)
>        name    "getClientDetails"
>        returnType      Class<T> (com.xxx.ClientDetails) (id=185)
>
> But when the problem presents itself, I get the following:
>
> obj     $Proxy54  (id=105)
>        h       JdkDynamicAopProxy  (id=153)
>
> method  Method  (id=111)
>        clazz   Class<T> (mx.xxx.RetrieveAccountInfoImpl) (id=68)
>        name    "getClientDetails"
>        returnType      Class<T> (com.xxx.ClientDetails) (id=201)
>
> As you can see (see bold text) the problem is that the class of the method
> object does not match the class of the actual object.  In the first case
> both classes are $Proxy, while in the second case the object is a $Proxy
> but
> the method points to mx.xxx.RetrieveAccountInfoImpl  (which is the proxied
> class).
>
> I have tried to replicate this problem in a small sample so that I can
> attach it, but haven't been able to reproduce this in a small scale.
>
> I don't understand why the position of the file in the web.xml file can
> affect this behaviour since Spring is supposed to load the complete context
> formed by all listed files, and once this is done it then processes the
> whole context resolving dependencies, creating proxies, injecting stuff,
> etc.  Why not put the file at the end and stop complaining?... well
> actually, that is what we are doing but gets a little more complex since we
> have multiple dwr files for the different modules of the system.
>
> I would appreciate any pointers you can give regarding this issue.
> --
> View this message in context:
> http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17524227.html
> Sent from the DWR - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>

[XMaNIaC]

I've only seen that error when not implementing interfaces or not declaring the appropiate <aop:proxy> tags sorry

Regards

On Thu, May 29, 2008 at 5:42 PM, krause <pablokrause@...> wrote:

Yes I am implementing an interface (required for JDK proxies).
The class mx.xxx.RetrieveAccountInfoImpl implements the interface
mx.xxx.RetrieveAccountInfo.
As you can see from the original post the problem ONLY presents itself
depending on the position of where it is listed inside web.xml.

XMaNIaC wrote:
>
> Let me guess...you're not implementing an interface?
>

> On Thu, May 29, 2008 at 1:26 AM, krause  wrote:
>
>>
>> I'm getting an "object is not an instance of declaring class" error from
>> DWR... but not always:
>> This problem presents depending on the actual order in which the spring's
>> xml file is listed in the web.xml file (using the contextConfigLocation
>> param). If I put my springDwr.xml file at the very end, everything works
>> ok.
>> If I put it somewhere in between I'm getting the described error.
>>
>> The exception is being thrown at ExecuteAjaxFilter class, which recieves
>> as
>> parameters an Object obj, and a Method method (among others).
>> I set a breakpoint in ExecuteAjaxFilter and found out the following:
>>
>> When everything works ok, the debugger shows the following:
>>
>> obj     $Proxy63  (id=138)
>>        h       JdkDynamicAopProxy  (id=165)
>>
>> method  Method  (id=147)
>>        clazz   Class<T> ($Proxy63) (id=139)
>>        name    "getClientDetails"
>>        returnType      Class<T> (com.xxx.ClientDetails) (id=185)
>>
>> But when the problem presents itself, I get the following:
>>
>> obj     $Proxy54  (id=105)
>>        h       JdkDynamicAopProxy  (id=153)
>>
>> method  Method  (id=111)
>>        clazz   Class<T> (mx.xxx.RetrieveAccountInfoImpl) (id=68)
>>        name    "getClientDetails"
>>        returnType      Class<T> (com.xxx.ClientDetails) (id=201)
>>
>> As you can see (see bold text) the problem is that the class of the
>> method
>> object does not match the class of the actual object.  In the first case
>> both classes are $Proxy, while in the second case the object is a $Proxy
>> but
>> the method points to mx.xxx.RetrieveAccountInfoImpl  (which is the
>> proxied
>> class).
>>
>> I have tried to replicate this problem in a small sample so that I can
>> attach it, but haven't been able to reproduce this in a small scale.
>>
>> I don't understand why the position of the file in the web.xml file can
>> affect this behaviour since Spring is supposed to load the complete
>> context
>> formed by all listed files, and once this is done it then processes the
>> whole context resolving dependencies, creating proxies, injecting stuff,
>> etc.  Why not put the file at the end and stop complaining?... well
>> actually, that is what we are doing but gets a little more complex since
>> we
>> have multiple dwr files for the different modules of the system.
>>
>> I would appreciate any pointers you can give regarding this issue.
>> --
>> View this message in context:
>> http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17524227.html
>> Sent from the DWR - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>

--
View this message in context: http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17537457.html

Sent from the DWR - Users mailing list archive at Nabble.com.


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

[krause]

I finally figured out what the problem is, or rather when it manifest itself.
This happens when you have multiple <dwr:configuration/> tags, either in the same file or because you have multiple Spring configuration files which include dwr configuration.
Apparentrly, once the first dwr element is processed, all dwr elements get processed as well BEFORE Spring wraps the beans in the appropriate proxies, i.e. DWR gets a "naked" bean.

I finally managed to reproduce this error in a small scale, and am attaching the sample code project.
Please look at the web.xml file for different configuration options which causes the problem.
The first case is when you have multiple <dwr:configuration/> tags in the same file (singleContext.xml).
The second case is when you have multiple files, each having their own <dwr:configuration/> entries.

A quick fix is to put all dwr related stuff into a single <dwr:configuration> tag or to group all files containing dwr configuration together at the very end (this files should only contain dwr stuff).

I find this quite limiting, specially in big applications where they are split (e.g. into modules) whith their own set of Spring files.

Regards

DWRSpringIssue.zip

XMaNIaC wrote:

I've only seen that error when not implementing interfaces or not declaring
the appropiate <aop:proxy> tags sorry

Regards

On Thu, May 29, 2008 at 5:42 PM, krause <[e-mail]> wrote:

>
>
> Yes I am implementing an interface (required for JDK proxies).
> The class mx.xxx.RetrieveAccountInfoImpl implements the interface
> mx.xxx.RetrieveAccountInfo.
> As you can see from the original post the problem ONLY presents itself
> depending on the position of where it is listed inside web.xml.
>
>
> XMaNIaC wrote:
> >
> > Let me guess...you're not implementing an interface?
> >
> > On Thu, May 29, 2008 at 1:26 AM, krause  wrote:
> >
> >>
> >> I'm getting an "object is not an instance of declaring class" error from
> >> DWR... but not always:
> >> This problem presents depending on the actual order in which the
> spring's
> >> xml file is listed in the web.xml file (using the contextConfigLocation
> >> param). If I put my springDwr.xml file at the very end, everything works
> >> ok.
> >> If I put it somewhere in between I'm getting the described error.
> >>
> >> The exception is being thrown at ExecuteAjaxFilter class, which recieves
> >> as
> >> parameters an Object obj, and a Method method (among others).
> >> I set a breakpoint in ExecuteAjaxFilter and found out the following:
> >>
> >> When everything works ok, the debugger shows the following:
> >>
> >> obj     $Proxy63  (id=138)
> >>        h       JdkDynamicAopProxy  (id=165)
> >>
> >> method  Method  (id=147)
> >>        clazz   Class<T> ($Proxy63) (id=139)
> >>        name    "getClientDetails"
> >>        returnType      Class<T> (com.xxx.ClientDetails) (id=185)
> >>
> >> But when the problem presents itself, I get the following:
> >>
> >> obj     $Proxy54  (id=105)
> >>        h       JdkDynamicAopProxy  (id=153)
> >>
> >> method  Method  (id=111)
> >>        clazz   Class<T> (mx.xxx.RetrieveAccountInfoImpl) (id=68)
> >>        name    "getClientDetails"
> >>        returnType      Class<T> (com.xxx.ClientDetails) (id=201)
> >>
> >> As you can see (see bold text) the problem is that the class of the
> >> method
> >> object does not match the class of the actual object.  In the first case
> >> both classes are $Proxy, while in the second case the object is a $Proxy
> >> but
> >> the method points to mx.xxx.RetrieveAccountInfoImpl  (which is the
> >> proxied
> >> class).
> >>
> >> I have tried to replicate this problem in a small sample so that I can
> >> attach it, but haven't been able to reproduce this in a small scale.
> >>
> >> I don't understand why the position of the file in the web.xml file can
> >> affect this behaviour since Spring is supposed to load the complete
> >> context
> >> formed by all listed files, and once this is done it then processes the
> >> whole context resolving dependencies, creating proxies, injecting stuff,
> >> etc.  Why not put the file at the end and stop complaining?... well
> >> actually, that is what we are doing but gets a little more complex since
> >> we
> >> have multiple dwr files for the different modules of the system.
> >>
> >> I would appreciate any pointers you can give regarding this issue.
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17524227.html
> >> Sent from the DWR - Users mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [e-mail]
> >> For additional commands, e-mail: [e-mail]
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17537457.html
> Sent from the DWR - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>

[XMaNIaC]

Hi,

Currently you can have one <dwr:configuration> tag per Spring context. For example, one for a root application context and one per each web app. In addition, you can only have one <dwr:controller> tag per web application. This won't change in the near future. Remoted beans can be declared in different XML files though (and/or using annotations). Use the <dwr:remote> or the new <dwr:proxy-ref> tags to do it.

Regards,

On Tue, Jun 3, 2008 at 6:58 PM, krause <pablokrause@...> wrote:

I finally figured out what the problem is, or rather when it manifest itself.
This happens when you have multiple <dwr:configuration/> tags, either in the
same file or because you have multiple Spring configuration files which
include dwr configuration.
Apparentrly, once the first dwr element is processed, all dwr elements get
processed as well BEFORE Spring wraps the beans in the appropriate proxies,
i.e. DWR gets a "naked" bean.

I finally managed to reproduce this error in a small scale, and am attaching
the sample code project.
Please look at the web.xml file for different configuration options which
causes the problem.
The first case is when you have multiple <dwr:configuration/> tags in the
same file (singleContext.xml).
The second case is when you have multiple files, each having their own
<dwr:configuration/> entries.

A quick fix is to put all dwr related stuff into a single
<dwr:configuration> tag or to group all files containing dwr configuration
together at the very end (this files should only contain dwr stuff).

I find this quite limiting, specially in big applications where they are
split (e.g. into modules) whith their own set of Spring files.

Regards

http://www.nabble.com/file/p17628391/DWRSpringIssue.zip DWRSpringIssue.zip



XMaNIaC wrote:
>
> I've only seen that error when not implementing interfaces or not
> declaring
> the appropiate <aop:proxy> tags sorry
>
> Regards
>
> On Thu, May 29, 2008 at 5:42 PM, krause <pablokrause@...> wrote:
>
>>
>>
>> Yes I am implementing an interface (required for JDK proxies).
>> The class mx.xxx.RetrieveAccountInfoImpl implements the interface
>> mx.xxx.RetrieveAccountInfo.
>> As you can see from the original post the problem ONLY presents itself
>> depending on the position of where it is listed inside web.xml.
>>
>>
>> XMaNIaC wrote:
>> >
>> > Let me guess...you're not implementing an interface?
>> >
>> > On Thu, May 29, 2008 at 1:26 AM, krause  wrote:
>> >
>> >>
>> >> I'm getting an "object is not an instance of declaring class" error
>> from
>> >> DWR... but not always:
>> >> This problem presents depending on the actual order in which the
>> spring's
>> >> xml file is listed in the web.xml file (using the
>> contextConfigLocation
>> >> param). If I put my springDwr.xml file at the very end, everything
>> works
>> >> ok.
>> >> If I put it somewhere in between I'm getting the described error.
>> >>
>> >> The exception is being thrown at ExecuteAjaxFilter class, which
>> recieves
>> >> as
>> >> parameters an Object obj, and a Method method (among others).
>> >> I set a breakpoint in ExecuteAjaxFilter and found out the following:
>> >>
>> >> When everything works ok, the debugger shows the following:
>> >>
>> >> obj     $Proxy63  (id=138)
>> >>        h       JdkDynamicAopProxy  (id=165)
>> >>
>> >> method  Method  (id=147)
>> >>        clazz   Class<T> ($Proxy63) (id=139)
>> >>        name    "getClientDetails"
>> >>        returnType      Class<T> (com.xxx.ClientDetails) (id=185)
>> >>
>> >> But when the problem presents itself, I get the following:
>> >>
>> >> obj     $Proxy54  (id=105)
>> >>        h       JdkDynamicAopProxy  (id=153)
>> >>
>> >> method  Method  (id=111)
>> >>        clazz   Class<T> (mx.xxx.RetrieveAccountInfoImpl) (id=68)
>> >>        name    "getClientDetails"
>> >>        returnType      Class<T> (com.xxx.ClientDetails) (id=201)
>> >>
>> >> As you can see (see bold text) the problem is that the class of the
>> >> method
>> >> object does not match the class of the actual object.  In the first
>> case
>> >> both classes are $Proxy, while in the second case the object is a
>> $Proxy
>> >> but
>> >> the method points to mx.xxx.RetrieveAccountInfoImpl  (which is the
>> >> proxied
>> >> class).
>> >>
>> >> I have tried to replicate this problem in a small sample so that I can
>> >> attach it, but haven't been able to reproduce this in a small scale.
>> >>
>> >> I don't understand why the position of the file in the web.xml file
>> can
>> >> affect this behaviour since Spring is supposed to load the complete
>> >> context
>> >> formed by all listed files, and once this is done it then processes
>> the
>> >> whole context resolving dependencies, creating proxies, injecting
>> stuff,
>> >> etc.  Why not put the file at the end and stop complaining?... well
>> >> actually, that is what we are doing but gets a little more complex
>> since
>> >> we
>> >> have multiple dwr files for the different modules of the system.
>> >>
>> >> I would appreciate any pointers you can give regarding this issue.
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17524227.html
>> >> Sent from the DWR - Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@...
>> >> For additional commands, e-mail: users-help@...
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17537457.html
>> Sent from the DWR - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>

--
View this message in context: http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17628391.html
Sent from the DWR - Users mailing list archive at Nabble.com.


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

[krause]

For anyone interested in this subject, I opened JIRA issue DWR-259.

XMaNIaC wrote:

Hi,

Currently you can have one <dwr:configuration> tag per Spring context. For
example, one for a root application context and one per each web app. In
addition, you can only have one <dwr:controller> tag per web application.
This won't change in the near future. Remoted beans can be declared in
different XML files though (and/or using annotations). Use the <dwr:remote>
or the new <dwr:proxy-ref> tags to do it.

Regards,

On Tue, Jun 3, 2008 at 6:58 PM, krause <[e-mail]> wrote:

>
> I finally figured out what the problem is, or rather when it manifest
> itself.
> This happens when you have multiple <dwr:configuration/> tags, either in
> the
> same file or because you have multiple Spring configuration files which
> include dwr configuration.
> Apparentrly, once the first dwr element is processed, all dwr elements get
> processed as well BEFORE Spring wraps the beans in the appropriate proxies,
> i.e. DWR gets a "naked" bean.
>
> I finally managed to reproduce this error in a small scale, and am
> attaching
> the sample code project.
> Please look at the web.xml file for different configuration options which
> causes the problem.
> The first case is when you have multiple <dwr:configuration/> tags in the
> same file (singleContext.xml).
> The second case is when you have multiple files, each having their own
> <dwr:configuration/> entries.
>
> A quick fix is to put all dwr related stuff into a single
> <dwr:configuration> tag or to group all files containing dwr configuration
> together at the very end (this files should only contain dwr stuff).
>
> I find this quite limiting, specially in big applications where they are
> split (e.g. into modules) whith their own set of Spring files.
>
> Regards
>
> http://www.nabble.com/file/p17628391/DWRSpringIssue.zip DWRSpringIssue.zip
>
>
>
> XMaNIaC wrote:
> >
> > I've only seen that error when not implementing interfaces or not
> > declaring
> > the appropiate <aop:proxy> tags sorry
> >
> > Regards
> >
> > On Thu, May 29, 2008 at 5:42 PM, krause <[e-mail]> wrote:
> >
> >>
> >>
> >> Yes I am implementing an interface (required for JDK proxies).
> >> The class mx.xxx.RetrieveAccountInfoImpl implements the interface
> >> mx.xxx.RetrieveAccountInfo.
> >> As you can see from the original post the problem ONLY presents itself
> >> depending on the position of where it is listed inside web.xml.
> >>
> >>
> >> XMaNIaC wrote:
> >> >
> >> > Let me guess...you're not implementing an interface?
> >> >
> >> > On Thu, May 29, 2008 at 1:26 AM, krause  wrote:
> >> >
> >> >>
> >> >> I'm getting an "object is not an instance of declaring class" error
> >> from
> >> >> DWR... but not always:
> >> >> This problem presents depending on the actual order in which the
> >> spring's
> >> >> xml file is listed in the web.xml file (using the
> >> contextConfigLocation
> >> >> param). If I put my springDwr.xml file at the very end, everything
> >> works
> >> >> ok.
> >> >> If I put it somewhere in between I'm getting the described error.
> >> >>
> >> >> The exception is being thrown at ExecuteAjaxFilter class, which
> >> recieves
> >> >> as
> >> >> parameters an Object obj, and a Method method (among others).
> >> >> I set a breakpoint in ExecuteAjaxFilter and found out the following:
> >> >>
> >> >> When everything works ok, the debugger shows the following:
> >> >>
> >> >> obj     $Proxy63  (id=138)
> >> >>        h       JdkDynamicAopProxy  (id=165)
> >> >>
> >> >> method  Method  (id=147)
> >> >>        clazz   Class<T> ($Proxy63) (id=139)
> >> >>        name    "getClientDetails"
> >> >>        returnType      Class<T> (com.xxx.ClientDetails) (id=185)
> >> >>
> >> >> But when the problem presents itself, I get the following:
> >> >>
> >> >> obj     $Proxy54  (id=105)
> >> >>        h       JdkDynamicAopProxy  (id=153)
> >> >>
> >> >> method  Method  (id=111)
> >> >>        clazz   Class<T> (mx.xxx.RetrieveAccountInfoImpl) (id=68)
> >> >>        name    "getClientDetails"
> >> >>        returnType      Class<T> (com.xxx.ClientDetails) (id=201)
> >> >>
> >> >> As you can see (see bold text) the problem is that the class of the
> >> >> method
> >> >> object does not match the class of the actual object.  In the first
> >> case
> >> >> both classes are $Proxy, while in the second case the object is a
> >> $Proxy
> >> >> but
> >> >> the method points to mx.xxx.RetrieveAccountInfoImpl  (which is the
> >> >> proxied
> >> >> class).
> >> >>
> >> >> I have tried to replicate this problem in a small sample so that I
> can
> >> >> attach it, but haven't been able to reproduce this in a small scale.
> >> >>
> >> >> I don't understand why the position of the file in the web.xml file
> >> can
> >> >> affect this behaviour since Spring is supposed to load the complete
> >> >> context
> >> >> formed by all listed files, and once this is done it then processes
> >> the
> >> >> whole context resolving dependencies, creating proxies, injecting
> >> stuff,
> >> >> etc.  Why not put the file at the end and stop complaining?... well
> >> >> actually, that is what we are doing but gets a little more complex
> >> since
> >> >> we
> >> >> have multiple dwr files for the different modules of the system.
> >> >>
> >> >> I would appreciate any pointers you can give regarding this issue.
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17524227.html
> >> >> Sent from the DWR - Users mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [e-mail]
> >> >> For additional commands, e-mail: [e-mail]
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17537457.html
> >> Sent from the DWR - Users mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [e-mail]
> >> For additional commands, e-mail: [e-mail]
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17628391.html
> Sent from the DWR - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>

[krause]

I posted a proposed solution at JIRA issue DWR-259.



For anyone interested in this subject, I opened JIRA issue DWR-259.

XMaNIaC wrote:

Hi,

Currently you can have one <dwr:configuration> tag per Spring context. For
example, one for a root application context and one per each web app. In
addition, you can only have one <dwr:controller> tag per web application.
This won't change in the near future. Remoted beans can be declared in
different XML files though (and/or using annotations). Use the <dwr:remote>
or the new <dwr:proxy-ref> tags to do it.

Regards,

On Tue, Jun 3, 2008 at 6:58 PM, krause <[e-mail]> wrote:

>
> I finally figured out what the problem is, or rather when it manifest
> itself.
> This happens when you have multiple <dwr:configuration/> tags, either in
> the
> same file or because you have multiple Spring configuration files which
> include dwr configuration.
> Apparentrly, once the first dwr element is processed, all dwr elements get
> processed as well BEFORE Spring wraps the beans in the appropriate proxies,
> i.e. DWR gets a "naked" bean.
>
> I finally managed to reproduce this error in a small scale, and am
> attaching
> the sample code project.
> Please look at the web.xml file for different configuration options which
> causes the problem.
> The first case is when you have multiple <dwr:configuration/> tags in the
> same file (singleContext.xml).
> The second case is when you have multiple files, each having their own
> <dwr:configuration/> entries.
>
> A quick fix is to put all dwr related stuff into a single
> <dwr:configuration> tag or to group all files containing dwr configuration
> together at the very end (this files should only contain dwr stuff).
>
> I find this quite limiting, specially in big applications where they are
> split (e.g. into modules) whith their own set of Spring files.
>
> Regards
>
> http://www.nabble.com/file/p17628391/DWRSpringIssue.zip DWRSpringIssue.zip
>
>
>
> XMaNIaC wrote:
> >
> > I've only seen that error when not implementing interfaces or not
> > declaring
> > the appropiate <aop:proxy> tags sorry
> >
> > Regards
> >
> > On Thu, May 29, 2008 at 5:42 PM, krause <[e-mail]> wrote:
> >
> >>
> >>
> >> Yes I am implementing an interface (required for JDK proxies).
> >> The class mx.xxx.RetrieveAccountInfoImpl implements the interface
> >> mx.xxx.RetrieveAccountInfo.
> >> As you can see from the original post the problem ONLY presents itself
> >> depending on the position of where it is listed inside web.xml.
> >>
> >>
> >> XMaNIaC wrote:
> >> >
> >> > Let me guess...you're not implementing an interface?
> >> >
> >> > On Thu, May 29, 2008 at 1:26 AM, krause  wrote:
> >> >
> >> >>
> >> >> I'm getting an "object is not an instance of declaring class" error
> >> from
> >> >> DWR... but not always:
> >> >> This problem presents depending on the actual order in which the
> >> spring's
> >> >> xml file is listed in the web.xml file (using the
> >> contextConfigLocation
> >> >> param). If I put my springDwr.xml file at the very end, everything
> >> works
> >> >> ok.
> >> >> If I put it somewhere in between I'm getting the described error.
> >> >>
> >> >> The exception is being thrown at ExecuteAjaxFilter class, which
> >> recieves
> >> >> as
> >> >> parameters an Object obj, and a Method method (among others).
> >> >> I set a breakpoint in ExecuteAjaxFilter and found out the following:
> >> >>
> >> >> When everything works ok, the debugger shows the following:
> >> >>
> >> >> obj     $Proxy63  (id=138)
> >> >>        h       JdkDynamicAopProxy  (id=165)
> >> >>
> >> >> method  Method  (id=147)
> >> >>        clazz   Class<T> ($Proxy63) (id=139)
> >> >>        name    "getClientDetails"
> >> >>        returnType      Class<T> (com.xxx.ClientDetails) (id=185)
> >> >>
> >> >> But when the problem presents itself, I get the following:
> >> >>
> >> >> obj     $Proxy54  (id=105)
> >> >>        h       JdkDynamicAopProxy  (id=153)
> >> >>
> >> >> method  Method  (id=111)
> >> >>        clazz   Class<T> (mx.xxx.RetrieveAccountInfoImpl) (id=68)
> >> >>        name    "getClientDetails"
> >> >>        returnType      Class<T> (com.xxx.ClientDetails) (id=201)
> >> >>
> >> >> As you can see (see bold text) the problem is that the class of the
> >> >> method
> >> >> object does not match the class of the actual object.  In the first
> >> case
> >> >> both classes are $Proxy, while in the second case the object is a
> >> $Proxy
> >> >> but
> >> >> the method points to mx.xxx.RetrieveAccountInfoImpl  (which is the
> >> >> proxied
> >> >> class).
> >> >>
> >> >> I have tried to replicate this problem in a small sample so that I
> can
> >> >> attach it, but haven't been able to reproduce this in a small scale.
> >> >>
> >> >> I don't understand why the position of the file in the web.xml file
> >> can
> >> >> affect this behaviour since Spring is supposed to load the complete
> >> >> context
> >> >> formed by all listed files, and once this is done it then processes
> >> the
> >> >> whole context resolving dependencies, creating proxies, injecting
> >> stuff,
> >> >> etc.  Why not put the file at the end and stop complaining?... well
> >> >> actually, that is what we are doing but gets a little more complex
> >> since
> >> >> we
> >> >> have multiple dwr files for the different modules of the system.
> >> >>
> >> >> I would appreciate any pointers you can give regarding this issue.
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17524227.html
> >> >> Sent from the DWR - Users mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [e-mail]
> >> >> For additional commands, e-mail: [e-mail]
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17537457.html
> >> Sent from the DWR - Users mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [e-mail]
> >> For additional commands, e-mail: [e-mail]
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17628391.html
> Sent from the DWR - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>

[XMaNIaC]

I've tested the latest HEAD code with a dispatcher-servlet.xml that includes:

<dwr:configuration>
      <dwr:create javascript="Hello2" type="spring">
            <dwr:param name="beanName" value="helloRemoted2" />
            <dwr:include method="sayHello" />
      </dwr:create>
</dwr:configuration>

<dwr:configuration>
      <dwr:create javascript="Hello4" type="spring">
            <dwr:param name="beanName" value="h4" />
            <dwr:include method="sayHello" />
      </dwr:create>
</dwr:configuration>

<bean id="helloRemoted2" class="..." />

<bean id="hello4" class="..." abstract="true"/>

<bean id="hl4" abstract="true" parent="hello4" />

<bean id="h4" parent="hl4" lazy-init="true">

It was the most convoluted example I could think of. Everything worked fine. Can you confirm please?

Regards,

On Thu, Jun 5, 2008 at 2:21 AM, krause <pablokrause@...> wrote:

I posted a proposed solution at JIRA issue
http://getahead.org/bugs/browse/DWR-259 DWR-259 .

krause wrote:
>
>
> For anyone interested in this subject, I opened
> http://getahead.org/bugs/browse/DWR-259 JIRA issue DWR-259 .
>
>
> XMaNIaC wrote:
>>
>> Hi,
>>
>> Currently you can have one <dwr:configuration> tag per Spring context.
>> For
>> example, one for a root application context and one per each web app. In
>> addition, you can only have one <dwr:controller> tag per web application.
>> This won't change in the near future. Remoted beans can be declared in
>> different XML files though (and/or using annotations). Use the
>> <dwr:remote>
>> or the new <dwr:proxy-ref> tags to do it.
>>
>> Regards,
>>
>> On Tue, Jun 3, 2008 at 6:58 PM, krause <pablokrause@...> wrote:
>>
>>>
>>> I finally figured out what the problem is, or rather when it manifest
>>> itself.
>>> This happens when you have multiple <dwr:configuration/> tags, either in
>>> the
>>> same file or because you have multiple Spring configuration files which
>>> include dwr configuration.
>>> Apparentrly, once the first dwr element is processed, all dwr elements
>>> get
>>> processed as well BEFORE Spring wraps the beans in the appropriate
>>> proxies,
>>> i.e. DWR gets a "naked" bean.
>>>
>>> I finally managed to reproduce this error in a small scale, and am
>>> attaching
>>> the sample code project.
>>> Please look at the web.xml file for different configuration options
>>> which
>>> causes the problem.
>>> The first case is when you have multiple <dwr:configuration/> tags in
>>> the
>>> same file (singleContext.xml).
>>> The second case is when you have multiple files, each having their own
>>> <dwr:configuration/> entries.
>>>
>>> A quick fix is to put all dwr related stuff into a single
>>> <dwr:configuration> tag or to group all files containing dwr
>>> configuration
>>> together at the very end (this files should only contain dwr stuff).
>>>
>>> I find this quite limiting, specially in big applications where they are
>>> split (e.g. into modules) whith their own set of Spring files.
>>>
>>> Regards
>>>
>>> http://www.nabble.com/file/p17628391/DWRSpringIssue.zip
>>> DWRSpringIssue.zip
>>>
>>>
>>>
>>> XMaNIaC wrote:
>>> >
>>> > I've only seen that error when not implementing interfaces or not
>>> > declaring
>>> > the appropiate <aop:proxy> tags sorry
>>> >
>>> > Regards
>>> >
>>> > On Thu, May 29, 2008 at 5:42 PM, krause <pablokrause@...> wrote:
>>> >
>>> >>
>>> >>
>>> >> Yes I am implementing an interface (required for JDK proxies).
>>> >> The class mx.xxx.RetrieveAccountInfoImpl implements the interface
>>> >> mx.xxx.RetrieveAccountInfo.
>>> >> As you can see from the original post the problem ONLY presents
>>> itself
>>> >> depending on the position of where it is listed inside web.xml.
>>> >>
>>> >>
>>> >> XMaNIaC wrote:
>>> >> >
>>> >> > Let me guess...you're not implementing an interface?
>>> >> >
>>> >> > On Thu, May 29, 2008 at 1:26 AM, krause  wrote:
>>> >> >
>>> >> >>
>>> >> >> I'm getting an "object is not an instance of declaring class"
>>> error
>>> >> from
>>> >> >> DWR... but not always:
>>> >> >> This problem presents depending on the actual order in which the
>>> >> spring's
>>> >> >> xml file is listed in the web.xml file (using the
>>> >> contextConfigLocation
>>> >> >> param). If I put my springDwr.xml file at the very end, everything
>>> >> works
>>> >> >> ok.
>>> >> >> If I put it somewhere in between I'm getting the described error.
>>> >> >>
>>> >> >> The exception is being thrown at ExecuteAjaxFilter class, which
>>> >> recieves
>>> >> >> as
>>> >> >> parameters an Object obj, and a Method method (among others).
>>> >> >> I set a breakpoint in ExecuteAjaxFilter and found out the
>>> following:
>>> >> >>
>>> >> >> When everything works ok, the debugger shows the following:
>>> >> >>
>>> >> >> obj     $Proxy63  (id=138)
>>> >> >>        h       JdkDynamicAopProxy  (id=165)
>>> >> >>
>>> >> >> method  Method  (id=147)
>>> >> >>        clazz   Class<T> ($Proxy63) (id=139)
>>> >> >>        name    "getClientDetails"
>>> >> >>        returnType      Class<T> (com.xxx.ClientDetails) (id=185)
>>> >> >>
>>> >> >> But when the problem presents itself, I get the following:
>>> >> >>
>>> >> >> obj     $Proxy54  (id=105)
>>> >> >>        h       JdkDynamicAopProxy  (id=153)
>>> >> >>
>>> >> >> method  Method  (id=111)
>>> >> >>        clazz   Class<T> (mx.xxx.RetrieveAccountInfoImpl) (id=68)
>>> >> >>        name    "getClientDetails"
>>> >> >>        returnType      Class<T> (com.xxx.ClientDetails) (id=201)
>>> >> >>
>>> >> >> As you can see (see bold text) the problem is that the class of
>>> the
>>> >> >> method
>>> >> >> object does not match the class of the actual object.  In the
>>> first
>>> >> case
>>> >> >> both classes are $Proxy, while in the second case the object is a
>>> >> $Proxy
>>> >> >> but
>>> >> >> the method points to mx.xxx.RetrieveAccountInfoImpl  (which is the
>>> >> >> proxied
>>> >> >> class).
>>> >> >>
>>> >> >> I have tried to replicate this problem in a small sample so that I
>>> can
>>> >> >> attach it, but haven't been able to reproduce this in a small
>>> scale.
>>> >> >>
>>> >> >> I don't understand why the position of the file in the web.xml
>>> file
>>> >> can
>>> >> >> affect this behaviour since Spring is supposed to load the
>>> complete
>>> >> >> context
>>> >> >> formed by all listed files, and once this is done it then
>>> processes
>>> >> the
>>> >> >> whole context resolving dependencies, creating proxies, injecting
>>> >> stuff,
>>> >> >> etc.  Why not put the file at the end and stop complaining?...
>>> well
>>> >> >> actually, that is what we are doing but gets a little more complex
>>> >> since
>>> >> >> we
>>> >> >> have multiple dwr files for the different modules of the system.
>>> >> >>
>>> >> >> I would appreciate any pointers you can give regarding this issue.
>>> >> >> --
>>> >> >> View this message in context:
>>> >> >>
>>> >>
>>> http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17524227.html
>>> >> >> Sent from the DWR - Users mailing list archive at Nabble.com.
>>> >> >>
>>> >> >>
>>> >> >>
>>> ---------------------------------------------------------------------
>>> >> >> To unsubscribe, e-mail: users-unsubscribe@...
>>> >> >> For additional commands, e-mail: users-help@...
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >> --
>>> >> View this message in context:
>>> >>
>>> http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17537457.html
>>> >> Sent from the DWR - Users mailing list archive at Nabble.com.
>>> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: users-unsubscribe@...
>>> >> For additional commands, e-mail: users-help@...
>>> >>
>>> >>
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17628391.html
>>> Sent from the DWR - Users mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>>
>
>

--

View this message in context: http://www.nabble.com/Spring-%2B-dwr-file-order-%3D-object-is-not-instance-of-declared-type-%28sometimes%29-tp17524227p17659536.html

Sent from the DWR - Users mailing list archive at Nabble.com.


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