JAKARTA COMMONS DIGESTER RULES XML PROBLEM

2007-12-10 Thread twathelet

High I'm using DIGESTER to parse an xml doc but it seems that I don't
understang somethig
My xml file:

!-- message JMS --
message
!-- enveloppe des informations propre  la FDR --
fdr
!-- Numro de FDR (ex: 650451) --
number690504/number
docType
!-- Mnmonique du type de document (ex: AM, RR, ...) --
docTypeMnemoAM/docTypeMnemo
/docType
/fdr
version
!-- Indique l'outil utilis pour produire le doc. --
jobProductionToolSEIAMD/jobProductionTool
!-- Donne toutes les langues cibles de la traduction ou de la 
mise en
forme --
languagesCouples
languageCouple
targetLanguageEN/targetLanguage
/languageCouple
languageCouple
targetLanguageFR/targetLanguage
/languageCouple
languageCouple
targetLanguageDE/targetLanguage
/languageCouple
/languagesCouples
/version
/message

***

My xml rules:

?xml version=1.0 encoding=UTF-8?
digester-rules
pattern value=message
object-create-rule
classname=europarl.trad.sild.movearch.model.FdrFile /
call-method-rule pattern=fdr/number methodname=setFdrNumber
paramcount=0 /
call-method-rule pattern=fdr/docType/docTypeMnemo
methodname=setDocType paramcount=0 /
call-method-rule pattern=version/jobProductionTool
methodname=setProductionTool paramcount=0 /
pattern
value=message/version/languagesCouples/languageCouple
object-create-rule

classname=europarl.trad.sild.movearch.model.Lang /
call-method-rule pattern=targetLanguage
methodname=setCode paramnumber=0 /
call-method-rule pattern=targetLanguage
methodname=setLabel paramnumber=0 /
set-next-rule methodename=addLang /
/pattern
/pattern
/digester-rules



My classes are:

/**
 * 
 */
package europarl.trad.sild.movearch.model;

import java.util.Vector;

/**
 * @author twathelet
 */
public class FdrFile {

private String fdrNumber;

private String docType;

private String productionTool;

private Vector coupleLang;

/**
 * @return the coupleLang
 */
public Vector getCoupleLang() {
return coupleLang;
}

/**
 * @param coupleLang
 *the coupleLang to set
 */
public void setCoupleLang(Vector coupleLang) {
this.coupleLang = coupleLang;
}

/**
 * @return the fdrNumber
 */
public String getFdrNumber() {
return fdrNumber;
}

/**
 * @param fdrNumber
 *the fdrNumber to set
 */
public void setFdrNumber(String fdrNumber) {
this.fdrNumber = fdrNumber;
}

/**
 * @return the docType
 */
public String getDocType() {
return docType;
}

/**
 * @param docType
 *the docType to set
 */
public void setDocType(String docType) {
this.docType = docType;
}

/**
 * @return the productionTool
 */
public String getProductionTool() {
return productionTool;
}

/**
 * @param productionTool
 *the productionTool to set
 */
public void setProductionTool(String productionTool) {
this.productionTool = productionTool;
}

public void addLang(Lang lang) {
this.coupleLang.addElement(lang);
}

/**
 * 
 */
public FdrFile() {
this.coupleLang = new Vector();
}

}



/**
 * 
 */
package europarl.trad.sild.movearch.model;

/**
 * @author twathelet
 */
public class Lang {
private String code;

private String label;

/**
 * @return the code
 */
public String getCode() {
return code;
}

/**
 * @param code
 *the code to set
 */
public void setCode(String code) {
this.code = code;
}

/**
 * @return the label
 */
public String getLabel() {
return label;
}

/**
 * @param label
 *the label to set
 */
public void setLabel(String label) {
this.label = label;
}

/**
 * 
 */
public Lang() {
// TODO Auto-generated constructor stub

Re: JAKARTA COMMONS DIGESTER RULES XML PROBLEM

2007-12-10 Thread Simon Kitching
Hi,

It would be appreciated if you could follow these conventions:
(1) Please do not use all-capitals for an email subject. IT IS ANNOYING AND 
HARD TO READ.
(2) When using the commons list, put the component name at the start of the 
subject line, eg 
[digester] ...  because this email list is shared by many components.
(3) Please try to choose a better subject for emails. About 50% of all emails 
about digester could be described by this subject (the others can be described 
as rules api problem). This subject is therefore no use to anyone searching 
the archives.

I think you've just got a simple typing error. There is no paramnumber 
attribute on call-method-rule. But using paramcount=0 should work (as you do 
earlier in the file).

This also looks like a spelling mistake (well, in English anyway..):

  set-next-rule methodename=addLang /

Everything else looks ok to me..

Regards,

Simon

 twathelet [EMAIL PROTECTED] schrieb:
 
 High I'm using DIGESTER to parse an xml doc but it seems that I don't
 understang somethig
 My xml file:
 
 !-- message JMS --
 message
   !-- enveloppe des informations propre  la FDR --
   fdr
   !-- Numro de FDR (ex: 650451) --
   number690504/number
   docType
   !-- Mnmonique du type de document (ex: AM, RR, ...) --
   docTypeMnemoAM/docTypeMnemo
   /docType
   /fdr
   version
   !-- Indique l'outil utilis pour produire le doc. --
   jobProductionToolSEIAMD/jobProductionTool
   !-- Donne toutes les langues cibles de la traduction ou de la 
 mise en
 forme --
   languagesCouples
   languageCouple
   targetLanguageEN/targetLanguage
   /languageCouple
   languageCouple
   targetLanguageFR/targetLanguage
   /languageCouple
   languageCouple
   targetLanguageDE/targetLanguage
   /languageCouple
   /languagesCouples
   /version
 /message
 
 ***
 
 My xml rules:
 
 ?xml version=1.0 encoding=UTF-8?
 digester-rules
   pattern value=message
   object-create-rule
   classname=europarl.trad.sild.movearch.model.FdrFile /
   call-method-rule pattern=fdr/number methodname=setFdrNumber
   paramcount=0 /
   call-method-rule pattern=fdr/docType/docTypeMnemo
   methodname=setDocType paramcount=0 /
   call-method-rule pattern=version/jobProductionTool
   methodname=setProductionTool paramcount=0 /
   pattern
   value=message/version/languagesCouples/languageCouple
   object-create-rule
   
 classname=europarl.trad.sild.movearch.model.Lang /
   call-method-rule pattern=targetLanguage
   methodname=setCode paramnumber=0 /
   call-method-rule pattern=targetLanguage
   methodname=setLabel paramnumber=0 /
   set-next-rule methodename=addLang /
   /pattern
   /pattern
 /digester-rules
 
 
 
 My classes are:
 
 /**
  * 
  */
 package europarl.trad.sild.movearch.model;
 
 import java.util.Vector;
 
 /**
  * @author twathelet
  */
 public class FdrFile {
 
 private String fdrNumber;
 
 private String docType;
 
 private String productionTool;
 
 private Vector coupleLang;
 
 /**
  * @return the coupleLang
  */
 public Vector getCoupleLang() {
 return coupleLang;
 }
 
 /**
  * @param coupleLang
  *the coupleLang to set
  */
 public void setCoupleLang(Vector coupleLang) {
 this.coupleLang = coupleLang;
 }
 
 /**
  * @return the fdrNumber
  */
 public String getFdrNumber() {
 return fdrNumber;
 }
 
 /**
  * @param fdrNumber
  *the fdrNumber to set
  */
 public void setFdrNumber(String fdrNumber) {
 this.fdrNumber = fdrNumber;
 }
 
 /**
  * @return the docType
  */
 public String getDocType() {
 return docType;
 }
 
 /**
  * @param docType
  *the docType to set
  */
 public void setDocType(String docType) {
 this.docType = docType;
 }
 
 /**
  * @return the productionTool
  */
 public String getProductionTool() {
 return productionTool;
 }
 
 /**
  * @param productionTool
  *the productionTool to set
  */
 public void setProductionTool(String productionTool) {
 

Re: [jelly] certain way to evaluate a document (usecase)

2007-12-10 Thread Evaldas Taroza

Hi,
Actually I already have a solution that works (i.e. I have some sort of 
executable XML which has the needed logic), however, for me it is very 
important to answer the question, would it be better to refactor that 
solution in the way that it would use Jelly.


What I have is an engine (coincides with the Jelly script engine) that 
is able to evaluate the XML documents with embedded executable parts. 
These parts are simply XML tags in a special namespace. So for me it 
looks completely like Jelly. The thing is that my engine is:

1. can only understand my tags in my namespace
2. can execute those tags in the order that I predefine (possibly inside 
the tags)
3. during the execution of tags some new data can appear next to those 
tags as a result of execution


Now the question: in order to transition to Jelly will I need to develop 
taglibs only, or I will end up extending and modifying the jelly script 
engine? I would really like it to be the former case:) do you think it 
is reasonable?


Evaldas

Paul Libbrecht wrote:

Evaldas,

the jelly script is loaded in memory then the doTag methods are called.
So, of course, it could not scale to kilometers of source, but, indeed, 
then a fancy branching logic of doTag is doable.


hope it helps.

paul


Le 10 déc. 07 à 09:42, Evaldas Taroza a écrit :


Hi,
Yes, I think I would need to implement something similar to the thread 
taglib. Because I will need something like:

1. There is a dedicated thread for every tag
2. Some threads are blocked by other threads (waiting to end)
3. Unblocked threads can run

I haven't looked deep into Jelly yet, nor available taglibs, but what 
worries me is that the script engine is like SAX, so will I be able to 
construct a difficult execution plan with only one-pass parsing?


Evaldas

Paul Libbrecht wrote:

Evaldas,
I believe that the answer to your question is that it is flexible.
Jelly's default follows Ant and SAX: most tag's doTag call invokeBody 
which produces a depth-first execution. The thread taglib does it 
differently though.
You might be well served with Jelly although it still has some rough 
edges.

paul
Le 9 déc. 07 à 17:16, Evaldas Taroza a écrit :

Hi,
I have a very specific usecase to program. Specifically, I need to 
be able to execute the tags in a certain order. For instance, I 
should be able to say that this tag is executing after another, 
others can execute in parallel etc.


So I am considering Jelly as already implementing the execution of 
the tags but what about the ordering? In what order are the tags 
executed now? Is it at all feasible to use Jelly for such a usecase 
or I will end up implementing a completely new Jelly script 
evaluation engine?


Evaldas




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[vfs] FTP extremely slow compared to SFTP

2007-12-10 Thread Jörg Schaible
Hi,

can somebody explain the following numbers - especially why FTP is that dead 
slow compared to SFTP handling a lot of files? I measure a simple copy action 
of a directory containing some few files:


FTP

* Initial Run
  - Exporter.. 8252.0 ms
* Single File (25kb)
  - Exporter.. 8021.0 ms
* Single File (25000kb)
  - Exporter.. 11437.0 ms
* Single File (5kb)
  - Exporter.. 16043.0 ms
* Single Directory (with 10 files of 1kb)
  - Exporter.. 47859.0 ms
* Single Directory (with 25 files of 1kb)
  - Exporter.. 113964.0 ms
* Single Directory (with 50 files of 1kb)
  - Exporter.. 224312.0 ms


SFTP

* Initial Run
  - Exporter.. 1252.0 ms
* Single File (25kb)
  - Exporter.. 921.0 ms
* Single File (25000kb)
  - Exporter.. 14952.0 ms
* Single File (5kb)
  - Exporter.. 24885.0 ms
* Single Directory (with 10 files of 1kb)
  - Exporter.. 601.0 ms
* Single Directory (with 25 files of 1kb)
  - Exporter.. 922.0 ms
* Single Directory (with 50 files of 1kb)
  - Exporter.. 1552.0 ms


Any explanation or - even better - suggestions to improve FTP speed?

- Jörg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [SCXML] problems with Data() function in Jexl

2007-12-10 Thread Rahul Akolkar
On 12/8/07, Sudeep Gandhe [EMAIL PROTECTED] wrote:
 I tried the following scxml file with the StandaloneJexlExpressions. I don't 
 get the correct value for Data(d, '//tar/@name'). Can you explain, what's 
 wrong ?

snip/

We use some Xalan APIs internally to be able to resolve prefixes in
XPath expressions (since XPath expressions in SCXML documents can have
different context nodes, say assign, log etc. and hence different
prefixes, than the datas they refer to).

It is not immediately evident why the behavior you describe is only
seen when a combination of descendent-or-self and attribute axes are
used in the expression, I suspect this is either:
a) A bug or inconsistency in the Xalan processing (quite unlikely), or
b) A bug in the usage of Xalan APIs by Commons SCXML (more likely)

In any case, can you please attach a complete JUnit test case addition
to the Commons SCXML test suite that illustrates this, to the issue
tracker [1]? That will help us dig deeper. Thanks in advance.

-Rahul

[1] http://commons.apache.org/scxml/issue-tracking.html


 -- Sudeep

 SCXML file :

 ?xml version=1.0?
 scxml xmlns=http://www.w3.org/2005/07/scxml;  version=1.0 
 initialstate=first

 datamodel
  data name=d
  foo xmlns=
  bar
  tar name=po12/tar
  /bar
  /foo
  /data
  data name=p
  one xmlns=/
  /data
 /datamodel

 state id=first
  onentry
  log label=//tar expr=Data(d, '//tar')/
  !-- //tar/@name doesn't work --
  log label=//tar/@name expr=Data(d, '//tar/@name')/
  log label=foo/bar/tar expr=Data(d, 'foo/bar/tar')/
  !-- foo/bar/tar/@name  works --
  log label=foo/bar/tar/@name expr=Data(d, 
 'foo/bar/tar/@name')/
  /onentry
  transition event=first.done target=second/
  onexit
  assign location=Data(p, 'one') expr=Data(d, '//bar')/
  /onexit
 /state

 state id=second final=true
  onentry
  log label=//tar expr=Data(p, '//tar')/
  !-- //tar/@name doesn't work --
  log label=//tar/@name expr=Data(p, '//tar/@name')/
  !-- one/tar/@name  works --
  log label=one/tar/@name expr=Data(p, 'one/tar/@name')/
  /onentry
 /state
 /scxml



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]