On 3/19/09 4:57 PM, Sahoo wrote:
> The question was different. Can Felix's logger be configured via JDK
> logging.properties file? AFAIK, it can't be.
Well, I thought I answered it. :-)
Felix only looks for config properties in the map passed into its
constructor. So, the answer is, "no".
Unless the logging.properties file happens to be copied to system
properties by the JRE...
-> richard
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>