Yes, or changing the API to declare them as checked exceptions :) Cheers,
David On 23 November 2011 11:14, Timothy Ward <[email protected]> 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: [email protected] >> Date: Wed, 23 Nov 2011 10:42:57 +0000 >> Subject: Re: org.apache.aries.util and slf4j >> To: [email protected] >> >> 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 <[email protected]> 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: [email protected] >> >> Date: Tue, 22 Nov 2011 15:33:30 +0000 >> >> Subject: org.apache.aries.util and slf4j >> >> To: [email protected] >> >> >> >> 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 >> > >
