Jacques-Olivier Goussard wrote:
Granted, people shouldn't compile against felix.jar, and I wasn't
(thus my missing constant). However, felix provides the OSGi core interfaces
at runtime,
so all I was saying is that users must trust felix dev to always modify OSGi
interfaces
in a fully compatible way. Which I guess is not a big concern if you have
enough
test cases (and you hold your horses :)
At run-time bundles never really know which version of OSGi they will
run against (unless they limit their import range) since the interfaces
are backwards compatible (i.e, R3 bundles run on R4 frameworks, which
have lots of additional methods and constants). Felix could just as
easily break compatibility between R3 and R4, not to mention R4 and some
yet unreleased RX.
You are correct that the goal is to be backwards compatible for those
bundles compiled against older versions of the interfaces. Of course,
bugs will happen so no guarantees there, but we try. :-)
-> richard
/jog
On Thu, Dec 18, 2008 at 9:44 AM, Stuart McCulloch <[email protected]> wrote:
2008/12/18 Richard S. Hall <[email protected]>
Jacques-Olivier Goussard wrote:
Sounds cool to be cutting edge, and I don't mind using those features in
the
launcher, which is felix specific. But IMHO, that makes building
portable
bundles (between equinox and felix for ex) a bit more difficult - felix
users have
to trust felix dev to modify the OSGi base only in backward compatible
ways
...
On my side for ex, I was coding against the official osgi.core.jar so
didn't
get
this FRAMEWORK_STORAGE constant at compile time (which, again, is not
a big pb for this specific case).
Just my 2 cents, but I'd advocate to stick stricly to the spec and push
on
the
OSGi comitee separately - but you're in charge ;)
Actually, I debated how to go about introducing the constants (and some
additional interface), since I could also introduce them as Felix
constants
(or interfaces) and move them later. I thought that sounded like a pain,
so
I didn't do it. :-) The approach I took was to have Felix contain its own
modified versions of the interfaces.
However, in the typical case, a bundle should not include felix.jar on
its
build class path, since no bundle should depend on Felix. To compile,
bundle
should be using org.osgi.core.jar, which is 100% pure.
Perhaps it is not a perfect approach, but it didn't seem unreasonable
either.
this sounds fair to me - same with the new service registry hooks, it lets
people try out features before they're cast in stone without impacting
those
who compile against the released API
-> richard
/jog
On Wed, Dec 17, 2008 at 2:41 PM, Richard S. Hall <[email protected]
wrote:
Jacques-Olivier Goussard wrote:
Thanks I'm looking into this.
One thing I found in the code snippet for embedding Felix is a
reference
to
Constants.FRAMEWORK_STORAGE.
Is this an addition from Felix ? Looking at OSGi 4rev4.1 (
http://www.osgi.org/javadoc/r4v41/org/osgi/framework/Constants.html),
there is no such constant. Does felix actually ships with a modified
version
of the OSGi spec ??
Yes, it does. This is stuff being proposed for R4.2...cutting edge! ;-)
-> richard
/jog
On Wed, Dec 17, 2008 at 11:36 AM, Richard S. Hall <
[email protected]
wrote:
For a while we had Felix' Logger using a LogService instance if one
was
available, but this was leading to deadlocks since some logging was
occurring while holding locks and we cannot control what happens when
we
call out to a logger. As a result, we disabled this feature until it
can
be
resolved.
There is still a possibility to get Felix to use a different logger
by
passing a Logger instance into Felix' constructor via the
configuration
properties, but this would require you to create your own Felix
instance,
see the following link for the property description:
http://felix.apache.org/site/apache-felix-usage-documentation.html#ApacheFelixUsageDocumentation-configuringfelix
And the following link on how to launch Felix yourself:
http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html
-> richard
Jacques-Olivier Goussard wrote:
Hi
Does anybody have an idea about how to capture felix logging in a
file
?
The org.apache.felix.framework.Logger class disables LogService
logging
and
sends
everything to System.out.
The pb is that if felix is used as daemon (background server),
logging
is
lost.
I can redirect to a file, but I'd rather have all logging in one
place
(I
use log4j internally) and
inherit all the rollover and log appenders setup.
Any idea to workaround this ?
/jog
--
Cheers, Stuart
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
