NH> It says that "If the Http Service does not have its port values configured
NH> through some other means, the Http Service implementation should use the
NH> following properties to determine the port values upon which to listen".
NH> Ok, pretty vague IMHO, but nevertheless...
Well, on purpose ... Jetty will require considerable different
configuration than a simple tiny webserver. Trying to standardize this
would be horrible, and we would likely get a lot of complaints because
we do not support feature x.
The goal of the OSGi specs is to allow the creation of bundles that
interoperate. By not trying to specify runtime and configuration
details I think we allow maximum freedom.
NH> My question is; Is any amount of elaborate configuration schemes considered
NH> Ok, and hence one can ignore the properties?? For instance; some dedicated
NH> set of bundles using some means to determine these ports.
NH> Does that mean the TCK does not test for this at all?
It actually uses the properties to figure out where the darned http
server is (and in the default setup we set it), but there should not
be a test for it, and as far as I know there is not.
NH> Should the language change from SHOULD to MUST, and some constraints on
NH> what "other means" mean, in some future revision?
I do not think so, configuration is clearly in the realm of the
implementation.
Though it would be nice to find out in runtime what
port/host/interface was configured in a standard way.
Kind regards,
Peter Kriens
NH> Cheers
NH> Niclas
NH> _______________________________________________
NH> OSGi Developer Mail List
NH> [email protected]
NH> http://www2.osgi.org/mailman/listinfo/osgi-dev
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
