Re: [osgi-dev] ServletContextListener not working?
Hi Thomas,
I wonder if you have found an answer to your issue with
ServletContextListener since I have the same problem here. I'm using paxweb
and their example/test don't use DS annotation but register the component
directly with httpservice.
Thai
On Sat, Feb 2, 2019 at 11:00 AM Thomas Driessen via osgi-dev <
osgi-dev@mail.osgi.org> wrote:
> Hi Dirk,
>
> I've read all of your great blog post. By the way thank you for those .
> Unfortunately, in those you do exact the same things as I did in my example.
>
> The servlet looks like this:
>
> @Component(service = Servlet.class, scope = ServiceScope.PROTOTYPE)
> public class MyServlet extends HttpServlet{
>
> protected void doGet(HttpServletRequest req, HttpServletResponse resp)
> throws IOException {
> resp.setContentType("text/plain");
> resp.getWriter().println("Hello World!");
> }
> }
>
> and the ServletContextListener like this:
>
> @Component
> @HttpWhiteboardListener
> public class MySCL implements ServletContextListener {
>
> @Override
> public void contextDestroyed(ServletContextEvent arg0) {
> System.out.println("Destroyed");
> }
>
> @Override
> public void contextInitialized(ServletContextEvent arg0) {
> System.out.println("Initialized");
> }
> }
>
> I think by using the new annotations everything should be set up right.
> The Servlet works as expected, but the SCL is never called.
>
> In contrast to your blog post examples I didn't use any specific
> ServletContext(Helper), but I thought this would lead to using the default
> ServletContext. I think in most of my cases I do not need to use a specific
> ServletContext,, so the default would be sufficient.
>
> Kind regards,
> Thomas
>
>
>
> Am Sa., 2. Feb. 2019 um 16:50 Uhr schrieb Dirk Fauth >:
>
>> Hi,
>>
>> Not sure if this helps, but I wrote a blog post a while ago where I also
>> used a ServletContextListener in my example.
>>
>> http://blog.vogella.com/2017/04/20/access-osgi-services-via-web-interface/
>>
>> Maybe it helps in finding the cause.
>>
>> Are you using the http whiteboard pattern and did you set the required
>> component property?
>>
>> Greez,
>> Dirk
>>
>> Am Sa., 2. Feb. 2019, 16:07 hat Thomas Driessen via osgi-dev <
>> osgi-dev@mail.osgi.org> geschrieben:
>>
>>> Hi,
>>>
>>> I just tried to get a ServletContextListener to work, but did not
>>> succeed, although everything is done as defined by the spec.
>>>
>>> Here you can find a minimal example of my setup
>>> https://github.com/Sandared/io.jatoms.osgi.possiblebugs.scl
>>>
>>> The Servlet I'm registering is working fine, but the
>>> ServletContextListener that I registered too is never called.
>>> Even if I call getServletContext() from within the Servlet, my Listener
>>> is never called.
>>>
>>> I would have expected the ServletContextListener to be called at least
>>> once, after a DefaultServletContext has been created by the
>>> ServletContainer, or am I wrong with this assumption?
>>>
>>> Kind regards,
>>> Thomas
>>> ___
>>> 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
--
Castor Technologies Inc
460 rue St-Catherine St Ouest, Suite 613
Montréal, Québec H3B-1A7
(514) 360-7208 o
(514) 798-2044 f
n...@castortech.com
www.castortech.com
CONFIDENTIALITY NOTICE: The information contained in this e-mail is
confidential and may be proprietary information intended only for the use
of the individual or entity to whom it is addressed. If the reader of this
message is not the intended recipient, you are hereby notified that any
viewing, dissemination, distribution, disclosure, copy or use of the
information contained in this e-mail message is strictly prohibited. If you
have received and/or are viewing this e-mail in error, please immediately
notify the sender by reply e-mail, and delete it from your system without
reading, forwarding, copying or saving in any manner. Thank you.
AVIS DE CONFIDENTIALITE: L’information contenue dans ce message est
confidentiel, peut être protégé par le secret professionnel et est réservé
à l'usage exclusif du destinataire. Toute autre personne est par les
présentes avisée qu'il lui est strictement interdit de diffuser, distribuer
ou reproduire ce message. Si vous avez reçu cette communication par erreur,
veuillez la détruire immédiatement et en aviser l'expéditeur. Merci.
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] SCR API
As an Addition to the things already suggested:
Taking your example I would create the MainView as follows:
@Route("")
@Component(name="MainView ", service=HasElement.class,
configurationPolicy=Required, scope=PROTOTYPE)
public class MainView extends VerticalLayout{
@Reference //what ever is required here
SomeService someService;
}
You can then use the Configurator or Config Admin to create you
component and even your someService target binding. Here is an example
for the Configurator would need to be translated to the ConfigAdmin if
you want to do this programmatically.
{
":configurator:resource-version": 1,
"MainView~instance1":
{
"someService.target": "(fancy.service.id.prop=fizzbuzz)"
}
}
Regards,
Jürgen.
Am 22/02/2019 um 10:29 schrieb Tim Ward via osgi-dev:
Hi Thomas,
I’m not sure that there is a naming issue here, but possibly a
different misunderstanding.
From my understanding there are two kinds of "services”:
This is not really accurate. There is only one kind of service in
OSGi, and it’s an object which has been registered with the service
registry. It is always registered by a call to
context.registerService(...). It doesn’t matter whether this action is
taken directly by your bundle, or on your bundle’s behalf by an
extender bundle. The fact that all services are the same is important
because this is how bundles interoperate. Your bundles can use any
mechanisms that they like internally and they can still interact with
other bundles that may be using the same, or different, internal details.
2) "Fancy services" aka DS managed by a SCR. I specify those
declaratively via annotations, they have a lifecycle and can have
references to other services/components via annotations like
@Activate/@Deactivate (Lifecycle) and @Reference. Those I will call
components for the rest of this mail.
There are a large number of different component models around in Java.
These provide lifecycle management and injection for your objects. In
the case of OSGi aware component models they also provide support for
registering the object instance as a service (using
context.registerService()).
For Declarative Services the programming and configuration model is
declarative - you describe how you want your component’s lifecycle to
look using XML (or annotations to generate the XML). This XML is
packaged into your bundle and used by a Service Component Runtime (an
implementation of the DS specification) at runtime to find and manage
your component.
Components on the other side have references and lifecycle methods,
but in order to instantiate them programmatically I have to force a
developer to annotate the class
with @Component(scope=ServiceScope.PROTOTYPE) and then use
ServiceObjects#getService() to instantiate/register it.
This procedure can be error-prone, e.g., when I assume that scope is
always PROTOTYPE but the developer forgot to set it to this value.
This problem came up during my discussion with Vaadin for a Flow-OSGi
integration.
This is really a decision that needs to be made by the component
developer. It doesn’t always make sense for a component to be
PROTOTYPE scoped, and they need to be aware that there may be multiple
instances created
In this context it would be great if there were a possibility to
programmatically create components (not services) where I can tell
SCR what fields/methods have to be treated as @Reference or lifecycle
methods and let SCR do the heavy lifting.
This is not what SCR does. SCR is a declarative component model, not a
programmatic one. There is no “DS builder API” for creating
components. If you want a builder API for creating a component then
you need to use a component framework that works in this way. As Ray
pointed out in a previous mail chain there is the Apache Aries
Component DSL. You could also use Apache Felix Dependency Manager.
Would such an API make sense? Or would it even be possible?
I think in general this would be very useful in order to create OSGi
integrations for third-party libs that need to interact with DS in OSGi.
This isn’t really a question of third party libraries interacting with
DS, it’s a request for a radically different component model with some
DS-like capabilities. There are already framework implementations in
the world that provide what you’re looking for, just not using DS.
Best Regards,
Tim
On 21 Feb 2019, at 18:07, Thomas Driessen via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:
Hi BJ,
sorry for being imprecise. I sometimes get confused regarding the
proper naming in OSGi. I will try to clear things up by defining what
my understanding is about services:
From my understanding there are two kinds of "services":
1) "Old school Services": I usually register those programmatically
via context.registerService(...). Those services are just POJOs with
a little bit metadata, i.e., properties, and a well-defined
Re: [osgi-dev] SCR API
Hi Thomas, I’m not sure that there is a naming issue here, but possibly a different misunderstanding. > From my understanding there are two kinds of "services”: This is not really accurate. There is only one kind of service in OSGi, and it’s an object which has been registered with the service registry. It is always registered by a call to context.registerService(...). It doesn’t matter whether this action is taken directly by your bundle, or on your bundle’s behalf by an extender bundle. The fact that all services are the same is important because this is how bundles interoperate. Your bundles can use any mechanisms that they like internally and they can still interact with other bundles that may be using the same, or different, internal details. > 2) "Fancy services" aka DS managed by a SCR. I specify those declaratively > via annotations, they have a lifecycle and can have references to other > services/components via annotations like @Activate/@Deactivate (Lifecycle) > and @Reference. Those I will call components for the rest of this mail. There are a large number of different component models around in Java. These provide lifecycle management and injection for your objects. In the case of OSGi aware component models they also provide support for registering the object instance as a service (using context.registerService()). For Declarative Services the programming and configuration model is declarative - you describe how you want your component’s lifecycle to look using XML (or annotations to generate the XML). This XML is packaged into your bundle and used by a Service Component Runtime (an implementation of the DS specification) at runtime to find and manage your component. > Components on the other side have references and lifecycle methods, but in > order to instantiate them programmatically I have to force a developer to > annotate the class with @Component(scope=ServiceScope.PROTOTYPE) and then use > ServiceObjects#getService() to instantiate/register it. > > This procedure can be error-prone, e.g., when I assume that scope is always > PROTOTYPE but the developer forgot to set it to this value. This problem came > up during my discussion with Vaadin for a Flow-OSGi integration. This is really a decision that needs to be made by the component developer. It doesn’t always make sense for a component to be PROTOTYPE scoped, and they need to be aware that there may be multiple instances created > In this context it would be great if there were a possibility to > programmatically create components (not services) where I can tell SCR what > fields/methods have to be treated as @Reference or lifecycle methods and let > SCR do the heavy lifting. This is not what SCR does. SCR is a declarative component model, not a programmatic one. There is no “DS builder API” for creating components. If you want a builder API for creating a component then you need to use a component framework that works in this way. As Ray pointed out in a previous mail chain there is the Apache Aries Component DSL. You could also use Apache Felix Dependency Manager. > Would such an API make sense? Or would it even be possible? > I think in general this would be very useful in order to create OSGi > integrations for third-party libs that need to interact with DS in OSGi. This isn’t really a question of third party libraries interacting with DS, it’s a request for a radically different component model with some DS-like capabilities. There are already framework implementations in the world that provide what you’re looking for, just not using DS. Best Regards, Tim > On 21 Feb 2019, at 18:07, Thomas Driessen via osgi-dev > wrote: > > Hi BJ, > > sorry for being imprecise. I sometimes get confused regarding the proper > naming in OSGi. I will try to clear things up by defining what my > understanding is about services: > > From my understanding there are two kinds of "services": > 1) "Old school Services": I usually register those programmatically via > context.registerService(...). Those services are just POJOs with a little bit > metadata, i.e., properties, and a well-defined interface. Those I will call > services for the rest of this mail. > 2) "Fancy services" aka DS managed by a SCR. I specify those declaratively > via annotations, they have a lifecycle and can have references to other > services/components via annotations like @Activate/@Deactivate (Lifecycle) > and @Reference. Those I will call components for the rest of this mail. > > The difference between both (as far as I understand it) is that services can > be instantiated and registered programmatically, but are not managed by SCR > and therefore have no references and lifecycle methods. > > Components on the other side have references and lifecycle methods, but in > order to instantiate them programmatically I have to force a developer to > annotate the class with
