xforge-users — X:Forge users list

[Xforge-users] installation help

[Tri D. T. <tri...@fr...>]

HI,
I'm a junior ingenior, I would like to install x:forge to test it and use
it.
I could'nt find any documents on x:forge website.
Could you help me please?

Thanx a lot
Tran Tri Duc

[Xforge-users] Much new stuff checked into xforge_3_0_branch

[Ulrich M. <ul...@de...>]

Hello,

I've updated Avalon Framework, Excalibur, LogKit etc. to the newest, 
officially released versions. I had to make a number of changes in 
various files in order to make it work. Most notably, XForgeProcessor 
now uses two Loggers internally (transparent to the user), one 
org.apache.log.Logger and one org.apache.avalon.framework.logger.Logger.

Reason is that the released version of ExcaliburComponentManager does 
not work with new-style logging. There are now additional deprecation 
warnings, because ECM is now deprecated in favor of Fortress. However, 
as Fortress is not released yet, I'll wait until then for upgrading from 
ECM to Fortress.

Besides the new Avalon JARs I also checked in commons-collections.jar 
and concurrent.jar. Both are now needed by ECM, previously it used 
Excalibur collections and concurrency, but the Excalibur versions were 
abolished in favor of more standard libraries.

I'll have to update a number of docs now to reflect changes in 
components.xml and Test.java, but the code is ready and checked in and 
the user experience should be identical to before.

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

[Xforge-users] Work in Progress

[Ulrich M. <ul...@de...>]

I'm currently changing things in a lot of places, but can't check in 
yet. Please nobody play on the sources of 3.0-branch before asking.

Perhaps I could lock the files, but since nobody probably works on the 
sources anyway at this moment, I think I could save that trouble :)

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

[Xforge-users] Keyed Object Pools

[Ulrich M. <ul...@de...>]

Hello,

I asked on the Avalon mailing list what to do if we want to pool objects 
with a certain key (like Transformers with the stylesheet URI as key). 
The answer was:

"Wander over to commons and grab the commons-pool package. There is a
KeyedObjectPool over there. Make the stylesheet the key and voila`!"

I looked at it, they even have some docs :)

Here is the link:
http://jakarta.apache.org/commons/pool/api/index.html

Seems like this could work for us, we'd have to throw out Excalibur Pool 
and replace it with this Pool. I have no idea whether that is possible 
easily or whether we have to change the component manager.

Also we'd need to have some type of configuration in components.xml 
where we can specify whether we want a KeyedPool or not and what the key is.

What do you think?

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

[Xforge-users] fixed bug in XSLComponent

[Ulrich M. <ul...@de...>]

Hello,

I fixed the bug in the XSLComponent, where sometimes the wrong 
stylesheet was applied, when doing multiple transforms in one X:Forge 
pass. This is until we have a better solution for cacheing stylesheets.

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Re: [Xforge-users] Re: Monitoring/Cacheing

[Ulrich M. <ul...@de...>]

> Ulrich Mayring wrote:
> 
> 1) Make a TransformerComponent. It will always know, when it has changed 
> via a simple FileMonitor.
> 
> 2) Invent a way to pass objects instead of Strings with the 
> <xf:parameter> element.
> 
> 3) Now the XSLComponent can implement Unchangeable, because changes only 
> occur, when the transformer component changes.

Suppose we implement this and have the following code:

<xsl:apply>

<xf:parameter name="xml"><foo>bar</foo></xf:parameter>
<xf:parameter name="xsl" type="object">
     <transformer:get>
         <xf:parameter>test1.xsl</xf:parameter>
     </transformer:get>
</xf:parameter>

</xsl:apply>

...

<xsl:apply>

<xf:parameter name="xml"><foo>bar</foo></xf:parameter>
<xf:parameter name="xsl" type="object">
     <transformer:get>
         <xf:parameter>test2.xsl</xf:parameter>
     </transformer:get>
</xf:parameter>

</xsl:apply>

The Transformer component is first called with test1.xsl, then with 
test2.xsl. It needs to keep an internal Hashtable of all transformers it 
creates and when it receives a request for a specific transformer it 
either already has it and returns it or it creates it and saves it 
internally.

However, we have no way of knowing which Transformer component is 
returned by the component manager, so *all* Transformer components have 
to have the same internal Hashtable of transformers. This has two 
disadvantages:

1) Potential for a lot of duplication (every Transformer components 
needs to save every transformer internally).

2) Unnecessary creation of a new transformer (several Transformer 
components may already have it, but the one that is returned to us 
doesn't have it).

Any ideas?

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

[Xforge-users] building site and docs targets

[Ulrich M. <ul...@de...>]

Hello,

I've indeed found a way to make the process transparently via ant 
filters. So now only book.xml exists and has a @SOURCEFORGELOGO@ token, 
which will be replaced by "" when building docs and 
"<separator/><sourceforgelogo/>" when building site.

cheers,

Uli

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

[Xforge-users] New target in build.xml

[Ulrich M. <ul...@de...>]

Hello,

I've added a new target "site" to build the website. The only difference 
to building "docs" is that the Sourceforge logo is included. Reasoning:

When building docs locally, you don't want the Sourceforge logo, because 
it lives at Sourceforge and you may not have or want a connection to the 
Internet just because of the stupid logo.

Unfortunately the solution is not elegant, because I had to add a new 
file book-site.xml, which is identical to book.xml with the exception of 
the logo.

So, making a new entry in the book file means we have to update both: 
book.xml (for the docs) and book-site.xml (for the site). I am 
researching a better solution, but it's good enough for now.

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

[Xforge-users] New Docs are up

[Ulrich M. <ul...@de...>]

Hello,

I just uploaded the newest docs and javadocs manually to the project 
homepage, check it out :)

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Re: [Xforge-users] Project Homepage

[Ulrich M. <ul...@de...>]

Alberto Garoffolo wrote:

>>could you make a crontab entry for rebuilding the docs every night for 
>>the project homepage? I'm still making changes (fixing typos, 
>>standardizing headlines, fixing examples etc.) pretty frequently.
> 
> I don't know if it' s possible to do it in sf. Do you have any idea?
> Do you have access ssh access to xforge in shell.sourceforge.net ?

Looks like it is not possible, as there is no cvs access from the 
compile farm and it's not allowed to build on the shell server.

I'm currently trying to upload my ssh key to Sourceforge, so I can log 
in without password. If that works I could make a crontab entry on my 
local machine to build locally and upload to Sourceforge automatically.

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Re: [Xforge-users] Project Homepage

[Ulrich M. <ul...@de...>]

Alberto Garoffolo wrote:
>>Also, there's still a wrong link to www.xforge.org at 
>>http://sourceforge.net/docman/display_doc.php?docid=11558&group_id=34689

Fixed this.

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Re: [Xforge-users] Project Homepage

[Ulrich M. <ul...@de...>]

Ulrich Mayring wrote:
> 
> I thought only project administrators have shell access, but I just 
> tried to login and it worked. I'll try to set it up myself now.

Oh, I just see now that I can access the admin pages, even though I'm 
not a project administrator.

This is good, because I need a lot of settings for setting up the web 
pages and they're only listed in the admin section.

Also, we should include the Sourceforge logo on our project web pages. 
Starting yesterday they are now using only this logo to count hits. I'll 
set this up.

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Re: [Xforge-users] Project Homepage

[Ulrich M. <ul...@de...>]

Alberto Garoffolo wrote:
> ----- Original Message ----- 
> From: "Ulrich Mayring" <ul...@de...>
> To: "xforge-users Mailinglist" <xfo...@li...>
> Sent: Monday, February 17, 2003 8:16 PM
> Subject: [Xforge-users] Project Homepage
> 
> 
> 
>>Hello Alberto,
>>
>>could you make a crontab entry for rebuilding the docs every night for 
>>the project homepage? I'm still making changes (fixing typos, 
>>standardizing headlines, fixing examples etc.) pretty frequently.
>>
> 
> I don't know if it' s possible to do it in sf. Do you have any idea?
> Do you have access ssh access to xforge in shell.sourceforge.net ?

Hello Alberto,

I thought only project administrators have shell access, but I just 
tried to login and it worked. I'll try to set it up myself now.

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Re: [Xforge-users] Project Homepage

[Alberto G. <alb...@ge...>]

----- Original Message ----- 
From: "Ulrich Mayring" <ul...@de...>
To: "xforge-users Mailinglist" <xfo...@li...>
Sent: Monday, February 17, 2003 8:16 PM
Subject: [Xforge-users] Project Homepage


> Hello Alberto,
> 
> could you make a crontab entry for rebuilding the docs every night for 
> the project homepage? I'm still making changes (fixing typos, 
> standardizing headlines, fixing examples etc.) pretty frequently.
> 
I don't know if it' s possible to do it in sf. Do you have any idea?
Do you have access ssh access to xforge in shell.sourceforge.net ?

> Also, there's still a wrong link to www.xforge.org at 
> http://sourceforge.net/docman/display_doc.php?docid=11558&group_id=34689
> 
> Now, another thought: the docs are clearly for version 3.0, which is not 
> yet released. Should I add a message on the index page, that this 
> version is only downloadable from cvs? And that we recommend it over 
> 2.0? (don't know the state of 2.0, I've never used it).
+1

Ciao,
---
Alberto.

Re: [Xforge-users] Re: Monitoring/Cacheing

[Ulrich M. <ul...@de...>]

Alberto Garoffolo wrote:
> 
> Here is, in my opinion, a misunderstanding (also related to (1)):
> If someone changes the input xml (for example test.xml) , 
> all the trasformation must be re-performed. We have no way to know
> if and what is changed inside the xml. We can only ask to our components
> if, with *unchanged input*, something external has changed.

Yes, I agree with you. But that means we still need a way to find out 
whether the input XML has changed. Because only if it hasn't changed, we 
should use the monitoring system.

And since we don't know whether the input XML is a file or a stream or 
something else, we need a very generic mechanism to monitor it.

My suggestion with monitoring static tags is meant for exactly that 
problem. It is a little overkill and I'd prefer something simpler, but 
currently I have no other idea how to monitor the input XML.

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Re: [Xforge-users] Re: Monitoring/Cacheing

[Alberto G. <alb...@ge...>]

----- Original Message ----- 
From: "Ulrich Mayring" <ul...@de...>
To: "xforge-users Mailinglist" <xfo...@li...>
Sent: Monday, February 17, 2003 6:51 PM
Subject: [Xforge-users] Re: Monitoring/Cacheing


> Ulrich Mayring wrote:
> 
> > Alberto Garoffolo wrote:
> > 
> >> The disadvantage is to re-run a component also if changed
> >> another component used in that request. To avoid this we
> >> should watch at the problem in a more general way; for
> >> example (1) thinking about cacheing each component sax result.
> >> For example:
> >>
> >> <test>
> >>     <comp1:dosomething>
> >>         <xf:param name="param1">
> >>             <comp2:dosomething/>
> >>         </xf:param>
> >>     </comp1:dosomething>
> >>
> >>     <comp3:dosomething>
> >>         <xf:param name="param1">
> >>             <comp4:dosomething/>
> >>         </xf:param>
> >>     </comp1:dosomething>
> >> </test>
> >>
> >> If comp2 changes, we must invalidate all it' s ancestors results,
> >> but we can reuse the ouput of comp3.
> 
> You cannot always assume a hierarchical structure, look at this example:
> 
> <mycomponent1:setDatabase>
>    <xf:parameter name="dbname">PRODUCTION_DB</xf:parameter>
> </mycomponent1:setDatabase>
> 
> <mycomponent2:getContactFromDB>
>    <xf:parameter name="contactId">12345</xf:parameter>
> </mycomponent2:getContactFromDB>
> 
> Suppose someone changes "PRODUCTION_DB" to "DEV_DB". It is quite 
> possible that the contact with ID 12345 is a different person in DEV_DB 
> or may not even exist there.
> 
(1)

> So, we need to monitor arbitrary XML elements (which would also include 
> the <xf:parameter> element). But we cannot, for example, refer up the 
> tree or sideways, that would violate IOC.
> 
> Therefore, instead of defining monitors locally to components, they must 
> be defined centrally. Basically we need something like the Sitemap in 
> Cocoon. But since I don't like the Cocoon Sitemap concept (it basically 
> brought me to X:Forge) I won't do it ;-)
> 
> The answer IMHO is to design components correctly. The above example is 
> a braindead design and so is the XSLComponent. A better design would be 
> this:
> 
> 1) Make a TransformerComponent. It will always know, when it has changed 
> via a simple FileMonitor.
> 
> 2) Invent a way to pass objects instead of Strings with the 
> <xf:parameter> element. For example:
> 
> <xsl:apply>
> 
> <xf:parameter name="xml">
> <!-- will be passed as String -->
> <foo:bar/>
> </xf:parameter>
> 
> <xf:parameter name="xsl" type="object">
> <!-- will be passed as Object -->
> <transformer:get>
> <xf:parameter>
> test.xsl
> </xf:parameter>
> </transformer:get>
> </xf:parameter>
> 
> </xsl:apply>
> 
I thought the same thing :)
I totally agree with you! 

> 3) Now the XSLComponent can implement Unchangeable, because changes only 
> occur, when either the transformer component or the foo component 
> changes. This solves all problems except where the XML input is at least 
> partly static like here:
> 
> <xf:parameter name="xml">
> <list1>
> <foo:bar/>
> </list1>
> </xf:parameter>
> 
> Suppose <foo:bar/> is unchangeable, but someone changes "list1" to 
> "list2", so that after stylesheet application he gets a different layout.
> 
Here is, in my opinion, a misunderstanding (also related to (1)):
If someone changes the input xml (for example test.xml) , 
all the trasformation must be re-performed. We have no way to know
if and what is changed inside the xml. We can only ask to our components
if, with *unchanged input*, something external has changed.

[...]


Ciao,
---
Alberto.

[Xforge-users] Project Homepage

[Ulrich M. <ul...@de...>]

Hello Alberto,

could you make a crontab entry for rebuilding the docs every night for 
the project homepage? I'm still making changes (fixing typos, 
standardizing headlines, fixing examples etc.) pretty frequently.

Also, there's still a wrong link to www.xforge.org at 
http://sourceforge.net/docman/display_doc.php?docid=11558&group_id=34689

Now, another thought: the docs are clearly for version 3.0, which is not 
yet released. Should I add a message on the index page, that this 
version is only downloadable from cvs? And that we recommend it over 
2.0? (don't know the state of 2.0, I've never used it).

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

[Xforge-users] Re: Monitoring/Cacheing

[Ulrich M. <ul...@de...>]

Ulrich Mayring wrote:

> Alberto Garoffolo wrote:
> 
>> The disadvantage is to re-run a component also if changed
>> another component used in that request. To avoid this we
>> should watch at the problem in a more general way; for
>> example (1) thinking about cacheing each component sax result.
>> For example:
>>
>> <test>
>>     <comp1:dosomething>
>>         <xf:param name="param1">
>>             <comp2:dosomething/>
>>         </xf:param>
>>     </comp1:dosomething>
>>
>>     <comp3:dosomething>
>>         <xf:param name="param1">
>>             <comp4:dosomething/>
>>         </xf:param>
>>     </comp1:dosomething>
>> </test>
>>
>> If comp2 changes, we must invalidate all it' s ancestors results,
>> but we can reuse the ouput of comp3.

You cannot always assume a hierarchical structure, look at this example:

<mycomponent1:setDatabase>
   <xf:parameter name="dbname">PRODUCTION_DB</xf:parameter>
</mycomponent1:setDatabase>

<mycomponent2:getContactFromDB>
   <xf:parameter name="contactId">12345</xf:parameter>
</mycomponent2:getContactFromDB>

Suppose someone changes "PRODUCTION_DB" to "DEV_DB". It is quite 
possible that the contact with ID 12345 is a different person in DEV_DB 
or may not even exist there.

So, we need to monitor arbitrary XML elements (which would also include 
the <xf:parameter> element). But we cannot, for example, refer up the 
tree or sideways, that would violate IOC.

Therefore, instead of defining monitors locally to components, they must 
be defined centrally. Basically we need something like the Sitemap in 
Cocoon. But since I don't like the Cocoon Sitemap concept (it basically 
brought me to X:Forge) I won't do it ;-)

The answer IMHO is to design components correctly. The above example is 
a braindead design and so is the XSLComponent. A better design would be 
this:

1) Make a TransformerComponent. It will always know, when it has changed 
via a simple FileMonitor.

2) Invent a way to pass objects instead of Strings with the 
<xf:parameter> element. For example:

<xsl:apply>

<xf:parameter name="xml">
	<!-- will be passed as String -->
	<foo:bar/>
</xf:parameter>

<xf:parameter name="xsl" type="object">
	<!-- will be passed as Object -->
	<transformer:get>
		<xf:parameter>
			test.xsl
		</xf:parameter>
	</transformer:get>
</xf:parameter>

</xsl:apply>

3) Now the XSLComponent can implement Unchangeable, because changes only 
occur, when either the transformer component or the foo component 
changes. This solves all problems except where the XML input is at least 
partly static like here:

<xf:parameter name="xml">
	<list1>
		<foo:bar/>
	</list1>
</xf:parameter>

Suppose <foo:bar/> is unchangeable, but someone changes "list1" to 
"list2", so that after stylesheet application he gets a different layout.

Right now static (non-namespace prefixed tags) are simply converted into 
SAX events (parent.startElement(...) etc.).

Perhaps we could design a generic component, which is responsible for 
all tags that have no namespace prefix (i.e. static tags). It could 
generate the SAX events like now, but have additional features:

1) It could implement Monitorizable and the getMonitor() method would 
return "this".
2) It could implement Monitor and the lastModified() method would return 
an internal timestamp.
3) The timestamp would be set on the first invocation and updated to 
now, whenever the current SAX events are different from the SAX events 
generated by the last invocation.

Now, is this totally stupid or what? :)

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Re: [Xforge-users] ProcessingOptions

[Ulrich M. <ul...@de...>]

Alberto Garoffolo wrote:
> ----- Original Message ----- 
> From: "Ulrich Mayring" <ul...@de...>
> To: "xforge-users Mailinglist" <xfo...@li...>
> Sent: Friday, February 14, 2003 6:08 PM
> Subject: [Xforge-users] ProcessingOptions
> 
> 
> 
>>Hello,
>>
>>the new ProcessingOptions system is now in CVS.
>>
> 
> Hi Ulim, 
> 
> Now encoding and more in general trasformation options  
> are very easy to be located and retrieved.
> 
> Our project activity percentile will jump to 100% after
> this update !!! :-)

We're #3251 (70.422%) for last week already (of 10988 total projects), 
but I think to get to 100.00% we need more downloads and page views, not 
just cvs commits :)

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Re: [Xforge-users] ProcessingOptions

[Alberto G. <alb...@ge...>]

----- Original Message ----- 
From: "Ulrich Mayring" <ul...@de...>
To: "xforge-users Mailinglist" <xfo...@li...>
Sent: Friday, February 14, 2003 6:08 PM
Subject: [Xforge-users] ProcessingOptions


> Hello,
> 
> the new ProcessingOptions system is now in CVS.
> 
Hi Ulim, 

Now encoding and more in general trasformation options  
are very easy to be located and retrieved.

Our project activity percentile will jump to 100% after
this update !!! :-)

Ciao,
---
Alberto.

[Xforge-users] ProcessingOptions

[Ulrich M. <ul...@de...>]

Hello,

the new ProcessingOptions system is now in CVS.

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Re: Monitoring/Cacheing (was: Re: [Xforge-users] New Feature implemented: FilesMonitor)

[Ulrich M. <ul...@de...>]

Alberto Garoffolo wrote:
> Hi,
> 
> IMHO cacheing/monitoring implemented in XSLComponent
> overlaps with the native X:Forge monitoring system.

Yes, unfortunately.

> X:Forge monitoring system philosophy is: Components
> doesn' t have to care about changes, when they are invoked
> they just produce xml and, if they are monitorizable,
> return a monitor which checks if the resources used in the
> *current request* change. If monitored resources for a
> specific request aren' t changed, associated components
> will not be called at all.

Ok.

> In the new XSLComponent version, there is also the possibilty
> to monitor the whole xml file used by x:forge. In my opinion
> this should be done by the generator/producer/"who loads the file"
>  in a cocoon/servlet like system.
> 
> Transformer cache in XSLComponent, doesn' t consider that a
> single Component instance can be used to apply different stylesheets:
 >
> <bug>
[...]
> </bug>
> The third trasformation will apply test2.xsl instead of test.xsl.

Hmm... I haven't tried it, but I think you're right that there's a bug.

> As u can see to make it work correctly, more code has to be
> written in the xslcomponent, weighting down it a lot. Consider
> also that if we follow this philosophy, each component will reinvent
> the wheel each time needs to cache something.

I absolutely agree with you. It's just that I have no better solution :(

> The advantage of the X:Forge monitoring system philosphy is
> to make component logic easier and cleaner.
> 
> The disadvantage is to re-run a component also if changed
> another component used in that request. To avoid this we
> should watch at the problem in a more general way; for
> example (1) thinking about cacheing each component sax result.
> For example:
> 
> <test>
>     <comp1:dosomething>
>         <xf:param name="param1">
>             <comp2:dosomething/>
>         </xf:param>
>     </comp1:dosomething>
> 
>     <comp3:dosomething>
>         <xf:param name="param1">
>             <comp4:dosomething/>
>         </xf:param>
>     </comp1:dosomething>
> </test>
> 
> If comp2 changes, we must invalidate all it' s ancestors results,
> but we can reuse the ouput of comp3.
> This is just an idea ...
> 
> But probably u need even something more: You want to cache
> one of the params passed to the component (in this case the
> Transfomation object created parsing the xsl) .... This is more
> difficult ...
> Hhhhmmm .... Do u really need it ( considered (1) ) ? :)

Stylesheet creation is an expensive operation and in many real-world 
scenarios you must be able to do it. Consider a Cocoon-like system, 
where you have many users accessing a page at the same time. If you have 
to recreate the transformer each time, it takes 2 seconds longer to wait 
for the user on every request. On the other hand the system has to pick 
up changes to the stylesheet and the XML files being transformed, 
because in a production scenario you can't constantly restart your 
application.

I'm absolutely in favor of solving this problem outside of the XSL 
component, but currently have no idea how to change the monitoring 
system, so that it supports such things. If you want we can do some 
brainstorming:

Maybe we need a FileComponent, which we can pass as parameter to the 
XSLComponent. The FileComponent could return a FileMonitor in its 
getMonitor() method, the XSLComponent could return a ComponentMonitor 
for the passed FileComponent. The ComponentMonitor's getLastModified() 
method would return this.component.getMonitor().getLastModified().

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Monitoring/Cacheing (was: Re: [Xforge-users] New Feature implemented: FilesMonitor)

[Alberto G. <alb...@ge...>]

Hi,

IMHO cacheing/monitoring implemented in XSLComponent
overlaps with the native X:Forge monitoring system.
X:Forge monitoring system philosophy is: Components
doesn' t have to care about changes, when they are invoked
they just produce xml and, if they are monitorizable,
return a monitor which checks if the resources used in the
*current request* change. If monitored resources for a
specific request aren' t changed, associated components
will not be called at all.

In the new XSLComponent version, there is also the possibilty
to monitor the whole xml file used by x:forge. In my opinion
this should be done by the generator/producer/"who loads the file"
 in a cocoon/servlet like system.

Transformer cache in XSLComponent, doesn' t consider that a
single Component instance can be used to apply different stylesheets:
<code>
    if (hasChanged(mFiles[0])) {
        try {
            // Initialize a new Transformer
            log.debug("Initializing a new transformer.");
            StreamSource stylesheet = new StreamSource(mFiles[0]);
            mTransformer = mTransformerFactory.newTransformer(stylesheet);
            mTransformer.setParameter("lastModified",new
Long(mFiles[0].lastModified()));
            }
        catch (TransformerConfigurationException tce) {
            throw new XForgeException("Something wrong with the transformer:
" + tce.toString());
            }
    }
    else { log.debug("Using cached transformer."); }
[...]
    // do the transformation
    try {
            mTransformer.transform(src,dest);
        }
    catch (TransformerException te) {
            throw new XForgeException("Problem transforming " + xml + " with
" + xsl + ": " + te.toString());
        }
</code>

<bug>

 <xsltest1>
  <xsl:apply>
   <xf:parameter name="xml">
    <xsldate>
     <date:xmlnow/>
    </xsldate>
   </xf:parameter>
   <xf:parameter name="xsl">test/test.xsl</xf:parameter>
  </xsl:apply>
 </xsltest1>

 <xsltest2>
  <xsl:apply>
   <xf:parameter name="xml">
    <xsldate>
     <date:xmlnow/>
    </xsldate>
   </xf:parameter>
   <xf:parameter name="xsl">test/test2.xsl</xf:parameter>
  </xsl:apply>
 </xsltest2>

 <xsltest3>
  <xsl:apply>
   <xf:parameter name="xml">
    <xsldate>
     <date:xmlnow/>
    </xsldate>
   </xf:parameter>
   <xf:parameter name="xsl">test/test.xsl</xf:parameter>
  </xsl:apply>
 </xsltest3>

</bug>
The third trasformation will apply test2.xsl instead of test.xsl.

As u can see to make it work correctly, more code has to be
written in the xslcomponent, weighting down it a lot. Consider
also that if we follow this philosophy, each component will reinvent
the wheel each time needs to cache something.

The advantage of the X:Forge monitoring system philosphy is
to make component logic easier and cleaner.

The disadvantage is to re-run a component also if changed
another component used in that request. To avoid this we
should watch at the problem in a more general way; for
example (1) thinking about cacheing each component sax result.
For example:

<test>
    <comp1:dosomething>
        <xf:param name="param1">
            <comp2:dosomething/>
        </xf:param>
    </comp1:dosomething>

    <comp3:dosomething>
        <xf:param name="param1">
            <comp4:dosomething/>
        </xf:param>
    </comp1:dosomething>
</test>

If comp2 changes, we must invalidate all it' s ancestors results,
but we can reuse the ouput of comp3.
This is just an idea ...

But probably u need even something more: You want to cache
one of the params passed to the component (in this case the
Transfomation object created parsing the xsl) .... This is more
difficult ...
Hhhhmmm .... Do u really need it ( considered (1) ) ? :)



Ciao,
---
Alberto.

[Xforge-users] Context question

[Ulrich M. <ul...@de...>]

Hello,

I'm currently writing docs for Contexts and the MonitorsManager and have 
a question. In Test.java there is this code:


broker.startContextScope(threadcontext);
broker.putObject(threadcontext,"testfile",src);
...
broker.startContextScope(testcontext);
broker.startContextScope(varscontext);

parser.parse(is);

broker.endContextScope(varscontext);
broker.endContextScope(testcontext);
...
broker.endContextScope(threadcontext);

In the XSLComponent I retrieve the "testfile" parameter from the 
ThreadContext. My question: why do I have to start a TestContext and a 
DefaultVariablesContext, when I only seem to use the ThreadContext?

In other words: what are those three contexts being used for?

many thanks in advance,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Re: [Xforge-users] New Feature implemented: FilesMonitor

[Ulrich M. <ul...@de...>]

Alberto Garoffolo wrote:
> Hhmmm .... probably i didn' t got the point ....
> Why do u need to have a unique identifier associated with the current
> resource?
> Monitors are already handled by the MonitorsManager which after a request is
> processed starts a context containing all the monitors needed to "monitor"
> components used, according to the context class specified by the current
> request
> context
> (see XForgeC2URLContext / XForgeC1URLContext / XForgeTestURLContext).
> 
> Perhaps i misunderstood ....

In the XSLComponent I need to know an identifier for the current XML 
resource being processed. Because if that identifier is a file (I test 
for that), then I have to return a FilesMonitor, which monitors both 
files (the XML file and the stylesheet) for modifications.

For example, run this test:

./run.sh test/XSLT.xml test/result.xml 100000 true

Then during the run do:
touch test/XSLT.xml
touch test/test.xsl

You will see in xforge.log (grep xforge.log "isn't changed"|wc -l) that 
each touch is picked up correctly by the monitoring system. The 
component is run three times altogether: The first time during the very 
first invocation. Then after the touch to the XML file, then again after 
the touch to the stylesheet.

If, however, you change in Test.java this line:

broker.putObject(threadcontext,"testfile",src);

to something like:

broker.putObject(threadcontext,"testfile","ThisIsNoFile");

and redo the same test, you will find that the monitoring system only 
picks up the touch to the stylesheet. This is because the XSL component 
found that "ThisIsNoFile" is not a file and so cannot return a Monitor 
for it.

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung