I've gone ahead and made the change in the datatypes registry to use log.debu 
instead of log.warning, so hopefully this issue is resolved.  The changeset in 
central is 12497:0b0018fa5d20, which has also be grafted to stable.

Greg Von Kuster

On Feb 13, 2014, at 11:51 AM, Jim Johnson <johns...@umn.edu> wrote:

> On 2/13/14, 10:22 AM, Greg Von Kuster wrote:
>> Hi JJ,
>> 
>> On Feb 13, 2014, at 11:00 AM, Jim Johnson <johns...@umn.edu> wrote:
>> 
>>> I now have 2 versions of snpeff installed from the toolshed on my galaxy 
>>> server.
>>> Each snpeff version includes an identical datatypes_conf.xml
>>> The galaxy server is setting metadata externally.
>>> 
>>> When any job runs, (in may case I was running a picard tool), the following 
>>> message is written to the job stderr:
>>> WARNING:galaxy.datatypes.registry:Overriding conflicting datatype with 
>>> extension 'snpeffdb', using datatype from /galaxy/database/tmp/tmpdKGVnQ.
>>> Without stdio tags or otherwise catching the stderr, the job state is set 
>>> to error.
>> I believe I'm responsible for the above warning message, but I'm not sure I 
>> like the resulting behavior - I wasn't aware that the job runner now 
>> captures warning messages like this and sets the job state to error.  At the 
>> time I enhance the Galaxy datatypes components to work with the Tool Shed, 
>> this was not the behavior.
>> 
>>> I'm now assuming that best practice would be to put the datatypes in a 
>>> separate toolshed repository that would be a dependency for the tools 
>>> repository.
>>> Thus the datatypes would not loaded multiple times and avoid overrride 
>>> conflicts.
>> Yes, the above plan would be a "best practice".
> Though I could still have some issues on my test galaxy instance,
> since I often have tools from both the toolshed and testtoolshed 
> simultaneously.
>> 
>>> In the meantime, I have just commented out the warning message.
>>> 
>>> Any other advice on this issue?
>> I'm wondering if we should just eliminate the warning message altogether 
>> sicne it now results in jobe errors.  Do others agree?
>> 
>>> Thanks,
>>> 
>>> JJ
>>>   -- 
>>> James E. Johnson, Minnesota Supercomputing Institute, University of 
>>> Minnesota
> Or we could move it to log.debug level, which wouldn't usually be set on a 
> production server.
> 
> JJ
> 
> -- 
> James E. Johnson, Minnesota Supercomputing Institute, University of Minnesota
> ___________________________________________________________
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
> http://lists.bx.psu.edu/
> 
> To search Galaxy mailing lists use the unified search at:
> http://galaxyproject.org/search/mailinglists/


___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  http://lists.bx.psu.edu/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Reply via email to