[ https://issues.apache.org/jira/browse/FELIX-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch updated FELIX-1712:
------------------------------------
Affects Version/s: (was: dependencymanager.shell-2.0.1)
Fix Version/s: (was: maven-bundle-plugin-2.1.0)
The components in affected/fix versions seem unrelated to this issue, so setting them to unknown.
Can you also provide more details about this issue (and how it relates to the installer component).
> CLONE -Support for port as service properties
> ---------------------------------------------
>
> Key: FELIX-1712
> URL: https://issues.apache.org/jira/browse/FELIX-1712
> Project: Felix
> Issue Type: Improvement
> Components: Installer
> Reporter: andre payne
> Assignee: Sten Roger Sandvik
>
> Support assigned port in Jetty as service property. Both secure and non secure. Use the
same logic as in old Jetty http service 1.0.1.
> * org.apache.felix.http.svcprop.port
> * org.apache.felix.http.svcprop.port.secure
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/FELIX-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786576#action_12786576
]
Stuart McCulloch commented on FELIX-1890:
-----------------------------------------
It must be something specific to this build, or the release settings, since many Apache projects
use the bundleplugin with the release plugin.
Unfortunately I have not had time to investigate in detail.
> The maven-bundle-plugin doesn't work properly if spawned by release:perform
> ---------------------------------------------------------------------------
>
> Key: FELIX-1890
> URL: https://issues.apache.org/jira/browse/FELIX-1890
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Affects Versions: maven-bundle-plugin-2.0.1
> Reporter: Fabrizio Giudici
>
> The bundle-plugin in my project works fine when I run goals such as clean install or
even release:prepare; it fails when I run release:perform.
> For instance, running release:prepare, this is the output produced:
> [Mistral:Projects/jrawio/src] fritz% ll modules/jrawio-all/target/
> total 992
> drwxrwx--- 8 fritz staff 272 Nov 23 21:03 .
> drwxrwx--- 6 fritz staff 204 Nov 23 21:03 ..
> drwxrwx--- 3 fritz staff 102 Nov 23 21:03 classes
> drwxrwx--- 3 fritz staff 102 Nov 23 21:03 dummy-hg-repo
> -rw-rw---- 1 fritz staff 3300 Nov 23 21:03 it.tidalwave.imageio.raw-1.6.2-tests.jar
> -rw-rw---- 1 fritz staff 500450 Nov 23 21:03 it.tidalwave.imageio.raw-1.6.2.jar
> drwxrwx--- 3 fritz staff 102 Nov 23 21:03 maven-archiver
> drwxrwx--- 2 fritz staff 68 Nov 23 21:03 target-maven-repo
> When running release:prepare, the jar file is mostly empty:
> [Mistral:Projects/jrawio/src] fritz% ll target/checkout/modules/jrawio-all/target/
> total 24
> drwxrwx--- 9 fritz staff 306 Nov 23 21:14 .
> drwxrwx--- 5 fritz staff 170 Nov 23 21:14 ..
> drwxrwx--- 3 fritz staff 102 Nov 23 21:14 classes
> drwxrwx--- 3 fritz staff 102 Nov 23 21:14 dummy-hg-repo
> -rw-rw---- 1 fritz staff 316 Nov 23 21:14 it.tidalwave.imageio.raw-1.6.2-sources.jar
> -rw-rw---- 1 fritz staff 3301 Nov 23 21:14 it.tidalwave.imageio.raw-1.6.2-tests.jar
> -rw-rw---- 1 fritz staff 3301 Nov 23 21:14 it.tidalwave.imageio.raw-1.6.2.jar
> drwxrwx--- 3 fritz staff 102 Nov 23 21:14 maven-archiver
> drwxrwx--- 2 fritz staff 68 Nov 23 21:14 target-maven-repo
> The curious thing is that I manually enter the directory target/checkout and run mvn
clean install from there, everything works. So the problem seems related to the maven run
spawned by release:perform
> This is the configuration that I'm using with the bundle-plugin:
> [Mistral:Projects/jrawio/src] fritz% cat modules/jrawio-all/pom.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
> <modelVersion>4.0.0</modelVersion>
> <parent>
> <groupId>it.tidalwave.imageio</groupId>
> <artifactId>jrawio</artifactId>
> <version>1.6.3-SNAPSHOT</version>
> <relativePath>../..</relativePath>
> </parent>
> <artifactId>it.tidalwave.imageio.raw</artifactId>
> <packaging>bundle</packaging>
> <name>jrawio - JAR artifact</name>
> <dependencies>
> <dependency>
> <groupId>it.tidalwave.imageio</groupId>
> <artifactId>codec</artifactId>
> <optional>true</optional>
> </dependency>
> <dependency>
> <groupId>it.tidalwave.imageio</groupId>
> <artifactId>processor</artifactId>
> <optional>true</optional>
> </dependency>
> </dependencies>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <extensions>true</extensions>
> <configuration>
> <instructions>
> <Export-Package>it.tidalwave.imageio.*;-split-package:=merge-first</Export-Package>
> <Bundle-Name>jrawio</Bundle-Name>
> <Bundle-SymbolicName>it.tidalwave.imageio.raw</Bundle-SymbolicName>
> <Bundle-DocURL>http://jrawio.rawdarkroom.org</Bundle-DocURL>
> <Embed-Dependency>processor;codec;inline=true</Embed-Dependency>
> </instructions>
> </configuration>
> </plugin>
> </plugins>
> </build>
> </project>
> This is the configuration of the release plugin:
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-release-plugin</artifactId>
> <configuration>
> <preparationGoals>clean install verify</preparationGoals>
> <goals>clean install javadoc:javadoc assembly:assembly deploy</goals>
> <arguments>-Prelease -DaltDeploymentRepository="${altDeploymentRepository}"</arguments>
> </configuration>
> </plugin>
> My project is open sourced and the problem can be reproduced by:
> hg clone https://kenai.com/hg/jrawio~src
> mvn -o -B release:clean release:prepare release:perform -Prelease
> The pom is configured to perform the release into staged repositories on a local directory,
so it can be run by everyone and won't do any change in public repos.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/FELIX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch updated FELIX-1847:
------------------------------------
Component/s: Maven SCR Plugin
Affects Version/s: scr-1.2.0
> Error with duplicates when using maven-bundle-plugin 2.0.1 and maven-scr-plugin 1.4
> -----------------------------------------------------------------------------------
>
> Key: FELIX-1847
> URL: https://issues.apache.org/jira/browse/FELIX-1847
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin, Maven SCR Plugin
> Affects Versions: scr-1.2.0, maven-bundle-plugin-2.0.1
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_15
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: de_DE, platform encoding: MacRoman
> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
> Reporter: Daniel Bimschas
> Fix For: maven-scr-plugin-1.4.0
>
> Attachments: felix-1847-patch
>
>
> Experiencing the same problem as Patrick Forhahn who commented after https://issues.apache.org/jira/browse/FELIX-1262
was fixed I asked Stuart McCulloch about the bug. Here is his answer about the issue:
> --------------------------
> "The underlying effect is the same (Bnd tool appends ~ to duplicate clauses) but the
cause is different.
> FELIX-1262 was caused by duplicate clauses in the Include-Resource calculated by the
bundleplugin,
> whereas this new issue is caused by duplication of Service-Component clauses by the scrplugin."
>
> "Basically duplicate entries should be removed, which is why directly setting ServiceComponent
works.
> The question is whether the scrplugin or the bundleplugin should detect and remove the
duplicates..."
> --------------------------
> The reason of error is the same as in Patricks comment:
> [ERROR] Error building bundle org.bjc.es:org.bjc.osgi.foundation.cache:bundle:1.13.0.RC1-SNAPSHOT
: Service-Component entry can not be located in JAR: OSGI-INF/serviceComponents.xml~
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/FELIX-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786473#action_12786473
]
Gert Vanthienen commented on FELIX-1914:
----------------------------------------
Added a *{{dev:framework}}* to enable/disable debug logging on the underlying OSGi framework
in http://svn.apache.org/viewvc?view=revision&revision=887538.
* dev:framework -debug enables debug logging
* dev:framework -nodebug disables debug logging
> 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.
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@ungoverned.org>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 >> >> >
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@ungoverned.org>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 >
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
[ 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.
[ 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.
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.
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@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 > <Tim.Moloney@mantech.com> 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 >
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@apache.org>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.
>>
>>
>>
>
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@apache.org>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.
>
>
[ 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.
[ 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.
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.
[ 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.
[ 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.
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@mantech.com> 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
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
[ 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.
[ 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.
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.
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.
[ 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.
[ 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.
[ 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.
[ 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.
[ 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.
[ 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.
[ 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.
[ 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.
[ 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.
[ 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.
> 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.
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.
[ 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.
[ 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.
[ 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.
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.
[ https://issues.apache.org/jira/browse/FELIX-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger reassigned FELIX-1758:
----------------------------------------
Assignee: Felix Meschberger
> 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.