Re: [VOTE] Release fileinstall 2.0.10, gogo 0.4.0, bundlerepository 1.6.2, bundleplugin 2.1.0
+1 (non-binding) -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org On Mon, May 3, 2010 at 4:14 PM, Gert Vanthienen gert.vanthie...@gmail.comwrote: +1 (non-binding) Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 3 May 2010 17:52, Richard S. Hall he...@ungoverned.org wrote: +1 for OBR: * It's NOTICE file says it includes OSGi code, but it doesn't. * The changelog hasn't been updated since 1.4.3. +1 for bundleplugin: * It's NOTICE file also says it includes OSGi code, but it doesn't. * NOTICE file copyright year is still 2009. * The changelog hasn't been updated. +1 for Gogo: * Commands, console, and runtime should depend on the official OSGi JAR files, not the Felix ones. * Commands' NOTICE file also says it includes OSGi code, but it doesn't. * Commands, console, launcher, and runtime NOTICE file copyright year is still 2009. * Launcher JAR includes OSGi classes, but only says it uses them. Clearly, we have some NOTICE file issues and we still need to change the way we deal with NOTICE files. Did we ever come to a conclusion how to handle this? We also apparently need to update our release process to document the inclusion of changelogs and make this consistent across releases. - richard On 4/29/10 14:47, Guillaume Nodet wrote: I would like to call a vote on the following subproject releases: fileinstall 2.0.10 gogo 0.4.0 bundlerepository 1.6.2 bundleplugin 2.1.0 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-034/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 034 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
Re: [gogo] Parameter annotations (Re: svn commit: r940514 - in /felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command: Flag.java Option.java)
A few things that would be missing imho to make that interesting:
* parameters annotation to mark parameters as optional or multi-valued
* flag and option could be merged (they are the same, maybe use an enum
value on the annotation to differentiate them and maybe have a smart default
value based on the fact that the annotated parameter is a boolean or not)
* option should support a list of value
* options should have multiple names (annotations support String[] quite
well)
* if we want to add some help information, we need an annotation on the
method
* we have a nice coercion mechanism defined in blueprint (handling
generics, collections and such), we should reuse it (without having a
dependency to blueprint)
On Mon, May 3, 2010 at 23:25, Richard S. Hall he...@ungoverned.org wrote:
On 5/3/10 16:56, Guillaume Nodet wrote:
On Mon, May 3, 2010 at 21:17, Richard S. Hallhe...@ungoverned.org
wrote:
On 5/3/10 14:51, Guillaume Nodet wrote:
What are those annotations suppose to actually provide ? It seems all
they
can do is provide some basic help to the user, but does not really help
the
user writing complex commands and dealing with complex arguments.
Have a look at an existing example:
http://svn.apache.org/repos/asf/felix/trunk/karaf/shell/commands/src/main/java/org/apache/felix/karaf/shell/commands/GrepAction.java
I think those annotations would not provide the slightest help in
analyzing
such a command line.
I don't think there will ever be a single solution that can help everyone
implement any possible command. If people need to do something that is
super
complex, then they can always fall back to parsing their own arguments.
I can agree to that, but then I don't see why it has to be in the proposed
spec. Having it as a separate module might be a better approach then.
The issue is you cannot easily do what we are trying to achieve in a
separate module since it is modifying how the runtime coerces arguments when
invoking methods. There is no place to hook into this externally. However, I
agree that it could be just an implementation-specific feature of the Gogo
runtime.
I actually talked with Peter specifically about this and he felt the
feature might be worthwhile for the spec, which is why he committed it
there, but nothing is set in stone at this point.
- richard
At this point, we're just messing around with allowing optional method
parameters and out of order specification of arguments.
- richard
On Mon, May 3, 2010 at 19:01,pkri...@apache.org wrote:
Author: pkriens
Date: Mon May 3 17:01:53 2010
New Revision: 940514
URL: http://svn.apache.org/viewvc?rev=940514view=rev
Log:
Annotations for parameters
Added:
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Option.java
Added:
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java
URL:
http://svn.apache.org/viewvc/felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java?rev=940514view=auto
==
---
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java
(added)
+++
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java
Mon May 3 17:01:53 2010
@@ -0,0 +1,6 @@
+package org.osgi.service.command;
+
+public @interface Flag {
+ String name();
+ String help() default no help;
+}
Added:
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Option.java
URL:
http://svn.apache.org/viewvc/felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Option.java?rev=940514view=auto
==
---
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Option.java
(added)
+++
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Option.java
Mon May 3 17:01:53 2010
@@ -0,0 +1,6 @@
+package org.osgi.service.command;
+
+public @interface Option {
+ String name();
+ String dflt();
+}
--
Cheers,
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
[jira] Commented: (FELIX-2292) Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331)
[ https://issues.apache.org/jira/browse/FELIX-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863697#action_12863697 ] Rob Walker commented on FELIX-2292: --- I'm working in this area at present, so if everyone is happy we go for this I'm happy to apply Jonathan's patch and also update the POM version to 2.1-SNAPSHOT (or should that be 2.1.0-SNAPSHOT?) Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331) -- Key: FELIX-2292 URL: https://issues.apache.org/jira/browse/FELIX-2292 Project: Felix Issue Type: Improvement Components: HTTP Service Reporter: Jonathan Bardin Fix For: http-2.1.0 Attachments: jetty7.patch, jetty7GoodFormat.patch Hi, This is a small improvement of the Http Service in order to use jetty 7.0.2 (org.eclipse.jetty 7.0.2v20100331). The patch is following. Regards, Jonathan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2292) Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331)
[ https://issues.apache.org/jira/browse/FELIX-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863712#action_12863712 ] Rob Walker commented on FELIX-2292: --- Thinking about this some more - I wonder if there is anyone who would prefer a later Jetty6 release prior to the Jetty7 one? If so, we could do a stepwise upgrade from 6.1.21 to the latest Jetty6 (6.1.24) under say 2.0.6-SNAPSHOT prior to committing the jetty 7 changes under a 2.1.0-SNAPSHOT. Obviously this is something of a half-solution - since we're still making an actual cutover point using this approach, albeit at the current latest Jetty6 version. If anyone had longer term interests in staying on Jetty6, we'd need to figure a way to have parallel options e.g. move the current code to a jetty6 package for those wanting that version. I doubt it's much of an issue - just something to consider Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331) -- Key: FELIX-2292 URL: https://issues.apache.org/jira/browse/FELIX-2292 Project: Felix Issue Type: Improvement Components: HTTP Service Reporter: Jonathan Bardin Fix For: http-2.1.0 Attachments: jetty7.patch, jetty7GoodFormat.patch Hi, This is a small improvement of the Http Service in order to use jetty 7.0.2 (org.eclipse.jetty 7.0.2v20100331). The patch is following. Regards, Jonathan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release fileinstall 3.0.0 (2nd try)
+1 (non-binding) Freeman On 2010-5-1, at 下午3:03, Guillaume Nodet wrote: I would like to call a vote on the following subproject releases: fileinstall 3.0.0 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-039/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 039 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Freeman Fang Open Source SOA: http://fusesource.com
Re: [VOTE] Release fileinstall 2.0.10, gogo 0.4.0, bundlerepository 1.6.2, bundleplugin 2.1.0
+1 (non-binding) Thanks Freeman On 2010-4-30, at 上午2:47, Guillaume Nodet wrote: I would like to call a vote on the following subproject releases: fileinstall 2.0.10 gogo 0.4.0 bundlerepository 1.6.2 bundleplugin 2.1.0 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-034/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 034 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Freeman Fang Open Source SOA: http://fusesource.com
Is it just me to gets the maven-bundle-plugin build error?
Whenever I clean build I get this error? Guessing it must just be my local setup. The version ssems out of sync i.e the current OBR is 1.6.3, but the bundleplugin is asking for 1.6.2. Even if I change this though I still get the error unless I manually install the newly built OBR to my local maven repos. If this is the correct solution, maybe we should change the POM version to 1.6.3 so it's a simple step to install it after the build fails direct from the newly built OBR jar -- Rob Ascert - Taking systems to the Edge r...@ascert.com +44 (0)20 7488 3470 www.ascert.com
Re: Felix compiler version Android dx
Well, this should be easy enough to test, right? Just re-compile the
eventadmin and see whether that fixes the issue or not - if it does,
that would be really useful to know :-)
regards,
Karl
On Tue, May 4, 2010 at 1:23 PM, Jackson, Bruce bru...@qualcomm.com wrote:
Hi All
Some time back, we had a discussion about the default compiler version used
to build Felix, and whether this was compatible with the requirements of
Android.
I noted that when you dx the bundle jars produced by the regular Felix build,
you get a whole collection of warning of the the form:
$ dx --dex --output=classes.dex org.apache.felix.eventadmin-1.2.2.jar
warning: Ignoring InnerClasses attribute for an anonymous inner class that
doesn't come with an associated EnclosingMethod attribute. (This class was
probably produced by a broken compiler.)
...for example. We debated this, and decided that these were just warning and
not a real problem. However, now that I have a working Felix framework on
Android, I find that when I load and start the EventAdmin bundle, I find that
it fails to start with the following message in the log:
05-04 12:01:26.853: WARN/System.err(4682):
org.osgi.framework.BundleException: Activator start error in bundle
org.apache.felix.eventadmin [5].
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.Felix.activateBundle(Felix.java:1807)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.Felix.startBundle(Felix.java:1682)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)
05-04 12:01:26.853: WARN/System.err(4682): at
com.skifta.android.client.SkiftaService.startOSGi(SkiftaService.java:437)
05-04 12:01:26.853: WARN/System.err(4682): at
com.skifta.android.client.SkiftaService.init(SkiftaService.java:174)
05-04 12:01:26.853: WARN/System.err(4682): at
com.skifta.android.client.SkiftaService.onCreate(SkiftaService.java:166)
05-04 12:01:26.853: WARN/System.err(4682): at
android.app.ActivityThread.handleCreateService(ActivityThread.java:2894)
05-04 12:01:26.853: WARN/System.err(4682): at
android.app.ActivityThread.access$3200(ActivityThread.java:126)
05-04 12:01:26.853: WARN/System.err(4682): at
android.app.ActivityThread$H.handleMessage(ActivityThread.java:1986)
05-04 12:01:26.853: WARN/System.err(4682): at
android.os.Handler.dispatchMessage(Handler.java:99)
05-04 12:01:26.853: WARN/System.err(4682): at
android.os.Looper.loop(Looper.java:123)
05-04 12:01:26.853: WARN/System.err(4682): at
android.app.ActivityThread.main(ActivityThread.java:4595)
05-04 12:01:26.853: WARN/System.err(4682): at
java.lang.reflect.Method.invokeNative(Native Method)
05-04 12:01:26.853: WARN/System.err(4682): at
java.lang.reflect.Method.invoke(Method.java:521)
05-04 12:01:26.853: WARN/System.err(4682): at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:860)
05-04 12:01:26.853: WARN/System.err(4682): at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618)
05-04 12:01:26.853: WARN/System.err(4682): at
dalvik.system.NativeStart.main(Native Method)
05-04 12:01:26.853: WARN/System.err(4682): Caused by:
java.lang.NoClassDefFoundError:
org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks$1
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks.init(BlacklistingHandlerTasks.java:223)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.eventadmin.impl.Configuration.start(Configuration.java:293)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.eventadmin.impl.Configuration.init(Configuration.java:152)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.eventadmin.impl.Activator.start(Activator.java:65)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:661)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.Felix.activateBundle(Felix.java:1760)
05-04 12:01:26.853: WARN/System.err(4682): ... 17 more
Looking at the class in question (BlacklistingHandlerTasks:223) I see that
this is a use of an anonymous inner class:
private final EventHandler m_nullEventHandler = new EventHandler()
{
/**
* This is a null object that is supposed to do nothing at this point.
*
* @param event an event that is not used
*/
public void handleEvent(final Event event)
{
// This is a null object that is supposed to do nothing at this
// point. This is used once a EventHandler is requested for a
// servicereference that is either stale
Re: Felix compiler version Android dx
And like before, make sure you don't have other messages like class
resolved by unexpected dex in the log ...
regards,
Karl
On Tue, May 4, 2010 at 1:33 PM, Karl Pauls karlpa...@gmail.com wrote:
Well, this should be easy enough to test, right? Just re-compile the
eventadmin and see whether that fixes the issue or not - if it does,
that would be really useful to know :-)
regards,
Karl
On Tue, May 4, 2010 at 1:23 PM, Jackson, Bruce bru...@qualcomm.com wrote:
Hi All
Some time back, we had a discussion about the default compiler version used
to build Felix, and whether this was compatible with the requirements of
Android.
I noted that when you dx the bundle jars produced by the regular Felix
build, you get a whole collection of warning of the the form:
$ dx --dex --output=classes.dex org.apache.felix.eventadmin-1.2.2.jar
warning: Ignoring InnerClasses attribute for an anonymous inner class that
doesn't come with an associated EnclosingMethod attribute. (This class was
probably produced by a broken compiler.)
...for example. We debated this, and decided that these were just warning
and not a real problem. However, now that I have a working Felix framework
on Android, I find that when I load and start the EventAdmin bundle, I find
that it fails to start with the following message in the log:
05-04 12:01:26.853: WARN/System.err(4682):
org.osgi.framework.BundleException: Activator start error in bundle
org.apache.felix.eventadmin [5].
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.Felix.activateBundle(Felix.java:1807)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.Felix.startBundle(Felix.java:1682)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)
05-04 12:01:26.853: WARN/System.err(4682): at
com.skifta.android.client.SkiftaService.startOSGi(SkiftaService.java:437)
05-04 12:01:26.853: WARN/System.err(4682): at
com.skifta.android.client.SkiftaService.init(SkiftaService.java:174)
05-04 12:01:26.853: WARN/System.err(4682): at
com.skifta.android.client.SkiftaService.onCreate(SkiftaService.java:166)
05-04 12:01:26.853: WARN/System.err(4682): at
android.app.ActivityThread.handleCreateService(ActivityThread.java:2894)
05-04 12:01:26.853: WARN/System.err(4682): at
android.app.ActivityThread.access$3200(ActivityThread.java:126)
05-04 12:01:26.853: WARN/System.err(4682): at
android.app.ActivityThread$H.handleMessage(ActivityThread.java:1986)
05-04 12:01:26.853: WARN/System.err(4682): at
android.os.Handler.dispatchMessage(Handler.java:99)
05-04 12:01:26.853: WARN/System.err(4682): at
android.os.Looper.loop(Looper.java:123)
05-04 12:01:26.853: WARN/System.err(4682): at
android.app.ActivityThread.main(ActivityThread.java:4595)
05-04 12:01:26.853: WARN/System.err(4682): at
java.lang.reflect.Method.invokeNative(Native Method)
05-04 12:01:26.853: WARN/System.err(4682): at
java.lang.reflect.Method.invoke(Method.java:521)
05-04 12:01:26.853: WARN/System.err(4682): at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:860)
05-04 12:01:26.853: WARN/System.err(4682): at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618)
05-04 12:01:26.853: WARN/System.err(4682): at
dalvik.system.NativeStart.main(Native Method)
05-04 12:01:26.853: WARN/System.err(4682): Caused by:
java.lang.NoClassDefFoundError:
org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks$1
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks.init(BlacklistingHandlerTasks.java:223)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.eventadmin.impl.Configuration.start(Configuration.java:293)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.eventadmin.impl.Configuration.init(Configuration.java:152)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.eventadmin.impl.Activator.start(Activator.java:65)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:661)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.Felix.activateBundle(Felix.java:1760)
05-04 12:01:26.853: WARN/System.err(4682): ... 17 more
Looking at the class in question (BlacklistingHandlerTasks:223) I see that
this is a use of an anonymous inner class:
private final EventHandler m_nullEventHandler = new EventHandler()
{
/**
* This is a null object that is supposed to do nothing at this point.
*
* @param event an event that is not used
*/
public void handleEvent(final Event event)
{
[jira] Commented: (FELIX-2292) Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331)
[ https://issues.apache.org/jira/browse/FELIX-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863779#action_12863779 ] Rob Walker commented on FELIX-2292: --- Ok - both the new (jetty) and old (http.jetty) implementations seem to work fine on 6.1.24, so as an interim step prior to moving to jetty 7 I'll commit those changes. I guess the question then is do we release the current snapshot (2.0.5) prior to starting the 2.1 version on jetty 7. My view would be yes, so that we have a released final jetty 6 version on the latest current jetty6 for anyone who doesn't want to go to jetty 7 yet. Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331) -- Key: FELIX-2292 URL: https://issues.apache.org/jira/browse/FELIX-2292 Project: Felix Issue Type: Improvement Components: HTTP Service Reporter: Jonathan Bardin Fix For: http-2.1.0 Attachments: jetty7.patch, jetty7GoodFormat.patch Hi, This is a small improvement of the Http Service in order to use jetty 7.0.2 (org.eclipse.jetty 7.0.2v20100331). The patch is following. Regards, Jonathan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Felix compiler version Android dx
I have the same issues with all Apple SDKs (tried 5 and 6) here. Lets hope that Google's not dissing Apple Java this way. So far it let to not more than those warn messages produced by dx. Toni On Tue, May 4, 2010 at 1:54 PM, Karl Pauls karlpa...@gmail.com wrote: And like before, make sure you don't have other messages like class resolved by unexpected dex in the log ... regards, Karl On Tue, May 4, 2010 at 1:33 PM, Karl Pauls karlpa...@gmail.com wrote: Well, this should be easy enough to test, right? Just re-compile the eventadmin and see whether that fixes the issue or not - if it does, that would be really useful to know :-) regards, Karl On Tue, May 4, 2010 at 1:23 PM, Jackson, Bruce bru...@qualcomm.com wrote: Hi All Some time back, we had a discussion about the default compiler version used to build Felix, and whether this was compatible with the requirements of Android. I noted that when you dx the bundle jars produced by the regular Felix build, you get a whole collection of warning of the the form: $ dx --dex --output=classes.dex org.apache.felix.eventadmin-1.2.2.jar warning: Ignoring InnerClasses attribute for an anonymous inner class that doesn't come with an associated EnclosingMethod attribute. (This class was probably produced by a broken compiler.) ...for example. We debated this, and decided that these were just warning and not a real problem. However, now that I have a working Felix framework on Android, I find that when I load and start the EventAdmin bundle, I find that it fails to start with the following message in the log: 05-04 12:01:26.853: WARN/System.err(4682): org.osgi.framework.BundleException: Activator start error in bundle org.apache.felix.eventadmin [5]. 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.activateBundle(Felix.java:1807) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.startBundle(Felix.java:1682) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.startOSGi(SkiftaService.java:437) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.init(SkiftaService.java:174) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.onCreate(SkiftaService.java:166) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.handleCreateService(ActivityThread.java:2894) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.access$3200(ActivityThread.java:126) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1986) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Handler.dispatchMessage(Handler.java:99) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Looper.loop(Looper.java:123) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.main(ActivityThread.java:4595) 05-04 12:01:26.853: WARN/System.err(4682): at java.lang.reflect.Method.invokeNative(Native Method) 05-04 12:01:26.853: WARN/System.err(4682): at java.lang.reflect.Method.invoke(Method.java:521) 05-04 12:01:26.853: WARN/System.err(4682): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:860) 05-04 12:01:26.853: WARN/System.err(4682): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618) 05-04 12:01:26.853: WARN/System.err(4682): at dalvik.system.NativeStart.main(Native Method) 05-04 12:01:26.853: WARN/System.err(4682): Caused by: java.lang.NoClassDefFoundError: org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks$1 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks.init(BlacklistingHandlerTasks.java:223) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.Configuration.start(Configuration.java:293) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.Configuration.init(Configuration.java:152) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.Activator.start(Activator.java:65) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:661) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.activateBundle(Felix.java:1760) 05-04 12:01:26.853: WARN/System.err(4682): ... 17 more Looking at the class in question (BlacklistingHandlerTasks:223) I see that this is a use of an anonymous inner class: private
Re: [VOTE] Release fileinstall 3.0.0 (2nd try)
+1 (non-binding) Jamie On Tue, May 4, 2010 at 5:58 AM, Freeman Fang freeman.f...@gmail.com wrote: +1 (non-binding) Freeman On 2010-5-1, at 下午3:03, Guillaume Nodet wrote: I would like to call a vote on the following subproject releases: fileinstall 3.0.0 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-039/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 039 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Freeman Fang Open Source SOA: http://fusesource.com
Re: [gogo] Parameter annotations (Re: svn commit: r940514 - in /felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command: Flag.java Option.java)
On 5/4/10 2:33, Guillaume Nodet wrote:
A few things that would be missing imho to make that interesting:
* parameters annotation to mark parameters as optional or multi-valued
Currently, flags are always optional, whereas options are only optional
if a default value is specified. We haven't given any thought to
multi-valued, but I agree that it is worth thinking about.
* flag and option could be merged (they are the same, maybe use an enum
value on the annotation to differentiate them and maybe have a smart default
value based on the fact that the annotated parameter is a boolean or not)
Yeah, we talked about this. Peter liked them separate. It doesn't matter
to me.
* option should support a list of value
* options should have multiple names (annotations support String[] quite
well)
Quite possibly.
* if we want to add some help information, we need an annotation on the
method
Agreed. We also need to have a description on the flags/options.
* we have a nice coercion mechanism defined in blueprint (handling
generics, collections and such), we should reuse it (without having a
dependency to blueprint)
That can certainly be considered.
At this point, I am just trying to get something to work. I had
originally tried to use the approach used in Karaf to make commands, but
it didn't feel completely right to me. I talked with Peter and he said
his vision was that people wouldn't implement commands as Gogo
Functions, but just as methods on an object. So, I then started to think
about how to refactor the approach using methods, but realized it would
need to have some help from the Gogo runtime to make it work. So, that's
what this experiment is about.
There probably will be some balancing act between making it usable for
building command-line commands vs keeping it general purpose and UI
independent. We'll see as we go.
- richard
On Mon, May 3, 2010 at 23:25, Richard S. Hallhe...@ungoverned.org wrote:
On 5/3/10 16:56, Guillaume Nodet wrote:
On Mon, May 3, 2010 at 21:17, Richard S. Hallhe...@ungoverned.org
wrote:
On 5/3/10 14:51, Guillaume Nodet wrote:
What are those annotations suppose to actually provide ? It seems all
they
can do is provide some basic help to the user, but does not really help
the
user writing complex commands and dealing with complex arguments.
Have a look at an existing example:
http://svn.apache.org/repos/asf/felix/trunk/karaf/shell/commands/src/main/java/org/apache/felix/karaf/shell/commands/GrepAction.java
I think those annotations would not provide the slightest help in
analyzing
such a command line.
I don't think there will ever be a single solution that can help everyone
implement any possible command. If people need to do something that is
super
complex, then they can always fall back to parsing their own arguments.
I can agree to that, but then I don't see why it has to be in the proposed
spec. Having it as a separate module might be a better approach then.
The issue is you cannot easily do what we are trying to achieve in a
separate module since it is modifying how the runtime coerces arguments when
invoking methods. There is no place to hook into this externally. However, I
agree that it could be just an implementation-specific feature of the Gogo
runtime.
I actually talked with Peter specifically about this and he felt the
feature might be worthwhile for the spec, which is why he committed it
there, but nothing is set in stone at this point.
- richard
At this point, we're just messing around with allowing optional method
parameters and out of order specification of arguments.
- richard
On Mon, May 3, 2010 at 19:01,pkri...@apache.orgwrote:
Author: pkriens
Date: Mon May 3 17:01:53 2010
New Revision: 940514
URL: http://svn.apache.org/viewvc?rev=940514view=rev
Log:
Annotations for parameters
Added:
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Option.java
Added:
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java
URL:
http://svn.apache.org/viewvc/felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java?rev=940514view=auto
==
---
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java
(added)
+++
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java
Mon May 3 17:01:53 2010
@@ -0,0 +1,6 @@
+package org.osgi.service.command;
+
+public @interface Flag {
+ String name();
+ String help() default no help;
+}
Added:
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Option.java
URL:
Re: [gogo] Parameter annotations (Re: svn commit: r940514 - in /felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command: Flag.java Option.java)
I'm interested to see how your experiment develops. Meanwhile, an alternative approach to writing RFC-147 commands is presented here: https://www.osgi.org/bugzilla/show_bug.cgi?id=53 I'm happy to donate this 500-line Options class to Felix, if there is any interest. Derek On 4 May 2010 14:07, Richard S. Hall he...@ungoverned.org wrote: At this point, I am just trying to get something to work. I had originally tried to use the approach used in Karaf to make commands, but it didn't feel completely right to me. I talked with Peter and he said his vision was that people wouldn't implement commands as Gogo Functions, but just as methods on an object. So, I then started to think about how to refactor the approach using methods, but realized it would need to have some help from the Gogo runtime to make it work. So, that's what this experiment is about. There probably will be some balancing act between making it usable for building command-line commands vs keeping it general purpose and UI independent. We'll see as we go. - richard
Re: Felix compiler version Android dx
Yes, that's easier said than done!
I seem to remember that the was no single place where you could set the
compiler version to use for building Felix. Is that correct?
On 04/05/2010 12:54, Karl Pauls karlpa...@gmail.com wrote:
And like before, make sure you don't have other messages like class
resolved by unexpected dex in the log ...
regards,
Karl
On Tue, May 4, 2010 at 1:33 PM, Karl Pauls karlpa...@gmail.com wrote:
Well, this should be easy enough to test, right? Just re-compile the
eventadmin and see whether that fixes the issue or not - if it does,
that would be really useful to know :-)
regards,
Karl
On Tue, May 4, 2010 at 1:23 PM, Jackson, Bruce bru...@qualcomm.com wrote:
Hi All
Some time back, we had a discussion about the default compiler version used
to build Felix, and whether this was compatible with the requirements of
Android.
I noted that when you dx the bundle jars produced by the regular Felix
build, you get a whole collection of warning of the the form:
$ dx --dex --output=classes.dex org.apache.felix.eventadmin-1.2.2.jar
warning: Ignoring InnerClasses attribute for an anonymous inner class that
doesn't come with an associated EnclosingMethod attribute. (This class was
probably produced by a broken compiler.)
...for example. We debated this, and decided that these were just warning
and not a real problem. However, now that I have a working Felix framework
on Android, I find that when I load and start the EventAdmin bundle, I find
that it fails to start with the following message in the log:
05-04 12:01:26.853: WARN/System.err(4682):
org.osgi.framework.BundleException: Activator start error in bundle
org.apache.felix.eventadmin [5].
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.Felix.activateBundle(Felix.java:1807)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.Felix.startBundle(Felix.java:1682)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)
05-04 12:01:26.853: WARN/System.err(4682): at
com.skifta.android.client.SkiftaService.startOSGi(SkiftaService.java:437)
05-04 12:01:26.853: WARN/System.err(4682): at
com.skifta.android.client.SkiftaService.init(SkiftaService.java:174)
05-04 12:01:26.853: WARN/System.err(4682): at
com.skifta.android.client.SkiftaService.onCreate(SkiftaService.java:166)
05-04 12:01:26.853: WARN/System.err(4682): at
android.app.ActivityThread.handleCreateService(ActivityThread.java:2894)
05-04 12:01:26.853: WARN/System.err(4682): at
android.app.ActivityThread.access$3200(ActivityThread.java:126)
05-04 12:01:26.853: WARN/System.err(4682): at
android.app.ActivityThread$H.handleMessage(ActivityThread.java:1986)
05-04 12:01:26.853: WARN/System.err(4682): at
android.os.Handler.dispatchMessage(Handler.java:99)
05-04 12:01:26.853: WARN/System.err(4682): at
android.os.Looper.loop(Looper.java:123)
05-04 12:01:26.853: WARN/System.err(4682): at
android.app.ActivityThread.main(ActivityThread.java:4595)
05-04 12:01:26.853: WARN/System.err(4682): at
java.lang.reflect.Method.invokeNative(Native Method)
05-04 12:01:26.853: WARN/System.err(4682): at
java.lang.reflect.Method.invoke(Method.java:521)
05-04 12:01:26.853: WARN/System.err(4682): at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:8
60)
05-04 12:01:26.853: WARN/System.err(4682): at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618)
05-04 12:01:26.853: WARN/System.err(4682): at
dalvik.system.NativeStart.main(Native Method)
05-04 12:01:26.853: WARN/System.err(4682): Caused by:
java.lang.NoClassDefFoundError:
org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks$1
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks.init(Bla
cklistingHandlerTasks.java:223)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.eventadmin.impl.Configuration.start(Configuration.java:293)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.eventadmin.impl.Configuration.init(Configuration.java:152
)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.eventadmin.impl.Activator.start(Activator.java:65)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.jav
a:661)
05-04 12:01:26.853: WARN/System.err(4682): at
org.apache.felix.framework.Felix.activateBundle(Felix.java:1760)
05-04 12:01:26.853: WARN/System.err(4682): ... 17 more
Looking at the class in question (BlacklistingHandlerTasks:223) I see that
this is a use of an anonymous inner class:
private final EventHandler m_nullEventHandler = new EventHandler()
{
Re: [gogo] Parameter annotations (Re: svn commit: r940514 - in /felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command: Flag.java Option.java)
On 5/4/10 10:07, Derek Baum wrote: I'm interested to see how your experiment develops. Meanwhile, an alternative approach to writing RFC-147 commands is presented here: https://www.osgi.org/bugzilla/show_bug.cgi?id=53 I'm happy to donate this 500-line Options class to Felix, if there is any interest. That looks like another valid approach. I am sure that a single approach won't work for everyone, so having multiple approaches might make sense if they apply to different use cases. - richard Derek On 4 May 2010 14:07, Richard S. Hallhe...@ungoverned.org wrote: At this point, I am just trying to get something to work. I had originally tried to use the approach used in Karaf to make commands, but it didn't feel completely right to me. I talked with Peter and he said his vision was that people wouldn't implement commands as Gogo Functions, but just as methods on an object. So, I then started to think about how to refactor the approach using methods, but realized it would need to have some help from the Gogo runtime to make it work. So, that's what this experiment is about. There probably will be some balancing act between making it usable for building command-line commands vs keeping it general purpose and UI independent. We'll see as we go. - richard
Re: Felix compiler version Android dx
Toni I don't think its an Apple issue. The dx tool works fine for me with no warnings as long as the source is compiled with either 1.5 or 1.6. Thanks Bruce On 04/05/2010 13:22, Toni Menzel t...@okidokiteam.com wrote: I have the same issues with all Apple SDKs (tried 5 and 6) here. Lets hope that Google's not dissing Apple Java this way. So far it let to not more than those warn messages produced by dx. Toni On Tue, May 4, 2010 at 1:54 PM, Karl Pauls karlpa...@gmail.com wrote: And like before, make sure you don't have other messages like class resolved by unexpected dex in the log ... regards, Karl On Tue, May 4, 2010 at 1:33 PM, Karl Pauls karlpa...@gmail.com wrote: Well, this should be easy enough to test, right? Just re-compile the eventadmin and see whether that fixes the issue or not - if it does, that would be really useful to know :-) regards, Karl On Tue, May 4, 2010 at 1:23 PM, Jackson, Bruce bru...@qualcomm.com wrote: Hi All Some time back, we had a discussion about the default compiler version used to build Felix, and whether this was compatible with the requirements of Android. I noted that when you dx the bundle jars produced by the regular Felix build, you get a whole collection of warning of the the form: $ dx --dex --output=classes.dex org.apache.felix.eventadmin-1.2.2.jar warning: Ignoring InnerClasses attribute for an anonymous inner class that doesn't come with an associated EnclosingMethod attribute. (This class was probably produced by a broken compiler.) ...for example. We debated this, and decided that these were just warning and not a real problem. However, now that I have a working Felix framework on Android, I find that when I load and start the EventAdmin bundle, I find that it fails to start with the following message in the log: 05-04 12:01:26.853: WARN/System.err(4682): org.osgi.framework.BundleException: Activator start error in bundle org.apache.felix.eventadmin [5]. 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.activateBundle(Felix.java:1807) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.startBundle(Felix.java:1682) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.startOSGi(SkiftaService.java:437) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.init(SkiftaService.java:174) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.onCreate(SkiftaService.java:166) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.handleCreateService(ActivityThread.java:2894) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.access$3200(ActivityThread.java:126) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1986) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Handler.dispatchMessage(Handler.java:99) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Looper.loop(Looper.java:123) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.main(ActivityThread.java:4595) 05-04 12:01:26.853: WARN/System.err(4682): at java.lang.reflect.Method.invokeNative(Native Method) 05-04 12:01:26.853: WARN/System.err(4682): at java.lang.reflect.Method.invoke(Method.java:521) 05-04 12:01:26.853: WARN/System.err(4682): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:86 0) 05-04 12:01:26.853: WARN/System.err(4682): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618) 05-04 12:01:26.853: WARN/System.err(4682): at dalvik.system.NativeStart.main(Native Method) 05-04 12:01:26.853: WARN/System.err(4682): Caused by: java.lang.NoClassDefFoundError: org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks$1 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks.init(Blac klistingHandlerTasks.java:223) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.Configuration.start(Configuration.java:293) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.Configuration.init(Configuration.java:152) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.Activator.start(Activator.java:65) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java :661) 05-04 12:01:26.853: WARN/System.err(4682): at
Re: Felix compiler version Android dx
On 5/4/10 10:19, Jackson, Bruce wrote: Yes, that's easier said than done! I seem to remember that the was no single place where you could set the compiler version to use for building Felix. Is that correct? You should just be able to edit the Event Admin pom.xml file to include this in its plugins section, no? - richard On 04/05/2010 12:54, Karl Paulskarlpa...@gmail.com wrote: And like before, make sure you don't have other messages like class resolved by unexpected dex in the log ... regards, Karl On Tue, May 4, 2010 at 1:33 PM, Karl Paulskarlpa...@gmail.com wrote: Well, this should be easy enough to test, right? Just re-compile the eventadmin and see whether that fixes the issue or not - if it does, that would be really useful to know :-) regards, Karl On Tue, May 4, 2010 at 1:23 PM, Jackson, Brucebru...@qualcomm.com wrote: Hi All Some time back, we had a discussion about the default compiler version used to build Felix, and whether this was compatible with the requirements of Android. I noted that when you dx the bundle jars produced by the regular Felix build, you get a whole collection of warning of the the form: $ dx --dex --output=classes.dex org.apache.felix.eventadmin-1.2.2.jar warning: Ignoring InnerClasses attribute for an anonymous inner class that doesn't come with an associated EnclosingMethod attribute. (This class was probably produced by a broken compiler.) ...for example. We debated this, and decided that these were just warning and not a real problem. However, now that I have a working Felix framework on Android, I find that when I load and start the EventAdmin bundle, I find that it fails to start with the following message in the log: 05-04 12:01:26.853: WARN/System.err(4682): org.osgi.framework.BundleException: Activator start error in bundle org.apache.felix.eventadmin [5]. 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.activateBundle(Felix.java:1807) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.startBundle(Felix.java:1682) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.startOSGi(SkiftaService.java:437) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.init(SkiftaService.java:174) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.onCreate(SkiftaService.java:166) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.handleCreateService(ActivityThread.java:2894) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.access$3200(ActivityThread.java:126) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1986) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Handler.dispatchMessage(Handler.java:99) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Looper.loop(Looper.java:123) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.main(ActivityThread.java:4595) 05-04 12:01:26.853: WARN/System.err(4682): at java.lang.reflect.Method.invokeNative(Native Method) 05-04 12:01:26.853: WARN/System.err(4682): at java.lang.reflect.Method.invoke(Method.java:521) 05-04 12:01:26.853: WARN/System.err(4682): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:8 60) 05-04 12:01:26.853: WARN/System.err(4682): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618) 05-04 12:01:26.853: WARN/System.err(4682): at dalvik.system.NativeStart.main(Native Method) 05-04 12:01:26.853: WARN/System.err(4682): Caused by: java.lang.NoClassDefFoundError: org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks$1 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks.init(Bla cklistingHandlerTasks.java:223) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.Configuration.start(Configuration.java:293) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.Configuration.init(Configuration.java:152 ) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.Activator.start(Activator.java:65) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.jav a:661) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.activateBundle(Felix.java:1760) 05-04 12:01:26.853: WARN/System.err(4682): ... 17 more Looking at the class in question (BlacklistingHandlerTasks:223) I see that this is a use of
[jira] Created: (FELIX-2323) Unbind method should not be called during the invalidation process if the invalidation does not come from a service departure
Unbind method should not be called during the invalidation process if the invalidation does not come from a service departure - Key: FELIX-2323 URL: https://issues.apache.org/jira/browse/FELIX-2323 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: iPOJO-1.6.0 Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: iPOJO-1.8.0 The invalidation / stopping process is calling unbind method which is not correct as the process does not necessary comes from a service departure. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2318) Possible NPE for jars with null Manifest
[
https://issues.apache.org/jira/browse/FELIX-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863839#action_12863839
]
Marco commented on FELIX-2318:
--
Yesterday, I stumbled exactly over this NPE, which was not very developer
friendly and forced me to dig quite deep into it (decompiling debugging).
I'm not sure whether I can agree to Sahoo's suggestion to return a value in
this case. I mean, if there is no proper MANIFEST, it is not a valid OSGi
bundle and thus the method installOrUpdateBundle(...) cannot really return
anything meaningful. Or am I overlooking anything?
Anyway, for me (and everyone else not being aware of the MANIFEST.MF being
required at the very beginning of the JAR) a simple exception with a precise
error message would have been most helpful. I therefore recommend to simply add
sth. like this:
if (m == null)
throw new BundleException(
String.format(
The bundle %s does not have a META-INF/MANIFEST.MF! +
Make sure, META-INF and MANIFEST.MF are the first 2 entries in your
JAR!,
bundleLocation
)
);
Possible NPE for jars with null Manifest
Key: FELIX-2318
URL: https://issues.apache.org/jira/browse/FELIX-2318
Project: Felix
Issue Type: Bug
Components: File Install
Reporter: Sahoo
JarFile.getManifest() can return null, so caller must check return value for
null-ness to avoid NPE. I see two such occurrences in fileinstall:
DirectoryWatcher.java:
private Bundle installOrUpdateBundle(
String bundleLocation, BufferedInputStream is, long checksum)
throws IOException, BundleException
{
is.mark(256 * 1024);
JarInputStream jar = new JarInputStream(is);
Manifest m = jar.getManifest();
String sn =
m.getMainAttributes().getValue(Constants.BUNDLE_SYMBOLICNAME);
...
BundleTransformer.java:
Manifest m = jar.getManifest();
if (m.getMainAttributes().getValue(new
Attributes.Name(Bundle-SymbolicName)) != null)
...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Felix compiler version Android dx
On 5/4/10 10:25 AM, Richard S. Hall wrote: On 5/4/10 10:19, Jackson, Bruce wrote: Yes, that's easier said than done! I seem to remember that the was no single place where you could set the compiler version to use for building Felix. Is that correct? You should just be able to edit the Event Admin pom.xml file to include this in its plugins section, no? - richard You can actually do it from the command line: mvn package -Dmaven.compiler.compilerVersion=1.4 -Dmaven.compiler.executable=[path to javac] -Dmaven.compiler.fork=true -Dmaven.compiler.verbose=true See http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerVersion Justin On 04/05/2010 12:54, Karl Paulskarlpa...@gmail.com wrote: And like before, make sure you don't have other messages like class resolved by unexpected dex in the log ... regards, Karl On Tue, May 4, 2010 at 1:33 PM, Karl Paulskarlpa...@gmail.com wrote: Well, this should be easy enough to test, right? Just re-compile the eventadmin and see whether that fixes the issue or not - if it does, that would be really useful to know :-) regards, Karl On Tue, May 4, 2010 at 1:23 PM, Jackson, Brucebru...@qualcomm.com wrote: Hi All Some time back, we had a discussion about the default compiler version used to build Felix, and whether this was compatible with the requirements of Android. I noted that when you dx the bundle jars produced by the regular Felix build, you get a whole collection of warning of the the form: $ dx --dex --output=classes.dex org.apache.felix.eventadmin-1.2.2.jar warning: Ignoring InnerClasses attribute for an anonymous inner class that doesn't come with an associated EnclosingMethod attribute. (This class was probably produced by a broken compiler.) ...for example. We debated this, and decided that these were just warning and not a real problem. However, now that I have a working Felix framework on Android, I find that when I load and start the EventAdmin bundle, I find that it fails to start with the following message in the log: 05-04 12:01:26.853: WARN/System.err(4682): org.osgi.framework.BundleException: Activator start error in bundle org.apache.felix.eventadmin [5]. 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.activateBundle(Felix.java:1807) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.startBundle(Felix.java:1682) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.startOSGi(SkiftaService.java:437) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.init(SkiftaService.java:174) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.onCreate(SkiftaService.java:166) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.handleCreateService(ActivityThread.java:2894) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.access$3200(ActivityThread.java:126) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1986) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Handler.dispatchMessage(Handler.java:99) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Looper.loop(Looper.java:123) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.main(ActivityThread.java:4595) 05-04 12:01:26.853: WARN/System.err(4682): at java.lang.reflect.Method.invokeNative(Native Method) 05-04 12:01:26.853: WARN/System.err(4682): at java.lang.reflect.Method.invoke(Method.java:521) 05-04 12:01:26.853: WARN/System.err(4682): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:8 60) 05-04 12:01:26.853: WARN/System.err(4682): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618) 05-04 12:01:26.853: WARN/System.err(4682): at dalvik.system.NativeStart.main(Native Method) 05-04 12:01:26.853: WARN/System.err(4682): Caused by: java.lang.NoClassDefFoundError: org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks$1 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks.init(Bla cklistingHandlerTasks.java:223) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.Configuration.start(Configuration.java:293) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.Configuration.init(Configuration.java:152 ) 05-04 12:01:26.853: WARN/System.err(4682): at
[jira] Resolved: (FELIX-2323) Unbind method should not be called during the invalidation process if the invalidation does not come from a service departure
[ https://issues.apache.org/jira/browse/FELIX-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-2323. -- Resolution: Fixed Fixed in trunk. Unbind methods are no more called when the invalidation is not triggered by the service departure. Unbind method should not be called during the invalidation process if the invalidation does not come from a service departure - Key: FELIX-2323 URL: https://issues.apache.org/jira/browse/FELIX-2323 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: iPOJO-1.6.0 Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: iPOJO-1.8.0 The invalidation / stopping process is calling unbind method which is not correct as the process does not necessary comes from a service departure. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2279) Access to ServiceReference in iPOJO service
[
https://issues.apache.org/jira/browse/FELIX-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier resolved FELIX-2279.
--
Resolution: Fixed
Fixed in trunk.
Add the post-registration and post-unregistration attributes in the provides/
element. Such callbacks receives the ServiceReference as parameter. You can
have different callbacks if you have several provides/
Also define the @PostRegistration and @PostUnregistration annotations. You can
use those annotations only once per class.
To use them, you must declare the latest manipulator a dependency of the
maven-ipojo-plugin:
{code:xml}
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-ipojo-plugin/artifactId
version1.6.0/version
executions
execution
goals
goalipojo-bundle/goal
/goals
/execution
/executions
dependencies
dependency
groupIdorg.apache.felix/groupId
artifactIdorg.apache.felix.ipojo.manipulator/artifactId
version1.7.0-SNAPSHOT/version
/dependency
/dependencies
/plugin
{code}
Access to ServiceReference in iPOJO service
---
Key: FELIX-2279
URL: https://issues.apache.org/jira/browse/FELIX-2279
Project: Felix
Issue Type: New Feature
Components: iPOJO
Affects Versions: iPOJO-1.4.0
Reporter: Bengt Rodehav
Assignee: Clement Escoffier
Fix For: iPOJO-1.8.0
As a convenience, it would be very useful for an iPOJO service to have access
to its ServiceReference object. E g for logging purposes this is essential
information. Assuming that the service has been registered prior to the
@Validate method being called, it makes sense to provide the ServiceReference
as an argument to this method.
If the service is not registered until the @Valid method returns, then
another callback (e g @Registered) is needed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Felix compiler version Android dx
But i realized i the warnings just appear when using the stock felix 2.0.5 (and other bundles like event admin). Self built stuff works just fine. So Karl, what do you use to build the released artifacts ? On Tue, May 4, 2010 at 5:27 PM, Justin Edelson justinedel...@gmail.comwrote: On 5/4/10 10:25 AM, Richard S. Hall wrote: On 5/4/10 10:19, Jackson, Bruce wrote: Yes, that's easier said than done! I seem to remember that the was no single place where you could set the compiler version to use for building Felix. Is that correct? You should just be able to edit the Event Admin pom.xml file to include this in its plugins section, no? - richard You can actually do it from the command line: mvn package -Dmaven.compiler.compilerVersion=1.4 -Dmaven.compiler.executable=[path to javac] -Dmaven.compiler.fork=true -Dmaven.compiler.verbose=true See http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerVersion Justin On 04/05/2010 12:54, Karl Paulskarlpa...@gmail.com wrote: And like before, make sure you don't have other messages like class resolved by unexpected dex in the log ... regards, Karl On Tue, May 4, 2010 at 1:33 PM, Karl Paulskarlpa...@gmail.com wrote: Well, this should be easy enough to test, right? Just re-compile the eventadmin and see whether that fixes the issue or not - if it does, that would be really useful to know :-) regards, Karl On Tue, May 4, 2010 at 1:23 PM, Jackson, Brucebru...@qualcomm.com wrote: Hi All Some time back, we had a discussion about the default compiler version used to build Felix, and whether this was compatible with the requirements of Android. I noted that when you dx the bundle jars produced by the regular Felix build, you get a whole collection of warning of the the form: $ dx --dex --output=classes.dex org.apache.felix.eventadmin-1.2.2.jar warning: Ignoring InnerClasses attribute for an anonymous inner class that doesn't come with an associated EnclosingMethod attribute. (This class was probably produced by a broken compiler.) ...for example. We debated this, and decided that these were just warning and not a real problem. However, now that I have a working Felix framework on Android, I find that when I load and start the EventAdmin bundle, I find that it fails to start with the following message in the log: 05-04 12:01:26.853: WARN/System.err(4682): org.osgi.framework.BundleException: Activator start error in bundle org.apache.felix.eventadmin [5]. 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.activateBundle(Felix.java:1807) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.startBundle(Felix.java:1682) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.startOSGi(SkiftaService.java:437) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.init(SkiftaService.java:174) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.onCreate(SkiftaService.java:166) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.handleCreateService(ActivityThread.java:2894) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.access$3200(ActivityThread.java:126) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1986) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Handler.dispatchMessage(Handler.java:99) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Looper.loop(Looper.java:123) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.main(ActivityThread.java:4595) 05-04 12:01:26.853: WARN/System.err(4682): at java.lang.reflect.Method.invokeNative(Native Method) 05-04 12:01:26.853: WARN/System.err(4682): at java.lang.reflect.Method.invoke(Method.java:521) 05-04 12:01:26.853: WARN/System.err(4682): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:8 60) 05-04 12:01:26.853: WARN/System.err(4682): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618) 05-04 12:01:26.853: WARN/System.err(4682): at dalvik.system.NativeStart.main(Native Method) 05-04 12:01:26.853: WARN/System.err(4682): Caused by: java.lang.NoClassDefFoundError: org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks$1 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks.init(Bla
[jira] Created: (FELIX-2324) Support execution environment so that OBR works properly
Support execution environment so that OBR works properly Key: FELIX-2324 URL: https://issues.apache.org/jira/browse/FELIX-2324 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: karaf-1.4.0 Reporter: Christopher Blunck Priority: Minor Fix For: karaf 1.6.0 Basic use case here is that I'd like to use Jackson within OBR. Jackson expresses a requirement on ee=J2SE-1.5. Felix Karaf doesn't have a facility for supported execution environments. I can set: JAVA_OPTS=-Dorg.osgi.framework.executionenvironment=J2SE-1.5 before I start karaf from the command line but this seems like a hack. It's very possible that I'll start Karaf using Sun's 1.6 JVM or an IBM JVM. Ideally at startup time Karaf could look at the runtime and determine the JVM version (at the very least). It could then expose the execution environment somehow (presumably in a way that OBR would understand). We should still be able to explicitly set the org.osgi.framework.executionenvironment system property but ideally it'd be additive to the ee's that Karaf senses when it starts up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Felix compiler version Android dx
According to the manifest, Carsten, not Karl, built EventAdmin 1.2.2. On 5/4/10 11:49 AM, Toni Menzel wrote: But i realized i the warnings just appear when using the stock felix 2.0.5 (and other bundles like event admin). Self built stuff works just fine. So Karl, what do you use to build the released artifacts ? On Tue, May 4, 2010 at 5:27 PM, Justin Edelson justinedel...@gmail.com mailto:justinedel...@gmail.com wrote: On 5/4/10 10:25 AM, Richard S. Hall wrote: On 5/4/10 10:19, Jackson, Bruce wrote: Yes, that's easier said than done! I seem to remember that the was no single place where you could set the compiler version to use for building Felix. Is that correct? You should just be able to edit the Event Admin pom.xml file to include this in its plugins section, no? - richard You can actually do it from the command line: mvn package -Dmaven.compiler.compilerVersion=1.4 -Dmaven.compiler.executable=[path to javac] -Dmaven.compiler.fork=true -Dmaven.compiler.verbose=true See http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerVersion Justin On 04/05/2010 12:54, Karl Paulskarlpa...@gmail.com mailto:karlpa...@gmail.com wrote: And like before, make sure you don't have other messages like class resolved by unexpected dex in the log ... regards, Karl On Tue, May 4, 2010 at 1:33 PM, Karl Paulskarlpa...@gmail.com mailto:karlpa...@gmail.com wrote: Well, this should be easy enough to test, right? Just re-compile the eventadmin and see whether that fixes the issue or not - if it does, that would be really useful to know :-) regards, Karl On Tue, May 4, 2010 at 1:23 PM, Jackson, Brucebru...@qualcomm.com mailto:bru...@qualcomm.com wrote: Hi All Some time back, we had a discussion about the default compiler version used to build Felix, and whether this was compatible with the requirements of Android. I noted that when you dx the bundle jars produced by the regular Felix build, you get a whole collection of warning of the the form: $ dx --dex --output=classes.dex org.apache.felix.eventadmin-1.2.2.jar warning: Ignoring InnerClasses attribute for an anonymous inner class that doesn't come with an associated EnclosingMethod attribute. (This class was probably produced by a broken compiler.) ...for example. We debated this, and decided that these were just warning and not a real problem. However, now that I have a working Felix framework on Android, I find that when I load and start the EventAdmin bundle, I find that it fails to start with the following message in the log: 05-04 12:01:26.853: WARN/System.err(4682): org.osgi.framework.BundleException: Activator start error in bundle org.apache.felix.eventadmin [5]. 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.activateBundle(Felix.java:1807) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.startBundle(Felix.java:1682) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.startOSGi(SkiftaService.java:437) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.init(SkiftaService.java:174) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.onCreate(SkiftaService.java:166) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.handleCreateService(ActivityThread.java:2894) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.access$3200(ActivityThread.java:126) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1986) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Handler.dispatchMessage(Handler.java:99) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Looper.loop(Looper.java:123) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.main(ActivityThread.java:4595) 05-04 12:01:26.853: WARN/System.err(4682): at java.lang.reflect.Method.invokeNative(Native Method) 05-04 12:01:26.853:
Re: Felix compiler version Android dx
then there are at least two broken compilers out in the wild ;) 2010/5/4 Justin Edelson justinedel...@gmail.com According to the manifest, Carsten, not Karl, built EventAdmin 1.2.2. On 5/4/10 11:49 AM, Toni Menzel wrote: But i realized i the warnings just appear when using the stock felix 2.0.5 (and other bundles like event admin). Self built stuff works just fine. So Karl, what do you use to build the released artifacts ? On Tue, May 4, 2010 at 5:27 PM, Justin Edelson justinedel...@gmail.com mailto:justinedel...@gmail.com wrote: On 5/4/10 10:25 AM, Richard S. Hall wrote: On 5/4/10 10:19, Jackson, Bruce wrote: Yes, that's easier said than done! I seem to remember that the was no single place where you could set the compiler version to use for building Felix. Is that correct? You should just be able to edit the Event Admin pom.xml file to include this in its plugins section, no? - richard You can actually do it from the command line: mvn package -Dmaven.compiler.compilerVersion=1.4 -Dmaven.compiler.executable=[path to javac] -Dmaven.compiler.fork=true -Dmaven.compiler.verbose=true See http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerVersion Justin On 04/05/2010 12:54, Karl Paulskarlpa...@gmail.com mailto:karlpa...@gmail.com wrote: And like before, make sure you don't have other messages like class resolved by unexpected dex in the log ... regards, Karl On Tue, May 4, 2010 at 1:33 PM, Karl Paulskarlpa...@gmail.com mailto:karlpa...@gmail.com wrote: Well, this should be easy enough to test, right? Just re-compile the eventadmin and see whether that fixes the issue or not - if it does, that would be really useful to know :-) regards, Karl On Tue, May 4, 2010 at 1:23 PM, Jackson, Brucebru...@qualcomm.com mailto:bru...@qualcomm.com wrote: Hi All Some time back, we had a discussion about the default compiler version used to build Felix, and whether this was compatible with the requirements of Android. I noted that when you dx the bundle jars produced by the regular Felix build, you get a whole collection of warning of the the form: $ dx --dex --output=classes.dex org.apache.felix.eventadmin-1.2.2.jar warning: Ignoring InnerClasses attribute for an anonymous inner class that doesn't come with an associated EnclosingMethod attribute. (This class was probably produced by a broken compiler.) ...for example. We debated this, and decided that these were just warning and not a real problem. However, now that I have a working Felix framework on Android, I find that when I load and start the EventAdmin bundle, I find that it fails to start with the following message in the log: 05-04 12:01:26.853: WARN/System.err(4682): org.osgi.framework.BundleException: Activator start error in bundle org.apache.felix.eventadmin [5]. 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.activateBundle(Felix.java:1807) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.startBundle(Felix.java:1682) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.startOSGi(SkiftaService.java:437) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.init(SkiftaService.java:174) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.onCreate(SkiftaService.java:166) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.handleCreateService(ActivityThread.java:2894) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.access$3200(ActivityThread.java:126) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1986) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Handler.dispatchMessage(Handler.java:99) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Looper.loop(Looper.java:123) 05-04 12:01:26.853:
Re: Felix compiler version Android dx
we compile for 1.4 by default. regards, Karl 2010/5/4 Toni Menzel t...@okidokiteam.com: then there are at least two broken compilers out in the wild ;) 2010/5/4 Justin Edelson justinedel...@gmail.com According to the manifest, Carsten, not Karl, built EventAdmin 1.2.2. On 5/4/10 11:49 AM, Toni Menzel wrote: But i realized i the warnings just appear when using the stock felix 2.0.5 (and other bundles like event admin). Self built stuff works just fine. So Karl, what do you use to build the released artifacts ? On Tue, May 4, 2010 at 5:27 PM, Justin Edelson justinedel...@gmail.com mailto:justinedel...@gmail.com wrote: On 5/4/10 10:25 AM, Richard S. Hall wrote: On 5/4/10 10:19, Jackson, Bruce wrote: Yes, that's easier said than done! I seem to remember that the was no single place where you could set the compiler version to use for building Felix. Is that correct? You should just be able to edit the Event Admin pom.xml file to include this in its plugins section, no? - richard You can actually do it from the command line: mvn package -Dmaven.compiler.compilerVersion=1.4 -Dmaven.compiler.executable=[path to javac] -Dmaven.compiler.fork=true -Dmaven.compiler.verbose=true See http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerVersion Justin On 04/05/2010 12:54, Karl Paulskarlpa...@gmail.com mailto:karlpa...@gmail.com wrote: And like before, make sure you don't have other messages like class resolved by unexpected dex in the log ... regards, Karl On Tue, May 4, 2010 at 1:33 PM, Karl Paulskarlpa...@gmail.com mailto:karlpa...@gmail.com wrote: Well, this should be easy enough to test, right? Just re-compile the eventadmin and see whether that fixes the issue or not - if it does, that would be really useful to know :-) regards, Karl On Tue, May 4, 2010 at 1:23 PM, Jackson, Brucebru...@qualcomm.com mailto:bru...@qualcomm.com wrote: Hi All Some time back, we had a discussion about the default compiler version used to build Felix, and whether this was compatible with the requirements of Android. I noted that when you dx the bundle jars produced by the regular Felix build, you get a whole collection of warning of the the form: $ dx --dex --output=classes.dex org.apache.felix.eventadmin-1.2.2.jar warning: Ignoring InnerClasses attribute for an anonymous inner class that doesn't come with an associated EnclosingMethod attribute. (This class was probably produced by a broken compiler.) ...for example. We debated this, and decided that these were just warning and not a real problem. However, now that I have a working Felix framework on Android, I find that when I load and start the EventAdmin bundle, I find that it fails to start with the following message in the log: 05-04 12:01:26.853: WARN/System.err(4682): org.osgi.framework.BundleException: Activator start error in bundle org.apache.felix.eventadmin [5]. 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.activateBundle(Felix.java:1807) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.startBundle(Felix.java:1682) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.startOSGi(SkiftaService.java:437) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.init(SkiftaService.java:174) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.onCreate(SkiftaService.java:166) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.handleCreateService(ActivityThread.java:2894) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.access$3200(ActivityThread.java:126) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1986) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Handler.dispatchMessage(Handler.java:99) 05-04 12:01:26.853:
Re: Felix compiler version Android dx
This is probably the valid explanation: http://www.mailinglistarchive.com/html/derby-...@db.apache.org/2009-12/msg00072.html http://www.mailinglistarchive.com/html/derby-...@db.apache.org/2009-12/msg00072.html In fact, I believe the bytecode spec changed between 1.4 and 1.5. dx's warning is basically saying that 1.4-based code that uses inner classes doesn't provide enough information for a 1.5 runtime to faithfully report about them via reflection. Rather than try to halfway reconstruct the reflection info in such cases, dx just gives up and ignores inner classes info entirely. If your code doesn't make reflection calls to look at inner class stuff, then none of this makes any difference. Toni 2010/5/4 Karl Pauls karlpa...@gmail.com we compile for 1.4 by default. regards, Karl 2010/5/4 Toni Menzel t...@okidokiteam.com: then there are at least two broken compilers out in the wild ;) 2010/5/4 Justin Edelson justinedel...@gmail.com According to the manifest, Carsten, not Karl, built EventAdmin 1.2.2. On 5/4/10 11:49 AM, Toni Menzel wrote: But i realized i the warnings just appear when using the stock felix 2.0.5 (and other bundles like event admin). Self built stuff works just fine. So Karl, what do you use to build the released artifacts ? On Tue, May 4, 2010 at 5:27 PM, Justin Edelson justinedel...@gmail.com mailto:justinedel...@gmail.com wrote: On 5/4/10 10:25 AM, Richard S. Hall wrote: On 5/4/10 10:19, Jackson, Bruce wrote: Yes, that's easier said than done! I seem to remember that the was no single place where you could set the compiler version to use for building Felix. Is that correct? You should just be able to edit the Event Admin pom.xml file to include this in its plugins section, no? - richard You can actually do it from the command line: mvn package -Dmaven.compiler.compilerVersion=1.4 -Dmaven.compiler.executable=[path to javac] -Dmaven.compiler.fork=true -Dmaven.compiler.verbose=true See http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerVersion Justin On 04/05/2010 12:54, Karl Paulskarlpa...@gmail.com mailto:karlpa...@gmail.com wrote: And like before, make sure you don't have other messages like class resolved by unexpected dex in the log ... regards, Karl On Tue, May 4, 2010 at 1:33 PM, Karl Pauls karlpa...@gmail.com mailto:karlpa...@gmail.com wrote: Well, this should be easy enough to test, right? Just re-compile the eventadmin and see whether that fixes the issue or not - if it does, that would be really useful to know :-) regards, Karl On Tue, May 4, 2010 at 1:23 PM, Jackson, Brucebru...@qualcomm.com mailto:bru...@qualcomm.com wrote: Hi All Some time back, we had a discussion about the default compiler version used to build Felix, and whether this was compatible with the requirements of Android. I noted that when you dx the bundle jars produced by the regular Felix build, you get a whole collection of warning of the the form: $ dx --dex --output=classes.dex org.apache.felix.eventadmin-1.2.2.jar warning: Ignoring InnerClasses attribute for an anonymous inner class that doesn't come with an associated EnclosingMethod attribute. (This class was probably produced by a broken compiler.) ...for example. We debated this, and decided that these were just warning and not a real problem. However, now that I have a working Felix framework on Android, I find that when I load and start the EventAdmin bundle, I find that it fails to start with the following message in the log: 05-04 12:01:26.853: WARN/System.err(4682): org.osgi.framework.BundleException: Activator start error in bundle org.apache.felix.eventadmin [5]. 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.activateBundle(Felix.java:1807) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.startBundle(Felix.java:1682) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892) 05-04 12:01:26.853: WARN/System.err(4682): at
[jira] Updated: (FELIX-2324) Support execution environment so that OBR works properly
[ https://issues.apache.org/jira/browse/FELIX-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-2324: --- Fix Version/s: framework-3.0.0 Affects Version/s: framework-2.0.5 (was: karaf-1.4.0) Fix Version/s: (was: karaf 1.6.0) Support execution environment so that OBR works properly Key: FELIX-2324 URL: https://issues.apache.org/jira/browse/FELIX-2324 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-2.0.5 Reporter: Christopher Blunck Priority: Minor Fix For: framework-3.0.0 Basic use case here is that I'd like to use Jackson within OBR. Jackson expresses a requirement on ee=J2SE-1.5. Felix Karaf doesn't have a facility for supported execution environments. I can set: JAVA_OPTS=-Dorg.osgi.framework.executionenvironment=J2SE-1.5 before I start karaf from the command line but this seems like a hack. It's very possible that I'll start Karaf using Sun's 1.6 JVM or an IBM JVM. Ideally at startup time Karaf could look at the runtime and determine the JVM version (at the very least). It could then expose the execution environment somehow (presumably in a way that OBR would understand). We should still be able to explicitly set the org.osgi.framework.executionenvironment system property but ideally it'd be additive to the ee's that Karaf senses when it starts up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2314) Improve logging support
[ https://issues.apache.org/jira/browse/FELIX-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863873#action_12863873 ] Guillaume Nodet commented on FELIX-2314: Committing to https://svn.apache.org/repos/asf/felix/trunk ... M karaf/pom.xml Committed r940942 Improve logging support --- Key: FELIX-2314 URL: https://issues.apache.org/jira/browse/FELIX-2314 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: karaf 1.6.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2324) Support execution environment so that OBR works properly
[ https://issues.apache.org/jira/browse/FELIX-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863875#action_12863875 ] Richard S. Hall commented on FELIX-2324: I was thinking about adding this in the default properties for the framework, not in Karaf. Are there actually two issues here: one for the framework and one for Karaf? Support execution environment so that OBR works properly Key: FELIX-2324 URL: https://issues.apache.org/jira/browse/FELIX-2324 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-2.0.5 Reporter: Christopher Blunck Priority: Minor Fix For: framework-3.0.0 Basic use case here is that I'd like to use Jackson within OBR. Jackson expresses a requirement on ee=J2SE-1.5. Felix Karaf doesn't have a facility for supported execution environments. I can set: JAVA_OPTS=-Dorg.osgi.framework.executionenvironment=J2SE-1.5 before I start karaf from the command line but this seems like a hack. It's very possible that I'll start Karaf using Sun's 1.6 JVM or an IBM JVM. Ideally at startup time Karaf could look at the runtime and determine the JVM version (at the very least). It could then expose the execution environment somehow (presumably in a way that OBR would understand). We should still be able to explicitly set the org.osgi.framework.executionenvironment system property but ideally it'd be additive to the ee's that Karaf senses when it starts up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2324) Support execution environment so that OBR works properly
[ https://issues.apache.org/jira/browse/FELIX-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863878#action_12863878 ] Christopher Blunck commented on FELIX-2324: --- I don't know as I'm pretty new to Karaf. It strikes me though that ee is a framework concept and not a Karaf concept. I also know that pax-runner has some ee related functionality within it. Might be worth considering how that functionality works and if it can be incorporated into the Felix framework. Support execution environment so that OBR works properly Key: FELIX-2324 URL: https://issues.apache.org/jira/browse/FELIX-2324 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-2.0.5 Reporter: Christopher Blunck Priority: Minor Fix For: framework-3.0.0 Basic use case here is that I'd like to use Jackson within OBR. Jackson expresses a requirement on ee=J2SE-1.5. Felix Karaf doesn't have a facility for supported execution environments. I can set: JAVA_OPTS=-Dorg.osgi.framework.executionenvironment=J2SE-1.5 before I start karaf from the command line but this seems like a hack. It's very possible that I'll start Karaf using Sun's 1.6 JVM or an IBM JVM. Ideally at startup time Karaf could look at the runtime and determine the JVM version (at the very least). It could then expose the execution environment somehow (presumably in a way that OBR would understand). We should still be able to explicitly set the org.osgi.framework.executionenvironment system property but ideally it'd be additive to the ee's that Karaf senses when it starts up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2324) Support execution environment so that OBR works properly
[ https://issues.apache.org/jira/browse/FELIX-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863884#action_12863884 ] Richard S. Hall commented on FELIX-2324: ok. Well, all I am thinking about doing is adding some property substitution magic in the default.properties file that ships with the framework so that it tries to select a default value based on the JRE. This shouldn't be problematic, since anyone will be able to override it by specifying the property explicitly in the framework configuration properties. Just like we do currently for system packages. Support execution environment so that OBR works properly Key: FELIX-2324 URL: https://issues.apache.org/jira/browse/FELIX-2324 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-2.0.5 Reporter: Christopher Blunck Priority: Minor Fix For: framework-3.0.0 Basic use case here is that I'd like to use Jackson within OBR. Jackson expresses a requirement on ee=J2SE-1.5. Felix Karaf doesn't have a facility for supported execution environments. I can set: JAVA_OPTS=-Dorg.osgi.framework.executionenvironment=J2SE-1.5 before I start karaf from the command line but this seems like a hack. It's very possible that I'll start Karaf using Sun's 1.6 JVM or an IBM JVM. Ideally at startup time Karaf could look at the runtime and determine the JVM version (at the very least). It could then expose the execution environment somehow (presumably in a way that OBR would understand). We should still be able to explicitly set the org.osgi.framework.executionenvironment system property but ideally it'd be additive to the ee's that Karaf senses when it starts up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Felix compiler version Android dx
But the compiler used is system-dependent. All the source/target bits do is impact what the compiler does, not which compiler is used. If you specify the fork, compilerVersion, and executable properties as I described below, you can use an alternate javac. You can also use a different compiler (see http://maven.apache.org/plugins/maven-compiler-plugin/non-javac-compilers.html) if you want to go there. Justin On 5/4/10 12:23 PM, Karl Pauls wrote: we compile for 1.4 by default. regards, Karl 2010/5/4 Toni Menzel t...@okidokiteam.com: then there are at least two broken compilers out in the wild ;) 2010/5/4 Justin Edelson justinedel...@gmail.com According to the manifest, Carsten, not Karl, built EventAdmin 1.2.2. On 5/4/10 11:49 AM, Toni Menzel wrote: But i realized i the warnings just appear when using the stock felix 2.0.5 (and other bundles like event admin). Self built stuff works just fine. So Karl, what do you use to build the released artifacts ? On Tue, May 4, 2010 at 5:27 PM, Justin Edelson justinedel...@gmail.com mailto:justinedel...@gmail.com wrote: On 5/4/10 10:25 AM, Richard S. Hall wrote: On 5/4/10 10:19, Jackson, Bruce wrote: Yes, that's easier said than done! I seem to remember that the was no single place where you could set the compiler version to use for building Felix. Is that correct? You should just be able to edit the Event Admin pom.xml file to include this in its plugins section, no? - richard You can actually do it from the command line: mvn package -Dmaven.compiler.compilerVersion=1.4 -Dmaven.compiler.executable=[path to javac] -Dmaven.compiler.fork=true -Dmaven.compiler.verbose=true See http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerVersion Justin On 04/05/2010 12:54, Karl Paulskarlpa...@gmail.com mailto:karlpa...@gmail.com wrote: And like before, make sure you don't have other messages like class resolved by unexpected dex in the log ... regards, Karl On Tue, May 4, 2010 at 1:33 PM, Karl Paulskarlpa...@gmail.com mailto:karlpa...@gmail.com wrote: Well, this should be easy enough to test, right? Just re-compile the eventadmin and see whether that fixes the issue or not - if it does, that would be really useful to know :-) regards, Karl On Tue, May 4, 2010 at 1:23 PM, Jackson, Brucebru...@qualcomm.com mailto:bru...@qualcomm.com wrote: Hi All Some time back, we had a discussion about the default compiler version used to build Felix, and whether this was compatible with the requirements of Android. I noted that when you dx the bundle jars produced by the regular Felix build, you get a whole collection of warning of the the form: $ dx --dex --output=classes.dex org.apache.felix.eventadmin-1.2.2.jar warning: Ignoring InnerClasses attribute for an anonymous inner class that doesn't come with an associated EnclosingMethod attribute. (This class was probably produced by a broken compiler.) ...for example. We debated this, and decided that these were just warning and not a real problem. However, now that I have a working Felix framework on Android, I find that when I load and start the EventAdmin bundle, I find that it fails to start with the following message in the log: 05-04 12:01:26.853: WARN/System.err(4682): org.osgi.framework.BundleException: Activator start error in bundle org.apache.felix.eventadmin [5]. 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.activateBundle(Felix.java:1807) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.startBundle(Felix.java:1682) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.startOSGi(SkiftaService.java:437) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.init(SkiftaService.java:174) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.onCreate(SkiftaService.java:166) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.handleCreateService(ActivityThread.java:2894) 05-04 12:01:26.853: WARN/System.err(4682): at
[jira] Updated: (FELIX-2280) To much code duplication in DefaultJDBCLock, OracleJDBCLock and MySQLJDBCLock
[ https://issues.apache.org/jira/browse/FELIX-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Müller updated FELIX-2280: Attachment: FELIX-2280.patch Me again... I provide a new patch (based on the current trunk) which respects your requirements: 1) OracleJDBCLock: - We perform only a SELECT FOR UPDATE in the lock() and in the isAlive() method. This works for Oracle and will hopefully not overflow the UNDO table space for long running instances. 2) DefaultJDBCLock: - Provides the same functionality like the current implementation (add the ;create=true jdbc url option to a derby connection url, if they is not provided by the user). 3) DerbyJDBCLock: - New Lock implementation for Derby. Also set the ;create=true jdbc url option, if they is not provided by the user 4) MySQLJDBCLock: - Provides the same functionality like the current implementation, but in a more elegant way (add the ;createDatabaseIfNotExist=true jdbc url option, if they is not provided by the user). I hope that's what you want. Sometime, my brain is a bit slow... :o) Cheers, Christian To much code duplication in DefaultJDBCLock, OracleJDBCLock and MySQLJDBCLock - Key: FELIX-2280 URL: https://issues.apache.org/jira/browse/FELIX-2280 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.4.0 Environment: All Reporter: Christian Müller Attachments: FELIX-2280.patch, FELIX-2280.patch, FELIX-2280.patch org.apache.felix.karaf.main.DefaultJDBCLock, org.apache.felix.karaf.main.MySQLJDBCLock and org.apache.felix.karaf.main.OracleJDBCLock has to much code duplications. I propose a solution like in ActiveMQ [package org.apache.activemq.store.jdbc.adapter|http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/store/jdbc/adapter/]. And we should implement some unit tests for it. If it's fine for you, I will try to improve this part of karaf and provide a patch for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2280) To much code duplication in DefaultJDBCLock, OracleJDBCLock and MySQLJDBCLock
[ https://issues.apache.org/jira/browse/FELIX-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863920#action_12863920 ] Jamie goodyear commented on FELIX-2280: --- Thanks, I'll take a look over this latest patch soon :) Cheers, Jamie To much code duplication in DefaultJDBCLock, OracleJDBCLock and MySQLJDBCLock - Key: FELIX-2280 URL: https://issues.apache.org/jira/browse/FELIX-2280 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.4.0 Environment: All Reporter: Christian Müller Attachments: FELIX-2280.patch, FELIX-2280.patch, FELIX-2280.patch org.apache.felix.karaf.main.DefaultJDBCLock, org.apache.felix.karaf.main.MySQLJDBCLock and org.apache.felix.karaf.main.OracleJDBCLock has to much code duplications. I propose a solution like in ActiveMQ [package org.apache.activemq.store.jdbc.adapter|http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/store/jdbc/adapter/]. And we should implement some unit tests for it. If it's fine for you, I will try to improve this part of karaf and provide a patch for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Felix compiler version Android dx
Really, my guess is that you are running into the same issue as you did the last time namely, the eventadmin contains the org.osgi.service.event package and imports it as well. Do you have the compendium bundle installed (or any other provider of the org.osgi.service.event package)? Remember, substitutable imports need to be dex-ified separately... regards, Karl On Tue, May 4, 2010 at 1:54 PM, Karl Pauls karlpa...@gmail.com wrote: And like before, make sure you don't have other messages like class resolved by unexpected dex in the log ... regards, Karl On Tue, May 4, 2010 at 1:33 PM, Karl Pauls karlpa...@gmail.com wrote: Well, this should be easy enough to test, right? Just re-compile the eventadmin and see whether that fixes the issue or not - if it does, that would be really useful to know :-) regards, Karl On Tue, May 4, 2010 at 1:23 PM, Jackson, Bruce bru...@qualcomm.com wrote: Hi All Some time back, we had a discussion about the default compiler version used to build Felix, and whether this was compatible with the requirements of Android. I noted that when you dx the bundle jars produced by the regular Felix build, you get a whole collection of warning of the the form: $ dx --dex --output=classes.dex org.apache.felix.eventadmin-1.2.2.jar warning: Ignoring InnerClasses attribute for an anonymous inner class that doesn't come with an associated EnclosingMethod attribute. (This class was probably produced by a broken compiler.) ...for example. We debated this, and decided that these were just warning and not a real problem. However, now that I have a working Felix framework on Android, I find that when I load and start the EventAdmin bundle, I find that it fails to start with the following message in the log: 05-04 12:01:26.853: WARN/System.err(4682): org.osgi.framework.BundleException: Activator start error in bundle org.apache.felix.eventadmin [5]. 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.activateBundle(Felix.java:1807) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.startBundle(Felix.java:1682) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.startOSGi(SkiftaService.java:437) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.init(SkiftaService.java:174) 05-04 12:01:26.853: WARN/System.err(4682): at com.skifta.android.client.SkiftaService.onCreate(SkiftaService.java:166) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.handleCreateService(ActivityThread.java:2894) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.access$3200(ActivityThread.java:126) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1986) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Handler.dispatchMessage(Handler.java:99) 05-04 12:01:26.853: WARN/System.err(4682): at android.os.Looper.loop(Looper.java:123) 05-04 12:01:26.853: WARN/System.err(4682): at android.app.ActivityThread.main(ActivityThread.java:4595) 05-04 12:01:26.853: WARN/System.err(4682): at java.lang.reflect.Method.invokeNative(Native Method) 05-04 12:01:26.853: WARN/System.err(4682): at java.lang.reflect.Method.invoke(Method.java:521) 05-04 12:01:26.853: WARN/System.err(4682): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:860) 05-04 12:01:26.853: WARN/System.err(4682): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618) 05-04 12:01:26.853: WARN/System.err(4682): at dalvik.system.NativeStart.main(Native Method) 05-04 12:01:26.853: WARN/System.err(4682): Caused by: java.lang.NoClassDefFoundError: org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks$1 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks.init(BlacklistingHandlerTasks.java:223) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.Configuration.start(Configuration.java:293) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.Configuration.init(Configuration.java:152) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.eventadmin.impl.Activator.start(Activator.java:65) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:661) 05-04 12:01:26.853: WARN/System.err(4682): at org.apache.felix.framework.Felix.activateBundle(Felix.java:1760) 05-04 12:01:26.853:
[jira] Commented: (FELIX-2324) Support execution environment so that OBR works properly
[ https://issues.apache.org/jira/browse/FELIX-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12864139#action_12864139 ] Christopher Blunck commented on FELIX-2324: --- I looked up standardization on execution environments in JVMs and I didn't get very far. It appears that execution environments is more of a concept than an actual underlying artifact (accessible via a property or some other construct). There appears to be some disagreement between Bundle-RequireExecutionEnvironment values where some people cite 1.3 vs J2SE-1.3: http://www.mail-archive.com/d...@slf4j.org/msg00843.html This smells like a very slipper slope from a framework perspective. imo the framework should detect the current JVM version and then step backwards in minor versions in an additive fashion, appending each value to the execution environments that are supported. For example... If JVM 1.6.0_X is detected then the execution environments that should be supported are: J2SE-1.6, J2SE-1.5, J2SE-1.4, J2SE-1.3, J2SE-1.2, J2SE-1.1, J2SE-1.0. If an application developer specifies -Dorg.osgi.framework.executionenvironment=foo I'm on fence as to what happens. In one hand I respect the application developer's perspective that foo is the ONLY ee that their app suports. OTOH I also appreciate the perspective that foo should be additive to the other sensed environments. Perhaps a second system property is needed here? Or ... ? Support execution environment so that OBR works properly Key: FELIX-2324 URL: https://issues.apache.org/jira/browse/FELIX-2324 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-2.0.5 Reporter: Christopher Blunck Priority: Minor Fix For: framework-3.0.0 Basic use case here is that I'd like to use Jackson within OBR. Jackson expresses a requirement on ee=J2SE-1.5. Felix Karaf doesn't have a facility for supported execution environments. I can set: JAVA_OPTS=-Dorg.osgi.framework.executionenvironment=J2SE-1.5 before I start karaf from the command line but this seems like a hack. It's very possible that I'll start Karaf using Sun's 1.6 JVM or an IBM JVM. Ideally at startup time Karaf could look at the runtime and determine the JVM version (at the very least). It could then expose the execution environment somehow (presumably in a way that OBR would understand). We should still be able to explicitly set the org.osgi.framework.executionenvironment system property but ideally it'd be additive to the ee's that Karaf senses when it starts up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [gogo] Parameter annotations (Re: svn commit: r940514 - in /felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command: Flag.java Option.java)
I guess we should have tried this out in a sandbox but this experiment seems
rather harmless for existing users and potentially very powerful. And this
experiment is timely because I do have to update RFC 147. Will do different
next time :-)
On 4 mei 2010, at 08:33, Guillaume Nodet wrote:
A few things that would be missing imho to make that interesting:
* parameters annotation to mark parameters as optional or multi-valued
How do you see this? We do have the type of the parameter so we can deduce it
is multi value. However, how do we know the last one? We would need some kind
of separator. And do not forget that we have real objects, not strings.
We had not gotten around the optional mandatory part. I think I'd like to have
a special annotation for that.
* flag and option could be merged (they are the same, maybe use an enum
value on the annotation to differentiate them and maybe have a smart default
value based on the fact that the annotated parameter is a boolean or not)
Well, it is shorter and easier on the eyes to have different annotations I
think.
* option should support a list of value
Not sure how this interplays with the type we also have.
* options should have multiple names (annotations support String[] quite
well)
Ok.
* if we want to add some help information, we need an annotation on the
method
Yes. I think some help on the arguments would also be nice.
* we have a nice coercion mechanism defined in blueprint (handling
generics, collections and such), we should reuse it (without having a
dependency to blueprint)
I agree we should follow the same rules in tsh though implementation code will
differ because the args/options/flags will have to be parsed in the heart of
the method selection algorithm, they directly interfere with it. The low level
type converter should be very similar to the BP type converter I think. When
working on the BP converter I used a lot of lessons from tsh. However, the BP
type converter takes generics better into account.
Kind regards,
Peter Kriens
On Mon, May 3, 2010 at 23:25, Richard S. Hall he...@ungoverned.org wrote:
On 5/3/10 16:56, Guillaume Nodet wrote:
On Mon, May 3, 2010 at 21:17, Richard S. Hallhe...@ungoverned.org
wrote:
On 5/3/10 14:51, Guillaume Nodet wrote:
What are those annotations suppose to actually provide ? It seems all
they
can do is provide some basic help to the user, but does not really help
the
user writing complex commands and dealing with complex arguments.
Have a look at an existing example:
http://svn.apache.org/repos/asf/felix/trunk/karaf/shell/commands/src/main/java/org/apache/felix/karaf/shell/commands/GrepAction.java
I think those annotations would not provide the slightest help in
analyzing
such a command line.
I don't think there will ever be a single solution that can help everyone
implement any possible command. If people need to do something that is
super
complex, then they can always fall back to parsing their own arguments.
I can agree to that, but then I don't see why it has to be in the proposed
spec. Having it as a separate module might be a better approach then.
The issue is you cannot easily do what we are trying to achieve in a
separate module since it is modifying how the runtime coerces arguments when
invoking methods. There is no place to hook into this externally. However, I
agree that it could be just an implementation-specific feature of the Gogo
runtime.
I actually talked with Peter specifically about this and he felt the
feature might be worthwhile for the spec, which is why he committed it
there, but nothing is set in stone at this point.
- richard
At this point, we're just messing around with allowing optional method
parameters and out of order specification of arguments.
- richard
On Mon, May 3, 2010 at 19:01,pkri...@apache.org wrote:
Author: pkriens
Date: Mon May 3 17:01:53 2010
New Revision: 940514
URL: http://svn.apache.org/viewvc?rev=940514view=rev
Log:
Annotations for parameters
Added:
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Option.java
Added:
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java
URL:
http://svn.apache.org/viewvc/felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java?rev=940514view=auto
==
---
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java
(added)
+++
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java
Mon May 3 17:01:53 2010
@@ -0,0 +1,6 @@
+package org.osgi.service.command;
+
+public @interface Flag {
+ String name();
+ String help() default no help;
+}
Added:
