Nabble - Apache Felix - Dev

Re: Updated main page

2009-12-04T13:58:09Z

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. Hall<heavy@...>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
>>
>>
>

Re: Updated main page

2009-12-04T13:43:36Z

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 <heavy@...>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

2009-12-04T13:33:36Z

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

2009-12-04T12:47:20Z

[ 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

2009-12-04T12:23:20Z

[ 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

2009-12-04T12:19:21Z

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

2009-12-04T11:35:35Z

Ah, 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

> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@...]
> 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
> <Tim.Moloney@...> 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

2009-12-04T10:57:56Z

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)<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

2009-12-04T10:10:37Z

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) <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] Closed: (FELIX-1920) RequiredBundle.getRequiringBundles() incorrectly calculates result

2009-12-04T09:42:20Z

[ 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] Resolved: (FELIX-1920) RequiredBundle.getRequiringBundles() incorrectly calculates result

2009-12-04T09:42:20Z

[ 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.

--
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

2009-12-04T09:32:20Z

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

2009-12-04T09:28:20Z

[ 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

2009-12-04T09:28:20Z

[ 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.

--
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

2009-12-04T09:13:24Z

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 <Tim.Moloney@...> 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

2009-12-04T08:40:23Z

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

[jira] Commented: (FELIX-1914) Add a development subshell to ease troubleshooting classloading/resolution issues

2009-12-04T07:54:20Z

[ 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}
karaf@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

2009-12-04T07:02:20Z

[ 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}
> karaf@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
> karaf@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)",net.sf.cglib.core;version="
> [2.2.0, 3.0.0)",net.sf.cglib.proxy;version="[2.2.0, 3.0.0)",net.sf.cglib.reflect;version="[2.2.0, 3.0.0)",net.sf.cglib.transform;version="[2.2.0, 3.0.
> 0)",net.sf.cglib.transform.impl;version="[2.2.0, 3.0.0)",net.sf.ehcache;version="[1.2.3, 2.0.0)";resolution:="optional",net.sf.ehcache.util;version="[
> 1.2.3, 2.0.0)";resolution:="optional",net.sf.swarmcache;version="[1.0.0.RC2, 2.0.0)";resolution:="optional",org.apache.commons.collections.map;version
> ="[3.1.0, 4.0.0)",org.apache.tools.ant;version="[1.7.0, 2.0.0)";resolution:="optional",org.apache.tools.ant.taskdefs;version="[1.7.0, 2.0.0)";resoluti
> on:="optional",org.apache.tools.ant.types;version="[1.7.0, 2.0.0)";resolution:="optional",org.dom4j;version="[1.6.1, 2.0.0)",org.dom4j.io;version="[1.
> 6.1, 2.0.0)",org.jboss.cache;version="[1.2.2, 4.0.0)";resolution:="optional",org.jboss.cache.config;version="[1.2.2, 4.0.0)";resolution:="optional",or
> g.jboss.cache.lock;version="[1.2.2, 4.0.0)";resolution:="optional",org.jboss.cache.notifications.annotation;version="[1.2.2, 4.0.0)";resolution:="opti
> onal",org.jboss.cache.notifications.event;version="[1.2.2, 4.0.0)";resolution:="optional",org.jboss.cache.optimistic;version="[1.2.2, 4.0.0)";resoluti
> on:="optional",org.jgroups;version="[2.2.7, 3.0.0)",org.logicalcobwebs.proxool;version="[0.8.3, 1.0.0)";resolution:="optional",org.logicalcobwebs.prox
> ool.configuration;version="[0.8.3, 1.0.0)";resolution:="optional",org.objectweb.asm;version="[1.5.3, 2.0.0)",org.slf4j;version="[1.5.6, 2.0.0)",org.w3
> c.dom;version="0",org.xml.sax;version="0"
> {code}
> Remark : the two bundles can be linked using Equinox 3

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (FELIX-1919) Fragment bundle cannot be linked to its host

2009-12-04T03:48:20Z

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}
karaf@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

karaf@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)",net.sf.cglib.core;version="
[2.2.0, 3.0.0)",net.sf.cglib.proxy;version="[2.2.0, 3.0.0)",net.sf.cglib.reflect;version="[2.2.0, 3.0.0)",net.sf.cglib.transform;version="[2.2.0, 3.0.
0)",net.sf.cglib.transform.impl;version="[2.2.0, 3.0.0)",net.sf.ehcache;version="[1.2.3, 2.0.0)";resolution:="optional",net.sf.ehcache.util;version="[
1.2.3, 2.0.0)";resolution:="optional",net.sf.swarmcache;version="[1.0.0.RC2, 2.0.0)";resolution:="optional",org.apache.commons.collections.map;version
="[3.1.0, 4.0.0)",org.apache.tools.ant;version="[1.7.0, 2.0.0)";resolution:="optional",org.apache.tools.ant.taskdefs;version="[1.7.0, 2.0.0)";resoluti
on:="optional",org.apache.tools.ant.types;version="[1.7.0, 2.0.0)";resolution:="optional",org.dom4j;version="[1.6.1, 2.0.0)",org.dom4j.io;version="[1.
6.1, 2.0.0)",org.jboss.cache;version="[1.2.2, 4.0.0)";resolution:="optional",org.jboss.cache.config;version="[1.2.2, 4.0.0)";resolution:="optional",or
g.jboss.cache.lock;version="[1.2.2, 4.0.0)";resolution:="optional",org.jboss.cache.notifications.annotation;version="[1.2.2, 4.0.0)";resolution:="opti
onal",org.jboss.cache.notifications.event;version="[1.2.2, 4.0.0)";resolution:="optional",org.jboss.cache.optimistic;version="[1.2.2, 4.0.0)";resoluti
on:="optional",org.jgroups;version="[2.2.7, 3.0.0)",org.logicalcobwebs.proxool;version="[0.8.3, 1.0.0)";resolution:="optional",org.logicalcobwebs.prox
ool.configuration;version="[0.8.3, 1.0.0)";resolution:="optional",org.objectweb.asm;version="[1.5.3, 2.0.0)",org.slf4j;version="[1.5.6, 2.0.0)",org.w3
c.dom;version="0",org.xml.sax;version="0"

{code}

Remark : the two bundles can be linked using Equinox 3

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (FELIX-1918) Add property felix.log.level=1 in the etc/config.properties file

2009-12-04T03:36:20Z

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

2009-12-04T01:51:20Z

[ 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

2009-12-04T01:27:20Z

[ 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.

--
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

2009-12-04T01:27:20Z

[ 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.

--
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

2009-12-04T01:27:20Z

[ 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.

--
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

2009-12-04T01:27:20Z

[ 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.

--
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

2009-12-04T01:25:20Z

[ 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.

--
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

2009-12-04T01:23:21Z

[ 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.

--
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

2009-12-04T01:23:21Z

[ 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.

--
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

2009-12-04T01:19:39Z

[ 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.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (FELIX-1917) A few minor bugs in the framework found while embedding Felix

2009-12-03T18:05:20Z

[ https://issues.apache.org/jira/browse/FELIX-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Graham Jenson updated FELIX-1917:
---------------------------------

Attachment: Patch.txt

A patch, to fix.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (FELIX-1917) A few minor bugs in the framework found while embedding Felix

2009-12-03T18:01:20Z

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

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] Resolved: (FELIX-1916) Rename "Location" label to "Bundle Location" in the bundle details display

2009-12-03T15:46:21Z

[ https://issues.apache.org/jira/browse/FELIX-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger resolved FELIX-1916.
--------------------------------------

Resolution: Fixed
Assignee: Felix Meschberger

Done in Rev. 886990.

> Rename "Location" label to "Bundle Location" in the bundle details display
> --------------------------------------------------------------------------
>
> Key: FELIX-1916
> URL: https://issues.apache.org/jira/browse/FELIX-1916
> Project: Felix
> Issue Type: Improvement
> Components: Web Console
> Affects Versions: webconsole-2.0.2
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: webconsole-2.0.4
>
>
> As discussed in FELIX-1758.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FELIX-1758) bundle.location not updated when new version of a bundle is 'jcr'-installed

2009-12-03T15:46:21Z

[ https://issues.apache.org/jira/browse/FELIX-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785644#action_12785644 ]

Felix Meschberger commented on FELIX-1758:
------------------------------------------

As of FELIX-1916 changed the label to "Bundle Location" for clarification.

> bundle.location not updated when new version of a bundle is 'jcr'-installed
> ---------------------------------------------------------------------------
>
> Key: FELIX-1758
> URL: https://issues.apache.org/jira/browse/FELIX-1758
> Project: Felix
> Issue Type: Bug
> Components: Web Console
> Affects Versions: webconsole-1.2.10
> Reporter: Honwai Wong
> Assignee: Felix Meschberger
> Priority: Trivial
>
> The details view of a bundle shows an outdated location if a newer version of the bundle has been deployed using jcrinstall. The version information is correct, merely the location points to an old version of the bundle. This does not occur when deploying the same bundle directly via the web console.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (FELIX-1916) Rename "Location" label to "Bundle Location" in the bundle details display

2009-12-03T15:44:20Z

[ https://issues.apache.org/jira/browse/FELIX-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger updated FELIX-1916:
-------------------------------------

Component/s: Web Console
Affects Version/s: webconsole-2.0.2
Fix Version/s: webconsole-2.0.4

> Rename "Location" label to "Bundle Location" in the bundle details display
> --------------------------------------------------------------------------
>
> Key: FELIX-1916
> URL: https://issues.apache.org/jira/browse/FELIX-1916
> Project: Felix
> Issue Type: Improvement
> Components: Web Console
> Affects Versions: webconsole-2.0.2
> Reporter: Felix Meschberger
> Fix For: webconsole-2.0.4
>
>
> As discussed in FELIX-1758.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (FELIX-1916) Rename "Location" label to "Bundle Location" in the bundle details display

2009-12-03T15:44:20Z

Rename "Location" label to "Bundle Location" in the bundle details display
--------------------------------------------------------------------------

Key: FELIX-1916
URL: https://issues.apache.org/jira/browse/FELIX-1916
Project: Felix
Issue Type: Improvement
Reporter: Felix Meschberger

As discussed in FELIX-1758.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.