Re: [Karaf] Moving Karaf svn into Felix
L.S., From what I read so far, I'm definitely +1 on going with org.apache.karaf as a package name. BTW, just shout if you need an extra hand for the package rename operation. For the JIRA, I agree with Guillaume that a bulk move operation won't work between different instances. The only thing we can do to ease the effort somehow is export the issues to e.g. CSV and do an import in the target JIRA. While I can help out with preparing the CSV file, I don't have admin rights on the target JIRA so we'd need someone to do the import. Couldn't we make the ServiceMix Kernel JIRA read-only/hidden for now and provide a link back to the original issues for looking up comments, creators, watchers, ...? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/4/25 Guillaume Nodet gno...@gmail.com: On Sat, Apr 25, 2009 at 00:14, Marcel Offermans marcel.offerm...@luminis.nl wrote: On Apr 24, 2009, at 23:45 , Felix Meschberger wrote: Marcel Offermans schrieb: About JIRA, I don't think trying to migrate the current issues makes a lot of sense. There really aren't any good tools for that as far as I know. I could live with Karaf sticking with the current JIRA or perhaps slowly migrating towards the Felix JIRA (but only for new issues, leave existing ones where they are now). Hmm, I think migration of the issues from one project to another is a trivial thing in JIRA. We would have to watch out for assigned components/versions, but basically it is not that complicated. That's good to know. Does that include people who have created an account in JIRA and are watching specific issues? Unfortunately, this only work inside the same JIRA instance. The current jira issues are hosted at: https://issues.apache.org/activemq/browse/SMX4KNL whereas felix is at https://issues.apache.org/jira/browse/FELIX So I don't think we'll be able to move the issues at all. It's only possible to move them to another project hosted on the same instance :-( And: it is only for the open issues. We probably don't want to move the closed ones, just like we probably don't move the past releases, tags and branches Agreed. We don't have too many opened issues right now (36 actually) so it may be doable to recreate them, but we'll loose creator / watchers / comments if any. Greetings, Marcel -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Created: (FELIX-1057) stopping bundle causes NPE
stopping bundle causes NPE -- Key: FELIX-1057 URL: https://issues.apache.org/jira/browse/FELIX-1057 Project: Felix Issue Type: Bug Components: Remote Shell Affects Versions: shell.remote-1.0.4 Reporter: Peter Doornbosch Priority: Minor Stopping the remote shell bundle itself remotely, causes a NPE: Exception in thread telnetconsole.shell remote=/127.0.0.1:56512 java.lang.NullPointerException at org.apache.felix.shell.remote.TerminalPrintStream.print(TerminalPrintStream.java:52) I admit that stopping the bundle itself over the remote connection may seem like a silly use case, but under circumstances it is necessary (to release the socket). The NPE is causes by Activator.getServices() returning null. The fix is trivial: ServiceMediator services = Activator.getServices(); if (services != null) services.error(...) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1010) add java annotation support to felix-scr-plugin
[
https://issues.apache.org/jira/browse/FELIX-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12702681#action_12702681
]
Stefan Seifert commented on FELIX-1010:
---
the perfact way would be to define the value annotation attribut as Object[].
but this is not allowed, only primitive types and String is allowed for an
annotation property.
when using plain annotations a workaround like
@Property(value=MY_DEFAULT_VALUE+)
would work, although ugly and still the property type has to be specified
separately.
an expression like
@Property(value=Integer.toString(MY_DEFAULT_VALUE))
does not work because the compiler rates this as not a constant expression.
but event the workaround with MY_DEFAULT_VALUE+ does not work right now,
because the property values of the annotation are not read via the java
annotation support, which evalutes the expression automatically and returns the
computed valued, but with qdox which returns only the plain string including
the formula. perhaps a way for interpreting it dynamically can be found, but
this still prevents correct type detection from the property's value itself.
yes, this is a limitation compared to the qdox style attributes. i've no other
ideas yet than to add different primitive typed properties.
add java annotation support to felix-scr-plugin
---
Key: FELIX-1010
URL: https://issues.apache.org/jira/browse/FELIX-1010
Project: Felix
Issue Type: New Feature
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.0.10
Reporter: Stefan Seifert
Assignee: Carsten Ziegeler
Fix For: maven-scr-plugin-1.0.11
Attachments: 090329_felix_scrplugin_annotationsupport.patch,
090406_component_patch.patch, 090423_property_sorted_map.patch,
FELIX-1010.patch, scrplugin_annot_090422.patch
goals of this proposal:
- allow definition of SCR components with java annotations instead of QDox
tags
- advantages: strong typing, auto-completion and jump to source documentation
in modern IDEs
- support built-in annotations with 1:1 matching the old scr.* tags, and
allow definition of custom annotations for other felix/scr-based projects to
minimalize syntax overhead
- the QDox tags are still supported, but cannot be mixed with annotations
whithing the same source file
attached to this ticket is a full implemented and tested patch, that supports
all feates supported by the scr.* QDox tags today. some of the more exotic
features are not tested in detail, only the generated descriptors where
compared.
i created a new project scrplugin-annotations, that contains only the
annotations for easy referencing without unwanted transitive dependencies.
i'm not sure if the package and artifact name are well chosen.
Example 1
-
QDox version:
/**
* Service class with QDox annotations.
*
* @scr.component
* @scr.property name=testProperty value=testValue
* @scr.service
*/
public class MinimalServiceQDox implements {
...
Annotation version:
/**
* Service class with java annotations.
*/
@Component
@Property(name = testProperty, value = testValue)
@Service
public class MinimalServiceAnnotations {
...
Example 2
-
QDox version:
/**
* Service class with QDox annotations.
*
* @scr.component name=QDoxName label=theLabel
description=theDescription
*immediate=false enabled=false factory=xx.yy.zz
* @scr.service interface=org.osgi.service.component.ComponentInstance
* servicefactory=true
* @scr.service interface=java.lang.Readable
* @scr.property name=stringProp value=theValue label=thePropLabel
* description=thePropDesc options 0=option0 1=option1
* 2=option2
* @scr.property name=intProp value=5 type=Integer
* @scr.property name=multiProp values.0=multiValue1
values.1=multiValue2
*/
public class ServiceQDox implements ComponentInstance, Readable {
/**
* @scr.reference cardinality=0..1, dynamic=true
*/
MinimalServiceQDox reference;
...
Annotation version:
/**
* Service class with java annotations.
*/
@Component(name = AnnotName, label = theLabel, description =
theDescription, immediate = false, enabled = false, factory = xx.yy.zz)
@Services( { @Service(value = ComponentInstance.class, serviceFactory =
true), @Service(Readable.class) })
@Properties( {
@Property(name = stringProp, value = theValue, label =
thePropLabel, description = thePropDesc, options = {
@PropertyOption(name = 0, value = option0),
@PropertyOption(name = 1, value = option1),
@PropertyOption(name = 2, value = option2) }),
@Property(name = intProp, value = 5, type = Integer.class),
@Property(name = multiProp, value = {
[jira] Commented: (FELIX-1010) add java annotation support to felix-scr-plugin
[
https://issues.apache.org/jira/browse/FELIX-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12702682#action_12702682
]
Stefan Seifert commented on FELIX-1010:
---
in my tests even using simple String constants did not work, but results in a
error in qdox parsing engine.
example:
@Component
@Properties( {
@Property(name = ServiceValueRefAnnotations.STRINGPROP_NAME, value =
ServiceValueRefAnnotations.STRINGPROP_VALUE),
@Property(name = ServiceValueRefAnnotations.MULTIPROP_NAME, value = {
ServiceValueRefAnnotations.MULTIPROP_VALUE1,
ServiceValueRefAnnotations.MULTIPROP_VALUE2 })
})
public class ServiceValueRefAnnotations {
public static final String STRINGPROP_NAME = stringProp;
public static final String STRINGPROP_VALUE = theValue;
private static final String MULTIPROP_NAME = multiProp;
private static final String MULTIPROP_VALUE1 = multiValue1;
private static final String MULTIPROP_VALUE2 = multiValue2;
}
results in:
com.thoughtworks.qdox.parser.ParseException: syntax error @[31,5] in
scrplugin-testproject/src/main/java/org/testproject/valuerefs/ServiceValueRefAnnotations.java
at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:987)
at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:1293)
at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:968)
at
com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:317)
at
com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:349)
at
com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:345)
at
com.thoughtworks.qdox.JavaDocBuilder$2.visitFile(JavaDocBuilder.java:435)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:43)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.scan(DirectoryScanner.java:52)
at
com.thoughtworks.qdox.JavaDocBuilder.addSourceTree(JavaDocBuilder.java:432)
at
com.thoughtworks.qdox.JavaDocBuilder.addSourceTree(JavaDocBuilder.java:421)
at
org.apache.felix.scrplugin.tags.JavaClassDescriptorManager.init(JavaClassDescriptorManager.java:155)
at
org.apache.felix.scrplugin.SCRDescriptorMojo.execute(SCRDescriptorMojo.java:139)
it seems that the qdox annotation support is limited or broken here?
add java annotation support to felix-scr-plugin
---
Key: FELIX-1010
URL: https://issues.apache.org/jira/browse/FELIX-1010
Project: Felix
Issue Type: New Feature
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.0.10
Reporter: Stefan Seifert
Assignee: Carsten Ziegeler
Fix For: maven-scr-plugin-1.0.11
Attachments: 090329_felix_scrplugin_annotationsupport.patch,
090406_component_patch.patch, 090423_property_sorted_map.patch,
FELIX-1010.patch, scrplugin_annot_090422.patch
goals of this proposal:
- allow definition of SCR components with java annotations instead of QDox
tags
- advantages: strong typing, auto-completion and jump to source documentation
in modern IDEs
- support built-in annotations with 1:1 matching the old scr.* tags, and
allow definition of custom annotations for other felix/scr-based projects to
minimalize syntax overhead
- the QDox tags are still supported, but cannot be mixed with annotations
whithing the same source file
attached to this ticket is a full implemented and tested patch, that supports
all feates supported by the scr.* QDox tags today. some of the more exotic
features are not tested in detail, only the generated descriptors where
compared.
i created a new project scrplugin-annotations, that contains only the
annotations for easy referencing without unwanted transitive dependencies.
i'm not sure if the package and artifact name are well chosen.
Example 1
-
QDox version:
/**
* Service class with QDox annotations.
*
* @scr.component
* @scr.property name=testProperty value=testValue
* @scr.service
*/
public class MinimalServiceQDox implements {
...
Annotation version:
/**
* Service class with java annotations.
*/
@Component
@Property(name = testProperty, value = testValue)
@Service
public class MinimalServiceAnnotations {
...
Example 2
-
QDox version:
/**
* Service class with QDox annotations.
*
* @scr.component name=QDoxName
[jira] Commented: (FELIX-1010) add java annotation support to felix-scr-plugin
[
https://issues.apache.org/jira/browse/FELIX-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12702686#action_12702686
]
Stefan Seifert commented on FELIX-1010:
---
update for last comment: there are strange differences in this area between
eclipse compiler and sun jdk javac compiler.
if all static fields in the sample above are declared as public, it works. the
eclipse compiler accepts private static fields in annotation references as
well, but not the sun compiler.
beware of any comment marking inside the annotation tags like this:
@Properties( {
/* this is a property */
@Property(name = ServiceValueRefAnnotations.STRINGPROP_NAME, value =
ServiceValueRefAnnotations.STRINGPROP_VALUE)
})
this breaks the qdox annotation parser and results in a qdox exception as
listed in the comment before.
add java annotation support to felix-scr-plugin
---
Key: FELIX-1010
URL: https://issues.apache.org/jira/browse/FELIX-1010
Project: Felix
Issue Type: New Feature
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.0.10
Reporter: Stefan Seifert
Assignee: Carsten Ziegeler
Fix For: maven-scr-plugin-1.0.11
Attachments: 090329_felix_scrplugin_annotationsupport.patch,
090406_component_patch.patch, 090423_property_sorted_map.patch,
FELIX-1010.patch, scrplugin_annot_090422.patch
goals of this proposal:
- allow definition of SCR components with java annotations instead of QDox
tags
- advantages: strong typing, auto-completion and jump to source documentation
in modern IDEs
- support built-in annotations with 1:1 matching the old scr.* tags, and
allow definition of custom annotations for other felix/scr-based projects to
minimalize syntax overhead
- the QDox tags are still supported, but cannot be mixed with annotations
whithing the same source file
attached to this ticket is a full implemented and tested patch, that supports
all feates supported by the scr.* QDox tags today. some of the more exotic
features are not tested in detail, only the generated descriptors where
compared.
i created a new project scrplugin-annotations, that contains only the
annotations for easy referencing without unwanted transitive dependencies.
i'm not sure if the package and artifact name are well chosen.
Example 1
-
QDox version:
/**
* Service class with QDox annotations.
*
* @scr.component
* @scr.property name=testProperty value=testValue
* @scr.service
*/
public class MinimalServiceQDox implements {
...
Annotation version:
/**
* Service class with java annotations.
*/
@Component
@Property(name = testProperty, value = testValue)
@Service
public class MinimalServiceAnnotations {
...
Example 2
-
QDox version:
/**
* Service class with QDox annotations.
*
* @scr.component name=QDoxName label=theLabel
description=theDescription
*immediate=false enabled=false factory=xx.yy.zz
* @scr.service interface=org.osgi.service.component.ComponentInstance
* servicefactory=true
* @scr.service interface=java.lang.Readable
* @scr.property name=stringProp value=theValue label=thePropLabel
* description=thePropDesc options 0=option0 1=option1
* 2=option2
* @scr.property name=intProp value=5 type=Integer
* @scr.property name=multiProp values.0=multiValue1
values.1=multiValue2
*/
public class ServiceQDox implements ComponentInstance, Readable {
/**
* @scr.reference cardinality=0..1, dynamic=true
*/
MinimalServiceQDox reference;
...
Annotation version:
/**
* Service class with java annotations.
*/
@Component(name = AnnotName, label = theLabel, description =
theDescription, immediate = false, enabled = false, factory = xx.yy.zz)
@Services( { @Service(value = ComponentInstance.class, serviceFactory =
true), @Service(Readable.class) })
@Properties( {
@Property(name = stringProp, value = theValue, label =
thePropLabel, description = thePropDesc, options = {
@PropertyOption(name = 0, value = option0),
@PropertyOption(name = 1, value = option1),
@PropertyOption(name = 2, value = option2) }),
@Property(name = intProp, value = 5, type = Integer.class),
@Property(name = multiProp, value = { multiValue1, multiValue2
}) })
public class ServiceAnnotations implements ComponentInstance, Readable {
@Reference(cardinality = ReferenceCardinality.ZERO_TO_ONE, policy =
ReferencePolicy.DYNAMIC)
MinimalServiceAnnotations reference;
...
Example 3 - using Custom Annotation from other project
--
QDox version:
/**
* Sample servlet with sling mappings.
*
* @scr.component
[jira] Resolved: (FELIX-1057) stopping bundle causes NPE
[ https://issues.apache.org/jira/browse/FELIX-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall resolved FELIX-1057. Resolution: Fixed Fix Version/s: shell.remote-1.0.5 Ok, it turned out to not be so trivial. I could have done the fix you suggested, but the root of the issue was a little uglier since it was using a static-based approach to allow it to pass services around to all classes in the bundle; I highly recommend against this approach. Also, there were a handful of concurrency issues and service tracking was not correct. I ended up pulling that code and just using ServiceTrackers to track log and shell services. Please run remote shell through its paces to make sure I didn't break anything else, but at least your issue is now gone after a few hours of work. :-) Close this issue when you are satisfied. Thanks. stopping bundle causes NPE -- Key: FELIX-1057 URL: https://issues.apache.org/jira/browse/FELIX-1057 Project: Felix Issue Type: Bug Components: Remote Shell Affects Versions: shell.remote-1.0.4 Reporter: Peter Doornbosch Assignee: Richard S. Hall Priority: Minor Fix For: shell.remote-1.0.5 Stopping the remote shell bundle itself remotely, causes a NPE: Exception in thread telnetconsole.shell remote=/127.0.0.1:56512 java.lang.NullPointerException at org.apache.felix.shell.remote.TerminalPrintStream.print(TerminalPrintStream.java:52) I admit that stopping the bundle itself over the remote connection may seem like a silly use case, but under circumstances it is necessary (to release the socket). The NPE is causes by Activator.getServices() returning null. The fix is trivial: ServiceMediator services = Activator.getServices(); if (services != null) services.error(...) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1057) stopping bundle causes NPE
[ https://issues.apache.org/jira/browse/FELIX-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Doornbosch closed FELIX-1057. --- Yeah, i noticed the concurrency issues too, but didn't want to be a nag ;-). Thanks for fixing this. Keep up the good work! stopping bundle causes NPE -- Key: FELIX-1057 URL: https://issues.apache.org/jira/browse/FELIX-1057 Project: Felix Issue Type: Bug Components: Remote Shell Affects Versions: shell.remote-1.0.4 Reporter: Peter Doornbosch Assignee: Richard S. Hall Priority: Minor Fix For: shell.remote-1.0.5 Stopping the remote shell bundle itself remotely, causes a NPE: Exception in thread telnetconsole.shell remote=/127.0.0.1:56512 java.lang.NullPointerException at org.apache.felix.shell.remote.TerminalPrintStream.print(TerminalPrintStream.java:52) I admit that stopping the bundle itself over the remote connection may seem like a silly use case, but under circumstances it is necessary (to release the socket). The NPE is causes by Activator.getServices() returning null. The fix is trivial: ServiceMediator services = Activator.getServices(); if (services != null) services.error(...) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
