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
>