You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by David Bosschaert <da...@gmail.com> on 2011/11/22 16:33:30 UTC
org.apache.aries.util and slf4j
Hi all,
I'm depending on a class from org.apache.aries.util in the SPI-Fly
component (the ManifestHeaderProcessor) and I noticed that
org.apache.aries.util has started depending on SLF4J since version
0.4. This dependency wasn't there in 0.3 and I would like to ask to
make it an optional dependency as it's not used generally and it drags
in a transitive dependency for me that I don't need. I noticed that
many imports in org.apache.aries.util are marked as optional but this
one isn't. Was that an oversight?
Bundle-SymbolicName: org.apache.aries.util
Import-Package: org.eclipse.osgi.framework.adaptor;resolution:=optiona
l,org.eclipse.osgi.framework.internal.core;resolution:=optional,org.e
clipse.osgi.internal.loader;resolution:=optional,org.osgi.framework;v
ersion="[1.5,2)",org.osgi.framework.hooks.bundle;resolution:=optional
;version="[1.0,2)",org.osgi.framework.launch;resolution:=optional;ver
sion="[1.0,2)",org.osgi.framework.wiring;resolution:=optional;version
="[1.0,2)",org.osgi.service.framework;resolution:=optional;version="[
1.0,2)",org.osgi.util.tracker;version="[1.4,2)",org.slf4j;version="[1
.5,2)"
Thanks,
David
Re: org.apache.aries.util and slf4j
Posted by David Bosschaert <da...@gmail.com>.
Ok - in r1205919 I've changed the slf4j.log("IOException: ", ioe)
lines into throw new IORuntimeExcepton(ioe) calls.
And I've removed the SLF4J dependency from util.
Couple of things to note:
* I noticed that a variety of coding styles were used, sometimes even
within a single file. 2 spaces, 4 spaces seem to be intermingled
across the util component (and maybe beyond?). Also the position of
the curly braces is not clearly defined. I didn't do anything about it
in this commit, and tried to adapt as much as possible to whatever
seemed to be prevalent in the files I was editing, but I think it
would be good to get the Aries codebase to use a single coding style.
* My editor removes trailing spaces which makes the diff look busier
than it actually is. Maybe I need to tweak this...
* I keep getting these failures (osx lion JDK 1.6_26, also on a
non-modified trunk) so I ignored them:
in jndi/jndi-url-itest
Running org.apache.aries.jndi.itests.JndiUrlIntegrationTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
7.938 sec <<< FAILURE!
in samples/blog/blog-itests
Running org.apache.aries.samples.blog.itests.QuiesceBlogSampleWithEbaTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
5.253 sec <<< FAILURE!
Running org.apache.aries.samples.blog.itests.JdbcBlogSampleWithEbaTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
5.344 sec <<< FAILURE!
Cheers,
David
On 23 November 2011 11:20, David Bosschaert <da...@gmail.com> wrote:
> Yes, or changing the API to declare them as checked exceptions :)
>
> Cheers,
>
> David
>
> On 23 November 2011 11:14, Timothy Ward <ti...@apache.org> wrote:
>>
>> Hi David,
>>
>> Rethrowing them wrapped in a RuntimeException subclass might be an option. WDYT?
>>
>> Regards,
>>
>> Tim Ward
>> -------------------
>> Apache Aries PMC member & Enterprise OSGi advocate
>> Enterprise OSGi in Action (http://www.manning.com/cummins)
>> -------------------
>>
>>
>>> From: david.bosschaert@gmail.com
>>> Date: Wed, 23 Nov 2011 10:42:57 +0000
>>> Subject: Re: org.apache.aries.util and slf4j
>>> To: dev@aries.apache.org
>>>
>>> Hi Tim,
>>>
>>> Since these are all utility methods would it not make sense to rethrow
>>> any exceptions to the user and let them deal with it using whatever is
>>> the appropriate mechanism for their application?
>>>
>>> Not sure about silently dropping exceptions. This only makes sense if
>>> they are completely and totally harmless but I don't think that is the
>>> case here (it's rarely the case IMO)... I mean some of the methods
>>> here currently log an IOException to slf4j and then return null.
>>> Wouldn't that simply delay (and obscure) the actual problem that
>>> caused the exception in the first place?
>>>
>>> Cheers,
>>>
>>> David
>>>
>>> On 23 November 2011 09:59, Timothy Ward <ti...@apache.org> wrote:
>>> >
>>> > Hi David,
>>> >
>>> > It looks like the following classes:
>>> >
>>> > org.apache.aries.util.filesystem.impl.FileSystemImpl
>>> > org.apache.aries.util.filesystem.impl.NestedZipDirectory
>>> > org.apache.aries.util.filesystem.impl.ZipDirectory
>>> > org.apache.aries.util.filesystem.impl.ZipFileImpl
>>> > org.apache.aries.util.manifest.BundleManifest
>>> >
>>> > use SLF4J to log exceptions. These are things that have been moved to the more generic utils package from Application Utils (which was a good idea, they're now used by JPA, EJB and probably elsewhere). I'd be happy to see the dependency gone, although it also isn't a problem for me, but it would be nice not to just swallow any exceptions silently. Any thoughts?
>>> >
>>> > Regards
>>> >
>>> > Tim Ward
>>> > -------------------
>>> > Apache Aries PMC member & Enterprise OSGi advocate
>>> > Enterprise OSGi in Action (http://www.manning.com/cummins)
>>> > -------------------
>>> >
>>> >
>>> >> From: david.bosschaert@gmail.com
>>> >> Date: Tue, 22 Nov 2011 15:33:30 +0000
>>> >> Subject: org.apache.aries.util and slf4j
>>> >> To: aries-dev@incubator.apache.org
>>> >>
>>> >> Hi all,
>>> >>
>>> >> I'm depending on a class from org.apache.aries.util in the SPI-Fly
>>> >> component (the ManifestHeaderProcessor) and I noticed that
>>> >> org.apache.aries.util has started depending on SLF4J since version
>>> >> 0.4. This dependency wasn't there in 0.3 and I would like to ask to
>>> >> make it an optional dependency as it's not used generally and it drags
>>> >> in a transitive dependency for me that I don't need. I noticed that
>>> >> many imports in org.apache.aries.util are marked as optional but this
>>> >> one isn't. Was that an oversight?
>>> >>
>>> >> Bundle-SymbolicName: org.apache.aries.util
>>> >> Import-Package: org.eclipse.osgi.framework.adaptor;resolution:=optiona
>>> >> l,org.eclipse.osgi.framework.internal.core;resolution:=optional,org.e
>>> >> clipse.osgi.internal.loader;resolution:=optional,org.osgi.framework;v
>>> >> ersion="[1.5,2)",org.osgi.framework.hooks.bundle;resolution:=optional
>>> >> ;version="[1.0,2)",org.osgi.framework.launch;resolution:=optional;ver
>>> >> sion="[1.0,2)",org.osgi.framework.wiring;resolution:=optional;version
>>> >> ="[1.0,2)",org.osgi.service.framework;resolution:=optional;version="[
>>> >> 1.0,2)",org.osgi.util.tracker;version="[1.4,2)",org.slf4j;version="[1
>>> >> .5,2)"
>>> >>
>>> >> Thanks,
>>> >>
>>> >> David
>>> >
>>
>
Re: org.apache.aries.util and slf4j
Posted by David Bosschaert <da...@gmail.com>.
Yes, or changing the API to declare them as checked exceptions :)
Cheers,
David
On 23 November 2011 11:14, Timothy Ward <ti...@apache.org> wrote:
>
> Hi David,
>
> Rethrowing them wrapped in a RuntimeException subclass might be an option. WDYT?
>
> Regards,
>
> Tim Ward
> -------------------
> Apache Aries PMC member & Enterprise OSGi advocate
> Enterprise OSGi in Action (http://www.manning.com/cummins)
> -------------------
>
>
>> From: david.bosschaert@gmail.com
>> Date: Wed, 23 Nov 2011 10:42:57 +0000
>> Subject: Re: org.apache.aries.util and slf4j
>> To: dev@aries.apache.org
>>
>> Hi Tim,
>>
>> Since these are all utility methods would it not make sense to rethrow
>> any exceptions to the user and let them deal with it using whatever is
>> the appropriate mechanism for their application?
>>
>> Not sure about silently dropping exceptions. This only makes sense if
>> they are completely and totally harmless but I don't think that is the
>> case here (it's rarely the case IMO)... I mean some of the methods
>> here currently log an IOException to slf4j and then return null.
>> Wouldn't that simply delay (and obscure) the actual problem that
>> caused the exception in the first place?
>>
>> Cheers,
>>
>> David
>>
>> On 23 November 2011 09:59, Timothy Ward <ti...@apache.org> wrote:
>> >
>> > Hi David,
>> >
>> > It looks like the following classes:
>> >
>> > org.apache.aries.util.filesystem.impl.FileSystemImpl
>> > org.apache.aries.util.filesystem.impl.NestedZipDirectory
>> > org.apache.aries.util.filesystem.impl.ZipDirectory
>> > org.apache.aries.util.filesystem.impl.ZipFileImpl
>> > org.apache.aries.util.manifest.BundleManifest
>> >
>> > use SLF4J to log exceptions. These are things that have been moved to the more generic utils package from Application Utils (which was a good idea, they're now used by JPA, EJB and probably elsewhere). I'd be happy to see the dependency gone, although it also isn't a problem for me, but it would be nice not to just swallow any exceptions silently. Any thoughts?
>> >
>> > Regards
>> >
>> > Tim Ward
>> > -------------------
>> > Apache Aries PMC member & Enterprise OSGi advocate
>> > Enterprise OSGi in Action (http://www.manning.com/cummins)
>> > -------------------
>> >
>> >
>> >> From: david.bosschaert@gmail.com
>> >> Date: Tue, 22 Nov 2011 15:33:30 +0000
>> >> Subject: org.apache.aries.util and slf4j
>> >> To: aries-dev@incubator.apache.org
>> >>
>> >> Hi all,
>> >>
>> >> I'm depending on a class from org.apache.aries.util in the SPI-Fly
>> >> component (the ManifestHeaderProcessor) and I noticed that
>> >> org.apache.aries.util has started depending on SLF4J since version
>> >> 0.4. This dependency wasn't there in 0.3 and I would like to ask to
>> >> make it an optional dependency as it's not used generally and it drags
>> >> in a transitive dependency for me that I don't need. I noticed that
>> >> many imports in org.apache.aries.util are marked as optional but this
>> >> one isn't. Was that an oversight?
>> >>
>> >> Bundle-SymbolicName: org.apache.aries.util
>> >> Import-Package: org.eclipse.osgi.framework.adaptor;resolution:=optiona
>> >> l,org.eclipse.osgi.framework.internal.core;resolution:=optional,org.e
>> >> clipse.osgi.internal.loader;resolution:=optional,org.osgi.framework;v
>> >> ersion="[1.5,2)",org.osgi.framework.hooks.bundle;resolution:=optional
>> >> ;version="[1.0,2)",org.osgi.framework.launch;resolution:=optional;ver
>> >> sion="[1.0,2)",org.osgi.framework.wiring;resolution:=optional;version
>> >> ="[1.0,2)",org.osgi.service.framework;resolution:=optional;version="[
>> >> 1.0,2)",org.osgi.util.tracker;version="[1.4,2)",org.slf4j;version="[1
>> >> .5,2)"
>> >>
>> >> Thanks,
>> >>
>> >> David
>> >
>
RE: org.apache.aries.util and slf4j
Posted by Timothy Ward <ti...@apache.org>.
Hi David,
Rethrowing them wrapped in a RuntimeException subclass might be an option. WDYT?
Regards,
Tim Ward
-------------------
Apache Aries PMC member & Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
-------------------
> From: david.bosschaert@gmail.com
> Date: Wed, 23 Nov 2011 10:42:57 +0000
> Subject: Re: org.apache.aries.util and slf4j
> To: dev@aries.apache.org
>
> Hi Tim,
>
> Since these are all utility methods would it not make sense to rethrow
> any exceptions to the user and let them deal with it using whatever is
> the appropriate mechanism for their application?
>
> Not sure about silently dropping exceptions. This only makes sense if
> they are completely and totally harmless but I don't think that is the
> case here (it's rarely the case IMO)... I mean some of the methods
> here currently log an IOException to slf4j and then return null.
> Wouldn't that simply delay (and obscure) the actual problem that
> caused the exception in the first place?
>
> Cheers,
>
> David
>
> On 23 November 2011 09:59, Timothy Ward <ti...@apache.org> wrote:
> >
> > Hi David,
> >
> > It looks like the following classes:
> >
> > org.apache.aries.util.filesystem.impl.FileSystemImpl
> > org.apache.aries.util.filesystem.impl.NestedZipDirectory
> > org.apache.aries.util.filesystem.impl.ZipDirectory
> > org.apache.aries.util.filesystem.impl.ZipFileImpl
> > org.apache.aries.util.manifest.BundleManifest
> >
> > use SLF4J to log exceptions. These are things that have been moved to the more generic utils package from Application Utils (which was a good idea, they're now used by JPA, EJB and probably elsewhere). I'd be happy to see the dependency gone, although it also isn't a problem for me, but it would be nice not to just swallow any exceptions silently. Any thoughts?
> >
> > Regards
> >
> > Tim Ward
> > -------------------
> > Apache Aries PMC member & Enterprise OSGi advocate
> > Enterprise OSGi in Action (http://www.manning.com/cummins)
> > -------------------
> >
> >
> >> From: david.bosschaert@gmail.com
> >> Date: Tue, 22 Nov 2011 15:33:30 +0000
> >> Subject: org.apache.aries.util and slf4j
> >> To: aries-dev@incubator.apache.org
> >>
> >> Hi all,
> >>
> >> I'm depending on a class from org.apache.aries.util in the SPI-Fly
> >> component (the ManifestHeaderProcessor) and I noticed that
> >> org.apache.aries.util has started depending on SLF4J since version
> >> 0.4. This dependency wasn't there in 0.3 and I would like to ask to
> >> make it an optional dependency as it's not used generally and it drags
> >> in a transitive dependency for me that I don't need. I noticed that
> >> many imports in org.apache.aries.util are marked as optional but this
> >> one isn't. Was that an oversight?
> >>
> >> Bundle-SymbolicName: org.apache.aries.util
> >> Import-Package: org.eclipse.osgi.framework.adaptor;resolution:=optiona
> >> l,org.eclipse.osgi.framework.internal.core;resolution:=optional,org.e
> >> clipse.osgi.internal.loader;resolution:=optional,org.osgi.framework;v
> >> ersion="[1.5,2)",org.osgi.framework.hooks.bundle;resolution:=optional
> >> ;version="[1.0,2)",org.osgi.framework.launch;resolution:=optional;ver
> >> sion="[1.0,2)",org.osgi.framework.wiring;resolution:=optional;version
> >> ="[1.0,2)",org.osgi.service.framework;resolution:=optional;version="[
> >> 1.0,2)",org.osgi.util.tracker;version="[1.4,2)",org.slf4j;version="[1
> >> .5,2)"
> >>
> >> Thanks,
> >>
> >> David
> >
Re: org.apache.aries.util and slf4j
Posted by David Bosschaert <da...@gmail.com>.
Hi Tim,
Since these are all utility methods would it not make sense to rethrow
any exceptions to the user and let them deal with it using whatever is
the appropriate mechanism for their application?
Not sure about silently dropping exceptions. This only makes sense if
they are completely and totally harmless but I don't think that is the
case here (it's rarely the case IMO)... I mean some of the methods
here currently log an IOException to slf4j and then return null.
Wouldn't that simply delay (and obscure) the actual problem that
caused the exception in the first place?
Cheers,
David
On 23 November 2011 09:59, Timothy Ward <ti...@apache.org> wrote:
>
> Hi David,
>
> It looks like the following classes:
>
> org.apache.aries.util.filesystem.impl.FileSystemImpl
> org.apache.aries.util.filesystem.impl.NestedZipDirectory
> org.apache.aries.util.filesystem.impl.ZipDirectory
> org.apache.aries.util.filesystem.impl.ZipFileImpl
> org.apache.aries.util.manifest.BundleManifest
>
> use SLF4J to log exceptions. These are things that have been moved to the more generic utils package from Application Utils (which was a good idea, they're now used by JPA, EJB and probably elsewhere). I'd be happy to see the dependency gone, although it also isn't a problem for me, but it would be nice not to just swallow any exceptions silently. Any thoughts?
>
> Regards
>
> Tim Ward
> -------------------
> Apache Aries PMC member & Enterprise OSGi advocate
> Enterprise OSGi in Action (http://www.manning.com/cummins)
> -------------------
>
>
>> From: david.bosschaert@gmail.com
>> Date: Tue, 22 Nov 2011 15:33:30 +0000
>> Subject: org.apache.aries.util and slf4j
>> To: aries-dev@incubator.apache.org
>>
>> Hi all,
>>
>> I'm depending on a class from org.apache.aries.util in the SPI-Fly
>> component (the ManifestHeaderProcessor) and I noticed that
>> org.apache.aries.util has started depending on SLF4J since version
>> 0.4. This dependency wasn't there in 0.3 and I would like to ask to
>> make it an optional dependency as it's not used generally and it drags
>> in a transitive dependency for me that I don't need. I noticed that
>> many imports in org.apache.aries.util are marked as optional but this
>> one isn't. Was that an oversight?
>>
>> Bundle-SymbolicName: org.apache.aries.util
>> Import-Package: org.eclipse.osgi.framework.adaptor;resolution:=optiona
>> l,org.eclipse.osgi.framework.internal.core;resolution:=optional,org.e
>> clipse.osgi.internal.loader;resolution:=optional,org.osgi.framework;v
>> ersion="[1.5,2)",org.osgi.framework.hooks.bundle;resolution:=optional
>> ;version="[1.0,2)",org.osgi.framework.launch;resolution:=optional;ver
>> sion="[1.0,2)",org.osgi.framework.wiring;resolution:=optional;version
>> ="[1.0,2)",org.osgi.service.framework;resolution:=optional;version="[
>> 1.0,2)",org.osgi.util.tracker;version="[1.4,2)",org.slf4j;version="[1
>> .5,2)"
>>
>> Thanks,
>>
>> David
>
RE: org.apache.aries.util and slf4j
Posted by Timothy Ward <ti...@apache.org>.
Hi David,
It looks like the following classes:
org.apache.aries.util.filesystem.impl.FileSystemImpl
org.apache.aries.util.filesystem.impl.NestedZipDirectory
org.apache.aries.util.filesystem.impl.ZipDirectory
org.apache.aries.util.filesystem.impl.ZipFileImpl
org.apache.aries.util.manifest.BundleManifest
use SLF4J to log exceptions. These are things that have been moved to the more generic utils package from Application Utils (which was a good idea, they're now used by JPA, EJB and probably elsewhere). I'd be happy to see the dependency gone, although it also isn't a problem for me, but it would be nice not to just swallow any exceptions silently. Any thoughts?
Regards
Tim Ward
-------------------
Apache Aries PMC member & Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
-------------------
> From: david.bosschaert@gmail.com
> Date: Tue, 22 Nov 2011 15:33:30 +0000
> Subject: org.apache.aries.util and slf4j
> To: aries-dev@incubator.apache.org
>
> Hi all,
>
> I'm depending on a class from org.apache.aries.util in the SPI-Fly
> component (the ManifestHeaderProcessor) and I noticed that
> org.apache.aries.util has started depending on SLF4J since version
> 0.4. This dependency wasn't there in 0.3 and I would like to ask to
> make it an optional dependency as it's not used generally and it drags
> in a transitive dependency for me that I don't need. I noticed that
> many imports in org.apache.aries.util are marked as optional but this
> one isn't. Was that an oversight?
>
> Bundle-SymbolicName: org.apache.aries.util
> Import-Package: org.eclipse.osgi.framework.adaptor;resolution:=optiona
> l,org.eclipse.osgi.framework.internal.core;resolution:=optional,org.e
> clipse.osgi.internal.loader;resolution:=optional,org.osgi.framework;v
> ersion="[1.5,2)",org.osgi.framework.hooks.bundle;resolution:=optional
> ;version="[1.0,2)",org.osgi.framework.launch;resolution:=optional;ver
> sion="[1.0,2)",org.osgi.framework.wiring;resolution:=optional;version
> ="[1.0,2)",org.osgi.service.framework;resolution:=optional;version="[
> 1.0,2)",org.osgi.util.tracker;version="[1.4,2)",org.slf4j;version="[1
> .5,2)"
>
> Thanks,
>
> David