Kane,
Thanks for getting back.
Currently, there is no provision to pass a domain.xml file. You can only
point the server to a domain directory of choice. So, I see two options
here:
Copy your custom domain.xml to ${com.sun.aas.instanceRoot}/config/domain.xml
or
Set com.sun.aas.instanceRoot to your custom domain directory.
In future, we shall allow user to pass in a custom domain.xml. Hope the
current limitations are not stoppers for you.
Thanks,
Sahoo
On Thursday 10 February 2011 05:28 PM, Michael Hollatz wrote:
> Hi Sahoo,
>
> just wanted to report back that it really works fine. However, we need
> the ability to configure a lot of stuff for the various components we
> want to test separately.
>
> So, besides the properties "com.sun.aas.installRoot" and
> "com.sun.aas.instanceRoot" can we also just a path to a specifc
> domain.xml? And are there other properties available that might be of
> interest here?
>
>
> Thanx,
>
> Kane
>
>
>
> On 02/09/2011 04:20 PM, Michael Hollatz wrote:
>> Hi Sahoo,
>>
>> Nice one with the file://... approach. I'll test that.
>>
>> Really sad for the embedded jar part, but I guess it'll be even better
>> if we stay as close as possible to a real environment, just to be sure.
>>
>>
>> Thanks a lot and I'll report back,
>>
>> Kane
>>
>>
>> On 02/09/2011 04:12 PM, Sahoo wrote:
>>> Hi Kane,
>>>
>>> Well, I failed to convince our embedded engineers to add support for
>>> OSGi in the all-in-one uber jar. In 3.1, they started with the goal of
>>> having a single bundle distribution that could be activated inside an
>>> OSGi framework which would then install and activate the rest of the
>>> bundles, but they had to drop that because of lack of
>>> time/motivation(?).
>>>
>>> The only extra step needed now is to have a glassfish installation.
>>> Does
>>> it truly make it so much worse? I didn't mention one more thing in my
>>> last email. If you install glassfish.jar with a location URL like
>>> file:/<full path to glassfish.jar>, then there is no need to set those
>>> two properties, as the bundle activator can deduce the installRoot and
>>> instanceRoot from the location URL itself.
>>>
>>> Secondly, when you embed using the technique I mentioned in my previous
>>> email, what you get is close to what happens when GlassFish runs in
>>> non-embedded mode, so I would be very surprised if the runtime behaves
>>> any differently.
>>>
>>> Once you have embedded, you can actually get hold of the GlassFish
>>> service using ServiceTracker or BundleContext.getService(), which
>>> implements org.glassfish.embeddable.GlassFish interface [1] and from
>>> there on use that object. glassfish.jar bundle exports the embeddable
>>> api package as well.
>>>
>>> Sahoo
>>>
>>> [1]
>>> http://embedded-glassfish.java.net/nonav/apidocs/org/glassfish/embeddable/GlassFish.html
>>>
>>>
>>>
>>>
>>>
>>> On Wednesday 09 February 2011 08:09 PM, Michael Hollatz wrote:
>>>> Hi Sahoo,
>>>>
>>>> thanx for that info. I'll give it a try.
>>>>
>>>> However, I think for most developers it would be even easier to use
>>>> the embedded version but as it doesn't come as an OSGi bundle itslef I
>>>> wondered if that is even supported?
>>>>
>>>> Thanx,
>>>>
>>>> Kane
>>>>
>>>> On 02/09/2011 03:24 PM, Sahoo wrote:
>>>>> Hi Kane,
>>>>>
>>>>> Yes, that blog is indeed dated. It is even simpler to embed
>>>>> GlassFish in
>>>>> an OSGi runtime. No need to write any code. You just have to install
>>>>> and
>>>>> start glassfish/modules/glassfish.jar bundle. Just set the following
>>>>> properties in your OSGi environment:
>>>>> com.sun.aas.installRoot=<full path to your glassfish3/glassfish/>
>>>>> com.sun.ass.instanceRoot=<full path to your domain directory>
>>>>>
>>>>> Let us know your experience.
>>>>>
>>>>> Thanks,
>>>>> Sahoo
>>>>>
>>>>> On Wednesday 09 February 2011 05:55 PM, Michael Hollatz wrote:
>>>>>> Hi *,
>>>>>>
>>>>>> I know you all are busy with the RC's and bug fixing but I have a
>>>>>> "simple" question:
>>>>>>
>>>>>> How are we supposed to use the embedded GF within an OSGi
>>>>>> environment?
>>>>>>
>>>>>> So we have some applications composed of OSGi Bundles and they also
>>>>>> use the JavaEE/OSGi integration provided by GlassFish 3.1. In
>>>>>> order to
>>>>>> implement component/module tests I was thinking about using the
>>>>>> glassfish-embedded-all to accomplish that but I want to make sure if
>>>>>> it is confirmed (or proposed) to work or, if not, what other options
>>>>>> you would recommend me to try.
>>>>>>
>>>>>> Thanx for any hint/information/links.
>>>>>>
>>>>>> Kane
>>>>>>
>>>>>> P.S.: I've already tried the approach that Sahoo described once
>>>>>> here:
>>>>>> http://weblogs.java.net/blog/ss141213/archive/2010/02/14/how-embed-glassfish-existing-osgi-runtime
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> This one is a bit dated and trying that one with a recent promoted
>>>>>> build lets the main glassfish-core bundle fail to start.
>>>>>
>>>>
>>>
>>
>