You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by jamie campbell <ja...@parit.ca> on 2011/02/21 01:12:55 UTC
bundleContext retrieval question
While I was poking around trying to solve a different jndi issue (which
turned out to not be a jndi issue at all) I came across a possible
solution to another bit of my architecture which is currently inelegant.
Right now, bundles I'm developing tend to have a ContextHolder singleton
that other classes in the same bundle use to get access to the
BundleContext.
in the osgi enterprise spec, pg 394/395, I found "A JNDI client can also
obtain the BundleContext of the owning bundle by using the osgi: scheme
namespace with the framework/bundleContext name. The following URL must
return the Bundle Context of the owning bundle:
osgi:framework/bundleContext "
Does this mean "if you're lucky enough to already have the jndi service,
retrieved by some other place that already had the bundle context, then
you can get the bundle context too" or does it mean there's a jndi way
of getting the bundle context without requiring service lookup (which
would itself require the bundle context)?
Or, I may be thinking about the problem wrong and there may be some
other way of dumping the singleton I'm using. In other words, I might
be missing something that's pretty foundational to OSGi programming, I'm
not sure. I'm posting to this list because I found it in the
osgi-enterprise-jndi section and aries is an osgi jndi implementer..
thoughts?
-Jamie
Re: Void factory method
Posted by Mark Nuttall <mn...@apache.org>.
Hi Łukasz,
Section 121.5.7 of the OSGi Enterprise 4.2 spec does go on to say,
"The object created this way will be the provided object of the bean
after any properties are injected. If
the factoryMethod returns a primitive type, then this primitive must
be converted to the correspond-
ing wrapper type before any usage."
Given that beans can be injected into other beans, that cannot work if
a factory-method returns a void: nor will the abovementioned cast be
possible. Spring's MethodInvokingFactoryBean states,
"Note that this factory bean will return the special
MethodInvoker.VOID singleton instance when it is used to invoke a
method which returns null, or has a void return type. While the user
of the factory bean is presumably calling the method to perform some
sort of initialization, and doesn't care about any return value, all
factory beans must return a value, so this special singleton instance
is used for this case."
While it's possible that we could implement something in Aries, I do
not believe that this use case is specifically supported by the 4.2
spec.
Regards,
Mark
2011/2/22 Łukasz Dywicki <lu...@code-house.org>:
> Hello,
> I won't argue it is good or not, it's just not in line with bean specs.
> However blueprint specs says:
> #factoryMethod - A static or instance factory method name that corresponds
> to a publicly accessible method on the given class or factory manager.
>
> So it's not pointing to return value of the factory method.
>
> To be honest, it's not important for me how this combination might be done -
> it might be done just like we did this in Spring - with
> MethodInvokingFactoryBean. But I wish to don't copy unnecessary code when it
> might be done in existing. WDYT?
>
> Best regards,
> Lukasz
>
> -----Original Message-----
> From: alasdair.nottingham@gmail.com [mailto:alasdair.nottingham@gmail.com]
> On Behalf Of Alasdair Nottingham
> Sent: Tuesday, February 22, 2011 1:58 PM
> To: user@aries.apache.org
> Subject: Re: Void factory method
>
> Can you raise a JIRA to make the error message better?
>
> JIRA issues can be raised here: https://issues.apache.org/jira/browse/ARIES
>
> Thanks for bringing this to our attention.
> Alasdair
>
> 2011/2/22 Alasdair Nottingham <no...@apache.org>:
>> Hi,
>>
>> You can't do what you are trying to do here. The factory-method needs
>> to return an object
>> that represents the bean. In this case it returns void. It is not a
>> very nice error, we shouldn't
>> throw a NullPointerException.
>>
>> In this scenario you are defining a bean without providing an instance
>> that could back that bean.
>>
>> Alasdair
>>
>> 2011/2/22 Łukasz Dywicki <lu...@code-house.org>:
>>> Hello,
>>> I have small problem with Aries. I try to configure jetty with blueprint.
>>> Jetty requires to register some objects using void methods, for example:
>>> Server.addConnector(Connector).
>>>
>>> I try to use blueprint XML:
>>>
>>> <bean id="server" class="org.eclipse.jetty.server.Server"
>>> init-method="start" destroy-method="stop"
>>> />
>>>
>>> <bean id="http" factory-ref="server" factory-method="addConnector"
>>> depends-on="jersey">
>>> <argument>
>>> <bean
>>> class="org.eclipse.jetty.server.nio.SelectChannelConnector">
>>> <property name="port" value="8080" />
>>> <property name="host" value="0.0.0.0" />
>>> </bean>
>>> </argument>
>>> </bean>
>>>
>>> This configuration causes following error:
>>> org.apache.aries.blueprint - 0.2.0.incubating | Unable to start blueprint
>>> container for bundle jetty-server
>>> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable
> to
>>> instantiate components
>>> at
>>>
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
>>>
> Components(BlueprintContainerImpl.java:628)[7:org.apache.aries.blueprint:0.2
>>> .0.incubating]
>>> at
>>>
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintC
>>> ontainerImpl.java:315)[7:org.apache.aries.blueprint:0.2.0.incubating]
>>> at
>>>
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintCon
>>> tainerImpl.java:213)[7:org.apache.aries.blueprint:0.2.0.incubating]
>>> at
>>>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6
>>> .0_21]
>>> at
>>>
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_21
>>> ]
>>> at
>>> java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_21]
>>> at
>>>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$
>>> 301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_21]
>>> at
>>>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Sch
>>> eduledThreadPoolExecutor.java:207)[:1.6.0_21]
>>> at
>>>
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
>>> va:886)[:1.6.0_21]
>>> at
>>>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
>>> 08)[:1.6.0_21]
>>> at java.lang.Thread.run(Thread.java:619)[:1.6.0_21]
>>> Caused by: java.lang.NullPointerException
>>> at
>>>
> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)[:1.6.
>>> 0_21]
>>> at
>>>
> org.apache.aries.blueprint.container.BlueprintRepository.addPartialObject(Bl
>>>
> ueprintRepository.java:357)[7:org.apache.aries.blueprint:0.2.0.incubating]
>>> at
>>>
> org.apache.aries.blueprint.di.AbstractRecipe.addPartialObject(AbstractRecipe
>>> .java:84)[7:org.apache.aries.blueprint:0.2.0.incubating]
>>> at
>>>
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.ja
>>> va:736)[7:org.apache.aries.blueprint:0.2.0.incubating]
>>> at
>>>
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)[
>>> 7:org.apache.aries.blueprint:0.2.0.incubating]
>>> at
>>>
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(Blu
>>> eprintRepository.java:219)[7:org.apache.aries.blueprint:0.2.0.incubating]
>>> at
>>>
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(Blueprint
>>> Repository.java:147)[7:org.apache.aries.blueprint:0.2.0.incubating]
>>> at
>>>
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
>>>
> Components(BlueprintContainerImpl.java:624)[7:org.apache.aries.blueprint:0.2
>>> .0.incubating]
>>> ... 10 more
>>>
>>>
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
>
RE: Void factory method
Posted by Łukasz Dywicki <lu...@code-house.org>.
Hello,
I won't argue it is good or not, it's just not in line with bean specs.
However blueprint specs says:
#factoryMethod - A static or instance factory method name that corresponds
to a publicly accessible method on the given class or factory manager.
So it's not pointing to return value of the factory method.
To be honest, it's not important for me how this combination might be done -
it might be done just like we did this in Spring - with
MethodInvokingFactoryBean. But I wish to don't copy unnecessary code when it
might be done in existing. WDYT?
Best regards,
Lukasz
-----Original Message-----
From: alasdair.nottingham@gmail.com [mailto:alasdair.nottingham@gmail.com]
On Behalf Of Alasdair Nottingham
Sent: Tuesday, February 22, 2011 1:58 PM
To: user@aries.apache.org
Subject: Re: Void factory method
Can you raise a JIRA to make the error message better?
JIRA issues can be raised here: https://issues.apache.org/jira/browse/ARIES
Thanks for bringing this to our attention.
Alasdair
2011/2/22 Alasdair Nottingham <no...@apache.org>:
> Hi,
>
> You can't do what you are trying to do here. The factory-method needs
> to return an object
> that represents the bean. In this case it returns void. It is not a
> very nice error, we shouldn't
> throw a NullPointerException.
>
> In this scenario you are defining a bean without providing an instance
> that could back that bean.
>
> Alasdair
>
> 2011/2/22 Łukasz Dywicki <lu...@code-house.org>:
>> Hello,
>> I have small problem with Aries. I try to configure jetty with blueprint.
>> Jetty requires to register some objects using void methods, for example:
>> Server.addConnector(Connector).
>>
>> I try to use blueprint XML:
>>
>> <bean id="server" class="org.eclipse.jetty.server.Server"
>> init-method="start" destroy-method="stop"
>> />
>>
>> <bean id="http" factory-ref="server" factory-method="addConnector"
>> depends-on="jersey">
>> <argument>
>> <bean
>> class="org.eclipse.jetty.server.nio.SelectChannelConnector">
>> <property name="port" value="8080" />
>> <property name="host" value="0.0.0.0" />
>> </bean>
>> </argument>
>> </bean>
>>
>> This configuration causes following error:
>> org.apache.aries.blueprint - 0.2.0.incubating | Unable to start blueprint
>> container for bundle jetty-server
>> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable
to
>> instantiate components
>> at
>>
org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
>>
Components(BlueprintContainerImpl.java:628)[7:org.apache.aries.blueprint:0.2
>> .0.incubating]
>> at
>>
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintC
>> ontainerImpl.java:315)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>>
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintCon
>> tainerImpl.java:213)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>>
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6
>> .0_21]
>> at
>>
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_21
>> ]
>> at
>> java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_21]
>> at
>>
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$
>> 301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_21]
>> at
>>
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Sch
>> eduledThreadPoolExecutor.java:207)[:1.6.0_21]
>> at
>>
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
>> va:886)[:1.6.0_21]
>> at
>>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
>> 08)[:1.6.0_21]
>> at java.lang.Thread.run(Thread.java:619)[:1.6.0_21]
>> Caused by: java.lang.NullPointerException
>> at
>>
java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)[:1.6.
>> 0_21]
>> at
>>
org.apache.aries.blueprint.container.BlueprintRepository.addPartialObject(Bl
>>
ueprintRepository.java:357)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>>
org.apache.aries.blueprint.di.AbstractRecipe.addPartialObject(AbstractRecipe
>> .java:84)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>>
org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.ja
>> va:736)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>>
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)[
>> 7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>>
org.apache.aries.blueprint.container.BlueprintRepository.createInstances(Blu
>> eprintRepository.java:219)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>>
org.apache.aries.blueprint.container.BlueprintRepository.createAll(Blueprint
>> Repository.java:147)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>>
org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
>>
Components(BlueprintContainerImpl.java:624)[7:org.apache.aries.blueprint:0.2
>> .0.incubating]
>> ... 10 more
>>
>>
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Alasdair Nottingham
not@apache.org
Re: Void factory method
Posted by Alasdair Nottingham <no...@apache.org>.
Can you raise a JIRA to make the error message better?
JIRA issues can be raised here: https://issues.apache.org/jira/browse/ARIES
Thanks for bringing this to our attention.
Alasdair
2011/2/22 Alasdair Nottingham <no...@apache.org>:
> Hi,
>
> You can't do what you are trying to do here. The factory-method needs
> to return an object
> that represents the bean. In this case it returns void. It is not a
> very nice error, we shouldn't
> throw a NullPointerException.
>
> In this scenario you are defining a bean without providing an instance
> that could back that bean.
>
> Alasdair
>
> 2011/2/22 Łukasz Dywicki <lu...@code-house.org>:
>> Hello,
>> I have small problem with Aries. I try to configure jetty with blueprint.
>> Jetty requires to register some objects using void methods, for example:
>> Server.addConnector(Connector).
>>
>> I try to use blueprint XML:
>>
>> <bean id="server" class="org.eclipse.jetty.server.Server"
>> init-method="start" destroy-method="stop"
>> />
>>
>> <bean id="http" factory-ref="server" factory-method="addConnector"
>> depends-on="jersey">
>> <argument>
>> <bean
>> class="org.eclipse.jetty.server.nio.SelectChannelConnector">
>> <property name="port" value="8080" />
>> <property name="host" value="0.0.0.0" />
>> </bean>
>> </argument>
>> </bean>
>>
>> This configuration causes following error:
>> org.apache.aries.blueprint - 0.2.0.incubating | Unable to start blueprint
>> container for bundle jetty-server
>> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
>> instantiate components
>> at
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
>> Components(BlueprintContainerImpl.java:628)[7:org.apache.aries.blueprint:0.2
>> .0.incubating]
>> at
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintC
>> ontainerImpl.java:315)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintCon
>> tainerImpl.java:213)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6
>> .0_21]
>> at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_21
>> ]
>> at
>> java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_21]
>> at
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$
>> 301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_21]
>> at
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Sch
>> eduledThreadPoolExecutor.java:207)[:1.6.0_21]
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
>> va:886)[:1.6.0_21]
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
>> 08)[:1.6.0_21]
>> at java.lang.Thread.run(Thread.java:619)[:1.6.0_21]
>> Caused by: java.lang.NullPointerException
>> at
>> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)[:1.6.
>> 0_21]
>> at
>> org.apache.aries.blueprint.container.BlueprintRepository.addPartialObject(Bl
>> ueprintRepository.java:357)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.di.AbstractRecipe.addPartialObject(AbstractRecipe
>> .java:84)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.ja
>> va:736)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)[
>> 7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(Blu
>> eprintRepository.java:219)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.container.BlueprintRepository.createAll(Blueprint
>> Repository.java:147)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
>> Components(BlueprintContainerImpl.java:624)[7:org.apache.aries.blueprint:0.2
>> .0.incubating]
>> ... 10 more
>>
>>
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Alasdair Nottingham
not@apache.org
Re: Void factory method
Posted by Alasdair Nottingham <no...@apache.org>.
Hi,
You can't do what you are trying to do here. The factory-method needs
to return an object
that represents the bean. In this case it returns void. It is not a
very nice error, we shouldn't
throw a NullPointerException.
In this scenario you are defining a bean without providing an instance
that could back that bean.
Alasdair
2011/2/22 Łukasz Dywicki <lu...@code-house.org>:
> Hello,
> I have small problem with Aries. I try to configure jetty with blueprint.
> Jetty requires to register some objects using void methods, for example:
> Server.addConnector(Connector).
>
> I try to use blueprint XML:
>
> <bean id="server" class="org.eclipse.jetty.server.Server"
> init-method="start" destroy-method="stop"
> />
>
> <bean id="http" factory-ref="server" factory-method="addConnector"
> depends-on="jersey">
> <argument>
> <bean
> class="org.eclipse.jetty.server.nio.SelectChannelConnector">
> <property name="port" value="8080" />
> <property name="host" value="0.0.0.0" />
> </bean>
> </argument>
> </bean>
>
> This configuration causes following error:
> org.apache.aries.blueprint - 0.2.0.incubating | Unable to start blueprint
> container for bundle jetty-server
> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
> instantiate components
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
> Components(BlueprintContainerImpl.java:628)[7:org.apache.aries.blueprint:0.2
> .0.incubating]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintC
> ontainerImpl.java:315)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintCon
> tainerImpl.java:213)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6
> .0_21]
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_21
> ]
> at
> java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_21]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$
> 301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_21]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Sch
> eduledThreadPoolExecutor.java:207)[:1.6.0_21]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
> va:886)[:1.6.0_21]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
> 08)[:1.6.0_21]
> at java.lang.Thread.run(Thread.java:619)[:1.6.0_21]
> Caused by: java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)[:1.6.
> 0_21]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.addPartialObject(Bl
> ueprintRepository.java:357)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.addPartialObject(AbstractRecipe
> .java:84)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.ja
> va:736)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)[
> 7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(Blu
> eprintRepository.java:219)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(Blueprint
> Repository.java:147)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
> Components(BlueprintContainerImpl.java:624)[7:org.apache.aries.blueprint:0.2
> .0.incubating]
> ... 10 more
>
>
>
--
Alasdair Nottingham
not@apache.org
Re: Void factory method
Posted by Alasdair Nottingham <no...@apache.org>.
I'd been thinking along these lines too, but I think the first case is more general and therefore preferable. I also don't think we should be putting this in blueprint core, but trying to do it as a namespace handler extension.
Alasdair Nottingham
On 22 Feb 2011, at 20:08, Guillaume Nodet <gn...@gmail.com> wrote:
> As others have indicated, that's clearly outside of the specs.
> However, I see two different improvements we could add to Aries
> Blueprint to support such use cases:
>
> <ext:call ref="server" method="addConnector">
> <argument>
> <bean .../>
> </argument>
> </ext:call>
>
> or (maybe closer to the underlying jetty model):
>
> <bean id="server" class="org.eclipse.jetty.server.Server"
> init-method="start" destroy-method="stop">
> <ext:list-property method="addConnector">
> <list>
> <bean .../>
> </list>
> </ext:list-property>
> </bean>
>
> I haven't given that a lot of thoughts, and I'm not really sure how/if
> this can actually be implemented ...
> Both could actually be useful I suppose.
>
> 2011/2/22 Łukasz Dywicki <lu...@code-house.org>:
>> Hello,
>> I have small problem with Aries. I try to configure jetty with blueprint.
>> Jetty requires to register some objects using void methods, for example:
>> Server.addConnector(Connector).
>>
>> I try to use blueprint XML:
>>
>> <bean id="server" class="org.eclipse.jetty.server.Server"
>> init-method="start" destroy-method="stop"
>> />
>>
>> <bean id="http" factory-ref="server" factory-method="addConnector"
>> depends-on="jersey">
>> <argument>
>> <bean
>> class="org.eclipse.jetty.server.nio.SelectChannelConnector">
>> <property name="port" value="8080" />
>> <property name="host" value="0.0.0.0" />
>> </bean>
>> </argument>
>> </bean>
>>
>> This configuration causes following error:
>> org.apache.aries.blueprint - 0.2.0.incubating | Unable to start blueprint
>> container for bundle jetty-server
>> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
>> instantiate components
>> at
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
>> Components(BlueprintContainerImpl.java:628)[7:org.apache.aries.blueprint:0.2
>> .0.incubating]
>> at
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintC
>> ontainerImpl.java:315)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintCon
>> tainerImpl.java:213)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6
>> .0_21]
>> at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_21
>> ]
>> at
>> java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_21]
>> at
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$
>> 301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_21]
>> at
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Sch
>> eduledThreadPoolExecutor.java:207)[:1.6.0_21]
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
>> va:886)[:1.6.0_21]
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
>> 08)[:1.6.0_21]
>> at java.lang.Thread.run(Thread.java:619)[:1.6.0_21]
>> Caused by: java.lang.NullPointerException
>> at
>> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)[:1.6.
>> 0_21]
>> at
>> org.apache.aries.blueprint.container.BlueprintRepository.addPartialObject(Bl
>> ueprintRepository.java:357)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.di.AbstractRecipe.addPartialObject(AbstractRecipe
>> .java:84)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.ja
>> va:736)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)[
>> 7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(Blu
>> eprintRepository.java:219)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.container.BlueprintRepository.createAll(Blueprint
>> Repository.java:147)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
>> Components(BlueprintContainerImpl.java:624)[7:org.apache.aries.blueprint:0.2
>> .0.incubating]
>> ... 10 more
>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
RE: Void factory method
Posted by Timothy Ward <ti...@apache.org>.
I'm suggesting something that could possibly be used today - I don't believe it's particularly nice syntax, and it won't work for abstract classes or ones that you can't construct, but it might be possible to make progress without changes to the blueprint extender.
Regards,
Tim
----------------------------------------
> Subject: Re: Void factory method
> From: not@apache.org
> Date: Tue, 22 Feb 2011 22:26:08 +0000
> To: user@aries.apache.org
>
> I'm not sure I follow are you suggesting something that might work today or an alternative change?
>
> Alasdair Nottingham
>
> On 22 Feb 2011, at 22:21, Timothy Ward wrote:
>
> >
> > Hi,
> >
> > Just a query, but I'm assuming that we can't just new up an instance of the Server and inject into the static methods as if they were instance methods on a normal bean? I don't believe we do any checking to see whether property setters are static or not. This seems like it would be the simplest solution, and wouldn't involve adding a new namespace.
> >
> > Regards,
> >
> > Tim
> >
> > ----------------------------------------
> >> Date: Tue, 22 Feb 2011 21:08:14 +0100
> >> Subject: Re: Void factory method
> >> From: gnodet@gmail.com
> >> To: user@aries.apache.org
> >>
> >> As others have indicated, that's clearly outside of the specs.
> >> However, I see two different improvements we could add to Aries
> >> Blueprint to support such use cases:
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> or (maybe closer to the underlying jetty model):
> >>
> >>
> >> init-method="start" destroy-method="stop">
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> I haven't given that a lot of thoughts, and I'm not really sure how/if
> >> this can actually be implemented ...
> >> Both could actually be useful I suppose.
> >>
> >> 2011/2/22 Łukasz Dywicki :
> >>> Hello,
> >>> I have small problem with Aries. I try to configure jetty with blueprint.
> >>> Jetty requires to register some objects using void methods, for example:
> >>> Server.addConnector(Connector).
> >>>
> >>> I try to use blueprint XML:
> >>>
> >>>
> >>> init-method="start" destroy-method="stop"
> >>> />
> >>>
> >>>
> >>> depends-on="jersey">
> >>>
> >>>
> >>> class="org.eclipse.jetty.server.nio.SelectChannelConnector">
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> This configuration causes following error:
> >>> org.apache.aries.blueprint - 0.2.0.incubating | Unable to start blueprint
> >>> container for bundle jetty-server
> >>> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
> >>> instantiate components
> >>> at
> >>> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
> >>> Components(BlueprintContainerImpl.java:628)[7:org.apache.aries.blueprint:0.2
> >>> .0.incubating]
> >>> at
> >>> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintC
> >>> ontainerImpl.java:315)[7:org.apache.aries.blueprint:0.2.0.incubating]
> >>> at
> >>> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintCon
> >>> tainerImpl.java:213)[7:org.apache.aries.blueprint:0.2.0.incubating]
> >>> at
> >>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6
> >>> .0_21]
> >>> at
> >>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_21
> >>> ]
> >>> at
> >>> java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_21]
> >>> at
> >>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$
> >>> 301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_21]
> >>> at
> >>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Sch
> >>> eduledThreadPoolExecutor.java:207)[:1.6.0_21]
> >>> at
> >>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
> >>> va:886)[:1.6.0_21]
> >>> at
> >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
> >>> 08)[:1.6.0_21]
> >>> at java.lang.Thread.run(Thread.java:619)[:1.6.0_21]
> >>> Caused by: java.lang.NullPointerException
> >>> at
> >>> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)[:1.6.
> >>> 0_21]
> >>> at
> >>> org.apache.aries.blueprint.container.BlueprintRepository.addPartialObject(Bl
> >>> ueprintRepository.java:357)[7:org.apache.aries.blueprint:0.2.0.incubating]
> >>> at
> >>> org.apache.aries.blueprint.di.AbstractRecipe.addPartialObject(AbstractRecipe
> >>> .java:84)[7:org.apache.aries.blueprint:0.2.0.incubating]
> >>> at
> >>> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.ja
> >>> va:736)[7:org.apache.aries.blueprint:0.2.0.incubating]
> >>> at
> >>> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)[
> >>> 7:org.apache.aries.blueprint:0.2.0.incubating]
> >>> at
> >>> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(Blu
> >>> eprintRepository.java:219)[7:org.apache.aries.blueprint:0.2.0.incubating]
> >>> at
> >>> org.apache.aries.blueprint.container.BlueprintRepository.createAll(Blueprint
> >>> Repository.java:147)[7:org.apache.aries.blueprint:0.2.0.incubating]
> >>> at
> >>> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
> >>> Components(BlueprintContainerImpl.java:624)[7:org.apache.aries.blueprint:0.2
> >>> .0.incubating]
> >>> ... 10 more
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >> ------------------------
> >> Blog: http://gnodet.blogspot.com/
> >> ------------------------
> >> Open Source SOA
> >> http://fusesource.com
> >
Re: Void factory method
Posted by Alasdair Nottingham <no...@apache.org>.
I'm not sure I follow are you suggesting something that might work today or an alternative change?
Alasdair Nottingham
On 22 Feb 2011, at 22:21, Timothy Ward <ti...@apache.org> wrote:
>
> Hi,
>
> Just a query, but I'm assuming that we can't just new up an instance of the Server and inject into the static methods as if they were instance methods on a normal bean? I don't believe we do any checking to see whether property setters are static or not. This seems like it would be the simplest solution, and wouldn't involve adding a new namespace.
>
> Regards,
>
> Tim
>
> ----------------------------------------
>> Date: Tue, 22 Feb 2011 21:08:14 +0100
>> Subject: Re: Void factory method
>> From: gnodet@gmail.com
>> To: user@aries.apache.org
>>
>> As others have indicated, that's clearly outside of the specs.
>> However, I see two different improvements we could add to Aries
>> Blueprint to support such use cases:
>>
>>
>>
>>
>>
>>
>>
>> or (maybe closer to the underlying jetty model):
>>
>>
>> init-method="start" destroy-method="stop">
>>
>>
>>
>>
>>
>>
>>
>> I haven't given that a lot of thoughts, and I'm not really sure how/if
>> this can actually be implemented ...
>> Both could actually be useful I suppose.
>>
>> 2011/2/22 Łukasz Dywicki :
>>> Hello,
>>> I have small problem with Aries. I try to configure jetty with blueprint.
>>> Jetty requires to register some objects using void methods, for example:
>>> Server.addConnector(Connector).
>>>
>>> I try to use blueprint XML:
>>>
>>>
>>> init-method="start" destroy-method="stop"
>>> />
>>>
>>>
>>> depends-on="jersey">
>>>
>>>
>>> class="org.eclipse.jetty.server.nio.SelectChannelConnector">
>>>
>>>
>>>
>>>
>>>
>>>
>>> This configuration causes following error:
>>> org.apache.aries.blueprint - 0.2.0.incubating | Unable to start blueprint
>>> container for bundle jetty-server
>>> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
>>> instantiate components
>>> at
>>> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
>>> Components(BlueprintContainerImpl.java:628)[7:org.apache.aries.blueprint:0.2
>>> .0.incubating]
>>> at
>>> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintC
>>> ontainerImpl.java:315)[7:org.apache.aries.blueprint:0.2.0.incubating]
>>> at
>>> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintCon
>>> tainerImpl.java:213)[7:org.apache.aries.blueprint:0.2.0.incubating]
>>> at
>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6
>>> .0_21]
>>> at
>>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_21
>>> ]
>>> at
>>> java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_21]
>>> at
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$
>>> 301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_21]
>>> at
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Sch
>>> eduledThreadPoolExecutor.java:207)[:1.6.0_21]
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
>>> va:886)[:1.6.0_21]
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
>>> 08)[:1.6.0_21]
>>> at java.lang.Thread.run(Thread.java:619)[:1.6.0_21]
>>> Caused by: java.lang.NullPointerException
>>> at
>>> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)[:1.6.
>>> 0_21]
>>> at
>>> org.apache.aries.blueprint.container.BlueprintRepository.addPartialObject(Bl
>>> ueprintRepository.java:357)[7:org.apache.aries.blueprint:0.2.0.incubating]
>>> at
>>> org.apache.aries.blueprint.di.AbstractRecipe.addPartialObject(AbstractRecipe
>>> .java:84)[7:org.apache.aries.blueprint:0.2.0.incubating]
>>> at
>>> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.ja
>>> va:736)[7:org.apache.aries.blueprint:0.2.0.incubating]
>>> at
>>> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)[
>>> 7:org.apache.aries.blueprint:0.2.0.incubating]
>>> at
>>> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(Blu
>>> eprintRepository.java:219)[7:org.apache.aries.blueprint:0.2.0.incubating]
>>> at
>>> org.apache.aries.blueprint.container.BlueprintRepository.createAll(Blueprint
>>> Repository.java:147)[7:org.apache.aries.blueprint:0.2.0.incubating]
>>> at
>>> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
>>> Components(BlueprintContainerImpl.java:624)[7:org.apache.aries.blueprint:0.2
>>> .0.incubating]
>>> ... 10 more
>>>
>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>
RE: Void factory method
Posted by Timothy Ward <ti...@apache.org>.
Hi,
Just a query, but I'm assuming that we can't just new up an instance of the Server and inject into the static methods as if they were instance methods on a normal bean? I don't believe we do any checking to see whether property setters are static or not. This seems like it would be the simplest solution, and wouldn't involve adding a new namespace.
Regards,
Tim
----------------------------------------
> Date: Tue, 22 Feb 2011 21:08:14 +0100
> Subject: Re: Void factory method
> From: gnodet@gmail.com
> To: user@aries.apache.org
>
> As others have indicated, that's clearly outside of the specs.
> However, I see two different improvements we could add to Aries
> Blueprint to support such use cases:
>
>
>
>
>
>
>
> or (maybe closer to the underlying jetty model):
>
>
> init-method="start" destroy-method="stop">
>
>
>
>
>
>
>
> I haven't given that a lot of thoughts, and I'm not really sure how/if
> this can actually be implemented ...
> Both could actually be useful I suppose.
>
> 2011/2/22 Łukasz Dywicki :
> > Hello,
> > I have small problem with Aries. I try to configure jetty with blueprint.
> > Jetty requires to register some objects using void methods, for example:
> > Server.addConnector(Connector).
> >
> > I try to use blueprint XML:
> >
> >
> > init-method="start" destroy-method="stop"
> > />
> >
> >
> > depends-on="jersey">
> >
> >
> > class="org.eclipse.jetty.server.nio.SelectChannelConnector">
> >
> >
> >
> >
> >
> >
> > This configuration causes following error:
> > org.apache.aries.blueprint - 0.2.0.incubating | Unable to start blueprint
> > container for bundle jetty-server
> > org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
> > instantiate components
> > at
> > org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
> > Components(BlueprintContainerImpl.java:628)[7:org.apache.aries.blueprint:0.2
> > .0.incubating]
> > at
> > org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintC
> > ontainerImpl.java:315)[7:org.apache.aries.blueprint:0.2.0.incubating]
> > at
> > org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintCon
> > tainerImpl.java:213)[7:org.apache.aries.blueprint:0.2.0.incubating]
> > at
> > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6
> > .0_21]
> > at
> > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_21
> > ]
> > at
> > java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_21]
> > at
> > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$
> > 301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_21]
> > at
> > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Sch
> > eduledThreadPoolExecutor.java:207)[:1.6.0_21]
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
> > va:886)[:1.6.0_21]
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
> > 08)[:1.6.0_21]
> > at java.lang.Thread.run(Thread.java:619)[:1.6.0_21]
> > Caused by: java.lang.NullPointerException
> > at
> > java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)[:1.6.
> > 0_21]
> > at
> > org.apache.aries.blueprint.container.BlueprintRepository.addPartialObject(Bl
> > ueprintRepository.java:357)[7:org.apache.aries.blueprint:0.2.0.incubating]
> > at
> > org.apache.aries.blueprint.di.AbstractRecipe.addPartialObject(AbstractRecipe
> > .java:84)[7:org.apache.aries.blueprint:0.2.0.incubating]
> > at
> > org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.ja
> > va:736)[7:org.apache.aries.blueprint:0.2.0.incubating]
> > at
> > org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)[
> > 7:org.apache.aries.blueprint:0.2.0.incubating]
> > at
> > org.apache.aries.blueprint.container.BlueprintRepository.createInstances(Blu
> > eprintRepository.java:219)[7:org.apache.aries.blueprint:0.2.0.incubating]
> > at
> > org.apache.aries.blueprint.container.BlueprintRepository.createAll(Blueprint
> > Repository.java:147)[7:org.apache.aries.blueprint:0.2.0.incubating]
> > at
> > org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
> > Components(BlueprintContainerImpl.java:624)[7:org.apache.aries.blueprint:0.2
> > .0.incubating]
> > ... 10 more
> >
> >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Void factory method
Posted by Guillaume Nodet <gn...@gmail.com>.
As others have indicated, that's clearly outside of the specs.
However, I see two different improvements we could add to Aries
Blueprint to support such use cases:
<ext:call ref="server" method="addConnector">
<argument>
<bean .../>
</argument>
</ext:call>
or (maybe closer to the underlying jetty model):
<bean id="server" class="org.eclipse.jetty.server.Server"
init-method="start" destroy-method="stop">
<ext:list-property method="addConnector">
<list>
<bean .../>
</list>
</ext:list-property>
</bean>
I haven't given that a lot of thoughts, and I'm not really sure how/if
this can actually be implemented ...
Both could actually be useful I suppose.
2011/2/22 Łukasz Dywicki <lu...@code-house.org>:
> Hello,
> I have small problem with Aries. I try to configure jetty with blueprint.
> Jetty requires to register some objects using void methods, for example:
> Server.addConnector(Connector).
>
> I try to use blueprint XML:
>
> <bean id="server" class="org.eclipse.jetty.server.Server"
> init-method="start" destroy-method="stop"
> />
>
> <bean id="http" factory-ref="server" factory-method="addConnector"
> depends-on="jersey">
> <argument>
> <bean
> class="org.eclipse.jetty.server.nio.SelectChannelConnector">
> <property name="port" value="8080" />
> <property name="host" value="0.0.0.0" />
> </bean>
> </argument>
> </bean>
>
> This configuration causes following error:
> org.apache.aries.blueprint - 0.2.0.incubating | Unable to start blueprint
> container for bundle jetty-server
> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
> instantiate components
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
> Components(BlueprintContainerImpl.java:628)[7:org.apache.aries.blueprint:0.2
> .0.incubating]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintC
> ontainerImpl.java:315)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintCon
> tainerImpl.java:213)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6
> .0_21]
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_21
> ]
> at
> java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_21]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$
> 301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_21]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Sch
> eduledThreadPoolExecutor.java:207)[:1.6.0_21]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
> va:886)[:1.6.0_21]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
> 08)[:1.6.0_21]
> at java.lang.Thread.run(Thread.java:619)[:1.6.0_21]
> Caused by: java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)[:1.6.
> 0_21]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.addPartialObject(Bl
> ueprintRepository.java:357)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.addPartialObject(AbstractRecipe
> .java:84)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.ja
> va:736)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)[
> 7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(Blu
> eprintRepository.java:219)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(Blueprint
> Repository.java:147)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
> Components(BlueprintContainerImpl.java:624)[7:org.apache.aries.blueprint:0.2
> .0.incubating]
> ... 10 more
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Void factory method
Posted by Łukasz Dywicki <lu...@code-house.org>.
Hello,
I have small problem with Aries. I try to configure jetty with blueprint.
Jetty requires to register some objects using void methods, for example:
Server.addConnector(Connector).
I try to use blueprint XML:
<bean id="server" class="org.eclipse.jetty.server.Server"
init-method="start" destroy-method="stop"
/>
<bean id="http" factory-ref="server" factory-method="addConnector"
depends-on="jersey">
<argument>
<bean
class="org.eclipse.jetty.server.nio.SelectChannelConnector">
<property name="port" value="8080" />
<property name="host" value="0.0.0.0" />
</bean>
</argument>
</bean>
This configuration causes following error:
org.apache.aries.blueprint - 0.2.0.incubating | Unable to start blueprint
container for bundle jetty-server
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
instantiate components
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
Components(BlueprintContainerImpl.java:628)[7:org.apache.aries.blueprint:0.2
.0.incubating]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintC
ontainerImpl.java:315)[7:org.apache.aries.blueprint:0.2.0.incubating]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintCon
tainerImpl.java:213)[7:org.apache.aries.blueprint:0.2.0.incubating]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6
.0_21]
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_21
]
at
java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_21]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$
301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_21]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Sch
eduledThreadPoolExecutor.java:207)[:1.6.0_21]
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
va:886)[:1.6.0_21]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
08)[:1.6.0_21]
at java.lang.Thread.run(Thread.java:619)[:1.6.0_21]
Caused by: java.lang.NullPointerException
at
java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)[:1.6.
0_21]
at
org.apache.aries.blueprint.container.BlueprintRepository.addPartialObject(Bl
ueprintRepository.java:357)[7:org.apache.aries.blueprint:0.2.0.incubating]
at
org.apache.aries.blueprint.di.AbstractRecipe.addPartialObject(AbstractRecipe
.java:84)[7:org.apache.aries.blueprint:0.2.0.incubating]
at
org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.ja
va:736)[7:org.apache.aries.blueprint:0.2.0.incubating]
at
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)[
7:org.apache.aries.blueprint:0.2.0.incubating]
at
org.apache.aries.blueprint.container.BlueprintRepository.createInstances(Blu
eprintRepository.java:219)[7:org.apache.aries.blueprint:0.2.0.incubating]
at
org.apache.aries.blueprint.container.BlueprintRepository.createAll(Blueprint
Repository.java:147)[7:org.apache.aries.blueprint:0.2.0.incubating]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
Components(BlueprintContainerImpl.java:624)[7:org.apache.aries.blueprint:0.2
.0.incubating]
... 10 more
Re: bundleContext retrieval question
Posted by jamie campbell <ja...@parit.ca>.
On 11-02-21 01:42 AM, Alasdair Nottingham wrote:
> Hi,
>
> Have you considered using the FrameworkUtil? This will give you a bundle when you give it a class, and you can then get the bundle context.
Thanks Alasdair, this is exactly the creature I sought
-Jamie
Re: bundleContext retrieval question
Posted by Alasdair Nottingham <no...@apache.org>.
Hi,
Have you considered using the FrameworkUtil? This will give you a bundle when you give it a class, and you can then get the bundle context.
To answer your other question the osgi;framework/bundleContext is more intended for "hybrid" apps. That is apps which want to use the bundle context sometimes, but use the InitialContext class to do lookups.
Alasdair
Alasdair Nottingham
On 21 Feb 2011, at 00:12, jamie campbell <ja...@parit.ca> wrote:
> While I was poking around trying to solve a different jndi issue (which turned out to not be a jndi issue at all) I came across a possible solution to another bit of my architecture which is currently inelegant.
>
> Right now, bundles I'm developing tend to have a ContextHolder singleton that other classes in the same bundle use to get access to the BundleContext.
>
> in the osgi enterprise spec, pg 394/395, I found "A JNDI client can also obtain the BundleContext of the owning bundle by using the osgi: scheme namespace with the framework/bundleContext name. The following URL must return the Bundle Context of the owning bundle: osgi:framework/bundleContext "
>
> Does this mean "if you're lucky enough to already have the jndi service, retrieved by some other place that already had the bundle context, then you can get the bundle context too" or does it mean there's a jndi way of getting the bundle context without requiring service lookup (which would itself require the bundle context)?
>
> Or, I may be thinking about the problem wrong and there may be some other way of dumping the singleton I'm using. In other words, I might be missing something that's pretty foundational to OSGi programming, I'm not sure. I'm posting to this list because I found it in the osgi-enterprise-jndi section and aries is an osgi jndi implementer.. thoughts?
>
> -Jamie
Re: bundleContext retrieval question
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
I may be completely misunderstanding the question. But if you have the
Bundle (object) you get the BundleContext by just calling
Bundle.getBundleContext() ...
The owning bundle of Service can be obtained by calling
ServiceReference.getBundle().
Regards
Felix
Am Sonntag, den 20.02.2011, 18:12 -0600 schrieb jamie campbell:
> While I was poking around trying to solve a different jndi issue (which
> turned out to not be a jndi issue at all) I came across a possible
> solution to another bit of my architecture which is currently inelegant.
>
> Right now, bundles I'm developing tend to have a ContextHolder singleton
> that other classes in the same bundle use to get access to the
> BundleContext.
>
> in the osgi enterprise spec, pg 394/395, I found "A JNDI client can also
> obtain the BundleContext of the owning bundle by using the osgi: scheme
> namespace with the framework/bundleContext name. The following URL must
> return the Bundle Context of the owning bundle:
> osgi:framework/bundleContext "
>
> Does this mean "if you're lucky enough to already have the jndi service,
> retrieved by some other place that already had the bundle context, then
> you can get the bundle context too" or does it mean there's a jndi way
> of getting the bundle context without requiring service lookup (which
> would itself require the bundle context)?
>
> Or, I may be thinking about the problem wrong and there may be some
> other way of dumping the singleton I'm using. In other words, I might
> be missing something that's pretty foundational to OSGi programming, I'm
> not sure. I'm posting to this list because I found it in the
> osgi-enterprise-jndi section and aries is an osgi jndi implementer..
> thoughts?
>
> -Jamie