dev@glassfish.java.net

Re: multiple problems with empty password in creating jdbc connection pool

From: Muhammad Siraj Ghaffar <siraj.ghaffar_at_Sun.COM>
Date: Wed, 09 Aug 2006 07:55:20 -0400

Kedar Mhaswade wrote:

>> Backend treats "" empty String as removal of the property itself.
>> This mean, unless backend changed the behaviour or have a way for
>> setting property value to "" empty string, there is not much GUI can do.
>> I am transferring this bug to 'admin'. Once they design and
>> implemented a way to set empty string value to Property, then GUI can
>> implement that.
>> Here is comment from bug# 6363330
>>
>>> Set empty valued property is treated by backend as request to remove
>>> property.
>>> This is only way to remove property from CLI, as far as it has only
>>> 'get' and 'set' command to handle dotted named attributes and
>>> properties.
>>> We can not re-consider this behaviour now because of backward
>>> compartibility.
>>> Kedar and Abhijit proposed to have the special value for property to
>>> set it to "empty" string.
>>>
>
> The point that I was trying to make was it is hard to represent on any
> interface.


This particular problem isnt hard for gui. The current gui design does
allows both deleting properties and setting empty values.

> Definitely not on the lines of "It is someone else's problem" or
> "something is not done right".
>
> What is true for properties is however not true for attributes, that's
> all. For example, if I am modifying an attribute (let's say per the
> schema,
> this is an IMPLIED attribute) of an element on the GUI, then when I
> specify an empty value in the text field, that attribute is removed from
> domain.xml.

I am not sure if we even want to present an interface to the user where
the user can either delete an attribute or set an empty value. Shouldnt
the system be deciding what to do, given that attributes are more 'well
known/well understood' by the appserver itself ?

>
> How would we (easily) make this to be distinct from having the
> attribute with
> a value "" in the domain.xml because
>
> <foo a1="" a2="xyz" .../>
>
> could be a configuration different from:
>
> <foo a2="xyz" .../>
>