felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <ben...@basistech.com>
Subject Re: An 'internal' package versus a system bundle
Date Tue, 23 Dec 2014 17:38:05 GMT
On Tue, Dec 23, 2014 at 10:49 AM, Andras Szerdahelyi <
andras.szerdahelyi@gmail.com> wrote:
>
> > I am using declarative services, but I do need a data model to pass
> > information into and out of the services.
>
>
> i think your fundamental problem here is you are making this model
> available to bundles via the system classpath. Export it ( preferably from
> your service api bundle and in its _entirety_; ie anything p imports (
> "uses" ) also needs to be available from somewhere.. ) and let the
> framework manage dependencies for you.
>

I have sorted this out, and I'll explain briefly so that I seem less of an
idiot.

I built a structure that works in two modes: either with everything inside
the container, or just using the container to isolate a collection of
components from the larger application classpath. This morning, I got my
wires crossed as to which sort of test I was writing.

In 'all in OSGi' mode, all my bundles get installed in the container,
nothing goes into the system bundle, it's all very boring.

In 'some in OSGi mode', there is a data model bundle that is not supposed
to be installed in the container  _at all_. I treat it as a plain old jar,
and it goes in the application's class path, and it gets added to the
system bundle. And everything works fine; when it makes use of its own
internal workings, they are out there in the application's class loader,
not in any bundle class loader.

My mistake this morning was to install this data model bundle into the
container, and that caused the fuss. I apologize for the bandwidth
consumption.





>
>
> I was expecting that q could be a private package. Could it be that I have
> > to explicitly declare 'q' as a Private-Package?
>
>
> if your build system is bnd, you'll need this directive in your bnd file
> for packages that are not exported or imported but should be present in the
> bundle. Otherwise IIRC, its not an actual OSGi manifest header line.
>
> But again, if exported package p imports classes from q, q needs to be made
> available ( exported ) from somewhere, so it has no business being
> "private"
>
>
> > On 23 December 2014 at 16:02, Benson Margulies <benson@basistech.com>
> > wrote:
> >
> On Tue, Dec 23, 2014 at 9:54 AM, Andras Szerdahelyi <
> > andras.szerdahelyi@gmail.com> wrote:
> > >
> > > Well, if exported package p imports from package q, my understanding is
> > > that q will need to be available ( imported ) wherever p is used ( "p
> > uses
> > > q" )
> > >
> >
> > I was expecting that q could be a private package. Could it be that I
> have
> > to explicitly declare 'q' as a Private-Package?
> >
> >
> >
> > >
> > > What state is "provisioned" ? active ? I'm not sure how the bundle
> would
> > > resolve with q not exported, to begin with. Is your build system bnd?
> Who
> > > or what writes the export-package line for this bundle?
> > >
> > > You might also want to consider declarative services to share state (
> > > "communicate information" ) across bundles without spreading your
> > > dependencies across the system classpath
> > >
> >
> > I am using declarative services, but I do need a data model to pass
> > information into and out of the services.
> >
> >
> >
> >
> > >
> > > On 23 December 2014 at 15:18, Neil Bartlett <njbartlett@gmail.com>
> > wrote:
> > >
> > > > Your question is not very clear. Who or what uses the classes from
> > > package
> > > > ‘q’? Where are they now and where do you want them to be?
> > > >
> > > > Please also report the actual error message from Felix. Merely
> stating
> > > > that “Felix complains” is not informative.
> > > >
> > > > Regards,
> > > > Neil
> > > >
> > > >
> > > > > On 23 Dec 2014, at 13:58, Benson Margulies <benson@basistech.com>
> > > wrote:
> > > > >
> > > > > I have a bundle that contains a set of classes that are used to
> > > > communicate
> > > > > information across the boundary of the OSGi container. All these
> > > classes
> > > > > are in one package ('p'). That package is both imported and
> exported
> > > from
> > > > > the bundle.
> > > > >
> > > > > The bundle also contains some support classes in the package that
> > never
> > > > > cross the boundary. They are in package 'q'. 'q' is neither
> imported
> > > nor
> > > > > exported.
> > > > >
> > > > > I set up as follows:
> > > > >
> > > > > - The classes in 'p' are in my overall application classpath.
> > > > > - 'p' is listed as a system bundle package
> > > > > - the bundle is provisioned
> > > > >
> > > > > If I don't list 'q' in the system bundle packages, then Felix
> > complains
> > > > > that it cannot find classes in 'q'. I imagine that I'm missing
> > > something
> > > > > basic here. Is there a way to avoid including 'q' in the system
> > bundle?
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > > For additional commands, e-mail: users-help@felix.apache.org
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message