Tank you guys, equinox.ds.print=true was exactly what I was looking for. Now I get all the logs I was missing!!!
Regards, Eugen > On 2010-05-20, at 3:03 PM, Jeff McAffer wrote: > If you are using the Equinox implementation of DS try adding the system > property > equinox.ds.print=true > You get all manner of handy output. -consolelog is also useful in this. If > you run Equinox with -console then you can use commands like "ls" and "conf" > to investigate what's happening in DS land. > > Jeff > >> Hi Eugen, >> >> What the DS specification specifies for these cases is the usage of >> org.osgi.service.log.LogService. If you have this service registered, SCR >> has to use it to log detected errors. Reading the logged errors might be an >> issue though. Depending on the LogService implementation, the log may be >> stored in a file or not. You can observe the log programmatically using the >> LogReaderService but this is not convenient. >> >> On the other hand the DS implementations might have additional settings for >> turning on their debug so you can easily see these errors in the console. >> For instance the Equinox DS bundle has trace options or system properties >> that may be used for that purpose. The system property for enabling the >> printing of errors in the console is "equinox.ds.print=true". >> >> Regards, >> Stoyan > > On 2010-05-20, at 8:59 AM, Peter Kriens wrote: > >> :-) Look in the OSGi log ... There are extensive logs of anything that goes >> wrong with DS. It is actually one of the attractive aspects of DS that you >> can just throw an exception when you do not like something, being sure that >> it gets logged by DS. >> >> Kind regards, >> >> Peter Kriens >> >> >> On 20 mei 2010, at 12:59, Eugen Reiswich wrote: >> >>> Hi, >>> >>> I am using now declarative services for a while and I really like the idea >>> of avoiding all that boiler plate ServiceTracker code. But what really >>> frustrates me is that I don't get any feedback (e.g. exceptions) when I >>> misspell my bind and unbind service methods or when I accidentally use the >>> same service component id for several components. In this case the service >>> components either do not start or do not behave as expected. At the same >>> time as developer I don't get any feedback what might be wrong. Is there >>> any "verbose" mode for OSGi declarative services or could this be an >>> eclipse preference problem? Any hint would be appreciated! >>> >>> Regards, >>> Eugen >>> _______________________________________________ >>> OSGi Developer Mail List >>> osgi-dev@mail.osgi.org >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
