tag:old.nabble.com,2006:forum-28134Nabble - Apache Felix2009-12-23T13:48:29Z<a href="http://felix.apache.org" target="_top" rel="nofollow">Felix</a> is a community effort to implement the <a href="http://www2.osgi.org/Specifications/HomePage" target="_top" rel="nofollow">OSGi R4 Service Platform</a>, which includes the OSGi framework and standard services, as well as providing and supporting other interesting OSGi-related technologies. The ultimate goal is to provide a completely compliant implementation of the OSGi framework and standard services and to support a community around this technology. Felix currently implements a large portion of the OSGi release 4 specification, but additional work is necessary for full compliance. Despite this fact, the OSGi framework functionality provided by Felix is very stable.tag:old.nabble.com,2006:post-26907872[jira] Commented: (FELIX-1913) All events are processed in a queue2009-12-23T13:48:29Z2009-12-23T13:48:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794231#action_12794231" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794231#action_12794231</a> ]
<br><br>Karl Pauls commented on FELIX-1913:
<br>-----------------------------------
<br><br>ah ok. yeah, that would be cool.
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, ea2.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26907885Felix/Grizzly/Jersey2009-12-23T13:45:45Z2009-12-23T13:45:45ZDavid Tkaczyk-2Hi,
<br><br>
<br><br>I'm really struggling (going on 2 or 3 days now) to get Felix to work with a
<br>Grizzly http service deploying a Jersey servlet. I've googled like crazy to
<br>try and resolve on my own, but no luck. I'm hoping that I'm overlooking
<br>something simple that someone can point out to me. Everything is
<br>ACTIVE/RESOLVED from an osgi perspective. My problem appears to be that
<br>Jersey cannot locate my resource file. Along with Jersey's inability to
<br>find my resource class there's also a stack trace
<br>(ServiceConfigurationError) that I'll post below.
<br><br>
<br><br>Thanks,
<br><br>Dave
<br><br>
<br><br>package camiant.osgi.msr.rest;
<br><br>
<br><br>import java.util.Dictionary;
<br><br>import java.util.Hashtable;
<br><br>
<br><br>import org.osgi.framework.ServiceReference;
<br><br>import org.osgi.service.http.HttpService;
<br><br>import org.osgi.util.tracker.ServiceTrackerCustomizer;
<br><br>import org.slf4j.Logger;
<br><br>import org.slf4j.LoggerFactory;
<br><br>
<br><br>import com.sun.jersey.server.impl.container.servlet.ServletAdaptor;
<br><br>
<br><br>public class HttpServiceServiceTrackerCustomizer implements
<br>ServiceTrackerCustomizer {
<br><br>
<br><br> private static final Logger LOGGER =
<br>LoggerFactory.getLogger(HttpServiceServiceTrackerCustomizer.class);
<br><br>
<br><br> private static final Dictionary<String, String> JERSEY_INIT_PARAMS = new
<br>Hashtable<String, String>();
<br><br>
<br><br> static {
<br><br> // NOTE: I've tried several different ways to get Jersey to find my
<br>resource file, but no luck. package config/resource config/custom
<br>Application
<br><br> // Just about every different way that Jersey allows, I've
<br>tried
<br><br> JERSEY_INIT_PARAMS.put("com.sun.jersey.config.property.packages",
<br>"camiant.osgi.msr.rest.resource");
<br><br> }
<br><br>
<br><br> @Override
<br><br> public Object addingService(ServiceReference serviceRef) {
<br><br> LOGGER.info("Adding service: " +
<br>serviceRef.getBundle().getSymbolicName());
<br><br>
<br><br> HttpService grizzlyService =
<br>(HttpService)serviceRef.getBundle().getBundleContext().getService(serviceRef
<br>);
<br><br> try {
<br><br> // NOTE: as you see I've tried both ServletContainer and
<br>ServletAdaptor - both produce similar results
<br><br> //grizzlyService.registerServlet("/rs", new ServletContainer(),
<br>JERSEY_INIT_PARAMS, null);
<br><br> grizzlyService.registerServlet("/rs", new ServletAdaptor(),
<br>JERSEY_INIT_PARAMS, null);
<br><br> } catch (Exception e) {
<br><br> e.printStackTrace(); //TODO what is best here..
<br><br> grizzlyService = null;
<br><br> }
<br><br>
<br><br> return grizzlyService;
<br><br> }
<br><br>
<br><br>}
<br><br>
<br><br>package camiant.osgi.msr.rest.resource;
<br><br>
<br><br>import javax.ws.rs.GET;
<br><br>import javax.ws.rs.Path;
<br><br>import javax.ws.rs.Produces;
<br><br>import javax.ws.rs.core.Response;
<br><br>
<br><br>@Path("/msr")
<br><br>public class TestResource {
<br><br>
<br><br> @GET
<br><br> @Path("/keytypes")
<br><br> @Produces("text/xml")
<br><br> public Response getKeyTypes() {
<br><br> return Response.ok().entity("this is a cheap key type!!!!!!!!!").build();
<br><br><br> }
<br><br>
<br><br>}
<br><br>
<br><br>Welcome to Felix
<br><br>================
<br><br>
<br><br>2009-12-23 16:30:47,872-0500 INFO RestMSRCoreServiceTrackerCustomizer:16 -
<br>Adding service: camiant.osgi.msr.core
<br><br>Dec 23, 2009 4:30:48 PM com.sun.grizzly.Controller logVersion
<br><br>INFO: Starting Grizzly Framework 1.9.18-e - Wed Dec 23 16:30:48 EST 2009
<br><br>2009-12-23 16:30:48,220-0500 INFO HttpServiceServiceTrackerCustomizer:65 -
<br>Adding service: com.sun.grizzly.osgi.grizzly-httpservice-bundle
<br><br>Dec 23, 2009 4:30:48 PM com.sun.jersey.api.core.PackagesResourceConfig init
<br><br>INFO: Scanning for root resource and provider classes in the packages:
<br><br> camiant.osgi.msr.rest.resource
<br><br>Dec 23, 2009 4:30:48 PM com.sun.jersey.api.core.ScanningResourceConfig init
<br><br>INFO: No root resource classes found.
<br><br>Dec 23, 2009 4:30:48 PM com.sun.jersey.api.core.ScanningResourceConfig init
<br><br>INFO: No provider classes found.
<br><br>ERROR: EventDispatcher: Error during dispatch.
<br>(com.sun.jersey.spi.service.ServiceConfigurationError:
<br>com.sun.jersey.spi.container.WebApplicationProvider: The class
<br>com.sun.jersey.server.impl.container.WebApplicationProviderImpl implementing
<br>provider interface com.sun.jersey.spi.container.WebApplicationProvider could
<br>not be instantiated: null)
<br><br>com.sun.jersey.spi.service.ServiceConfigurationError:
<br>com.sun.jersey.spi.container.WebApplicationProvider: The class
<br>com.sun.jersey.server.impl.container.WebApplicationProviderImpl implementing
<br>provider interface com.sun.jersey.spi.container.WebApplicationProvider could
<br>not be instantiated: null
<br><br> at
<br>com.sun.jersey.spi.service.ServiceFinder.fail(ServiceFinder.java:380)
<br><br> at
<br>com.sun.jersey.spi.service.ServiceFinder.access$600(ServiceFinder.java:144)
<br><br> at
<br>com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator.hasNext(ServiceF
<br>inder.java:683)
<br><br> at
<br>com.sun.jersey.spi.container.WebApplicationFactory.createWebApplication(WebA
<br>pplicationFactory.java:61)
<br><br> at
<br>com.sun.jersey.spi.container.servlet.ServletContainer.create(ServletContaine
<br>r.java:325)
<br><br> at
<br>com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.c
<br>reate(ServletContainer.java:240)
<br><br> at
<br>com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:548
<br>)
<br><br> at
<br>com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:201
<br>)
<br><br> at
<br>com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.
<br>java:307)
<br><br> at
<br>com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.
<br>java:470)
<br><br> at javax.servlet.GenericServlet.init(GenericServlet.java:242)
<br><br> at
<br>com.sun.grizzly.http.servlet.ServletAdapter.loadServlet(ServletAdapter.java:
<br>428)
<br><br> at
<br>com.sun.grizzly.osgi.httpservice.OSGiServletAdapter.startServlet(OSGiServlet
<br>Adapter.java:99)
<br><br> at
<br>com.sun.grizzly.osgi.httpservice.OSGiMainAdapter.registerServletAdapter(OSGi
<br>MainAdapter.java:178)
<br><br> at
<br>com.sun.grizzly.osgi.httpservice.HttpServiceImpl.registerServlet(HttpService
<br>Impl.java:92)
<br><br> at
<br>camiant.osgi.msr.rest.HttpServiceServiceTrackerCustomizer.addingService(Http
<br>ServiceServiceTrackerCustomizer.java:70)
<br><br> at
<br>org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker
<br>.java:896)
<br><br> at
<br>org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)
<br><br> at
<br>org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233)
<br><br> at
<br>org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.j
<br>ava:840)
<br><br> at
<br>org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallbac
<br>k(EventDispatcher.java:878)
<br><br> at
<br>org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDi
<br>spatcher.java:732)
<br><br> at
<br>org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispat
<br>cher.java:662)
<br><br> at
<br>org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3587)
<br><br> at org.apache.felix.framework.Felix.access$000(Felix.java:40)
<br><br> at
<br>org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:625)
<br><br> at
<br>org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.j
<br>ava:90)
<br><br> at
<br>org.apache.felix.framework.Felix.registerService(Felix.java:2711)
<br><br> at
<br>org.apache.felix.framework.BundleContextImpl.registerService(BundleContextIm
<br>pl.java:252)
<br><br> at
<br>org.apache.felix.framework.BundleContextImpl.registerService(BundleContextIm
<br>pl.java:230)
<br><br> at
<br>com.sun.grizzly.osgi.httpservice.Activator.start(Activator.java:89)
<br><br> at
<br>org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.jav
<br>a:639)
<br><br> at
<br>org.apache.felix.framework.Felix.activateBundle(Felix.java:1700)
<br><br> at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)
<br><br> at
<br>org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077)
<br><br> at
<br>org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
<br><br> at java.lang.Thread.run(Thread.java:619)
<br><br>Caused by: java.lang.ClassCastException
<br><br> at java.lang.Class.cast(Class.java:2990)
<br><br> at
<br>com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator.hasNext(ServiceF
<br>inder.java:641)
<br><br> ... 34 more
<br><br>[INFO] Started bridged http service
<br><br>-> *INFO * Failed to instantiate plugin
<br>org.apache.felix.webconsole.internal.compendium.ComponentsServlet. Reason:
<br>java.lang.NoClassDefFoundError: org.apache.felix.scr.ScrService
<br><br>*INFO * Failed to instantiate plugin
<br>org.apache.felix.webconsole.internal.compendium.ConfigManager. Reason:
<br>java.lang.NoClassDefFoundError:
<br>org/osgi/service/metatype/ObjectClassDefinition
<br><br>*INFO * Failed to instantiate plugin
<br>org.apache.felix.webconsole.internal.compendium.PreferencesConfigurationPrin
<br>ter. Reason: java.lang.NoClassDefFoundError:
<br>org/osgi/service/prefs/BackingStoreException
<br><br>*INFO * Failed to instantiate plugin
<br>org.apache.felix.webconsole.internal.deppack.DepPackServlet. Reason:
<br>java.lang.NoClassDefFoundError:
<br>org/osgi/service/deploymentadmin/DeploymentException
<br><br>ps
<br><br>START LEVEL 1
<br><br> ID State Level Name
<br><br>[ 0] [Active ] [ 0] System Bundle (2.0.1)
<br><br>[ 1] [Active ] [ 1] Ant repackaging (3.0.0.b74b)
<br><br>[ 2] [Active ] [ 1] ASM all classes (3.2)
<br><br>[ 3] [Active ] [ 1] Camiant MSR Core (0.1.0)
<br><br>[ 4] [Active ] [ 1] Camiant MSR REST (0.1.0)
<br><br>[ 5] [Active ] [ 1] Grizzly OSGi HttpService Bundle (1.9.18.e)
<br><br>[ 6] [Active ] [ 1] http (0)
<br><br>[ 7] [Active ] [ 1] Jackson JSON processor (1.1.1)
<br><br>[ 8] [Active ] [ 1] javax.annotation API v.1.1 (3.0.0.b74b)
<br><br>[ 9] [Active ] [ 1] javax.ejb API v.3.1 (3.0.0.b74b)
<br><br>[ 10] [Active ] [ 1] Java Persistence API 2.0 (2.0.0.v200911271158)
<br><br>[ 11] [Active ] [ 1] javax.servlet API v.3.0 (3.0.0.b74b)
<br><br>[ 12] [Active ] [ 1] javax.servlet.jsp API v.2.1.2 (3.0.0.b74b)
<br><br>[ 13] [Active ] [ 1] jaxb-api (2.2)
<br><br>[ 14] [Active ] [ 1] jaxb (2.2)
<br><br>[ 15] [Active ] [ 1] jdom (0)
<br><br>[ 16] [Active ] [ 1] jersey-bundle (1.1.5.ea-SNAPSHOT)
<br><br>[ 17] [Active ] [ 1] jettison (1.1)
<br><br>[ 18] [Active ] [ 1] jsr311-api (1.1.1)
<br><br>[ 19] [Active ] [ 1] JavaMail API (1.4.3)
<br><br>[ 20] [Active ] [ 1] Apache Felix Configuration Admin Service
<br>(1.2.4)
<br><br>[ 21] [Active ] [ 1] Apache Felix Http Bundle (2.0.4)
<br><br>[ 22] [Active ] [ 1] Apache Felix Shell Service (1.4.1)
<br><br>[ 23] [Active ] [ 1] Apache Felix Shell TUI (1.4.1)
<br><br>[ 24] [Active ] [ 1] Apache Felix Web Management Console (2.0.2)
<br><br>[ 25] [Resolved ] [ 1] Camiant MSR Log4JProperties (0.5.0)
<br><br>[ 26] [Active ] [ 1] Apache Jakarta log4j Plug-in
<br>(1.2.15.v200910021404)
<br><br>[ 27] [Active ] [ 1] ROME, RSS and atOM utilitiEs for Java (1.0)
<br><br>[ 28] [Active ] [ 1] slf4j-api (1.5.8)
<br><br>[ 29] [Resolved ] [ 1] slf4j-log4j12 (1.5.8)
<br><br>[ 30] [Active ] [ 1] Sun Misc RT Packages (1.0.0)
<br><br>[ 31] [Active ] [ 1] tools (0)
<br><br>[ 32] [Active ] [ 1] Weld OSGi Bundle (1.0.0.SP4)
<br><br>
<br><br>
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Users-f28135.html" embed="fixTarget[28135]" target="_top" >Apache Felix - Users</a></p>tag:old.nabble.com,2006:post-26905966Karaf's Blueprint implementation and namespace question2009-12-23T10:56:18Z2009-12-23T10:56:18ZnfndxHi
<br><br>I was wondering if it is at all possible to add custom namespace handlers to
<br>the blueprint config file
<br>What I would like to do is port an existing spring-osgi configuration file
<br>to blueprint, but at th emoment I am stuck.
<br><br>Below is the xml configuration file which I ported to blueprint
<br><br><br><?xml version="1.0" encoding="UTF-8" standalone="no"?>
<br><blueprint xmlns="<a href="http://www.osgi.org/xmlns/blueprint/v1.0.0" target="_top" rel="nofollow">http://www.osgi.org/xmlns/blueprint/v1.0.0</a>"
<br>xmlns:xsi="<a href="http://www.w3.org/2001/XMLSchema-instance" target="_top" rel="nofollow">http://www.w3.org/2001/XMLSchema-instance</a>"
<br>xmlns:tx="<a href="http://www.springframework.org/schema/tx" target="_top" rel="nofollow">http://www.springframework.org/schema/tx</a>"
<br>xmlns:context="<a href="http://www.springframework.org/schema/context" target="_top" rel="nofollow">http://www.springframework.org/schema/context</a>"
<br> xmlns:aop="<a href="http://www.springframework.org/schema/aop" target="_top" rel="nofollow">http://www.springframework.org/schema/aop</a>"
<br>xsi:schemaLocation="<a href="http://www.springframework.org/schema/beans" target="_top" rel="nofollow">http://www.springframework.org/schema/beans</a><br><a href="http://www.springframework.org/schema/beans/spring-beans.xsd" target="_top" rel="nofollow">http://www.springframework.org/schema/beans/spring-beans.xsd</a><br> <a href="http://www.springframework.org/schema/tx" target="_top" rel="nofollow">http://www.springframework.org/schema/tx</a><br><a href="http://www.springframework.org/schema/tx/spring-tx-2.5.xsd" target="_top" rel="nofollow">http://www.springframework.org/schema/tx/spring-tx-2.5.xsd</a><br> <a href="http://www.springframework.org/schema/context" target="_top" rel="nofollow">http://www.springframework.org/schema/context</a><br><a href="http://www.springframework.org/schema/context/spring-context-2.5.xsd" target="_top" rel="nofollow">http://www.springframework.org/schema/context/spring-context-2.5.xsd</a><br> <a href="http://www.springframework.org/schema/aop" target="_top" rel="nofollow">http://www.springframework.org/schema/aop</a><br><a href="http://www.springframework.org/schema/aop/spring-aop-2.5.xsd" target="_top" rel="nofollow">http://www.springframework.org/schema/aop/spring-aop-2.5.xsd</a>">
<br><br><br><service ref="rules-service"
<br>interface="com.nebulasoft.rulesservice.RulesServices" />
<br><reference id="referencecodes-service"
<br>interface="com.nebulasoft.referencecodes.ReferenceCodesService" />
<br><bean id="rules-service"
<br>class="com.nebulasoft.rulesservice.drools.DroolsRuleServicesImplementation"
<br>init-method="init">
<br><property name="referenceCodeService" ref="referencecodes-service" />
<br></bean>
<br><bean
<br>class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"
<br>/>
<br><bean id="entityManagerFactory"
<br>class="org.springframework.orm.jpa.LocalEntityManagerFactoryBean">
<br><property name="persistenceUnitName" value="test" />
<br></bean>
<br><bean id="transactionManager"
<br>class="org.springframework.orm.jpa.JpaTransactionManager">
<br><property name="entityManagerFactory" ref="entityManagerFactory" />
<br></bean>
<br><context:load-time-weaver
<br>weaver-class="org.springframework.instrument.classloading.InstrumentationLoadTimeWeaver"
<br>/>
<br><tx:advice id="txAdvice" transaction-manager="transactionManager">
<br><tx:attributes>
<br><tx:method name="*" propagation="REQUIRED" />
<br></tx:attributes>
<br></tx:advice>
<br></blueprint>
<br><br><br><br>However, when I deploy my bundle into Karaf/Felix. I see the following DEBUG
<br>log, which seems like it cannot resolve the namespace handlers which are in
<br>the spring bundlesin the spring bundles. Thereafter nothing seems to
<br>happen....in other words my service is not started
<br><br><br>20:30:27,828 | DEBUG | pool-2-thread-2 | BlueprintEventDispatcher |
<br>ntainer.BlueprintEventDispatcher 97 | Sending blueprint container event
<br>BlueprintEvent[type=GRACE_PERIOD,
<br>dependencies=[(&(objectClass=org.apache.geronimo.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=
<br><a href="http://www.springframework.org/schema/context" target="_top" rel="nofollow">http://www.springframework.org/schema/context</a>)),
<br>(&(objectClass=org.apache.geronimo.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=
<br><a href="http://www.springframework.org/schema/tx" target="_top" rel="nofollow">http://www.springframework.org/schema/tx</a>))]] for bundle rules-service-drools
<br>20:30:27,828 | DEBUG | pool-1-thread-1 | BlueprintListener |
<br>raf.shell.osgi.BlueprintListener 85 | Blueprint app state changed to
<br>GracePeriod for bundle 68
<br><br><br><br>Thank you in advance
<br>Ivanhoe
<br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Users-f28135.html" embed="fixTarget[28135]" target="_top" >Apache Felix - Users</a></p>tag:old.nabble.com,2006:post-26903332[jira] Commented: (FELIX-1913) All events are processed in a queue2009-12-23T07:08:29Z2009-12-23T07:08:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794066#action_12794066" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794066#action_12794066</a> ]
<br><br>Carsten Ziegeler commented on FELIX-1913:
<br>-----------------------------------------
<br><br>I mean the library for java 1.3 or 1.4 - not the package in java 1.5 :)
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, ea2.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26903107[jira] Commented: (FELIX-1913) All events are processed in a queue2009-12-23T06:48:29Z2009-12-23T06:48:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794062#action_12794062" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794062#action_12794062</a> ]
<br><br>Karl Pauls commented on FELIX-1913:
<br>-----------------------------------
<br><br>Uses the util.concurrent? I was thinking about one that doesn't...
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, ea2.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26902808[jira] Commented: (FELIX-1913) All events are processed in a queue2009-12-23T06:22:29Z2009-12-23T06:22:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794059#action_12794059" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794059#action_12794059</a> ]
<br><br>Carsten Ziegeler commented on FELIX-1913:
<br>-----------------------------------------
<br><br>I've an older thread pool implementation lying around which uses the util.concurrent package (and provides the same functionality)
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, ea2.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26902731[jira] Commented: (FELIX-1913) All events are processed in a queue2009-12-23T06:14:29Z2009-12-23T06:14:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794057#action_12794057" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794057#action_12794057</a> ]
<br><br>Karl Pauls commented on FELIX-1913:
<br>-----------------------------------
<br><br>yes, it seems to be passing now. i will try to add a thread pool that doesn't require java5 and then we might be good to go. Cool stuff.
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, ea2.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26901850[jira] Commented: (FELIX-1913) All events are processed in a queue2009-12-23T05:08:29Z2009-12-23T05:08:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794044#action_12794044" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794044#action_12794044</a> ]
<br><br>Carsten Ziegeler commented on FELIX-1913:
<br>-----------------------------------------
<br><br>Yes, the order is preserverd - however if an event handler takes longer than the timeout, this handler still runs when the next event from the stack is processed.
<br>I've run it through my tests and they look fine (which is obvious as the whole point of this change is to make my tests look good), so I'm looking forward to your additional tests.
<br>By this, I assume the TCK runs fine on the implementation, right?
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, ea2.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26901785[jira] Commented: (FELIX-1913) All events are processed in a queue2009-12-23T05:02:29Z2009-12-23T05:02:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794042#action_12794042" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794042#action_12794042</a> ]
<br><br>Karl Pauls commented on FELIX-1913:
<br>-----------------------------------
<br><br>So how do you handle timeouts in the case of stacked sync events then? Are you still preserving the order in that case? I guess i will have to find my old tests and look at your patch. I'll give it a go and report back next week.
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, ea2.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26901620Re: [VOTE] Release fileinstall 2.0.82009-12-23T04:48:25Z2009-12-23T04:48:25ZFreeman Fang+1 (Non-binding）
<br><br>Regards
<br>Freeman
<br>On 2009-12-23, at 上午4:35, Chris Custine wrote:
<br><div class='shrinkable-quote'><br>> Hi All,
<br>> Before checking the staged artifacts, please be sure to import my
<br>> public key
<br>> from either <a href="http://www.apache.org/dist/felix/KEYS" target="_top" rel="nofollow">http://www.apache.org/dist/felix/KEYS</a> or a public
<br>> keyserver.
<br>>
<br>> Release Notes - Felix - Version fileinstall-2.0.8
<br>> ** Bug
<br>> * [FELIX-1775] - fileinstall release archives contains an empty
<br>> "load"
<br>> folder which should be removed
<br>> * [FELIX-1789] - FileInstall is too verbose
<br>> * [FELIX-1851] - FileInstall watched bundles are restarted twice
<br>> upon
<br>> update
<br>> * [FELIX-1861] - FileInstall created temp directories are never
<br>> deleted
<br>> * [FELIX-1862] - fileinstall thread name as printed in log
<br>> messages need
<br>> to be less verbose
<br>> * [FELIX-1928] - File installer starts bundles too early on restart
<br>> ** Task
<br>> * [FELIX-1811] - fileinstall should depend on the official osgi
<br>> artifacts
<br>>
<br>> Staging repository:
<br>> <a href="https://repository.apache.org/content/repositories/orgapachefelix-005/" target="_top" rel="nofollow">https://repository.apache.org/content/repositories/orgapachefelix-005/</a><br>>
<br>> You can use this UNIX script to download the release and verify the
<br>> signatures:
<br>> <a href="http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh" target="_top" rel="nofollow">http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh</a><br>>
<br>> Usage:
<br>> sh check_staged_release.sh 005 /tmp/felix-staging
<br>>
<br>> Please vote to approve this release:
<br>>
<br>> [ ] +1 Approve the release
<br>> [ ] -1 Veto the release (please provide specific comments)
<br>>
<br>> This vote will be open for 72 hours.
<br>>
<br>> Thanks,
<br>> Chris
<br>>
<br>> --
<br>> Chris Custine
<br>> FUSESource :: <a href="http://fusesource.com" target="_top" rel="nofollow">http://fusesource.com</a><br>> My Blog :: <a href="http://blog.organicelement.com" target="_top" rel="nofollow">http://blog.organicelement.com</a><br>> Apache ServiceMix :: <a href="http://servicemix.apache.org" target="_top" rel="nofollow">http://servicemix.apache.org</a><br>> Apache Felix :: <a href="http://felix.apache.org" target="_top" rel="nofollow">http://felix.apache.org</a><br>> Apache Directory Server :: <a href="http://directory.apache.org" target="_top" rel="nofollow">http://directory.apache.org</a></div><br><br>--
<br>Freeman Fang
<br>------------------------
<br>Open Source SOA: <a href="http://fusesource.com" target="_top" rel="nofollow">http://fusesource.com</a><br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26901467[jira] Commented: (FELIX-1913) All events are processed in a queue2009-12-23T04:32:29Z2009-12-23T04:32:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794034#action_12794034" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794034#action_12794034</a> ]
<br><br>Carsten Ziegeler commented on FELIX-1913:
<br>-----------------------------------------
<br><br>Yes, more or less :) Each event handler is sent the event with a new thread. If you have two event handlers for a given event, the second handler is called either when the first one returns (within the timeout) or as soon as the timeout occurs. In this case the first handler is immediately blacklisted - so a handler is blacklisted as soon as the timeout is reached and other handlers get called immediately.
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, ea2.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26901140[jira] Commented: (FELIX-1913) All events are processed in a queue2009-12-23T03:58:31Z2009-12-23T03:58:31ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794027#action_12794027" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794027#action_12794027</a> ]
<br><br>Karl Pauls commented on FELIX-1913:
<br>-----------------------------------
<br><br>This looks better. One question, if a handler gets a timeout are you then still using a new thread to continue the sync dispatch of the event to the other handlers or are you just waiting for the handler to finally return and then blacklist the handler?
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, ea2.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26900869[jira] Commented: (FELIX-1913) All events are processed in a queue2009-12-23T03:27:29Z2009-12-23T03:27:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794023#action_12794023" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794023#action_12794023</a> ]
<br><br>Carsten Ziegeler commented on FELIX-1913:
<br>-----------------------------------------
<br><br>According to my tests the order is now maintained, but performance increases if several threads are posting events...so let's see what the TCK says :)
<br>I've attached the complete patch for the source code as well - currently it requires java 5 - it is more a prototype which might need further cleanup/improvements :)
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, ea2.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26900853[jira] Updated: (FELIX-1913) All events are processed in a queue2009-12-23T03:25:29Z2009-12-23T03:25:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Carsten Ziegeler updated FELIX-1913:
<br>------------------------------------
<br><br> Attachment: (was: org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar)
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, ea2.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26900854[jira] Updated: (FELIX-1913) All events are processed in a queue2009-12-23T03:25:29Z2009-12-23T03:25:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Carsten Ziegeler updated FELIX-1913:
<br>------------------------------------
<br><br> Attachment: org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br><br>New version
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, ea2.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26900855[jira] Updated: (FELIX-1913) All events are processed in a queue2009-12-23T03:25:29Z2009-12-23T03:25:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Carsten Ziegeler updated FELIX-1913:
<br>------------------------------------
<br><br> Attachment: (was: org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar)
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, ea2.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26900856[jira] Updated: (FELIX-1913) All events are processed in a queue2009-12-23T03:25:29Z2009-12-23T03:25:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Carsten Ziegeler updated FELIX-1913:
<br>------------------------------------
<br><br> Attachment: ea2.patch
<br><br>The complete patch
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, ea2.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26900857[jira] Updated: (FELIX-1913) All events are processed in a queue2009-12-23T03:25:29Z2009-12-23T03:25:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Carsten Ziegeler updated FELIX-1913:
<br>------------------------------------
<br><br> Attachment: org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br><br>New version
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, ea2.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26900725[jira] Commented: (FELIX-1792) Felix OBR seems to just randomly choose one of the satisifed bundles if more than one bundle meets the requirement2009-12-23T03:11:30Z2009-12-23T03:11:30ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794014#action_12794014" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794014#action_12794014</a> ]
<br><br>hehe ji commented on FELIX-1792:
<br>--------------------------------
<br><br>Hi Richard,
<br><br>What I mean about "in eba" is that I put the bundles in my local repository. Sorry about the confusion. You can put the bundles in any repositories, which should not make any difference.
<br><br>Below are the manifests for the bundles I mentioned in my previous email.
<br><br>bundle71.jar
<br><br>Manifest-Version: 1.0
<br>Bundle-ManifestVersion: 2
<br>Bundle-Name: Bundle Plug-in
<br>Bundle-SymbolicName: a.b.c.bundle71
<br>Bundle-Version: 1.0.0
<br>Bundle-Vendor: ABC
<br>Import-Package: a.b.c.bundle72;version=3.0
<br>Export-Package: a.b.c.bundle71
<br><br>bundle72.jar
<br>Manifest-Version: 1.0
<br>Bundle-ManifestVersion: 2
<br>Bundle-Name: Bundle Plug-in
<br>Bundle-SymbolicName: a.b.c.bundle72
<br>Bundle-Version: 1.0.0
<br>Bundle-Vendor: ABC
<br>Import-Package: a.b.c.bundle73
<br>Export-Package: a.b.c.bundle72;version=3.2.4.1ded6
<br><br>bundle72_2.jar
<br>Manifest-Version: 1.0
<br>Bundle-ManifestVersion: 2
<br>Bundle-Name: Bundle Plug-in
<br>Bundle-SymbolicName: a.b.c.bundle72
<br>Bundle-Version: 2.0.0
<br>Bundle-Vendor: ABC
<br>Import-Package: a.b.c.bundle.invalid
<br>Export-Package: a.b.c.bundle72;version=9
<br><br>bundle73
<br>Manifest-Version: 1.0
<br>Bundle-ManifestVersion: 2
<br>Bundle-Name: Bundle Plug-in
<br>Bundle-SymbolicName: a.b.c.bundle73
<br>Bundle-Version: 1.0.0
<br>Bundle-Vendor: ABC
<br>Export-Package: a.b.c.bundle73
<br>Import-Package: org.osgi.framework
<br><br>Feel free to let me know if you need more explanation.
<br>Thanks
<br>Emily
<br><div class='shrinkable-quote'><br>> Felix OBR seems to just randomly choose one of the satisifed bundles if more than one bundle meets the requirement
<br>> ------------------------------------------------------------------------------------------------------------------
<br>>
<br>> Key: FELIX-1792
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1792" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1792</a><br>> Project: Felix
<br>> Issue Type: Bug
<br>> Components: Bundle Repository (OBR)
<br>> Affects Versions: bundlerepository-1.4.2
<br>> Environment: n/a
<br>> Reporter: david small99
<br>> Assignee: Richard S. Hall
<br>> Fix For: bundlerepository-1.6.0
<br>>
<br>>
<br>> I have one bundle bundle1, which imports a package called com.obr.bundle
<br>> Bundle1's manifest:
<br>> Manifest-Version: 1.0
<br>> Ant-Version: Apache Ant 1.7.0
<br>> Bundle-ManifestVersion: 2
<br>> Bundle-Name: Bundle Plug-in
<br>> Bundle-SymbolicName: com.obr.bundle1
<br>> Bundle-Version: 1.0.0
<br>> Export-Package: com.obr.bundle1
<br>> Import-Package: com.obr.bundle;version="[1.2.0.999,3.2.2.bz]"
<br>> There are two bundles in my repositories, bundler2 and bundle 3. Both of them export package com.obr.bundle. Below are their manifest files.
<br>> Bundle2
<br>> Manifest-Version: 1.0
<br>> Ant-Version: Apache Ant 1.7.0
<br>> Bundle-ManifestVersion: 2
<br>> Bundle-Name: Bundle Plug-in
<br>> Bundle-SymbolicName: com.obr.bundle2
<br>> Bundle-Version: 1.0.0
<br>> Bundle-Vendor: xxx
<br>> Import-Package: a.b.c
<br>> Export-Package: com.obr.bundle;version=3.2.2.blah
<br>> Bundle3:
<br>> Manifest-Version: 1.0
<br>> Ant-Version: Apache Ant 1.7.0
<br>> Bundle-ManifestVersion: 2
<br>> Bundle-Name: Bundle Plug-in
<br>> Bundle-SymbolicName: com.obr.bundle3
<br>> Bundle-Version: 1.0.0
<br>> Import-Package: a.b.c
<br>> Export-Package: com.obr.bundle;version=3.1
<br>> As you can see, both bundle2 and bundle3 meet the requirements of bundle1. I hope the highest package version, which is bundle2, is chosen by felix obr. However, sometimes bundle 3 was chosen instead of bundle2. The behaviour is random.
<br>> Am I right to say that the Felix obr runtime just picks the first bundle that meets the requirements and then stop searching for any more eligible bundles?
<br>> Thanks
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26900452[jira] Commented: (FELIX-1913) All events are processed in a queue2009-12-23T02:35:29Z2009-12-23T02:35:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794006#action_12794006" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794006#action_12794006</a> ]
<br><br>Carsten Ziegeler commented on FELIX-1913:
<br>-----------------------------------------
<br><br>Ah yes, the order is not maintained in the async case :) I did overlook the second sentence in the spec....I'll try to fix this today and then give you the patch :)
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26900342[jira] Commented: (FELIX-1913) All events are processed in a queue2009-12-23T02:23:29Z2009-12-23T02:23:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794000#action_12794000" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794000#action_12794000</a> ]
<br><br>Karl Pauls commented on FELIX-1913:
<br>-----------------------------------
<br><br>Well, as i did say, we have to make sure we maintain the order of events and it did sound like you don't. Sure enough, your implementation doesn't pass the tck (complains about out-of-order delivery :-). Can you try to get me a patch (then i will have a look during the chrismas break)?
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26900223[jira] Commented: (FELIX-1913) All events are processed in a queue2009-12-23T02:11:29Z2009-12-23T02:11:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793996#action_12793996" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793996#action_12793996</a> ]
<br><br>Carsten Ziegeler commented on FELIX-1913:
<br>-----------------------------------------
<br><br>I've added the final bundle as I did change a lot :) (Mostly removed stuff which is not needed with a thread pool anymore) - yes, I'm not sure if this is 100% spec compliant - it should be, but the tck check will show this :) Thanks!
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26900193[jira] Updated: (FELIX-1913) All events are processed in a queue2009-12-23T02:09:30Z2009-12-23T02:09:30ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Carsten Ziegeler updated FELIX-1913:
<br>------------------------------------
<br><br> Attachment: org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br><br>Prototype using thread pools
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch, org.apache.felix.eventadmin-1.0.1-SNAPSHOT.jar
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26899922[jira] Commented: (FELIX-1913) All events are processed in a queue2009-12-23T01:41:29Z2009-12-23T01:41:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793984#action_12793984" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793984#action_12793984</a> ]
<br><br>Karl Pauls commented on FELIX-1913:
<br>-----------------------------------
<br><br>Can you attach the patch for the concurrent async delivery? I'm not sure that we can get the speed-up you see as events have to be delivered in order if they are posted by the same thread. In other words, we have to make sure that we account for a handler that turns around and posts a new event. For sure, we can have each event delivered in parallel. If you attach the patch I'll run it through the tck.
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26898910[jira] Created: (FELIX-1960) Fine-grained timeout configuration2009-12-22T23:29:29Z2009-12-22T23:29:29ZJIRA jira@apache.orgFine-grained timeout configuration
<br>----------------------------------
<br><br> Key: FELIX-1960
<br> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1960" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1960</a><br> Project: Felix
<br> Issue Type: Improvement
<br> Components: Event Admin
<br> Affects Versions: eventadmin 1.0.0
<br> Reporter: Carsten Ziegeler
<br><br><br>The timeout setting for event delivery is currentl a global setting - event listeners should (recommended by the spec as well) start an async thread if they need some time to process the event.
<br>With the timeout setting in place, this creates two threads for each event delivery: one for the timeout handling and one for the event processing.
<br><br>I think it would be nice, if one could optimize this behaviour by configuring the event admin to directly call specific event listeners and don't check the timeout. An administrator could add well-known event listeners to this configuration. This would reduce the server load for well-behaving event listeners.
<br><br>I could imagine something like ignore.timeout.for=org.apache.sling.jcr.*,my.special.EventListener (with a better name for the config property) - so you can either add package prefixes or specific classes to the configuration.
<br><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26898883[jira] Commented: (FELIX-1913) All events are processed in a queue2009-12-22T23:25:29Z2009-12-22T23:25:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793960#action_12793960" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793960#action_12793960</a> ]
<br><br>Carsten Ziegeler commented on FELIX-1913:
<br>-----------------------------------------
<br><br>The processing of async events is very slow as well as they are put in a queue as well - this could be done in parallel, too. In the meantime I've rewritten the event admin as a proof of concept. My version now uses a thread pool (currently from jdk 1.5 - but this can be backportet for older java versions). The events are processed in parallel (if possible) by using this thread pool. This gives a real performance boost with lots of events and several listeners.
<br>Just as an example: I create 1000 events which are sent directly one after the other and 4 listeners - each listeners takes 50ms - each listener gets each event.
<br>As the listeners are processed one after other a single event delivery takes 200ms. The old implementation processes the 1000 events one after the other - so the total delivery time is 1000 * 200ms.
<br>The new implementation takes a configurable thread pool - in my example I use 25 threads - therefore 25 events are processed in parallel, total delivery time goes down to 40 * 200ms
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26898844[jira] Updated: (FELIX-1913) All events are processed in a queue2009-12-22T23:19:29Z2009-12-22T23:19:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Carsten Ziegeler updated FELIX-1913:
<br>------------------------------------
<br><br> Description:
<br>The current event admin implementation puts all events into a queue and processes this queue 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.
<br>In the async mode, event deliver might take a long time as these events are processed one after the other as well.
<br><br> was: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.
<br><br> Summary: All events are processed in a queue (was: All synchronous events are processed in one queue)
<br><div class='shrinkable-quote'><br>> All events are processed in a queue
<br>> -----------------------------------
<br>>
<br>> Key: FELIX-1913
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1913" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1913</a><br>> Project: Felix
<br>> Issue Type: Improvement
<br>> Components: Event Admin
<br>> Affects Versions: eventadmin 1.0.0
<br>> Reporter: Carsten Ziegeler
<br>> Assignee: Karl Pauls
<br>> Priority: Minor
<br>> Attachments: ea.patch
<br>>
<br>>
<br>> The current event admin implementation puts all events into a queue and processes this queue 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.
<br>> In the async mode, event deliver might take a long time as these events are processed one after the other as well.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26898833[jira] Commented: (FELIX-1959) Move towards unified L&F and extended branding support2009-12-22T23:17:31Z2009-12-22T23:17:31ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793956#action_12793956" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793956#action_12793956</a> ]
<br><br>Carsten Ziegeler commented on FELIX-1959:
<br>-----------------------------------------
<br><br>Yes, I think we should move forward with this!
<br>Maybe we should start by adding the libraries to the console and then migrate one plugin after the other.
<br>When we have migrated all plugins we could cleanup the html/css of the console itself
<br><br>And having i18n support would be a real nice thing...but maybe we could do this afterwards?
<br><br>So if you have any patches, Valentin, they're more than welcome :)
<br><div class='shrinkable-quote'><br>> Move towards unified L&F and extended branding support
<br>> ------------------------------------------------------
<br>>
<br>> Key: FELIX-1959
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1959" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1959</a><br>> Project: Felix
<br>> Issue Type: New Feature
<br>> Components: Web Console
<br>> Reporter: Valentin Valchev
<br>> Assignee: Carsten Ziegeler
<br>> Priority: Minor
<br>> Attachments: jqueryui-vs-default-lnf.png, tb6.jar
<br>>
<br>>
<br>> Currently the Web Console uses heavily on the JQuery framework. Using a unified JavaScript framework simplifies development of all plugins and unifies the used approach.
<br>> However, when talking about visual styling, there are number of differences because each plugin developer uses own styles.
<br>> My suggestion is to adopt the JQuery UI . The benefits of using it as unified widget/css framework are:
<br>> - no time to spend on writing widgets already in the library
<br>> - clean CSS visual styling
<br>> - easy way to change the L&F by changing the theme (extended branding support!)
<br>> - improved cross-browser support (JQuery UI takes care of CSS differences)
<br>> Using the JQuery UI framework the developer shouldn't care about color but only for layout - components position; and for data being displayed.
<br>> To illustrate the benefits I've saved the "Log Service" page, modified it to use JQuery UI, took screen-shot, modified the theme CSS only, and again took screen-shot, and finally added the original L&F for reference, so you can easily compare the result.
<br>> The attached image contains the combined screen-shots.
<br>> "
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26897953Re: [VOTE] Release fileinstall 2.0.82009-12-22T20:18:15Z2009-12-22T20:18:15ZGert VanthienenL.S.,
<br><br>Here's my +1 (non-binding)
<br><br>Regards,
<br><br>Gert Vanthienen
<br>------------------------
<br>Open Source SOA: <a href="http://fusesource.com" target="_top" rel="nofollow">http://fusesource.com</a><br>Blog: <a href="http://gertvanthienen.blogspot.com/" target="_top" rel="nofollow">http://gertvanthienen.blogspot.com/</a><br><br><br><br>2009/12/22 Chris Custine <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26897953&i=0" target="_top" rel="nofollow">ccustine@...</a>>:
<div class='shrinkable-quote'><br>> Hi All,
<br>> Before checking the staged artifacts, please be sure to import my public key
<br>> from either <a href="http://www.apache.org/dist/felix/KEYS" target="_top" rel="nofollow">http://www.apache.org/dist/felix/KEYS</a> or a public keyserver.
<br>>
<br>> Release Notes - Felix - Version fileinstall-2.0.8
<br>> ** Bug
<br>> * [FELIX-1775] - fileinstall release archives contains an empty "load"
<br>> folder which should be removed
<br>> * [FELIX-1789] - FileInstall is too verbose
<br>> * [FELIX-1851] - FileInstall watched bundles are restarted twice upon
<br>> update
<br>> * [FELIX-1861] - FileInstall created temp directories are never deleted
<br>> * [FELIX-1862] - fileinstall thread name as printed in log messages need
<br>> to be less verbose
<br>> * [FELIX-1928] - File installer starts bundles too early on restart
<br>> ** Task
<br>> * [FELIX-1811] - fileinstall should depend on the official osgi artifacts
<br>>
<br>> Staging repository:
<br>> <a href="https://repository.apache.org/content/repositories/orgapachefelix-005/" target="_top" rel="nofollow">https://repository.apache.org/content/repositories/orgapachefelix-005/</a><br>>
<br>> You can use this UNIX script to download the release and verify the
<br>> signatures:
<br>> <a href="http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh" target="_top" rel="nofollow">http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh</a><br>>
<br>> Usage:
<br>> sh check_staged_release.sh 005 /tmp/felix-staging
<br>>
<br>> Please vote to approve this release:
<br>>
<br>> [ ] +1 Approve the release
<br>> [ ] -1 Veto the release (please provide specific comments)
<br>>
<br>> This vote will be open for 72 hours.
<br>>
<br>> Thanks,
<br>> Chris
<br>>
<br>> --
<br>> Chris Custine
<br>> FUSESource :: <a href="http://fusesource.com" target="_top" rel="nofollow">http://fusesource.com</a><br>> My Blog :: <a href="http://blog.organicelement.com" target="_top" rel="nofollow">http://blog.organicelement.com</a><br>> Apache ServiceMix :: <a href="http://servicemix.apache.org" target="_top" rel="nofollow">http://servicemix.apache.org</a><br>> Apache Felix :: <a href="http://felix.apache.org" target="_top" rel="nofollow">http://felix.apache.org</a><br>> Apache Directory Server :: <a href="http://directory.apache.org" target="_top" rel="nofollow">http://directory.apache.org</a><br>>
<br></div><div class="signature">---
<br>Gert Vanthienen
<br><a href="http://gertvanthienen.blogspot.com" target="_top" rel="nofollow">http://gertvanthienen.blogspot.com</a></div><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26894114Re: [VOTE] Release fileinstall 2.0.62009-12-22T12:47:41Z2009-12-22T12:47:41ZgnodetSorry about that (I'm in holidays until January so haven't had much
<br>time to follow on this vote). Chris, thx for taking care of that.
<br><br>On Tue, Dec 22, 2009 at 21:06, Chris Custine <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26894114&i=0" target="_top" rel="nofollow">chris.custine@...</a>> wrote:
<div class='shrinkable-quote'><br>> This vote is cancelled due to bad signatures on the artifacts. I'll launch a
<br>> vote on a 2.0.8 release in a new thread.
<br>>
<br>> Chris
<br>> --
<br>> Chris Custine
<br>> FUSESource :: <a href="http://fusesource.com" target="_top" rel="nofollow">http://fusesource.com</a><br>> My Blog :: <a href="http://blog.organicelement.com" target="_top" rel="nofollow">http://blog.organicelement.com</a><br>> Apache ServiceMix :: <a href="http://servicemix.apache.org" target="_top" rel="nofollow">http://servicemix.apache.org</a><br>> Apache Felix :: <a href="http://felix.apache.org" target="_top" rel="nofollow">http://felix.apache.org</a><br>> Apache Directory Server :: <a href="http://directory.apache.org" target="_top" rel="nofollow">http://directory.apache.org</a><br>>
<br>>
<br>> On Thu, Dec 17, 2009 at 3:06 AM, Guillaume Nodet <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26894114&i=1" target="_top" rel="nofollow">gnodet@...</a>> wrote:
<br>>
<br>>> Release Notes - Felix - Version fileinstall-2.0.6
<br>>> ** Bug
<br>>> * [FELIX-1775] - fileinstall release archives contains an empty
<br>>> "load" folder which should be removed
<br>>> * [FELIX-1789] - FileInstall is too verbose
<br>>> * [FELIX-1851] - FileInstall watched bundles are restarted twice upon
<br>>> update
<br>>> * [FELIX-1861] - FileInstall created temp directories are never deleted
<br>>> * [FELIX-1862] - fileinstall thread name as printed in log
<br>>> messages need to be less verbose
<br>>> * [FELIX-1928] - File installer starts bundles too early on restart
<br>>> ** Task
<br>>> * [FELIX-1811] - fileinstall should depend on the official osgi
<br>>> artifacts
<br>>>
<br>>> Staging repository:
<br>>> <a href="https://repository.apache.org/content/repositories/felix-staging-054/" target="_top" rel="nofollow">https://repository.apache.org/content/repositories/felix-staging-054/</a><br>>>
<br>>> You can use this UNIX script to download the release and verify the
<br>>> signatures:
<br>>> <a href="http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh" target="_top" rel="nofollow">http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh</a><br>>>
<br>>> Usage:
<br>>> sh check_staged_release.sh 054 /tmp/felix-staging
<br>>>
<br>>> Please vote to approve this release:
<br>>>
<br>>> [ ] +1 Approve the release
<br>>> [ ] -1 Veto the release (please provide specific comments)
<br>>>
<br>>> This vote will be open for 72 hours.
<br>>>
<br>>> --
<br>>> Cheers,
<br>>> Guillaume Nodet
<br>>> ------------------------
<br>>> Blog: <a href="http://gnodet.blogspot.com/" target="_top" rel="nofollow">http://gnodet.blogspot.com/</a><br>>> ------------------------
<br>>> Open Source SOA
<br>>> <a href="http://fusesource.com" target="_top" rel="nofollow">http://fusesource.com</a><br>>>
<br>>
</div><br><br><br>--
<br>Cheers,
<br>Guillaume Nodet
<br>------------------------
<br>Blog: <a href="http://gnodet.blogspot.com/" target="_top" rel="nofollow">http://gnodet.blogspot.com/</a><br>------------------------
<br>Open Source SOA
<br><a href="http://fusesource.com" target="_top" rel="nofollow">http://fusesource.com</a><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26893977[VOTE] Release fileinstall 2.0.82009-12-22T12:35:20Z2009-12-22T12:35:20ZChris Custine (Apache)Hi All,
<br>Before checking the staged artifacts, please be sure to import my public key
<br>from either <a href="http://www.apache.org/dist/felix/KEYS" target="_top" rel="nofollow">http://www.apache.org/dist/felix/KEYS</a> or a public keyserver.
<br><br>Release Notes - Felix - Version fileinstall-2.0.8
<br>** Bug
<br> * [FELIX-1775] - fileinstall release archives contains an empty "load"
<br>folder which should be removed
<br> * [FELIX-1789] - FileInstall is too verbose
<br> * [FELIX-1851] - FileInstall watched bundles are restarted twice upon
<br>update
<br> * [FELIX-1861] - FileInstall created temp directories are never deleted
<br> * [FELIX-1862] - fileinstall thread name as printed in log messages need
<br>to be less verbose
<br> * [FELIX-1928] - File installer starts bundles too early on restart
<br>** Task
<br> * [FELIX-1811] - fileinstall should depend on the official osgi artifacts
<br><br>Staging repository:
<br><a href="https://repository.apache.org/content/repositories/orgapachefelix-005/" target="_top" rel="nofollow">https://repository.apache.org/content/repositories/orgapachefelix-005/</a><br><br>You can use this UNIX script to download the release and verify the
<br>signatures:
<br><a href="http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh" target="_top" rel="nofollow">http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh</a><br><br>Usage:
<br>sh check_staged_release.sh 005 /tmp/felix-staging
<br><br>Please vote to approve this release:
<br><br>[ ] +1 Approve the release
<br>[ ] -1 Veto the release (please provide specific comments)
<br><br>This vote will be open for 72 hours.
<br><br>Thanks,
<br>Chris
<br><br>--
<br>Chris Custine
<br>FUSESource :: <a href="http://fusesource.com" target="_top" rel="nofollow">http://fusesource.com</a><br>My Blog :: <a href="http://blog.organicelement.com" target="_top" rel="nofollow">http://blog.organicelement.com</a><br>Apache ServiceMix :: <a href="http://servicemix.apache.org" target="_top" rel="nofollow">http://servicemix.apache.org</a><br>Apache Felix :: <a href="http://felix.apache.org" target="_top" rel="nofollow">http://felix.apache.org</a><br>Apache Directory Server :: <a href="http://directory.apache.org" target="_top" rel="nofollow">http://directory.apache.org</a><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26893572Re: [VOTE] Release fileinstall 2.0.62009-12-22T12:06:19Z2009-12-22T12:06:19ZChris CustineThis vote is cancelled due to bad signatures on the artifacts. I'll launch a
<br>vote on a 2.0.8 release in a new thread.
<br><br>Chris
<br>--
<br>Chris Custine
<br>FUSESource :: <a href="http://fusesource.com" target="_top" rel="nofollow">http://fusesource.com</a><br>My Blog :: <a href="http://blog.organicelement.com" target="_top" rel="nofollow">http://blog.organicelement.com</a><br>Apache ServiceMix :: <a href="http://servicemix.apache.org" target="_top" rel="nofollow">http://servicemix.apache.org</a><br>Apache Felix :: <a href="http://felix.apache.org" target="_top" rel="nofollow">http://felix.apache.org</a><br>Apache Directory Server :: <a href="http://directory.apache.org" target="_top" rel="nofollow">http://directory.apache.org</a><br><br><br>On Thu, Dec 17, 2009 at 3:06 AM, Guillaume Nodet <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26893572&i=0" target="_top" rel="nofollow">gnodet@...</a>> wrote:
<br><div class='shrinkable-quote'><br>> Release Notes - Felix - Version fileinstall-2.0.6
<br>> ** Bug
<br>> * [FELIX-1775] - fileinstall release archives contains an empty
<br>> "load" folder which should be removed
<br>> * [FELIX-1789] - FileInstall is too verbose
<br>> * [FELIX-1851] - FileInstall watched bundles are restarted twice upon
<br>> update
<br>> * [FELIX-1861] - FileInstall created temp directories are never deleted
<br>> * [FELIX-1862] - fileinstall thread name as printed in log
<br>> messages need to be less verbose
<br>> * [FELIX-1928] - File installer starts bundles too early on restart
<br>> ** Task
<br>> * [FELIX-1811] - fileinstall should depend on the official osgi
<br>> artifacts
<br>>
<br>> Staging repository:
<br>> <a href="https://repository.apache.org/content/repositories/felix-staging-054/" target="_top" rel="nofollow">https://repository.apache.org/content/repositories/felix-staging-054/</a><br>>
<br>> You can use this UNIX script to download the release and verify the
<br>> signatures:
<br>> <a href="http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh" target="_top" rel="nofollow">http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh</a><br>>
<br>> Usage:
<br>> sh check_staged_release.sh 054 /tmp/felix-staging
<br>>
<br>> Please vote to approve this release:
<br>>
<br>> [ ] +1 Approve the release
<br>> [ ] -1 Veto the release (please provide specific comments)
<br>>
<br>> This vote will be open for 72 hours.
<br>>
<br>> --
<br>> Cheers,
<br>> Guillaume Nodet
<br>> ------------------------
<br>> Blog: <a href="http://gnodet.blogspot.com/" target="_top" rel="nofollow">http://gnodet.blogspot.com/</a><br>> ------------------------
<br>> Open Source SOA
<br>> <a href="http://fusesource.com" target="_top" rel="nofollow">http://fusesource.com</a><br>>
<br></div><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26890878[jira] Issue Comment Edited: (FELIX-1792) Felix OBR seems to just randomly choose one of the satisifed bundles if more than one bundle meets the requirement2009-12-22T08:36:29Z2009-12-22T08:36:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793654#action_12793654" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793654#action_12793654</a> ]
<br><br>Richard S. Hall edited comment on FELIX-1792 at 12/22/09 4:35 PM:
<br>------------------------------------------------------------------
<br><br>What does "in eba" mean?
<br><br>Could you give me a simplified example of the bundle manifests and a description of the steps needed to reproduce the issue? If so, I will look into it.
<br><br> was (Author: rickhall):
<br> What is "in eba" mean?
<br><br>Could you give me a simplified example of the bundle manifests and a description of the steps needed to reproduce the issue? If so, I will look into it.
<br>
<div class='shrinkable-quote'><br>> Felix OBR seems to just randomly choose one of the satisifed bundles if more than one bundle meets the requirement
<br>> ------------------------------------------------------------------------------------------------------------------
<br>>
<br>> Key: FELIX-1792
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1792" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1792</a><br>> Project: Felix
<br>> Issue Type: Bug
<br>> Components: Bundle Repository (OBR)
<br>> Affects Versions: bundlerepository-1.4.2
<br>> Environment: n/a
<br>> Reporter: david small99
<br>> Assignee: Richard S. Hall
<br>> Fix For: bundlerepository-1.6.0
<br>>
<br>>
<br>> I have one bundle bundle1, which imports a package called com.obr.bundle
<br>> Bundle1's manifest:
<br>> Manifest-Version: 1.0
<br>> Ant-Version: Apache Ant 1.7.0
<br>> Bundle-ManifestVersion: 2
<br>> Bundle-Name: Bundle Plug-in
<br>> Bundle-SymbolicName: com.obr.bundle1
<br>> Bundle-Version: 1.0.0
<br>> Export-Package: com.obr.bundle1
<br>> Import-Package: com.obr.bundle;version="[1.2.0.999,3.2.2.bz]"
<br>> There are two bundles in my repositories, bundler2 and bundle 3. Both of them export package com.obr.bundle. Below are their manifest files.
<br>> Bundle2
<br>> Manifest-Version: 1.0
<br>> Ant-Version: Apache Ant 1.7.0
<br>> Bundle-ManifestVersion: 2
<br>> Bundle-Name: Bundle Plug-in
<br>> Bundle-SymbolicName: com.obr.bundle2
<br>> Bundle-Version: 1.0.0
<br>> Bundle-Vendor: xxx
<br>> Import-Package: a.b.c
<br>> Export-Package: com.obr.bundle;version=3.2.2.blah
<br>> Bundle3:
<br>> Manifest-Version: 1.0
<br>> Ant-Version: Apache Ant 1.7.0
<br>> Bundle-ManifestVersion: 2
<br>> Bundle-Name: Bundle Plug-in
<br>> Bundle-SymbolicName: com.obr.bundle3
<br>> Bundle-Version: 1.0.0
<br>> Import-Package: a.b.c
<br>> Export-Package: com.obr.bundle;version=3.1
<br>> As you can see, both bundle2 and bundle3 meet the requirements of bundle1. I hope the highest package version, which is bundle2, is chosen by felix obr. However, sometimes bundle 3 was chosen instead of bundle2. The behaviour is random.
<br>> Am I right to say that the Felix obr runtime just picks the first bundle that meets the requirements and then stop searching for any more eligible bundles?
<br>> Thanks
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26890819[jira] Commented: (FELIX-1959) Move towards unified L&F and extended branding support2009-12-22T08:30:29Z2009-12-22T08:30:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793658#action_12793658" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793658#action_12793658</a> ]
<br><br>Felix Meschberger commented on FELIX-1959:
<br>------------------------------------------
<br><br>This looks very promising -- but also like a big change in various rendering areas.
<br><br>Can we do this step by step aka "page by page" ?
<br><br>Anyways, a big +1 for pursuiing this.
<br><br>... and investigation of internationalization would be a nice thing.
<br><div class='shrinkable-quote'><br>> Move towards unified L&F and extended branding support
<br>> ------------------------------------------------------
<br>>
<br>> Key: FELIX-1959
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1959" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1959</a><br>> Project: Felix
<br>> Issue Type: New Feature
<br>> Components: Web Console
<br>> Reporter: Valentin Valchev
<br>> Assignee: Carsten Ziegeler
<br>> Priority: Minor
<br>> Attachments: jqueryui-vs-default-lnf.png, tb6.jar
<br>>
<br>>
<br>> Currently the Web Console uses heavily on the JQuery framework. Using a unified JavaScript framework simplifies development of all plugins and unifies the used approach.
<br>> However, when talking about visual styling, there are number of differences because each plugin developer uses own styles.
<br>> My suggestion is to adopt the JQuery UI . The benefits of using it as unified widget/css framework are:
<br>> - no time to spend on writing widgets already in the library
<br>> - clean CSS visual styling
<br>> - easy way to change the L&F by changing the theme (extended branding support!)
<br>> - improved cross-browser support (JQuery UI takes care of CSS differences)
<br>> Using the JQuery UI framework the developer shouldn't care about color but only for layout - components position; and for data being displayed.
<br>> To illustrate the benefits I've saved the "Log Service" page, modified it to use JQuery UI, took screen-shot, modified the theme CSS only, and again took screen-shot, and finally added the original L&F for reference, so you can easily compare the result.
<br>> The attached image contains the combined screen-shots.
<br>> "
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>tag:old.nabble.com,2006:post-26890560[jira] Commented: (FELIX-1792) Felix OBR seems to just randomly choose one of the satisifed bundles if more than one bundle meets the requirement2009-12-22T08:08:29Z2009-12-22T08:08:29ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/FELIX-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793654#action_12793654" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793654#action_12793654</a> ]
<br><br>Richard S. Hall commented on FELIX-1792:
<br>----------------------------------------
<br><br>What is "in eba" mean?
<br><br>Could you give me a simplified example of the bundle manifests and a description of the steps needed to reproduce the issue? If so, I will look into it.
<br><div class='shrinkable-quote'><br>> Felix OBR seems to just randomly choose one of the satisifed bundles if more than one bundle meets the requirement
<br>> ------------------------------------------------------------------------------------------------------------------
<br>>
<br>> Key: FELIX-1792
<br>> URL: <a href="https://issues.apache.org/jira/browse/FELIX-1792" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/FELIX-1792</a><br>> Project: Felix
<br>> Issue Type: Bug
<br>> Components: Bundle Repository (OBR)
<br>> Affects Versions: bundlerepository-1.4.2
<br>> Environment: n/a
<br>> Reporter: david small99
<br>> Assignee: Richard S. Hall
<br>> Fix For: bundlerepository-1.6.0
<br>>
<br>>
<br>> I have one bundle bundle1, which imports a package called com.obr.bundle
<br>> Bundle1's manifest:
<br>> Manifest-Version: 1.0
<br>> Ant-Version: Apache Ant 1.7.0
<br>> Bundle-ManifestVersion: 2
<br>> Bundle-Name: Bundle Plug-in
<br>> Bundle-SymbolicName: com.obr.bundle1
<br>> Bundle-Version: 1.0.0
<br>> Export-Package: com.obr.bundle1
<br>> Import-Package: com.obr.bundle;version="[1.2.0.999,3.2.2.bz]"
<br>> There are two bundles in my repositories, bundler2 and bundle 3. Both of them export package com.obr.bundle. Below are their manifest files.
<br>> Bundle2
<br>> Manifest-Version: 1.0
<br>> Ant-Version: Apache Ant 1.7.0
<br>> Bundle-ManifestVersion: 2
<br>> Bundle-Name: Bundle Plug-in
<br>> Bundle-SymbolicName: com.obr.bundle2
<br>> Bundle-Version: 1.0.0
<br>> Bundle-Vendor: xxx
<br>> Import-Package: a.b.c
<br>> Export-Package: com.obr.bundle;version=3.2.2.blah
<br>> Bundle3:
<br>> Manifest-Version: 1.0
<br>> Ant-Version: Apache Ant 1.7.0
<br>> Bundle-ManifestVersion: 2
<br>> Bundle-Name: Bundle Plug-in
<br>> Bundle-SymbolicName: com.obr.bundle3
<br>> Bundle-Version: 1.0.0
<br>> Import-Package: a.b.c
<br>> Export-Package: com.obr.bundle;version=3.1
<br>> As you can see, both bundle2 and bundle3 meet the requirements of bundle1. I hope the highest package version, which is bundle2, is chosen by felix obr. However, sometimes bundle 3 was chosen instead of bundle2. The behaviour is random.
<br>> Am I right to say that the Felix obr runtime just picks the first bundle that meets the requirements and then stop searching for any more eligible bundles?
<br>> Thanks
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/Apache-Felix---Dev-f28136.html" embed="fixTarget[28136]" target="_top" >Apache Felix - Dev</a></p>