On Fri, 24 Sep 2004 04:23:06 -0600, "Bill Winspur"
<[EMAIL PROTECTED]> said:
> Dan,
>
>
> Question: I like the syntax coloring set up that I've established
> in OxygenXML, but what would I loose by associating it to the page-
> flow and xpl files of OXF, instead of using the editors that come
> with studio?
Assuming you have fed OxygenXML the schemas for our various document
types, not too much. The main loss would be the browsing/navigation
functionality of the PFC views. ( The smalltalk like views that show
pages, actions, and results of the PFC. )
Now shouldn't be considered objective, however for .xpl, log4j.xml,
and the page-flow.xml my preference is the Studio editors. My
reasons for this is I hate figuring out how to get XML editors to
use my schemas and I don't like the way most editors don't validate
while you type.
Of course if you already are familiar with a particular editor then
that is probably a moot point.
>
> Just to make sure I've got it (or not), here's my feedback of how
> debug logging of OXF on remote servers works.
>
> * When the Log Event View (LEV) is opened in Studio ( stand alone
> or plugin ) it initially scans the log4j.xml files in your
> workspace. If LEV sees a SocketAppender, SocketReceiver, or
> SocketHubAppender declaration in log4j,xml (denoting an intent
> to log to a remote logging facility - studio in this case), it
> creates a corresponding server socket or socket connection,
> allowing the remote presentation server to connect to the Studio
> host for logging purposes.
Yes, however see summary below about SocketHub*.
>
> * The Presentation Server, on the remote app server, loads its
> copy of log4j, and configures it with the log4j.xml named in
> properties.xml. e.g. 'oxf:/config/log4j.xml'
>
> * Each time Presentation manger on the remote appserver encounters
> a debug attrib in a .xpl file, it generates a log message, which
> log4j forwards to the logging socket on the studio host
Again, see the SocketHub* case in the summary below.
>
> * LEV on the Studio host monitors the log files and refreshes the
> display, whenever logging lines are received from the remote
> appserver.
Not sure if it matters, but there are no files. Or rather
Studio isn't working with files but is just getting events
from the net and keeping what it can in memory. If you
want the log events recorded to a file as well you should
add file appender to the deployed log4j.xml.
>
> * So, as long as the logging config files for Studio and
> Presentation Server are complementary everything should just
> work. ( Barring firewalls etc. )
Hmm, thought I said 'identical or complementary', anyhoo
see below for more detail on this..
>
> Question: What exactly does 'complementary logging
> configurations' mean ?
>
For example you could have a log4j.xml in the studio workspace that
looks like
<:configuration
xmlns="http://jakarta.apache.org/log4j/";
>
<plugin
class="org.apache.log4j.net.SocketReceiver"
name="x"
>
<param
name="Port"
value="9090"
/>
</plugin>
</configuration>
and one deployed that looks like
<configuration
xmlns="http://jakarta.apache.org/log4j/";
>
<appender
name="MyAppender"
class="org.apache.log4j.net.SocketAppender"
>
<param
name="RemoteHost"
value="my-dev-machine"
/>
<param
name="Port"
value="9090"
/>
</appender>
<root>
<priority
value="info"
/>
<appender-ref
ref="MyAppender"
/>
</root>
</configuration>
asssuming that your machine is named 'my-dev-machine'
these two files are complementary.
To summarize the situation wrt log4j, logging
over the network, and Studio :
o Log events from Loggers go to Appenders. Appenders
exist in the same VM as the code that is logging.
o Log Events go from Appenders to Receivers. If there
is no Reciever the log event is lost.
o SocketHubReceiver pull events from SocketHubAppenders
and SocketAppenders push events to SocketReceivers
o Within Presentation Server what basically matters is
the logger and appender specs. ( However nothing
in the file is ignored. )
o On the Studio side, Studio will create any Receivers
that are declared. For appender declarations it makes
a best guess at what an apropriate Receiver would be.
The guess should always work in the SocketAppender case
however in the SocketHubAppender case it will only
work if the Presentation Server is on the local
machine. Not surprising, as the hub system is a pull
one. i.e. Studio, or log4j within Studio, will have
to connect to a remote host and pull log events.
The only reasonable guess for the remote host name
is 'localhost'. ( Yeah, not really remote but I
hope you understand what I mean. :) )
A few final blurbs on the monitoring support :
o By default when you use the browser view in Studio
the Log Event is cleared with each request. (
So you can just view the events for that request. )
o In the 1.0 release the log event view tries to
keep the selection on the last event with a
matching line and column pair. i.e. If you
selected an event from the debug attrib
at line 5, column 4 in foo.xpl then if another
event comes from that debug attrib the selection
will move to the newer event.
-- Regards, Dan S
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
orbeon-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/orbeon-user
