t; has,
> > > > then I have no objections.
> > > >
> > > > Indiens I am not that deep into osgi to have a well founded opinion.
> > > >
> > > > The api will probably never be a pure api module as it contains the
> > > driver
> >
objections.
> > >
> > > Indiens I am not that deep into osgi to have a well founded opinion.
> > >
> > > The api will probably never be a pure api module as it contains the
> > driver
> > > manager, which I wouldn't want to put into a separate module.
>
separate module.
> >
> > Chris
> >
> > Von: Niclas Hedhman
> > Gesendet: Freitag, 8. Mai 2020 05:12
> > An: dev@plc4x.apache.org
> > Betreff: Re: SPI Module - OSGi Bundle
> >
> > Both approaches are independent of O
separate module.
>
> Chris
>
> Von: Niclas Hedhman
> Gesendet: Freitag, 8. Mai 2020 05:12
> An: dev@plc4x.apache.org
> Betreff: Re: SPI Module - OSGi Bundle
>
> Both approaches are independent of OSGi framework implementations, which is
> part of the beauty of OSGi.
>
into a separate module.
Chris
Von: Niclas Hedhman
Gesendet: Freitag, 8. Mai 2020 05:12
An: dev@plc4x.apache.org
Betreff: Re: SPI Module - OSGi Bundle
Both approaches are independent of OSGi framework implementations, which is
part of the beauty of OSGi.
Lukasz
Both approaches are independent of OSGi framework implementations, which is
part of the beauty of OSGi.
Lukasz puts more value on some dogmatic principle ("only interfaces in
API"), whereas I have forwarded how an OSGi bundle producer is expected to
provide it, and how an OSGi bundle consumer
Hi Etienne,
I have to admit that I would prefer this option ... but we should also let the
others state their opinion.
Chris
Am 07.05.20, 19:27 schrieb "Etienne Robinet" <43...@etu.he2b.be>:
Hi Chris
Well then we could create a seperate module to put the Activators we have
in it?
I would say that there are arguments for both cases (as ist often with OSGi,
IMHO).
So I see them not as right or wrong but as to different styles or approaches
that I woudl leave up to you to decide.
IMHO
Julian
Am 07.05.20, 10:07 schrieb "Robinet, Etienne" <43...@etu.he2b.be>:
Hi guys,
Hi guys,
As I am really not an expert, which approach should we use?
Etienne
Le mer. 6 mai 2020 à 15:57, Łukasz Dywicki a écrit :
> Hey Niclas,
> While this code seems straight I don't think it is needed, and valid in
> our case.
> Main benefit of extender and extender based patterns is
Hey Niclas,
While this code seems straight I don't think it is needed, and valid in
our case.
Main benefit of extender and extender based patterns is centralized
processing of drivers.
I am keen to keep only interfaces in the API packages and bundles and
move active parts of code (such base
My suggestion was;
1. Don't do the BundleTracker classes, and instead change to a bundle
activator for each.
2. Add the "Bundle-Activator: org.apache.plc4x.java.osgi.DriverActivator"
to the driver META/MANIFEST.MF
3. Do the equivalent for the Transports.
public class DriverActivator implements
Hi all,
So concretely what changes should be done so that a Driver/Transport declares
itself his service? Beside the changes in the manifest?
Etienne
On 2020/05/06 01:26:42, Niclas Hedhman wrote:
> Łukasz,
>
> the reason I say it is not very OSGi-y, is that the principle of OSGi is
> that the
Łukasz,
the reason I say it is not very OSGi-y, is that the principle of OSGi is
that the bundle handles its own service registrations. In the case of JDBC
(I initiated that spec, and I am the founder of OPS4J as well as Pax
subproject, 2005), it needed to address the problem that JDBC drivers
Hey Etienne, that's awesome piece of work. I can test it! :-)
I believe that's what Etienne code does it in a valid OSGi way. And I do
believe not because he mentioned me by name, but due to below argumentation.
Proposed code uses extender pattern to grab specific META-INF/services
entries and
Hi Etienne and Niclas,
indeed we could orient (again) on how JDBC does that in OSGi.
They really focus on "late binding" so that you resolve the driver directly
when you need it.
In theory, there is no such thing as a DriverManager in OSGi but only a
PlcDriver with the capability
Also, just in case, a custom activator is ever required, it can be
overridden easily without breaking the over all design
On Tue, May 5, 2020 at 6:27 PM Niclas Hedhman wrote:
> Yes, that's what I mean, because that is what you have inside the loop, so
> it should work.
>
> On Tue, May 5, 2020
Yes, that's what I mean, because that is what you have inside the loop, so
it should work.
On Tue, May 5, 2020 at 11:50 AM Robinet, Etienne <43...@etu.he2b.be> wrote:
> Hi Niclas,
> thanks for the feedback. So you mean to make the Activator in API/SPI
> generic so every Driver would call it and
Hi Niclas,
thanks for the feedback. So you mean to make the Activator in API/SPI
generic so every Driver would call it and declare the service itself?
Le mar. 5 mai 2020 à 05:25, Niclas Hedhman a écrit :
> What you are doing is not particularly OSGi-y... The expected way to do
> this is to have
What you are doing is not particularly OSGi-y... The expected way to do
this is to have each bundle register their PlcDriver or Transport to the
OSGi service registry.
That said, what you have done is otherwise fine, as you basically trying to
centralize the BundleActivators away from respective
Hi all,
With the change of Christofer this problem got solved. Nonetheless, I kept
the work I did (inspired by the work of Lukasz) to make an Activator for
API (Driver Services) and SPI (Transport Services). I also tested it, but
as I am pretty new to this, if anyone could just give me a feedback
Hi folks,
I just pushed a change that might get rid of this error.
I added the Plc4xBootstrap in an attempt to get the TestTransport working.
For some reasons the netty folks created the EmbeddedChannel differently than
the rest.
However as the TestTransport is the only one needing this
Hi all,
I’ve checked the Manifest. If I put the Embed-Dependency to the plc4j-spi
artifact it does not find the Transport Service. And if I dont it does not
find the Plc4xBootstrap.
Etienne ROBINET
> Le 7 avr. 2020 à 16:48, Łukasz Dywicki a écrit :
>
> I was updating my local checkout
I was updating my local checkout yesterday. Can't promise if I will be
able to help, but will give a try with 0.7 snapshot.
Best,
Łukasz
On 07.04.2020 15:39, Etienne Robinet wrote:
> Hi again,
> I've been looking at this issue all day, and I am back to the initial error:
>
Have you checked that the MANIFEST.MF looks good?
On Tue, Apr 7, 2020, 21:39 Etienne Robinet wrote:
> Hi again,
> I've been looking at this issue all day, and I am back to the initial
> error:
> https://i.imgur.com/LLfan8H.png
>
> The difference is I used and Activator for API and SPI to
Hi all,
the faulty ClassLoader is the BundleDelegatingClassLoader(plc4x-test [191]).
Which means that the custom bundle can not find the class right?
I'm sorry if it's a silly question but I am pretty new to this.
Etienne
On 2020/04/06 20:28:17, Łukasz Dywicki wrote:
> I haven't used Camel
As for the META-INF/services, that is a standard JDK feature, known as the
ServiceLoader, unrelated to OSGi.
@Component is a sign of the Declarative Services that Łukasz asked about,
but it requires compile-time support to work as expected. Under the hood,
DS is still doing the normal song and
Hi Lukasz,
thank you very much for your help, I will look into this today.
For the drivers as services, isn't that already the case? I know that for
S7 and EIP at least,
the yhave the osgi.cmpn dependency and the @Component annotation for the
class, as well as a file with the implemented Driver
I haven't used Camel for a while, but to me it seems to be a problem
caused by caller's classloader.
See that in stack trace you have a thread which is started by camel, so
there are 3 or even 4 classloaders to be considered:
- plc4x, definitely not a faulty one
- netty, could be troublesome but
Hi Christian,
you mean the code used in the Camel route? It is an blueprint:
http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation= "http://www.osgi.org/xmlns/blueprint/v1.0.0
The code in plc4x directly uses the class (not a String of the name). This
is good. Normally such a class reference should work fine.
Can you show your code as a complete example?
Christian
Am Fr., 3. Apr. 2020 um 09:58 Uhr schrieb Julian Feinauer <
j.feina...@pragmaticminds.de>:
> I am off
I am off with my knowledge.
You could ask the Karaf friends (#karaf in Slack). They are all OSGi experts
and very friendly and helpful.
Or perhaps Christian has an idea here?
Best
Julian
Am 03.04.20, 09:50 schrieb "Etienne Robinet" :
Hi again,
I've been struggling with this issue for
Hi again,
I've been struggling with this issue for 2 days now... I still don't get it why
it can not find classes. here is the current problem:
https://i.imgur.com/LtZMdsu.png
We can see that the classes are available and exported, I don't know why the
Camel Context can't find it. I even tried
It happens that OSGi classloading result in the wrong NCDFE and that one of
the classes "used" (i.e. return type, parameter, throws, extends,
implements) in the reported class is not visible by the classloader. And
occasionally, it is a "diamond problem", i.e. that the Constraints (IIRC,
see
Hi all,
But If I search for uses of that class, it's only in the
org.apache.plc4x.java.spi.connection.NettyChannelFactory which is in the SPI
module.
So I am not sure where this is accessed directly from the outside. I know every
driver would use the NettyChannelFactory, but that shouldn't be
Hi Julian,
that actually did the trick. But now I am getting the next error.
https://i.imgur.com/U7NjmsF.png
As you can see, the class it cant find is inside the container, so that is even
more weird.
Etienne
On 2020/03/31 14:09:11, Julian Feinauer wrote:
> Hi,
>
> this is not so optimal.
>
Hi,
this is not so optimal.
Then one solution would be to embed the SPI bundle inside the transport
bundle(s).
This can be done with the felix-maven plugin by using the
configuration if I remember correctly.
Julian
Am 31.03.20, 16:07 schrieb "Etienne Robinet" <43...@etu.he2b.be>:
Hi,
Hi,
From the log the class is called outside the SPI by the transport
Etienne
> Le 31 mars 2020 à 15:24, Julian Feinauer a
> écrit :
>
> Hi,
>
> yes, if ist only needed internally its fine.But why does someone then get a
> Class Not Found Exception?
> This is usually a hint to some class
Hi,
yes, if ist only needed internally its fine.But why does someone then get a
Class Not Found Exception?
This is usually a hint to some class loader issue in OSGi which is related to
exports/ imports.
J
Am 31.03.20, 15:23 schrieb "Christofer Dutz" :
As this package is only referenced
As this package is only referenced from within SPI, couldn't we just exclude it
from the package exports?
Chris
Am 31.03.20, 15:17 schrieb "Julian Feinauer" :
Hi,
the issue is that if we export it, then we break Nettys OSGi integration as
we get a split package situation (two
Hi,
the issue is that if we export it, then we break Nettys OSGi integration as we
get a split package situation (two bundles exporting the same package, which is
forbidden in OSGi).
So I see no easy solution (but had to do the same once as Netty is pretty...
private).
J
Am 31.03.20, 15:15
Hi all,
I just discussed this issue with Etienne and I thought it was important for
all, so I asked him to bring it here.
In my effort to get the EmbeddedChannel working as a full "transport" module, I
had to override the Netty Bootstrap mechanism.
Unfortunately in order to do so, I need to
Hi all,
I've been working on the Camel Component and decided to test it inside Karaf,
but I noticed that I've got this error now:
https://i.imgur.com/kUZPwZ5.png
Seems like this class is not exported by the bundle so it can not be found.
Anyone has an idea on how we could solve this?
Etienne
42 matches
Mail list logo
