Re: [WebConsoel] ConfigurationPrinter service
Felix Meschberger wrote Hi all, FELIX-2649 introduced the facility to register a service as a ConfigurationPrinter for the web console without actually implementing the interface but merely being registered with a number of required registration properties and implementing one of the ConfigurationPrinter or ModeAwareConfigurationPrinter methods. The problem now is, that FELIX-2649 introduced a new property allowing the definition of the configuration printer modes located in the WebConsoleConstants class. So we now have two situations: A ConfigurationPrinter service (implementing the interface) has to register the supported modes in a different registration property than a ConfigurationPrinter not implementing the ConfigurationPrinter interface. I think this inconsistency is bad and error-prone. IMHO we should drop the newly introduced property (WebConsoleConstants.CONFIG_PRINTER_MODES) and only use the old property ConfigurationPrinter.PROPERTY_MODES. Alternatively we might define the WebConsoleConstants.CONFIG_PRINTER_MODES to the same value as the ConfigurationPrinter.PROPERTY_MODES constant. Or we really mark the old ConfigurationPrinter.PROPERTY_MODES constant deprecated and primarily use the new WebConsoleConstants.CONFIG_PRINTER_MODES in all cases and only falling back to the old property if a ConfigurationPrinter implementation does not have the new property (to support existing implementations). Thanks for bringing this up Felix - it was actually on my todo list, but I forgot about it. The new property is used to detect configuration printers not implementing the interfaces - the name is more unique than the old value (which is just modes). I think the mistake is that we used this short name for the property in the first place. Therefore I think we should deprecate the old value and use the new one (falling back to the old prop if new is missing). Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Created: (FELIX-2658) Deprecate ConfigurationPrinter.PROPERTY_MODES constant
Deprecate ConfigurationPrinter.PROPERTY_MODES constant -- Key: FELIX-2658 URL: https://issues.apache.org/jira/browse/FELIX-2658 Project: Felix Issue Type: Bug Components: Web Console Reporter: Felix Meschberger Assignee: Carsten Ziegeler Fix For: webconsole-3.1.4 As discussed on the dev list [1] : The ConfigurationPrinter.PROPERTY_MODES should be deprecated (replaced by the WebConsoleConstants.CONFIG_PRINTER_MODES constant. Still the deprecated constant should be supported as a fallback in case the new constant is not used in the ConfigurationPrinter service registration. [1] http://markmail.org/message/hruez7l2g5lfasnu -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2659) ConfigurationRender.searchMethod must catch problems more broadly
ConfigurationRender.searchMethod must catch problems more broadly - Key: FELIX-2659 URL: https://issues.apache.org/jira/browse/FELIX-2659 Project: Felix Issue Type: Bug Components: Web Console Reporter: Felix Meschberger Fix For: webconsole-3.1.4 The ConfigurationRender.searchMethod looks up a method by reflection and catches any NoSuchMethodException thrown. There are situations, though, where a ClassDefNotFoundError may be thrown -- noticed in the PermissionAdmin Configuration Printer if the ConfigurationAdmin API is not available - which must also be caught to not break the generation of the configuration status ZIP file. Proposed solution is to just ignore any Throwable and assume method not found and thus ignore -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-2659) ConfigurationRender.searchMethod must catch problems more broadly
[ https://issues.apache.org/jira/browse/FELIX-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned FELIX-2659: --- Assignee: Carsten Ziegeler ConfigurationRender.searchMethod must catch problems more broadly - Key: FELIX-2659 URL: https://issues.apache.org/jira/browse/FELIX-2659 Project: Felix Issue Type: Bug Components: Web Console Reporter: Felix Meschberger Assignee: Carsten Ziegeler Fix For: webconsole-3.1.4 The ConfigurationRender.searchMethod looks up a method by reflection and catches any NoSuchMethodException thrown. There are situations, though, where a ClassDefNotFoundError may be thrown -- noticed in the PermissionAdmin Configuration Printer if the ConfigurationAdmin API is not available - which must also be caught to not break the generation of the configuration status ZIP file. Proposed solution is to just ignore any Throwable and assume method not found and thus ignore -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Documenting API evolution
Hi all, To document in JavaDoc the evolution of the API of a class we generally (and should) use the @since tag. Traditionally, this tag is provided with the first release version of the library included the modified API (e.g. the added method or constant). With OSGi where we not only have the module/bundle level versioning but also the independent versioning of the exported packages, just listing the library version in the @since tag seems a bit wrong. I started listing the actual package export version as the primary value of the @since tag adding also the bundle version first exporting this package version. For example: /** * ... * * @since 3.1.2; Web Console Bundle 3.1.4 */ public static final String CONFIG_PRINTER_MODES =... Does this make sense in terms of good practice ? Regards Felix
FELIX-2655: allow event admin log level to be configurable
Hi, I have attached a patch for this issue in JIRA. I would like to know from the developers of event admin service if they are fine with the change. The change can be described as adding a configuration option to control the logger's log level and the default being LOG_WARNING. Hope someone will look at it soon. Thanks, Sahoo Original Message Subject: [jira] Created: (FELIX-2655) allow event admin log level to be configurable Date: Wed, 13 Oct 2010 15:53:32 -0400 (EDT) From: Sahoo (JIRA) j...@apache.org Reply-To: dev@felix.apache.org To: dev@felix.apache.org allow event admin log level to be configurable -- Key: FELIX-2655 URL: https://issues.apache.org/jira/browse/FELIX-2655 Project: Felix Issue Type: Bug Components: Event Admin Reporter: Sahoo Fix For: eventadmin-1.2.4 Currently eventadmin bundle prints messages like these: DEBUG: EventAdmin: org.apache.felix.eventadmin.CacheSize=30 DEBUG: EventAdmin: org.apache.felix.eventadmin.ThreadPoolSize=20 DEBUG: EventAdmin: org.apache.felix.eventadmin.Timeout=5000 DEBUG: EventAdmin: org.apache.felix.eventadmin.RequireTopic=true In my env, there is no LogService, so the messages appear in System.out. I don't see any way to disable them from being logged. Should we not make the log level configurable just like it is done in FileInstall? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2655) allow event admin log level to be configurable
[ https://issues.apache.org/jira/browse/FELIX-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sahoo updated FELIX-2655: - Attachment: FELIX-2655-patch.txt Patch that addresses the issue. The change can be described as adding a configuration option to control the logger's log level and the default being LOG_WARNING. allow event admin log level to be configurable -- Key: FELIX-2655 URL: https://issues.apache.org/jira/browse/FELIX-2655 Project: Felix Issue Type: Bug Components: Event Admin Reporter: Sahoo Fix For: eventadmin-1.2.4 Attachments: FELIX-2655-patch.txt Currently eventadmin bundle prints messages like these: DEBUG: EventAdmin: org.apache.felix.eventadmin.CacheSize=30 DEBUG: EventAdmin: org.apache.felix.eventadmin.ThreadPoolSize=20 DEBUG: EventAdmin: org.apache.felix.eventadmin.Timeout=5000 DEBUG: EventAdmin: org.apache.felix.eventadmin.RequireTopic=true In my env, there is no LogService, so the messages appear in System.out. I don't see any way to disable them from being logged. Should we not make the log level configurable just like it is done in FileInstall? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2655) allow event admin log level to be configurable
[ https://issues.apache.org/jira/browse/FELIX-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-2655: Affects Version/s: eventadmin-1.2.4 Fix Version/s: (was: eventadmin-1.2.4) eventadmin-1.2.8 allow event admin log level to be configurable -- Key: FELIX-2655 URL: https://issues.apache.org/jira/browse/FELIX-2655 Project: Felix Issue Type: Bug Components: Event Admin Affects Versions: eventadmin-1.2.4 Reporter: Sahoo Fix For: eventadmin-1.2.8 Attachments: FELIX-2655-patch.txt Currently eventadmin bundle prints messages like these: DEBUG: EventAdmin: org.apache.felix.eventadmin.CacheSize=30 DEBUG: EventAdmin: org.apache.felix.eventadmin.ThreadPoolSize=20 DEBUG: EventAdmin: org.apache.felix.eventadmin.Timeout=5000 DEBUG: EventAdmin: org.apache.felix.eventadmin.RequireTopic=true In my env, there is no LogService, so the messages appear in System.out. I don't see any way to disable them from being logged. Should we not make the log level configurable just like it is done in FileInstall? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2655) allow event admin log level to be configurable
[ https://issues.apache.org/jira/browse/FELIX-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920876#action_12920876 ] Carsten Ziegeler commented on FELIX-2655: - The patch looks good to me allow event admin log level to be configurable -- Key: FELIX-2655 URL: https://issues.apache.org/jira/browse/FELIX-2655 Project: Felix Issue Type: Bug Components: Event Admin Affects Versions: eventadmin-1.2.4 Reporter: Sahoo Fix For: eventadmin-1.2.8 Attachments: FELIX-2655-patch.txt Currently eventadmin bundle prints messages like these: DEBUG: EventAdmin: org.apache.felix.eventadmin.CacheSize=30 DEBUG: EventAdmin: org.apache.felix.eventadmin.ThreadPoolSize=20 DEBUG: EventAdmin: org.apache.felix.eventadmin.Timeout=5000 DEBUG: EventAdmin: org.apache.felix.eventadmin.RequireTopic=true In my env, there is no LogService, so the messages appear in System.out. I don't see any way to disable them from being logged. Should we not make the log level configurable just like it is done in FileInstall? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: FELIX-2655: allow event admin log level to be configurable
Hi, the patch looks good to me. I've changed the target version for the issue to 1.2.8 which will be the next release. Regards Carsten Sanjeeb Sahoo wrote Hi, I have attached a patch for this issue in JIRA. I would like to know from the developers of event admin service if they are fine with the change. The change can be described as adding a configuration option to control the logger's log level and the default being LOG_WARNING. Hope someone will look at it soon. Thanks, Sahoo Original Message Subject: [jira] Created: (FELIX-2655) allow event admin log level to be configurable Date: Wed, 13 Oct 2010 15:53:32 -0400 (EDT) From: Sahoo (JIRA) j...@apache.org Reply-To: dev@felix.apache.org To: dev@felix.apache.org allow event admin log level to be configurable -- Key: FELIX-2655 URL: https://issues.apache.org/jira/browse/FELIX-2655 Project: Felix Issue Type: Bug Components: Event Admin Reporter: Sahoo Fix For: eventadmin-1.2.4 Currently eventadmin bundle prints messages like these: DEBUG: EventAdmin: org.apache.felix.eventadmin.CacheSize=30 DEBUG: EventAdmin: org.apache.felix.eventadmin.ThreadPoolSize=20 DEBUG: EventAdmin: org.apache.felix.eventadmin.Timeout=5000 DEBUG: EventAdmin: org.apache.felix.eventadmin.RequireTopic=true In my env, there is no LogService, so the messages appear in System.out. I don't see any way to disable them from being logged. Should we not make the log level configurable just like it is done in FileInstall? -- Carsten Ziegeler cziege...@apache.org
[jira] Resolved: (FELIX-2658) Deprecate ConfigurationPrinter.PROPERTY_MODES constant
[ https://issues.apache.org/jira/browse/FELIX-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-2658. - Resolution: Fixed Fixed in revision 1022445 Deprecate ConfigurationPrinter.PROPERTY_MODES constant -- Key: FELIX-2658 URL: https://issues.apache.org/jira/browse/FELIX-2658 Project: Felix Issue Type: Bug Components: Web Console Reporter: Felix Meschberger Assignee: Carsten Ziegeler Fix For: webconsole-3.1.4 As discussed on the dev list [1] : The ConfigurationPrinter.PROPERTY_MODES should be deprecated (replaced by the WebConsoleConstants.CONFIG_PRINTER_MODES constant. Still the deprecated constant should be supported as a fallback in case the new constant is not used in the ConfigurationPrinter service registration. [1] http://markmail.org/message/hruez7l2g5lfasnu -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2659) ConfigurationRender.searchMethod must catch problems more broadly
[ https://issues.apache.org/jira/browse/FELIX-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-2659. - Resolution: Fixed Catching throwable with revision 1022448 ConfigurationRender.searchMethod must catch problems more broadly - Key: FELIX-2659 URL: https://issues.apache.org/jira/browse/FELIX-2659 Project: Felix Issue Type: Bug Components: Web Console Reporter: Felix Meschberger Assignee: Carsten Ziegeler Fix For: webconsole-3.1.4 The ConfigurationRender.searchMethod looks up a method by reflection and catches any NoSuchMethodException thrown. There are situations, though, where a ClassDefNotFoundError may be thrown -- noticed in the PermissionAdmin Configuration Printer if the ConfigurationAdmin API is not available - which must also be caught to not break the generation of the configuration status ZIP file. Proposed solution is to just ignore any Throwable and assume method not found and thus ignore -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Documenting API evolution
On 10/14/10 2:48, Felix Meschberger wrote: Hi all, To document in JavaDoc the evolution of the API of a class we generally (and should) use the @since tag. Traditionally, this tag is provided with the first release version of the library included the modified API (e.g. the added method or constant). With OSGi where we not only have the module/bundle level versioning but also the independent versioning of the exported packages, just listing the library version in the @since tag seems a bit wrong. I started listing the actual package export version as the primary value of the @since tag adding also the bundle version first exporting this package version. For example: /** * ... * * @since 3.1.2; Web Console Bundle 3.1.4 */ public static final String CONFIG_PRINTER_MODES =... Does this make sense in terms of good practice ? Certainly using the package version makes sense. I think the bundle version makes less sense since the packages could be re-packaged into other bundles, like we do with the OSGi API and others. But it doesn't harm anything. - richard Regards Felix
[jira] Created: (FELIX-2660) Prevent Bundle ConfigurationPrinter from being used in the web output
Prevent Bundle ConfigurationPrinter from being used in the web output - Key: FELIX-2660 URL: https://issues.apache.org/jira/browse/FELIX-2660 Project: Felix Issue Type: Improvement Components: Web Console Affects Versions: webconsole-3.1.2 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: webconsole-3.1.4 The root cause for FELIX-2613 (which makes in itself, too) is that the Bundles tab is generally the first to be loaded when the Configuration Status page is selected. Loading this page takes a long time depending on the number of bundles installed. Since the same information is actually also available from the Bundles page itself it makes probably not much sense to repeat this information in the regular web output of the Configuration Status page. It makes of course sense to include the information in the text file or ZIP file output. Thus we should prevent the Bundles tab from being displayed in the web output of the Configuration Status page. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2570) HTML is escaped in ModeAwareConfigurationPrinter when in web mode
[ https://issues.apache.org/jira/browse/FELIX-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920961#action_12920961 ] Felix Meschberger commented on FELIX-2570: -- Committed the changes in Rev. 1022523. Added a new service registration property WebConsoleConstants.CONFIG_PRINTER_WEB_UNESCAPED = felix.webconsole.configprinter.web.unescaped; If this property is set to true (Boolean true or String true) the output of the respective Configuration Printer service is not escaped when displayed in the web display. Of course the configuration printer has to take care to not generate HTML when printing status in non-web mode, like text or ZIP. Does this suit your need ? HTML is escaped in ModeAwareConfigurationPrinter when in web mode --- Key: FELIX-2570 URL: https://issues.apache.org/jira/browse/FELIX-2570 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-3.1.2 Reporter: Justin Edelson Assignee: Felix Meschberger See http://markmail.org/message/ppwjjbc6tayzvcew -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Documenting API evolution
On 14.10.2010 14:59, Richard S. Hall wrote: On 10/14/10 2:48, Felix Meschberger wrote: snip /** * ... * * @since 3.1.2; Web Console Bundle 3.1.4 */ public static final String CONFIG_PRINTER_MODES =... Does this make sense in terms of good practice ? Certainly using the package version makes sense. I think the bundle version makes less sense since the packages could be re-packaged into other bundles, like we do with the OSGi API and others. But it doesn't harm anything. I agree. Also I'd think that using bundle symbolic name in the tag might be safer than the descriptive name because it is more stable. Premek -- Premek Brada (Ing et MSc, PhD) Lecturer in Software enginering, Webmaster Department of Computer Science and Engineering University of West Bohemia, Pilsen, CZ brada at kiv.zcu.cz | www.kiv.zcu.cz/~brada/ | +420-377-63-2435
[jira] Resolved: (FELIX-2660) Prevent Bundle ConfigurationPrinter from being used in the web output
[ https://issues.apache.org/jira/browse/FELIX-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-2660. -- Resolution: Fixed Fixed in Rev. 1022527 by setting printer mode service registration property for the bundles configuration printer to text, zip thus preventing the bundles tab from being displayed Prevent Bundle ConfigurationPrinter from being used in the web output - Key: FELIX-2660 URL: https://issues.apache.org/jira/browse/FELIX-2660 Project: Felix Issue Type: Improvement Components: Web Console Affects Versions: webconsole-3.1.2 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: webconsole-3.1.4 The root cause for FELIX-2613 (which makes in itself, too) is that the Bundles tab is generally the first to be loaded when the Configuration Status page is selected. Loading this page takes a long time depending on the number of bundles installed. Since the same information is actually also available from the Bundles page itself it makes probably not much sense to repeat this information in the regular web output of the Configuration Status page. It makes of course sense to include the information in the text file or ZIP file output. Thus we should prevent the Bundles tab from being displayed in the web output of the Configuration Status page. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2570) HTML is escaped in ModeAwareConfigurationPrinter when in web mode
[ https://issues.apache.org/jira/browse/FELIX-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-2570: - Fix Version/s: webconsole-3.1.4 HTML is escaped in ModeAwareConfigurationPrinter when in web mode --- Key: FELIX-2570 URL: https://issues.apache.org/jira/browse/FELIX-2570 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-3.1.2 Reporter: Justin Edelson Assignee: Felix Meschberger Fix For: webconsole-3.1.4 See http://markmail.org/message/ppwjjbc6tayzvcew -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2661) [Gogo] It should be easier to start Gogo shell non-interactively
[Gogo] It should be easier to start Gogo shell non-interactively Key: FELIX-2661 URL: https://issues.apache.org/jira/browse/FELIX-2661 Project: Felix Issue Type: Improvement Components: Gogo Shell Affects Versions: gogo-0.6.1 Reporter: Richard S. Hall Fix For: gogo-0.8.0 To start the Gogo shell non-interactively, you have to specify a dummy command and tell it not to shutdown in its configuration...something like this: gosh.args=--noshutdown -c noop=true This is not necessarily the most straightforward approach and it also results in the gosh_profile being executed and the MOTD being displayed, which doesn't really make sense in the non-interactive use case. It seems like it would be better to have an explicit flag to tell the Gogo shell to start up non-interactively (e.g., --noninteractive), which would also imply not shutting down, but wouldn't require a dummy command, nor execute the gosh_profile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-2661) [Gogo] It should be easier to start Gogo shell non-interactively
[ https://issues.apache.org/jira/browse/FELIX-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum reassigned FELIX-2661: - Assignee: Derek Baum [Gogo] It should be easier to start Gogo shell non-interactively Key: FELIX-2661 URL: https://issues.apache.org/jira/browse/FELIX-2661 Project: Felix Issue Type: Improvement Components: Gogo Shell Affects Versions: gogo-0.6.1 Reporter: Richard S. Hall Assignee: Derek Baum Fix For: gogo-0.8.0 To start the Gogo shell non-interactively, you have to specify a dummy command and tell it not to shutdown in its configuration...something like this: gosh.args=--noshutdown -c noop=true This is not necessarily the most straightforward approach and it also results in the gosh_profile being executed and the MOTD being displayed, which doesn't really make sense in the non-interactive use case. It seems like it would be better to have an explicit flag to tell the Gogo shell to start up non-interactively (e.g., --noninteractive), which would also imply not shutting down, but wouldn't require a dummy command, nor execute the gosh_profile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (FELIX-2661) [Gogo] It should be easier to start Gogo shell non-interactively
[ https://issues.apache.org/jira/browse/FELIX-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-2661 started by Derek Baum. [Gogo] It should be easier to start Gogo shell non-interactively Key: FELIX-2661 URL: https://issues.apache.org/jira/browse/FELIX-2661 Project: Felix Issue Type: Improvement Components: Gogo Shell Affects Versions: gogo-0.6.1 Reporter: Richard S. Hall Assignee: Derek Baum Fix For: gogo-0.8.0 To start the Gogo shell non-interactively, you have to specify a dummy command and tell it not to shutdown in its configuration...something like this: gosh.args=--noshutdown -c noop=true This is not necessarily the most straightforward approach and it also results in the gosh_profile being executed and the MOTD being displayed, which doesn't really make sense in the non-interactive use case. It seems like it would be better to have an explicit flag to tell the Gogo shell to start up non-interactively (e.g., --noninteractive), which would also imply not shutting down, but wouldn't require a dummy command, nor execute the gosh_profile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2662) [Gogo] Consider more fully qualified configuration property names
[Gogo] Consider more fully qualified configuration property names - Key: FELIX-2662 URL: https://issues.apache.org/jira/browse/FELIX-2662 Project: Felix Issue Type: Task Components: Gogo Shell Affects Versions: gogo-0.6.1 Reporter: Richard S. Hall Priority: Minor Fix For: gogo-0.8.0 I am not sure if this applies to the other Gogo modules, but Gogo Shell uses configuration property names like gosh.args and gosh.home, but these should likely be more fully qualified names. For the framework, we've typically used names like felix.* although one could argue for org.apache.felix.*...I think the former is sufficient. For the precise names, it is not clear if they should be felix.gosh.args or felix.gogo.shell.args...I assume if the runtime has config properties they would be felix.gogo.runtime.*... We just need to think about this and make things consistent and meaningful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2653) LinkageError caused by duplicate class definition during implicit boot delegation
[ https://issues.apache.org/jira/browse/FELIX-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sahoo updated FELIX-2653: - Description: I am seeing linkage errors caused by attempt to load duplicate classes and I think it is caused by implicit boot delegation. In our server log, we see the following exception stack: java.lang.LinkageError: loader (instance of java/net/URLClassLoader): attempted duplicate class definition for name: com/acme/Foo at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at com.acme.Foo$Factory.bar(Foo.java:93) I tried to trace the execution to find out what causes the class to be defined for the first time and with the help of btrace (http://projectkenai.com/projects/btrace/), I could obtain the stack and relevant information. First time the class is defined, the stack looks like this: java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) java.net.URLClassLoader.defineClass(URLClassLoader.java:283) java.net.URLClassLoader.access$000(URLClassLoader.java:58) java.net.URLClassLoader$1.run(URLClassLoader.java:197) java.security.AccessController.doPrivileged(Native Method) java.net.URLClassLoader.findClass(URLClassLoader.java:190) java.lang.ClassLoader.loadClass(ClassLoader.java:307) java.lang.ClassLoader.loadClass(ClassLoader.java:248) org.apache.felix.framework.ModuleImpl.getEnclosingClass(ModuleImpl.java:1570) org.apache.felix.framework.ModuleImpl.isClassNotLoadedFromBundle(ModuleImpl.java:1545) org.apache.felix.framework.ModuleImpl.doImplicitBootDelegation(ModuleImpl.java:1498) org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1452) org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:727) org.apache.felix.framework.ModuleImpl.access$300(ModuleImpl.java:73) org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1733) java.lang.ClassLoader.loadClass(ClassLoader.java:248) org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:638) org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1599) org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:904) org.jvnet.hk2.osgiadapter.OSGiModuleImpl$3$1.run(OSGiModuleImpl.java:399) java.security.AccessController.doPrivileged(Native Method) org.jvnet.hk2.osgiadapter.OSGiModuleImpl$3.loadClass(OSGiModuleImpl.java:395) java.lang.ClassLoader.loadClass(ClassLoader.java:248) com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:169) java.lang.ClassLoader.loadClass(ClassLoader.java:296) java.lang.ClassLoader.loadClass(ClassLoader.java:248) com.acme.Foo$Factory.bar(Foo.java:93) As you can see, when bar method is called, VM tries to load com.acme.Foo.class and the call reaches org.apache.felix.framework.ModuleImpl.getEnclosingClass. getEnclosingClass actually causes the enclosing class, com.acme.Foo, to be defined. So, VM actually records this new class in loaded classes cache of the appropriate loader, but Felix does not consult the loaded classes cache again before trying to define the class. was: I am seeing linkage errors caused by attempt to load duplicate classes and I think it is caused by implicit boot delegation. In our server log, we see the following exception stack: java.lang.LinkageError: loader (instance of java/net/URLClassLoader): attempted duplicate class definition for name: com/acme/Foo at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at
[jira] Resolved: (FELIX-2661) [Gogo] It should be easier to start Gogo shell non-interactively
[ https://issues.apache.org/jira/browse/FELIX-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2661. --- Resolution: Fixed added --nointeractive flag to gosh, so no interactive startup can now be achieved using: $ java -Dgosh.args=--nointeractive bin/felix.jar It is no longer necessary to specify a dummy command like '-sc echo'. The gosh_profile is not run in non-interactive mode (so the gogo banner will not be displayed). However, new sessions created by telnet or ssh, will be interactive and thus run gosh_profile and show gogo banner. [Gogo] It should be easier to start Gogo shell non-interactively Key: FELIX-2661 URL: https://issues.apache.org/jira/browse/FELIX-2661 Project: Felix Issue Type: Improvement Components: Gogo Shell Affects Versions: gogo-0.6.1 Reporter: Richard S. Hall Assignee: Derek Baum Fix For: gogo-0.8.0 To start the Gogo shell non-interactively, you have to specify a dummy command and tell it not to shutdown in its configuration...something like this: gosh.args=--noshutdown -c noop=true This is not necessarily the most straightforward approach and it also results in the gosh_profile being executed and the MOTD being displayed, which doesn't really make sense in the non-interactive use case. It seems like it would be better to have an explicit flag to tell the Gogo shell to start up non-interactively (e.g., --noninteractive), which would also imply not shutting down, but wouldn't require a dummy command, nor execute the gosh_profile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2653) LinkageError caused by duplicate class definition during implicit boot delegation
[ https://issues.apache.org/jira/browse/FELIX-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920997#action_12920997 ] Richard S. Hall commented on FELIX-2653: Just some more summary, it appears that the situation is such that we are getting a request for a class that a bundle shouldn't have. However, as part of our normal processing of a failed class request we try to determine if we should implicitly boot delegate if the request was coming from external code. In this particular scenario we ended up causing the class being requested to be defined as a byproduct in getEnclosingClass(). Thus, when we get back to the original class loader, it has already checked for the class and doesn't check again, so it gets a duplicate definition error. I'm not sure if we can resolve this in a general way. LinkageError caused by duplicate class definition during implicit boot delegation - Key: FELIX-2653 URL: https://issues.apache.org/jira/browse/FELIX-2653 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-3.0.4 Environment: java version 1.6.0_21 Java(TM) SE Runtime Environment (build 1.6.0_21-b06) Java HotSpot(TM) Server VM (build 17.0-b16, mixed mode) Reporter: Sahoo Assignee: Richard S. Hall Priority: Critical Fix For: framework-3.2.0 I am seeing linkage errors caused by attempt to load duplicate classes and I think it is caused by implicit boot delegation. In our server log, we see the following exception stack: java.lang.LinkageError: loader (instance of java/net/URLClassLoader): attempted duplicate class definition for name: com/acme/Foo at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at com.acme.Foo$Factory.bar(Foo.java:93) I tried to trace the execution to find out what causes the class to be defined for the first time and with the help of btrace (http://projectkenai.com/projects/btrace/), I could obtain the stack and relevant information. First time the class is defined, the stack looks like this: java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) java.net.URLClassLoader.defineClass(URLClassLoader.java:283) java.net.URLClassLoader.access$000(URLClassLoader.java:58) java.net.URLClassLoader$1.run(URLClassLoader.java:197) java.security.AccessController.doPrivileged(Native Method) java.net.URLClassLoader.findClass(URLClassLoader.java:190) java.lang.ClassLoader.loadClass(ClassLoader.java:307) java.lang.ClassLoader.loadClass(ClassLoader.java:248) org.apache.felix.framework.ModuleImpl.getEnclosingClass(ModuleImpl.java:1570) org.apache.felix.framework.ModuleImpl.isClassNotLoadedFromBundle(ModuleImpl.java:1545) org.apache.felix.framework.ModuleImpl.doImplicitBootDelegation(ModuleImpl.java:1498) org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1452) org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:727) org.apache.felix.framework.ModuleImpl.access$300(ModuleImpl.java:73) org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1733) java.lang.ClassLoader.loadClass(ClassLoader.java:248) org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:638) org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1599) org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:904) org.jvnet.hk2.osgiadapter.OSGiModuleImpl$3$1.run(OSGiModuleImpl.java:399) java.security.AccessController.doPrivileged(Native Method) org.jvnet.hk2.osgiadapter.OSGiModuleImpl$3.loadClass(OSGiModuleImpl.java:395) java.lang.ClassLoader.loadClass(ClassLoader.java:248) com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:169) java.lang.ClassLoader.loadClass(ClassLoader.java:296) java.lang.ClassLoader.loadClass(ClassLoader.java:248) com.acme.Foo$Factory.bar(Foo.java:93) As you can see, when bar method is called, VM tries to load com.acme.Foo.class and the call reaches
[jira] Commented: (FELIX-2661) [Gogo] It should be easier to start Gogo shell non-interactively
[ https://issues.apache.org/jira/browse/FELIX-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921018#action_12921018 ] Richard S. Hall commented on FELIX-2661: It is not clear that -i is a good alias for --nointeractive... [Gogo] It should be easier to start Gogo shell non-interactively Key: FELIX-2661 URL: https://issues.apache.org/jira/browse/FELIX-2661 Project: Felix Issue Type: Improvement Components: Gogo Shell Affects Versions: gogo-0.6.1 Reporter: Richard S. Hall Assignee: Derek Baum Fix For: gogo-0.8.0 To start the Gogo shell non-interactively, you have to specify a dummy command and tell it not to shutdown in its configuration...something like this: gosh.args=--noshutdown -c noop=true This is not necessarily the most straightforward approach and it also results in the gosh_profile being executed and the MOTD being displayed, which doesn't really make sense in the non-interactive use case. It seems like it would be better to have an explicit flag to tell the Gogo shell to start up non-interactively (e.g., --noninteractive), which would also imply not shutting down, but wouldn't require a dummy command, nor execute the gosh_profile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2661) [Gogo] It should be easier to start Gogo shell non-interactively
[ https://issues.apache.org/jira/browse/FELIX-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921021#action_12921021 ] Derek Baum commented on FELIX-2661: --- It is not clear that -i is a good alias for --nointeractive... aliases are a single letter, so -n would be ambiguous with --noshutdown. Often CAPS are used for single letter inverse options (-I), but in this case I don't think that there's any need for an alias. Aliases are generally used to save interactive typing. The full long option name is preferred in scripts as it is self-documenting, rather than wondering what the -i or -ni option does. Long options can be abbreviated to their shortest unambiguous form, e.g. --noi and --nos. So shall we just remove the -i alias for --nointeractive? [Gogo] It should be easier to start Gogo shell non-interactively Key: FELIX-2661 URL: https://issues.apache.org/jira/browse/FELIX-2661 Project: Felix Issue Type: Improvement Components: Gogo Shell Affects Versions: gogo-0.6.1 Reporter: Richard S. Hall Assignee: Derek Baum Fix For: gogo-0.8.0 To start the Gogo shell non-interactively, you have to specify a dummy command and tell it not to shutdown in its configuration...something like this: gosh.args=--noshutdown -c noop=true This is not necessarily the most straightforward approach and it also results in the gosh_profile being executed and the MOTD being displayed, which doesn't really make sense in the non-interactive use case. It seems like it would be better to have an explicit flag to tell the Gogo shell to start up non-interactively (e.g., --noninteractive), which would also imply not shutting down, but wouldn't require a dummy command, nor execute the gosh_profile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2661) [Gogo] It should be easier to start Gogo shell non-interactively
[ https://issues.apache.org/jira/browse/FELIX-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921059#action_12921059 ] Richard S. Hall commented on FELIX-2661: I'm fine with just having the long name. [Gogo] It should be easier to start Gogo shell non-interactively Key: FELIX-2661 URL: https://issues.apache.org/jira/browse/FELIX-2661 Project: Felix Issue Type: Improvement Components: Gogo Shell Affects Versions: gogo-0.6.1 Reporter: Richard S. Hall Assignee: Derek Baum Fix For: gogo-0.8.0 To start the Gogo shell non-interactively, you have to specify a dummy command and tell it not to shutdown in its configuration...something like this: gosh.args=--noshutdown -c noop=true This is not necessarily the most straightforward approach and it also results in the gosh_profile being executed and the MOTD being displayed, which doesn't really make sense in the non-interactive use case. It seems like it would be better to have an explicit flag to tell the Gogo shell to start up non-interactively (e.g., --noninteractive), which would also imply not shutting down, but wouldn't require a dummy command, nor execute the gosh_profile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-2655) allow event admin log level to be configurable
[ https://issues.apache.org/jira/browse/FELIX-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sahoo reassigned FELIX-2655: Assignee: Sahoo allow event admin log level to be configurable -- Key: FELIX-2655 URL: https://issues.apache.org/jira/browse/FELIX-2655 Project: Felix Issue Type: Bug Components: Event Admin Affects Versions: eventadmin-1.2.4 Reporter: Sahoo Assignee: Sahoo Fix For: eventadmin-1.2.8 Attachments: FELIX-2655-patch.txt Currently eventadmin bundle prints messages like these: DEBUG: EventAdmin: org.apache.felix.eventadmin.CacheSize=30 DEBUG: EventAdmin: org.apache.felix.eventadmin.ThreadPoolSize=20 DEBUG: EventAdmin: org.apache.felix.eventadmin.Timeout=5000 DEBUG: EventAdmin: org.apache.felix.eventadmin.RequireTopic=true In my env, there is no LogService, so the messages appear in System.out. I don't see any way to disable them from being logged. Should we not make the log level configurable just like it is done in FileInstall? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2655) allow event admin log level to be configurable
[ https://issues.apache.org/jira/browse/FELIX-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sahoo resolved FELIX-2655. -- Resolution: Fixed Committed the attached patch as revision 1022638. allow event admin log level to be configurable -- Key: FELIX-2655 URL: https://issues.apache.org/jira/browse/FELIX-2655 Project: Felix Issue Type: Bug Components: Event Admin Affects Versions: eventadmin-1.2.4 Reporter: Sahoo Assignee: Sahoo Fix For: eventadmin-1.2.8 Attachments: FELIX-2655-patch.txt Currently eventadmin bundle prints messages like these: DEBUG: EventAdmin: org.apache.felix.eventadmin.CacheSize=30 DEBUG: EventAdmin: org.apache.felix.eventadmin.ThreadPoolSize=20 DEBUG: EventAdmin: org.apache.felix.eventadmin.Timeout=5000 DEBUG: EventAdmin: org.apache.felix.eventadmin.RequireTopic=true In my env, there is no LogService, so the messages appear in System.out. I don't see any way to disable them from being logged. Should we not make the log level configurable just like it is done in FileInstall? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2645) Add a (hidden) way to retrieve a local URL for a given bundle URL
[ https://issues.apache.org/jira/browse/FELIX-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall resolved FELIX-2645. Resolution: Fixed I refactored the patch to convert bundle URLs to local URLs at the point of return to avoid the need for a ThreadLocal and anonymous inner class. Add a (hidden) way to retrieve a local URL for a given bundle URL - Key: FELIX-2645 URL: https://issues.apache.org/jira/browse/FELIX-2645 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-3.0.3 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: framework-3.2.0 Original Estimate: 2h Remaining Estimate: 2h This is actually very important to support libraries that need to do class-path scanning. A better solution will certainly come from the OSGi alliance in 4.3, but in the mean time, there's no way to do that in Felix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2556) FileInstall fails to update fragments as it tries to stop them
[ https://issues.apache.org/jira/browse/FELIX-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sahoo resolved FELIX-2556. -- Resolution: Fixed Fix Version/s: fileinstall-3.1.0 Assignee: Sahoo Committed the above patch as revision 1022686. FileInstall fails to update fragments as it tries to stop them -- Key: FELIX-2556 URL: https://issues.apache.org/jira/browse/FELIX-2556 Project: Felix Issue Type: Bug Components: File Install Affects Versions: fileinstall-3.0.2 Reporter: Sahoo Assignee: Sahoo Priority: Minor Fix For: fileinstall-3.1.0 Attachments: patch org.osgi.framework.BundleException: Fragment bundles can not be stopped: webapp-fragment [259]|#] at org.apache.felix.framework.Felix.stopBundle(Felix.java:2194)|#] at org.apache.felix.framework.BundleImpl.stop(BundleImpl.java:941)|#] at org.apache.felix.fileinstall.internal.DirectoryWatcher.stopTransient(DirectoryWatcher.java:1091)|#] at org.apache.felix.fileinstall.internal.DirectoryWatcher.update(DirectoryWatcher.java:1035)|#] at org.apache.felix.fileinstall.internal.DirectoryWatcher.update(DirectoryWatcher.java:826)|#] at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:422)|#] at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:241)|#] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2663) Allow ConfigInstaller to perform placeholder substitution from framework properties
Allow ConfigInstaller to perform placeholder substitution from framework
properties
---
Key: FELIX-2663
URL: https://issues.apache.org/jira/browse/FELIX-2663
Project: Felix
Issue Type: Improvement
Components: File Install
Affects Versions: fileinstall-3.0.2
Reporter: David Hay
The ConfigInstaller class will perform placeholder substitution using
configuration values defined elsewhere in the .cfg file or using System
properties. Would be nice if it could also use properties defined by the
framework (i.e. BundleContext.getProperty())
The use case is this: As part of the OSGi framework initialization, some
properties are set on the framework that define things such as a home
directory. The various configuration files could then refer to resources
relative to this home directory. For example:
props.setProperty(app.home, homeDir); // homeDir provided by JNDI config, env
variable, etc.
frameworkFactory.newFramework(props);
...
Then, in a configuration file read by the FileInstall bundle, it would be nice
to be able to do:
data.directory=${app.home}/data/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2663) Allow ConfigInstaller to perform placeholder substitution from framework properties
[
https://issues.apache.org/jira/browse/FELIX-2663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921115#action_12921115
]
Richard S. Hall commented on FELIX-2663:
File Install just needs to use BundleContext.getProperty() for its property
lookup instead of calling System.getProperty() directly, since the former
already exposes system properties unless they are overwritten by configuration
properties.
Allow ConfigInstaller to perform placeholder substitution from framework
properties
---
Key: FELIX-2663
URL: https://issues.apache.org/jira/browse/FELIX-2663
Project: Felix
Issue Type: Improvement
Components: File Install
Affects Versions: fileinstall-3.0.2
Reporter: David Hay
The ConfigInstaller class will perform placeholder substitution using
configuration values defined elsewhere in the .cfg file or using System
properties. Would be nice if it could also use properties defined by the
framework (i.e. BundleContext.getProperty())
The use case is this: As part of the OSGi framework initialization, some
properties are set on the framework that define things such as a home
directory. The various configuration files could then refer to resources
relative to this home directory. For example:
props.setProperty(app.home, homeDir); // homeDir provided by JNDI config,
env variable, etc.
frameworkFactory.newFramework(props);
...
Then, in a configuration file read by the FileInstall bundle, it would be
nice to be able to do:
data.directory=${app.home}/data/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
ApacheCon 2010 NA Felix/OSGi Meetup
Hi all, As the Felix project we're organizing a Felix/OSGi meetup at ApacheCon NA 2010 in a few weeks. If you're going, please sign up for the meetup on this wiki page, so we know approximately how many people to expect: http://wiki.apache.org/apachecon/ApacheMeetupsNa10 Also, if you want to present an OSGi related topic (in about 15 minutes) let us know so we can add you to the agenda here: https://cwiki.apache.org/confluence/display/FELIXWIKI/ApacheCon+2010+NA+Meetup Let's try to make this a fun and interesting event. Hope to see you all in Atlanta! Greetings, Marcel
