> Here's a little patch addressing the issue.
>
> Regards
>
> On Wed, Oct 21, 2009 at 7:29 AM, Jose Noheda <
jose.noheda@...
> <mailto:
jose.noheda@...>> wrote:
>
> Fantastic David. I was going to check it in myself but having some
> input is way better.
>
> By the way, we should add a setAccessible(true) when returning
> methods that are not public.
>
> Regards
>
>
> On Wed, Oct 21, 2009 at 2:26 AM, David Marginian
> <
david@... <mailto:
david@...>> wrote:
>
> I took a look at the patch, sorry it took so long. Looks
> good. I am going to run some tests and check it in.
>
> Jose Noheda wrote:
>
> Sorry, it took me some time to get this going. Here's a
> patch. It attempts to find a setter method using several
> possible ways (as much as I could think of). It needs
> reviewing! I changed a couple converters but it may be
> useful in other places as well. Let me know what you think
>
> Regards
>
> On Thu, Oct 1, 2009 at 1:15 PM, Jose Noheda
> <
jose.noheda@... <mailto:
jose.noheda@...>
> <mailto:
jose.noheda@...
> <mailto:
jose.noheda@...>>> wrote:
>
> I created
>
http://bugs.directwebremoting.org/bugs/browse/DWR-419.
> I'll try to resolve it soon (including unit test and such)
>
> Regards
>
>
> On Wed, Sep 30, 2009 at 9:09 PM, Mike Wilson
> <
mikewse@... <mailto:
mikewse@...>
> <mailto:
mikewse@...
> <mailto:
mikewse@...>>> wrote:
>
> Great that you found this Jose, and yes, it would
> be super if
> you could create a bug report and patch for it. It
> would also
> be great if you could first create a unit test that
> triggers
> the bug. It seems it would be straight-forward to
> make a test
> that is solved by (1)?
> It would be interesting to have a failing test case
> before patching (2), as we are not sure we need it?
> If you
> think we should patch (2) anyway, I think it would
> be good to
> first look for any performance implications of flushing
> classes from the Introspector (so we don't get hit
> because
> having to re-read class info too often).
> Best regards
> Mike
>
>
> ------------------------------------------------------------------------
> *From:* Jose Noheda
> [mailto:
jose.noheda@... <mailto:
jose.noheda@...>
> <mailto:
jose.noheda@...
> <mailto:
jose.noheda@...>>]
> *Sent:* den 30 september 2009 15:52
> *To:*
users@...
> <mailto:
users@...>
> <mailto:
users@...
> <mailto:
users@...>>
>
> *Subject:* Re: [dwr-user] Duplicate variable
> conversion
> warning
>
> I've checked Spring sources to see why it was
> working
> correctly to found two interesting tidbits:
>
> 1) In GenericTypeAwarePropertyDescriptor
> constructor:
>
> if (writeMethodToUse == null && readMethodToUse
> != null) {
> // Fallback: Original JavaBeans
> introspection might not
> have found matching setter
> // method due to lack of bridge method
> resolution, in
> case of the getter using a
> // covariant return type whereas the setter
> is defined
> for the concrete property type.
> writeMethodToUse =
> ClassUtils.getMethodIfAvailable(this.beanClass,
> "set" +
> StringUtils.capitalize(getName()), new Class[]
> {readMethodToUse.getReturnType()});
> }
>
> 2) In CachedIntrospectionResults constructor:
>
> // Immediately remove class from Introspector
> cache, to
> allow for proper
> // garbage collection on class loader shutdown
> - we cache
> it here anyway,
> // in a GC-friendly manner. In contrast to
> CachedIntrospectionResults,
> // Introspector does not use WeakReferences as
> values of
> its WeakHashMap!
> Class classToFlush = beanClass;
> do {
> Introspector.flushFromCaches(classToFlush);
> classToFlush = classToFlush.getSuperclass();
> } while (classToFlush != null);
>
> It seems Introspector is not reliable enough.
> The first
> point alone would resolve my issue but the
> second seems
> like a safety net after doing the
> introspection. Anyone
> aganist adding a patch with both to the codebase?
>
> Regards
>
> On Wed, Sep 30, 2009 at 3:38 PM, Lance Java
> <
lance.java@...
> <mailto:
lance.java@...>
> <mailto:
lance.java@...
> <mailto:
lance.java@...>>> wrote:
>
> Very strange that debug would perform
> differently to
> run... I've never witnessed this with
> eclipse. I'm not
> familiar with netbeans... are there any
> differences
> between the build and debug classpaths? Any
> byte code
> manipulation that I should know about?
>
> 2009/9/30 Jose Noheda
> <
jose.noheda@... <mailto:
jose.noheda@...>
> <mailto:
jose.noheda@...
> <mailto:
jose.noheda@...>>>
>
> I finally got DWR debugging working inside
> Netbeans (it's a pain as DWR is not
> available in a
> Maven repo) and localized the issue. It
> seems that
> BeanConverter checks for a setter:
>
> if (writeRequired &&
> descriptor.getWriteMethod()
> == null) // line 76
>
> and the setter is not there (null).
> That surprised
> me a little so I created a unit test
> and fired it.
>
> PropertyDescriptor parentProject =
> getPropertyDescriptor(DefaultVersion.class,
> "parentProject");
> assertNotNull("Parent project has a
> setter",
> parentProject.getWriteMethod());
>
> BeanInfo info =
>
> Introspector.getBeanInfo(DefaultVersion.class);
> PropertyDescriptor[] descriptors =
> info.getPropertyDescriptors();
> for (PropertyDescriptor descriptor :
> descriptors) {
> String name = descriptor.getName();
> if (name.equals("parentProject"))
> assertNotNull(descriptor.getWriteMethod());
> }
>
> The unit test checks the property
> descriptor in
> two ways, the first two lines use
> Spring to get
> the descriptor, the rest mimic the way
> that DWR
> currently uses. Now, the surprise.
> Running the
> test as is shows no errors but
> debugging the test
> (without modification) throws an exception
> (assertion failed) on the second
> assertNotNull
> (DWR style). Has anyone seen anything
> like this
> before?
>
> Regards
>
>
> On Wed, Sep 30, 2009 at 12:43 PM, Jose
> Noheda
> <
jose.noheda@...
> <mailto:
jose.noheda@...>
> <mailto:
jose.noheda@...
> <mailto:
jose.noheda@...>>> wrote:
>
> I've investigated the issue a
> little bit more
> in depth. The Spring code is
> working well and
> the property is being added to the
> include list:
>
> DEBUG
>
> [org.directwebremoting.spring.DwrClassPathBeanDefinitionScanner]
> - <Adding remote property
>
> [org.internna.iwebjtracker.model.DefaultVersion]:
> displayable>
> DEBUG
>
> [org.directwebremoting.spring.DwrClassPathBeanDefinitionScanner]
> - <Adding remote property
>
> [org.internna.iwebjtracker.model.DefaultVersion]:
> series>
> DEBUG
>
> [org.directwebremoting.spring.DwrClassPathBeanDefinitionScanner]
> - <Adding remote property
>
> [org.internna.iwebjtracker.model.DefaultVersion]:
> id>
> DEBUG
>
> [org.directwebremoting.spring.DwrClassPathBeanDefinitionScanner]
> - <Adding remote property
>
> [org.internna.iwebjtracker.model.DefaultVersion]:
> dueDate>
> DEBUG
>
> [org.directwebremoting.spring.DwrClassPathBeanDefinitionScanner]
> - <Adding remote property
>
> [org.internna.iwebjtracker.model.DefaultVersion]:
> currentVersion>
> DEBUG
>
> [org.directwebremoting.spring.DwrClassPathBeanDefinitionScanner]
> - <Adding remote property
>
> [org.internna.iwebjtracker.model.DefaultVersion]:
> parentProject>
> DEBUG
>
> [org.directwebremoting.spring.DwrClassPathBeanDefinitionScanner]
> - <Adding remote property
>
> [org.internna.iwebjtracker.model.DefaultVersion]:
> parentVersion>
> DEBUG
>
> [org.directwebremoting.spring.DwrClassPathBeanDefinitionScanner]
> - <Adding remote property
>
> [org.internna.iwebjtracker.model.DefaultVersion]:
> label>
>
> But the JS code generated is:
>
> if (typeof DefaultVersion !=
> 'function') {
> DefaultVersion = function() {
> this.id <
http://this.id>
> <
http://this.id> = null;
>
> this.parentVersion = null;
> this.currentVersion = false;
> this.label = null;
> this.dueDate = null;
> }
> DefaultVersion.$dwrClassName =
> 'DefaultVersion';
> DefaultVersion.$dwrClassMembers = {};
>
> DefaultVersion.$dwrClassMembers.id = {};
>
> DefaultVersion.$dwrClassMembers.parentVersion = {};
>
> DefaultVersion.$dwrClassMembers.currentVersion = {};
>
> DefaultVersion.$dwrClassMembers.label = {};
>
> DefaultVersion.$dwrClassMembers.dueDate = {};
> DefaultVersion.createFromMap =
> function(map) {
> var obj = new this();
> for(prop in map) if
> (map.hasOwnProperty(prop)) obj[prop] = map[prop];
> return obj;
> }
>
> dwr.engine._mappedClasses['DefaultVersion'] = DefaultVersion;
> }
>
> The parentProject property is lost
> in the
> process as if it was read-only (like
> displayable or series which are).
> This means
> the property is not converted even
> if sent (it
> is) and hence the null later. Ideas?
>
> Regards
>
> On Wed, Sep 30, 2009 at 12:28 PM,
> Lance Java
> <
lance.java@...
> <mailto:
lance.java@...>
> <mailto:
lance.java@...
> <mailto:
lance.java@...>>> wrote:
>
> Can you get the send through
> the POST body
> from the firebug net tab?
>
> 2009/9/29 Jose Noheda
> <
jose.noheda@...
> <mailto:
jose.noheda@...>
> <mailto:
jose.noheda@...
> <mailto:
jose.noheda@...>>>
>
> Hi,
>
> I'm getting a weird error when
> converting an mapped object:
>
> WARN
>
> [org.directwebremoting.extend.InboundContext]
> - <Duplicate variable
> conversion
> called:
>
> Conversion[Object_DefaultProject:FormField:String:{id:reference:c0-e11,
> ....},....DefaultProject]>
>
> The object in question has
> three
> variables all of which
> refer to the
> same DefaultProject
> instance. The
> first two work fine. The
> third prints
> the warning and results in
> a null.
>
> The relevant JS code:
>
> var prj =
>
> dwr.engine.remote.newObject("DefaultProject",
> {id: 0});
>
> var issue =
>
> dwr.engine.remote.newObject("DefaultIssue",
> {
> parentProject: prj,
>
> parentModule:
> dwr.engine.remote.newObject("DefaultVersion",
> {parentProject: prj},
>
> affectedVersion:
> dwr.engine.remote.newObject("DefaultModule",
> {parentProject: prj}
> });
>
> Any ideas what can be
> causing the issue?
>
> Regards
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
users-unsubscribe@...
> <mailto:
users-unsubscribe@...>
> For additional commands, e-mail:
>
users-help@...
> <mailto:
users-help@...>
>
>
> __________ Information from ESET NOD32 Antivirus, version
> of virus signature database 4509 (20091015) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
>
http://www.eset.com>
>
>
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of
> virus signature database 4527 (20091020) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
>
http://www.eset.com>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
users-unsubscribe@...
> <mailto:
users-unsubscribe@...>
> For additional commands, e-mail:
users-help@...
> <mailto:
users-help@...>
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
users-unsubscribe@...
> For additional commands, e-mail:
users-help@...
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 4530 (20091021) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
>
http://www.eset.com>
>
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4530 (20091021) __________
setter.patch (19K) 