Hi Marina,
For some reason, I can't get to the GF web pages right now. I'll try
again later.
Let's do #1 and #3
I have started the process for #3 and it should be possible to
complete it by the time Sahoo finishes his changes.
Are we ok with changing the current bug to a Feature request and
updating the subject line? Or do we want to close the current issue and
point to a new feature request?
-Tom
Marina Vatkina wrote:
>Hi Tom,
>
>Fair enough. We have several options:
>
>1. File a feature request and mark it as fixed.
>2. Add a note to GF persistence page.
>3. Add a note to TopLink JPA page where you list this option.
>
>What would be your preference? I don't think it's a candidate for the release
>notes.
>
>thanks,
>-marina
>
>Tom Ware wrote:
>
>
>>Hi Marina,
>>
>> First of all, saying we are ignoring the issue is conpletely false. A
>>warning message is logged. In fact, having the exception thrown is even
>>a configuration option.
>>
>> We have now chosen to change this default value for this option.
>>
>> The fact is, that whether or not you personally like the initial design
>>choice, that is what the current product does and there could be
>>customers that are able to deploy an application that runs successfully
>>as a result of that choice. With this change, their applications will
>>potentially no longer deploy. I think it is perfectly reasonable to
>>publish this kind of information somewhere.
>>
>> My question is simply: In this open source environment, how do we
>>publish changes to defaults from build to build when they are NOT bugs,
>>but simply new design choices.
>>
>>-Tom
>>
>>
>>Marina Vatkina wrote:
>>
>>
>>
>>>Hi Tom,
>>>
>>>Are you concerned that throwing an exception when we should, instead
>>>of ignoring
>>>it will as we do today, will cause some users to clean up their
>>>applications?
>>>
>>>thanks,
>>>-marina
>>>
>>>Tom Ware wrote:
>>>
>>>
>>>
>>>
>>>>Hi Sahoo,
>>>>
>>>>I am, in principal, ok with changing the default.
>>>>
>>>>Here is a more general question. If we decide to change a default
>>>>like this (that could affect backward compatibility for some users).
>>>>How do we notify them? To me, just closing the issue is not really
>>>>adequate in the case were we are making a conscious choice to change
>>>>behavior rather than fixing something that is clearly a bug.
>>>>
>>>>-Tom
>>>>
>>>>Sanjeeb Kumar Sahoo wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi Tom,
>>>>>
>>>>>Tom Ware wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi Sahoo,
>>>>>>
>>>>>>Choosing to just warn for an orm.xml file that does not exist was a
>>>>>>design choice. I think both the current behavior and the behavior
>>>>>>you are suggesting are quite reasonable.
>>>>>>We initially chose to only send a warning to allow developers to
>>>>>>continue to work with their persistence unit even if there were
>>>>>>some errors in some of the files. Changing the value
>>>>>>toplink.orm.throw.exceptions should allow the exceptions to
>>>>>>actually be thrown. Is simply documenting this property adequate
>>>>>>to fix this issue?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>No. I think, we should change the default (see further explanation
>>>>>given below) in addition to documenting the property.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Is there any particular reason why we are choosing to change this
>>>>>>default?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>More often than not, an application will run into some kind of
>>>>>trouble if a mapping file is not processed. The submitter of issue
>>>>>#1051 also wants us to throw exception. I support him, because we
>>>>>both wasted 15 to 20 minutes before we found out the typo in mapping
>>>>>file name. Given the number of messages that get logged, it is very
>>>>>easy to miss a warning. Why would a (real) developer ever want to
>>>>>specify a non-existent mapping file? So I think, throwing an
>>>>>exception is a more developer friendly choice.
>>>>>
>>>>>So, let me know if I can change the default behavior or not. I would
>>>>>also like to know what others think.
>>>>>
>>>>>Thanks,
>>>>>Sahoo
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-Tom
>>>>>>
>>>>>>Sanjeeb Kumar Sahoo wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Hi Tom,
>>>>>>>
>>>>>>>I am working on
>>>>>>>https://glassfish.dev.java.net/issues/show_bug.cgi?id=1051. The
>>>>>>>current behavior is to log a message when mapping file does not
>>>>>>>exist. I am planning to change it to throw an exception by
>>>>>>>default, but I see some entity-persistence-tests failing as they
>>>>>>>specifically test for the current behavior. The persistence.xml
>>>>>>>has such text:
>>>>>>><!-- this is here for testing purposes - ensures a persistence
>>>>>>>unit can load even with a file that does not exist. Please do not
>>>>>>>add an xml file called: META-INF/non-existant-orm-file.xml -->
>>>>>>>
>>>>>>><mapping-file>META-INF/non-existant-orm-file.xml</mapping-file>
>>>>>>>
>>>>>>>Is there a specific reason behind the current behavior? Can we
>>>>>>>change it?
>>>>>>>
>>>>>>>Also, what's this property called toplink.orm.throw.exceptions? I
>>>>>>>don't find any documentation for this property. It is used in
>>>>>>>current code.
>>>>>>>
>>>>>>>Thanks,
>>>>>>>Sahoo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>