Discussion:
[jitsi-users] jitsi-defaults.properties, jitsi-default-overrides.properties
Daniel Pocock
2014-07-24 07:04:48 UTC
Permalink
Can anybody comment on the intended lifecycle for
jitsi-defaults.properties and jitsi-default-overrides.properties?

Are they supposed to be in a JAR or just on the filesystem so they can
be tweaked by a sysadmin at runtime?

It appears they are not copied into any of the JARs created by the web
start build.xml, should they be in configs.jar?

I notice this in the build.xml:

<jar destfile="${release.dir}/lib/configs.jar">
<manifest>
<attribute name="Application-Name"
value="Jitsi"/>
<attribute name="Permissions"
value="all-permissions"/>
<attribute name="Codebase" value="*"/>
</manifest>
<fileset dir="${sc.basedir}/resources/install">
<include name="logging.properties" />
</fileset>
<fileset dir="${tmp.dir}">
<include name="*.properties" />
</fileset>
</jar>



Does that mean that somebody wanting to override these things has to
manually copy their file to ${tmp.dir} before building? Or this is just
something that should happen automatically but was overlooked?
Ingo Bauersachs
2014-07-24 08:11:10 UTC
Permalink
These files were introduced long after I created the WebStart launcher, so it's just something that needs to be added to the build.

In the desktop version, jitsi-defaults is updated by the installer and could be overwritten by a newer version, while jitsi-default-overrides is meant for an admin to override the defaults and should not be touched by an installer.

Both are loaded as a resource from the classpath, which is why they reside in the lib-directory. So no need to put them in any jar. They can be tweaked by a sysadmin, although not at runtime - a restart of Jitsi is necessary.

The configs.jar you mention below is something else, although I can't quite remember what that was. I think we (at the Uni project where the WebStart comes from) had some additional stuff for our proprietary plugin in there.

HTH,
Ingo

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile
Post by Daniel Pocock
Can anybody comment on the intended lifecycle for
jitsi-defaults.properties and jitsi-default-overrides.properties?
Are they supposed to be in a JAR or just on the filesystem so they can
be tweaked by a sysadmin at runtime?
It appears they are not copied into any of the JARs created by the web
start build.xml, should they be in configs.jar?
<jar destfile="${release.dir}/lib/configs.jar">
<manifest>
<attribute name="Application-Name"
value="Jitsi"/>
<attribute name="Permissions"
value="all-permissions"/>
<attribute name="Codebase" value="*"/>
</manifest>
<fileset dir="${sc.basedir}/resources/install">
<include name="logging.properties" />
</fileset>
<fileset dir="${tmp.dir}">
<include name="*.properties" />
</fileset>
</jar>
Does that mean that somebody wanting to override these things has to
manually copy their file to ${tmp.dir} before building? Or this is just
something that should happen automatically but was overlooked?
_______________________________________________
users mailing list
http://lists.jitsi.org/mailman/listinfo/users
Daniel Pocock
2014-07-24 08:30:21 UTC
Permalink
Post by Ingo Bauersachs
These files were introduced long after I created the WebStart launcher, so it's just something that needs to be added to the build.
Which JAR do you think I should add them to?
Post by Ingo Bauersachs
In the desktop version, jitsi-defaults is updated by the installer and could be overwritten by a newer version, while jitsi-default-overrides is meant for an admin to override the defaults and should not be touched by an installer.
Ok, so jitsi-defaults.properties could live happily in a JAR but
jitsi-default-overrides:

a) for standalone deployments, it could be in /etc/jitsi and that
directory could be added to the classpath

b) for JNLP deployment, it would probably have to be in a JAR too so it
doesn't make much difference whether somebody deploying this way puts
their changes in jitsi-defaults.properties or the overrides file because
both have to come from a JAR anyway
Post by Ingo Bauersachs
Both are loaded as a resource from the classpath, which is why they reside in the lib-directory. So no need to put them in any jar. They can be tweaked by a sysadmin, although not at runtime - a restart of Jitsi is necessary.
It looks like apps launched by WebStart need to use a different method
to load these properties:
https://community.oracle.com/thread/1308233?start=0&tstart=0

I'll try and make a patch for this. Could there be other things in
Jitsi that are impacted too?
Post by Ingo Bauersachs
The configs.jar you mention below is something else, although I can't quite remember what that was. I think we (at the Uni project where the WebStart comes from) had some additional stuff for our proprietary plugin in there.
Here is what I see in configs.jar:

META-INF/MANIFEST.MF
META-INF/CS.SF
META-INF/CS.RSA
META-INF/
logging.properties
jitsi-defaults.properties
felix.client.run.android.properties
felix.client.run.linux.properties
felix.client.run.macosx.properties
felix.client.run.windows.properties
Ingo Bauersachs
2014-07-24 12:23:32 UTC
Permalink
Oh yeah, now that you mention all that it dawns on me again... I think thats the reason why I created the configs.jar, however I don't remember how I dealt with the properties files. It might require a patch in the ConfigService implementations to check for the presence of WebStart and use a specific classloader in that case.

/etc/jitsi is a good idea, but we should deal with that for Windows then as well (%ProgramData%\Jitsi) and Mac probably has a directory for that too. (b: true)

There could be other affected places, however I don't remember other significant changes right now since I've built webstart, so it should be okay rest of it. No guarantees though.

Jitsi-defaults endes up in the jar by pattern matching and the felix config are generated by ant. The logger is for sure affected, but afaik the launcher takes care of it.

Sorry for the top-posting :-(

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile
Post by Daniel Pocock
Post by Ingo Bauersachs
These files were introduced long after I created the WebStart launcher, so it's just something that needs to be added to the build.
Which JAR do you think I should add them to?
Post by Ingo Bauersachs
In the desktop version, jitsi-defaults is updated by the installer and could be overwritten by a newer version, while jitsi-default-overrides is meant for an admin to override the defaults and should not be touched by an installer.
Ok, so jitsi-defaults.properties could live happily in a JAR but
a) for standalone deployments, it could be in /etc/jitsi and that
directory could be added to the classpath
b) for JNLP deployment, it would probably have to be in a JAR too so it
doesn't make much difference whether somebody deploying this way puts
their changes in jitsi-defaults.properties or the overrides file because
both have to come from a JAR anyway
Post by Ingo Bauersachs
Both are loaded as a resource from the classpath, which is why they reside in the lib-directory. So no need to put them in any jar. They can be tweaked by a sysadmin, although not at runtime - a restart of Jitsi is necessary.
It looks like apps launched by WebStart need to use a different method
https://community.oracle.com/thread/1308233?start=0&tstart=0
I'll try and make a patch for this. Could there be other things in
Jitsi that are impacted too?
Post by Ingo Bauersachs
The configs.jar you mention below is something else, although I can't quite remember what that was. I think we (at the Uni project where the WebStart comes from) had some additional stuff for our proprietary plugin in there.
META-INF/MANIFEST.MF
META-INF/CS.SF
META-INF/CS.RSA
META-INF/
logging.properties
jitsi-defaults.properties
felix.client.run.android.properties
felix.client.run.linux.properties
felix.client.run.macosx.properties
felix.client.run.windows.properties
_______________________________________________
users mailing list
http://lists.jitsi.org/mailman/listinfo/users
Loading...