OPS User Guide
- Getting Started
- Core Technologies Reference
- XForms
- Page Flow
- XML Pipelines (XPL)
- OPS Technologies Reference
- Processors Reference
- API Reference
- Integration
|
Orbeon PresentationServer and Orbeon Studio FAQ
1. Introduction
This FAQ answsers technical questions about Orbeon Presentation Server (OPS). See
also the Orbeon community FAQ.
2. General Orbeon PresentationServer FAQ
2.1. What is Orbeon PresentationServer?
Orbeon PresentationServer (OPS) is an open source J2EE-based platform for
XML-centric web applications. OPS is built around XHTML, XForms, XSLT, XML
pipelines, and Web Services, which makes it ideal for applications that capture,
process and present XML data.
Unlike other popular web application frameworks like Struts or WebWork that are
based on Java objects and JSP, OPS is based on XML documents and XML
technologies. This leads to an architecture better suited for the tasks of
capturing, processing, and presenting information in XML format, and often does
not require writing any Java code at all to implement your presentation layer.
OPS is built around Orbeon's optimized XPL engine, a
mature, high-performance XML pipeline engine for processing XML data.
OPS features standards-based forms processing using XForms, rich controller
semantics, and full-featured XML pipelines described with XPL, the XML Pipeline
Language.
2.2. How does Orbeon PresentationServer compare with Apache Cocoon?
OPS is similar to Cocoon in some respects but also presents many differences,
in particular XForms support. For more information, see our OPS and Cocoon comparison
matrix.
2.3. How does OPS compare with Model 2X?
Model 2 defines how the Model-View-Controller (MVC) pattern can be applied to
Web applications. Model 2X builds on top of Model 2 and replaces the JSP layer
with XML and XSLT. Model 2X was first described in an article
Orbeon published by JavaWorld in February 2002. A variant of the concept using
JavaServer Faces was published
in TheServerSide in 2003. OPS can be used to implement Model 2X and much more,
but the current focus of the platform remains XForms technology. For more
information, please refer to the OPS User Guide.
3. XForms FAQ
3.1. What is XForms?
XForms is W3C's next generation web forms. XForms 1.0 is a W3C Recommendation
since October 2003.
XForms aims at replacing HTML forms, but it is not strictly tied to HTML. The
main goal of XForms is to make web forms design easier, allowing the developer
to write less client-side scripting (or none at all), and less server-side code
thanks to a feature-rich declarative approach.
Benefits of XForms include:
- Clear separation between data captured and presentation (separation of concerns)
- Flexible, structured XML-based data model: define your data model as an XML document, then create forms accessing the data
- Built-in facilities for validation and data integrity based on XML Schema and/or assertions
- Declarative approach requiring less / no scripting at all, in particular thanks to declarative events and actions
- Ease of internationalization
- Support for a variety of devices
- W3C standard
- Not tied to a particular platform or language such as Java or .NET
See also the OPS XForms
Introduction section.
3.2. How much of the XForms specification does OPS support?
The OPS implementation is based on the W3C XForms 1.0 Recommendation (14
October 2003). OPS 3.0's XForms NG engine is close to supporting all of the
XForms 1.0 specification. For more detailed information on what features are
supported in the latest version of OPS, see the XForms conformance matrix section of the
documentation.
3.3. What is a server-side XForms implementation?
The XForms specification assumes that XForms is implemented on the client-side,
that is natively within a web browser. Until XForms becomes standard on
mainstream browsers, XForms-based applications can use server-side
implementations (that delegate a good part of the XForms processing to
server-side code), or hybrid implementations, that share XForms processing
between server-side code and client-side code and rely on Ajax technology.
Orbeon PresentationServer features such a hybrid implementation. We believe that
using hybrid implementation is the best possible migration path towards XForms.
A server-side implementation of XForms translates your forms described in terms
of the XForms specification into HTML, CSS and JavaScript code understood by
your web browser. The following diagram shows a high-level overview of the
architecture of a hybrid XForms implementation:

Hybrid XForms
For more information about server-side XForms, we refer you to this article we
presented at the XTech 2005 conference:
3.4. What are the XForms Classic and XForms NG engnes?
Up to version 2.8, OPS featured a pure server-side XForms engine with limited
XForms functionality. With version 3.0, OPS features a much enhanced XForms
engine, with support for almost the entire XForms specification, with the intent
to completely support XForms 1.0 and XForms 1.1 in the future. The older XForms
engine has been informally dubbed "XForms Classic", and the new XForms engine
"XForms NG".
For backward compatibility reasons, the XForms Classic engine is still present
in OPS 3.0.
3.5. How do I know which XForms engine I am using?
If you are using OPS 2.8 or earlier, you are using XForms Classic. If you are
using OPS 3.0 or later, then you may be using XForms Classic or XForms NG, but
there is an easy way to tell: if a <page> entry in your page
flow features an xforms attribute, then and only then that page is
using XForms Classic. Otherwise, if the page view contains at least one XForms
model under its xhtml:head element, then it is using XForms NG.
3.6. Should I keep using the XForms Classic engine?
The XForms Classic engine has been kept only for backward compatibility. It is
currently deprecated, and may be removed in the future. If you are starting an
application from scratch with OPS 3.0, we strongly advise against using XForms
Classic. If you are migrating to OPS 3.0, we advise starting migrating XForms
NG. You can keep your existing pages working with XForms Classic, and write new
pages with XForms NG. Over time, you can migrate existing XForms Classic pages
to XForms NG, making for a smooth transition.
As of OPS 3.0, some features of XForms Classic have not yet made it into XForms
NG, in particular support for browsers with very limited Javascript
functionality, and non-Ajax mode. In time, we hope to bring these features to
XForms NG as well, therefore completely removing the need for XForms Classic.
3.7. Do I need to use XForms to create my HTML forms?
It is not a requirement to use XForms. It is possible to generate HTML form
elements and to examine request parameters manually. We recommend however using
XForms whenever possible, because it provides an elegant abstraction that
simplifies form handling.
3.8. How can I perform a file upload?
3.9. My XForms upload doesn't work. What can I do?
With OPS 2.8 or earlier, or if you are using XForms Classic with OPS 3.0, make
sure that you have the correct submission method and encoding in your XForms
model:
<xforms:submission method="post" encoding="multipart/form-data" xmlns:xforms="http://www.w3.org/2002/xforms"/>
With OPS 3.0 and XForms NG, uploaded files can only be retrieved with a
submission with replace="all" .
3.10. Can I mix and match XForms and JSP?
Yes, you can use JSP alongside XForms, even within the same web app. You can
"call" JSP by redirecting or forwarding using the Redirect processor. You can also
use the Servlet Include generator to include the content produced by a JSP.
Finally, you can use the Servlet Filter generator and implement JSP
post-processing with OPS.
4. XML pipelines (XPL) FAQ
4.1. What is an XML pipeline and why do I care?
XML pipelining is an approach to processing XML where the inputs and outputs of
multiple processing steps (e.g., XSLT transformations) are connected together
using a pipeline metaphor. Orbeon has implemented an XML pipeline engine in Java
that executes a declarative XML pipelining language called XPL.
"Programming" pipelines using declarative XML instead of writing procedural
code results in a significant increase in productivity for tasks that require
high volume or complex XML processing. XML documents enter a pipeline, are
efficiently processed by one or more processors as specified by XPL
instructions, and are then output for further processing, display, or storage.
XPL features advanced capabilities such as document aggregation, conditionals
("if" conditions), loops, schema validation, caching, and sub-pipelines.
XML pipelines are built up from smaller components called XML processors. An
XML processor is a software component which consumes and produces XML documents.
New XML processors are most often written in Java, but most often developers do
not need to write their own processors because the engine provides a
comprehensive library. Example processors include an XSLT processor, database
processors that interface with both SQL and native XML databases, and a
serializer processor that writes XML documents to disk. XPL orchestrates these
to create business logic, similar to the way Java code "orchestrates" Java
object method calls.
4.2. What is XPL?
At the core of OPS lies a powerful XML processing engine that
natively speaks the XML Pipeline
Language (XPL). XPL is a declarative language for processing XML using a
pipeline metaphor. XML documents enter a pipeline, are efficiently processed by
one or more processors as specified by XPL instructions, and are then output for
further processing, display, or storage. XPL features advanced capabilities such
as document aggregation, conditionals ("if" conditions), loops, schema
validation, and sub-pipelines.
The Orbeon XPL pipeline engine used in OPS is designed for
low-memory consumption and supports transparent caching.
4.3. What is an XML processor?
The term XML processor is commonly used to refer to XML parsers. In the context
of OPS, the term
XML processor is used to refer to
any software component consuming and/or producing XML documents. An XML
processor can also simply be called an
XML component.
4.4. What does an XML pipeline look like?
This particular example illustrates a simple 2-stage XPL pipeline that performs
an XSLT transformation on an XML document that is located on disk, and then
writes the result back to a another file on disk. For more details about XPL,
please see the XPL and Pipelines reference
documentation, or the OPS tutorial.

2-Stage XPL Pipeline Diagram

2-Stage Pipeline XPL Code
4.5. Is there a specification for XPL?
As of February 2005, a draft
specification has been completed amd submitted to W3C. It serves as a basis
of discussion for an XPL 1.0 specification.
As of December 2005, XML Processing Model Working Group meetings have started at
W3C. This working group, of which Orbeon is a member, is in charge of working
on a standard XML processing language. While the deliverable of the working
group will certainly not be exactly XPL, we do hope that in its first version it
will cover a significant number of use cases currently covered by the XPL
implementation found in Orbeon PresentationServer.
4.6. Is anybody free to implement XPL?
4.7. How much of the XPointer specification does XPL support?
OPS supports a subset of XPointer. You can use the
XPointer document#xpointer(/xpath/expression) syntax to extract a
nodeset from a document.
4.8. How can I pass parameters to an XSLT stylesheet?
It is possible by importing the stylesheet within another
stylesheet, as follows:
<p:processor name="oxf:xslt"> <p:input name="data" href="..."/> <p:input name="config"> <xsl:stylesheet version="2.0"> <!-- This is the stylesheet to pass parameters to --> <xsl:import href="tour.xsl"/> <!-- Here we assign a value to the "start" parameter --> <xsl:param name="start" select="'a1'"/> </xsl:stylesheet> </p:input> <p:output name="data" id="..."/> </p:processor>
4.9. How does caching work in OPS?
Caching mechanisms should have no impact on the behavior of a system, except
for a gain in performance. This is also the principle followed by the
OPS cache: when you develop an application with
OPS, you should be able to ignore that caching takes place. This
may be all you want to know about caching in OPS!
To get a better understanding of the underlying mechanism,
consider the example below:
Let's assume the following:
- The XSLT processor's
config input is an XSLT stylesheet on disk
- The XSLT processor's
data input is an XML file on disk
-
The XSLT stylesheet does not contain imports, includes,
the document() function, or calls to Java code.
Under those assumptions, the XSLT transformation does not
have side effects, which means that if neither the XSLT
stylesheet
(
config input) nor the input XML
document (
data input) change, the output of the
transformation will be the same.
If you were to keep the result of the transformation,
knowing that both inputs have not changed since the last
time you generated that output, you wouldn't have to
actually run the transformation again: you could just reuse
the result you already have. This is the basic of caching in
OPS.
In this example, the result of the XSLT transformation is
used to create an XUpdate processor configuration, which is
an XUpdate program that will be interpreted or compiled by
the XUpdate processor. Instead of keeping the result of the
XSLT transformation as an XML document, the XUpdate
processor can cache the compiled XUpdate program. Compared
to a solution where the XML document is cached, this
technique saves memory by not keeping the XML document in
cache, and saves processing power by preventing the XUpdate
processor to recompile its program.
Therefore, if neither the XSLT transformer's
config nor
data input has changed, the XUpdate processor can keep the
same program in the OPS object cache, saving an XSLT stylesheet
compilation, an XSLT transformation, and an XUpdate program compilation.
The same mechanism applies to the XSLT transformer configuration: the compiled
XSLT stylesheet can be kept in the OPS object cache. And if the
output of the XUpdate transformation is sent to an HTML serializer, the HTML
output could be cached as well.
In general, OPS does not unnecessarily cache the XML
documents passed between processors. Instead, it caches the
result of time-consuming operations, as illustrated above.
Some cases are more complex than the example shown here. For
example in the case of XSLT 1.0, OPS handles caching and
dependencies related to imports, includes as well as the
XPath
document() function when the URL passed
to the function is static. Some processors, like the SQL
processors, never allow their output to be cached.
4.10.
Do debug attributes make my application slower?
The OPS cache avoids executing the parts of a pipeline that do
not need to be re-evaluated. However when the a debug attribute is set, the
point where the attribute is set needs to be evaluated so that meaningful data
can be displayed. This can cause the performance to degrade. Debug attributes
should be removed in production.
4.11. Can I disable debug attributes globally?
4.12. When invoking a processor in XPL, what is the difference between a name and an id?
Processors can be compared to functions in traditional programming languages.
Processors (just like functions) have inputs (arguments) and outputs (return
values). Each input and output has a name. The name is part of the
processor's interface. For instance, using an informal function-like notation,
the XSLT processor interface is:
(data) = xslt(data, config)
since the XSLT processor has 2 inputs named data and
config , and one output named data .
The interface to a processor is the contract that defines what inputs and
outputs do. If you are using an existing processor, for example the XSLT
transformer, you have to use the names declared by that processor. To know what
names you must use, you have to consult the documentation for each processor. We
have tried to be consistent and to use "config" and "data" as often as possible.
You can for example call the XSLT transformer like this:
<p:processor name="oxf:xslt"> <p:input name="config" href="stylesheet.xsl"/> <p:input name="data" href="input.xml"/> <p:output name="data" id="my-output"/> </p:processor>
A pipeline can also be viewed as a processor. If that pipeline decides to
export inputs and outputs, it must do so using the <p:param
name="..."/> syntax. This defines its interface. You can compare this to
writing your own method in Java, as opposed to using an existing method. The
difference is that in Java, you address method parameters by position when you
call a method. In XPL, you always address them by name. Therefore it is
important to use the right name when you call a processor (or a pipeline).
This also applies to the cases where the Web Application Controller calls your
own pipelines: the PFC has to know the names of the inputs and outputs to
connect to. Therefore, you have to use the names ( data and
instance ) documented.
If you implement a pipeline or write a new processor in Java, and you don't
have any external naming constraints (such as the ones defined by the PFC, or
if somebody expects to call your pipeline using names defined in advance), you
are free to use any name.
In XPL an id can be assigned to an output when invoking a processor. This
id can then be used latter on in the same pipeline to refer to that specific
output, and for instance connect it to the input of another processor. Ids are
similar to variable names in most programming languages.
5. Other Orbeon PresentationServer FAQ
5.1. How can I improve the performance of my OPS application?
We provide below a list of tips that you might find helpful to improve the
performance of your OPS application.
-
Do not run your code in the examples portal. The OPS examples
portal (i.e. the home page of OPS, which lists all the OPS examples),
while convenient to run examples, is not implemented optimally and
relies on portlets which cause overhead. The first thing to do is make
sure that your code runs outside of the examples portal, i.e. that your
page flow entries are present in the main page flow file
(resources/page-flow.xml ).
-
Customize the standard epilogue. The standard OPS epilogue can be optimized for
your own needs. For example, if you do not use XForms Classic, you can remove the test
for the XForms classic engine; if you do not use "widgets", you can
remove the inclusion of xforms-widgets.xsl ; if you are not
using portlets (which is likely), you can remove the test for portlets.
-
Make sure you remove all your XPL debug attributes.
While using debug attributes is one of the best ways to
debug XPL pipelines, those also have an impact on performance as they
locally disable XPL caching and also require time to serialize XML
documents to your logger. For performance testing and production, always
remove all the debug attributes.
-
Don't serve your static files through OPS. It is overkill to
serve static files such as static images through OPS, which is optimized
to run XPL pipelines. Instead, use your servlet container's facilities
for serving static files, or even better, use a simple web server such
as Apache Server.
-
Use a performance analysis tool. To obtain your numbers, use a
tool such as Apache
JMeter. Be sure to warm up your Java VM first and to let the tool
run for a significant number of sample before recording your performance
numbers.
-
Make sure of what you are measuring. If you are testing the
performance of an application that talks to a database or backend
services, be sure to be able to determine how much time your front-end
or presentation layer, versus your backend and data layers, are
respectively taking.
5.2. I am concerned about the performance of OPS. Can you provide performance numbers please?
Orbeon does not provide performance figures at this point, due to the number of
different possible scenarios, the differences between hardware platforms, and
the different expectations of users. We believe that the best way to tackle
performance questions is to go beyond theory and work on a small but
representative prototype. Orbeon can help you build that prototype, a task often
done in just a few days. Upon completion of the prototype, you can evaluate
whether the performance of the prototype is satisfying or not, and if not Orbeon
can help you determine whether and how performance can be improved. The final
appreciation belongs to you.
5.3. What is the recommended XSLT transformer for OPS?
Saxon 8 is used by default within
OPS. It has proven reliable, and supports the latest XSLT 2.0 and XPath 2.0 drafts from the W3C.
OPS also ships with Saxon 6, Xalan 2.5 and XSLTC 2.5.
5.4. Isn't XSLT processing slow?
XSLT performance can vary greatly depending on the XSLT processor used. In
general, XSLT performance has shown perfectly adequate for all but the most
performance-intensive applications. This being said, OPS
minimizes the performance hit with its advanced cache, which for example caches
objects such as XSLT templates, therefore avoiding reparsing and revalidating
stylesheets unless absolutely necessary.
OPS also ships with XSLTC, an XSLT compiler now part of Apache
Jakarta. XSLTC has shown significant performance improvements over the regular
Xalan implementation, at the cost of a lack of maturity.
5.5. Is XSLTC a mature product?
XSLTC is not quite mature yet and caution must be exercised when using it. If
you plan to use XSLTC, we recommend extensive testing as well as switching back
and forth between XSLTC and the regular Xalan implementation during development
to ensure proper behavior. We also recommend submitting bugs to the Jakarta
project if necessary.
5.6.
Why am I getting an "org.dom4j.IllegalAddException" error?
The full message looks like:
org.dom4j.IllegalAddException: The node
"org.dom4j.util.UserDataElement@c11567 [Element: <gaga attributes:
[]/>] userData: null, line 0, column 0" could not be added to the branch
"null" because: Cannot add another element to this Document as it already
has a root element of: gaga
You get this error when you have a stylesheet that generate two or more root
elements. This tends to happen if your stylesheet does not match on "/". For
instance, say you have this stylesheet:
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="a"> <x/> </xsl:template> </xsl:stylesheet>
The XSLT output will be <x/><x/>, which is a not legal XML
document (of course, you can only have one root element in an XML document).
5.7.
How can I parse a string containing XML into a document that OPS can process?
Use the XSLT transformer and the
saxon:parse
function. This function parses an XML document supplied as a string and returns
a document node. To copy the resulting document to the output of your XSLT
transformation, use
xsl:copy . For example, assuming your input
document is as follows:
<document> <xml-string><name> <first>John</first> <last>Smith</last> </name> </xml-string> </document>
Consider also the following XSLT transformation:
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <xsl:copy-of select="saxon:parse(/document/xml-string)"/> </xsl:template> </xsl:stylesheet>
Running this transformation on the input document above generates the following
output:
<name> <first>John</first> <last>Smith</last> </name>
This tip is particularly useful for parsing XML strings returned by EJBs, Web
Services, or entered by a user in XForms textarea controls.
5.8.
What can I do if the application server hangs?
-
If your JVM is running but is not responding to HTTP requests, you
might first want to see where in the Java code threads are blocked. To do so, on
Windows hit ctrl-break in the command prompt window where your application
server is running; on Linux identify the process id of the JVM running
your application server and issue a kill -3 pid .
If you are using Tomcat and the threads are blocked in database code
(e.g. SQLProcessor, PoolingDataSource) open your server.xml ,
locate the element configuring the Coyote HTTP 1.1 Connector. Make sure
that the maxProcessors attribute on Tomcat 4.1 or the maxThreads
attribute on Tomcat 5 is set to a value that is much lower than the value of
the acceptCount attribute. Typically values for maxProcessor
or maxThreads are 3 for a single-CPU server or 4 for a dual-CPU server,
while the value of acceptCount can be much higher, typically between
50 and 100.
For more information on those and other attributes configuring the Coyote HTTP
1.1 Connector in general, see the
Tomcat 4.1
or Tomcat 5
documentation.
-
Some versions of Chainsaw have a bug where Chainsaw stops responding
in certain situations, which blocks the application server. If you are
using Chainsaw, this might be the problem: use the FileAppender
instead, or use Orbeon
Studio instead of Chainsaw to view log messages.
-
If you are running RedHat 9, set the environment variable
LD_ASSUME_KERNEL=2.4.1 and restart the application server.
5.9.
What can I do about the error "Cannot output a namespace node for the default
namespace when the element is in no namespace"?
This is a Saxon issue. It might happen when in the input document of a
stylesheet or in the output of the stylesheet you have an element declared with
no prefix as the child of an element with a prefix. One way to get around this
is to add a prefix to all the element having a parent declared with a prefix.
5.10.
Where can I find more information about XUpdate?
Efforts around the XUpdate language appear to be stalled. XML databases now
tend to bid on proprietary extensions to the standard XQuery language (e.g. see
what Tamino does, and there are talks about implementing something similar in
the open source eXist database). In the future, XQuery will support standard
update features, but that is probably years away.
We do recognize that XUpdate has definite advantages over XSLT in certain use
cases (which is why we implemented it in the first place), but it seems that the
market is currently not supporting what is considered "yet another XML
transformation language".
For use as a general-purpose XML update language with Orbeon Presentation
Server, we now recommend using XSLT. Use either XSLT 1.0 or XSLT 2.0 (12
November 2003 Draft as implemented by Saxon) instead of using the XUpdate
processor. The only place where XUpdate is not deprecated is within Page Flow,
but only a subset of XUpdate is required and you can simply consider that it is
part of the Page Flow syntax.
This being said, our XUpdate implementation is functional and of course anybody
is free to use it or contribute to it. Like the rest of OPS, it
is available under the LGPL license.
5.11. How can I debug the XUpdate code in my page flow?
Insert at the very beginning of the in the XUpdate code those 3 lines to log the
instance being modified (instance of target page), the current instance, and
the output of the action pipeline:
<xu:message xmlns:xu="http://www.xmldb.org/xupdate">Instance of target page before XUpdate:<xu:copy-of select="/*"/> </xu:message> <xu:message xmlns:xu="http://www.xmldb.org/xupdate">Instance of this page:<xu:copy-of select="doc('oxf:instance')/*"/> </xu:message> <xu:message xmlns:xu="http://www.xmldb.org/xupdate">Action output:<xu:copy-of select="doc('oxf:action')/*"/> </xu:message>
Then as the very last instruction in the XUpdate code, add:
<xu:message xmlns:xu="http://www.xmldb.org/xupdate">Instance of target page after XUpdate:<xu:copy-of select="/*"/> </xu:message>
5.12.
Why am I getting a "Empty local name in SAX event" exception?
If this exception is thrown from the class TransformerImpl class in a Xalan
package (orbeon.apache.xalan.transformer ), a bug in Xalan is at
the source of the problem. Xalan calls the SAX startElement()
method with an attribute that has an empty local name.
Switching to Saxon will solve the problem. Saxon is now the default XSLT 1.0 and
XSLT 2.0 processor in OPS, and will get used when using oxf:xslt .
See the XSLT documentation for more information.
5.13.
Are JSR-168 portlets supported in OPS
The short answer: portlets are not officially "supported" at this time.
The long answer: there is a lot of code in OPS to support JSR-168. When
this code was written back in 2003, the JSR-168 specification was not final and
no JSR-168 container was available. So Orbeon developped a container based on
draft specifications for testing. This code is now used to run the examples
portal. Examples are actually using the portlet code and running as portlets,
and the examples portal is an early JSR-168 portal.
The current status is that there are some bugs in the implementation and that
due to high workload at Orbeon and lack of demand so far nobody has spent the
time to make this code work with actual JSR-168 container out there now that the
specification has been final for a while and that containers are available.
The great thing about OPS and portlets is that there is very little difference
between writing an application working in a portlet vs. a servlet. You can use
some particularities of portlets, like preferences, and you have to be careful
about paths to serve resources, but otherwise portlets are transparent to the
developer. This contrasts with many other web platforms. OPS example
applications that run within the examples portal can be trivially made working
outside of the portal (see the BizDoc example).
The bottom line is that there is some cleanup work, compatibility testing and
documentation work to do until support for JSR-168 works robustly and is
considered "supported" in OPS. Orbeon is hoping to find a sponsor for this
work.
5.14.
Why am I getting extra xml:base attributes on my documents?
This usually happens when you use XInclude. As per the XInclude
specification, such attributes are added upon inclusion. You can get rid of
them by using XSLT:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:import href="oxf:/oxf/xslt/utils/copy.xsl"/> <xsl:template match="@xml:base"/> </xsl:stylesheet>
5.15.
What should I do about the error message
ERROR: invalid console appender config detected, console stream looping when deploying to JBOSS:
This used to happen with JBoss 3.2.1 and OXF 2.2. The work around a the time
was to add -Dorg.jboss.logging.Log4jService.catchSystemOut=false to
the end of the JAVA_OPTS line in JBOSS_HOME/bin/run.bat. (run.sh on UNIX)
5.16.
I am getting frequent Out of Memory errors with OPS. What can I do?
Often, this is due to too many threads doing processing within OPS at the same
time. There is just a lot going on in OPS when a request is processed, including
typically several XSLT transformations.
Servlet containers like Tomcat, or application servers like WebLogic, by default
allow a very large number of concurrent threads to enter a servlet. For Tomcat,
the default is 200. This means that memory usage cannot be effectively bound. It
is enough to have a few requests slightly overlapping to cause extra memory
consuption that can lead to Out of Memory errors. In addition, extra memory
usage leads to poorer performance.
It is recommended to start by changing the container parameters that control
threads. With Tomcat (see the documentation),
try first:
- maxThreads="3"
- acceptCount="50"
This setting will set a small maximum of 3 concurrent requests, and 50 more
requests being queued. This will ensure that memory usage does not go out of
control.
Then, experiment with a tool like Apache JMeter to test load, and adjust those
parameters, as well as your virtual machine heap, until you get results that are
satisfactory as far as memory consumption and number of concurrent requests are
concerned.
Note that it is typical for Java virtual machines to have maximum heap sizes of
256 MB to 1 GB in production.
5.17. OPS Java stack traces are very long. Does that mean that performance is necessarily bad?
Java stack traces are indeed very long in OPS. This is due mainly to the nature
of XPL pipelines, which are implemented on top of the event-based SAX API.
In reality you cannot make any reasonable conclusion about performance just by
looking at the length of a typical stack trace: you would have in addition to
that to look at the pattern of execution of those methods. For example, if every
top-level method call was going through, say, 300 levels of method calls, this
would likely be an issue, but it is not the case in OPS. The bottom line is that
no, the length of a stack trace does not directly correlate with poor
performance.
To reach valid conclusions about performance, run a tool like Apache JMeter on your application.
5.18. Can JSP or other servlets share a session with OPS?
Yes, the Scope serializer
and Scope generator simply
use the Servlet (or Portlet) session to store and retrieve information.
6. Studio FAQ
6.1.
In Studio, how can I add my own VM arguments (e.g. heap size, debugging)
6.2.
In Studio, why is the Logging Events view always empty?
-
Make you don't have any "Address already in use" error in the Console
view when you start the application server. If you do, it means that you
already have another application (other program, or other OPS
application maybe deployed in the same application server) using the
same port. On Windows, you can use TCPView
to determine what application is using the port you mention in the
log4j.xml .
-
Make sure you don't have any filter setup in Logging Events view by
right-clicking on the "down arrow" icon and selecting "Filters".
-
To populate the Logging Events view, Studio connects to log4j, and
log4j listens on the port specified in the log4j.xml file.
There is nothing in the Studio preferences to tell Studio to which port
it should connect. Instead, Studio finds the port by looking at all the
log4j.xml files you have in all the open projects. It will then try to
connect to all the ports specified those files.
If log4j was able to listen on the port specified in your log4j.xml (see
point 1 above) and still no messages appear in the Logging Events view,
that might be because Studio cannot find your log4j.xml. So make sure
that this file is in an open project defined in the Studio. Also note
that if you modify this file outside of Eclipse with an external
program, Studio won't pick up that modification. In that case, in the
Navigator view, right click on the project that contains your log4j.xml
and choose Refresh. Right after this, events should start to appear in
the Logging Event view as you load pages in the browser.
|