On Apr 22, 2009, at 6:16 AM, Sahoo wrote:
> In this case, user was not trying any j2ee application. It was a
> plain OSGi bundle and what I gathered was deploy command was not
> starting the bundle, so I suggested the alternative.
I understand that, all I am saying is that it eventually can become
confusing to people about what's the best way of deploying their
applications wether or not they are pure OSGi, pure JavaEE or a mix.
>
> Secondly, when we have our deployment code ready for OSGi/javaee
> apps, it will automatically work for bundles started via fileinstall
> or via deploy command, as I am assuming we shall implement some kind
> of extender pattern to achieve this.
>
maybe, maybe not. Until we have made enough experimentation, it's
dangerous to assume it will necessarily work especially for components
like JPA that requires two different classloaders for a single bundle.
I like the autodeploy-modules features, I am not sure we can safely
assume that we will be always capable of implementing it using the
file-install or achieve Java EE deployment through an extender pattern.
Jerome
> Thanks,
> Sahoo
>
> Jerome Dochez wrote:
>> I don't think we should advocate the use of the felix file install
>> for application deployment as it will not work well with OSGi
>> enabled Java EE applications unless we hook up our deployment
>> backend to module installation etc... which we are not planning to
>> do anytime soon.
>>
>> we should have a "autodeploy" like feature implemented on top of
>> the ${com.sun.aas.instanceRoot}/autodeploy-modules so that it still
>> goes through the application server deployment infrastructure.
>> Until that is done, I think we should not advocate the current usage.
>>
>> jerome
>>
>> On Apr 21, 2009, at 12:13 PM, Sahoo wrote:
>>
>>> glassfish_at_javadesktop.org wrote:
>>>>> On Apr 20, 2009, at 1:59 PM,
>>>>> glassfish_at_javadesktop.org wrote:
>>>>>
>>>>>
>>>>>> Hi Jerome,
>>>>>>
>>>>>> deploying osgi bundles is no problem. I got
>>>>>>
>>>>> problems while deploying
>>>>>> osgi bundles with declared services
>>>>>>
>>>>> (http://felix.apache.org/site/apache-felix-service-com
>>>>> ponent-runtime.html
>>>>>> ). Important there is that i define an
>>>>>>
>>>>> Service-Component entry in
>>>>>> Manifest.MF which reference an xml file. This xml
>>>>>>
>>>>> file contains my
>>>>>> service declaration (like hk2 @Service annotation
>>>>>>
>>>>> but an xml file).
>>>>>
>>>>>> By the way i deploy my bundles by hand, just
>>>>>>
>>>>> copying them into the
>>>>>> modules folder.
>>>>>>
>>>>>>
>>>>> if you do that, the bundles are not started
>>>>> automatically which may explain why your services are not
>>>>> started.
>>>>>
>>>>
>>>> i now use the asadmin deploy command via maven exec. This
>>>> approach is very nice but doesn't solve my problem. The Service
>>>> is not visible nor initiated.
>>>>
>>>> I currently user bundlecontext.getServiceReference(String
>>>> serviceInterface);
>>>>
>>>> should i use an different approach?
>>>>
>>>>
>>> You can also use felix fileinstall bundle which is part of GFv3 to
>>> deploy your bundle. You can do something like this:
>>> Create a file called org.apache.felix.fileinstall-autodeploy-
>>> modules.cfg in glassfish/modules dir. Let it contain following
>>> properties:
>>> felix.fileinstall.dir=${com.sun.aas.instanceRoot}/autodeploy-
>>> modules/
>>> felix.fileinstall.poll=5000
>>> felix.fileinstall.debug=1
>>> felix.fileinstall.bundles.new.start=true
>>>
>>> Now, fileinstall will create domains/domain1/autodeploy-modules
>>> dir for you. Drop your bundle into that dir.
>>>
>>> Sahoo
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>