Re: Sample app for procrun.

2004-10-07 Thread Bryce Fischer
There are several ways you can implement them. My favorite is using 
worker threads and thread pools:
http://www-106.ibm.com/developerworks/java/library/j-jtp0730.html


None None wrote:
Hey am trying to implement a sample application that runs a loop until 
I stop it! Does any one hve a sample class and app to show how to do 
this! I tried reading the boostrap class of tomcat but there is to 
much code to look just to get around to the proc run stuff!

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


How to write app class for proc run?

2004-10-07 Thread None None
So far I have this... But I cant seem to get it to stop when I execute it...
Thanks
public class Executer
{
private static Executer daemon = null;
private boolean state = false;
public static void main(String[] args)
{
   if(daemon == null)
   {
   daemon = new Executer();
try
{
daemon.init();
   }
catch(Throwable t)
{
t.printStackTrace();
return;
   }
   }
if(args.length  0)
if(args[0].equals(start))
daemon.start();
else if(args[0].equals(stop))
daemon.stop();
}
public void init()
{
state = true;
}
public void start()
{
while(state)
{
System.out.println(Running...);
try
{
Thread.sleep(1000);
}
catch (InterruptedException e)
{
e.printStackTrace();
}
}
}
public void stop()
{
state = false;
}
}
_
Scan and help eliminate destructive viruses from your inbound and outbound 
e-mail and attachments. 
http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU=http://hotmail.com/encaHL=Market_MSNIS_Taglines 
 Start enjoying all the benefits of MSNĀ® Premium right now and get the 
first two months FREE*.

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


RE: [cli] commons cli version 2.0?

2004-10-07 Thread Andrew Ferguson
 Thanks for that, I've added a new test (based on yours) and fixed
existing ones.  It turns out that GroupImpl was only validating options
that are present and skipping those that were missing.   I've fixed
this in cvs but no binary is available yet.

ok thanks, I've updated my local checkout now and picked it up. I've
being playing with it some more and have some more minor points..

1) On the Builder classes the reset() method has a void return type

This means that you can't reuse the same builder within one
large expression for multiple options (eg because the PreferredName is
set to the first value used)?

eg. Code like this is currently blocked

DefaultOptionBuilder dob = ...
Group wizardArgs =
gBuilder
.withOption(
oBuilder
.reset()
.withLongName(opt1)
.withLongName(altopt1)
.create()
).withOption(
oBuilder
.reset()
.withLongName(opt1)
.withLongName(altopt1)
.create()
).create();

2) Some error messages could be more specific eg in
DefaultOption.validate


===
RCS file:
/home/cvspublic/jakarta-commons/cli/src/java/org/apache/commons/cli2/opt
ion/DefaultOption.java,v
retrieving revision 1.3
diff -r1.3 DefaultOption.java
187c187
 throw new OptionException(this);
---
 throw new OptionException(this,
cli.error.missing.required, preferredName);

3) (As noted before) in the svn/cvs-style usage there is no easy way
to determine which command has been invoked - a (hacky?) workaround is
to do something like

String command = null;
for(Iterator i = line.getOptions().iterator(); i.hasNext(); ) {
Option o = (Option) i.next();
if(!o.getPreferredName().startsWith(-)) {
if(command!=null) {
throw new RuntimeException(You can only
specify one command); // this is never thrown as the top-level Group
has a maximum of 1
} else {
command = o.getPreferredName();
}
}
}

I'm not sure what a nice API for this would be though - maybe
something to look at only the top level options passed (and not their
children)

CommandLine line = ...
...
line.getTopLevelOptions(); ??

4) (As noted before) For non-group option implementations nesting
exceptions might be a way of allowing detailed information about where
the parse error occurred
eg in the validate method in Command you could have

public void validate(WriteableCommandLine commandLine)
throws OptionException {
if (isRequired()  !commandLine.hasOption(this)) {
throw new OptionException(this);
}
try {
super.validate(commandLine);
} catch(OptionException oe) {
OptionException mine = new OptionException(this); // or
maybe the message should be altered to Command +preferredName+
+oe.getMessage());
mine.initCause(oe);
throw mine;
}
}

which would mean the HelpFormatter would need to iterate to the
end of the chain of exceptions to find the true message (or as in the
comment above parent options could prefix additional
information about what is going on). Its probably better to have
the HelpFormatter construct this detailed message as an option if this
idea has any milage in it

Also, if you do need/want some extra coding/docs time then I might be
able to get permission to allocate some time to lending a hand?

thanks,
Andrew

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



FileUpload Parameter Handling

2004-10-07 Thread Adam Pelletier
I'm using commons-fileupload-1.0.jar.

I'm trying to upload a file using enctype=multipart/form-data.

However, I'm also passing a hidden form input element with an ID stuck in it.  This ID 
is critical for the state of the servlet.  Oddly, when I use the 
enctype=multipart/form-data, my HttpServletRequest no longer seems to contain the 
parameters usually accessible by req.getParameter(ID);.  In the debugger I see that 
the parameter hashtable is empty.  As a test I remove enctype=multipart/form-data 
from the form.  The parameters then show up properly in the parameter map, but now the 
file is not accessible.  

Is there a way to utilize both the file uploading capability and still have access to 
the parameter list as it comes in as a HttpServletRequest?

Thanks in advance.
Adam

Digester: Problem of loading parents attribute to the child

2004-10-07 Thread Nalika Dissanayaka
Hi,

I am having a difficulty to load the following XML file by using the
commons Digester. Is there anyone that can help me on this...

XML FILE

?xml version=1.0 encoding=UTF-8?
metadata lang=en-US environment=Production revision=001
   Sender
   Namemy nameDC/Name
   Addressmy address /Address
   /Sender
   DataArea
   Data Set
   Data
   attr1/attr1
   attr2/attr2

   attrn/attrn

   /Data
   Data
   attr1/attr1
   attr2/attr2

   attrn/attrn
   /Data
   /Data Set
   /DataArea
/metadata

I am only interested getting the list of Data objects. The issue is,
Data class has a attribute  called lang which should be loaded from
the value of the lang in the metadata node. (I am planning to load
series of files where metadata lang can be changed based on the
locale)

What are the possible approaches that I can use ?. Is this something
that can be done by using the commons Digester. (I have no problrm of
loading the list of Data)

Thanks in advance
Nalika

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



Re: FileUpload Parameter Handling

2004-10-07 Thread Ben Souther
Regular form params show up in in the DiskFileUpload.

When you iterate through the values, you can test to see 
if they are form fields with isFormField


Example:..
DiskFileUpload upload = new DiskFileUpload();
List   files  = upload.parseRequest(request);
Iterator   it = files.iterator();

while(it.hasNext()){
   FileItem item = (FileItem)it.next();
   if(item.isFormField()){











On Thu, 2004-10-07 at 13:59, Adam Pelletier wrote:
 I'm using commons-fileupload-1.0.jar.
 
 I'm trying to upload a file using enctype=multipart/form-data.
 
 However, I'm also passing a hidden form input element with an ID stuck in it.  This 
 ID is critical for the state of the servlet.  Oddly, when I use the 
 enctype=multipart/form-data, my HttpServletRequest no longer seems to contain the 
 parameters usually accessible by req.getParameter(ID);.  In the debugger I see 
 that the parameter hashtable is empty.  As a test I remove 
 enctype=multipart/form-data from the form.  The parameters then show up properly 
 in the parameter map, but now the file is not accessible.  
 
 Is there a way to utilize both the file uploading capability and still have access 
 to the parameter list as it comes in as a HttpServletRequest?
 
 Thanks in advance.
 Adam


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



Re: FileUpload Parameter Handling

2004-10-07 Thread Michael McGrady
Are you using Struts, Adam?
Michael McGrady
Adam Pelletier wrote:
I'm using commons-fileupload-1.0.jar.
I'm trying to upload a file using enctype=multipart/form-data.
However, I'm also passing a hidden form input element with an ID stuck in it.  This ID is critical for the state of the servlet.  Oddly, when I use the enctype=multipart/form-data, my HttpServletRequest no longer seems to contain the parameters usually accessible by req.getParameter(ID);.  In the debugger I see that the parameter hashtable is empty.  As a test I remove enctype=multipart/form-data from the form.  The parameters then show up properly in the parameter map, but now the file is not accessible.  

Is there a way to utilize both the file uploading capability and still have access to 
the parameter list as it comes in as a HttpServletRequest?
Thanks in advance.
Adam
 


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


Re: FileUpload Parameter Handling

2004-10-07 Thread Adam Pelletier
No, this is just a plain servlet.  Another guy wrote that regular form 
params show up in in the DiskFileUpload.

When you iterate through the values, you can test to see
if they are form fields with isFormField
Example:..
DiskFileUpload upload = new DiskFileUpload();
List   files  = upload.parseRequest(request);
Iterator   it = files.iterator();
while(it.hasNext()){
  FileItem item = (FileItem)it.next();
  if(item.isFormField()){
But that still breaks my architecture - although I can get to that 
architecture if I have to.

Adam
- Original Message - 
From: Michael McGrady [EMAIL PROTECTED]
To: Jakarta Commons Users List [EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 11:45 AM
Subject: Re: FileUpload Parameter Handling


Are you using Struts, Adam?
Michael McGrady
Adam Pelletier wrote:
I'm using commons-fileupload-1.0.jar.
I'm trying to upload a file using enctype=multipart/form-data.
However, I'm also passing a hidden form input element with an ID stuck in 
it.  This ID is critical for the state of the servlet.  Oddly, when I use 
the enctype=multipart/form-data, my HttpServletRequest no longer seems 
to contain the parameters usually accessible by req.getParameter(ID);. 
In the debugger I see that the parameter hashtable is empty.  As a test I 
remove enctype=multipart/form-data from the form.  The parameters then 
show up properly in the parameter map, but now the file is not accessible.
Is there a way to utilize both the file uploading capability and still 
have access to the parameter list as it comes in as a HttpServletRequest?

Thanks in advance.
Adam

-
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]


Re: Digester trimming whitespaces

2004-10-07 Thread robert burrell donkin
On 3 Oct 2004, at 22:51, Simon Kitching wrote:
On Mon, 2004-10-04 at 11:33, robert burrell donkin wrote:
I would recommend that you take a copy of the source of whatever rule
is
causing you problems and rename the class (including changing the
package declaration to something in your namespace), then delete the
trim() call.
i'm not sure whether this would do it.
i suspect that what would be needed would be for an additional flag to
be added to digester that would pass on all calls to
ignorableWhitespace to characters. depending on the parser used, some
configuration may be necessary to ensure that the whitespace is passed
on to digester.
My understanding of ignorable whitespace is that when there is no DTD
or schema, whitespace is never ignorable; any text within an element is
reported via the characters callback. When there is a DTD or schema
present, and it indicates that a particular element has element 
content
only then any whitespace found in the element is reported as 
ignorable
whitespace instead of being reported via the characters method.

So as far as I can see, this is not relevant to Digester. If a document
has a schema/DTD and that DTD specifies that element foo is not
supposed to have any text within it (just child elements) then we 
really
don't care about whether there is whitespace present or not.
+1
i've had a poke around and i recon that you're probably right on this 
one.

I think it might be possible for the Digester class itself to trim or
not trim the body text, instead of the individual rules doing it. But
that would then force the same to trim or not to trim setting to be
present for every rule, making it impossible (for example) to allow
whitespace in text within the description element but to ignore it
inside the location-code element.
+1
on reflection, i'd probably support added a property (to allow trimming 
or not) or (alternative) a post processing hook for a subclass to those 
rules that trim.

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


Re: FileUpload Parameter Handling

2004-10-07 Thread Michael McGrady
What are you doing with commons upload?  You should be able to get
whatever values are present as values of parameter keys in the form.
There is nothing about a multipart upload that precludes regular
parameters.  For example, I parse the DiskFileUpload as follows:
  DiskFileUpload dfu = new DiskFileUpload();
  dfu.setSizeMax(fileSizeLimit);
  dfu.setSizeThreshold(UploadConstant.MEMORY_BUFFER_SIZE);
  dfu.setRepositoryPath(tmpFolder);
  if(encoding != null) {
dfu.setHeaderEncoding(encoding);
  }
  List list = null;
  try {
list = dfu.parseRequest(req);
StdOut.log(log.development,UploadParser list =  + list);
  } catch(FileUploadException fue) {
throw new IOException(fue.getMessage());
  }
And my log test (StdOut) that you see here results in
UploadParser list =
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED]
UploadParser fieldName = uploadedFile1
UploadParser fieldName = uploadedFile2
UploadParser fieldName = uploadedFile3
UploadParser fieldName = uploadedFile4
UploadParser fieldName = uploadedFile5
UploadParser fieldName = uploadedFile6
UploadParser fieldName = uploadedFile7
UploadParser fieldName = uploadedFile8
UploadParser fieldName = uploadedFile9
UploadParser fieldName = uploadedFile10
UploadParser fieldName = uploadedFile11
UploadParser fieldName = uploadedFile12
UploadParser fieldName = submit.dispatch.x
UploadParser fieldName = submit.dispatch.y
UploadParser fieldName = fileOp
From a page that has twelve input type='file' tags.  Hope this helps.
Michael McGrady
Adam Pelletier wrote:
No, this is just a plain servlet.  Another guy wrote that regular form 
params show up in in the DiskFileUpload.

When you iterate through the values, you can test to see
if they are form fields with isFormField
Example:..
DiskFileUpload upload = new DiskFileUpload();
List   files  = upload.parseRequest(request);
Iterator   it = files.iterator();
while(it.hasNext()){
  FileItem item = (FileItem)it.next();
  if(item.isFormField()){
But that still breaks my architecture - although I can get to that 
architecture if I have to.

Adam
- Original Message - From: Michael McGrady 
[EMAIL PROTECTED]
To: Jakarta Commons Users List [EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 11:45 AM
Subject: Re: FileUpload Parameter Handling


Are you using Struts, Adam?
Michael McGrady
Adam Pelletier wrote:
I'm using commons-fileupload-1.0.jar.
I'm trying to upload a file using enctype=multipart/form-data.
However, I'm also passing a hidden form input element with an ID 
stuck in it.  This ID is critical for the state of the servlet.  
Oddly, when I use the enctype=multipart/form-data, my 
HttpServletRequest no longer seems to contain the parameters usually 
accessible by req.getParameter(ID);. In the debugger I see that 
the parameter hashtable is empty.  As a test I remove 
enctype=multipart/form-data from the form.  The parameters then 
show up properly in the parameter map, but now the file is not 
accessible.
Is there a way to utilize both the file uploading capability and 
still have access to the parameter list as it comes in as a 
HttpServletRequest?

Thanks in advance.
Adam

-
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]





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


Re: Digester trimming whitespaces

2004-10-07 Thread Adam Pelletier
Fixed it with a HttpServletRequestWrapper subclass that wraps up the request 
and the DiskFileUpload and makes it all work together.  Thanks.

- Original Message - 
From: robert burrell donkin [EMAIL PROTECTED]
To: Jakarta Commons Users List [EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 1:59 PM
Subject: Re: Digester trimming whitespaces


On 3 Oct 2004, at 22:51, Simon Kitching wrote:
On Mon, 2004-10-04 at 11:33, robert burrell donkin wrote:
I would recommend that you take a copy of the source of whatever rule
is
causing you problems and rename the class (including changing the
package declaration to something in your namespace), then delete the
trim() call.
i'm not sure whether this would do it.
i suspect that what would be needed would be for an additional flag to
be added to digester that would pass on all calls to
ignorableWhitespace to characters. depending on the parser used, some
configuration may be necessary to ensure that the whitespace is passed
on to digester.
My understanding of ignorable whitespace is that when there is no DTD
or schema, whitespace is never ignorable; any text within an element is
reported via the characters callback. When there is a DTD or schema
present, and it indicates that a particular element has element content
only then any whitespace found in the element is reported as ignorable
whitespace instead of being reported via the characters method.
So as far as I can see, this is not relevant to Digester. If a document
has a schema/DTD and that DTD specifies that element foo is not
supposed to have any text within it (just child elements) then we really
don't care about whether there is whitespace present or not.
+1
i've had a poke around and i recon that you're probably right on this one.
I think it might be possible for the Digester class itself to trim or
not trim the body text, instead of the individual rules doing it. But
that would then force the same to trim or not to trim setting to be
present for every rule, making it impossible (for example) to allow
whitespace in text within the description element but to ignore it
inside the location-code element.
+1
on reflection, i'd probably support added a property (to allow trimming or 
not) or (alternative) a post processing hook for a subclass to those rules 
that trim.

- robert
-
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]


Re: FileUpload Parameter Handling

2004-10-07 Thread Paul DeCoursey
I know what you are saying about it breaking your architecture... i use a
servlet that calls scripts based on a parameter, I found that using the
multipart-encoding broke that.  I later discovered that if I post the
multipart but have my parameter on the querystring it works fine.

Paul


 No, this is just a plain servlet.  Another guy wrote that regular form
 params show up in in the DiskFileUpload.

 When you iterate through the values, you can test to see
 if they are form fields with isFormField


 Example:..
 DiskFileUpload upload = new DiskFileUpload();
 List   files  = upload.parseRequest(request);
 Iterator   it = files.iterator();

 while(it.hasNext()){
FileItem item = (FileItem)it.next();
if(item.isFormField()){


 But that still breaks my architecture - although I can get to that
 architecture if I have to.

 Adam




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



[HttpClient] getting the http connection or setting the params

2004-10-07 Thread Gustavo Hexsel
  I'm using HttpClient to read a variable number of pages in sequence.  I
have a time frame by which the page accesses (method execution and all the
input stream reads) have to be done.  I tried calling 

method.getParams().setSoTimeout(remainingTime)

  but it only sets the timeout once, just before opening the connection.  Is
there a way of getting the http connection behind an executing http method?
Or setting the connection parameters?

  Thank you!

[]s Gustavo

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



Re: FileUpload Parameter Handling

2004-10-07 Thread Michael McGrady
I cannot see how a servlet stepping through parameter values could break 
an architecture.  What do you mean by that?  If the parameter is there, 
then the servlet can read it.  How that could affect architecture is not 
clear to me.  Can you guys explain what you mean?

Michael McGrady
Paul DeCoursey wrote:
I know what you are saying about it breaking your architecture... i use a
servlet that calls scripts based on a parameter, I found that using the
multipart-encoding broke that.  I later discovered that if I post the
multipart but have my parameter on the querystring it works fine.
Paul
 

No, this is just a plain servlet.  Another guy wrote that regular form
params show up in in the DiskFileUpload.
When you iterate through the values, you can test to see
if they are form fields with isFormField
Example:..
DiskFileUpload upload = new DiskFileUpload();
List   files  = upload.parseRequest(request);
Iterator   it = files.iterator();
while(it.hasNext()){
  FileItem item = (FileItem)it.next();
  if(item.isFormField()){
But that still breaks my architecture - although I can get to that
architecture if I have to.
Adam
   


-
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]


Re: FileUpload Parameter Handling

2004-10-07 Thread Adam Pelletier
I fixed my problem.  My problem is that I had a Servlet that would serve up 
any number of Pages.  The way the navigation was wired was through 
keys/values pairs in the parameter list (i.e. req.getParameter(ID)).  So 
the HttpServletRequest itself would get passed down to a couple of different 
delgation layers.  Well in DiskFileUpload the parameters are stored 
differently in the Parts list and then have to be iterated over.  So all my 
code depended upon:

   // block 1
   req.getParameter(foo);
as opposed to
  // block 2
  Iterator iter = m_req_parts.iterator();
  while (iter.hasNext()) {
   FileItem fi = (FileItem) iter.next();
   if (fi.isFormField()  fi.getFieldName().equals(foo)) {
return fi.getString();
   }
  }
So what I did is write an HttpServletRequestWrapper so when my code calls 
black 1 above, what really happens is block 2 above executes.

Thanks all for the help,
Adam
- Original Message - 
From: Michael McGrady [EMAIL PROTECTED]
To: Jakarta Commons Users List [EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 3:29 PM
Subject: Re: FileUpload Parameter Handling


I cannot see how a servlet stepping through parameter values could break an 
architecture.  What do you mean by that?  If the parameter is there, then 
the servlet can read it.  How that could affect architecture is not clear 
to me.  Can you guys explain what you mean?

Michael McGrady
Paul DeCoursey wrote:
I know what you are saying about it breaking your architecture... i use a
servlet that calls scripts based on a parameter, I found that using the
multipart-encoding broke that.  I later discovered that if I post the
multipart but have my parameter on the querystring it works fine.
Paul

No, this is just a plain servlet.  Another guy wrote that regular form
params show up in in the DiskFileUpload.
When you iterate through the values, you can test to see
if they are form fields with isFormField
Example:..
DiskFileUpload upload = new DiskFileUpload();
List   files  = upload.parseRequest(request);
Iterator   it = files.iterator();
while(it.hasNext()){
  FileItem item = (FileItem)it.next();
  if(item.isFormField()){
But that still breaks my architecture - although I can get to that
architecture if I have to.
Adam


-
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]


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


Re: Digester: Problem of loading parents attribute to the child

2004-10-07 Thread Simon Kitching
On Fri, 2004-10-08 at 07:11, Nalika Dissanayaka wrote:
 Hi,
 
 I am having a difficulty to load the following XML file by using the
 commons Digester. Is there anyone that can help me on this...
 
 XML FILE
 
 ?xml version=1.0 encoding=UTF-8?
 metadata lang=en-US environment=Production revision=001
Sender
Namemy nameDC/Name
Addressmy address /Address
/Sender
DataArea
Data Set
Data
attr1/attr1
attr2/attr2
 
attrn/attrn
 
/Data
Data
attr1/attr1
attr2/attr2
 
attrn/attrn
/Data
/Data Set
/DataArea
 /metadata
 
 I am only interested getting the list of Data objects. The issue is,
 Data class has a attribute  called lang which should be loaded from
 the value of the lang in the metadata node. (I am planning to load
 series of files where metadata lang can be changed based on the
 locale)
 
 What are the possible approaches that I can use ?. Is this something
 that can be done by using the commons Digester. (I have no problrm of
 loading the list of Data)

It certainly can be done using the Digester, though you might have to
create a custom Rule class or two.

I would suggest having a look at the ObjectParamRule class which can be
used to pass an arbitrary object to a method on the top object on the
digester object stack.

Regards,

Simon


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



Re: [HttpClient] getting the http connection or setting the params

2004-10-07 Thread Michael Becke
Hi Gustavo,
Not sure what you mean by setting the connection parameters.  All 
timeout params available on the connection are configurable via some 
HttpClient param.  Which timeout do you want to set?

Though it is possible to get access to the actual connection it is 
highly discouraged.

It sounds like you may want a method to abort a request after some 
time.  HttpClient does not have a built-in request timeout param, but 
it can be simulated.  You would need a thread separate from the one 
executing the method that keeps track of the method execution time.  If 
it went over a timeout value you could call HttpMethod.abort().

Mike
On Oct 7, 2004, at 6:17 PM, Gustavo Hexsel wrote:
  I'm using HttpClient to read a variable number of pages in sequence. 
 I
have a time frame by which the page accesses (method execution and 
all the
input stream reads) have to be done.  I tried calling

method.getParams().setSoTimeout(remainingTime)
  but it only sets the timeout once, just before opening the 
connection.  Is
there a way of getting the http connection behind an executing http 
method?
Or setting the connection parameters?

  Thank you!
[]s Gustavo
-
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]


Re: FileUpload Parameter Handling

2004-10-07 Thread Michael McGrady
My pleasure, Adam.  I don't know who wrote the commons upload stuff, but 
I think they did one hell of a job.  You have to study it a bit, 
however, because it is not entirely intuitive at first.  I will tell you 
this, however, it really provides a wonderful base for working with 
multipart issues.  I have a hugely efficient file upload application 
built on top of this functionality.  Anyway, glad you are on track.  
These things can bedevil us.

Michael McGrady
Adam Pelletier wrote:
I fixed my problem.  My problem is that I had a Servlet that would 
serve up any number of Pages.  The way the navigation was wired was 
through keys/values pairs in the parameter list (i.e. 
req.getParameter(ID)).  So the HttpServletRequest itself would get 
passed down to a couple of different delgation layers.  Well in 
DiskFileUpload the parameters are stored differently in the Parts list 
and then have to be iterated over.  So all my code depended upon:

   // block 1
   req.getParameter(foo);
as opposed to
  // block 2
  Iterator iter = m_req_parts.iterator();
  while (iter.hasNext()) {
   FileItem fi = (FileItem) iter.next();
   if (fi.isFormField()  fi.getFieldName().equals(foo)) {
return fi.getString();
   }
  }
So what I did is write an HttpServletRequestWrapper so when my code 
calls black 1 above, what really happens is block 2 above executes.

Thanks all for the help,
Adam
- Original Message - From: Michael McGrady 
[EMAIL PROTECTED]
To: Jakarta Commons Users List [EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 3:29 PM
Subject: Re: FileUpload Parameter Handling


I cannot see how a servlet stepping through parameter values could 
break an architecture.  What do you mean by that?  If the parameter 
is there, then the servlet can read it.  How that could affect 
architecture is not clear to me.  Can you guys explain what you mean?

Michael McGrady
Paul DeCoursey wrote:
I know what you are saying about it breaking your architecture... i 
use a
servlet that calls scripts based on a parameter, I found that using the
multipart-encoding broke that.  I later discovered that if I post the
multipart but have my parameter on the querystring it works fine.

Paul

No, this is just a plain servlet.  Another guy wrote that regular form
params show up in in the DiskFileUpload.
When you iterate through the values, you can test to see
if they are form fields with isFormField
Example:..
DiskFileUpload upload = new DiskFileUpload();
List   files  = upload.parseRequest(request);
Iterator   it = files.iterator();
while(it.hasNext()){
  FileItem item = (FileItem)it.next();
  if(item.isFormField()){
But that still breaks my architecture - although I can get to that
architecture if I have to.
Adam


-
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]


-
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]


[Digester] cousin Beck

2004-10-07 Thread John Kristian
If you need an XML-to-Java mapper that's more programmable than Digester,
or a Java-to-XML mapper designed on similar lines, check out Beck
http://beck.sourceforge.net/.


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