Sahoo wrote:
> 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.
Hmm. It is best to leave such configuration out of domain.xml then.
Anything that goes to domain.xml should have a backing @Configured
(e.g. http-service -> com.sun.enterprise.config.serverbeans.HttpService)
in some module. Remember, administration depends on these interfaces
in order to expose it uniformly via admin interfaces.
The downside is you'll have to build management of this separate configuration.
So, I think this is a hard problem to solve if this configuration
can not leverage @Configured :(
-Kedar
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>