Re: Updated main page
On 12/4/09 16:43, Gerry Woods wrote: The OSGi Bundle Repository summary could use some cleanup: A bundle repository service for easily discovery and deploying bundles... Picky, picky. ;-) I'll fix it...thanks. -> richard On Fri, Dec 4, 2009 at 1:33 PM, Richard S. Hallwrote: I updated the main wiki/web page... We talked about making the subprojects more visible, but we never have the time to do a fancy redesign. Well, I got sick of the current page, so I decided change it to make the subprojects more visible. It ain't fancy, but I think it is an improvement. Notice, I only list released subprojects on the front page...please feel free to edit the summaries. -> richard
Re: Updated main page
The OSGi Bundle Repository summary could use some cleanup: A bundle repository service for easily discovery and deploying bundles... On Fri, Dec 4, 2009 at 1:33 PM, Richard S. Hall wrote: > I updated the main wiki/web page... > > We talked about making the subprojects more visible, but we never have the > time to do a fancy redesign. Well, I got sick of the current page, so I > decided change it to make the subprojects more visible. > > It ain't fancy, but I think it is an improvement. > > Notice, I only list released subprojects on the front page...please feel > free to edit the summaries. > > -> richard >
Updated main page
I updated the main wiki/web page... We talked about making the subprojects more visible, but we never have the time to do a fancy redesign. Well, I got sick of the current page, so I decided change it to make the subprojects more visible. It ain't fancy, but I think it is an improvement. Notice, I only list released subprojects on the front page...please feel free to edit the summaries. -> richard
[jira] Commented: (FELIX-1917) A few minor bugs in the framework found while embedding Felix
[ https://issues.apache.org/jira/browse/FELIX-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786149#action_12786149 ] Richard S. Hall commented on FELIX-1917: Regarding the first bug, I don't think this is an error due to a missing filter, I think it is actually an error due to invalid filter syntax. Requirement.toString() calls getFilter() which calls convertToFilter() if there is no filter. If the resulting filter has invalid syntax, then null is returned. Normally it shouldn't have invalid syntax, but there was a bug in handling classes in the default package which would result in filter "(package=)" which is incorrect. I fixed the default package bug in FELIX-1867, so perhaps that will resolve this issue too. If you are seeing it still with trunk, could you explain how to reproduce? Regarding the second bug, you are correct, it makes sense to check for null. I commit this fix. Thanks. > A few minor bugs in the framework found while embedding Felix > - > > Key: FELIX-1917 > URL: https://issues.apache.org/jira/browse/FELIX-1917 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: felix-2.0.2 > Environment: Not an issue (I dont think) >Reporter: Graham Jenson >Priority: Minor > Attachments: Patch.txt > > Original Estimate: 0.03h > Remaining Estimate: 0.03h > > First Bug > org.apache.felix.framework.util.manifestparser.Requirement.toString() method > can throw null pointer exception if the requirement does not have a filter. > Second Bug > org.apache.felix.framework.ExtensionManager.loadDefaultSystemPackages() > method throws null pointer on variable propURL if there is no > default.properties file. > Fix, check if null before. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1921) Provide a way to configure the host used for karaf ssh server
[ https://issues.apache.org/jira/browse/FELIX-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-1921: --- Attachment: FELIX-1921.patch Patch to be applied, but i'd like to avoid too many snapshot dependencies for now in case we want to release a bug fix release. > Provide a way to configure the host used for karaf ssh server > - > > Key: FELIX-1921 > URL: https://issues.apache.org/jira/browse/FELIX-1921 > Project: Felix > Issue Type: Improvement > Components: Karaf >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Attachments: FELIX-1921.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1921) Provide a way to configure the host used for karaf ssh server
Provide a way to configure the host used for karaf ssh server - Key: FELIX-1921 URL: https://issues.apache.org/jira/browse/FELIX-1921 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: org.apache.felix.karaf.shell.admin 1.2.0 missing in central
Ah, thanks. :) Tim Moloney I brought down the sky for you MRSL but all you did was shrug. 2015 Cattlemen RoadAudience Of One Sarasota, FL 34232 Appeal To Reason (941) 377-6775 x208Rise Against > -Original Message- > From: Guillaume Nodet [mailto:gno...@gmail.com] > Sent: Friday, December 04, 2009 12:13 > To: dev > Subject: Re: org.apache.felix.karaf.shell.admin 1.2.0 missing > in central > > The admin modules have been refactored a bit. > It's now available at > > http://repo1.maven.org/maven2/org/apache/felix/karaf/admin/org > .apache.felix.karaf.admin.command/1.2.0 > > On Fri, Dec 4, 2009 at 17:40, Moloney, Tim M > wrote: > > > > Could someone push org.apache.felix.karaf.shell.admin 1.2.0 to the > > central maven repository > > (http://repo1.maven.org/maven2/org/apache/felix/karaf/shell/)? > > > > All of the other Karaf 1.2.0 bundles are there. > > > > Thanks. > > > > > > Tim Moloney I brought down the > sky for you > > MRSL but all you did was shrug. > > 2015 Cattlemen Road Audience Of One > > Sarasota, FL 34232 Appeal > To Reason > > (941) 377-6775 x208 > Rise Against > > > > > > > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com >
Re: [jira] Resolved: (FELIX-1920) RequiredBundle.getRequiringBundles() incorrectly calculates result
No problem. Thanks for checking the patch! Definitely keep reporting any
issues you uncover.
-> richard
On 12/4/09 13:10, Alan Keane wrote:
Thanks Richard..
Apologies, I should have sent to this mailing list.
I tested with that update locally on the same set of bundles and all looks
fine now.
Alan
On Fri, Dec 4, 2009 at 5:42 PM, Richard S. Hall (JIRA)wrote:
[
https://issues.apache.org/jira/browse/FELIX-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
Richard S. Hall resolved FELIX-1920.
Resolution: Fixed
I committed a fix for this and improved the method a little in the process
too.
RequiredBundle.getRequiringBundles() incorrectly calculates result
--
Key: FELIX-1920
URL: https://issues.apache.org/jira/browse/FELIX-1920
Project: Felix
Issue Type: Bug
Components: Framework, Specification compliance
Affects Versions: felix-2.0.2
Reporter: Richard S. Hall
Assignee: Richard S. Hall
Fix For: felix-2.2.0
Alan Keane noticed:
---
Is the following a bug?
Index: RequiredBundleImpl.java
===
--- RequiredBundleImpl.java (revision 886835)
+++ RequiredBundleImpl.java (working copy)
@@ -74,7 +74,7 @@
IModule[] dependents = ((ModuleImpl)
modules[modIdx]).getDependentRequirers();
for (int depIdx = 0; (dependents != null)&& (depIdx<
dependents.length); depIdx++)
{
-moduleList.add(dependents[modIdx]);
+moduleList.add(dependents[depIdx]);
}
Thanks,
Alan
---
It certainly appears to be a bug and clearly could lead to bad results.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (FELIX-1920) RequiredBundle.getRequiringBundles() incorrectly calculates result
Thanks Richard..
Apologies, I should have sent to this mailing list.
I tested with that update locally on the same set of bundles and all looks
fine now.
Alan
On Fri, Dec 4, 2009 at 5:42 PM, Richard S. Hall (JIRA) wrote:
>
> [
> https://issues.apache.org/jira/browse/FELIX-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Richard S. Hall resolved FELIX-1920.
>
>
>Resolution: Fixed
>
> I committed a fix for this and improved the method a little in the process
> too.
>
> > RequiredBundle.getRequiringBundles() incorrectly calculates result
> > --
> >
> > Key: FELIX-1920
> > URL: https://issues.apache.org/jira/browse/FELIX-1920
> > Project: Felix
> > Issue Type: Bug
> > Components: Framework, Specification compliance
> >Affects Versions: felix-2.0.2
> >Reporter: Richard S. Hall
> >Assignee: Richard S. Hall
> > Fix For: felix-2.2.0
> >
> >
> > Alan Keane noticed:
> > ---
> > Is the following a bug?
> > Index: RequiredBundleImpl.java
> > ===
> > --- RequiredBundleImpl.java (revision 886835)
> > +++ RequiredBundleImpl.java (working copy)
> > @@ -74,7 +74,7 @@
> > IModule[] dependents = ((ModuleImpl)
> > modules[modIdx]).getDependentRequirers();
> > for (int depIdx = 0; (dependents != null) && (depIdx <
> > dependents.length); depIdx++)
> > {
> > -moduleList.add(dependents[modIdx]);
> > +moduleList.add(dependents[depIdx]);
> > }
> > Thanks,
> > Alan
> > ---
> > It certainly appears to be a bug and clearly could lead to bad results.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
[jira] Resolved: (FELIX-1920) RequiredBundle.getRequiringBundles() incorrectly calculates result
[
https://issues.apache.org/jira/browse/FELIX-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall resolved FELIX-1920.
Resolution: Fixed
I committed a fix for this and improved the method a little in the process too.
> RequiredBundle.getRequiringBundles() incorrectly calculates result
> --
>
> Key: FELIX-1920
> URL: https://issues.apache.org/jira/browse/FELIX-1920
> Project: Felix
> Issue Type: Bug
> Components: Framework, Specification compliance
>Affects Versions: felix-2.0.2
>Reporter: Richard S. Hall
>Assignee: Richard S. Hall
> Fix For: felix-2.2.0
>
>
> Alan Keane noticed:
> ---
> Is the following a bug?
> Index: RequiredBundleImpl.java
> ===
> --- RequiredBundleImpl.java (revision 886835)
> +++ RequiredBundleImpl.java (working copy)
> @@ -74,7 +74,7 @@
> IModule[] dependents = ((ModuleImpl)
> modules[modIdx]).getDependentRequirers();
> for (int depIdx = 0; (dependents != null) && (depIdx <
> dependents.length); depIdx++)
> {
> -moduleList.add(dependents[modIdx]);
> +moduleList.add(dependents[depIdx]);
> }
> Thanks,
> Alan
> ---
> It certainly appears to be a bug and clearly could lead to bad results.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1920) RequiredBundle.getRequiringBundles() incorrectly calculates result
[
https://issues.apache.org/jira/browse/FELIX-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall closed FELIX-1920.
--
> RequiredBundle.getRequiringBundles() incorrectly calculates result
> --
>
> Key: FELIX-1920
> URL: https://issues.apache.org/jira/browse/FELIX-1920
> Project: Felix
> Issue Type: Bug
> Components: Framework, Specification compliance
>Affects Versions: felix-2.0.2
>Reporter: Richard S. Hall
>Assignee: Richard S. Hall
> Fix For: felix-2.2.0
>
>
> Alan Keane noticed:
> ---
> Is the following a bug?
> Index: RequiredBundleImpl.java
> ===
> --- RequiredBundleImpl.java (revision 886835)
> +++ RequiredBundleImpl.java (working copy)
> @@ -74,7 +74,7 @@
> IModule[] dependents = ((ModuleImpl)
> modules[modIdx]).getDependentRequirers();
> for (int depIdx = 0; (dependents != null) && (depIdx <
> dependents.length); depIdx++)
> {
> -moduleList.add(dependents[modIdx]);
> +moduleList.add(dependents[depIdx]);
> }
> Thanks,
> Alan
> ---
> It certainly appears to be a bug and clearly could lead to bad results.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1920) RequiredBundle.getRequiringBundles() incorrectly calculates result
RequiredBundle.getRequiringBundles() incorrectly calculates result
--
Key: FELIX-1920
URL: https://issues.apache.org/jira/browse/FELIX-1920
Project: Felix
Issue Type: Bug
Components: Framework, Specification compliance
Affects Versions: felix-2.0.2
Reporter: Richard S. Hall
Assignee: Richard S. Hall
Fix For: felix-2.2.0
Alan Keane noticed:
---
Is the following a bug?
Index: RequiredBundleImpl.java
===
--- RequiredBundleImpl.java (revision 886835)
+++ RequiredBundleImpl.java (working copy)
@@ -74,7 +74,7 @@
IModule[] dependents = ((ModuleImpl)
modules[modIdx]).getDependentRequirers();
for (int depIdx = 0; (dependents != null) && (depIdx <
dependents.length); depIdx++)
{
-moduleList.add(dependents[modIdx]);
+moduleList.add(dependents[depIdx]);
}
Thanks,
Alan
---
It certainly appears to be a bug and clearly could lead to bad results.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1915) [karaf] allow overridding of etc/system.properties via environment
[ https://issues.apache.org/jira/browse/FELIX-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine resolved FELIX-1915. -- Resolution: Fixed > [karaf] allow overridding of etc/system.properties via environment > -- > > Key: FELIX-1915 > URL: https://issues.apache.org/jira/browse/FELIX-1915 > Project: Felix > Issue Type: Task > Components: Karaf >Affects Versions: karaf-1.2.0 >Reporter: Eoghan Glynn >Assignee: Chris Custine >Priority: Minor > Fix For: karaf-1.4.0 > > Attachments: felix_1915.patch > > > The properties specified in etc/system.properties take precedence over those > set via -Dname=value in the JAVA_OPTS. It would be more convenient for > overriding if the opposite precedence ordering was used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1915) [karaf] allow overridding of etc/system.properties via environment
[ https://issues.apache.org/jira/browse/FELIX-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786011#action_12786011 ] Chris Custine commented on FELIX-1915: -- Patch applied, with thanks to Eoghan Glynn. > [karaf] allow overridding of etc/system.properties via environment > -- > > Key: FELIX-1915 > URL: https://issues.apache.org/jira/browse/FELIX-1915 > Project: Felix > Issue Type: Task > Components: Karaf >Affects Versions: karaf-1.2.0 >Reporter: Eoghan Glynn >Assignee: Chris Custine >Priority: Minor > Fix For: karaf-1.4.0 > > Attachments: felix_1915.patch > > > The properties specified in etc/system.properties take precedence over those > set via -Dname=value in the JAVA_OPTS. It would be more convenient for > overriding if the opposite precedence ordering was used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: org.apache.felix.karaf.shell.admin 1.2.0 missing in central
The admin modules have been refactored a bit. It's now available at http://repo1.maven.org/maven2/org/apache/felix/karaf/admin/org.apache.felix.karaf.admin.command/1.2.0 On Fri, Dec 4, 2009 at 17:40, Moloney, Tim M wrote: > > Could someone push org.apache.felix.karaf.shell.admin 1.2.0 to the > central maven repository > (http://repo1.maven.org/maven2/org/apache/felix/karaf/shell/)? > > All of the other Karaf 1.2.0 bundles are there. > > Thanks. > > > Tim Moloney I brought down the sky for you > MRSL but all you did was shrug. > 2015 Cattlemen Road Audience Of One > Sarasota, FL 34232 Appeal To Reason > (941) 377-6775 x208 Rise Against > > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
org.apache.felix.karaf.shell.admin 1.2.0 missing in central
Could someone push org.apache.felix.karaf.shell.admin 1.2.0 to the central maven repository (http://repo1.maven.org/maven2/org/apache/felix/karaf/shell/)? All of the other Karaf 1.2.0 bundles are there. Thanks. Tim Moloney I brought down the sky for you MRSL but all you did was shrug. 2015 Cattlemen RoadAudience Of One Sarasota, FL 34232 Appeal To Reason (941) 377-6775 x208Rise Against
[jira] Commented: (FELIX-1914) Add a development subshell to ease troubleshooting classloading/resolution issues
[
https://issues.apache.org/jira/browse/FELIX-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785971#action_12785971
]
Gert Vanthienen commented on FELIX-1914:
Added a *{{dev:show-tree}}* in
http://svn.apache.org/viewvc?view=revision&revision=887233
This can be used to represent bundle dependencies 'graphically' and it will
also warn users if multiple bundles in the dependency graph are exporting the
same packages.
{noformat}
ka...@root> dev:show-tree 36
Bundle wip.foobar [36] is currently INSTALLED
- using wip.bar2 [34] to resolve import org.wip.bar;version="2.0.0"
- using wip.foo [35] to resolve import org.wip.foo
wip.foobar [36]
+- wip.bar2 [34]
+- wip.foo [35]
+- wip.bar1 [33]
WARNING: multiple bundles are exporting package org.wip.bar
- wip.bar1 [33]
- wip.bar2 [34]
{noformat}
> Add a development subshell to ease troubleshooting classloading/resolution
> issues
> -
>
> Key: FELIX-1914
> URL: https://issues.apache.org/jira/browse/FELIX-1914
> Project: Felix
> Issue Type: Improvement
> Components: Karaf
>Affects Versions: karaf-1.2.0
>Reporter: Gert Vanthienen
>Assignee: Gert Vanthienen
> Fix For: karaf-1.4.0
>
>
> At development time, people sometimes bump into classloading or bundle
> resolution issues. Proposing to add a subshell with a few development tools
> that can be used to troubleshoot these issues:
> - To solve the "unable to resolve due to constraint violation", we could
> build a tool that discovers multiple bundles exporting the same package that
> are needed to resolve the given bundle to give people a clue which
> uses-constraints might be involved
> - To solve a CNFE, we could build a tool that takes a snapshot of imports,
> enabled dynamic imports and refreshes the bundle and then checks the imported
> packages again to see which imports were added by the dynamic import
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1919) Fragment bundle cannot be linked to its host
[
https://issues.apache.org/jira/browse/FELIX-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785955#action_12785955
]
Richard S. Hall commented on FELIX-1919:
We are not very lenient when it comes to conflict detection, we check for exact
matches, which is acceptable for the spec. In this case, the version ranges are
not exact matches. We could possibly try to special case version attributes and
calculate the intersection of the host import and the fragment import and use
that instead...
> Fragment bundle cannot be linked to its host
>
>
> Key: FELIX-1919
> URL: https://issues.apache.org/jira/browse/FELIX-1919
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: felix-2.0.1
>Reporter: Charles Moulliard
>Priority: Critical
>
> The following fragment bundle cannot be link to its host
> osgi:install -s mvn:org.hibernate/com.springsource.org.hibernate.ejb/3.4.0.GA
> // FRAGMENT BUNDLE
> osgi:install -s mvn:org.hibernate/com.springsource.org.hibernate/3.3.2.GA //
> HOST
> Here is what the trace report
> {code}
> DEBUG: Excluding fragment com.springsource.org.hibernate.ejb from
> com.springsource.org.hibernate due to conflict with imported package
> javassist.bytec
> ode from com.springsource.org.hibernate
> DEBUG: Excluding fragment com.springsource.org.hibernate.annotations from
> com.springsource.org.hibernate due to conflict with imported package org.slf
> 4j from com.springsource.org.hibernate
> {code}
> but the import declaration for javassist.bytecode / slf4j are correct
> {code}
> ka...@root> headers 86
> JBoss Hibernate Entity Manager (86)
> ---
> Ant-Version = Apache Ant 1.7.1
> Bundle-Classpath = .
> Bundle-ManifestVersion = 2
> Bundle-Name = JBoss Hibernate Entity Manager
> Bundle-SymbolicName = com.springsource.org.hibernate.ejb
> Bundle-Vendor = SpringSource
> Bundle-Version = 3.4.0.GA
> Created-By = 1.5.0_06-b05 (Sun Microsystems Inc.)
> Export-Package =
> org.hibernate.ejb;version="3.4.0.GA";uses:="javax.naming,javax.persistence,javax.persistence.spi,javax.sql,org.hibernate,org.hibernat
> e.cfg,org.hibernate.connection,org.hibernate.ejb.packaging,org.hibernate.engine,org.hibernate.event,org.hibernate.mapping,org.slf4j,org.xml.sax",org.h
> ibernate.ejb.connection;version="3.4.0.GA";uses:="javax.sql,org.hibernate",org.hibernate.ejb.event;version="3.4.0.GA";uses:="org.hibernate.annotations
> .common.reflection,org.hibernate.engine,org.hibernate.event,org.hibernate.persister.entity",org.hibernate.ejb.instrument;version="3.4.0.GA",org.hibern
> ate.ejb.packaging;version="3.4.0.GA";uses:="javax.persistence.spi,org.slf4j,org.w3c.dom,org.xml.sax",org.hibernate.ejb.transaction;version="3.4.0.GA";
> uses:="org.hibernate,org.hibernate.jdbc,org.hibernate.transaction",org.hibernate.ejb.util;version="3.4.0.GA";uses:="javax.naming.event,javax.persisten
> ce,javax.persistence.spi,org.hibernate,org.hibernate.ejb,org.slf4j",org.hibernate.engine;version="3.4.0.GA";uses:="org.hibernate,org.hibernate.event,o
> rg.hibernate.type,org.slf4j"
> Fragment-Host = com.springsource.org.hibernate;bundle-version="[3.3.1.GA,
> 3.4.0)"
> Implementation-Title = Hibernate EntityManager
> Implementation-URL = http://entitymanager.hibernate.org
> Implementation-Vendor = hibernate.org
> Implementation-Vendor-Id = hibernate.org
> Implementation-Version = 3.4.0.GA
> Import-Package = javassist.bytecode;version="[3.3.0.ga,
> 4.0.0)",javassist.bytecode.annotation;version="[3.3.0.ga,
> 4.0.0)",javax.naming,javax.naming.ev
> ent,javax.naming.spi,javax.persistence;version="[1.0.0,
> 2.0.0)",javax.persistence.spi;version="[1.0.0,
> 2.0.0)",javax.sql,javax.transaction;version="[1
> .0.1,
> 2.0.0)";resolution:=optional,javax.xml.parsers,org.dom4j;version="[1.6.1,
> 2.0.0)",org.dom4j.io;version="[1.6.1, 2.0.0)",org.hibernate.annotation
> s.common;version="[3.3.0.ga,
> 3.4.0)",org.hibernate.annotations.common.reflection;version="[3.3.0.ga,
> 3.4.0)",org.hibernate.annotations.common.util;ver
> sion="[3.3.0.ga, 3.4.0)",org.slf4j;version="[1.5.3,
> 1.6.0)",org.w3c.dom,org.xml.sax
> Manifest-Version = 1.0
> Specification-Title = Java Persistence
> Specification-Vendor = jcp.org
> Specification-Version = 1.0
> ka...@root> headers 89
> JBoss Hibernate Object-Relational Mapper (89)
> -
> Archiver-Version = Plexus Archiver
> Bundle-ManifestVersion = 2
> Bundle-Name = JBoss Hibernate Object-Relational Mapper
> Bundle-SymbolicName = com.springsource.org.hibernate
> Bundle-Vendor = SpringSource
> Bundle-Version = 3.3.2.GA
> Created-By = 1.5.0_18-b02 (Sun Microsystems Inc.)
> Import-Package = antlr;version="[2.7.6,
> 3.0.0)",antlr.collections;version="[2.7.6,
> 3.0.0)",antlr.collections.impl;version="[2.7.6, 3
[jira] Created: (FELIX-1919) Fragment bundle cannot be linked to its host
Fragment bundle cannot be linked to its host
Key: FELIX-1919
URL: https://issues.apache.org/jira/browse/FELIX-1919
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: felix-2.0.1
Reporter: Charles Moulliard
Priority: Critical
The following fragment bundle cannot be link to its host
osgi:install -s mvn:org.hibernate/com.springsource.org.hibernate.ejb/3.4.0.GA
// FRAGMENT BUNDLE
osgi:install -s mvn:org.hibernate/com.springsource.org.hibernate/3.3.2.GA //
HOST
Here is what the trace report
{code}
DEBUG: Excluding fragment com.springsource.org.hibernate.ejb from
com.springsource.org.hibernate due to conflict with imported package
javassist.bytec
ode from com.springsource.org.hibernate
DEBUG: Excluding fragment com.springsource.org.hibernate.annotations from
com.springsource.org.hibernate due to conflict with imported package org.slf
4j from com.springsource.org.hibernate
{code}
but the import declaration for javassist.bytecode / slf4j are correct
{code}
ka...@root> headers 86
JBoss Hibernate Entity Manager (86)
---
Ant-Version = Apache Ant 1.7.1
Bundle-Classpath = .
Bundle-ManifestVersion = 2
Bundle-Name = JBoss Hibernate Entity Manager
Bundle-SymbolicName = com.springsource.org.hibernate.ejb
Bundle-Vendor = SpringSource
Bundle-Version = 3.4.0.GA
Created-By = 1.5.0_06-b05 (Sun Microsystems Inc.)
Export-Package =
org.hibernate.ejb;version="3.4.0.GA";uses:="javax.naming,javax.persistence,javax.persistence.spi,javax.sql,org.hibernate,org.hibernat
e.cfg,org.hibernate.connection,org.hibernate.ejb.packaging,org.hibernate.engine,org.hibernate.event,org.hibernate.mapping,org.slf4j,org.xml.sax",org.h
ibernate.ejb.connection;version="3.4.0.GA";uses:="javax.sql,org.hibernate",org.hibernate.ejb.event;version="3.4.0.GA";uses:="org.hibernate.annotations
.common.reflection,org.hibernate.engine,org.hibernate.event,org.hibernate.persister.entity",org.hibernate.ejb.instrument;version="3.4.0.GA",org.hibern
ate.ejb.packaging;version="3.4.0.GA";uses:="javax.persistence.spi,org.slf4j,org.w3c.dom,org.xml.sax",org.hibernate.ejb.transaction;version="3.4.0.GA";
uses:="org.hibernate,org.hibernate.jdbc,org.hibernate.transaction",org.hibernate.ejb.util;version="3.4.0.GA";uses:="javax.naming.event,javax.persisten
ce,javax.persistence.spi,org.hibernate,org.hibernate.ejb,org.slf4j",org.hibernate.engine;version="3.4.0.GA";uses:="org.hibernate,org.hibernate.event,o
rg.hibernate.type,org.slf4j"
Fragment-Host = com.springsource.org.hibernate;bundle-version="[3.3.1.GA,
3.4.0)"
Implementation-Title = Hibernate EntityManager
Implementation-URL = http://entitymanager.hibernate.org
Implementation-Vendor = hibernate.org
Implementation-Vendor-Id = hibernate.org
Implementation-Version = 3.4.0.GA
Import-Package = javassist.bytecode;version="[3.3.0.ga,
4.0.0)",javassist.bytecode.annotation;version="[3.3.0.ga,
4.0.0)",javax.naming,javax.naming.ev
ent,javax.naming.spi,javax.persistence;version="[1.0.0,
2.0.0)",javax.persistence.spi;version="[1.0.0,
2.0.0)",javax.sql,javax.transaction;version="[1
.0.1, 2.0.0)";resolution:=optional,javax.xml.parsers,org.dom4j;version="[1.6.1,
2.0.0)",org.dom4j.io;version="[1.6.1, 2.0.0)",org.hibernate.annotation
s.common;version="[3.3.0.ga,
3.4.0)",org.hibernate.annotations.common.reflection;version="[3.3.0.ga,
3.4.0)",org.hibernate.annotations.common.util;ver
sion="[3.3.0.ga, 3.4.0)",org.slf4j;version="[1.5.3,
1.6.0)",org.w3c.dom,org.xml.sax
Manifest-Version = 1.0
Specification-Title = Java Persistence
Specification-Vendor = jcp.org
Specification-Version = 1.0
ka...@root> headers 89
JBoss Hibernate Object-Relational Mapper (89)
-
Archiver-Version = Plexus Archiver
Bundle-ManifestVersion = 2
Bundle-Name = JBoss Hibernate Object-Relational Mapper
Bundle-SymbolicName = com.springsource.org.hibernate
Bundle-Vendor = SpringSource
Bundle-Version = 3.3.2.GA
Created-By = 1.5.0_18-b02 (Sun Microsystems Inc.)
Import-Package = antlr;version="[2.7.6,
3.0.0)",antlr.collections;version="[2.7.6,
3.0.0)",antlr.collections.impl;version="[2.7.6, 3.0.0)",com.mchange
.v2.c3p0;version="[0.9.1,
1.0.0)";resolution:="optional",com.opensymphony.oscache.base;version="[2.1.0,
3.0.0)";resolution:="optional",com.opensymphon
y.oscache.general;version="[2.1.0,
3.0.0)";resolution:="optional",javassist;version="[3.9.0.GA,
4.0.0)",javassist.bytecode;version="[3.9.0.GA, 4.0.0)"
,javassist.util.proxy;version="[3.9.0.GA,
4.0.0)",javax.naming;version="0",javax.naming.event;version="0",javax.naming.spi;version="0",javax.security.
auth;version="0",javax.security.jacc;version="0";resolution:="optional",javax.sql;version="0",javax.transaction;version="[1.0.1,
2.0.0)";resolution:="
optional",javax.transaction.xa;version="[1.0.1,
2.0.0)";resolution:="optional",net.sf.cglib.beans;version="[2.2.0,
3.0.0
[jira] Created: (FELIX-1918) Add property felix.log.level=1 in the etc/config.properties file
Add property felix.log.level=1 in the etc/config.properties file
Key: FELIX-1918
URL: https://issues.apache.org/jira/browse/FELIX-1918
Project: Felix
Issue Type: Improvement
Reporter: Charles Moulliard
Fix For: karaf-1.4.0
Add property felix.log.level=1 in the etc/config.properties file
felix.log.level - An integer value indicating the degree of logging reported by
the framework; the higher the value the more logging is reported. If zero ('0')
is specified, then logging is turned off completely. The log levels match those
specified in the OSGi Log Service (i.e., 1 = error, 2 = warning, 3 =
information, and 4 = debug). The default value is 1.
This can help users/administrators to find error like why a fragment bundle
cannot be linked to its host
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1913) All synchronous events are processed in one queue
[ https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785843#action_12785843 ] Carsten Ziegeler commented on FELIX-1913: - As Karl statet the current implementation is according to the spec - however, it is very slow in delivering synchronous events as they are put in in a single queue. Apart from performance, there is no problem with this - but in some cases performance matters, at least a little bit. If you're using the event admin for notifications, especially to give a user a feedback or something like that, it matters if the event takes 2 minutes to be delivered or 100ms. - And yes, these are realistic figures. The spec allows to dispatch events coming from different threads in parallel. So in your example, if the events come from different threads, there is no particular order mandated from the spec and therefore can safely be processed in parallel. > All synchronous events are processed in one queue > - > > Key: FELIX-1913 > URL: https://issues.apache.org/jira/browse/FELIX-1913 > Project: Felix > Issue Type: Improvement > Components: Event Admin >Affects Versions: eventadmin 1.0.0 >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Minor > Attachments: ea.patch > > > The current event admin implementation puts all events into one single queue > and processes this queue is in one thread. This creates a bottleneck when > different threads send events as they have to wait for other threads to be > processed first. Events from different threads can be processed in parallel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-1913) All synchronous events are processed in one queue
[ https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785833#action_12785833 ] Sven Ludwig edited comment on FELIX-1913 at 12/4/09 9:25 AM: - Hello, I find this an interesting thread and want to contribute with a question. First, what I have understood is that for one event-sending thread the events will be processed in serial (in the ordering that is applicable due to the spec). However, if two or more events are sent by two different threads, the two event series are processed concurrently. I am wondering if and why the assumption that events sent by different threads may be processed concurrently holds. This is just a question out of interest, and maybe it helps to clarify the situation even more. I am considering a situation in which the event sender (wherever the events come from) may be a multi-threaded implementation and thus the same end-point-sender may not send its events via the same thread - maybe such a situation s possible and thus may be a problem for the patch. was (Author: sludwig): Hello, I find this an interesting thread and want to contribute with a question. First, what I have understood is that for one event-sending thread the events will be processed in serial. However, if two events are sent by two different threads, the events are processed concurrently. I am wondering if and why the assumption that events sent by different threads may be processed concurrently holds. This is just a question out of interest, and maybe it helps to clarify the situation even more. I am considering a situation in which the event sender (wherever the events come from) may be a multi-threaded implementation and thus the same end-point-sender may not send its events via the same thread - maybe such a situation s possible and thus may be a problem for the patch. > All synchronous events are processed in one queue > - > > Key: FELIX-1913 > URL: https://issues.apache.org/jira/browse/FELIX-1913 > Project: Felix > Issue Type: Improvement > Components: Event Admin >Affects Versions: eventadmin 1.0.0 >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Minor > Attachments: ea.patch > > > The current event admin implementation puts all events into one single queue > and processes this queue is in one thread. This creates a bottleneck when > different threads send events as they have to wait for other threads to be > processed first. Events from different threads can be processed in parallel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-1913) All synchronous events are processed in one queue
[ https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785833#action_12785833 ] Sven Ludwig edited comment on FELIX-1913 at 12/4/09 9:26 AM: - Hello, I find this an interesting thread and want to contribute with a question. First, what I have understood is that for one event-sending thread the events will be processed in serial (in the ordering that is applicable due to the spec). However, if two or more events are sent by two different threads, the two event series are processed in parallel. I am wondering if and why the assumption that events sent by different threads may be processed concurrently holds. This is just a question out of interest, and maybe it helps to clarify the situation even more. I am considering a situation in which the event sender (wherever the events come from) may be a multi-threaded implementation in which the same end-point-sender may not send its events via the same thread - maybe such a situation s possible and thus may be a problem for the patch. was (Author: sludwig): Hello, I find this an interesting thread and want to contribute with a question. First, what I have understood is that for one event-sending thread the events will be processed in serial (in the ordering that is applicable due to the spec). However, if two or more events are sent by two different threads, the two event series are processed in parallel. I am wondering if and why the assumption that events sent by different threads may be processed concurrently holds. This is just a question out of interest, and maybe it helps to clarify the situation even more. I am considering a situation in which the event sender (wherever the events come from) may be a multi-threaded implementation and thus the same end-point-sender may not send its events via the same thread - maybe such a situation s possible and thus may be a problem for the patch. > All synchronous events are processed in one queue > - > > Key: FELIX-1913 > URL: https://issues.apache.org/jira/browse/FELIX-1913 > Project: Felix > Issue Type: Improvement > Components: Event Admin >Affects Versions: eventadmin 1.0.0 >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Minor > Attachments: ea.patch > > > The current event admin implementation puts all events into one single queue > and processes this queue is in one thread. This creates a bottleneck when > different threads send events as they have to wait for other threads to be > processed first. Events from different threads can be processed in parallel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-1913) All synchronous events are processed in one queue
[ https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785833#action_12785833 ] Sven Ludwig edited comment on FELIX-1913 at 12/4/09 9:26 AM: - Hello, I find this an interesting thread and want to contribute with a question. First, what I have understood is that for one event-sending thread the events will be processed in serial (in the ordering that is applicable due to the spec). However, if two or more events are sent by two different threads, the two event series are processed in parallel. I am wondering if and why the assumption that events sent by different threads may be processed concurrently holds. This is just a question out of interest, and maybe it helps to clarify the situation even more. I am considering a situation in which the event sender (wherever the events come from) may be a multi-threaded implementation in which the same end-point-sender may not send its events via the same thread - maybe such a situation is possible and thus may be a problem for the patch. was (Author: sludwig): Hello, I find this an interesting thread and want to contribute with a question. First, what I have understood is that for one event-sending thread the events will be processed in serial (in the ordering that is applicable due to the spec). However, if two or more events are sent by two different threads, the two event series are processed in parallel. I am wondering if and why the assumption that events sent by different threads may be processed concurrently holds. This is just a question out of interest, and maybe it helps to clarify the situation even more. I am considering a situation in which the event sender (wherever the events come from) may be a multi-threaded implementation in which the same end-point-sender may not send its events via the same thread - maybe such a situation s possible and thus may be a problem for the patch. > All synchronous events are processed in one queue > - > > Key: FELIX-1913 > URL: https://issues.apache.org/jira/browse/FELIX-1913 > Project: Felix > Issue Type: Improvement > Components: Event Admin >Affects Versions: eventadmin 1.0.0 >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Minor > Attachments: ea.patch > > > The current event admin implementation puts all events into one single queue > and processes this queue is in one thread. This creates a bottleneck when > different threads send events as they have to wait for other threads to be > processed first. Events from different threads can be processed in parallel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-1913) All synchronous events are processed in one queue
[ https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785833#action_12785833 ] Sven Ludwig edited comment on FELIX-1913 at 12/4/09 9:25 AM: - Hello, I find this an interesting thread and want to contribute with a question. First, what I have understood is that for one event-sending thread the events will be processed in serial (in the ordering that is applicable due to the spec). However, if two or more events are sent by two different threads, the two event series are processed in parallel. I am wondering if and why the assumption that events sent by different threads may be processed concurrently holds. This is just a question out of interest, and maybe it helps to clarify the situation even more. I am considering a situation in which the event sender (wherever the events come from) may be a multi-threaded implementation and thus the same end-point-sender may not send its events via the same thread - maybe such a situation s possible and thus may be a problem for the patch. was (Author: sludwig): Hello, I find this an interesting thread and want to contribute with a question. First, what I have understood is that for one event-sending thread the events will be processed in serial (in the ordering that is applicable due to the spec). However, if two or more events are sent by two different threads, the two event series are processed concurrently. I am wondering if and why the assumption that events sent by different threads may be processed concurrently holds. This is just a question out of interest, and maybe it helps to clarify the situation even more. I am considering a situation in which the event sender (wherever the events come from) may be a multi-threaded implementation and thus the same end-point-sender may not send its events via the same thread - maybe such a situation s possible and thus may be a problem for the patch. > All synchronous events are processed in one queue > - > > Key: FELIX-1913 > URL: https://issues.apache.org/jira/browse/FELIX-1913 > Project: Felix > Issue Type: Improvement > Components: Event Admin >Affects Versions: eventadmin 1.0.0 >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Minor > Attachments: ea.patch > > > The current event admin implementation puts all events into one single queue > and processes this queue is in one thread. This creates a bottleneck when > different threads send events as they have to wait for other threads to be > processed first. Events from different threads can be processed in parallel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-1913) All synchronous events are processed in one queue
[ https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785833#action_12785833 ] Sven Ludwig edited comment on FELIX-1913 at 12/4/09 9:24 AM: - Hello, I find this an interesting thread and want to contribute with a question. First, what I have understood is that for one event-sending thread the events will be processed in serial. However, if two events are sent by two different threads, the events are processed concurrently. I am wondering if and why the assumption that events sent by different threads may be processed concurrently holds. This is just a question out of interest, and maybe it helps to clarify the situation even more. I am considering a situation in which the event sender (wherever the events come from) may be a multi-threaded implementation and thus the same end-point-sender may not send its events via the same thread - maybe such a situation s possible and thus may be a problem for the patch. was (Author: sludwig): Hello, I find this an interesting thread and want to contribute with a question. First, what I have understood is that for one event-sending thread the events will be processed in serial. However, if two events are sent by two different threads, the events are processed concurrently. I am wondering if and why the assumption that events sent by different threads may be processed concurrently holds. This is just a question out of interest, and maybe it helps to clarify the situation even more. I am considering a situation in which the event sender (wherever the events come from) may be a multi-threaded implementation and thus the same end-point-sender may not send its events via the same thread - maybe such a situation exists and thus may be a problem here for the patch. > All synchronous events are processed in one queue > - > > Key: FELIX-1913 > URL: https://issues.apache.org/jira/browse/FELIX-1913 > Project: Felix > Issue Type: Improvement > Components: Event Admin >Affects Versions: eventadmin 1.0.0 >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Minor > Attachments: ea.patch > > > The current event admin implementation puts all events into one single queue > and processes this queue is in one thread. This creates a bottleneck when > different threads send events as they have to wait for other threads to be > processed first. Events from different threads can be processed in parallel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-1913) All synchronous events are processed in one queue
[ https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785833#action_12785833 ] Sven Ludwig edited comment on FELIX-1913 at 12/4/09 9:22 AM: - Hello, I find this an interesting thread and want to contribute with a question. First, what I have understood is that for one event-sending thread the events will be processed in serial. However, if two events are sent by two different threads, the events are processed concurrently. I am wondering if and why the assumption that events sent by different threads may be processed concurrently holds. This is just a question out of interest, and maybe it helps to clarify the situation even more. I am considering a situation in which the event sender (wherever the events come from) may be concurrent implementations and thus the same end-point-sender may not send its events via the same thread - maybe such a situation exists and thus may be a problem here for the patch. was (Author: sludwig): Hello, I find this an interesting thread and want to contribute with a question. First, what I have understood is that for one event-sending thread the events will be processed in serial. However, if two events are sent by two different threads, the events are processed concurrently. I am wondering why the assumption that events sent by different threads may be processed concurrently. This is just a question out of interest, and maybe it helps to clarify the situation even more. I am considering a situation in which the event sender (wherever the events come from) may be concurrent implementations and thus the same end-point-sender may not send its events via the same thread - maybe such a situation exists and thus may be a problem here for the patch. > All synchronous events are processed in one queue > - > > Key: FELIX-1913 > URL: https://issues.apache.org/jira/browse/FELIX-1913 > Project: Felix > Issue Type: Improvement > Components: Event Admin >Affects Versions: eventadmin 1.0.0 >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Minor > Attachments: ea.patch > > > The current event admin implementation puts all events into one single queue > and processes this queue is in one thread. This creates a bottleneck when > different threads send events as they have to wait for other threads to be > processed first. Events from different threads can be processed in parallel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-1913) All synchronous events are processed in one queue
[ https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785833#action_12785833 ] Sven Ludwig edited comment on FELIX-1913 at 12/4/09 9:22 AM: - Hello, I find this an interesting thread and want to contribute with a question. First, what I have understood is that for one event-sending thread the events will be processed in serial. However, if two events are sent by two different threads, the events are processed concurrently. I am wondering if and why the assumption that events sent by different threads may be processed concurrently holds. This is just a question out of interest, and maybe it helps to clarify the situation even more. I am considering a situation in which the event sender (wherever the events come from) may be a multi-threaded implementation and thus the same end-point-sender may not send its events via the same thread - maybe such a situation exists and thus may be a problem here for the patch. was (Author: sludwig): Hello, I find this an interesting thread and want to contribute with a question. First, what I have understood is that for one event-sending thread the events will be processed in serial. However, if two events are sent by two different threads, the events are processed concurrently. I am wondering if and why the assumption that events sent by different threads may be processed concurrently holds. This is just a question out of interest, and maybe it helps to clarify the situation even more. I am considering a situation in which the event sender (wherever the events come from) may be concurrent implementations and thus the same end-point-sender may not send its events via the same thread - maybe such a situation exists and thus may be a problem here for the patch. > All synchronous events are processed in one queue > - > > Key: FELIX-1913 > URL: https://issues.apache.org/jira/browse/FELIX-1913 > Project: Felix > Issue Type: Improvement > Components: Event Admin >Affects Versions: eventadmin 1.0.0 >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Minor > Attachments: ea.patch > > > The current event admin implementation puts all events into one single queue > and processes this queue is in one thread. This creates a bottleneck when > different threads send events as they have to wait for other threads to be > processed first. Events from different threads can be processed in parallel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1913) All synchronous events are processed in one queue
[ https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785833#action_12785833 ] Sven Ludwig commented on FELIX-1913: Hello, I find this an interesting thread and want to contribute with a question. First, what I have understood is that for one event-sending thread the events will be processed in serial. However, if two events are sent by two different threads, the events are processed concurrently. I am wondering why the assumption that events sent by different threads may be processed concurrently. This is just a question out of interest, and maybe it helps to clarify the situation even more. I am considering a situation in which the event sender (wherever the events come from) may be concurrent implementations and thus the same end-point-sender may not send its events via the same thread - maybe such a situation exists and thus may be a problem here for the patch. > All synchronous events are processed in one queue > - > > Key: FELIX-1913 > URL: https://issues.apache.org/jira/browse/FELIX-1913 > Project: Felix > Issue Type: Improvement > Components: Event Admin >Affects Versions: eventadmin 1.0.0 >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Minor > Attachments: ea.patch > > > The current event admin implementation puts all events into one single queue > and processes this queue is in one thread. This creates a bottleneck when > different threads send events as they have to wait for other threads to be > processed first. Events from different threads can be processed in parallel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
