|
Hi, all: I got a super class that defines methods with generic parameters (along with some DWR annotation), i.e: --------------------------------------- and a subclass that only inherit the above class: --------------------------------------- and of course: --------------------------------------- in dwr.xml, I have the following: --------------------------------------- When I deploy that to my WAR and try to run the code, exception was thrown: --------------------------------------- So I checked the dwr test page, only to find the following: --------------------------------------- It seems DWR does not recognize my generic parameter in SubClass which should be actually com.mypackage.domain.MyDomainObject,
--------------------------------------- @Override Code works, but I still got "(Warning: overloaded methods are not recommended. See below) " in the test page (Yes, this is a reasonable warning).
which does not work.
FYI: I use DWR 2.0.5 and JDK1.5 Any ideas/comments are appreciated.
|
|
DWR needs to be able to create T from a JavaScript object. Finding out
what T is, is not exactly straightforward. DWR has a feature to make this easier. See "Mapping Java classes to JavaScript classes" here: http://directwebremoting.org/dwr/server/dwrxml/converters/bean.html Let us know if it helps you out. You will need to specify a converter for each bean: <convert converter="bean" match="com.mypackage.domain.Bean1" javascript="bean1"/> etc. Hubert Yang wrote: > > Hi, all: > > I got a super class that defines methods with generic parameters > (along with some DWR annotation), i.e: > > --------------------------------------- > @RemoteProxy(creator = GuiceCreator.class) > public class BaseClass <T> ( > @RemoteMethod > public add(T domainObj){ > //... > } > } > --------------------------------------- > > and a subclass that only inherit the above class: > > --------------------------------------- > @RemoteProxy(creator = GuiceCreator.class) > public class SubClass extends BaseClass<MyDomainObject> { } > --------------------------------------- > > and of course: > > --------------------------------------- > @DataTransferObject > public class MyDomainObject implements java.io.Serializable { > @RemoteProperty > private String property; > > //... > } > --------------------------------------- > > in dwr.xml, I have the following: > > --------------------------------------- > <dwr> > <allow> > <convert converter="bean" match="com.mypackage.domain.*"/> > </allow> > </dwr> > --------------------------------------- > > When I deploy that to my WAR and try to run the code, exception was > thrown: > > --------------------------------------- > java.lang.IllegalArgumentException: "Missing method or missing > parameter converters" > --------------------------------------- > > So I checked the dwr test page, only to find the following: > > --------------------------------------- > (Warning: No Converter for java.lang.Object. See below) > --------------------------------------- > > It seems DWR does not recognize my generic parameter in SubClass which > should be actually com.mypackage.domain.MyDomainObject, > but use java.lang.Object instead. > > > So I tried another way: > > --------------------------------------- > @RemoteProxy(creator = GuiceCreator.class) > public class SubClass extends BaseClass<MyDomainObject> { > > @Override > @RemoteMethod > public void add(MyDomainObject obj) { > super.add(obj); > } > --------------------------------------- > > Code works, but I still got "(Warning: overloaded methods are not > recommended. See below) " in the test page (Yes, this is a reasonable > warning). > > > And also trying to add the following to dwr.xml: > --------------------------------------- > <signatures> > <![CDATA[ > import com.mypackage.domain.MyDomainObject; > import com.mypackage.SubClass; > SubClass.add(MyDomainObject obj); > ]]> > </signatures> > --------------------------------------- > > which does not work. > > > Is there a workaround for this so that DWR could recognize this kind > of generic paramter without re-define a method with new name in > SubClass (I really saved a lot of code by using generic types) > > FYI: I use DWR 2.0.5 and JDK1.5 > > Any ideas/comments are appreciated. > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4439 (20090918) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
Thanks for the reply, David
I added the following line in dwr.xml:
<convert converter="bean" match="java.lang.Object" javascript="MyObject" />
<convert converter="bean" match="com.mypackage.domain.MyDomainObject" javascript="MyDomainObj"/>
however, when I try to create a new javascript object:
var record = new MyDomainObj();
in firebug I was told: MyDomainObj is not defined.
Do I need to include some extra js files in html header? I only find the definition of "MyObject" in ${webroot}/dwr/interface/SubClass.js
The page you give use the following example which is not the case for me here (I need to create a new MyDomainObj from scratch):
var p = ... // get an Employee from the server
On the other hand, In dwr test page, the "no converter warning for java.lang.Object" is gone, and the tooltip of add() method says "Will be converted to: java.lang.Object"
This is pretty weird to me since DWR still cound not regonize the correct type of T here.
On Sat, Sep 19, 2009 at 11:20 AM, David Marginian <[hidden email]> wrote: DWR needs to be able to create T from a JavaScript object. Finding out what T is, is not exactly straightforward. DWR has a feature to make this easier. See "Mapping Java classes to JavaScript classes" here: |
|
The first line does not make sense. Check the JS generated by DWR and look for MyDomainObj in there
Regards
On Sat, Sep 19, 2009 at 6:51 AM, Hubert Yang <hubert.yang.cn@gmail.com> wrote:
|
|
Hey Jose:
This does NOT help things out.
My problem is how to define the MyDomainObject so that it could be regonized by DWR.
No matter the first line is included or not, the javascript error "MyDomainObj" is always there. That is the key problem.
On Sat, Sep 19, 2009 at 8:56 PM, Jose Noheda <[hidden email]> wrote: The first line does not make sense. Check the JS generated by DWR and look for MyDomainObj in there |
|
Hubert,
You have a lot going on here. When trying to fix problems it is always best to simplify things - which you have not done. Why are you mixing annotations with dwr.xml configuration? You also have creators (RemoteProxys) defined for both the subclass and the superclass. I have never done this before but I would think you would only need a RemoteProxy for the subclass. I believe the MyDomainObject will be defined in the DWR generated interface file (I would assume this would be the JavaScript interface generated for SubClass). The test page should help you out in seeing the generated JavaScript. If this doesn't help I would suggest simplifying by configuring (for now) with just the dwr.xml - get that working and then move on and make things more complex. Hubert Yang wrote: > Hey Jose: > > This does NOT help things out. > My problem is how to define the MyDomainObject so that it could be > regonized by DWR. > > No matter the first line is included or not, the javascript error > "MyDomainObj" is always there. That is the key problem. > > On Sat, Sep 19, 2009 at 8:56 PM, Jose Noheda <[hidden email] > <mailto:[hidden email]>> wrote: > > The first line does not make sense. Check the JS generated by DWR > and look for MyDomainObj in there > > Regards > > > On Sat, Sep 19, 2009 at 6:51 AM, Hubert Yang <hubert.yang.cn > <http://hubert.yang.cn/>@gmail.com <http://gmail.com/>> wrote: > > Thanks for the reply, David > > I added the following line in dwr.xml: > > <convert converter="bean" > match="java.lang.Object" javascript="MyObject" /> > <convert converter="bean" > match="com.mypackage.domain.MyDomainObject" > javascript="MyDomainObj"/> > > however, when I try to create a new javascript object: > > var record = new MyDomainObj(); > > in firebug I was told: MyDomainObj is not defined. > > Do I need to include some extra js files in html header? I > only find the definition of "MyObject" in > ${webroot}/dwr/interface/SubClass.js > > The page you give use the following example which is not the > case for me here (I need to create a new MyDomainObj from > scratch): > > var p = ... // get an Employee from the server > > On the other hand, In dwr test page, the "no converter warning > for java.lang.Object" is gone, and the tooltip of add() > method says "Will be converted to: java.lang.Object" > > This is pretty weird to me since DWR still cound not regonize > the correct type of T here. > > > > > On Sat, Sep 19, 2009 at 11:20 AM, David Marginian > <[hidden email] <mailto:[hidden email]>> wrote: > > DWR needs to be able to create T from a JavaScript object. > Finding out what T is, is not exactly straightforward. > DWR has a feature to make this easier. See "Mapping Java > classes to JavaScript classes" here: > http://directwebremoting.org/dwr/server/dwrxml/converters/bean.html > > Let us know if it helps you out. You will need to specify > a converter for each bean: > <convert converter="bean" > match="com.mypackage.domain.Bean1" javascript="bean1"/> > etc. > > > > Hubert Yang wrote: > > > Hi, all: > > I got a super class that defines methods with generic > parameters (along with some DWR annotation), i.e: > > --------------------------------------- > @RemoteProxy(creator = GuiceCreator.class) > public class BaseClass <T> ( > @RemoteMethod > public add(T domainObj){ > //... > } > } > --------------------------------------- > > and a subclass that only inherit the above class: > > --------------------------------------- > @RemoteProxy(creator = GuiceCreator.class) > public class SubClass extends > BaseClass<MyDomainObject> { } > --------------------------------------- > > and of course: > > --------------------------------------- > @DataTransferObject > public class MyDomainObject implements > java.io.Serializable { > @RemoteProperty > private String property; > //... > } > --------------------------------------- > > in dwr.xml, I have the following: > > --------------------------------------- > <dwr> > <allow> > <convert converter="bean" > match="com.mypackage.domain.*"/> > </allow> > </dwr> > --------------------------------------- > > When I deploy that to my WAR and try to run the code, > exception was thrown: > > --------------------------------------- > java.lang.IllegalArgumentException: "Missing method or > missing parameter converters" > --------------------------------------- > > So I checked the dwr test page, only to find the > following: > > --------------------------------------- > (Warning: No Converter for java.lang.Object. See below) > --------------------------------------- > > It seems DWR does not recognize my generic parameter > in SubClass which should be actually > com.mypackage.domain.MyDomainObject, > but use java.lang.Object instead. > > > So I tried another way: > > --------------------------------------- > @RemoteProxy(creator = GuiceCreator.class) > public class SubClass extends BaseClass<MyDomainObject> { > > @Override > @RemoteMethod > public void add(MyDomainObject obj) { > super.add(obj); > } > --------------------------------------- > > Code works, but I still got "(Warning: overloaded > methods are not recommended. See below) " in the test > page (Yes, this is a reasonable warning). > > > And also trying to add the following to dwr.xml: > --------------------------------------- > <signatures> > <![CDATA[ > import com.mypackage.domain.MyDomainObject; > import com.mypackage.SubClass; > SubClass.add(MyDomainObject obj); > ]]> > </signatures> > --------------------------------------- > > which does not work. > > > Is there a workaround for this so that DWR could > recognize this kind of generic paramter without > re-define a method with new name in SubClass (I really > saved a lot of code by using generic types) > > FYI: I use DWR 2.0.5 and JDK1.5 > > Any ideas/comments are appreciated. > > > > > > > __________ Information from ESET NOD32 Antivirus, version > of virus signature database 4439 (20090918) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com <http://www.eset.com/> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > <mailto:[hidden email]> > For additional commands, e-mail: > [hidden email] > <mailto:[hidden email]> > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4440 (20090919) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
Apologies if my explanation confuses you
Actually I use annotation to reduce the size of xml configuration file and also for better refactor support.
I use guice injection in my own business logic, so if I do not use guice in combination with DWR, my backend code will probably not work via DWR ajax.
Yes you are right, superclass does not need the @RemoteProxy here, I have removed it. thanks for reminding.
Anyway, I will use some mockup service without any guice dependency and use only dwr.xml to check if things are working.
Thanks for the kind hint, I will let you know the result.
On Sat, Sep 19, 2009 at 11:16 PM, David Marginian <[hidden email]> wrote: Hubert, |
|
Hubert,
I understand why you are using the annotations. I just don't know why you are mixing them with the dwr.xml - seems to me you could eliminate dwr.xml completely. I think your problem is arising from mixing the two: You have the following annotation specified: @DataTransferObject public class MyDomainObject implements The @DataTransferObject declares a DWR converter. But then you also have the same converter specified in your dwr.xml: <convert converter="bean" match="com.mypackage.domain.MyDomainObject" javascript="MyDomainObj"/> My guess is that the annotation converter is being used which is why the MyDomainObj JavaScript class is not being created. I think this illustrates why I said - one or the other. -David Hubert Yang wrote: > Apologies if my explanation confuses you > > Actually I use annotation to reduce the size of xml configuration file > and also for better refactor support. > I use guice injection in my own business logic, so if I do not use > guice in combination with DWR, my backend code will probably not work > via DWR ajax. > > Yes you are right, superclass does not need the @RemoteProxy here, I > have removed it. thanks for reminding. > > Anyway, I will use some mockup service without any guice dependency > and use only dwr.xml to check if things are working. > > Thanks for the kind hint, I will let you know the result. > > On Sat, Sep 19, 2009 at 11:16 PM, David Marginian <[hidden email] > <mailto:[hidden email]>> wrote: > > Hubert, > You have a lot going on here. When trying to fix problems it is > always best to simplify things - which you have not done. Why are > you mixing annotations with dwr.xml configuration? You also have > creators (RemoteProxys) defined for both the subclass and the > superclass. I have never done this before but I would think you > would only need a RemoteProxy for the subclass. I believe the > MyDomainObject will be defined in the DWR generated interface file > (I would assume this would be the JavaScript interface generated > for SubClass). The test page should help you out in seeing the > generated JavaScript. If this doesn't help I would suggest > simplifying by configuring (for now) with just the dwr.xml - get > that working and then move on and make things more complex. > > > Hubert Yang wrote: > > Hey Jose: > This does NOT help things out. > My problem is how to define the MyDomainObject so that it > could be regonized by DWR. > No matter the first line is included or not, the javascript > error "MyDomainObj" is always there. That is the key problem. > > On Sat, Sep 19, 2009 at 8:56 PM, Jose Noheda > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> > wrote: > > The first line does not make sense. Check the JS generated > by DWR > and look for MyDomainObj in there > > Regards > > > On Sat, Sep 19, 2009 at 6:51 AM, Hubert Yang > <hubert.yang.cn <http://hubert.yang.cn/> > <http://hubert.yang.cn/>@gmail.com <http://gmail.com/> > <http://gmail.com/>> wrote: > > Thanks for the reply, David > I added the following line in dwr.xml: > <convert converter="bean" > match="java.lang.Object" javascript="MyObject" /> > <convert converter="bean" > match="com.mypackage.domain.MyDomainObject" > javascript="MyDomainObj"/> > however, when I try to create a new javascript > object: > var record = new MyDomainObj(); > in firebug I was told: MyDomainObj is not defined. > Do I need to include some extra js files in > html header? I > only find the definition of "MyObject" in > ${webroot}/dwr/interface/SubClass.js > The page you give use the following example > which is not the > case for me here (I need to create a new MyDomainObj from > scratch): > var p = ... // get an Employee from the server > On the other hand, In dwr test page, the "no > converter warning > for java.lang.Object" is gone, and the tooltip of add() > method says "Will be converted to: java.lang.Object" > This is pretty weird to me since DWR still > cound not regonize > the correct type of T here. > > > On Sat, Sep 19, 2009 at 11:20 AM, David Marginian > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> wrote: > > DWR needs to be able to create T from a JavaScript > object. > Finding out what T is, is not exactly straightforward. > DWR has a feature to make this easier. See > "Mapping Java > classes to JavaScript classes" here: > > http://directwebremoting.org/dwr/server/dwrxml/converters/bean.html > > Let us know if it helps you out. You will need to > specify > a converter for each bean: > <convert converter="bean" > match="com.mypackage.domain.Bean1" javascript="bean1"/> > etc. > > > > Hubert Yang wrote: > > > Hi, all: > > I got a super class that defines methods with > generic > parameters (along with some DWR annotation), i.e: > > --------------------------------------- > @RemoteProxy(creator = GuiceCreator.class) > public class BaseClass <T> ( > @RemoteMethod > public add(T domainObj){ > //... > } > } > --------------------------------------- > > and a subclass that only inherit the above class: > > --------------------------------------- > @RemoteProxy(creator = GuiceCreator.class) > public class SubClass extends > BaseClass<MyDomainObject> { } > --------------------------------------- > > and of course: > > --------------------------------------- > @DataTransferObject > public class MyDomainObject implements > java.io.Serializable { > @RemoteProperty > private String property; > //... > } > --------------------------------------- > > in dwr.xml, I have the following: > > --------------------------------------- > <dwr> > <allow> > <convert converter="bean" > match="com.mypackage.domain.*"/> > </allow> > </dwr> > --------------------------------------- > > When I deploy that to my WAR and try to run the > code, > exception was thrown: > > --------------------------------------- > java.lang.IllegalArgumentException: "Missing > method or > missing parameter converters" > --------------------------------------- > > So I checked the dwr test page, only to find the > following: > > --------------------------------------- > (Warning: No Converter for java.lang.Object. > See below) > --------------------------------------- > > It seems DWR does not recognize my generic > parameter > in SubClass which should be actually > com.mypackage.domain.MyDomainObject, > but use java.lang.Object instead. > > > So I tried another way: > > --------------------------------------- > @RemoteProxy(creator = GuiceCreator.class) > public class SubClass extends > BaseClass<MyDomainObject> { > > @Override > @RemoteMethod > public void add(MyDomainObject obj) { > super.add(obj); > } > --------------------------------------- > > Code works, but I still got "(Warning: overloaded > methods are not recommended. See below) " in > the test > page (Yes, this is a reasonable warning). > > > And also trying to add the following to dwr.xml: > --------------------------------------- > <signatures> > <![CDATA[ > import com.mypackage.domain.MyDomainObject; > import com.mypackage.SubClass; > SubClass.add(MyDomainObject obj); > ]]> > </signatures> > --------------------------------------- > > which does not work. > > > Is there a workaround for this so that DWR could > recognize this kind of generic paramter without > re-define a method with new name in SubClass (I > really > saved a lot of code by using generic types) > > FYI: I use DWR 2.0.5 and JDK1.5 > > Any ideas/comments are appreciated. > > > > > > __________ Information from ESET NOD32 Antivirus, > version > of virus signature database 4439 (20090918) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com <http://www.eset.com/> > <http://www.eset.com/> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > For additional commands, e-mail: > [hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4440 (20090919) __________ > > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com <http://www.eset.com/> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > <mailto:[hidden email]> > For additional commands, e-mail: [hidden email] > <mailto:[hidden email]> > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4440 (20090919) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
Originally I only have the following in my dwr.xml:
<dwr>
<allow> <convert match="java.lang.Exception" converter="exception"> </allow> </dwr>
in order to have a better understanding of the exception message in js exception handler (Yes, I know this could be done via annotation, I will remove the dwr.xml completely)
the following line was added when I read the document you give:
<convert converter="bean" match="com.mypackage.domain.MyDomainObject" javascript="MyDomainObj" />
because I can not figure out how to add the "javascript" property in annoation.
By default, the converter for @DataTransfterObject is exactly the bean converter, so I don't think this will cause inconsistency
I am now trying to testing without annotation.
On Sat, Sep 19, 2009 at 11:53 PM, David Marginian <[hidden email]> wrote: Hubert, |
|
David:
Now I use only the traditional way of DWR, with the following xml and without any annotation:
-------------------------------------
<dwr>
<allow> <create creator="new" javascript="SubClass"> <param name="class" value="com.mypackage.SubClass" /> </create> <convert match="java.lang.Exception" converter="exception" /> <convert match="com.mypackage.domain.MyDomainObject" converter="bean" javascript="MyDomainObj" /> </allow> </dwr> -------------------------------------
Now I was able to find the definition of MyDomainObj function in SubClass.js, but in the test/debug page, the parameter for add is still java.lang.Object, not com.mypackage.domain.MyDomainObject
when I create a new MyDomainObj js object and sent it to server via dwr, exception is thrown:
-------------------------------------
java.lang.IllegalArgumentException: Missing method or missing parameter converters
-------------------------------------
I think it is conplaining that no converter could be found for java.lang.Object
So the problem goes back to the title again: DWR does not recognize generic type parameter (with inheritance)
I may upload my project tomorrow if this is necessary, since it's already over midnight here.
thank you and have a nice day, see you tomorrow.
On Sun, Sep 20, 2009 at 12:11 AM, Hubert Yang <hubert.yang.cn@gmail.com> wrote:
|
|
In reply to this post by david@butterdev.com
On Sat, Sep 19, 2009 at 5:53 PM, David Marginian <[hidden email]> wrote: Hubert, Remove the xml config and use @DTO(javascript = "whatever") Regards The @DataTransferObject declares a DWR converter. But then you also have the same converter specified in your dwr.xml: |
|
In reply to this post by Hubert Yang
David:
I have attached a simple web application that demostrate my problem, you can import into Eclipse and run index.jsp
Maven is required to download the library dependency (alternatively you can put dwr-2.0.5.jar&commons-logging-1.1.1.jar in MyWebApp\src\main\webapp\WEB-INF\lib folder).
Please let me know if my problem could be re-produced. Thanks
On Sun, Sep 20, 2009 at 12:43 AM, Hubert Yang <hubert.yang.cn@gmail.com> wrote:
--------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
Since the mail list does not support attachment, I upload to:
Please download it from there.
On Sun, Sep 20, 2009 at 3:22 PM, Hubert Yang <hubert.yang.cn@gmail.com> wrote:
|
|
I think this may be the same issue as this http://bugs.directwebremoting.org/bugs/browse/DWR-125. From memory, when you use reflection on a generic class there may be two copies of each method... one is marked as volitile. This is probably why dwr is complaining about overloading methods.
I think that a slight change is required to DWR to choose the non-volatile method in these cases. 2009/9/20 Hubert Yang <hubert.yang.cn@gmail.com>
|
|
I am not sure but from looking at this code I wouldn't expect this to
work. Can someone else (Jose, Lande) take a look at this? Lance Java wrote: > I think this may be the same issue as this > http://bugs.directwebremoting.org/bugs/browse/DWR-125. From memory, > when you use reflection on a generic class there may be two copies of > each method... one is marked as volitile. This is probably why dwr is > complaining about overloading methods. > > I think that a slight change is required to DWR to choose the > non-volatile method in these cases. > > 2009/9/20 Hubert Yang <hubert.yang.cn > <http://hubert.yang.cn>@gmail.com <http://gmail.com>> > > Since the mail list does not support attachment, I upload to: > > http://cube316.net/dwr/MyWebApp.zip > > Please download it from there. > > On Sun, Sep 20, 2009 at 3:22 PM, Hubert Yang <hubert.yang.cn > <http://hubert.yang.cn>@gmail.com <http://gmail.com>> wrote: > > David: > > I have attached a simple web application that demostrate my > problem, you can import into Eclipse and run index.jsp > > Maven is required to download the library dependency > (alternatively you can put > dwr-2.0.5.jar&commons-logging-1.1.1.jar in > MyWebApp\src\main\webapp\WEB-INF\lib folder). > > Please let me know if my problem could be re-produced. > > Thanks > > On Sun, Sep 20, 2009 at 12:43 AM, Hubert Yang <hubert.yang.cn > <http://hubert.yang.cn/>@gmail.com <http://gmail.com/>> wrote: > > David: > > Now I use only the traditional way of DWR, with the > following xml and without any annotation: > > ------------------------------------- > <dwr> > <allow> > <create creator="new" javascript="SubClass"> > <param name="class" value="com.mypackage.SubClass" /> > </create> > > <convert match="java.lang.Exception" > converter="exception" /> > <convert match="com.mypackage.domain.MyDomainObject" > converter="bean" javascript="MyDomainObj" /> > </allow> > </dwr> > ------------------------------------- > > Now I was able to find the definition of MyDomainObj > function in SubClass.js, but in the test/debug page, the > parameter for add is still java.lang.Object, not > com.mypackage.domain.MyDomainObject > > when I create a new MyDomainObj js object and sent it to > server via dwr, exception is thrown: > > ------------------------------------- > java.lang.IllegalArgumentException: Missing method or > missing parameter converters > ------------------------------------- > > I think it is conplaining that no converter could be found > for java.lang.Object > > So the problem goes back to the title again: DWR does not > recognize generic type parameter (with inheritance) > > I may upload my project tomorrow if this is necessary, > since it's already over midnight here. > > thank you and have a nice day, see you tomorrow. > On Sun, Sep 20, 2009 at 12:11 AM, Hubert Yang > <hubert.yang.cn <http://hubert.yang.cn/>@gmail.com > <http://gmail.com/>> wrote: > > Originally I only have the following in my dwr.xml: > > <dwr> > <allow> > <convert match="java.lang.Exception" > converter="exception"> > </allow> > </dwr> > > in order to have a better understanding of the > exception message in js exception handler (Yes, I know > this could be done via annotation, I will remove the > dwr.xml completely) > > the following line was added when I read the document > you give: > > <convert converter="bean" > match="com.mypackage.domain.MyDomainObject" javascript="MyDomainObj" > /> > > because I can not figure out how to add the > "javascript" property in annoation. > > By default, the converter for @DataTransfterObject is > exactly the bean converter, so I don't think this will > cause inconsistency > > I am now trying to testing without annotation. > > On Sat, Sep 19, 2009 at 11:53 PM, David Marginian > <[hidden email] <mailto:[hidden email]>> wrote: > > Hubert, > I understand why you are using the annotations. > I just don't know why you are mixing them with > the dwr.xml - seems to me you could eliminate > dwr.xml completely. I think your problem is > arising from mixing the two: > > You have the following annotation specified: > > @DataTransferObject > public class MyDomainObject implements > > The @DataTransferObject declares a DWR converter. > But then you also have the same converter > specified in your dwr.xml: > <convert converter="bean" > > match="com.mypackage.domain.MyDomainObject" > javascript="MyDomainObj"/> > > My guess is that the annotation converter is being > used which is why the MyDomainObj JavaScript class > is not being created. I think this illustrates > why I said - one or the other. > -David > > Hubert Yang wrote: > > Apologies if my explanation confuses you > Actually I use annotation to reduce the size > of xml configuration file and also for better > refactor support. > I use guice injection in my own business > logic, so if I do not use guice in combination > with DWR, my backend code will probably not > work via DWR ajax. > Yes you are right, superclass does not need > the @RemoteProxy here, I have removed it. > thanks for reminding. > Anyway, I will use some mockup service > without any guice dependency and use only > dwr.xml to check if things are working. > Thanks for the kind hint, I will let you know > the result. > > On Sat, Sep 19, 2009 at 11:16 PM, David > Marginian <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> wrote: > > Hubert, > You have a lot going on here. When trying > to fix problems it is > always best to simplify things - which you > have not done. Why are > you mixing annotations with dwr.xml > configuration? You also have > creators (RemoteProxys) defined for both > the subclass and the > superclass. I have never done this before > but I would think you > would only need a RemoteProxy for the > subclass. I believe the > MyDomainObject will be defined in the DWR > generated interface file > (I would assume this would be the > JavaScript interface generated > for SubClass). The test page should help > you out in seeing the > generated JavaScript. If this doesn't help > I would suggest > simplifying by configuring (for now) with > just the dwr.xml - get > that working and then move on and make > things more complex. > > > Hubert Yang wrote: > > Hey Jose: > This does NOT help things out. > My problem is how to define the > MyDomainObject so that it > could be regonized by DWR. > No matter the first line is included > or not, the javascript > error "MyDomainObj" is always there. > That is the key problem. > > On Sat, Sep 19, 2009 at 8:56 PM, Jose > Noheda > <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>> > > wrote: > > The first line does not make sense. > Check the JS generated > by DWR > and look for MyDomainObj in there > > Regards > > > On Sat, Sep 19, 2009 at 6:51 AM, > Hubert Yang > <hubert.yang.cn > <http://hubert.yang.cn/> <http://hubert.yang.cn/> > <http://hubert.yang.cn/>@gmail.com > <http://gmail.com/> <http://gmail.com/> > <http://gmail.com/>> wrote: > > Thanks for the reply, David > I added the following > line in dwr.xml: > <convert converter="bean" > match="java.lang.Object" > javascript="MyObject" /> > <convert converter="bean" > > match="com.mypackage.domain.MyDomainObject" > javascript="MyDomainObj"/> > however, when I try to > create a new javascript > object: > var record = new > MyDomainObj(); > in firebug I was told: > MyDomainObj is not defined. > Do I need to include > some extra js files in > html header? I > only find the definition of > "MyObject" in > ${webroot}/dwr/interface/SubClass.js > The page you give use > the following example > which is not the > case for me here (I need to > create a new MyDomainObj from > scratch): > var p = ... // get an > Employee from the server > On the other hand, In > dwr test page, the "no > converter warning > for java.lang.Object" is gone, > and the tooltip of add() > method says "Will be converted > to: java.lang.Object" > This is pretty weird to > me since DWR still > cound not regonize > the correct type of T here. > > On Sat, Sep 19, 2009 at > 11:20 AM, David Marginian > <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>> wrote: > > DWR needs to be able to > create T from a JavaScript > object. > Finding out what T is, is > not exactly straightforward. > DWR has a feature to make > this easier. See > "Mapping Java > classes to JavaScript > classes" here: > > http://directwebremoting.org/dwr/server/dwrxml/converters/bean.html > > Let us know if it helps you > out. You will need to > specify > a converter for each bean: > <convert converter="bean" > > match="com.mypackage.domain.Bean1" > javascript="bean1"/> > etc. > > > > Hubert Yang wrote: > > > Hi, all: > > I got a super class that > defines methods with > generic > parameters (along with > some DWR annotation), i.e: > > > --------------------------------------- > @RemoteProxy(creator = > GuiceCreator.class) > public class BaseClass <T> ( > @RemoteMethod > public add(T domainObj){ > //... > } > } > > --------------------------------------- > > and a subclass that only > inherit the above class: > > > --------------------------------------- > @RemoteProxy(creator = > GuiceCreator.class) > public class SubClass > extends > > BaseClass<MyDomainObject> { } > > --------------------------------------- > > and of course: > > > --------------------------------------- > @DataTransferObject > public class > MyDomainObject implements > java.io.Serializable { > @RemoteProperty > private String property; > //... > } > > --------------------------------------- > > in dwr.xml, I have the > following: > > > --------------------------------------- > <dwr> > <allow> > <convert converter="bean" > > match="com.mypackage.domain.*"/> > </allow> > </dwr> > > --------------------------------------- > > When I deploy that to my > WAR and try to run the > code, > exception was thrown: > > > --------------------------------------- > > java.lang.IllegalArgumentException: "Missing > method or > missing parameter > converters" > > --------------------------------------- > > So I checked the dwr > test page, only to find the > following: > > > --------------------------------------- > (Warning: No Converter > for java.lang.Object. > See below) > > --------------------------------------- > > It seems DWR does not > recognize my generic > parameter > in SubClass which should > be actually > > com.mypackage.domain.MyDomainObject, > but use java.lang.Object > instead. > > > So I tried another way: > > > --------------------------------------- > @RemoteProxy(creator = > GuiceCreator.class) > public class SubClass > extends > BaseClass<MyDomainObject> { > > @Override > @RemoteMethod > public void > add(MyDomainObject obj) { > super.add(obj); > } > > --------------------------------------- > > Code works, but I still > got "(Warning: overloaded > methods are not > recommended. See below) " in > the test > page (Yes, this is a > reasonable warning). > > > And also trying to add > the following to dwr.xml: > > --------------------------------------- > <signatures> > <![CDATA[ > import > com.mypackage.domain.MyDomainObject; > import > com.mypackage.SubClass; > > SubClass.add(MyDomainObject obj); > ]]> > </signatures> > > --------------------------------------- > > which does not work. > > > Is there a workaround > for this so that DWR could > recognize this kind of > generic paramter without > re-define a method with > new name in SubClass (I > really > saved a lot of code by > using generic types) > > FYI: I use DWR 2.0.5 and > JDK1.5 > > Any ideas/comments are > appreciated. > > > > > __________ Information from > ESET NOD32 Antivirus, > version > of virus signature database > 4439 (20090918) __________ > > The message was checked by > ESET NOD32 Antivirus. > > http://www.eset.com > <http://www.eset.com/> <http://www.eset.com/> > <http://www.eset.com/> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [hidden email] > <mailto:[hidden email]> > > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > > <mailto:[hidden email] > <mailto:[hidden email]>>> > > For additional commands, e-mail: > [hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> > > > > > > > > __________ Information from ESET NOD32 > Antivirus, version of virus > signature database 4440 (20090919) __________ > > > The message was checked by ESET NOD32 > Antivirus. > > http://www.eset.com <http://www.eset.com/> > <http://www.eset.com/> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > For additional commands, e-mail: > [hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > > > > > __________ Information from ESET NOD32 Antivirus, > version of virus signature database 4440 > (20090919) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com <http://www.eset.com/> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [hidden email] > <mailto:[hidden email]> > For additional commands, e-mail: > [hidden email] > <mailto:[hidden email]> > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4441 (20090919) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
I've only managed this kind of configuration to work using Spring, DWR 3.0 and JS mapped classes. I can't help that much with 2.x and Guice
Regards
On Sun, Sep 20, 2009 at 5:35 PM, David Marginian <[hidden email]> wrote: I am not sure but from looking at this code I wouldn't expect this to work. Can someone else (Jose, Lande) take a look at this? |
|
I got to the bottom of this. It is certainly NOT a bug in DWR. It is a
bug in Hubert's JavaScript code: var record = new MyDomainObj(); record = { id : null, name : null, age : null }; dwr.util.getValues(record); dwr.engine.beginBatch(); if (type == "add") { SubClass.add(record); Hubert, your are overwriting the type when you re-assign record to a new hash (record { id: null, name: null, age: null }). You need to do something like this: var record = new MyDomainObj(); record.id = dwr.util.getValue("idField"); record.name = dwr.util.getValue("nameField"); etc. etc. When I changed this the method was remoted properly by DWR. Next time send us your complete code (JavaScript, Java, etc.) instead of assuming a bug in DWR. -David Jose Noheda wrote: > I've only managed this kind of configuration to work using Spring, DWR > 3.0 and JS mapped classes. I can't help that much with 2.x and Guice > > Regards > > On Sun, Sep 20, 2009 at 5:35 PM, David Marginian <[hidden email] > <mailto:[hidden email]>> wrote: > > I am not sure but from looking at this code I wouldn't expect this > to work. Can someone else (Jose, Lande) take a look at this? > > Lance Java wrote: > > I think this may be the same issue as this > http://bugs.directwebremoting.org/bugs/browse/DWR-125. From > memory, when you use reflection on a generic class there may > be two copies of each method... one is marked as volitile. > This is probably why dwr is complaining about overloading methods. > > I think that a slight change is required to DWR to choose the > non-volatile method in these cases. > > 2009/9/20 Hubert Yang <hubert.yang.cn <http://hubert.yang.cn> > <http://hubert.yang.cn>@gmail.com <http://gmail.com> > <http://gmail.com>> > > > Since the mail list does not support attachment, I upload to: > http://cube316.net/dwr/MyWebApp.zip > Please download it from there. > > On Sun, Sep 20, 2009 at 3:22 PM, Hubert Yang > <hubert.yang.cn <http://hubert.yang.cn> > <http://hubert.yang.cn>@gmail.com <http://gmail.com> > <http://gmail.com>> wrote: > > David: > I have attached a simple web application that > demostrate my > problem, you can import into Eclipse and run index.jsp > Maven is required to download the library > dependency > (alternatively you can put > dwr-2.0.5.jar&commons-logging-1.1.1.jar in > MyWebApp\src\main\webapp\WEB-INF\lib folder). > > Please let me know if my problem could be re-produced. > Thanks > On Sun, Sep 20, 2009 at 12:43 AM, Hubert Yang > <hubert.yang.cn <http://hubert.yang.cn> > <http://hubert.yang.cn/>@gmail.com <http://gmail.com> > <http://gmail.com/>> wrote: > > David: > Now I use only the traditional way of > DWR, with the > following xml and without any annotation: > ------------------------------------- > <dwr> > <allow> > <create creator="new" javascript="SubClass"> > <param name="class" > value="com.mypackage.SubClass" /> > </create> > > <convert match="java.lang.Exception" > converter="exception" /> > <convert match="com.mypackage.domain.MyDomainObject" > converter="bean" javascript="MyDomainObj" /> > </allow> > </dwr> > ------------------------------------- > Now I was able to find the definition > of MyDomainObj > function in SubClass.js, but in the test/debug > page, the > parameter for add is still java.lang.Object, not > com.mypackage.domain.MyDomainObject > when I create a new MyDomainObj js > object and sent it to > server via dwr, exception is thrown: > ------------------------------------- > java.lang.IllegalArgumentException: Missing method or > missing parameter converters > ------------------------------------- > I think it is conplaining that no > converter could be found > for java.lang.Object > So the problem goes back to the title > again: DWR does not > recognize generic type parameter (with inheritance) > I may upload my project tomorrow if > this is necessary, > since it's already over midnight here. > thank you and have a nice day, see you > tomorrow. > On Sun, Sep 20, 2009 at 12:11 AM, Hubert Yang > <hubert.yang.cn <http://hubert.yang.cn> > <http://hubert.yang.cn/>@gmail.com <http://gmail.com> > > <http://gmail.com/>> wrote: > > Originally I only have the following in my dwr.xml: > <dwr> > <allow> > <convert match="java.lang.Exception" > converter="exception"> > </allow> > </dwr> > in order to have a better > understanding of the > exception message in js exception handler (Yes, > I know > this could be done via annotation, I will > remove the > dwr.xml completely) > the following line was added > when I read the document > you give: > <convert converter="bean" > match="com.mypackage.domain.MyDomainObject" > javascript="MyDomainObj" > /> > because I can not figure out > how to add the > "javascript" property in annoation. > By default, the converter for > @DataTransfterObject is > exactly the bean converter, so I don't think > this will > cause inconsistency > I am now trying to testing > without annotation. > > On Sat, Sep 19, 2009 at 11:53 PM, David Marginian > <[hidden email] > <mailto:[hidden email]> <mailto:[hidden email] > <mailto:[hidden email]>>> wrote: > > Hubert, > I understand why you are using the > annotations. > I just don't know why you are mixing them with > the dwr.xml - seems to me you could eliminate > dwr.xml completely. I think your problem is > arising from mixing the two: > > You have the following annotation specified: > > @DataTransferObject > public class MyDomainObject implements > > The @DataTransferObject declares a DWR > converter. > But then you also have the same converter > specified in your dwr.xml: > <convert converter="bean" > > > match="com.mypackage.domain.MyDomainObject" > javascript="MyDomainObj"/> > > My guess is that the annotation converter > is being > used which is why the MyDomainObj > JavaScript class > is not being created. I think this illustrates > why I said - one or the other. > -David > > Hubert Yang wrote: > > Apologies if my explanation confuses you > Actually I use annotation to reduce > the size > of xml configuration file and also for > better > refactor support. > I use guice injection in my own business > logic, so if I do not use guice in > combination > with DWR, my backend code will probably not > work via DWR ajax. > Yes you are right, superclass does not > need > the @RemoteProxy here, I have removed it. > thanks for reminding. > Anyway, I will use some mockup service > without any guice dependency and use only > dwr.xml to check if things are working. > Thanks for the kind hint, I will let > you know > the result. > > On Sat, Sep 19, 2009 at 11:16 PM, David > Marginian <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>> wrote: > > Hubert, > You have a lot going on here. When > trying > to fix problems it is > always best to simplify things - > which you > have not done. Why are > you mixing annotations with dwr.xml > configuration? You also have > creators (RemoteProxys) defined for both > the subclass and the > superclass. I have never done this > before > but I would think you > would only need a RemoteProxy for the > subclass. I believe the > MyDomainObject will be defined in > the DWR > generated interface file > (I would assume this would be the > JavaScript interface generated > for SubClass). The test page should > help > you out in seeing the > generated JavaScript. If this > doesn't help > I would suggest > simplifying by configuring (for now) > with > just the dwr.xml - get > that working and then move on and make > things more complex. > > > Hubert Yang wrote: > > Hey Jose: > This does NOT help things out. > My problem is how to define the > MyDomainObject so that it > could be regonized by DWR. > No matter the first line is > included > or not, the javascript > error "MyDomainObj" is always there. > That is the key problem. > > On Sat, Sep 19, 2009 at 8:56 PM, > Jose > Noheda > <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>>> > > wrote: > > The first line does not make > sense. > Check the JS generated > by DWR > and look for MyDomainObj in there > > Regards > > > On Sat, Sep 19, 2009 at 6:51 AM, > Hubert Yang > <hubert.yang.cn > <http://hubert.yang.cn> > <http://hubert.yang.cn/> > <http://hubert.yang.cn/> > > <http://hubert.yang.cn/>@gmail.com <http://gmail.com> > <http://gmail.com/> <http://gmail.com/> > <http://gmail.com/>> wrote: > > Thanks for the reply, David > I added the following > line in dwr.xml: > <convert > converter="bean" > match="java.lang.Object" > javascript="MyObject" /> > <convert converter="bean" > > match="com.mypackage.domain.MyDomainObject" > javascript="MyDomainObj"/> > however, when I > try to > create a new javascript > object: > var record = new > MyDomainObj(); > in firebug I was > told: > MyDomainObj is not defined. > Do I need to include > some extra js files in > html header? I > only find the definition of > "MyObject" in > > ${webroot}/dwr/interface/SubClass.js > The page you give use > the following example > which is not the > case for me here (I need to > create a new MyDomainObj from > scratch): > var p = ... // > get an > Employee from the server > On the other hand, In > dwr test page, the "no > converter warning > for java.lang.Object" is > gone, > and the tooltip of add() > method says "Will be > converted > to: java.lang.Object" > This is pretty > weird to > me since DWR still > cound not regonize > the correct type of T here. > > On Sat, Sep 19, 2009 at > 11:20 AM, David Marginian > <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>>> wrote: > > DWR needs to be able to > create T from a JavaScript > object. > Finding out what T > is, is > not exactly straightforward. > DWR has a feature to > make > this easier. See > "Mapping Java > classes to JavaScript > classes" here: > > > http://directwebremoting.org/dwr/server/dwrxml/converters/bean.html > > Let us know if it > helps you > out. You will need to > specify > a converter for each > bean: > <convert converter="bean" > > match="com.mypackage.domain.Bean1" > javascript="bean1"/> > etc. > > > > Hubert Yang wrote: > > > Hi, all: > > I got a super > class that > defines methods with > generic > parameters (along > with > some DWR annotation), i.e: > > > --------------------------------------- > > @RemoteProxy(creator = > GuiceCreator.class) > public class > BaseClass <T> ( > @RemoteMethod > public add(T > domainObj){ > //... > } > } > > --------------------------------------- > > and a subclass > that only > inherit the above class: > > > --------------------------------------- > > @RemoteProxy(creator = > GuiceCreator.class) > public class SubClass > extends > > BaseClass<MyDomainObject> { } > > --------------------------------------- > > and of course: > > > --------------------------------------- > @DataTransferObject > public class > MyDomainObject implements > > java.io.Serializable { > @RemoteProperty > private String > property; > //... > } > > --------------------------------------- > > in dwr.xml, I > have the > following: > > > --------------------------------------- > <dwr> > <allow> > <convert > converter="bean" > > match="com.mypackage.domain.*"/> > </allow> > </dwr> > > --------------------------------------- > > When I deploy > that to my > WAR and try to run the > code, > exception was thrown: > > > --------------------------------------- > > java.lang.IllegalArgumentException: "Missing > method or > missing parameter > converters" > > --------------------------------------- > > So I checked the dwr > test page, only to find the > following: > > > --------------------------------------- > (Warning: No > Converter > for java.lang.Object. > See below) > > --------------------------------------- > > It seems DWR does not > recognize my generic > parameter > in SubClass which > should > be actually > > com.mypackage.domain.MyDomainObject, > but use > java.lang.Object > instead. > > > So I tried > another way: > > > --------------------------------------- > > @RemoteProxy(creator = > GuiceCreator.class) > public class SubClass > extends > BaseClass<MyDomainObject> { > > @Override > @RemoteMethod > public void > add(MyDomainObject obj) { > > super.add(obj); > } > > --------------------------------------- > > Code works, but I > still > got "(Warning: overloaded > methods are not > recommended. See below) " in > the test > page (Yes, this is a > reasonable warning). > > > And also trying > to add > the following to dwr.xml: > > --------------------------------------- > <signatures> > <![CDATA[ > import > com.mypackage.domain.MyDomainObject; > import > com.mypackage.SubClass; > > SubClass.add(MyDomainObject obj); > ]]> > </signatures> > > --------------------------------------- > > which does not work. > > > Is there a workaround > for this so that DWR could > recognize this > kind of > generic paramter without > re-define a > method with > new name in SubClass (I > really > saved a lot of > code by > using generic types) > > FYI: I use DWR > 2.0.5 and > JDK1.5 > > Any > ideas/comments are > appreciated. > > > > __________ > Information from > ESET NOD32 Antivirus, > version > of virus signature > database > 4439 (20090918) __________ > > The message was > checked by > ESET NOD32 Antivirus. > > http://www.eset.com > <http://www.eset.com/> > <http://www.eset.com/> > <http://www.eset.com/> > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > > [hidden email] > <mailto:[hidden email]> > > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > > <mailto:[hidden email] > <mailto:[hidden email]>>> > > <mailto:[hidden email] > <mailto:[hidden email]> > > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > > <mailto:[hidden email] > <mailto:[hidden email]>>>> > > For additional > commands, e-mail: > > [hidden email] <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>> > > > > > > > > __________ Information from ESET NOD32 > Antivirus, version of virus > signature database 4440 (20090919) > __________ > > > The message was checked by ESET NOD32 > Antivirus. > > http://www.eset.com > <http://www.eset.com/> > <http://www.eset.com/> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [hidden email] > <mailto:[hidden email]> > > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > > <mailto:[hidden email] > <mailto:[hidden email]>>> > For additional commands, e-mail: > [hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> > > > > > > __________ Information from ESET NOD32 > Antivirus, > version of virus signature database 4440 > (20090919) __________ > > The message was checked by ESET NOD32 > Antivirus. > > http://www.eset.com <http://www.eset.com/> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > For additional commands, e-mail: > [hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4441 (20090919) __________ > > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > <mailto:[hidden email]> > For additional commands, e-mail: [hidden email] > <mailto:[hidden email]> > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4441 (20090919) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
I followed your javascript code but still got exception complaining about "java.lang.IllegalArgumentException", and in the DWR test page the parameter type is still java.lang.Object.
Besides, under the assumption that the code should work (despite of my local environment problem), I will endup with writing code like "record.id = dwr.util.getValue("idField")" if MyDomainObj got lots of properties.
Anyway, I solve this problem by adding different remote method to SubClass (generally speaking, only CRUD operation), and call those methods instead of calling methods from SuperClass
Again, thanks a lot for helping me.
On Mon, Sep 21, 2009 at 8:00 AM, David Marginian <[hidden email]> wrote: I got to the bottom of this. It is certainly NOT a bug in DWR. It is a bug in Hubert's JavaScript code: |
|
What do you expect to see on the DWR test page? It does not know the
type of what you are passing until the method is called. So you got everything working? Hubert Yang wrote: > I followed your javascript code but still got exception complaining > about "java.lang.IllegalArgumentException", and in the DWR test page > the parameter type is still java.lang.Object. > > Besides, under the assumption that the code should work (despite of my > local environment problem), I will endup with writing code like > "record.id <http://record.id> = dwr.util.getValue("idField")" if > MyDomainObj got lots of properties. > > Anyway, I solve this problem by adding different remote method to > SubClass (generally speaking, only CRUD operation), and call those > methods instead of calling methods from SuperClass > > Again, thanks a lot for helping me. > > On Mon, Sep 21, 2009 at 8:00 AM, David Marginian <[hidden email] > <mailto:[hidden email]>> wrote: > > I got to the bottom of this. It is certainly NOT a bug in DWR. > It is a bug in Hubert's JavaScript code: > > var record = new MyDomainObj(); > record = { > id : null, > name : null, > age : null > }; > dwr.util.getValues(record); > dwr.engine.beginBatch(); > if (type == "add") { > SubClass.add(record); > > Hubert, your are overwriting the type when you re-assign record to > a new hash (record { id: null, name: null, age: null }). You need > to do something like this: > > var record = new MyDomainObj(); > record.id <http://record.id/> = dwr.util.getValue("idField"); > record.name <http://record.name/> = dwr.util.getValue("nameField"); > etc. > etc. > > When I changed this the method was remoted properly by DWR. Next > time send us your complete code (JavaScript, Java, etc.) instead > of assuming a bug in DWR. > > -David > > Jose Noheda wrote: > > I've only managed this kind of configuration to work using > Spring, DWR 3.0 and JS mapped classes. I can't help that much > with 2.x and Guice > > Regards > > On Sun, Sep 20, 2009 at 5:35 PM, David Marginian > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> wrote: > > I am not sure but from looking at this code I wouldn't > expect this > to work. Can someone else (Jose, Lande) take a look at this? > > Lance Java wrote: > > I think this may be the same issue as this > http://bugs.directwebremoting.org/bugs/browse/DWR-125. From > memory, when you use reflection on a generic class > there may > be two copies of each method... one is marked as volitile. > This is probably why dwr is complaining about > overloading methods. > > I think that a slight change is required to DWR to > choose the > non-volatile method in these cases. > > 2009/9/20 Hubert Yang <hubert.yang.cn > <http://hubert.yang.cn/> <http://hubert.yang.cn > <http://hubert.yang.cn/>> > <http://hubert.yang.cn > <http://hubert.yang.cn/>>@gmail.com <http://gmail.com/> > <http://gmail.com <http://gmail.com/>> > <http://gmail.com <http://gmail.com/>>> > > > Since the mail list does not support attachment, I > upload to: > http://cube316.net/dwr/MyWebApp.zip > Please download it from there. > > On Sun, Sep 20, 2009 at 3:22 PM, Hubert Yang > <hubert.yang.cn <http://hubert.yang.cn/> > <http://hubert.yang.cn <http://hubert.yang.cn/>> > <http://hubert.yang.cn > <http://hubert.yang.cn/>>@gmail.com <http://gmail.com/> > <http://gmail.com <http://gmail.com/>> > <http://gmail.com <http://gmail.com/>>> wrote: > > David: > I have attached a simple web application > that > demostrate my > problem, you can import into Eclipse and run > index.jsp > Maven is required to download the library > dependency > (alternatively you can put > dwr-2.0.5.jar&commons-logging-1.1.1.jar in > MyWebApp\src\main\webapp\WEB-INF\lib folder). > > Please let me know if my problem could be > re-produced. > Thanks > On Sun, Sep 20, 2009 at 12:43 AM, Hubert > Yang > <hubert.yang.cn <http://hubert.yang.cn/> > <http://hubert.yang.cn <http://hubert.yang.cn/>> > <http://hubert.yang.cn/>@gmail.com > <http://gmail.com/> <http://gmail.com <http://gmail.com/>> > <http://gmail.com/>> wrote: > > David: > Now I use only the traditional > way of > DWR, with the > following xml and without any annotation: > > ------------------------------------- > <dwr> > <allow> > <create creator="new" javascript="SubClass"> > <param name="class" > value="com.mypackage.SubClass" /> > </create> > > <convert match="java.lang.Exception" > converter="exception" /> > <convert > match="com.mypackage.domain.MyDomainObject" > converter="bean" javascript="MyDomainObj" /> > </allow> > </dwr> > ------------------------------------- > Now I was able to find the > definition > of MyDomainObj > function in SubClass.js, but in the test/debug > page, the > parameter for add is still java.lang.Object, not > com.mypackage.domain.MyDomainObject > when I create a new MyDomainObj js > object and sent it to > server via dwr, exception is thrown: > > ------------------------------------- > java.lang.IllegalArgumentException: Missing > method or > missing parameter converters > ------------------------------------- > I think it is conplaining that no > converter could be found > for java.lang.Object > So the problem goes back to the > title > again: DWR does not > recognize generic type parameter (with > inheritance) > I may upload my project tomorrow if > this is necessary, > since it's already over midnight here. > thank you and have a nice day, > see you > tomorrow. > On Sun, Sep 20, 2009 at 12:11 AM, Hubert Yang > <hubert.yang.cn <http://hubert.yang.cn/> > <http://hubert.yang.cn <http://hubert.yang.cn/>> > <http://hubert.yang.cn/>@gmail.com <http://gmail.com/> > <http://gmail.com <http://gmail.com/>> > > <http://gmail.com/>> wrote: > > Originally I only have the following in > my dwr.xml: > <dwr> > <allow> > <convert match="java.lang.Exception" > converter="exception"> > </allow> > </dwr> > in order to have a better > understanding of the > exception message in js exception > handler (Yes, > I know > this could be done via annotation, I will > remove the > dwr.xml completely) > the following line was added > when I read the document > you give: > <convert converter="bean" > match="com.mypackage.domain.MyDomainObject" > javascript="MyDomainObj" > /> > because I can not figure out > how to add the > "javascript" property in annoation. > By default, the > converter for > @DataTransfterObject is > exactly the bean converter, so I don't think > this will > cause inconsistency > I am now trying to testing > without annotation. > > On Sat, Sep 19, 2009 at 11:53 PM, David > Marginian > <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>> wrote: > > Hubert, > I understand why you are using the > annotations. > I just don't know why you are > mixing them with > the dwr.xml - seems to me you could > eliminate > dwr.xml completely. I think your > problem is > arising from mixing the two: > > You have the following annotation > specified: > > @DataTransferObject > public class MyDomainObject implements > > The @DataTransferObject declares a DWR > converter. > But then you also have the same > converter > specified in your dwr.xml: > <convert converter="bean" > > > match="com.mypackage.domain.MyDomainObject" > javascript="MyDomainObj"/> > > My guess is that the annotation > converter > is being > used which is why the MyDomainObj > JavaScript class > is not being created. I think this > illustrates > why I said - one or the other. > -David > > Hubert Yang wrote: > > Apologies if my explanation > confuses you > Actually I use annotation to reduce > the size > of xml configuration file and > also for > better > refactor support. > I use guice injection in my own > business > logic, so if I do not use guice in > combination > with DWR, my backend code will > probably not > work via DWR ajax. > Yes you are right, superclass > does not > need > the @RemoteProxy here, I have > removed it. > thanks for reminding. > Anyway, I will use some mockup > service > without any guice dependency and > use only > dwr.xml to check if things are > working. > Thanks for the kind hint, I > will let > you know > the result. > > On Sat, Sep 19, 2009 at 11:16 > PM, David > Marginian <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>>> wrote: > > Hubert, > You have a lot going on > here. When > trying > to fix problems it is > always best to simplify things - > which you > have not done. Why are > you mixing annotations with > dwr.xml > configuration? You also have > creators (RemoteProxys) > defined for both > the subclass and the > superclass. I have never > done this > before > but I would think you > would only need a RemoteProxy > for the > subclass. I believe the > MyDomainObject will be defined in > the DWR > generated interface file > (I would assume this would be the > JavaScript interface generated > for SubClass). The test page > should > help > you out in seeing the > generated JavaScript. If this > doesn't help > I would suggest > simplifying by configuring > (for now) > with > just the dwr.xml - get > that working and then move on > and make > things more complex. > > > Hubert Yang wrote: > > Hey Jose: > This does NOT help > things out. > My problem is how to > define the > MyDomainObject so that it > could be regonized by DWR. > No matter the first line is > included > or not, the javascript > error "MyDomainObj" is > always there. > That is the key problem. > > On Sat, Sep 19, 2009 at > 8:56 PM, > Jose > Noheda > <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>> > > <mailto:[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>>>> > > wrote: > > The first line does > not make > sense. > Check the JS generated > by DWR > and look for > MyDomainObj in there > > Regards > > > On Sat, Sep 19, 2009 > at 6:51 AM, > Hubert Yang > <hubert.yang.cn > <http://hubert.yang.cn/> > <http://hubert.yang.cn <http://hubert.yang.cn/>> > <http://hubert.yang.cn/> > <http://hubert.yang.cn/> > > <http://hubert.yang.cn/>@gmail.com <http://gmail.com/> > <http://gmail.com <http://gmail.com/>> > <http://gmail.com/> > <http://gmail.com/> > <http://gmail.com/>> wrote: > > Thanks for the > reply, David > I added > the following > line in dwr.xml: > <convert > converter="bean" > > match="java.lang.Object" > javascript="MyObject" /> > <convert > converter="bean" > > match="com.mypackage.domain.MyDomainObject" > > javascript="MyDomainObj"/> > however, > when I > try to > create a new javascript > object: > var record > = new > MyDomainObj(); > in firebug > I was > told: > MyDomainObj is not defined. > Do I need > to include > some extra js files in > html header? I > only find the > definition of > "MyObject" in > > ${webroot}/dwr/interface/SubClass.js > The page > you give use > the following example > which is not the > case for me here > (I need to > create a new MyDomainObj from > scratch): > var p = > ... // > get an > Employee from the server > On the > other hand, In > dwr test page, the "no > converter warning > for > java.lang.Object" is > gone, > and the tooltip of add() > method says "Will be > converted > to: java.lang.Object" > This is pretty > weird to > me since DWR still > cound not regonize > the correct type > of T here. > > On Sat, Sep 19, 2009 at > 11:20 AM, David Marginian > > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>>> > > <mailto:[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>>>> wrote: > > DWR needs to > be able to > create T from a JavaScript > object. > Finding out > what T > is, is > not exactly straightforward. > DWR has a > feature to > make > this easier. See > "Mapping Java > classes to > JavaScript > classes" here: > > > http://directwebremoting.org/dwr/server/dwrxml/converters/bean.html > > Let us know if it > helps you > out. You will need to > specify > a converter > for each > bean: > <convert > converter="bean" > > match="com.mypackage.domain.Bean1" > javascript="bean1"/> > etc. > > > > Hubert Yang wrote: > > > Hi, all: > > I got a super > class that > defines methods with > generic > parameters > (along > with > some DWR annotation), i.e: > > > --------------------------------------- > > @RemoteProxy(creator = > GuiceCreator.class) > public class > BaseClass <T> ( > @RemoteMethod > public add(T > domainObj){ > //... > } > } > > --------------------------------------- > > and a subclass > that only > inherit the above class: > > > --------------------------------------- > > @RemoteProxy(creator = > GuiceCreator.class) > public > class SubClass > extends > > BaseClass<MyDomainObject> { } > > --------------------------------------- > > and of course: > > > --------------------------------------- > > @DataTransferObject > public class > MyDomainObject implements > > java.io.Serializable { > > @RemoteProperty > private > String > property; > //... > } > > --------------------------------------- > > in dwr.xml, I > have the > following: > > > --------------------------------------- > <dwr> > <allow> > <convert > converter="bean" > > match="com.mypackage.domain.*"/> > </allow> > </dwr> > > --------------------------------------- > > When I deploy > that to my > WAR and try to run the > code, > exception > was thrown: > > > --------------------------------------- > > java.lang.IllegalArgumentException: "Missing > method or > missing > parameter > converters" > > --------------------------------------- > > So I > checked the dwr > test page, only to find the > following: > > > --------------------------------------- > (Warning: No > Converter > for java.lang.Object. > See below) > > --------------------------------------- > > It seems > DWR does not > recognize my generic > parameter > in > SubClass which > should > be actually > > com.mypackage.domain.MyDomainObject, > but use > java.lang.Object > instead. > > > So I tried > another way: > > > --------------------------------------- > > @RemoteProxy(creator = > GuiceCreator.class) > public > class SubClass > extends > BaseClass<MyDomainObject> { > > @Override > > @RemoteMethod > public void > add(MyDomainObject obj) { > > super.add(obj); > } > > --------------------------------------- > > Code > works, but I > still > got "(Warning: overloaded > methods > are not > recommended. See below) " in > the test > page (Yes, > this is a > reasonable warning). > > > And also > trying > to add > the following to dwr.xml: > > --------------------------------------- > <signatures> > <![CDATA[ > import > com.mypackage.domain.MyDomainObject; > import > com.mypackage.SubClass; > > SubClass.add(MyDomainObject obj); > ]]> > </signatures> > > --------------------------------------- > > which does > not work. > > > Is there a > workaround > for this so that DWR could > recognize this > kind of > generic paramter without > re-define a > method with > new name in SubClass (I > really > saved a lot of > code by > using generic types) > > FYI: I use DWR > 2.0.5 and > JDK1.5 > > Any > ideas/comments are > appreciated. > > > __________ > Information from > ESET NOD32 Antivirus, > version > of virus signature > database > 4439 (20090918) __________ > > The message was > checked by > ESET NOD32 Antivirus. > > > http://www.eset.com <http://www.eset.com/> > <http://www.eset.com/> > <http://www.eset.com/> > <http://www.eset.com/> > > > > > > > --------------------------------------------------------------------- > To > unsubscribe, e-mail: > > [hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>>> > > For additional > commands, e-mail: > > [hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>>> > > > > > > > > __________ Information from > ESET NOD32 > Antivirus, version of virus > signature database 4440 > (20090919) > __________ > > > The message was checked by > ESET NOD32 > Antivirus. > > http://www.eset.com > <http://www.eset.com/> > <http://www.eset.com/> > <http://www.eset.com/> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > > [hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>> > For additional commands, e-mail: > [hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>>> > > > > > > __________ Information from ESET NOD32 > Antivirus, > version of virus signature database 4440 > (20090919) __________ > > The message was checked by ESET NOD32 > Antivirus. > > http://www.eset.com > <http://www.eset.com/> <http://www.eset.com/> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> > For additional commands, e-mail: > [hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > <mailto:[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> > > > > > > > > > > __________ Information from ESET NOD32 Antivirus, version > of virus > signature database 4441 (20090919) __________ > > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com <http://www.eset.com/> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > For additional commands, e-mail: > [hidden email] <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4441 (20090919) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com <http://www.eset.com/> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > <mailto:[hidden email]> > For additional commands, e-mail: [hidden email] > <mailto:[hidden email]> > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4441 (20090919) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
Well, if you put your mouse over the textbox, the tooltip will tell you what type it will be converted to.
Here I am not talking about what type you are passing to DWR, but what type it is expecting for the method.
I expect to see "com.mypackage.MyDomainObject" instead of "java.lang.Object"
By what I mentioned above (adding new methods in SubClass and expose to DWR), I could see the correct type on test page, and of course no exception is thrown, code will work.
On Mon, Sep 21, 2009 at 11:37 AM, David Marginian <[hidden email]> wrote: What do you expect to see on the DWR test page? It does not know the type of what you are passing until the method is called. So you got everything working? Hubert Yang wrote: > I followed your javascript code but still got exception complaining > about "java.lang.IllegalArgumentException", and in the DWR test page > the parameter type is still java.lang.Object. > > Besides, under the assumption that the code should work (despite of my > local environment problem), I will endup with writing code like > "record.id = dwr.util.getValue("idField")" if > MyDomainObj got lots of properties. > > Anyway, I solve this problem by adding different remote method to > SubClass (generally speaking, only CRUD operation), and call those > methods instead of calling methods from SuperClass > > Again, thanks a lot for helping me. > > On Mon, Sep 21, 2009 at 8:00 AM, David Marginian > wrote: > > I got to the bottom of this. It is certainly NOT a bug in DWR. > It is a bug in Hubert's JavaScript code: > > var record = new MyDomainObj(); > record = { > id : null, > name : null, > age : null > }; > dwr.util.getValues(record); > dwr.engine.beginBatch(); > if (type == "add") { > SubClass.add(record); > > Hubert, your are overwriting the type when you re-assign record to > a new hash (record { id: null, name: null, age: null }). You need > to do something like this: > > var record = new MyDomainObj(); > record.id = dwr.util.getValue("idField"); > record.name = dwr.util.getValue("nameField"); > etc. > etc. > > When I changed this the method was remoted properly by DWR. Next > time send us your complete code (JavaScript, Java, etc.) instead > of assuming a bug in DWR. > > -David > > Jose Noheda wrote: > > I've only managed this kind of configuration to work using > Spring, DWR 3.0 and JS mapped classes. I can't help that much > with 2.x and Guice > > Regards > > On Sun, Sep 20, 2009 at 5:35 PM, David Marginian > > >> wrote: > > I am not sure but from looking at this code I wouldn't > expect this > to work. Can someone else (Jose, Lande) take a look at this? > > Lance Java wrote: > > I think this may be the same issue as this > http://bugs.directwebremoting.org/bugs/browse/DWR-125. From > memory, when you use reflection on a generic class > there may > be two copies of each method... one is marked as volitile. > This is probably why dwr is complaining about > overloading methods. > > I think that a slight change is required to DWR to > choose the > non-volatile method in these cases. > > 2009/9/20 Hubert Yang > > >@gmail.com > > > >> > > > Since the mail list does not support attachment, I > upload to: > http://cube316.net/dwr/MyWebApp.zip > Please download it from there. > > On Sun, Sep 20, 2009 at 3:22 PM, Hubert Yang > > > > >@gmail.com > > > >> wrote: > > David: > I have attached a simple web application > that > demostrate my > problem, you can import into Eclipse and run > index.jsp > Maven is required to download the library > dependency > (alternatively you can put > dwr-2.0.5.jar&commons-logging-1.1.1.jar in > MyWebApp\src\main\webapp\WEB-INF\lib folder). > > Please let me know if my problem could be > re-produced. > Thanks > On Sun, Sep 20, 2009 at 12:43 AM, Hubert > Yang > > > > @gmail.com > > > > wrote: > > David: > Now I use only the traditional > way of > DWR, with the > following xml and without any annotation: > > ------------------------------------- > > > > value="com.mypackage.SubClass" /> > > > converter="exception" /> > match="com.mypackage.domain.MyDomainObject" > converter="bean" javascript="MyDomainObj" /> > > > ------------------------------------- > Now I was able to find the > definition > of MyDomainObj > function in SubClass.js, but in the test/debug > page, the > parameter for add is still java.lang.Object, not > com.mypackage.domain.MyDomainObject > when I create a new MyDomainObj js > object and sent it to > server via dwr, exception is thrown: > > ------------------------------------- > java.lang.IllegalArgumentException: Missing > method or > missing parameter converters > ------------------------------------- > I think it is conplaining that no > converter could be found > for java.lang.Object > So the problem goes back to the > title > again: DWR does not > recognize generic type parameter (with > inheritance) > I may upload my project tomorrow if > this is necessary, > since it's already over midnight here. > thank you and have a nice day, > see you > tomorrow. > On Sun, Sep 20, 2009 at 12:11 AM, Hubert Yang > > > > @gmail.com > > > > > wrote: > > Originally I only have the following in > my dwr.xml: > > > converter="exception"> > > > in order to have a better > understanding of the > exception message in js exception > handler (Yes, > I know > this could be done via annotation, I will > remove the > dwr.xml completely) > the following line was added > when I read the document > you give: > match="com.mypackage.domain.MyDomainObject" > javascript="MyDomainObj" > /> > because I can not figure out > how to add the > "javascript" property in annoation. > By default, the > converter for > @DataTransfterObject is > exactly the bean converter, so I don't think > this will > cause inconsistency > I am now trying to testing > without annotation. > > On Sat, Sep 19, 2009 at 11:53 PM, David > Marginian > > > > >>> wrote: > > Hubert, > I understand why you are using the > annotations. > I just don't know why you are > mixing them with > the dwr.xml - seems to me you could > eliminate > dwr.xml completely. I think your > problem is > arising from mixing the two: > > You have the following annotation > specified: > > @DataTransferObject > public class MyDomainObject implements > > The @DataTransferObject declares a DWR > converter. > But then you also have the same > converter > specified in your dwr.xml: > > > match="com.mypackage.domain.MyDomainObject" > javascript="MyDomainObj"/> > > My guess is that the annotation > converter > is being > used which is why the MyDomainObj > JavaScript class > is not being created. I think this > illustrates > why I said - one or the other. > -David > > Hubert Yang wrote: > > Apologies if my explanation > confuses you > Actually I use annotation to reduce > the size > of xml configuration file and > also for > better > refactor support. > I use guice injection in my own > business > logic, so if I do not use guice in > combination > with DWR, my backend code will > probably not > work via DWR ajax. > Yes you are right, superclass > does not > need > the @RemoteProxy here, I have > removed it. > thanks for reminding. > Anyway, I will use some mockup > service > without any guice dependency and > use only > dwr.xml to check if things are > working. > Thanks for the kind hint, I > will let > you know > the result. > > On Sat, Sep 19, 2009 at 11:16 > PM, David > Marginian > > > > >> > > > > > >>>> wrote: > > Hubert, > You have a lot going on > here. When > trying > to fix problems it is > always best to simplify things - > which you > have not done. Why are > you mixing annotations with > dwr.xml > configuration? You also have > creators (RemoteProxys) > defined for both > the subclass and the > superclass. I have never > done this > before > but I would think you > would only need a RemoteProxy > for the > subclass. I believe the > MyDomainObject will be defined in > the DWR > generated interface file > (I would assume this would be the > JavaScript interface generated > for SubClass). The test page > should > help > you out in seeing the > generated JavaScript. If this > doesn't help > I would suggest > simplifying by configuring > (for now) > with > just the dwr.xml - get > that working and then move on > and make > things more complex. > > > Hubert Yang wrote: > > Hey Jose: > This does NOT help > things out. > My problem is how to > define the > MyDomainObject so that it > could be regonized by DWR. > No matter the first line is > included > or not, the javascript > error "MyDomainObj" is > always there. > That is the key problem. > > On Sat, Sep 19, 2009 at > 8:56 PM, > Jose > Noheda > > > > > >> > > > > > >>> > > > > > > >> > > > > > >>>>> > > wrote: > > The first line does > not make > sense. > Check the JS generated > by DWR > and look for > MyDomainObj in there > > Regards > > > On Sat, Sep 19, 2009 > at 6:51 AM, > Hubert Yang > > > > > > > @gmail.com > > > > > > wrote: > > Thanks for the > reply, David > I added > the following > line in dwr.xml: > converter="bean" > > match="java.lang.Object" > javascript="MyObject" /> > converter="bean" > > match="com.mypackage.domain.MyDomainObject" > > javascript="MyDomainObj"/> > however, > when I > try to > create a new javascript > object: > var record > = new > MyDomainObj(); > in firebug > I was > told: > MyDomainObj is not defined. > Do I need > to include > some extra js files in > html header? I > only find the > definition of > "MyObject" in > > ${webroot}/dwr/interface/SubClass.js > The page > you give use > the following example > which is not the > case for me here > (I need to > create a new MyDomainObj from > scratch): > var p = > ... // > get an > Employee from the server > On the > other hand, In > dwr test page, the "no > converter warning > for > java.lang.Object" is > gone, > and the tooltip of add() > method says "Will be > converted > to: java.lang.Object" > This is pretty > weird to > me since DWR still > cound not regonize > the correct type > of T here. > > On Sat, Sep 19, 2009 at > 11:20 AM, David Marginian > > > > > > >> > > > > > >>> > > > > > > >> > > > > > >>>>> wrote: > > DWR needs to > be able to > create T from a JavaScript > object. > Finding out > what T > is, is > not exactly straightforward. > DWR has a > feature to > make > this easier. See > "Mapping Java > classes to > JavaScript > classes" here: > > > http://directwebremoting.org/dwr/server/dwrxml/converters/bean.html > > Let us know if it > helps you > out. You will need to > specify > a converter > for each > bean: > converter="bean" > > match="com.mypackage.domain.Bean1" > javascript="bean1"/> > etc. > > > > Hubert Yang wrote: > > > Hi, all: > > I got a super > class that > defines methods with > generic > parameters > (along > with > some DWR annotation), i.e: > > > --------------------------------------- > > @RemoteProxy(creator = > GuiceCreator.class) > public class > BaseClass ( > @RemoteMethod > public add(T > domainObj){ > //... > } > } > > --------------------------------------- > > and a subclass > that only > inherit the above class: > > > --------------------------------------- > > @RemoteProxy(creator = > GuiceCreator.class) > public > class SubClass > extends > > BaseClass { } > > --------------------------------------- > > and of course: > > > --------------------------------------- > > @DataTransferObject > public class > MyDomainObject implements > > java.io.Serializable { > > @RemoteProperty > private > String > property; > //... > } > > --------------------------------------- > > in dwr.xml, I > have the > following: > > > --------------------------------------- > > > converter="bean" > > match="com.mypackage.domain.*"/> > > > > --------------------------------------- > > When I deploy > that to my > WAR and try to run the > code, > exception > was thrown: > > > --------------------------------------- > > java.lang.IllegalArgumentException: "Missing > method or > missing > parameter > converters" > > --------------------------------------- > > So I > checked the dwr > test page, only to find the > following: > > > --------------------------------------- > (Warning: No > Converter > for java.lang.Object. > See below) > > --------------------------------------- > > It seems > DWR does not > recognize my generic > parameter > in > SubClass which > should > be actually > > com.mypackage.domain.MyDomainObject, > but use > java.lang.Object > instead. > > > So I tried > another way: > > > --------------------------------------- > > @RemoteProxy(creator = > GuiceCreator.class) > public > class SubClass > extends > BaseClass { > > @Override > > @RemoteMethod > public void > add(MyDomainObject obj) { > > super.add(obj); > } > > --------------------------------------- > > Code > works, but I > still > got "(Warning: overloaded > methods > are not > recommended. See below) " in > the test > page (Yes, > this is a > reasonable warning). > > > And also > trying > to add > the following to dwr.xml: > > --------------------------------------- > > import > com.mypackage.domain.MyDomainObject; > import > com.mypackage.SubClass; > > SubClass.add(MyDomainObject obj); > ]]> > > > --------------------------------------- > > which does > not work. > > > Is there a > workaround > for this so that DWR could > recognize this > kind of > generic paramter without > re-define a > method with > new name in SubClass (I > really > saved a lot of > code by > using generic types) > > FYI: I use DWR > 2.0.5 and > JDK1.5 > > Any > ideas/comments are > appreciated. > > > __________ > Information from > ESET NOD32 Antivirus, > version > of virus signature > database > 4439 (20090918) __________ > > The message was > checked by > ESET NOD32 Antivirus. > > > http://www.eset.com > > > > > > > > > > --------------------------------------------------------------------- > To > unsubscribe, e-mail: > > [hidden email] > > > > > > >> > > > > > > > >>> > > > > > > > >> > > > > > > > >>>> > > For additional > commands, e-mail: > > [hidden email] > > > > > > >> > > > > > > > >>> > > > > > > > >> > > > > > > > >>>> > > > > > > > > __________ Information from > ESET NOD32 > Antivirus, version of virus > signature database 4440 > (20090919) > __________ > > > The message was checked by > ESET NOD32 > Antivirus. > > http://www.eset.com > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > > [hidden email] > > > > > > >> > > > > > > > >>> > For additional commands, e-mail: > [hidden email] > > > > > > >> > > > > > > > >>> > > > > > > __________ Information from ESET NOD32 > Antivirus, > version of virus signature database 4440 > (20090919) __________ > > The message was checked by ESET NOD32 > Antivirus. > > http://www.eset.com > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [hidden email] > > > > > > >> > For additional commands, e-mail: > [hidden email] > > > > > >> > > > > > > > > > > __________ Information from ESET NOD32 Antivirus, version > of virus > signature database 4441 (20090919) __________ > > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > > > > For additional commands, e-mail: > [hidden email] > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4441 (20090919) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > > For additional commands, e-mail: [hidden email] > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4441 (20090919) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
| Powered by Nabble | Edit this page |
