cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Want the oppurtunity to discuss enhancements to PTC products? Join a working group! X

Clearing PE Cache

ptc-3050150
1-Newbie

Clearing PE Cache

Is there a way to clear the PE template cache?

Probably this one:

• class com.arbortext.e3.TransformedStylesheetCache, ID stylesheet-cache. Caches transformed stylesheets in anticipation of composition requests

I'm finally to the point I can edit some stylesheets located on the PE and...it keeps caching them. I even deleted the one I'm working on and it still says there's an error on line 7!

I don't have access to the PE, took an act of Congress to get IT to restart it once...and there is this really nice Advanced Transaction Options box but the docs (as far as I've found) say to enter whatever your PE administrator tells you to.

Thanks!

8 REPLIES 8


I see this as a big flaw in the PE design. This
coupled with the fact that it doesn't work the
same as publisher makes it very difficult to test
and develop with PE in shops with extremely paranoid IT types.

I'm assuming you don't have access to the PE web
page. That does allow you to restart and clear
the cache. I have found that nothing short of
restarting the server seems to allow the introduction of a new dtd/fosi.

sorry this probably doesn't help, but I think it
is a big design issue that PTC should address.

..dan

John,
Do you have access to restart the Tomcat Services? That does it for me.
Otherwise compose locally with out using PE, if that is an option.

Ellen

John Jarrett <-> wrote on 12/29/2009 03:04:39
PM:

> Is there a way to clear the PE template cache?
> Probably this one:
> • class com.arbortext.e3.TransformedStylesheetCache, ID stylesheet-
> cache. Caches transformed stylesheets in anticipation of composition
requests
> I'm finally to the point I can edit some stylesheets located on the
> PE and...it keeps caching them. I even deleted the one I'm working
> on and it still says there's an error on line 7!
> I don't have access to the PE, took an act of Congress to get IT to
> restart it once...and there is this really nice Advanced Transaction
> Options box but the docs (as far as I've found) say to enter
> whatever your PE administrator tells you to.
> Thanks!

Thanks for your help.

We don't appear to have Tomcat installed on our Windows server which makes tracing down errors...interesting.

I was able to do it with the PE "homepage" at http://localserver:8282/e3 via the Reload Subprocesses link.

At some point, limited access to the PE should be granted to the editor so that large shops with super-tight IT can't totally cut users off from the PE. You can change the composer log file via the command line in the editor already - clearing cache and buffers sounds like it would be easy to add and a real help to some of us developers...not to mention things like restarting the PE.

I say you can change the logging settings...I can't get it to log more than the log file name (creates a zero byte file) to my local drive.

John

Well I lied - now that Rescan isn't clearing out the PE cache anymore.

Can I ask you a quick one or two?

a. In a stylesheet test, is ">" really valid? Not "GT" or ">"????

Example: <xsl:when test="$named.colnum"> 0">

b. Does this error mean anything to you?

org.xml.sax.SAXParseException: Cannot convert string " to a double
in "file:/E:/Program%20Files/PTC/Arbortext%20PE/custom/doctypes
/Production/table-v1_5.xsl" Line: 417

c. Do you happen to have a cute (or ugly) quick reference file to remind yourself how to handle errors? I've started one, but am slow learning one by one (like empty uri crash in a graphics xsl = some idiot didn't bother to link to an actual graphic in boardno)

Happy New Years...hear yours is gonna be colder than ours - 67 degree high tomorrow!

John T. Jarrett
-
Down in Sealy, Texas

At 04:38 PM 12/30/2009, Jarrett, John T. (External) wrote:
>Well I lied - now that Rescan isn't clearing out the PE cache anymore.
>
>Can I ask you a quick one or two?
>
>a. In a stylesheet test, is ">" really valid? Not "GT" or ">"????
>
> Example: <xsl:when test="$named.colnum"> 0">

GT definitely is wrong , just checked > is the correct way (only way)


>b. Does this error mean anything to you?
>
> org.xml.sax.SAXParseException: Cannot convert string " to a double
> in "file:/E:/Program%20Files/PTC/Arbortext%20PE/custom/doctypes
>/Production/table-v1_5.xsl" Line: 417

it's a conversion issue, what is on line 417? something is getting an
empty string that wants a number. For pure xsl questions there is
a better group, they generally don't know Arbortext, but you have
the experts on xsl at
XSL-List info and archive:

RE: seeing the intermediate FO instance when publishing XSL-FO output on
PE:

There are a couple of ways to do this:

a) Don't compose for PDF, but instead compose using XSL and select your
stylesheet as the XSL. Then you can select the filename for the
transformed output and where it is stored. (It will assume at first that
you want HTML output, but just change .htm to .fo.xml in the filename
and you should be OK.)

If you do it that way, you can then test the rendering by opening the FO
instance in Arbortext and issuing the "compose_fo_pdf" commmand in the
Arbortext command window. (If you haven't published yet in the session,
you might need to do a "require pub_xslfo" first.)

b) You can compose for PDF using PE, and then check the job archive for
the job. This works fine in a non-production environment; if your PE
server is a busy production environment, then you might have to do some
digging in the job archive to identify which job is yours. But if you
find the right job, the intermediate FO instance should be in the
archive. You access the job archive through the PE admin web pages. I
forget the exact URL, but I recall that it's pretty easy to find from
the main admin page.

Also, you want to be careful trying to debug with other (non-Arbortext)
rendering engines. For big kinds of errors, like invalid FO markup
generated by a stylesheet, that can work OK, and in some cases other
tools might do a better job of reporting that sort of thing. But my
experience is that the really thorny problems are usually either a)
noodly little things that are ambiguous in the spec, which can be
implemented differently by different engines, or b) extensions that are
implemented differently by different engines (such as indexing or server
graphics handling). In either case, trying to debug on some other
platform can lead you astray or mask a problem that may be
Arbortext-specific.

One technique I've found useful is to do this:

1) generate the FO instance as described in option a) above
2) use the compose_fo_pdf command to generate a baseline PDF
3) tweak the FO instance directly at a particular example to test
different hypotheses, e.g. exactly which element should I put that
margin-left property on to get the desired effect?
4) use compose_fo_pdf to generate a new PDF to see the result of the
tweak
5) repeat steps 3 & 4 as necessary until the right combination is found
6) then update the XSL-FO stylesheet so it generates the combination you
discovered.

HTH.

--Clay

At 07:45 PM 12/30/2009, you wrote:
>Also, you want to be careful trying to debug with other (non-Arbortext)
>rendering engines. For big kinds of errors, like invalid FO markup
>generated by a stylesheet, that can work OK, and in some cases other
>tools might do a better job of reporting that sort of thing. But my
>experience is that the really thorny problems are usually either a)
>noodly little things that are ambiguous in the spec, which can be
>implemented differently by different engines, or b) extensions that are
>implemented differently by different engines (such as indexing or server
>graphics handling). In either case, trying to debug on some other
>platform can lead you astray or mask a problem that may be
>Arbortext-specific.

thanks for the ideas. I had indicated that the final work would
require using PE, no way to avoid that.

The start of this thread had to do with IT locking down access to the
PE server to be able restart and such. In this environment even the
simplest of testing can be painful - access to logs, you got to be
kidding! So that with the added benefit of different error messages
make having alternate engines to test with very useful. It also can
help pinpoint if the issue is a standards compliance or a bug. John
indicated he inherited a new stylesheet that may or may not have been
built for PE - he hasn't confirmed the source system (and may not
know). I took it to be that the stylesheet was supposed to be tested
and correct and was having troubles integrating it into the local PE
environment.

Anyway, it is always good to have multiple tools, but ultimately you
have to make it work in the final production environment.

..dan
---------------------------------------------------------------------------
Danny Vint

Panoramic Photography

Sometimes you can get more meaningful error information from PE through PE
Interactive. This, of course, requires access to the server OR a development
install somewhere you have access (AND a reproducible error of course).

Specifically, start PE Interactive on the PE server.
Issue the following command from the PE Interactive command line:
set peservices=off
Open the content causing the problem (having made it available to the server
first, of course).
Submit the composition request.
Watch the fun.

Hope I didn't miss this suggestion earlier in the thread ... this holiday
stuff has flushed a few caches between my ears.

Top Tags