RE: Extension Functions & Transformation Thread in J2EE. Passing Context to Extenuation Functions explicitly via Transformer

["Roytman, Alex" <ro...@peacetech.com>]

Garry,

In J2EE and similar system many things are sensitive to where (in what
context, thread) it got instantiated or on which thread they are running. In
some cases you cant even pass them from 
one thread to another because when queried by the other thread they will
yield different result 
Consider ThreadLocal for instance
Good example is a creation of javax.naming.InitialContext() which represents
EJB environment - it does not take any parameters but the resulting instance
will be bean specific etc. 

I you fix only the part of the bug which allows <xsl:.....> to access
undeclared parameter
and still let an extension to access a top level parameter which was not
declared in stylesheet but was set with transformer.setParameter() then it
will make it an easy way to pass information to an extension
So a bug will become a nice feature.

!!!! I hope there will be no change in setParameter() behavior - now it does
not rise any exception when we set undeclared parameter on transformer.
Changing it to rise an exception will be a disaster 


Alex



-----Original Message-----
From: Gary L Peskin [mailto:garyp@firstech.com]
Sent: Friday, March 09, 2001 12:46 PM
To: xalan-dev@xml.apache.org
Subject: Re: Extension Functions & Transformation Thread in J2EE.
Passing Context to Extenuation Functions explicitly via Transformer


> "Roytman, Alex" wrote:
> Transformation thread created by Xalan does not inherit any properties
> of the thread where transformer was created. This prevents Xalan
> extensions from getting proper context provided by J2EE containers
> (i.e. InitialContext etc.) which is associated with invoking thread.
> PS
> Are you using one threads in Xalan1?
> All my extensions which rely on new InitialContext() being thread
> specific
> work just fine under Xalan1. Of course they break with Xalan2

Hi, Alex --

I'm not sure what you mean here.  If you mean that your extensions rely
on being able to tie a specific InitialContext to a particular
transformer, can't you just pass in your transformer (ie thread)
-specific information with a parameter in setParameter.

> Do you think it might be a good idea to allow to set attributes for
> transformer
> 
> myTransformer.setAttribute(String name, Object value);
> 
> so they can be accessed in an extension function/element
>
> I believe it will be very useful apart from second thread related
> issues.

Can't you do this with setParameter?

> I noticed that if we do myTransformer.setParameter(name, value)
> this parameter is accessible by both <xsl:value-of> and
> XPathContext.getVariable()
> even though it was not declared in the stylesheet - no errors/warnings
> raised
> Is it intended behavior or just a bug? If it is a bug would you fix it
> for both
> <xsl:value-of>  and XPathContext.getVariable()? may be you can let
> XPathContext.getVariable() to access it?

This is a bug.  I have entered into bugzilla as bug 914.  I'm working on
a fix which should be uploaded shortly (I hope!).  Look for the bugzilla
postings to the list for bug 914.

Gary

Re: Extension Functions & Transformation Thread in J2EE. Passing Context to Extenuation Functions explicitly via Transformer

[Gary L Peskin <ga...@firstech.com>]

> "Roytman, Alex" wrote:
> 
> Garry,
> 
> In J2EE and similar system many things are sensitive to where (in what
> context, thread) it got instantiated or on which thread they are
> running. In some cases you cant even pass them from
> one thread to another because when queried by the other thread they
> will yield different result
> Consider ThreadLocal for instance
> Good example is a creation of javax.naming.InitialContext() which
> represents EJB environment - it does not take any parameters but the
> resulting instance will be bean specific etc.
> 
> I you fix only the part of the bug which allows <xsl:.....> to access
> undeclared parameter
> and still let an extension to access a top level parameter which was
> not declared in stylesheet but was set with transformer.setParameter()
> then it will make it an easy way to pass information to an extension
> 
> So a bug will become a nice feature.
> 
> !!!! I hope there will be no change in setParameter() behavior - now
> it does not rise any exception when we set undeclared parameter on
> transformer. Changing it to rise an exception will be a disaster
> 
> Alex

Alex --

I haven't changed setParameter() at all.  But I think that getVariable()
is changed in that it will now work correctly.  In other words, it will
return an error message if your parameter set with setParameter() has
not be "received" by your stylesheet.  This is in keeping with the XSLT
Spec section 11.6:  "It is not an error to pass a parameter x to a
template that does not have an xsl:param element for x; the parameter is
simply ignored."

To rememdy this, you should include an xsl:param at the top level of
your stylesheets to receive the parameter you are passing with
setParameter.  Otherwise, it is "simply ignored.".

You should, however, be able to get to it with
Transformer.getParameter().  This is just a standard part of TRaX.

Gary