You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Atle Prange <at...@gmail.com> on 2010/07/31 22:58:18 UTC
Scala and osgi
Hi,
i am about to embark on a journey involving scala and osgi. But it appears
to me (ref. my last question on this list regarding static references) that
it might not be a good idea, since the otion of scala objects actually are
implemented as singletons, and therefor never will be cleaned up after a
bundle is unloaded. Does anybody here have experience with scala on osgi,
and could give me a hint on this matter?
-atle
Re: Scala and osgi
Posted by Peter Kriens <pe...@aqute.biz>.
Only RUNTIME annotations are imported because they're the only one that can cause imports ...
Kind regards,
Peter Kriens
On 19 nov 2010, at 17:05, Guillaume Nodet wrote:
> Note that loading a class with annotations while annotations are not
> available never result in a NoClassDefFoundError, annotations are
> simply discarded, so I'm not sure that a mandatory package should be
> generated, maybe an optional one though.
>
> On Fri, Nov 19, 2010 at 16:21, Justin Edelson <ju...@justinedelson.com> wrote:
>> Peter-
>> This is perhaps a bit of lazymail, but will bnd by default create an Import-Package statement for CLASS-retained annotations?
>>
>> In other words, if you had
>>
>> package foo;
>>
>> import bar.MyAnnotation;
>>
>> @MyAnnotation
>> public class MyClass {
>>
>> }
>>
>> Where bar.MyAnnotation has a RetentionPolicy of CLASS and is in a separate bundle, what Import-Package header for the bundle containing package foo will be generated by default?
>>
>> Thanks,
>> Justin
>>
>>
>> On Nov 19, 2010, at 8:58 AM, Peter Kriens wrote:
>>
>>> There is a class in bnd that can do this: aQute.lib.osgi.Clazz, it does not need access to the actual annotation classes.
>>>
>>> bnd uses CLASS annotations for its DS support because it is a lot easier to parse byte codes than source code.
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>>
>>> On 18 nov 2010, at 20:47, Felix Meschberger wrote:
>>>
>>>> Hi,
>>>>
>>>> Am Donnerstag, den 18.11.2010, 11:50 -0500 schrieb Justin Edelson:
>>>>> On Thu, Nov 18, 2010 at 3:35 AM, Felix Meschberger <fm...@gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Am Sonntag, den 01.08.2010, 14:07 +0200 schrieb Reto Bachmann-Gmuer:
>>>>>>> Hi Atle
>>>>>>>
>>>>>>> In the clerezza projects we're using more and more scala, the biggest
>>>>>>> disandvantage for me is that the maven-scr-plugin doesn't work for scala so
>>>>>>> I've to write the ds component descriptor by hand. We generallay don't use
>>>>>>> objects but classes, having ds caring about creating and activating the
>>>>>>> instances.
>>>>>>
>>>>>> I am by no means a Scala expert (whatever you will say now, but I am
>>>>>> just scared by the syntax ;-) )
>>>>>>
>>>>>> So, coming back to the scr-plugin problem: The plugin (currently) reads
>>>>>> the source files with the help of the QDox library. So I would assume
>>>>>> that the inability of the plugin to process Scala is related to this
>>>>>> situation.
>>>>>>
>>>>>> If you would know of a tool to read Scala source files for consumption
>>>>>> by the plugin, you are welcome to guide us there (or even better provide
>>>>>> a patch to use it ;-) ).
>>>>>>
>>>>>> I think a similar problem exists for Groovy (and yes, it would be nice
>>>>>> to have something there, too ;-) ).
>>>>>
>>>>> In theory, you might be able to use annotations (i.e. "real"
>>>>> annotations, not JavaDoc/QDox annotations). I've been planning on
>>>>> trying this technique with Groovy and maven-scr-plugin, but I haven't
>>>>> had the time to try it out. Beyond the fact that I personally prefer
>>>>> to use @Component instead of @scr.component, it just like parsing
>>>>> Scala (or Groovy) sources is far more complex than using the
>>>>> reflection API. To be clear, this is still going to require surgery to
>>>>> the scrplugin code, I just have a feeling that the surgery is going to
>>>>> more like foot surgery than brain surgery (if this metaphor makes
>>>>> sense).
>>>>
>>>> The point about having QDox also parse for the Annotations is, that the
>>>> Annotations are defined to not be added to the class files to not create
>>>> run-time dependencies and to not create class-file incompatibilities.
>>>>
>>>> Now, you may say we were over-cautious in this respect and another
>>>> retention policy would be viable (in terms of not creating runtime
>>>> dependencies), e.g. CLASS or even RUNTIME.
>>>>
>>>> If we can go with that, it should -- theoretically -- be possible to
>>>> actually read the annotations from the classes instead of using the QDox
>>>> parser.
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>>>
>>>>> Justin
>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Felix
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> reto
>>>>>>>
>>>>>>> On Sun, Aug 1, 2010 at 8:37 AM, Atle Prange <at...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Thank you for the replies, my journey can continue, although with a sligth
>>>>>>>> blow to my self esteem, i thought i was an experienced programmer, i guess
>>>>>>>> i
>>>>>>>> have to read more books....
>>>>>>>>
>>>>>>>>
>>>>>>>> -atle
>>>>>>>>
>>>>>>>> On Sat, Jul 31, 2010 at 11:02 PM, Christopher Brind <brindy@brindy.org.uk
>>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Have never used Scala myself, but Peter Kriens discussed this in his blog
>>>>>>>>> recently:
>>>>>>>>> http://www.osgi.org/blog/2010/07/scala-components-vs-osgi.html
>>>>>>>>>
>>>>>>>>> Hope it helps in some way.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 31 July 2010 21:58, Atle Prange <at...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> i am about to embark on a journey involving scala and osgi. But it
>>>>>>>>> appears
>>>>>>>>>> to me (ref. my last question on this list regarding static references)
>>>>>>>>> that
>>>>>>>>>> it might not be a good idea, since the otion of scala objects actually
>>>>>>>>> are
>>>>>>>>>> implemented as singletons, and therefor never will be cleaned up after
>>>>>>>> a
>>>>>>>>>> bundle is unloaded. Does anybody here have experience with scala on
>>>>>>>> osgi,
>>>>>>>>>> and could give me a hint on this matter?
>>>>>>>>>>
>>>>>>>>>> -atle
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle goes into Grace due to karaf shell
Posted by Guillaume Nodet <gn...@gmail.com>.
I think the manual is a bit outdated, but the following one should work:
http://karaf.apache.org/manual/2.1.99-SNAPSHOT/developers-guide/extending-console.html
FWIW, your problem is caused by a wrong namespace, if you change
http://felix.apache.org/karaf/xmlns/shell/v1.0.0
to
http://karaf.apache.org/xmlns/shell/v1.0.0
it should work better.
The namespace have changed since Karaf graduated as a TLP and so since
the 2.x version.
On Fri, Nov 19, 2010 at 18:56, Irad Dor <ir...@edgeci.com> wrote:
>
> Hi,
> I have been trying to follow the shell extension example here:
> http://karaf.apache.org/61-extending-the-console.html. This is on a
> 2.1.1 karaf server.
>
> When loading my bundle, it goes into grace period, and I see these
> messages when enabling debug on the log (below).
>
> It seems that the org.apache.karaf.shell.osgi is the issue.
>
> Can you help?
>
> Thanks,
> Irad.
>
> 19:13:43,097 | WARN | rint Extender: 3 | BlueprintContainerImpl
> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint
> - 0.2.0.incubating | Bundle load-server is waiting for namespace
> handlers
> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.servic
> e.blueprint.namespace=http://felix.apache.org/karaf/xmlns/shell/v1.0.0))
> ]
>
> 19:13:43,098 | DEBUG | rint Extender: 3 | BlueprintEventDispatcher
> | ntainer.BlueprintEventDispatcher 123 | 7 - org.apache.aries.blueprint
> - 0.2.0.incubating | Sending blueprint container event
> BlueprintEvent[type=GRACE_PERIOD,
> dependencies=[(&(objectClass=org.apache.aries.blueprint.NamespaceHandler
> )(osgi.service.blueprint.namespace=http://felix.apache.org/karaf/xmlns/s
> hell/v1.0.0))]] for bundle load-server
>
> 19:13:43,098 | DEBUG | nt Dispatcher: 1 | BlueprintListener
> | raf.shell.osgi.BlueprintListener 85 | 22 -
> org.apache.karaf.shell.osgi - 2.1.1 | Blueprint app state changed to
> GracePeriod for bundle 65
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Bundle goes into Grace due to karaf shell
Posted by Irad Dor <ir...@edgeci.com>.
Hi,
I have been trying to follow the shell extension example here:
http://karaf.apache.org/61-extending-the-console.html. This is on a
2.1.1 karaf server.
When loading my bundle, it goes into grace period, and I see these
messages when enabling debug on the log (below).
It seems that the org.apache.karaf.shell.osgi is the issue.
Can you help?
Thanks,
Irad.
19:13:43,097 | WARN | rint Extender: 3 | BlueprintContainerImpl
| container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint
- 0.2.0.incubating | Bundle load-server is waiting for namespace
handlers
[(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.servic
e.blueprint.namespace=http://felix.apache.org/karaf/xmlns/shell/v1.0.0))
]
19:13:43,098 | DEBUG | rint Extender: 3 | BlueprintEventDispatcher
| ntainer.BlueprintEventDispatcher 123 | 7 - org.apache.aries.blueprint
- 0.2.0.incubating | Sending blueprint container event
BlueprintEvent[type=GRACE_PERIOD,
dependencies=[(&(objectClass=org.apache.aries.blueprint.NamespaceHandler
)(osgi.service.blueprint.namespace=http://felix.apache.org/karaf/xmlns/s
hell/v1.0.0))]] for bundle load-server
19:13:43,098 | DEBUG | nt Dispatcher: 1 | BlueprintListener
| raf.shell.osgi.BlueprintListener 85 | 22 -
org.apache.karaf.shell.osgi - 2.1.1 | Blueprint app state changed to
GracePeriod for bundle 65
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scala and osgi
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Nov 19, 2010 at 17:20, Justin Edelson <ju...@gmail.com> wrote:
> Guillaume-
> I know this to be true (and have seen it with my own eyes), but I can't
> find where it's documented. Can you send me a link?
I've no idea, this is an empiric fact, but i suppose it's in the JLS doc:
http://java.sun.com/docs/books/jls/
I've had a quick look but could not find anything though.
> In any case, I agree with you that a mandatory package shouldn't be
> created. Ideally, an optional one would be created for RUNTIME or CLASS,
> but none for SOURCE.
Agreed.
>
> Thanks,
>
> Justin
>
>
> On 11/19/10 11:05 AM, Guillaume Nodet wrote:
>> Note that loading a class with annotations while annotations are not
>> available never result in a NoClassDefFoundError, annotations are
>> simply discarded, so I'm not sure that a mandatory package should be
>> generated, maybe an optional one though.
>>
>> On Fri, Nov 19, 2010 at 16:21, Justin Edelson <ju...@justinedelson.com> wrote:
>>> Peter-
>>> This is perhaps a bit of lazymail, but will bnd by default create an Import-Package statement for CLASS-retained annotations?
>>>
>>> In other words, if you had
>>>
>>> package foo;
>>>
>>> import bar.MyAnnotation;
>>>
>>> @MyAnnotation
>>> public class MyClass {
>>>
>>> }
>>>
>>> Where bar.MyAnnotation has a RetentionPolicy of CLASS and is in a separate bundle, what Import-Package header for the bundle containing package foo will be generated by default?
>>>
>>> Thanks,
>>> Justin
>>>
>>>
>>> On Nov 19, 2010, at 8:58 AM, Peter Kriens wrote:
>>>
>>>> There is a class in bnd that can do this: aQute.lib.osgi.Clazz, it does not need access to the actual annotation classes.
>>>>
>>>> bnd uses CLASS annotations for its DS support because it is a lot easier to parse byte codes than source code.
>>>>
>>>> Kind regards,
>>>>
>>>> Peter Kriens
>>>>
>>>>
>>>> On 18 nov 2010, at 20:47, Felix Meschberger wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Am Donnerstag, den 18.11.2010, 11:50 -0500 schrieb Justin Edelson:
>>>>>> On Thu, Nov 18, 2010 at 3:35 AM, Felix Meschberger <fm...@gmail.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Am Sonntag, den 01.08.2010, 14:07 +0200 schrieb Reto Bachmann-Gmuer:
>>>>>>>> Hi Atle
>>>>>>>>
>>>>>>>> In the clerezza projects we're using more and more scala, the biggest
>>>>>>>> disandvantage for me is that the maven-scr-plugin doesn't work for scala so
>>>>>>>> I've to write the ds component descriptor by hand. We generallay don't use
>>>>>>>> objects but classes, having ds caring about creating and activating the
>>>>>>>> instances.
>>>>>>>
>>>>>>> I am by no means a Scala expert (whatever you will say now, but I am
>>>>>>> just scared by the syntax ;-) )
>>>>>>>
>>>>>>> So, coming back to the scr-plugin problem: The plugin (currently) reads
>>>>>>> the source files with the help of the QDox library. So I would assume
>>>>>>> that the inability of the plugin to process Scala is related to this
>>>>>>> situation.
>>>>>>>
>>>>>>> If you would know of a tool to read Scala source files for consumption
>>>>>>> by the plugin, you are welcome to guide us there (or even better provide
>>>>>>> a patch to use it ;-) ).
>>>>>>>
>>>>>>> I think a similar problem exists for Groovy (and yes, it would be nice
>>>>>>> to have something there, too ;-) ).
>>>>>>
>>>>>> In theory, you might be able to use annotations (i.e. "real"
>>>>>> annotations, not JavaDoc/QDox annotations). I've been planning on
>>>>>> trying this technique with Groovy and maven-scr-plugin, but I haven't
>>>>>> had the time to try it out. Beyond the fact that I personally prefer
>>>>>> to use @Component instead of @scr.component, it just like parsing
>>>>>> Scala (or Groovy) sources is far more complex than using the
>>>>>> reflection API. To be clear, this is still going to require surgery to
>>>>>> the scrplugin code, I just have a feeling that the surgery is going to
>>>>>> more like foot surgery than brain surgery (if this metaphor makes
>>>>>> sense).
>>>>>
>>>>> The point about having QDox also parse for the Annotations is, that the
>>>>> Annotations are defined to not be added to the class files to not create
>>>>> run-time dependencies and to not create class-file incompatibilities.
>>>>>
>>>>> Now, you may say we were over-cautious in this respect and another
>>>>> retention policy would be viable (in terms of not creating runtime
>>>>> dependencies), e.g. CLASS or even RUNTIME.
>>>>>
>>>>> If we can go with that, it should -- theoretically -- be possible to
>>>>> actually read the annotations from the classes instead of using the QDox
>>>>> parser.
>>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>>>
>>>>>> Justin
>>>>>>
>>>>>>>
>>>>>>> Regards
>>>>>>> Felix
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> reto
>>>>>>>>
>>>>>>>> On Sun, Aug 1, 2010 at 8:37 AM, Atle Prange <at...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Thank you for the replies, my journey can continue, although with a sligth
>>>>>>>>> blow to my self esteem, i thought i was an experienced programmer, i guess
>>>>>>>>> i
>>>>>>>>> have to read more books....
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -atle
>>>>>>>>>
>>>>>>>>> On Sat, Jul 31, 2010 at 11:02 PM, Christopher Brind <brindy@brindy.org.uk
>>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Have never used Scala myself, but Peter Kriens discussed this in his blog
>>>>>>>>>> recently:
>>>>>>>>>> http://www.osgi.org/blog/2010/07/scala-components-vs-osgi.html
>>>>>>>>>>
>>>>>>>>>> Hope it helps in some way.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Chris
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 31 July 2010 21:58, Atle Prange <at...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> i am about to embark on a journey involving scala and osgi. But it
>>>>>>>>>> appears
>>>>>>>>>>> to me (ref. my last question on this list regarding static references)
>>>>>>>>>> that
>>>>>>>>>>> it might not be a good idea, since the otion of scala objects actually
>>>>>>>>>> are
>>>>>>>>>>> implemented as singletons, and therefor never will be cleaned up after
>>>>>>>>> a
>>>>>>>>>>> bundle is unloaded. Does anybody here have experience with scala on
>>>>>>>>> osgi,
>>>>>>>>>>> and could give me a hint on this matter?
>>>>>>>>>>>
>>>>>>>>>>> -atle
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scala and osgi
Posted by Justin Edelson <ju...@gmail.com>.
Guillaume-
I know this to be true (and have seen it with my own eyes), but I can't
find where it's documented. Can you send me a link?
In any case, I agree with you that a mandatory package shouldn't be
created. Ideally, an optional one would be created for RUNTIME or CLASS,
but none for SOURCE.
Thanks,
Justin
On 11/19/10 11:05 AM, Guillaume Nodet wrote:
> Note that loading a class with annotations while annotations are not
> available never result in a NoClassDefFoundError, annotations are
> simply discarded, so I'm not sure that a mandatory package should be
> generated, maybe an optional one though.
>
> On Fri, Nov 19, 2010 at 16:21, Justin Edelson <ju...@justinedelson.com> wrote:
>> Peter-
>> This is perhaps a bit of lazymail, but will bnd by default create an Import-Package statement for CLASS-retained annotations?
>>
>> In other words, if you had
>>
>> package foo;
>>
>> import bar.MyAnnotation;
>>
>> @MyAnnotation
>> public class MyClass {
>>
>> }
>>
>> Where bar.MyAnnotation has a RetentionPolicy of CLASS and is in a separate bundle, what Import-Package header for the bundle containing package foo will be generated by default?
>>
>> Thanks,
>> Justin
>>
>>
>> On Nov 19, 2010, at 8:58 AM, Peter Kriens wrote:
>>
>>> There is a class in bnd that can do this: aQute.lib.osgi.Clazz, it does not need access to the actual annotation classes.
>>>
>>> bnd uses CLASS annotations for its DS support because it is a lot easier to parse byte codes than source code.
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>>
>>> On 18 nov 2010, at 20:47, Felix Meschberger wrote:
>>>
>>>> Hi,
>>>>
>>>> Am Donnerstag, den 18.11.2010, 11:50 -0500 schrieb Justin Edelson:
>>>>> On Thu, Nov 18, 2010 at 3:35 AM, Felix Meschberger <fm...@gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Am Sonntag, den 01.08.2010, 14:07 +0200 schrieb Reto Bachmann-Gmuer:
>>>>>>> Hi Atle
>>>>>>>
>>>>>>> In the clerezza projects we're using more and more scala, the biggest
>>>>>>> disandvantage for me is that the maven-scr-plugin doesn't work for scala so
>>>>>>> I've to write the ds component descriptor by hand. We generallay don't use
>>>>>>> objects but classes, having ds caring about creating and activating the
>>>>>>> instances.
>>>>>>
>>>>>> I am by no means a Scala expert (whatever you will say now, but I am
>>>>>> just scared by the syntax ;-) )
>>>>>>
>>>>>> So, coming back to the scr-plugin problem: The plugin (currently) reads
>>>>>> the source files with the help of the QDox library. So I would assume
>>>>>> that the inability of the plugin to process Scala is related to this
>>>>>> situation.
>>>>>>
>>>>>> If you would know of a tool to read Scala source files for consumption
>>>>>> by the plugin, you are welcome to guide us there (or even better provide
>>>>>> a patch to use it ;-) ).
>>>>>>
>>>>>> I think a similar problem exists for Groovy (and yes, it would be nice
>>>>>> to have something there, too ;-) ).
>>>>>
>>>>> In theory, you might be able to use annotations (i.e. "real"
>>>>> annotations, not JavaDoc/QDox annotations). I've been planning on
>>>>> trying this technique with Groovy and maven-scr-plugin, but I haven't
>>>>> had the time to try it out. Beyond the fact that I personally prefer
>>>>> to use @Component instead of @scr.component, it just like parsing
>>>>> Scala (or Groovy) sources is far more complex than using the
>>>>> reflection API. To be clear, this is still going to require surgery to
>>>>> the scrplugin code, I just have a feeling that the surgery is going to
>>>>> more like foot surgery than brain surgery (if this metaphor makes
>>>>> sense).
>>>>
>>>> The point about having QDox also parse for the Annotations is, that the
>>>> Annotations are defined to not be added to the class files to not create
>>>> run-time dependencies and to not create class-file incompatibilities.
>>>>
>>>> Now, you may say we were over-cautious in this respect and another
>>>> retention policy would be viable (in terms of not creating runtime
>>>> dependencies), e.g. CLASS or even RUNTIME.
>>>>
>>>> If we can go with that, it should -- theoretically -- be possible to
>>>> actually read the annotations from the classes instead of using the QDox
>>>> parser.
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>>>
>>>>> Justin
>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Felix
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> reto
>>>>>>>
>>>>>>> On Sun, Aug 1, 2010 at 8:37 AM, Atle Prange <at...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Thank you for the replies, my journey can continue, although with a sligth
>>>>>>>> blow to my self esteem, i thought i was an experienced programmer, i guess
>>>>>>>> i
>>>>>>>> have to read more books....
>>>>>>>>
>>>>>>>>
>>>>>>>> -atle
>>>>>>>>
>>>>>>>> On Sat, Jul 31, 2010 at 11:02 PM, Christopher Brind <brindy@brindy.org.uk
>>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Have never used Scala myself, but Peter Kriens discussed this in his blog
>>>>>>>>> recently:
>>>>>>>>> http://www.osgi.org/blog/2010/07/scala-components-vs-osgi.html
>>>>>>>>>
>>>>>>>>> Hope it helps in some way.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 31 July 2010 21:58, Atle Prange <at...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> i am about to embark on a journey involving scala and osgi. But it
>>>>>>>>> appears
>>>>>>>>>> to me (ref. my last question on this list regarding static references)
>>>>>>>>> that
>>>>>>>>>> it might not be a good idea, since the otion of scala objects actually
>>>>>>>>> are
>>>>>>>>>> implemented as singletons, and therefor never will be cleaned up after
>>>>>>>> a
>>>>>>>>>> bundle is unloaded. Does anybody here have experience with scala on
>>>>>>>> osgi,
>>>>>>>>>> and could give me a hint on this matter?
>>>>>>>>>>
>>>>>>>>>> -atle
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scala and osgi
Posted by Guillaume Nodet <gn...@gmail.com>.
Note that loading a class with annotations while annotations are not
available never result in a NoClassDefFoundError, annotations are
simply discarded, so I'm not sure that a mandatory package should be
generated, maybe an optional one though.
On Fri, Nov 19, 2010 at 16:21, Justin Edelson <ju...@justinedelson.com> wrote:
> Peter-
> This is perhaps a bit of lazymail, but will bnd by default create an Import-Package statement for CLASS-retained annotations?
>
> In other words, if you had
>
> package foo;
>
> import bar.MyAnnotation;
>
> @MyAnnotation
> public class MyClass {
>
> }
>
> Where bar.MyAnnotation has a RetentionPolicy of CLASS and is in a separate bundle, what Import-Package header for the bundle containing package foo will be generated by default?
>
> Thanks,
> Justin
>
>
> On Nov 19, 2010, at 8:58 AM, Peter Kriens wrote:
>
>> There is a class in bnd that can do this: aQute.lib.osgi.Clazz, it does not need access to the actual annotation classes.
>>
>> bnd uses CLASS annotations for its DS support because it is a lot easier to parse byte codes than source code.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>> On 18 nov 2010, at 20:47, Felix Meschberger wrote:
>>
>>> Hi,
>>>
>>> Am Donnerstag, den 18.11.2010, 11:50 -0500 schrieb Justin Edelson:
>>>> On Thu, Nov 18, 2010 at 3:35 AM, Felix Meschberger <fm...@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> Am Sonntag, den 01.08.2010, 14:07 +0200 schrieb Reto Bachmann-Gmuer:
>>>>>> Hi Atle
>>>>>>
>>>>>> In the clerezza projects we're using more and more scala, the biggest
>>>>>> disandvantage for me is that the maven-scr-plugin doesn't work for scala so
>>>>>> I've to write the ds component descriptor by hand. We generallay don't use
>>>>>> objects but classes, having ds caring about creating and activating the
>>>>>> instances.
>>>>>
>>>>> I am by no means a Scala expert (whatever you will say now, but I am
>>>>> just scared by the syntax ;-) )
>>>>>
>>>>> So, coming back to the scr-plugin problem: The plugin (currently) reads
>>>>> the source files with the help of the QDox library. So I would assume
>>>>> that the inability of the plugin to process Scala is related to this
>>>>> situation.
>>>>>
>>>>> If you would know of a tool to read Scala source files for consumption
>>>>> by the plugin, you are welcome to guide us there (or even better provide
>>>>> a patch to use it ;-) ).
>>>>>
>>>>> I think a similar problem exists for Groovy (and yes, it would be nice
>>>>> to have something there, too ;-) ).
>>>>
>>>> In theory, you might be able to use annotations (i.e. "real"
>>>> annotations, not JavaDoc/QDox annotations). I've been planning on
>>>> trying this technique with Groovy and maven-scr-plugin, but I haven't
>>>> had the time to try it out. Beyond the fact that I personally prefer
>>>> to use @Component instead of @scr.component, it just like parsing
>>>> Scala (or Groovy) sources is far more complex than using the
>>>> reflection API. To be clear, this is still going to require surgery to
>>>> the scrplugin code, I just have a feeling that the surgery is going to
>>>> more like foot surgery than brain surgery (if this metaphor makes
>>>> sense).
>>>
>>> The point about having QDox also parse for the Annotations is, that the
>>> Annotations are defined to not be added to the class files to not create
>>> run-time dependencies and to not create class-file incompatibilities.
>>>
>>> Now, you may say we were over-cautious in this respect and another
>>> retention policy would be viable (in terms of not creating runtime
>>> dependencies), e.g. CLASS or even RUNTIME.
>>>
>>> If we can go with that, it should -- theoretically -- be possible to
>>> actually read the annotations from the classes instead of using the QDox
>>> parser.
>>>
>>> Regards
>>> Felix
>>>
>>>>
>>>> Justin
>>>>
>>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> reto
>>>>>>
>>>>>> On Sun, Aug 1, 2010 at 8:37 AM, Atle Prange <at...@gmail.com> wrote:
>>>>>>
>>>>>>> Thank you for the replies, my journey can continue, although with a sligth
>>>>>>> blow to my self esteem, i thought i was an experienced programmer, i guess
>>>>>>> i
>>>>>>> have to read more books....
>>>>>>>
>>>>>>>
>>>>>>> -atle
>>>>>>>
>>>>>>> On Sat, Jul 31, 2010 at 11:02 PM, Christopher Brind <brindy@brindy.org.uk
>>>>>>>> wrote:
>>>>>>>
>>>>>>>> Have never used Scala myself, but Peter Kriens discussed this in his blog
>>>>>>>> recently:
>>>>>>>> http://www.osgi.org/blog/2010/07/scala-components-vs-osgi.html
>>>>>>>>
>>>>>>>> Hope it helps in some way.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Chris
>>>>>>>>
>>>>>>>>
>>>>>>>> On 31 July 2010 21:58, Atle Prange <at...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> i am about to embark on a journey involving scala and osgi. But it
>>>>>>>> appears
>>>>>>>>> to me (ref. my last question on this list regarding static references)
>>>>>>>> that
>>>>>>>>> it might not be a good idea, since the otion of scala objects actually
>>>>>>>> are
>>>>>>>>> implemented as singletons, and therefor never will be cleaned up after
>>>>>>> a
>>>>>>>>> bundle is unloaded. Does anybody here have experience with scala on
>>>>>>> osgi,
>>>>>>>>> and could give me a hint on this matter?
>>>>>>>>>
>>>>>>>>> -atle
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scala and osgi
Posted by Justin Edelson <ju...@justinedelson.com>.
Peter-
This is perhaps a bit of lazymail, but will bnd by default create an Import-Package statement for CLASS-retained annotations?
In other words, if you had
package foo;
import bar.MyAnnotation;
@MyAnnotation
public class MyClass {
}
Where bar.MyAnnotation has a RetentionPolicy of CLASS and is in a separate bundle, what Import-Package header for the bundle containing package foo will be generated by default?
Thanks,
Justin
On Nov 19, 2010, at 8:58 AM, Peter Kriens wrote:
> There is a class in bnd that can do this: aQute.lib.osgi.Clazz, it does not need access to the actual annotation classes.
>
> bnd uses CLASS annotations for its DS support because it is a lot easier to parse byte codes than source code.
>
> Kind regards,
>
> Peter Kriens
>
>
> On 18 nov 2010, at 20:47, Felix Meschberger wrote:
>
>> Hi,
>>
>> Am Donnerstag, den 18.11.2010, 11:50 -0500 schrieb Justin Edelson:
>>> On Thu, Nov 18, 2010 at 3:35 AM, Felix Meschberger <fm...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> Am Sonntag, den 01.08.2010, 14:07 +0200 schrieb Reto Bachmann-Gmuer:
>>>>> Hi Atle
>>>>>
>>>>> In the clerezza projects we're using more and more scala, the biggest
>>>>> disandvantage for me is that the maven-scr-plugin doesn't work for scala so
>>>>> I've to write the ds component descriptor by hand. We generallay don't use
>>>>> objects but classes, having ds caring about creating and activating the
>>>>> instances.
>>>>
>>>> I am by no means a Scala expert (whatever you will say now, but I am
>>>> just scared by the syntax ;-) )
>>>>
>>>> So, coming back to the scr-plugin problem: The plugin (currently) reads
>>>> the source files with the help of the QDox library. So I would assume
>>>> that the inability of the plugin to process Scala is related to this
>>>> situation.
>>>>
>>>> If you would know of a tool to read Scala source files for consumption
>>>> by the plugin, you are welcome to guide us there (or even better provide
>>>> a patch to use it ;-) ).
>>>>
>>>> I think a similar problem exists for Groovy (and yes, it would be nice
>>>> to have something there, too ;-) ).
>>>
>>> In theory, you might be able to use annotations (i.e. "real"
>>> annotations, not JavaDoc/QDox annotations). I've been planning on
>>> trying this technique with Groovy and maven-scr-plugin, but I haven't
>>> had the time to try it out. Beyond the fact that I personally prefer
>>> to use @Component instead of @scr.component, it just like parsing
>>> Scala (or Groovy) sources is far more complex than using the
>>> reflection API. To be clear, this is still going to require surgery to
>>> the scrplugin code, I just have a feeling that the surgery is going to
>>> more like foot surgery than brain surgery (if this metaphor makes
>>> sense).
>>
>> The point about having QDox also parse for the Annotations is, that the
>> Annotations are defined to not be added to the class files to not create
>> run-time dependencies and to not create class-file incompatibilities.
>>
>> Now, you may say we were over-cautious in this respect and another
>> retention policy would be viable (in terms of not creating runtime
>> dependencies), e.g. CLASS or even RUNTIME.
>>
>> If we can go with that, it should -- theoretically -- be possible to
>> actually read the annotations from the classes instead of using the QDox
>> parser.
>>
>> Regards
>> Felix
>>
>>>
>>> Justin
>>>
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>> reto
>>>>>
>>>>> On Sun, Aug 1, 2010 at 8:37 AM, Atle Prange <at...@gmail.com> wrote:
>>>>>
>>>>>> Thank you for the replies, my journey can continue, although with a sligth
>>>>>> blow to my self esteem, i thought i was an experienced programmer, i guess
>>>>>> i
>>>>>> have to read more books....
>>>>>>
>>>>>>
>>>>>> -atle
>>>>>>
>>>>>> On Sat, Jul 31, 2010 at 11:02 PM, Christopher Brind <brindy@brindy.org.uk
>>>>>>> wrote:
>>>>>>
>>>>>>> Have never used Scala myself, but Peter Kriens discussed this in his blog
>>>>>>> recently:
>>>>>>> http://www.osgi.org/blog/2010/07/scala-components-vs-osgi.html
>>>>>>>
>>>>>>> Hope it helps in some way.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>> On 31 July 2010 21:58, Atle Prange <at...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> i am about to embark on a journey involving scala and osgi. But it
>>>>>>> appears
>>>>>>>> to me (ref. my last question on this list regarding static references)
>>>>>>> that
>>>>>>>> it might not be a good idea, since the otion of scala objects actually
>>>>>>> are
>>>>>>>> implemented as singletons, and therefor never will be cleaned up after
>>>>>> a
>>>>>>>> bundle is unloaded. Does anybody here have experience with scala on
>>>>>> osgi,
>>>>>>>> and could give me a hint on this matter?
>>>>>>>>
>>>>>>>> -atle
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scala and osgi
Posted by Peter Kriens <pe...@aqute.biz>.
There is a class in bnd that can do this: aQute.lib.osgi.Clazz, it does not need access to the actual annotation classes.
bnd uses CLASS annotations for its DS support because it is a lot easier to parse byte codes than source code.
Kind regards,
Peter Kriens
On 18 nov 2010, at 20:47, Felix Meschberger wrote:
> Hi,
>
> Am Donnerstag, den 18.11.2010, 11:50 -0500 schrieb Justin Edelson:
>> On Thu, Nov 18, 2010 at 3:35 AM, Felix Meschberger <fm...@gmail.com> wrote:
>>> Hi,
>>>
>>> Am Sonntag, den 01.08.2010, 14:07 +0200 schrieb Reto Bachmann-Gmuer:
>>>> Hi Atle
>>>>
>>>> In the clerezza projects we're using more and more scala, the biggest
>>>> disandvantage for me is that the maven-scr-plugin doesn't work for scala so
>>>> I've to write the ds component descriptor by hand. We generallay don't use
>>>> objects but classes, having ds caring about creating and activating the
>>>> instances.
>>>
>>> I am by no means a Scala expert (whatever you will say now, but I am
>>> just scared by the syntax ;-) )
>>>
>>> So, coming back to the scr-plugin problem: The plugin (currently) reads
>>> the source files with the help of the QDox library. So I would assume
>>> that the inability of the plugin to process Scala is related to this
>>> situation.
>>>
>>> If you would know of a tool to read Scala source files for consumption
>>> by the plugin, you are welcome to guide us there (or even better provide
>>> a patch to use it ;-) ).
>>>
>>> I think a similar problem exists for Groovy (and yes, it would be nice
>>> to have something there, too ;-) ).
>>
>> In theory, you might be able to use annotations (i.e. "real"
>> annotations, not JavaDoc/QDox annotations). I've been planning on
>> trying this technique with Groovy and maven-scr-plugin, but I haven't
>> had the time to try it out. Beyond the fact that I personally prefer
>> to use @Component instead of @scr.component, it just like parsing
>> Scala (or Groovy) sources is far more complex than using the
>> reflection API. To be clear, this is still going to require surgery to
>> the scrplugin code, I just have a feeling that the surgery is going to
>> more like foot surgery than brain surgery (if this metaphor makes
>> sense).
>
> The point about having QDox also parse for the Annotations is, that the
> Annotations are defined to not be added to the class files to not create
> run-time dependencies and to not create class-file incompatibilities.
>
> Now, you may say we were over-cautious in this respect and another
> retention policy would be viable (in terms of not creating runtime
> dependencies), e.g. CLASS or even RUNTIME.
>
> If we can go with that, it should -- theoretically -- be possible to
> actually read the annotations from the classes instead of using the QDox
> parser.
>
> Regards
> Felix
>
>>
>> Justin
>>
>>>
>>> Regards
>>> Felix
>>>
>>>>
>>>>
>>>> Cheers,
>>>> reto
>>>>
>>>> On Sun, Aug 1, 2010 at 8:37 AM, Atle Prange <at...@gmail.com> wrote:
>>>>
>>>>> Thank you for the replies, my journey can continue, although with a sligth
>>>>> blow to my self esteem, i thought i was an experienced programmer, i guess
>>>>> i
>>>>> have to read more books....
>>>>>
>>>>>
>>>>> -atle
>>>>>
>>>>> On Sat, Jul 31, 2010 at 11:02 PM, Christopher Brind <brindy@brindy.org.uk
>>>>>> wrote:
>>>>>
>>>>>> Have never used Scala myself, but Peter Kriens discussed this in his blog
>>>>>> recently:
>>>>>> http://www.osgi.org/blog/2010/07/scala-components-vs-osgi.html
>>>>>>
>>>>>> Hope it helps in some way.
>>>>>>
>>>>>> Cheers,
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>> On 31 July 2010 21:58, Atle Prange <at...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> i am about to embark on a journey involving scala and osgi. But it
>>>>>> appears
>>>>>>> to me (ref. my last question on this list regarding static references)
>>>>>> that
>>>>>>> it might not be a good idea, since the otion of scala objects actually
>>>>>> are
>>>>>>> implemented as singletons, and therefor never will be cleaned up after
>>>>> a
>>>>>>> bundle is unloaded. Does anybody here have experience with scala on
>>>>> osgi,
>>>>>>> and could give me a hint on this matter?
>>>>>>>
>>>>>>> -atle
>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scala and osgi
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Donnerstag, den 18.11.2010, 11:50 -0500 schrieb Justin Edelson:
> On Thu, Nov 18, 2010 at 3:35 AM, Felix Meschberger <fm...@gmail.com> wrote:
> > Hi,
> >
> > Am Sonntag, den 01.08.2010, 14:07 +0200 schrieb Reto Bachmann-Gmuer:
> >> Hi Atle
> >>
> >> In the clerezza projects we're using more and more scala, the biggest
> >> disandvantage for me is that the maven-scr-plugin doesn't work for scala so
> >> I've to write the ds component descriptor by hand. We generallay don't use
> >> objects but classes, having ds caring about creating and activating the
> >> instances.
> >
> > I am by no means a Scala expert (whatever you will say now, but I am
> > just scared by the syntax ;-) )
> >
> > So, coming back to the scr-plugin problem: The plugin (currently) reads
> > the source files with the help of the QDox library. So I would assume
> > that the inability of the plugin to process Scala is related to this
> > situation.
> >
> > If you would know of a tool to read Scala source files for consumption
> > by the plugin, you are welcome to guide us there (or even better provide
> > a patch to use it ;-) ).
> >
> > I think a similar problem exists for Groovy (and yes, it would be nice
> > to have something there, too ;-) ).
>
> In theory, you might be able to use annotations (i.e. "real"
> annotations, not JavaDoc/QDox annotations). I've been planning on
> trying this technique with Groovy and maven-scr-plugin, but I haven't
> had the time to try it out. Beyond the fact that I personally prefer
> to use @Component instead of @scr.component, it just like parsing
> Scala (or Groovy) sources is far more complex than using the
> reflection API. To be clear, this is still going to require surgery to
> the scrplugin code, I just have a feeling that the surgery is going to
> more like foot surgery than brain surgery (if this metaphor makes
> sense).
The point about having QDox also parse for the Annotations is, that the
Annotations are defined to not be added to the class files to not create
run-time dependencies and to not create class-file incompatibilities.
Now, you may say we were over-cautious in this respect and another
retention policy would be viable (in terms of not creating runtime
dependencies), e.g. CLASS or even RUNTIME.
If we can go with that, it should -- theoretically -- be possible to
actually read the annotations from the classes instead of using the QDox
parser.
Regards
Felix
>
> Justin
>
> >
> > Regards
> > Felix
> >
> >>
> >>
> >> Cheers,
> >> reto
> >>
> >> On Sun, Aug 1, 2010 at 8:37 AM, Atle Prange <at...@gmail.com> wrote:
> >>
> >> > Thank you for the replies, my journey can continue, although with a sligth
> >> > blow to my self esteem, i thought i was an experienced programmer, i guess
> >> > i
> >> > have to read more books....
> >> >
> >> >
> >> > -atle
> >> >
> >> > On Sat, Jul 31, 2010 at 11:02 PM, Christopher Brind <brindy@brindy.org.uk
> >> > >wrote:
> >> >
> >> > > Have never used Scala myself, but Peter Kriens discussed this in his blog
> >> > > recently:
> >> > > http://www.osgi.org/blog/2010/07/scala-components-vs-osgi.html
> >> > >
> >> > > Hope it helps in some way.
> >> > >
> >> > > Cheers,
> >> > > Chris
> >> > >
> >> > >
> >> > > On 31 July 2010 21:58, Atle Prange <at...@gmail.com> wrote:
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > i am about to embark on a journey involving scala and osgi. But it
> >> > > appears
> >> > > > to me (ref. my last question on this list regarding static references)
> >> > > that
> >> > > > it might not be a good idea, since the otion of scala objects actually
> >> > > are
> >> > > > implemented as singletons, and therefor never will be cleaned up after
> >> > a
> >> > > > bundle is unloaded. Does anybody here have experience with scala on
> >> > osgi,
> >> > > > and could give me a hint on this matter?
> >> > > >
> >> > > > -atle
> >> > > >
> >> > >
> >> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scala and osgi
Posted by Justin Edelson <ju...@justinedelson.com>.
On Thu, Nov 18, 2010 at 3:35 AM, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Am Sonntag, den 01.08.2010, 14:07 +0200 schrieb Reto Bachmann-Gmuer:
>> Hi Atle
>>
>> In the clerezza projects we're using more and more scala, the biggest
>> disandvantage for me is that the maven-scr-plugin doesn't work for scala so
>> I've to write the ds component descriptor by hand. We generallay don't use
>> objects but classes, having ds caring about creating and activating the
>> instances.
>
> I am by no means a Scala expert (whatever you will say now, but I am
> just scared by the syntax ;-) )
>
> So, coming back to the scr-plugin problem: The plugin (currently) reads
> the source files with the help of the QDox library. So I would assume
> that the inability of the plugin to process Scala is related to this
> situation.
>
> If you would know of a tool to read Scala source files for consumption
> by the plugin, you are welcome to guide us there (or even better provide
> a patch to use it ;-) ).
>
> I think a similar problem exists for Groovy (and yes, it would be nice
> to have something there, too ;-) ).
In theory, you might be able to use annotations (i.e. "real"
annotations, not JavaDoc/QDox annotations). I've been planning on
trying this technique with Groovy and maven-scr-plugin, but I haven't
had the time to try it out. Beyond the fact that I personally prefer
to use @Component instead of @scr.component, it just like parsing
Scala (or Groovy) sources is far more complex than using the
reflection API. To be clear, this is still going to require surgery to
the scrplugin code, I just have a feeling that the surgery is going to
more like foot surgery than brain surgery (if this metaphor makes
sense).
Justin
>
> Regards
> Felix
>
>>
>>
>> Cheers,
>> reto
>>
>> On Sun, Aug 1, 2010 at 8:37 AM, Atle Prange <at...@gmail.com> wrote:
>>
>> > Thank you for the replies, my journey can continue, although with a sligth
>> > blow to my self esteem, i thought i was an experienced programmer, i guess
>> > i
>> > have to read more books....
>> >
>> >
>> > -atle
>> >
>> > On Sat, Jul 31, 2010 at 11:02 PM, Christopher Brind <brindy@brindy.org.uk
>> > >wrote:
>> >
>> > > Have never used Scala myself, but Peter Kriens discussed this in his blog
>> > > recently:
>> > > http://www.osgi.org/blog/2010/07/scala-components-vs-osgi.html
>> > >
>> > > Hope it helps in some way.
>> > >
>> > > Cheers,
>> > > Chris
>> > >
>> > >
>> > > On 31 July 2010 21:58, Atle Prange <at...@gmail.com> wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > i am about to embark on a journey involving scala and osgi. But it
>> > > appears
>> > > > to me (ref. my last question on this list regarding static references)
>> > > that
>> > > > it might not be a good idea, since the otion of scala objects actually
>> > > are
>> > > > implemented as singletons, and therefor never will be cleaned up after
>> > a
>> > > > bundle is unloaded. Does anybody here have experience with scala on
>> > osgi,
>> > > > and could give me a hint on this matter?
>> > > >
>> > > > -atle
>> > > >
>> > >
>> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scala and osgi
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Sonntag, den 01.08.2010, 14:07 +0200 schrieb Reto Bachmann-Gmuer:
> Hi Atle
>
> In the clerezza projects we're using more and more scala, the biggest
> disandvantage for me is that the maven-scr-plugin doesn't work for scala so
> I've to write the ds component descriptor by hand. We generallay don't use
> objects but classes, having ds caring about creating and activating the
> instances.
I am by no means a Scala expert (whatever you will say now, but I am
just scared by the syntax ;-) )
So, coming back to the scr-plugin problem: The plugin (currently) reads
the source files with the help of the QDox library. So I would assume
that the inability of the plugin to process Scala is related to this
situation.
If you would know of a tool to read Scala source files for consumption
by the plugin, you are welcome to guide us there (or even better provide
a patch to use it ;-) ).
I think a similar problem exists for Groovy (and yes, it would be nice
to have something there, too ;-) ).
Regards
Felix
>
>
> Cheers,
> reto
>
> On Sun, Aug 1, 2010 at 8:37 AM, Atle Prange <at...@gmail.com> wrote:
>
> > Thank you for the replies, my journey can continue, although with a sligth
> > blow to my self esteem, i thought i was an experienced programmer, i guess
> > i
> > have to read more books....
> >
> >
> > -atle
> >
> > On Sat, Jul 31, 2010 at 11:02 PM, Christopher Brind <brindy@brindy.org.uk
> > >wrote:
> >
> > > Have never used Scala myself, but Peter Kriens discussed this in his blog
> > > recently:
> > > http://www.osgi.org/blog/2010/07/scala-components-vs-osgi.html
> > >
> > > Hope it helps in some way.
> > >
> > > Cheers,
> > > Chris
> > >
> > >
> > > On 31 July 2010 21:58, Atle Prange <at...@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > i am about to embark on a journey involving scala and osgi. But it
> > > appears
> > > > to me (ref. my last question on this list regarding static references)
> > > that
> > > > it might not be a good idea, since the otion of scala objects actually
> > > are
> > > > implemented as singletons, and therefor never will be cleaned up after
> > a
> > > > bundle is unloaded. Does anybody here have experience with scala on
> > osgi,
> > > > and could give me a hint on this matter?
> > > >
> > > > -atle
> > > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scala and osgi
Posted by Reto Bachmann-Gmuer <re...@trialox.org>.
Hi Atle
In the clerezza projects we're using more and more scala, the biggest
disandvantage for me is that the maven-scr-plugin doesn't work for scala so
I've to write the ds component descriptor by hand. We generallay don't use
objects but classes, having ds caring about creating and activating the
instances.
Cheers,
reto
On Sun, Aug 1, 2010 at 8:37 AM, Atle Prange <at...@gmail.com> wrote:
> Thank you for the replies, my journey can continue, although with a sligth
> blow to my self esteem, i thought i was an experienced programmer, i guess
> i
> have to read more books....
>
>
> -atle
>
> On Sat, Jul 31, 2010 at 11:02 PM, Christopher Brind <brindy@brindy.org.uk
> >wrote:
>
> > Have never used Scala myself, but Peter Kriens discussed this in his blog
> > recently:
> > http://www.osgi.org/blog/2010/07/scala-components-vs-osgi.html
> >
> > Hope it helps in some way.
> >
> > Cheers,
> > Chris
> >
> >
> > On 31 July 2010 21:58, Atle Prange <at...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > i am about to embark on a journey involving scala and osgi. But it
> > appears
> > > to me (ref. my last question on this list regarding static references)
> > that
> > > it might not be a good idea, since the otion of scala objects actually
> > are
> > > implemented as singletons, and therefor never will be cleaned up after
> a
> > > bundle is unloaded. Does anybody here have experience with scala on
> osgi,
> > > and could give me a hint on this matter?
> > >
> > > -atle
> > >
> >
>
Re: Scala and osgi
Posted by Atle Prange <at...@gmail.com>.
Thank you for the replies, my journey can continue, although with a sligth
blow to my self esteem, i thought i was an experienced programmer, i guess i
have to read more books....
-atle
On Sat, Jul 31, 2010 at 11:02 PM, Christopher Brind <br...@brindy.org.uk>wrote:
> Have never used Scala myself, but Peter Kriens discussed this in his blog
> recently:
> http://www.osgi.org/blog/2010/07/scala-components-vs-osgi.html
>
> Hope it helps in some way.
>
> Cheers,
> Chris
>
>
> On 31 July 2010 21:58, Atle Prange <at...@gmail.com> wrote:
>
> > Hi,
> >
> > i am about to embark on a journey involving scala and osgi. But it
> appears
> > to me (ref. my last question on this list regarding static references)
> that
> > it might not be a good idea, since the otion of scala objects actually
> are
> > implemented as singletons, and therefor never will be cleaned up after a
> > bundle is unloaded. Does anybody here have experience with scala on osgi,
> > and could give me a hint on this matter?
> >
> > -atle
> >
>
Re: Scala and osgi
Posted by Christopher Brind <br...@brindy.org.uk>.
Have never used Scala myself, but Peter Kriens discussed this in his blog
recently:
http://www.osgi.org/blog/2010/07/scala-components-vs-osgi.html
Hope it helps in some way.
Cheers,
Chris
On 31 July 2010 21:58, Atle Prange <at...@gmail.com> wrote:
> Hi,
>
> i am about to embark on a journey involving scala and osgi. But it appears
> to me (ref. my last question on this list regarding static references) that
> it might not be a good idea, since the otion of scala objects actually are
> implemented as singletons, and therefor never will be cleaned up after a
> bundle is unloaded. Does anybody here have experience with scala on osgi,
> and could give me a hint on this matter?
>
> -atle
>
Re: Scala and osgi
Posted by Andreas Kollegger <ak...@tembopublic.org>.
Scala singleton objects are implemented as a final java class with a static initializer that doesn't behave any differently under OSGi than a plain old java class with similar methods and initialization.
If I understand your concern, you're implying that singleton objects exist in a separate thread of some kind, with their own lifecycle, which may get orphaned when you unload a bundle. But, they don't, so it's not a problem.
See [1] for a brief look inside scala singleton objects.
/Andreas
[1] http://pbadenski.blogspot.com/2009/06/design-patterns-in-scala-singleton.html
On Jul 31, 2010, at 4:58 PM, Atle Prange wrote:
> Hi,
>
> i am about to embark on a journey involving scala and osgi. But it appears
> to me (ref. my last question on this list regarding static references) that
> it might not be a good idea, since the otion of scala objects actually are
> implemented as singletons, and therefor never will be cleaned up after a
> bundle is unloaded. Does anybody here have experience with scala on osgi,
> and could give me a hint on this matter?
>
> -atle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org