On Aug 19, 2010, at 9:13 AM, Justin Lee wrote:
> Adding an @NotNull there would mean that element would always be there and that's not what we need.
right, I agree there is a difference between these two possibilities. I am not sure I want to revert the feature completely, I can certainly think of a few ways to selectively write or not empty elements. Remember that all this was triggered by the REST layer which is happily creating empty elements just for browsing purposes.
I need to check with Ludo on a few things, especially about side effects of what he is doing and I will keep everyone posted afterwards.
jerome
>
> On 8/19/10 12:08 PM, Tom Mueller wrote:
>> Back the original problem - just want to make sure I understand:
>>
>> <protocol name="http-listener-1"/>
>>
>> and
>>
>> <protocol name="http-listener-1">
>> <http-redirect/>
>> </protocol>
>>
>> have a different meeting?
>>
>> And a @NotNull on Protocol.getHttpRedirect doesn't fix this?
>>
>> Tom
>>
>>
>> On 8/19/2010 11:03 AM, Ludovic Champenois wrote:
>>> On 8/19/10 8:50 AM, Justin Lee wrote:
>>>> That's a horrible hack
>>> Not completely sure about that:-) User visible and controllable in config.
>>> Reverting to store all default values is anyway uglier... So let's see if there is yet another way to fix the issue.
>>> Ludo
>>>> to impose locally to a problem that exists everywhere, though. And it would require another grizzly integration just to get it. Not really much of an option.
>>>>
>>>> On 8/19/10 11:39 AM, Ludovic Champenois wrote:
>>>>> On 8/19/10 8:30 AM, Justin Lee wrote:
>>>>>> We can't use @NotNull because this element isn't always used. I like the idea of not writing out defaulted *attributes* but not writing such elements causes too many problems.
>>>>>>
>>>>>>
>>>>> Will wait for Jerome.
>>>>> Maybe you could add a field in http-redirect that says used or not? By default it would be off (so not saved), but setting it would activate the redirect....and the storage?
>>>>> Ludo
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>