Property files and property names and duplicate properties.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Property files and property names and duplicate properties.

Rod Widdowson
I think I know what the answer here is ("it sucks being you"), but I thought I'd check.

As background, during the review of the Jetty 9.4 jetty-base stuff on Friday we decided that for our own sanity we would need to
develop property name renaming technology so we can track the (often arbitrary) names changes that Jetty impose between releases.
So if in 9.4.1 it was "jetty.ssl.port" and in 9.4.2 it became "jetty.tls.port" we could deal with this on behalf of our end users
(who use our Jetty installation precisely so they don't have to worry about this sort of nonsense).

It turns out that this has some definite advantages for our packaging both in 3.4 and looking forward to 4.0.

So, being me, as I started coding this up I considered all the screw cases and hit upon this one.  

The customer's property file is:

        my.property.one=foo
        my.property.two=bar

And for some reason it is decided to rename both of these properties to my.property.three.  We obviously end up with a clash and
badness could occur.

The "Obvious" fix is to check for property duplication as we are doing the rename.  But then we would warn (or, perhaps better,
fail) the install if someone already had a duplicate.

OTOH, that might be a useful feature anyway.  If someone has a duplicate this is badness and having it detected during upgrade would
be useful - if not bullet proof with the IdP property files which are nested.

I should close by saying that this really is an edge condition in 3.4 and the badness is limited to already broken installs.  There
are only a handful of properties and we can pretty much guarantee that the names will never collapse.  So the only issue would be if
someone had managed to add a property with a new (about to be valid) name but an invalid value to the end of the property file.

        jetty.ssl.port=8443
        jetty.tls.port=8442  // Pointless property until V3.4

        .....And we rename jetty.ssl.port to jetty.tls.port.

Since adding "jetty.tls.port" would be considered as breaking the install (the file says not to do that) we could default to a "we
told you not to do that" answer.

It may become more of an issue in V4 when there may more property renaming going on.

If anyone has any thoughts on this I'd be glad to hear them.

Ugh!

Rod

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Property files and property names and duplicate properties.

Cantor, Scott E.
> I should close by saying that this really is an edge condition in 3.4 and the
> badness is limited to already broken installs.  There are only a handful of
> properties and we can pretty much guarantee that the names will never
> collapse.  So the only issue would be if someone had managed to add a
> property with a new (about to be valid) name but an invalid value to the end of
> the property file.

Yeah, I think it assumes a case where two separate older versions of a given property appear. I would think warning and failing are reasonable.

Maybe it's simpler to just implement a pre-check that checks for mutually exclusive attributes up front.
 
-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Property files and property names and duplicate properties.

Rod Widdowson
>
> Maybe it's simpler to just implement a pre-check that checks for mutually exclusive attributes up front.
>

This actually leads into another topic I am mulling (but with no conclusion yet) for V4.  

It is very hard to get sensible warning up to the user during installs, particularly windows users.  

If the installer is using ant we can spit out something terse to stdout and stop, and we can even pop something into a log so that’s
largely OK.

On Windows however the guts of the install is still done by ant but it's in a detached process running Java, what's more it happens
after the UI has completed all interaction.    So currently the best you can do is arrange for the install to fail with an opaque
warning and hope that the user thinks to try again with a log file and can then thumb through several kb of garbage to locate the
error.

So I tend to avoid getting into the position of having to fail or warn.

It is not difficult to write plugins for MSI which can do things - I have never done so, but I have maintained them (.... aeons ago
[1]).  Of course they are written in something which is not Java.  And I am not keen in having rafts of specialized C/C++ in a side
project just to support the msi.  It will rot sure as eggs is eggs.  

I think that VBScript will be very brittle, but maybe that is something to look at.

But I also wonder whether - in the longer term - there might be a way to call through MSI into java and back.  We'd still have the
DLLs but they could be written once and not change much since all they did was bridge in and out of java.  The work could be done in
java, using our full environment.

I'm pretty sure that this is a sucky idea - if Scott hadn't mentioned "warning during the install" twice in less than a week I
wouldn't have mentioned it...

R

[1] http://git.openafs.org/?p=openafs.git;a=tree;f=src/WINNT/install/wix/custom;h=02d34d8fc423c851c187603626b9db0350f8b68e;hb=HEAD

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Property files and property names and duplicate properties.

Cantor, Scott E.
> It is very hard to get sensible warning up to the user during installs, particularly
> windows users.

Same problem with RPM, it's common to a lot of this stuff, you just don't have the ability to fail installs easily. I imagine the path of least resistance for something this rare is just create a log of problems, have a rule for which value we take, and move on.

> I think that VBScript will be very brittle, but maybe that is something to look at.

It probably wouldn't be that bad to just have to scan for some strings in a file, I suppose.

> But I also wonder whether - in the longer term - there might be a way to call
> through MSI into java and back.  We'd still have the DLLs but they could be
> written once and not change much since all they did was bridge in and out of
> java.  The work could be done in java, using our full environment.

That doesn't appeal to me.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]