-------- Original Message --------
Subject: Re: Re: [Wt-interest] wt_config.xml not readable?
Date: Tue, 16 Mar 2010 18:45:41 -0400
From: Diego Cantor <[email protected]>
To: [email protected]
That is what I thought. I tried to check it manually but I didn't see
anything. Doesn't this file gets automatically generated when you run
cmake? (I have no idea)
I am attaching it here.
Thank you!
On 2:59 PM, OvermindDL1 wrote:
> On Tue, Mar 16, 2010 at 4:02 PM, Diego Cantor-Rivera
> <[email protected]> wrote:
>
>> Hello,
>>
>> I am trying to compile Wt in Windows 7. So far this is what I have done:
>>
>> 1. I downloaded the cmakeable version of Boost
>> 2. I compile it with VC++ (MinSizeRel) and install it (c:\Program
>> Files\Boost)
>> 3. I downloaded Wt and run CMake.
>> 4. I configured Wt with CMake. It found Boost without a problem.
>> 5. I compiled ALL BUILD (Debug)
>> 6. I build INSTALL
>> 7. I selected hello.wt as the Start Up project and I added these arguments
>> in the configuration properties:--http-address=0.0.0.0 --http-port=8080
>> --deploy-path=/hello --docroot=.
>>
>> 8. I get this message in VC++:
>>
>> 'hello.wt.exe': Loaded
>> 'C:\Users\odin\Software\wt-3.1.1b.bin\examples\hello\Debug\hello.wt.exe',
>> Symbols loaded.
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\ntdll.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\kernel32.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\KernelBase.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\winmm.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\msvcrt.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\user32.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\gdi32.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\lpk.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\usp10.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\wsock32.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\ws2_32.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\rpcrt4.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\nsi.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\mswsock.dll'
>> 'hello.wt.exe': Loaded
>> 'C:\Windows\winsxs\x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.1_none_bb1f6aa1308c35eb\msvcp90d.dll'
>> 'hello.wt.exe': Loaded
>> 'C:\Windows\winsxs\x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.1_none_bb1f6aa1308c35eb\msvcr90d.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\advapi32.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\sechost.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\imm32.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\msctf.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\cryptsp.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\rsaenh.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\cryptbase.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\nlaapi.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\dnsapi.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\winrnr.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\NapiNSP.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\pnrpnsp.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\wshbth.dll'
>> 'hello.wt.exe': Loaded 'C:\Program Files\Bonjour\mdnsNSP.dll'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\IPHLPAPI.DLL'
>> 'hello.wt.exe': Loaded 'C:\Windows\System32\winnsi.dll'
>> First-chance exception at 0x75419617 in hello.wt.exe: Microsoft C++
>> exception: rapidxml::parse_error at memory location 0x00b2f0e0..
>> First-chance exception at 0x75419617 in hello.wt.exe: Microsoft C++
>> exception: Wt::WServer::Exception at memory location 0x00b2f290..
>> 'hello.wt.exe': Unloaded 'C:\Windows\System32\IPHLPAPI.DLL'
>> 'hello.wt.exe': Unloaded 'C:\Windows\System32\winnsi.dll'
>> 'hello.wt.exe': Unloaded 'C:\Windows\System32\nlaapi.dll'
>> 'hello.wt.exe': Unloaded 'C:\Windows\System32\winrnr.dll'
>> 'hello.wt.exe': Unloaded 'C:\Windows\System32\NapiNSP.dll'
>> 'hello.wt.exe': Unloaded 'C:\Windows\System32\pnrpnsp.dll'
>> 'hello.wt.exe': Unloaded 'C:\Windows\System32\wshbth.dll'
>> 'hello.wt.exe': Unloaded 'C:\Program Files\Bonjour\mdnsNSP.dll'
>> The thread 'Win32 Thread' (0x980) has exited with code 1 (0x1).
>> The program '[5384] hello.wt.exe: Native' has exited with code 1 (0x1).
>>
>> 9. When I run hello.wt.exe --http-address=0.0.0.0 --http-port=8080
>> --deploy-path=/hello --docroot=. I get:
>>
>> Option no-compression is implied because wthttp was built without zlib
>> support.
>> Error reading: c:/Users/odin/Software/witty/wt_config.xml: expected <
>>
> That indicates it is badly formatted. Have you ran it through an XML
> verifier? Can you attach it so we can do the same and look through
> it?
>
>
>
--
Diego Cantor-Rivera
mailto:[email protected]
--------------------------------------------------------------------
p.s. Internet Privacy
--------------------------------------------------------------------
My PGP public key is attached to this message.
If you want to know how to use my key please let me know.
Ma cle publique PGP est attachee a ce message.
Si tu veux savoir comment l'utiliser, demande-moi pour renseignements.
Mi llave publica PGP se encuentra anexada a este correo.
Si quieres saber como usar mi llave, preguntame.
--------------------------------------------------------------------
<!--
Wt Configuration File.
The Wt configuration file manages, for every Wt application, settings
for session management, debugging, directory for runtime information
such as session sockets, and some security settings.
Settings may be specified globally, or for a single application path.
The path should be as configured in the Wt build process, where it
defaults to /etc/wt/wt_config.xml. It can be overridden in the environment
variable WT_CONFIG_XML, or with the -c startup option of wthttpd.
The values listed here are the default values, which are used when the
declaration is missing or no configuration file is used.
-->
<server>
<!-- Default application settings
The special location "*" always matches. See below for an example
of settings specific to a single application.
-->
<application-settings location="*">
<!-- Session management. -->
<session-management>
<!-- Every session runs within a dedicated process.
This mode guarantees kernel-level session privacy, but as every
session requires a seperate process, it is also an easy target
for DoS attacks if not shielded by access control.
It is also a convenient mode during development, as it is easy
to enable disable debugging using valgrind, and it always starts
the latest deployed executable for a new session.
Note: currently only supported using the FastCGI connector
-->
<!--
<dedicated-process>
<max-num-sessions>100</max-num-sessions>
</dedicated-process>
-->
<!-- Multiple sessions within one process.
This mode spawns a number of processes, and sessions are
allocated randomly to one of these processes (you should not
use this for dynamic FCGI servers, but only in conjunction
with a fixed number of static FCGI servers.
This requires careful programming, as memory corruption in one
session will kill all of the sessions in the same process. You
should debug extensively using valgrind. Also, it is your
responsibility to keep session state not interfering and
seperated.
On the other hand, sessions are inexpensive, and this mode
suffers far less from DoS attacks than dedicated-process mode.
Use it for non-critical and well-debugged web applications.
Note: wthttpd always uses exactly one process
-->
<shared-process>
<num-processes>1</num-processes>
</shared-process>
<!-- Session tracking strategy.
Possible values:
Auto: cookies is available, otherwise URL rewriting
URL: only URL rewriting
-->
<tracking>URL</tracking>
<!-- How reload should be handled.
When reload should (or rather, may) spawn a new session, then
even in the case cookies are not used for session management,
the URL will not be cluttered with a sessionid.
However, WApplication::refresh() will never be called.
-->
<reload-is-new-session>true</reload-is-new-session>
<!-- Session timeout (seconds).
When a session remains inactive for this amount of time, it is
cleaned up.
-->
<timeout>600</timeout>
<!-- Server push timeout (seconds).
When using server-initiated updates, the client uses
long-polling requests. Proxies (including reverse
proxies) are notorious for silently closing idle
requests; the client therefore cancels the request
periodically and issues a new one. This timeout sets
the frequency.
-->
<server-push-timeout>50</server-push-timeout>
</session-management>
<!-- Settings that apply only to the FastCGI connector.
To configure the wthttpd connector, use command line options, or
configure default options in /etc/wt/wthttpd
-->
<connector-fcgi>
<!-- Valgrind path
If debugging is enabled and this path is not empty, then valgrind
will be started for every shared process, or for every session
which has ?debug appended to the command line.
The variable is slighly misnamed. Not only a path can be set,
but also options, like for example:
/usr/bin/valgrind - -leak-check=full
-->
<valgrind-path></valgrind-path>
<!-- Run directory
Path used by Wt to do session management.
-->
<run-directory>c:/Users/odin/Software/witty</run-directory>
<!-- Number of threads per process
This configures the size of the thread pool. You may
want to change this value if you would like to support
reentrant event loops, where you block one event loop
using WDialog::exec() or related static
methods. Everytime you enter such an event loop, one
thread is blocked, and therefore the total number of
sessions that reliably can do this is limited to the
number of thread you have (minus one to unblock).
For the built-in http connector, there is a similar
config option that is specified in the whttpd config
file or on the command line (-t).
The default value is 1.
-->
<num-threads>1</num-threads>
</connector-fcgi>
<!-- Enable debug
When enabled,
- JavaScript errors are not caught to display an error message.
-->
<debug>false</debug>
<!-- Log file
When the log file is empty, or omitted, logging is done to
stderr. This may end up in the web server error log file
(e.g. for apache + fastcgi module), or on stderr (e.g. for
the built-in httpd).
-->
<log-file></log-file>
<!-- Maximum HTTP request size (Kb) -->
<max-request-size>128</max-request-size>
<!-- Session id length (number of characters) -->
<session-id-length>16</session-id-length>
<!-- Send the XHTML mime type when appropriate
Wt renders XHTML1 (XML variant of HTML) that is backward-compatible
with HTML. Using XHTML, Wt is capable of supporting XHTML-only
features such as embedded SVG or MathML.
When enabled, JWt sets an XHTML mime-type
(application/xhtml+xml) when the browser reports support
for it. Most notably, Internet Explorer does not support
it. Because XHTML and HTML are slightly different with
respect to default CSS rules, you may want to disable
sending the XHTML mime-type alltogether, at least if you
are not using SVG (used by the WPaintedWidget). -->
<send-xhtml-mime-type>false</send-xhtml-mime-type>
<!-- Do strict serialization of events.
By default events are queued at the client-side, and
transmitted to the server so that at any time only one
request/response is pending. This scheme has a quality that
resembles TCP: on a low-latency link you allow the
transmission of many smaller requests, while on a high
latency link, events will be propagated less often, but in
batches.
In any case, this scheme does not drop events, no matter
how quickly they are generated.
In rare cases, the scheme may result in unwanted behaviour,
because the client-side is allowed to be slighly out of
sync at the time an event is recorded with the server-side
(and more so on high-latency links). The drastic
alternative is to discard events while a response is
pending, and can be configured by setting this option to
true.
-->
<strict-event-serialization>false</strict-event-serialization>
<!-- Redirect message shown for browsers without JavaScript support
By default, Wt will use an automatic redirect to start the
application when the browser does not support
JavaScript. However, browsers are not required to follow
the redirection, and in some situations (when using XHTML),
such automatic redirection is not supported.
This configures the text that is shown in the anchor which
the user may click to be redirected to a basic HTML version
of your application.
-->
<redirect-message>Load basic HTML</redirect-message>
<!-- Whether we are sitting behind a reverse proxy
When deployed behind a reverse proxy (such as Apache or Squid),
the server location is not read from the "Host" header,
but from the X-Forwarded-For header, if present.
-->
<behind-reverse-proxy>false</behind-reverse-proxy>
<!-- Whether inline CSS is allowed.
Some Wt widgets will insert CSS rules in the the inline
stylesheet when first used. This can be disabled using this
configuration option.
Note: some widgets, such as WTreeView, dynamically
manipulate rules in this stylesheet, and will no longer
work properly when inline-css is disabled.
-->
<inline-css>true</inline-css>
<!-- Ajax user agent list
Wt considers three types of sessions:
- AJAX sessions: use AJAX and JavaScript
- plain HTML sessions: use plain old server GETs and POSTs
- bots: have clean internal paths and no persistent sessions
By default, Wt does a browser detection to distinguish between
the first two: if a browser supports JavaScript (and has it
enabled), and has an AJAX DOM API, then AJAX sessions are chosen,
otherwise plain HTML sessions.
Here, you may indicate which user agents should or should
not receive an AJAX session regardless of what they report as
capabilities.
Possible values for 'mode' or "white-list" or "black-list". A
white-list will only treat the listed agents as supporting AJAX,
all other agents will be served plain HTML sessions. A black-list
will always server plain HTML sessions to listed agents and
otherwise rely on browser capability detection.
Each <user-agent> is a regular expression.
-->
<user-agents type="ajax" mode="black-list">
<!-- <user-agent>.*Crappy browser.*</user-agent> -->
</user-agents>
<!-- Bot user agent list
Here, you can specify user agents that should be should be
treated as bots.
Each <user-agent> is a regular expression.
-->
<user-agents type="bot">
<user-agent>.*Googlebot.*</user-agent>
<user-agent>.*msnbot.*</user-agent>
<user-agent>.*Slurp.*</user-agent>
<user-agent>.*Crawler.*</user-agent>
<user-agent>.*Bot.*</user-agent>
<user-agent>.*ia_archiver.*</user-agent>
<user-agent>.*Twiceler.*</user-agent>
</user-agents>
<!-- Whether the progressive bootstrap is used.
The default bootstrap method first senses whether there is AJAX
support, and only then creates the application.
The progressive bootstrap method first renders a plain HTML
version and later upgrades to an AJAX version.
-->
<progressive-bootstrap>false</progressive-bootstrap>
<!-- Runtime Properties
These properties may be used to adapt applications to their
deployment environment. Typical use is for paths to resources
that may or may not be shared between several applications.
-->
<properties>
<!-- resources property
The location of the resources/ folder that is part of the Wt
distribution.
The default value is 'resources/'
-->
<property name="resources">resources/</property>
<!-- extBaseURL property
Used in conjunction with Ext:: widgets, and points to the
location of Ext JavaScript and resource files (css, images).
See the documentation for the Ext namespace for details.
The default value is 'ext/'
-->
<property name="extBaseURL">ext/</property>
<!-- favicon property
By default, a browser will try to fetch a /favicon.ico icon
from the root of your web server which is used as an icon
for your application. You can specify an alternative location
by setting this property, or for an individual application
entry point by passing a location to WServer::addEntryPoint().
-->
<!-- <property name="favicon">images/favicon.ico</property> -->
<!-- oldInternalPathAPI property
Since wt 2.99.3, the internal path API has been simplified.
The API functions are still the same, but the semantics have
changed. To keep using the old semantics (which are deprecated
but still implemented) you can set this property.
-->
<!-- <property name="oldInternalPathAPI">true</property> -->
</properties>
</application-settings>
<!-- Override settings for specific applications.
Location refers to physical filesystem location of the
application. The application prints this location (which
corresponds to argv[0]) to the log file on startup, and this
should match exactly.
-->
<!--
<application-settings
location="/var/www/localhost/wt-examples/hello.wt">
</application-settings>
-->
</server>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
