Yes, there are other configurations as well. e.g., list of bundles to be
started automatically, port number for Felix remote shell, etc. I am
also not sure if JDK logging.properties file can be used to control
felix's log level. Richard, can you clarify?
No, I can't use @Configured, because this code runs outside of HK2 or
OSGi environment. It runs as part of ASMain before launching the OSGi
framework.
Sahoo
Kedar Mhaswade wrote:
> Uh oh!
>
> You should move it to logging.properties instead. The domain.xml
> log-service element is deprecated (read: effectively removed).
>
> Is there other configuration that you want to move into it?
> Have you considered creating an @Configured interface for your
> configuration?
>
> -Kedar
>
> Sahoo wrote:
>> Jerome,
>>
>> I want to move some of the Felix configuration stuff (which are
>> mostly system properties) to domain.xml. e.g., Felix log level.
>>
>> Thanks,
>> Sahoo
>>
>> Jerome Dochez wrote:
>>> domain.xml parsing in start-domain is not using the config-api
>>> module, it's using a mini xml parser which allow to only parse the
>>> required information like jvm parameters without constructing a full
>>> configuration tree like the full glassfish process does. And this is
>>> not a challenge, this is by design that all the modules except for
>>> hk2 and glassfish.jar are loaded by OSGi.
>>>
>>> All glassfish modules can be loaded statically (hence the static
>>> mode) but I don't think it's a good idea we start loading some
>>> glassfish modules through the application class loader and some
>>> others through OSGi. Can you clarify what you are trying to do.
>>>
>>> Jerome
>>>
>>> On Mar 19, 2009, at 12:03 PM, Sahoo wrote:
>>>
>>>> domain.xml is parsed by asadmin start-domain command, which runs as
>>>> a plain old Java program, so I would expect all the implementation
>>>> challenges to have been overcome by now.
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>> Jerome Dochez wrote:
>>>>> this has not changed recently and it would be very difficult to
>>>>> parse domain.xml before starting OSGi as it would require starting
>>>>> the kernel (probably could be avoided with some work) and
>>>>> config-api and all other imported modules as plain old jar files.
>>>>>
>>>>> jerome
>>>>>
>>>>> On Mar 19, 2009, at 11:31 AM, Sahoo wrote:
>>>>>
>>>>>> I used to think that we were parsing domain.xml somewhere in
>>>>>> ASMain and hence I would be able to move some of the OSGi
>>>>>> configuration stuff to domain.xml. But, I see we don't parse
>>>>>> domain.xml before starting the server bundles. Is this a recent
>>>>>> change or has it been like this from beginning? Can we parse
>>>>>> domain.xml before starting the OSGi framework?
>>>>>>
>>>>>> Thanks,
>>>>>> Sahoo
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>