Mailing-List: contact users-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of heavy@ungoverned.org
 designates 67.222.39.38 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=ungoverned.org;
	h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User;
	b=wZwe4DuQfQ31AW/pVCXbmrNMmpRGSJGm61QNcj9ECdRufzdx2SkRYVzwuD+NvnKQvVA5vkosvucMHuX6OrXk2yth8M33G99DJ8rh4TNcl0hz0fP1kQftMU/qG34t+5ji;
Message-ID: <4BB9DBC0.2090608@ungoverned.org>
Date: Mon, 05 Apr 2010 08:46:56 -0400
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: users@felix.apache.org
Subject: Re: Embedding felix - will this approach work?
References: <k2w7aa9fe391004040334u25f94c17ib3bf5b7eb98505b6@mail.gmail.com>
	 <4BB88E9E.2050106@ungoverned.org>
 <z2h7aa9fe391004042203gdcd866d2te5b74057a9160470@mail.gmail.com>
In-Reply-To: <z2h7aa9fe391004042203gdcd866d2te5b74057a9160470@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 4/5/10 1:03, Mike Haney wrote:
> Thanks Richard for your quick response.
>
> Since you are an "internals" guy, could I get your opinion on something
> else?  Felix seems to be pretty lightweight as far as the base framework
> goes.  I'm thinking about embedding several instances of the framework, to
> break up the work along layer boundaries and provide a better separation of
> concerns.  I would probably be looking at 4-5 instances embedded in my app.
> Does this sound feasible without putting undue memory constraints on the
> application?  We all know how Java apps can be very memory hungry in
> production environments, and I don't want to make the problem worse.
>    

Well, clearly five instances will be worse than one, but I don't think 
this should be a significant burden. The overhead for data structures 
for holding bundle info shouldn't be much different whether the bundles 
are installed into one or N frameworks, but there will be some extra 
overhead for framework-related info.

However, we do try to share across instances where possible (e.g., the 
event dispatching thread, but we don't currently share all threads). If 
you run into any issues, definitely let us know, but other people have 
certainly used the Felix framework this way.

-> richard

> On Sun, Apr 4, 2010 at 8:05 AM, Richard S. Hall<heavy@ungoverned.org>wrote:
>
>    
>> On 4/4/10 6:34, Mike Haney wrote:
>>
>>      
>>> Brief history - we initially wrote this app last year as pure OSGi running
>>> on Spring DM Server.  For a variety of reasons, that didn't work for us,
>>> and
>>> we ended up refactoring into a monolithic web app in a single WAR file.
>>>   We
>>> kept the modularity mostly intact, knowing we needed to go back to a
>>> plug-in
>>> based model in the near future - basically we are using our spring
>>> application context as a surrogate for the service registry.
>>>
>>> Now it's time to add the plugin capabilities back in, and our goal is to
>>> keep 70% of the functionality in the main web app itself, and just use
>>> OSGi
>>> to manage plugins for customizing and extending this app.  I've been
>>> reading
>>> the page on embedding and playing with a sample project, and so far so
>>> good.  Now the tricky part is how to deal with 3rd party libraries used
>>> both
>>> within the webapp and within the OSGi environment.  Here's where I need to
>>> verify my approach before I dive into the abyss.
>>>
>>> As a simple, concrete example, we want to be able to contribute Wicket
>>> components as plugins (this is just one of many plugin areas depending on
>>> 3rd party libraries - Drools and Hibernate are 2 other biggies).  Since
>>> the
>>> wicket jars already exist on the web application classpath, it looks like
>>> I
>>> should be able to just pass all the wicket packages (along with any
>>> transitive dependencies) to Felix using the
>>> org.osgi.framework.system.packages.extra property.  My understanding is
>>> this
>>> will make all those packages available as part of the system bundle, which
>>> conceptually seems like the same thing many frameworks like DM Server do
>>> for
>>> things like the servlet api, spring, etc.  Am I on the right track here?
>>>
>>>
>>>        
>> Sounds like it.
>>
>>
>> A few specific questions:
>>      
>>> 1) What kind of classpath issues would I need to be aware of using this
>>> approach.
>>>
>>>
>>>        
>> As long as the class loader that loads the framework classes has access to
>> the packages you want to provide, then it should work.
>>
>>
>> 2) Will the system.packages.extra property take wildcards in the value,
>>      
>>> similar to a manifest import-package statement?  IOW, can I just list
>>> "org.apache.wicket.*", or do I have to list out every single package in
>>> wicket?  Also, can I specify versions on these packages like in a
>>> manifest?
>>>
>>>
>>>        
>> Neither Import-Package, nor system.packages.extra support wildcards. You
>> have to specify them all. The same syntax for Import-Package is used, so you
>> can specify versions.
>>
>>
>> 3) I've already separated out our application-specific interfaces into a
>>      
>>> separate bundle, which is included in both the main web app and the bundle
>>> dependencies.  I assume this is the correct approach, based on my reading.
>>>
>>>
>>>        
>> Sounds like it.
>>
>>
>> 4) What about build-time dependencies on 3rd party jars like wicket within
>>      
>>> the bundles themselves?  It seems like it should be sufficient to just
>>> include the wicket, etc. dependencies in the pom so it can compile against
>>> those classes, but at runtime they will actually be resolved through the
>>> system bundle.  Any problems with that, or should I create another bundle
>>> used just for building that exports all of the 3rd party interfaces (i.e.
>>> with a proper OSGi manifest)?
>>>
>>>
>>>        
>> I don't think that is necessary. You could get some benefits if you had a
>> regular bundle and you are using maven-bundle-plugin or BND to generate your
>> bundles, since it will include proper versions for your bundle imports.
>> Also, if there are some packages you do not want your bundles to have access
>> to, then you could exclude them from the exports of your libraries, but
>> otherwise it probably doesn't really matter.
>>
>>
>> 5) The other big hiccup I can see is debugging in Eclipse.  Debugging the
>>      
>>> main webapp on Tomcat is a no brainer, but I'm trying to figure out the
>>> best
>>> method to drop the plugins into our debugged instance of Tomcat, short of
>>> having to do a Maven build each time, then copy the plugins to an
>>> autodeploy
>>> directory.  Any suggestions for streamlining this process?  I think Pax
>>> had
>>> a project that let you deploy bundles from an exploded directory instead
>>> of
>>> a jar, but I think it relied on the PaxRunner stuff to work.  Anything
>>> else
>>> similar to this?  If I could just point our embedded Felix instance at our
>>> source directory, that would save a lot of time.
>>>
>>>
>>>        
>> I am not sure the best way to streamline this. The Felix framework supports
>> installing an exploded bundle directory, but you'd still need to manually
>> perform an update inside the framework once the contents changed. Maybe
>> someone has created something to automate that as part of the build process.
>>
>> I admit to not having a lot of practical experience with bundle projects,
>> since I spend most of my time hacking on low-level framework issues, so
>> maybe someone else has better advice on all of these issues.
>>
>> ->  richard
>>
>>
>> Thanks in advance for any advice.
>>      
>>> Mike
>>>
>>>
>>>
>>>        
>>   ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>      
>    

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org