Home Projects Jobs Clientele Contact


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Configuration

Alexey Parshin wrote:

>It's included into SPTK and it doesn't use external XML libraries.. 
Well, since we link to libsptk already anyways, I might as well use your
XML classes.
On the other hand, how difficult would it be to move generic classes
(like CString, CThread, etc)
out of spdb2.so? It really makes no sense to link spdb (which brings in
dep on libodbc.so, etc) just
to get definitions of some generic classes. So, something like 
libsptk.slo (for generics and system services),
libspXML.so, libspGUI.so, libspXL.so (for excel - you alredy have this I
think) would be nice.

>On 4/23/05, Thibaut Colar <tcolar@qarbon.com> wrote:
>>Well depends of the setup.
>>For example sometimes i use tomcat standalone (not with apache +
>>mod_jk), so if you want to define an error page you add this to xml:
>>    <error-code>404</error-code>
>>    <location>/404.html</location>
>> </error-page>
>>Also you can define error 5xx (servlet errors) that apache would not
>>handle anyway.
>>Also most of the time if you do use apache with pass through to tomcat,
>>you would tell apache that everything in a context (ie: /servelts/) is
>>to be handled (passed to) tomcat, so if something is missing in there
>>apache won't handle the 404 since it delegated all to tomcat.
>>other things i use myself:
>>  <display-name>Viewlet Central</display-name>
>>  <description>
>>        Viewlet Central
>>    </description>
>>  <session-config>
>>    <session-timeout>600</session-timeout>
>>  </session-config>
>>Other than that the rest i don't use much.
>>Per servlets option i don't use but it's definitely something i think
>>could be useful.
>>As for XML, i agree with you and that is what i don't like with XML, a
>>huge, very slow, memory hungry parser to read 5 key values :-)   but if
>>you start to add parameters, etc ... to each servlets definition then it
>>might be best ...
>>Doesn't C++ have some light weight XML parser ? you really don't need a
>>full blown one, just something to read attributes/values.
>>Ilya A. Volynets-Evenbakh wrote:
>>>Nah.. CPPSERV doesn't claim to support "standards", it claims to have
>>>API losely based on that of J2EE Servlet API ;-)
>>>This means we can (and probably will) invent config format of our own.
>>>In fact XML parser is the last thing I want to
>>>hook up to this engine - it will automatically add dependancy on libs
>>>that are at least ~1.5 M in size. Not something I
>>>want to have in embedded device.
>>>BTW, what do you mean by defining error pages? Isn't that done by
>>>Apache? (ErrorDocument in .htaccess or apache.conf)
>>>So, config-wise - we have session timeouts, "application definitions" -
>>>i.e. set of related servlets sharing ServletContext and
>>>session name. I guess adding per-servlet parameters should be reasonable
>>>(think multiple instances of same servlet
>>>hooked to different databases, etc).
>>>Anything else?
>>>Thibaut Colar wrote:
>>>>Besides servlets definitions ?
>>>>not: much, most common i define is error pages (404)
>>>>and also very useful is session timeout.
>>>>Have rarely used anything else, i f any.
>>>>I'm not a big fan of the web.xml myself.
>>>>1) it's xml ... so you know :-)
>>>>2) it needs both the definitions, and then the mapping, and on most
>>>>java containers it needs all the definitions first, followed by all
>>>>the mappings, so it's annoying to edit (2 places).  But i guess it's
>>>>an implementation issue so you don't have to make yours stupid like
>>>>this :-)
>>>>But, i guess you gotta make the web.xml regardless cause it's "standard"
>>>>Ilya A. Volynets-Evenbakh wrote:
>>>>>I'm thinking about configuration of servlets right now.
>>>>>Ideas on what exactly should be configurable?
>>>>>Should I perhaps use web.xml config format?
>>>>>Question to those who program a lot of servlets:
>>>>>What things have you ever actually configured in real life?
>>>>>All ideas are welcome.

Ilya A. Volynets-Evenbakh
Total Knowledge. CTO

Authoright © Total Knowledge: 2001-2008