Menu
▾
▴
[Opensst-developer] Re: Proposition to externalize config variables
|
From: Pascal S. <Pas...@se...> - 2003-01-23 08:27:26
|
On Wed, 2003-01-22 at 20:03, "Stormacq, S=E9bastien" wrote:
> Hello Pascal,=20
>=20
>> I've got a liitle class, used in some other java apps, that handles,
>> pretty nicely, a global properties file containing the config=20
>> variables. If you want to go the properties way for externalizing=20
>> config variables, I suggest taking a look at my class (see=20
>> attachement, package has to be adapted of course <image.tiff>).=20
>=20
> I am always hesitating between a regular Java properties file and an
> XML file=20
>=20
> Maybe you have arguments that can help to choose between the two.=20
>=20
>=20
> Anyway, your class (and my hesitation) only address part of the
> problem : the reading and writing of the data itself. This is only the
> top of the iceberg on this topic and the most easy part to solve :-)=20
>=20
>=20
> The real problem, according to me, is to let the client figure out
> where the configuration file is and how he can read/write to it.=20
Well, as the client has to fill, set the config in his config file, I
think the use of a simple properties file would be easier accepted and
understood as a "complicated" xml file. XML is really powerfull, and I'm
pretty impressed about your xml messages, but for a config file I think
a properties file would do the thing, no need of a dtd, no need of
updating syntax and/or style, etc... it's pure text !
>=20
> As you have noticed, a JWS application can not write the file system
> as easily : we have to use JWS storage services.=20
>=20
>=20
> On the other hand, since we are in the context of a web application :
> i really like the idea of having the user's properties stored on the
> server (and the file being exchanged through opensst messages). This
> solution solves all deployment issues we are facing=20
That sounds really good to me. The user properties could be stored on
the server, and ciphered with his public key, so only he can use them.
But I don't know if you want to go that far ?
>=20
>=20
> P.S.: Bytheway, I test the stuff about the server being behind a
> proxy, works ok and is really easy to implement. The use a config
> properties file for tis too would be perfect.=20
>=20
>=20
> I really would like to see your modif (even with hardcoded proxy)=20
>=20
> The output of a "diff -c"is fine for me.=20
>=20
> I can commit that in the CVS tree=20
The modif is in the OpenSSTServlet class (the proxy config on the client
is handled by the JWS :)), here are the stuff I added :=20
Two global variables :
//if server is behind proxy=20
// use these :
private static final String SERVER_PROXY=3D"proxy.domain.tld";
private static final String SERVER_PROXY_PORT=3D"1234";
Setting of the proxy config into the system properties :
/**
* Forward the call we just receive to the specified URL.
*
* @param destinationURL where we need to forward the call
* @param httpHeaders the HTTP headers given by the browser
to the local proxy
* @param httpCommand the HTTP command to use (GET, POST,
...)
* @param urlParams the URL params as received by the browser
* @param httOUTHeaders an empty map that will be populated=20
with the HTTP headers send by the server (including cookies)
* @return the output of the forwarded call
*/
private HTTPResponse forwardCall(String destinationURL, String =09
httpCommand, Map httpHeaders, =09
Map urlParams, Map httpOutHeader) {
//testing proxy config
Properties prop =3D new Properties();
prop.put("http.proxyHost",SERVER_PROXY);
prop.put("http.proxyPort",SERVER_PROXY_PORT);
=20
return HTTPHelper.getInstance().connect(destinationURL, null,
httpHeaders, httpCommand, urlParams, =20
httpOutHeader, prop);
=20
}
I had also to modify slightly the HTTPHelper.connect() method, to accept
the proxy config :
public HTTPResponse connect(String url, String dataToSend, Map =20
httpHeaders, String sendMethod, Map urlParams, Map
httpOUTHeaders) {
return connect(url, dataToSend, httpHeaders, sendMethod, =09
urlParams, httpOUTHeaders,null);
}
=20
/**
* Connect to an URL and gives the result back.
* It can also optionnaly post a set of data.
*=20
* @todo we should find a more efficient way to read the stream
of bytes
* @param url the URL where we need to connect
* @param dataToSend the optional data to send
* @param httpHeaders the HTTP headers to send
* @param sendMethod the method to use when data will be =20
send (post or get)
* @param httOUTHeaders an empty map that will be populated =20
with the HTTP headers send by the server (including cookies)
* @param sysProps customized system properties, like proxy =09
server etc.
* @return the result, as received from the server
*/
public HTTPResponse connect(String url, String dataToSend, Map
httpHeaders, String sendMethod, Map urlParams, Map
httpOUTHeaders, Properties sysProps) {
=09
HTTPResponse result =3D null;
=20
=20
if ( (sendMethod =3D=3D null ) || ! (sendMethod.equals("POST") ||
sendMethod.equals("GET")) ) {
throw new IllegalArgumentException("HTTPHelper.connect
receives an invalid argument for sendMethod: " +
sendMethod);
} =20
=20
try {
if (urlParams !=3D null && !urlParams.isEmpty() &&
sendMethod.equals("GET")) {
//add the param to the URL
url =3D addParams(url, urlParams);
}
URL realURL =3D new URL(url);
=20
if ( sysProps !=3D null && !sysProps.isEmpty()) {
//add these properties to system the system properties
Properties prop =3D System.getProperties();
prop.putAll(sysProps);
}
=20
HttpURLConnection uc =3D
(HttpURLConnection)realURL.openConnection();
uc.setDoInput(true);
uc.setRequestMethod(sendMethod);
.
.
.
.
etc.
To put short one has to add http.proxyHost and http.proxyPort to the
system properties !
>=20
>=20
> Thanks for the effort and your suggestions=20
I really appreciate developping and contributing to the open-source
community. And I think that you project is very nice.
Eh, another thing, I heard that there is an initiative about testing
interoperability of openSST and idx-pki (from idealx), do you know more
about that, cause that would interset me aswell ?
>=20
>=20
> Seb
--=20
pst
|
