Re: Some proposals

2001-03-08 Thread Wong Kok Wai

Send a message to [EMAIL PROTECTED] (no subject or
message body needed). Wait for a acknowledgement and reply to that
acknowledgement.

Martin Quinn wrote:

 Sorry folks - i don't know how i got on the list - but i need to get off it.
 I did reply to the remove list but to not avail.







Database pooling comments (org.apache.struts.sql)

2001-03-08 Thread Johan Compagner

Hi,

I looked at that pooling framework and have some comments, i hope that
i can mail them to this list.

1
Why isn't there a closed boolean in the PoolablePreparedStatement/Connection?
If users do call the closed() method but then make a mistake and do use
the connection or the statement again, then the still can do that! (no error will apear
except when another also did get that statement again. very strange error phrone
situations can happen!!)
So i do think that there should be a closed boolean and when that one is true
no method call can be done anymore without throwing an exception.
Because there should be a boolean check the 2 delegating classes can be
discarded in this example because you in the Poolable versions you still need to
have all the methods because there should be a boolean check.

2
Why is the Factory implementation: KeyedPoolableObjectFactory or PoolableObjectFactory
be implemented in the Normal/Outer class (PoolingConnection and BaseConnectionPool)
If find this very confusing and bad design.
Because for example PoolingConnection.makeObject(Object) what does this do?
If you look at this then you should think that it makes a PoolingConnection Object for 
the
specifiek object that is given (like Locale.getCurrencyInstance(Locale) ect ect)
This Factory implementation should really be in an other class:
PreparedStatementFactory or ConnectionFactory and if this class is absolutly only be 
used
by PoolingConnection or BaseConnectionPool they should be private innerclasses i think.

3
the passivate methods of connection:
Why is only the autocommit and the readonly set back the the default values?
Why aren't clearWarnings(), setCatalog , setTransactionIsolation and setTypeMap called?
To get a exact copy of the original connection back?
But when calling those set methods there must be a check if it is really changed!!
  if(!conn.getCatalog().equals(this.catalog))
  {
   conn.setCatalog(this.catalog);
  }
Because if you don't do the above then the JDBC-ODBC bridge (to a acces mdb) doesn't 
work anymore
when you want to pool the prepared statements of this connection. So maybe more have 
this limitation.

The same for PreparedStatement.passivate:
Why are only the clearParameters() called?
There could be a batch() or warnings, or a left over resultset.
My close of my pooledpreparedstatement is this:

 try  {
  java.sql.ResultSet rs = _ps.getResultSet();
  if(rs != null)  {
   rs.close();
  }
 }
 catch (SQLException e) { }
 try  {
  clearBatch();
 }
 catch (SQLException sqlE) { }
 catch (UnsupportedOperationException uoe){}
 try  {
  clearParameters();
 }
 catch (Exception e) { }
 try  {
  clearWarnings();
 }
 catch (SQLException e) { }
 _bClosed = true;

4
I am planning (or already beginning to implement) also a bit of transcaction control.
Very simple in the beginning:

User calls:
Datasouce.startTranscation() (a transcation is started for the current thread)
Datasource.getConnection() (a connection is created/borrowed and attached the the 
current transaction)
Datasouce.startTranscation() (Ignored because there was already a transaction for 
the current thread, using that one)
Datasource.getConnection() (the connection of the current transaction is 
returned!!!)
Connection.close() (Connection is not "closed" (or returnend) yet because there is 
another one in this transaction holding on to
it)
Connection.rollback() (At this point something is gone wrong. The 
onlyRollBackBoolean == true)
Datasource.getConnection() (the connection of the current transaction is 
returned!!!)
Connection.close() (Connection is not "closed" (or returnend) yet because there is 
another one in this transaction holding on to
it)
Connection.commit() (Exception because it could only be rollbacked)
Connection.getError() get's the error why it is gone wrong
Connection.close() (Connection is "closed" or returnend because there is no one in 
this transaction holding on to it)


Connection.getStatus() (Can alway's be called, returns OnlyRollBack or something 
like that)

If there is call to getConnection but there is not a current Transaction, a 
Transaction will be made.

I want this because i make my Database Objects just as Entity beans (for easy 
transaction to a EJB server at one time)
so:
class Customer
{
public static Customer findCustomerByPrimaryKey(int key or PrimaryKey key)
{
Connection connection =  datasource.getConnection(); // Auto made a 
Transaction
// Select the customer and makes a customer (maybe the Customer is 
Pooled in a CacheablePool see below)
// Customer has a reference (foreign key) to another Object: Country:
customer.setCountry(Country.findCountryByPrimaryKey(rs.getInt(x)));
}
}

class Country
{
public static Country findCountryByPrimaryKey(int key)
{
// datasouce returns the same Connection, because it is in 

cvs commit: jakarta-struts/src/doc installation-ipas.xml

2001-03-08 Thread husted

husted  01/03/08 07:08:38

  Modified:src/doc  installation-ipas.xml
  Log:
  Update iPortal instructions, submitted by John Ueltzhoeffer.
  
  Revision  ChangesPath
  1.2   +20 -18jakarta-struts/src/doc/installation-ipas.xml
  
  Index: installation-ipas.xml
  ===
  RCS file: /home/cvs/jakarta-struts/src/doc/installation-ipas.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- installation-ipas.xml 2001/03/05 13:08:27 1.1
  +++ installation-ipas.xml 2001/03/08 15:08:37 1.2
  @@ -1,7 +1,7 @@
   ?xml version="1.0"?
   document url="./installation-ipas.xml"
   properties
  -authorUeltzhoeffer/author 
  +authorJohn Ueltzhoeffer/author 
   titleThe Struts Framework Project - Installation - iPortal Application 
Server/title
   /properties
   body
  @@ -19,22 +19,23 @@
   As it stands, JSP pages that make use of Struts taglibs whose parameters 
   require conversion (such as booleans) will not compile under iPAS 1.3. 
   This includes the Struts Example Application. Attempting to run the 
  -example a pplication will result in an exception similar to the 
  +example application will result in an exception similar to the 
   following being thrown: /p
   
   pre
   /struts-example/index.jsp:
  -
  -javax.servlet.ServletException: Compilation error occured:
  -
  -allaire.jrun.scripting.DefaultCFE: 
  -
  -Errors reported by compiler:
  -
  -c:/JRun/servers/default/Struts 
  -  Example/WEB-INF/jsp/jrun__index2ejspa.java:41:1:41:27: 
  -
  -Error: No match was found for method "setLocale(java.lang.String)".
  +Compilation failed [IT_Builder:1000]
  + at com.iona.j2ee.builder.JavaBuilder.build(JavaBuilder.java:84)
  + at com.iona.j2ee.builder.JspBuilder.build(JspBuilder.java:51)
  + at com.iona.j2ee.builder.WarBuilder.build(WarBuilder.java:111)
  + at com.iona.j2ee.builder.EarBuilder.build(EarBuilder.java:99)
  + at com.iona.j2ee.builder.EarBuilder.main(EarBuilder.java:223)
  + at iportal.build.main(build.java:14)
  + ocale(boolean) in org.apache.struts.taglib.html.HtmlTag 
  +   cannot be applied to (java.lang.String)
  +   _x0.setLocale("true");
  +^
  + 1 error
   /pre
   
   p(For more details see refer to: 
  @@ -48,7 +49,7 @@
   pThe following instructions assume the following:/p
   
   ul
  -lia href="./installation-jrun.html"JRun/a has been installed./li
  +liiPortal Application Server 1.3 has been installed./li
   liBoth the Strut and XML Parser libraries are in your classpath./li
   /ul
   
  @@ -77,7 +78,7 @@
   directory structure as follows: /p
   
   pUnder code$INSTALLDIR\IONA\jars\struts-examples\src\struts-example.war/code 
you 
  -copy contect into the following directories: etc, lib, src and web./p
  +copy contents into the following directories: etc, lib, src and web./p
   
   ul
   liCopy all files in the root directory br/
  @@ -137,13 +138,13 @@
   pcodejava iportal.deploy/code/p
   
   pThe first time you deploy you will be prompted by a Deploy wizard and asked to 
  -supply both location of the struts-example.ear file and of the cc.xml file. 
  -Once both elements have been statisfied continue till the finish button and 
  +supply both locations of the struts-example.ear file and of the cc.xml file. 
  +Once both elements have been satisfied continue until the finish button and 
   click it. The EAR file should deploy sucessfully./p
   
   pTest the sample application by using the following URL in the browser:/p
   
  -pcodehttp://hostname/struts-example/index.jsp/code/p
  +pcodehttp://hostname:9000/struts-example/index.jsp/code/p
   
   pThe codestruts-documentation.war/code can be installed using the same 
procedure./p
   
  @@ -171,3 +172,4 @@
   
   /body
   /document
  +
  
  
  



Patch on the digester to process recursive structures

2001-03-08 Thread Pierre Métras

Hi,

Following is a small patch to the Digester class to allow processing of
recursive XML structures.
In order to process a tree-like XML file, you sometimes need to discriminate
between a root entity and a node. For instance, with an XML input like:

tree
node
node
node
/node
node
/node
/node
node
/node
/node
/tree

The first level of node is the root of the tree, and must be unique, when
the other nodes can be multiple on the same level.
In order to differentiate between the two significances of the same tag, I
wanted to be able to write the following rules:

  digester.push(tree);

  // Rule set #1 for root
  digester.addObjectCreate("*/tree/node", "Node");
  digester.addSetProperties("*/tree/node");
  digester.addSetNext("*/tree/node", "setRoot");

  // Rule set #2 for node
  digester.addObjectCreate("*/node", "Node");
  digester.addSetProperties("*/node");
  digester.addSetNext("*/node", "addNode");

But in the current digester implementation, the getRules() method returns
the first rules set found in the HashMap, instead of taking the most
discriminant (ie. the one with the longest matching pattern), giving random
results!

Here is the patch to Digester.getRules() that returns the most discriminant
pattern macthing set of rules:

--
/**
 * Return the set of rules that apply to the specified match position.
 * The selected rules are those that match exactly, or those rules
 * that specify a suffix match and the tail of the rule matches the
 * current match position.  Exact matches have precedence over
 * suffix matches. Then longest suffix match is preferred.
 *
 * @param match The current match position
 */
private List getRules(String match) {

List rulesList = (List) this.rules.get(match);
if (rulesList == null) {
// Find longest key, ie more discriminant
String longKey = "";
Iterator keys = this.rules.keySet().iterator();
while (keys.hasNext()) {
String key = (String) keys.next();
if (key.startsWith("*/")) {
if (match.endsWith(key.substring(1))) {
if (key.length()  longKey.length()) {
rulesList = (List) this.rules.get(key);
longKey = key;
}
 }
 }
 }
 }

}

--

Pierre Mtras





Fw: Patch on the digester to process recursive structures

2001-03-08 Thread Pierre Métras

Ooops,

The return statement of the proposed Digester.getRules() method was drop in
the cut 'n paste operation. Here is the corrected version:

 private List getRules(String match) {

 List rulesList = (List) this.rules.get(match);
 if (rulesList == null) {
 // Find longest key, ie more discriminant
 String longKey = "";
 Iterator keys = this.rules.keySet().iterator();
 while (keys.hasNext()) {
 String key = (String) keys.next();
 if (key.startsWith("*/")) {
 if (match.endsWith(key.substring(1))) {
 if (key.length()  longKey.length()) {
 rulesList = (List) this.rules.get(key);
 longKey = key;
 }
  }
  }
  }
  }
  return (rulesList);

 }


- Original Message -
From: "Pierre Mtras" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, March 08, 2001 5:03 PM
Subject: Patch on the digester to process recursive structures


 Hi,

 Following is a small patch to the Digester class to allow processing of
 recursive XML structures.
 In order to process a tree-like XML file, you sometimes need to
discriminate
 between a root entity and a node. For instance, with an XML input like:

 tree
 node
 node
 node
 /node
 node
 /node
 /node
 node
 /node
 /node
 /tree

 The first level of node is the root of the tree, and must be unique, when
 the other nodes can be multiple on the same level.
 In order to differentiate between the two significances of the same tag, I
 wanted to be able to write the following rules:

   digester.push(tree);

   // Rule set #1 for root
   digester.addObjectCreate("*/tree/node", "Node");
   digester.addSetProperties("*/tree/node");
   digester.addSetNext("*/tree/node", "setRoot");

   // Rule set #2 for node
   digester.addObjectCreate("*/node", "Node");
   digester.addSetProperties("*/node");
   digester.addSetNext("*/node", "addNode");

 But in the current digester implementation, the getRules() method returns
 the first rules set found in the HashMap, instead of taking the most
 discriminant (ie. the one with the longest matching pattern), giving
random
 results!

 Here is the patch to Digester.getRules() that returns the most
discriminant
 pattern macthing set of rules:

 --
 /**
  * Return the set of rules that apply to the specified match position.
  * The selected rules are those that match exactly, or those rules
  * that specify a suffix match and the tail of the rule matches the
  * current match position.  Exact matches have precedence over
  * suffix matches. Then longest suffix match is preferred.
  *
  * @param match The current match position
  */
 private List getRules(String match) {

 List rulesList = (List) this.rules.get(match);
 if (rulesList == null) {
 // Find longest key, ie more discriminant
 String longKey = "";
 Iterator keys = this.rules.keySet().iterator();
 while (keys.hasNext()) {
 String key = (String) keys.next();
 if (key.startsWith("*/")) {
 if (match.endsWith(key.substring(1))) {
 if (key.length()  longKey.length()) {
 rulesList = (List) this.rules.get(key);
 longKey = key;
 }
  }
  }
  }
  }

 }

 --

 Pierre Mtras






Re: [INFORMATIONAL] Javasoft J2EE Patterns Catalog

2001-03-08 Thread Wong Kok Wai

I would also suggest reading the Service Locator and
Service Activator patterns which address Struts and
EJB integration.


--- Philip Hart [EMAIL PROTECTED] wrote:
 Hi All
 
 Javasoft have just released a J2EE Patterns Catalog

(http://www.javasoft.com/features/2001/03/patterns.html)
 To quote:
 
 
 The Sun Java Center has just released, in beta form,
 the J2EE Patterns
 Catalog to the development community via the Java
 Developer ConnectionSM
 (JDC) program. The 15 included J2EE Patterns
 represent more than three years
 of work by the Sun Java Center, and contain J2EE
 platform solutions for
 common problems experienced by architects using Java
 technology. The J2EE
 Patterns Catalog reflects the collective expertise
 and the experience of
 architects using Java technology in the Java Center
 over the past three
 years.
 
 
 Definitely worth a look, as it has the sort of
 patterns - Front Controller
 and Dispatcher for example - which we know and love
 in Struts.
 
 Happy Reading,
 Philip Hart
 


__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/