You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Karl-Philipp Richter <kr...@aol.de> on 2013/12/26 20:09:13 UTC
error message review
Hi together,
from today on I get the following error message and stack trace:
<output>
java.lang.IllegalArgumentException: URI is not absolute
at java.net.URI.toURL(URI.java:1095)
at
org.apache.openejb.config.PersistenceUnitLinkResolver.extractWebApp(PersistenceUnitLinkResolver.java:112)
at
org.apache.openejb.config.PersistenceUnitLinkResolver.tryToResolveForEar(PersistenceUnitLinkResolver.java:46)
at org.apache.openejb.util.LinkResolver.resolveLink(LinkResolver.java:93)
at
org.apache.openejb.util.UniqueDefaultLinkResolver.resolveLink(UniqueDefaultLinkResolver.java:32)
at
org.apache.openejb.config.AutoConfig.processPersistenceRef(AutoConfig.java:269)
at
org.apache.openejb.config.AutoConfig.processPersistenceRefs(AutoConfig.java:254)
at
org.apache.openejb.config.AutoConfig.resolvePersistenceRefs(AutoConfig.java:237)
at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
at
org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:396)
at
org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:938)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.checkHost(TomcatWebAppBuilder.java:1954)
at
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
at java.lang.Thread.run(Thread.java:744)
</output>
Independent from the error and its resolution (!! -> I'm not asking for
help on the issue) I'd like to suggest a review on error messages and
take this for an example what could be changed:
- print the URI which caused the exception
- if java.net.URI.toURL is invoked it is clear in the code which URI is
parsed, so the error message/cause might include information where the
URI is taken from, etc.
The first example takes no efforts at all (just one reference to the URI
object in a good class architecture), the second one needs one
try-catch-block and 10, maybe 15, words in a string literal without any
testing. The improvement of user experience in both cases is
indescribable :)
Regards,
Karl
Re: error message review
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Yes, this or a project reproducing the issue.
Le 28 déc. 2013 07:28, "Karl-Philipp Richter" <kr...@aol.de> a écrit :
> I guess it's more useful if I provide patches or ask questions about
> concrete code directly if I find the time
>
> On 27.12.2013 23:28, Romain Manni-Bucau wrote:
> > I just asked a test to check what we can do on our side ;)
> >
> > Ps: if i browse correctly the code you deploy multiple times in the same
> > ear persistence units with the same name
> > Le 27 déc. 2013 22:48, "Karl-Philipp Richter" <kr...@aol.de> a
> écrit :
> >
> >> Hi,
> >> Great, thanks for the fix! The error handling was exactly my case, I was
> >> just abstractly referring to any error handling of the same (in my
> >> opinion suboptimal) kind. I don't know so far what the concrete issue
> >> is, but now (thanks to the fix) I can investigate.
> >> In my opinion catching unexpected exceptions (i.e. exception which are
> >> not requested to be thrown by the software specification) and
> >> associating a cause and info about the context of the occurrence (by
> >> using exception properties or logging it) doesn't need regression
> >> testing because it doesn't change the program flow - the exception would
> >> be thrown anyway, just without a hint about the cause.
> >>
> >> Kind regards,
> >> Karl-P. R.
> >>
> >> On 27.12.2013 07:58, Romain Manni-Bucau wrote:
> >>> Hi
> >>>
> >>> added the uri in the log:
> >> https://issues.apache.org/jira/browse/TOMEE-1100
> >>>
> >>> btw would be great to know what is the issue, I enhanced a bit the
> >>> error handling but not sure that's your case.
> >>> Romain Manni-Bucau
> >>> Twitter: @rmannibucau
> >>> Blog: http://rmannibucau.wordpress.com/
> >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>> Github: https://github.com/rmannibucau
> >>>
> >>>
> >>>
> >>> 2013/12/26 Romain Manni-Bucau <rm...@gmail.com>:
> >>>> Hi,
> >>>>
> >>>> Are you able to provide us a test to avoid regressions?
> >>>>
> >>>> Le 26 déc. 2013 20:09, "Karl-Philipp Richter" <kr...@aol.de> a
> >> écrit :
> >>>>
> >>>>> Hi together,
> >>>>> from today on I get the following error message and stack trace:
> >>>>> <output>
> >>>>> java.lang.IllegalArgumentException: URI is not absolute
> >>>>> at java.net.URI.toURL(URI.java:1095)
> >>>>> at
> >>>>>
> >>>>>
> >>
> org.apache.openejb.config.PersistenceUnitLinkResolver.extractWebApp(PersistenceUnitLinkResolver.java:112)
> >>>>> at
> >>>>>
> >>>>>
> >>
> org.apache.openejb.config.PersistenceUnitLinkResolver.tryToResolveForEar(PersistenceUnitLinkResolver.java:46)
> >>>>> at
> >>>>>
> org.apache.openejb.util.LinkResolver.resolveLink(LinkResolver.java:93)
> >>>>> at
> >>>>>
> >>>>>
> >>
> org.apache.openejb.util.UniqueDefaultLinkResolver.resolveLink(UniqueDefaultLinkResolver.java:32)
> >>>>> at
> >>>>>
> >>>>>
> >>
> org.apache.openejb.config.AutoConfig.processPersistenceRef(AutoConfig.java:269)
> >>>>> at
> >>>>>
> >>>>>
> >>
> org.apache.openejb.config.AutoConfig.processPersistenceRefs(AutoConfig.java:254)
> >>>>> at
> >>>>>
> >>>>>
> >>
> org.apache.openejb.config.AutoConfig.resolvePersistenceRefs(AutoConfig.java:237)
> >>>>> at
> >>>>> org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
> >>>>> at
> >>>>>
> >>>>>
> >>
> org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:396)
> >>>>> at
> >>>>>
> >>>>>
> >>
> org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:938)
> >>>>> at
> >>>>>
> >>>>>
> >>
> org.apache.tomee.catalina.TomcatWebAppBuilder.checkHost(TomcatWebAppBuilder.java:1954)
> >>>>> at
> >>>>>
> >>>>>
> >>
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
> >>>>> at
> >>>>>
> >>>>>
> >>
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
> >>>>> at
> >>>>>
> >>>>>
> >>
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
> >>>>> at
> >>>>>
> >>>>>
> >>
> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374)
> >>>>> at
> >>>>>
> >>>>>
> >>
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
> >>>>> at
> >>>>>
> >>>>>
> >>
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
> >>>>> at
> >>>>>
> >>>>>
> >>
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
> >>>>> at java.lang.Thread.run(Thread.java:744)
> >>>>> </output>
> >>>>> Independent from the error and its resolution (!! -> I'm not asking
> for
> >>>>> help on the issue) I'd like to suggest a review on error messages and
> >>>>> take this for an example what could be changed:
> >>>>> - print the URI which caused the exception
> >>>>> - if java.net.URI.toURL is invoked it is clear in the code which URI
> is
> >>>>> parsed, so the error message/cause might include information where
> the
> >>>>> URI is taken from, etc.
> >>>>> The first example takes no efforts at all (just one reference to the
> >> URI
> >>>>> object in a good class architecture), the second one needs one
> >>>>> try-catch-block and 10, maybe 15, words in a string literal without
> any
> >>>>> testing. The improvement of user experience in both cases is
> >>>>> indescribable :)
> >>>>>
> >>>>> Regards,
> >>>>> Karl
> >>>>>
> >>>>
> >>
> >>
> >
>
>
Re: error message review
Posted by Karl-Philipp Richter <kr...@aol.de>.
I guess it's more useful if I provide patches or ask questions about
concrete code directly if I find the time
On 27.12.2013 23:28, Romain Manni-Bucau wrote:
> I just asked a test to check what we can do on our side ;)
>
> Ps: if i browse correctly the code you deploy multiple times in the same
> ear persistence units with the same name
> Le 27 déc. 2013 22:48, "Karl-Philipp Richter" <kr...@aol.de> a écrit :
>
>> Hi,
>> Great, thanks for the fix! The error handling was exactly my case, I was
>> just abstractly referring to any error handling of the same (in my
>> opinion suboptimal) kind. I don't know so far what the concrete issue
>> is, but now (thanks to the fix) I can investigate.
>> In my opinion catching unexpected exceptions (i.e. exception which are
>> not requested to be thrown by the software specification) and
>> associating a cause and info about the context of the occurrence (by
>> using exception properties or logging it) doesn't need regression
>> testing because it doesn't change the program flow - the exception would
>> be thrown anyway, just without a hint about the cause.
>>
>> Kind regards,
>> Karl-P. R.
>>
>> On 27.12.2013 07:58, Romain Manni-Bucau wrote:
>>> Hi
>>>
>>> added the uri in the log:
>> https://issues.apache.org/jira/browse/TOMEE-1100
>>>
>>> btw would be great to know what is the issue, I enhanced a bit the
>>> error handling but not sure that's your case.
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>>
>>>
>>>
>>> 2013/12/26 Romain Manni-Bucau <rm...@gmail.com>:
>>>> Hi,
>>>>
>>>> Are you able to provide us a test to avoid regressions?
>>>>
>>>> Le 26 déc. 2013 20:09, "Karl-Philipp Richter" <kr...@aol.de> a
>> écrit :
>>>>
>>>>> Hi together,
>>>>> from today on I get the following error message and stack trace:
>>>>> <output>
>>>>> java.lang.IllegalArgumentException: URI is not absolute
>>>>> at java.net.URI.toURL(URI.java:1095)
>>>>> at
>>>>>
>>>>>
>> org.apache.openejb.config.PersistenceUnitLinkResolver.extractWebApp(PersistenceUnitLinkResolver.java:112)
>>>>> at
>>>>>
>>>>>
>> org.apache.openejb.config.PersistenceUnitLinkResolver.tryToResolveForEar(PersistenceUnitLinkResolver.java:46)
>>>>> at
>>>>> org.apache.openejb.util.LinkResolver.resolveLink(LinkResolver.java:93)
>>>>> at
>>>>>
>>>>>
>> org.apache.openejb.util.UniqueDefaultLinkResolver.resolveLink(UniqueDefaultLinkResolver.java:32)
>>>>> at
>>>>>
>>>>>
>> org.apache.openejb.config.AutoConfig.processPersistenceRef(AutoConfig.java:269)
>>>>> at
>>>>>
>>>>>
>> org.apache.openejb.config.AutoConfig.processPersistenceRefs(AutoConfig.java:254)
>>>>> at
>>>>>
>>>>>
>> org.apache.openejb.config.AutoConfig.resolvePersistenceRefs(AutoConfig.java:237)
>>>>> at
>>>>> org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
>>>>> at
>>>>>
>>>>>
>> org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:396)
>>>>> at
>>>>>
>>>>>
>> org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:938)
>>>>> at
>>>>>
>>>>>
>> org.apache.tomee.catalina.TomcatWebAppBuilder.checkHost(TomcatWebAppBuilder.java:1954)
>>>>> at
>>>>>
>>>>>
>> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
>>>>> at
>>>>>
>>>>>
>> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
>>>>> at
>>>>>
>>>>>
>> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
>>>>> at
>>>>>
>>>>>
>> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374)
>>>>> at
>>>>>
>>>>>
>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
>>>>> at
>>>>>
>>>>>
>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
>>>>> at
>>>>>
>>>>>
>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
>>>>> at java.lang.Thread.run(Thread.java:744)
>>>>> </output>
>>>>> Independent from the error and its resolution (!! -> I'm not asking for
>>>>> help on the issue) I'd like to suggest a review on error messages and
>>>>> take this for an example what could be changed:
>>>>> - print the URI which caused the exception
>>>>> - if java.net.URI.toURL is invoked it is clear in the code which URI is
>>>>> parsed, so the error message/cause might include information where the
>>>>> URI is taken from, etc.
>>>>> The first example takes no efforts at all (just one reference to the
>> URI
>>>>> object in a good class architecture), the second one needs one
>>>>> try-catch-block and 10, maybe 15, words in a string literal without any
>>>>> testing. The improvement of user experience in both cases is
>>>>> indescribable :)
>>>>>
>>>>> Regards,
>>>>> Karl
>>>>>
>>>>
>>
>>
>
Re: error message review
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I just asked a test to check what we can do on our side ;)
Ps: if i browse correctly the code you deploy multiple times in the same
ear persistence units with the same name
Le 27 déc. 2013 22:48, "Karl-Philipp Richter" <kr...@aol.de> a écrit :
> Hi,
> Great, thanks for the fix! The error handling was exactly my case, I was
> just abstractly referring to any error handling of the same (in my
> opinion suboptimal) kind. I don't know so far what the concrete issue
> is, but now (thanks to the fix) I can investigate.
> In my opinion catching unexpected exceptions (i.e. exception which are
> not requested to be thrown by the software specification) and
> associating a cause and info about the context of the occurrence (by
> using exception properties or logging it) doesn't need regression
> testing because it doesn't change the program flow - the exception would
> be thrown anyway, just without a hint about the cause.
>
> Kind regards,
> Karl-P. R.
>
> On 27.12.2013 07:58, Romain Manni-Bucau wrote:
> > Hi
> >
> > added the uri in the log:
> https://issues.apache.org/jira/browse/TOMEE-1100
> >
> > btw would be great to know what is the issue, I enhanced a bit the
> > error handling but not sure that's your case.
> > Romain Manni-Bucau
> > Twitter: @rmannibucau
> > Blog: http://rmannibucau.wordpress.com/
> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > Github: https://github.com/rmannibucau
> >
> >
> >
> > 2013/12/26 Romain Manni-Bucau <rm...@gmail.com>:
> >> Hi,
> >>
> >> Are you able to provide us a test to avoid regressions?
> >>
> >> Le 26 déc. 2013 20:09, "Karl-Philipp Richter" <kr...@aol.de> a
> écrit :
> >>
> >>> Hi together,
> >>> from today on I get the following error message and stack trace:
> >>> <output>
> >>> java.lang.IllegalArgumentException: URI is not absolute
> >>> at java.net.URI.toURL(URI.java:1095)
> >>> at
> >>>
> >>>
> org.apache.openejb.config.PersistenceUnitLinkResolver.extractWebApp(PersistenceUnitLinkResolver.java:112)
> >>> at
> >>>
> >>>
> org.apache.openejb.config.PersistenceUnitLinkResolver.tryToResolveForEar(PersistenceUnitLinkResolver.java:46)
> >>> at
> >>> org.apache.openejb.util.LinkResolver.resolveLink(LinkResolver.java:93)
> >>> at
> >>>
> >>>
> org.apache.openejb.util.UniqueDefaultLinkResolver.resolveLink(UniqueDefaultLinkResolver.java:32)
> >>> at
> >>>
> >>>
> org.apache.openejb.config.AutoConfig.processPersistenceRef(AutoConfig.java:269)
> >>> at
> >>>
> >>>
> org.apache.openejb.config.AutoConfig.processPersistenceRefs(AutoConfig.java:254)
> >>> at
> >>>
> >>>
> org.apache.openejb.config.AutoConfig.resolvePersistenceRefs(AutoConfig.java:237)
> >>> at
> >>> org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
> >>> at
> >>>
> >>>
> org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:396)
> >>> at
> >>>
> >>>
> org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:938)
> >>> at
> >>>
> >>>
> org.apache.tomee.catalina.TomcatWebAppBuilder.checkHost(TomcatWebAppBuilder.java:1954)
> >>> at
> >>>
> >>>
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
> >>> at
> >>>
> >>>
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
> >>> at
> >>>
> >>>
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
> >>> at
> >>>
> >>>
> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374)
> >>> at
> >>>
> >>>
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
> >>> at
> >>>
> >>>
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
> >>> at
> >>>
> >>>
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
> >>> at java.lang.Thread.run(Thread.java:744)
> >>> </output>
> >>> Independent from the error and its resolution (!! -> I'm not asking for
> >>> help on the issue) I'd like to suggest a review on error messages and
> >>> take this for an example what could be changed:
> >>> - print the URI which caused the exception
> >>> - if java.net.URI.toURL is invoked it is clear in the code which URI is
> >>> parsed, so the error message/cause might include information where the
> >>> URI is taken from, etc.
> >>> The first example takes no efforts at all (just one reference to the
> URI
> >>> object in a good class architecture), the second one needs one
> >>> try-catch-block and 10, maybe 15, words in a string literal without any
> >>> testing. The improvement of user experience in both cases is
> >>> indescribable :)
> >>>
> >>> Regards,
> >>> Karl
> >>>
> >>
>
>
Re: error message review
Posted by Karl-Philipp Richter <kr...@aol.de>.
Hi,
Great, thanks for the fix! The error handling was exactly my case, I was
just abstractly referring to any error handling of the same (in my
opinion suboptimal) kind. I don't know so far what the concrete issue
is, but now (thanks to the fix) I can investigate.
In my opinion catching unexpected exceptions (i.e. exception which are
not requested to be thrown by the software specification) and
associating a cause and info about the context of the occurrence (by
using exception properties or logging it) doesn't need regression
testing because it doesn't change the program flow - the exception would
be thrown anyway, just without a hint about the cause.
Kind regards,
Karl-P. R.
On 27.12.2013 07:58, Romain Manni-Bucau wrote:
> Hi
>
> added the uri in the log: https://issues.apache.org/jira/browse/TOMEE-1100
>
> btw would be great to know what is the issue, I enhanced a bit the
> error handling but not sure that's your case.
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/12/26 Romain Manni-Bucau <rm...@gmail.com>:
>> Hi,
>>
>> Are you able to provide us a test to avoid regressions?
>>
>> Le 26 déc. 2013 20:09, "Karl-Philipp Richter" <kr...@aol.de> a écrit :
>>
>>> Hi together,
>>> from today on I get the following error message and stack trace:
>>> <output>
>>> java.lang.IllegalArgumentException: URI is not absolute
>>> at java.net.URI.toURL(URI.java:1095)
>>> at
>>>
>>> org.apache.openejb.config.PersistenceUnitLinkResolver.extractWebApp(PersistenceUnitLinkResolver.java:112)
>>> at
>>>
>>> org.apache.openejb.config.PersistenceUnitLinkResolver.tryToResolveForEar(PersistenceUnitLinkResolver.java:46)
>>> at
>>> org.apache.openejb.util.LinkResolver.resolveLink(LinkResolver.java:93)
>>> at
>>>
>>> org.apache.openejb.util.UniqueDefaultLinkResolver.resolveLink(UniqueDefaultLinkResolver.java:32)
>>> at
>>>
>>> org.apache.openejb.config.AutoConfig.processPersistenceRef(AutoConfig.java:269)
>>> at
>>>
>>> org.apache.openejb.config.AutoConfig.processPersistenceRefs(AutoConfig.java:254)
>>> at
>>>
>>> org.apache.openejb.config.AutoConfig.resolvePersistenceRefs(AutoConfig.java:237)
>>> at
>>> org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
>>> at
>>>
>>> org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:396)
>>> at
>>>
>>> org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:938)
>>> at
>>>
>>> org.apache.tomee.catalina.TomcatWebAppBuilder.checkHost(TomcatWebAppBuilder.java:1954)
>>> at
>>>
>>> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
>>> at
>>>
>>> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
>>> at
>>>
>>> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
>>> at
>>>
>>> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374)
>>> at
>>>
>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
>>> at
>>>
>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
>>> at
>>>
>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
>>> at java.lang.Thread.run(Thread.java:744)
>>> </output>
>>> Independent from the error and its resolution (!! -> I'm not asking for
>>> help on the issue) I'd like to suggest a review on error messages and
>>> take this for an example what could be changed:
>>> - print the URI which caused the exception
>>> - if java.net.URI.toURL is invoked it is clear in the code which URI is
>>> parsed, so the error message/cause might include information where the
>>> URI is taken from, etc.
>>> The first example takes no efforts at all (just one reference to the URI
>>> object in a good class architecture), the second one needs one
>>> try-catch-block and 10, maybe 15, words in a string literal without any
>>> testing. The improvement of user experience in both cases is
>>> indescribable :)
>>>
>>> Regards,
>>> Karl
>>>
>>
Re: error message review
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
added the uri in the log: https://issues.apache.org/jira/browse/TOMEE-1100
btw would be great to know what is the issue, I enhanced a bit the
error handling but not sure that's your case.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/12/26 Romain Manni-Bucau <rm...@gmail.com>:
> Hi,
>
> Are you able to provide us a test to avoid regressions?
>
> Le 26 déc. 2013 20:09, "Karl-Philipp Richter" <kr...@aol.de> a écrit :
>
>> Hi together,
>> from today on I get the following error message and stack trace:
>> <output>
>> java.lang.IllegalArgumentException: URI is not absolute
>> at java.net.URI.toURL(URI.java:1095)
>> at
>>
>> org.apache.openejb.config.PersistenceUnitLinkResolver.extractWebApp(PersistenceUnitLinkResolver.java:112)
>> at
>>
>> org.apache.openejb.config.PersistenceUnitLinkResolver.tryToResolveForEar(PersistenceUnitLinkResolver.java:46)
>> at
>> org.apache.openejb.util.LinkResolver.resolveLink(LinkResolver.java:93)
>> at
>>
>> org.apache.openejb.util.UniqueDefaultLinkResolver.resolveLink(UniqueDefaultLinkResolver.java:32)
>> at
>>
>> org.apache.openejb.config.AutoConfig.processPersistenceRef(AutoConfig.java:269)
>> at
>>
>> org.apache.openejb.config.AutoConfig.processPersistenceRefs(AutoConfig.java:254)
>> at
>>
>> org.apache.openejb.config.AutoConfig.resolvePersistenceRefs(AutoConfig.java:237)
>> at
>> org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
>> at
>>
>> org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:396)
>> at
>>
>> org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:938)
>> at
>>
>> org.apache.tomee.catalina.TomcatWebAppBuilder.checkHost(TomcatWebAppBuilder.java:1954)
>> at
>>
>> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
>> at
>>
>> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
>> at
>>
>> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
>> at
>>
>> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374)
>> at
>>
>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
>> at
>>
>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
>> at
>>
>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
>> at java.lang.Thread.run(Thread.java:744)
>> </output>
>> Independent from the error and its resolution (!! -> I'm not asking for
>> help on the issue) I'd like to suggest a review on error messages and
>> take this for an example what could be changed:
>> - print the URI which caused the exception
>> - if java.net.URI.toURL is invoked it is clear in the code which URI is
>> parsed, so the error message/cause might include information where the
>> URI is taken from, etc.
>> The first example takes no efforts at all (just one reference to the URI
>> object in a good class architecture), the second one needs one
>> try-catch-block and 10, maybe 15, words in a string literal without any
>> testing. The improvement of user experience in both cases is
>> indescribable :)
>>
>> Regards,
>> Karl
>>
>
Re: error message review
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
Are you able to provide us a test to avoid regressions?
Le 26 déc. 2013 20:09, "Karl-Philipp Richter" <kr...@aol.de> a écrit :
> Hi together,
> from today on I get the following error message and stack trace:
> <output>
> java.lang.IllegalArgumentException: URI is not absolute
> at java.net.URI.toURL(URI.java:1095)
> at
>
> org.apache.openejb.config.PersistenceUnitLinkResolver.extractWebApp(PersistenceUnitLinkResolver.java:112)
> at
>
> org.apache.openejb.config.PersistenceUnitLinkResolver.tryToResolveForEar(PersistenceUnitLinkResolver.java:46)
> at
> org.apache.openejb.util.LinkResolver.resolveLink(LinkResolver.java:93)
> at
>
> org.apache.openejb.util.UniqueDefaultLinkResolver.resolveLink(UniqueDefaultLinkResolver.java:32)
> at
>
> org.apache.openejb.config.AutoConfig.processPersistenceRef(AutoConfig.java:269)
> at
>
> org.apache.openejb.config.AutoConfig.processPersistenceRefs(AutoConfig.java:254)
> at
>
> org.apache.openejb.config.AutoConfig.resolvePersistenceRefs(AutoConfig.java:237)
> at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
> at
>
> org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:396)
> at
>
> org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:938)
> at
>
> org.apache.tomee.catalina.TomcatWebAppBuilder.checkHost(TomcatWebAppBuilder.java:1954)
> at
>
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
> at
>
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
> at
>
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
> at
>
> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374)
> at
>
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
> at
>
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
> at
>
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
> at java.lang.Thread.run(Thread.java:744)
> </output>
> Independent from the error and its resolution (!! -> I'm not asking for
> help on the issue) I'd like to suggest a review on error messages and
> take this for an example what could be changed:
> - print the URI which caused the exception
> - if java.net.URI.toURL is invoked it is clear in the code which URI is
> parsed, so the error message/cause might include information where the
> URI is taken from, etc.
> The first example takes no efforts at all (just one reference to the URI
> object in a good class architecture), the second one needs one
> try-catch-block and 10, maybe 15, words in a string literal without any
> testing. The improvement of user experience in both cases is
> indescribable :)
>
> Regards,
> Karl
>
>