On 5/21/10 9:53, Sanjeeb Sahoo wrote:
> Rickard Öberg wrote:
>> Hi!
>>
>> On 2010-05-21 14.39, Sanjeeb Sahoo wrote:
>>> I acknowledge absence of proper documentation about OSGi features in
>>> GlassFish. I don't see our docs to change either before 3.1 release, so
>>> in the mean while, I have created a Wiki page [1] to capture whatever
>>> information available. Take a look at it and send your comments.
>>> Keep in
>>> mind that I have just recently created the page, so it does not have
>>> all
>>> the info I want it to have. I certainly want to add an FAQ and some
>>> documentation in the form of a guide.
>>
>> Ok, cool, thanks!
>>
>> And just to let you know, the OSGi features are absolutely awesome,
>> even if undocumented. That I could take my WAR file and just drop it
>> into autodeploy, have it deployed, and then look up other bundles to
>> do the actual work, is amazing. I love it!
> Glad to know this.
>>
>>> Coming back to use of OBR, it is one of the things we would like to
>>> have
>>> a better story about in 3.1 release. /Can you please tell us what kind
>>> of OBR related feature you are looking for in glassfish? /
>>
>> The main issue I'm seeing is that although I barely started I already
>> have 5 bundles, and that's only because I'm cheating and put all of
>> my dependencies (30+ libraries) into one bundle. If I were to do this
>> "properly" the number of bundles would explode.
>>
>> For myself I can copy/paste jar files into /autodeploy. But how do I
>> install this in a customers production environment? Even worse, how
>> do I do upgrades, where I need to put in new bundles and remove the
>> old ones? It seems like it can easily become a mess. Especially
>> considering that /autodeploy contains both my own bundles as well as
>> 3rd party bundles that plugin to my application, so I can't just wipe
>> /autodeploy when a new version comes along.
>>
>> This is the problem I'm facing, and can't find a good answer to it.
>> In the old model I put all my stuff into one war file, and
>> installing/upgrading that was easy. How do I do it when my app is
>> splashed out into lots of bundles? Any ideas from the real world are
>> welcome! (And no, clever use of the shell is not practical)
>>
> If you think having a separate autodeploy directory for your app is
> going make things easier, then that's very easy to setup. I recently
> answered a user's query in this forum with the steps to do it. In
> fact, you can have as many such directories as you like. The steps to
> do it would be to add a simple one line config file. Just browse the
> forum for last one week, you will find the steps to do it.
>>> To use OBR in current glassfish, please download and install OBR
>>> bundles:
>>>
>>> cd .../glassfish/domains/domain1/autodeploy/bundles/
>>> wget
>>> http://www.reverse.net/pub/apache/felix/org.osgi.service.obr-1.0.2.jar
>>> wget
>>> http://www.reverse.net/pub/apache/felix/org.apache.felix.bundlerepository-1.6.2.jar
>>>
>>
>> Cool, I'll try it out!
>>
>>> I am assuming you have your own repo which you add using "obr add-url"
>>> command.
>>
>> So, what would be most interesting is if I can tell customers to
>> install Glassfish, and then use the above to get the actual
>> application. That seems to work for installation, but what about
>> upgrades? How does "old" bundles get removed?
> I am not an OBR expert. I am hoping Richard Hall would step in and
> provide some tips here.
Keep in mind, OBR is not a full provisioning system and you will likely
need to implement something yourself or use another system on top of
OBR, like Apache Ace.
However, for simple updates, OBR does allow you to deploy newer versions
and it will attempt to update corresponding bundles as necessary. So,
for example, if you have foo v1 deployed and ask OBR to deploy foo v2,
it should attempt to upgrade the existing bundle if possible.
-> richard
>>
>> Is anyone using this stuff *in production* yet, with these kinds of
>> issues coming up, or is it pilot/development mode only for most people?
> I am not sure if anyone has started to use it in production yet. I
> know some are using it though.
>
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>