The question was different. Can Felix's logger be configured via JDK
logging.properties file? AFAIK, it can't be.
Thanks,
Sahoo
Richard S. Hall wrote:
> One thing to keep in mind, Felix itself does not look at system
> properties at all. As a convenience, Felix' launcher will copy
> configuration properties specified as system properties into the
> property map passed into Felix' constructor, but Felix will never look
> at system properties for its own configuration (except for some
> JRE-specified properties).
>
> Bundles, on the other hand, can get their configuration data from
> system properties, because the spec states that Bundle.getProperty()
> must be backed by system properties.
>
> So, in short, for any value used to configure the framework, we need
> it put into the property map passed into Felix' constructor. For
> bundles, it can work either way.
>
> As long as we are using Felix' launcher, system properties will work
> because it copies system properties as mentioned above. In the future,
> if we decide to create a dedicated OSGi launcher using the new
> standard API, then we are free to define things pretty much how we
> want, but the standard is still similar to Felix' current approach,
> which is ultimately framework configuration properties must be somehow
> passed into the framework's constructor.
>
> This includes the log level property.
>
> Whew. Sorry for the long answer.
>
> -> richard
>
> On 3/19/09 3:38 PM, 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.
>>
>> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>