RE: [httpclient] Constructing Cookies with null domains (again)
I think both Marc and dIon raise some good points. The spec clearly allows domain to be null in a Set-Cookie header, but also speaks to what clients should assume to be the domain in that circumstance. So what is a *.httpclient.Cookie, really? A representation of the somewhate abstract client side state? A container for the parsed attributes of a Set-Cookie header? A container for the attributes that go into a Cookie header? Some combination of these? Under what circumstances would we want it to have a null domain or path? Is it ever useful to know, for example, that the server didn't indicate a domain, but the client assumed one? (And assuming it is useful, is Cookie the right place to go to find out, or is that really a question about Headers?) Is it always possible, in practice, to provide a default based upon the context in which the Cookie/Set-Cookie headers are encountered? (I'm really not trying to be coy, I honestly don't know the answers here.) - Rod
[GUMP] Build Failure - altrmi
This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2002-03-05/commons-altrmi.html Buildfile: build.xml init: [echo] altrmi 1.0-dev prepare: [mkdir] Created dir: /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/build [mkdir] Created dir: /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/build/classes [mkdir] Created dir: /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/build/classes2 [mkdir] Created dir: /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/build/genjava [mkdir] Created dir: /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/build/conf [mkdir] Created dir: /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/build/tests compile: [javac] Compiling 161 source files to /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/build/classes [javac] /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/beep/BEEPInvocationHandler.java:24: cannot resolve symbol [javac] symbol : class ByteDataStream [javac] location: package core [javac] import org.beepcore.beep.core.ByteDataStream; [javac] ^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/beep/BEEPInvocationHandler.java:28: cannot resolve symbol [javac] symbol : class DataStream [javac] location: package core [javac] import org.beepcore.beep.core.DataStream; [javac] ^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/beep/BEEPInvocationHandler.java:31: cannot resolve symbol [javac] symbol : class StringDataStream [javac] location: package core [javac] import org.beepcore.beep.core.StringDataStream; [javac] ^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/beep/BEEPInvocationHandler.java:36: cannot resolve symbol [javac] symbol : class AutomatedTCPSessionCreator [javac] location: package tcp [javac] import org.beepcore.beep.transport.tcp.AutomatedTCPSessionCreator; [javac]^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/server/impl/beep/CompleteBEEPServer.java:18: cannot resolve symbol [javac] symbol : class AutomatedTCPSessionCreator [javac] location: package tcp [javac] import org.beepcore.beep.transport.tcp.AutomatedTCPSessionCreator; [javac]^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/server/impl/beep/ServerBEEPReadWriter.java:27: cannot resolve symbol [javac] symbol : class StringDataStream [javac] location: package core [javac] import org.beepcore.beep.core.StringDataStream; [javac] ^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/server/impl/beep/ServerBEEPReadWriter.java:28: cannot resolve symbol [javac] symbol : class DataStream [javac] location: package core [javac] import org.beepcore.beep.core.DataStream; [javac] ^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/server/impl/beep/ServerBEEPReadWriter.java:29: cannot resolve symbol [javac] symbol : class ByteDataStream [javac] location: package core [javac] import org.beepcore.beep.core.ByteDataStream; [javac] ^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/beep/BEEPInvocationHandler.java:77: cannot resolve symbol [javac] symbol : variable AutomatedTCPSessionCreator [javac] location: class org.apache.commons.altrmi.client.impl.beep.BEEPInvocationHandler [javac] session = AutomatedTCPSessionCreator.initiate(mHost, mPort,new ProfileRegistry()); [javac] ^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/beep/BEEPInvocationHandler.java:113: cannot resolve symbol [javac] symbol : method setDataListener (org.beepcore.beep.lib.MessageQueue) [javac] location: class org.beepcore.beep.core.Channel [javac] channel.setDataListener(beepReadWriter.mQueue); [javac]^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/beep/BEEPInvocationHandler.java:176: cannot resolve symbol [javac] symbol : class ByteDataStream [javac] location: class
[httpclient] Why no HttpUrlMethodBase?
I've noticed that there's a set of methods now in httpclient called
'UrlMETHODNAMEMethod', which seem to implement HttpMultiClient compatible
methods.
These seem to all have the same boilerplate code in them for setting and
getting the url, and passing on the path information to the super class.
From the perspective of someone who might be implementing several new
UrlMethods, I'm thinking about a new abstract class as an analog to the
HttpClient's HttpMethodBase - the HttpUrlMethodBase. It might look something
like this:
package org.apache.commons.httpclient;
import java.net.URL;
import java.net.MalformedURLException;
public abstract class HttpUrlMethodBase
extends HttpMethodBase
implements HttpUrlMethod {
private URL _url;
public HttpUrlMethodBase() {
super();
}
public HttpUrlMethodBase(String url) throws
MalformedURLException {
super(URIUtil.getPath(url));
_url = new URL(url);
}
public void setUrl(String url) throws MalformedURLException
{
_url = new URL(url);
}
public String getUrl() {
return _url.toExternalForm();
}
public abstract String getName();
}
A new HttpUrlMethod would only have extend HttpUrlMethodBase and override
getName, to be functional, in the same fashion as a new HttpMethod only has
to extend HttpMethodBase and override getName. Does this sound reasonable
and/or useful to anyone but myself?
-Caleb
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/socket SocketObjectStreamFactoryHelper.java
hammant 02/03/05 08:30:17
Added: altrmi/src/java/org/apache/commons/altrmi/client
AltrmiInterfaceLookupFactory.java
altrmi/src/java/org/apache/commons/altrmi/client/impl
AbstractFactoryHelper.java
AbstractInterfaceLookupFactory.java
DefaultInterfaceLookupFactory.java
altrmi/src/java/org/apache/commons/altrmi/client/impl/socket
SocketObjectStreamFactoryHelper.java
Removed: altrmi/src/java/org/apache/commons/altrmi/client
AltrmiFactoryFactory.java
Log:
Start of work on String based lookup mechanism.
Revision ChangesPath
1.1
jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/AltrmiInterfaceLookupFactory.java
Index: AltrmiInterfaceLookupFactory.java
===
package org.apache.commons.altrmi.client;
import org.apache.commons.altrmi.common.AltrmiConnectionException;
/**
* Interface AltrmiInterfaceLookupFactory
*
*
* @author Paul Hammant a
href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a
* @version * $Revision: 1.1 $
*/
public interface AltrmiInterfaceLookupFactory {
/**
* Method getAltrmiInterfaceLookup
*
* FactoryStrings as listed here should look like this:
*
* SocketObjectStream:abcde.com:1234:S:BO
* SocketCustomStream:abcde.com:1235:C:NBO
* RMI:abcde.com:1236:S:NBO
*
* S:BO and alike is
*- S for server side proxy classes
*- C for client side proxy classes
*- BO is BeanOnly (not castable to the interface)
*- NBO is NotBeanOnly (castable to the interface)
*
* @param factoryString
*
* @return
*
*/
AltrmiInterfaceLookup getAltrmiInterfaceLookup(String factoryString) throws
AltrmiConnectionException;
}
1.1
jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/AbstractFactoryHelper.java
Index: AbstractFactoryHelper.java
===
/*
* Copyright (C) The Apache Software Foundation. All rights reserved.
*
* This software is published under the terms of the Apache Software License
* version 1.1, a copy of which has been included with this distribution in
* the LICENSE.txt file.
*/
package org.apache.commons.altrmi.client.impl;
import org.apache.commons.altrmi.client.AltrmiFactory;
import org.apache.commons.altrmi.client.AltrmiInterfaceLookupFactory;
import java.util.Vector;
import java.util.StringTokenizer;
/**
* Class AbstractFactoryHelper
*
*
* @author Paul Hammant a
href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a
* @version $Revision: 1.1 $
*/
public abstract class AbstractFactoryHelper implements AltrmiInterfaceLookupFactory {
protected String[] processFactoryString(String factoryString) {
Vector terms = new Vector();
StringTokenizer st = new StringTokenizer(factoryString, :);
while (st.hasMoreTokens()) {
terms.add(st.nextToken());
}
String[] retval = new String[terms.size()];
terms.copyInto(retval);
return retval;
}
protected AltrmiFactory createAltrmiFactory(String type, boolean beanOnly) {
if (type.equalsIgnoreCase(s)) {
return new ServerClassAltrmiFactory(beanOnly);
} else if (type.equalsIgnoreCase(c)) {
return new ClientClassAltrmiFactory(beanOnly);
} else {
return null;
}
}
}
1.1
jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/AbstractInterfaceLookupFactory.java
Index: AbstractInterfaceLookupFactory.java
===
/*
* Copyright (C) The Apache Software Foundation. All rights reserved.
*
* This software is published under the terms of the Apache Software License
* version 1.1, a copy of which has been included with this distribution in
* the LICENSE.txt file.
*/
package org.apache.commons.altrmi.client.impl;
import org.apache.commons.altrmi.client.AltrmiInterfaceLookupFactory;
import org.apache.commons.altrmi.client.AltrmiInterfaceLookup;
import org.apache.commons.altrmi.common.AltrmiConnectionException;
import java.util.Vector;
/**
* Class AbstractInterfaceLookupFactory
*
*
* @author Paul Hammant a
href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a
* @version $Revision: 1.1 $
*/
public class AbstractInterfaceLookupFactory implements AltrmiInterfaceLookupFactory {
private Vector
RE: Notes on building Struts from scratch (CVS Main)
I just wanted to add a few comments to the build process that I
went through. Please take my suggestions with a grain of salt:
I'm usually lurking, and not slugging it out on struts-dev,
commons-dev like the rest of you, so I don't know all the
implications of what I'm suggesting.
In the process of building struts...
I ended up with:
PRODUCT VERSION
commons-collections.jar 1.0
commons-pool.jarCVS-Main
commons-logging.jar CVS-Main
commons-validator.jar CVS-Main
commons-dbcp.jarCVS-Main
commons-digester.jarCVS-Main
commons-beanutils.jar CVS-Main
commons-services.jarCVS-Main
regexp.jar 1.2
1. Struts has dependencies on products that are not released:
. commons-pool.jar
. commons-dbcp.jar
It makes it impossible to check out the same libraries that the
nightly-builder and other developers have checked-out when they
build struts. This, I think can make things more difficult when
tracking down dependency bugs.
SUGGESTION: Only use dependent-products (i.e. libraries) that are
released (with a version number)
2. Struts has dependencies on commons-sandbox products that are not
released:
. commons-services.jar
Note that when I build services itself, it does not use any of
released products (only the latest and greatest from CVS-Main).
I then have to cascade these dependencies up to the rest of my
builds (I think).
SUGGESTION: Don't inlucde an commons-sandbox products. It just
seems to me that if it's in sandbox, it has not graduated to
something that can be included in a released product. (Now this
is a general statement and not aimed at Oleg or common-services by
any means!...from what I understand, Oleg, you do great work.)
3. SUGGESTION: If a prodcut is to be released, it should only include
libraries that are released (i.e. have a version number, and are
downloadable). Can get the same versions of libraries for building
products. I guess an alternative to using releases is to specify a
date on which certain products were built, so that I can go back
into CVS and checkout the dependent-product from that date. More
work...but not impossible.
I can understand some of Jon's frustrations when trying to build
workflow some months ago. Also, I KNOW that this versioning stuff has
been hashed out on commons-dev before, so I'm not certainly not baiting
that discussion. Anyway, as I recall, JJAR should take care of the
automating getting the right version of a dependent-library.
Thanks for hearing me out,
Gidado
-Original Message-
From: Immanuel, Gidado-Yisa [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 05, 2002 11:59 AM
To: 'Struts Developers List'
Subject: Notes on building Struts from scratch (CVS Main)
I was trying to build struts from source (nightlies and CVS-MAIN), and
found it a little less than straight forward. I did not see any help
in the archives...So this text documents my trials to
succesfully build
struts from scratch...it's here for the record. Also, if
there is a much
simpler way to do this, please let me know. If this text is
helpful in
the installation doc, let me know and I'll write a patch
(especially now
that I can build struts :)
I started with the following jars:
commons-digester.jar(v. 1.1)
commons-beanutils.jar (v. 1.0)
commons-collections.jar (v. 1.0)
A. BUILD STRUTS (MAIN branch)
-
1. Download nightly (our checkout jakarta-struts MAIN)
2. Create the file ${user.home}/build.properties
3. Set properties in build.properties
. commons-collections.jar
. commons-beanutils.jar
4. We find that out that we need
. commons-dbcp.jar
. commons-pool.jar
See:
http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg0
4437.html
But since there was no released version (that I could
locate) of dbcp,
I checked out the source from CVS and began to build. Go
to Step B-1
4. Set properties in build.properties
. commons-dbcp.jar (v. CVS-Main)
. commons-digester.jar
5. We find that out that we need
. commons-logging.jar (v. CVS-Main)
See:
http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg0
4271.html
And there *is* a 1.0 for logging :)
Get it from http://jakarta.apache.org/commons/logging.html
and install
6. Set properties in build.properties
. commons-logging.jar
7. We find that out that we need
. commons-services.jar
See:
http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg0
4739.html
But since there was no released version (that I could locate) of
services,
I checked out the source from CVS and began to build. Go
to Step D-1
8. Set properties in build.properties
. commons-services.jar (v. CVS-Main)
9. We find that out that we need
. comomons-validator.jar
Go to Step F-1
10. Set properties in build.properties:
.
Latka notes
I was just talking with a coworker about how to build some automated tests for our webapp, and sure enough Latka does a lot of what I was thinking. I had a few other todo items I might contribute, assuming I can get my client to pay or can otherwise find the time. I thought I'd bring up the ideas first to get some feedback on whether this is going in a good or bad direction: 1. meta process for test definition generation/maintenance I'd like to define a meta XML file for a webapp that could declare something like all HTML pages and JSPs in this webapp should be tested. Then new meta process code would use that meta XML to check that the Latka test definition meets these requirements... it would the recurse through the files in a webapp and look for them in the latka test file. If there were gaps, the meta check could either a) fail with a list of pages that aren't included or (my preference) b) add them to the test file with some comments (and stop before running the latka test). By default it could just require 200 status codes for those newly spotted pages. The tester could then look at the bottom of the latka test file, and cut and paste the definitions up to suites or to more understandable places in the file, and otherwise flesh out the validations. 2. JTidy for HTML validation I would really like to be able to validate that the HTML in a site is well formed. I've tried doing it with a servlet filter, but using Latka would make much more sense. Ideally we could define the JTidy settings for a site and whether to test all by default, and let individual requests override that. 3. Better ant/junit integration I'd have to see what's already there, but as I use ant to do my builds already, I'd like to have 2 custom taskdefs that will a) do the meta checking that the latka tests are complete and b) run the latka test. Comments? Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Latka notes
On Tue, 5 Mar 2002, Serge Knystautas wrote: Hello, 1. meta process for test definition generation/maintenance I'd like to define a meta XML file for a webapp that could declare something like all HTML pages and JSPs in this webapp should be tested. Then new meta process code would use that meta XML to check that the Latka test definition meets these requirements... it would the recurse through the files in a webapp and look for them in the latka test file. If there were gaps, the meta check could either a) fail with a list of pages that aren't included or (my preference) b) add them to the test file with some comments (and stop before running the latka test). By default it could just require 200 status codes for those newly spotted pages. The tester could then look at the bottom of the latka test file, and cut and paste the definitions up to suites or to more understandable places in the file, and otherwise flesh out the validations. RDF may be perfect for this. Is an w3 consortium standard for metadata. Was develop to model the p3p web annotation application but is growing very fast. (http://www.w3.org/RDF/) The semantic web vision is developing over it: perhaps i can develop a model for the tests (i made some formal testing of ISO protocols some years ago). regards Joaquin Comments? Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- --- Joaquin Salvachua tel: +34 91 549 57 00 x.367 Associated Professor +34 91 549 57 62 x.367 dpt. Telematica E.T.S.I. Telecomunicacion Ciudad Universitaria S/N fax: +34 91 336 73 33 E-28040 MADRID SPAIN mailto: [EMAIL PROTECTED] // http://www.dit.upm.es/~jsr -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/simplestore/src/test/org/apache/commons/simplestore TestEnhancer.java
baliuka 02/03/05 12:03:49
Modified:simplestore/src/java/org/apache/commons/simplestore/tools
Enhancer.java
simplestore/src/test/org/apache/commons/simplestore
TestEnhancer.java
Log:
Added class_name parameter to enhance method for
ARMI ProxyGenerator implementation
Revision ChangesPath
1.9 +35 -15
jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/tools/Enhancer.java
Index: Enhancer.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/tools/Enhancer.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- Enhancer.java 4 Mar 2002 22:51:16 - 1.8
+++ Enhancer.java 5 Mar 2002 20:03:49 - 1.9
@@ -63,7 +63,7 @@
/**
*@author Juozas Baliuka a href=mailto:[EMAIL PROTECTED];
* [EMAIL PROTECTED]/a
- *@version$Id: Enhancer.java,v 1.8 2002/03/04 22:51:16 baliuka Exp $
+ *@version$Id: Enhancer.java,v 1.9 2002/03/05 20:03:49 baliuka Exp $
*/
public class Enhancer implements org.apache.bcel.Constants{
@@ -110,9 +110,37 @@
public static Object enhance(Class cls,Class interfaces [] , MethodInterceptor
ih) throws Throwable{
-return
enhance(cls,interfaces,ih,Thread.currentThread().getContextClassLoader());
+return
enhance(cls,null,interfaces,ih,Thread.currentThread().getContextClassLoader());
}
-public synchronized static Object enhance(Class cls,Class interfaces[],
MethodInterceptor ih,ClassLoader loader)throws Throwable {
+
+static class Handler implements java.lang.reflect.InvocationHandler{
+MethodInterceptor ih;
+Handler(MethodInterceptor ih){
+this.ih = ih;
+}
+
+public Object invoke(Object obj, java.lang.reflect.Method method, Object[]
args) throws java.lang.Throwable {
+return ih.afterReturn( obj, method, args, null, false, null, null );
+}
+
+}
+
+public synchronized static Object enhance(Class cls,String class_name,Class
interfaces[], MethodInterceptor ih,ClassLoader loader)throws Throwable {
+// Use Standard way if we don't need to enhance any Class
+if( ( Object.class.equals(cls) || cls == null ) class_name == null ){
+return java.lang.reflect.Proxy.newProxyInstance(loader,interfaces, new
Handler(ih) );
+}
+
+if( cls == null ){
+cls = Object.class;
+}
+
+if( class_name == null ){
+class_name = cls.getName() + ENHAVCED_CLASS_SUFIX;
+if(class_name.startsWith(java)){
+class_name = ENHAVCED_CLASS_PREFIX + class_name;
+}
+}
java.util.Map map = (java.util.Map)cache.get(loader);
@@ -122,13 +150,11 @@
}
-
Class result = (Class)map.get(cls);
if(result == null){
java.util.HashMap methods = new java.util.HashMap();
-JavaClass clazz = enhance(cls, interfaces , methods);
-
+JavaClass clazz = enhance(cls, class_name, interfaces , methods);
byte b [] = clazz.getBytes();
java.lang.reflect.Method m =
ClassLoader.class.getDeclaredMethod(defineClass,
@@ -139,7 +165,6 @@
m.setAccessible(true);
result = (Class)m.invoke(loader,new Object[]{clazz.getClassName(),b,new
Integer(0),new Integer(b.length)});
m.setAccessible(flag);
-
for( java.util.Iterator i = methods.keySet().iterator(); i.hasNext();
){
String name = (String)i.next();
result.getField( name ).set(null,methods.get(name));
@@ -157,7 +182,6 @@
String parentClass = cg.getSuperclassName();
InstructionFactory factory = new InstructionFactory(cg);
ConstantPoolGen cp = cg.getConstantPool(); // cg creates constant pool
-
InstructionList il = new InstructionList();
MethodGen costructor = new MethodGen(ACC_PUBLIC,// access flags
Type.VOID,// return type
@@ -198,12 +222,8 @@
return gen;
}
-private static JavaClass enhance( Class parentClass,Class interfaces
[],java.util.HashMap methodTable ) {
+private static JavaClass enhance( Class parentClass,String class_name,Class
interfaces [],java.util.HashMap methodTable ) {
-String class_name = parentClass.getName() + ENHAVCED_CLASS_SUFIX;
-if(class_name.startsWith(java)){
-class_name = ENHAVCED_CLASS_PREFIX +
Re: Latka notes
Serge Knystautas wrote: I was just talking with a coworker about how to build some automated tests for our webapp, and sure enough Latka does a lot of what I was thinking. I had a few other todo items I might contribute, assuming I can get my client to pay or can otherwise find the time. I thought I'd bring up the ideas first to get some feedback on whether this is going in a good or bad direction: 1. meta process for test definition generation/maintenance I'd like to define a meta XML file for a webapp that could declare something like all HTML pages and JSPs in this webapp should be tested. Then new meta process code would use that meta XML to check that the Latka test definition meets these requirements... it would the recurse through the files in a webapp and look for them in the latka test file. If there were gaps, the meta check could either a) fail with a list of pages that aren't included or (my preference) b) add them to the test file with some comments (and stop before running the latka test). By default it could just require 200 status codes for those newly spotted pages. The tester could then look at the bottom of the latka test file, and cut and paste the definitions up to suites or to more understandable places in the file, and otherwise flesh out the validations. This doesn't sound like it fits in with what Latka already does; it sounds like an external checking/generation process that's completely outside of the functional testing. Don't get me wrong, I like the idea of generating latka suites off other documents, but don't think it's necessarily part of Latka. 2. JTidy for HTML validation I would really like to be able to validate that the HTML in a site is well formed. I've tried doing it with a servlet filter, but using Latka would make much more sense. Ideally we could define the JTidy settings for a site and whether to test all by default, and let individual requests override that. Sounds like a good custom validator, and a good fit with Latka. 3. Better ant/junit integration I'd have to see what's already there, but as I use ant to do my builds already, I'd like to have 2 custom taskdefs that will a) do the meta checking that the latka tests are complete and b) run the latka test. I use Latka with ant a lot. The user's guide ( http://jakarta.apache.org/commons/latka/users-guide.html ) talks about creating JUnit suites from a Latka Suite and running that. So b) above is just the usual JUnit task in ant. Is there something more you'd need? Comments? Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ -- dIon Gillard, Multitask Consulting http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Latka notes
On Tue, Mar 05, 2002 at 01:42:17PM -0500, Serge Knystautas wrote: I was just talking with a coworker about how to build some automated tests for our webapp, and sure enough Latka does a lot of what I was thinking. I had a few other todo items I might contribute, assuming I can get my client to pay or can otherwise find the time. I thought I'd bring up the ideas first to get some feedback on whether this is going in a good or bad direction: 1. meta process for test definition generation/maintenance I'd like to define a meta XML file for a webapp that could declare something like all HTML pages and JSPs in this webapp should be tested. Then new meta process code would use that meta XML to check that the Latka test definition meets these requirements... it would the recurse through the files in a webapp and look for them in the latka test file. How would you go about determining the URLs of all HTML pages and JSPs? Is this really *all* (ie you have inside information; it's your webapp you're testing), or just visible from the usual application workflow? Ie, is the list created by hand or created through a wget-like follow-the-links strategy? If there were gaps, the meta check could either a) fail with a list of pages that aren't included or (my preference) b) add them to the test file with some comments (and stop before running the latka test). By default it could just require 200 status codes for those newly spotted pages. The tester could then look at the bottom of the latka test file, and cut and paste the definitions up to suites or to more understandable places in the file, and otherwise flesh out the validations. 2. JTidy for HTML validation I would really like to be able to validate that the HTML in a site is well formed. If you mean well formed in the XML sense (XHTML), you could use the XPath validator, and just validate for something like '/'. I've tried doing it with a servlet filter, but using Latka would make much more sense. Ideally we could define the JTidy settings for a site and whether to test all by default, and let individual requests override that. Sounds good. 3. Better ant/junit integration Wasn't there an Ant task for running Latka in the works? Dion? I'd have to see what's already there, but as I use ant to do my builds already, I'd like to have 2 custom taskdefs that will a) do the meta checking that the latka tests are complete and b) run the latka test. If you're really keen on Ant integration, there's another testing framework called Anteater (http://sourceforge.net/projects/aft), which is 100% Ant tasks. It inherits a lot of expressive power from Ant itself. Eg, you can pattern-match or XPath-match, and then store the matched pattern/XML in an Ant property. You can also use Ant's parallel to start/stop Tomcat servers. --Jeff Comments? Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[OT] thoughts on Java pre processor
This is kinda off topic but I've been musing lately about a preprocessor for
Java. One of the early attractions to me about Java some 5-6 years ago
coming from a mostly C++ background was that there was no pre processor and
obfuscation, so Java code was very easy to read.
However in theses groovy days of having Ant to do all our building, JUnit
for unit testing and the various logging packages for logging, we rarely
need much from an IDE these days but a basic editor (does anyone even use
debuggers any more?), so maybe diverging from the Java Language spec
wouldn't be too bad. .
So I was thinking that maybe a preprocessor might now gain momentum since
* it can be an Ant task and integrate seamlessly into any build
* it can spit out regular Java code so even though the pre processor would
be 'non standard' it could become useful.
So the aim of the preprocessor would be to allow us to add some syntax
suguar to Java to save us some typing and avoid redundancy. I just wondered
what others thoughts are. Here's a couple of ideas for some syntax sugar...
Easier properties
Imagine a typical property definition in a Java bean
/**
* This is a foo property
*/
private Foo foo;
/**
* Gets the value of the foo property
*
* @return the foo property
*/
public Foo getFoo() {
return foo
}
/**
* Sets the value of the foo property
*
* @param foo the new value of the foo property
*/
public void setFoo(Foo foo) {
this.foo = foo;
}
Its quite a lot to type and takes up quite a bit of code. Also notice the
redundancy in the javadoc comments. We should be able to just describe the
property and the javadoc could be generated. I'd quite like some syntax
sugar (similar to in C#) to allow the property to be javadoc commented just
once and to save typing. e.g.
/** This is a foo property */
private property Foo foo {
get {
return foo;
}
set {
this.foo = value;
}
}
For most simple properies this could be simplified as just
/** This is a foo property */
private property Foo foo;
Maybe even extending this to provide 'lazy construction' properties which
expand to look like this...
/**
* @return the value of the foo property
* which will be created lazily if it is null
*/
public Foo getFoo() {
if ( foo == null ) {
foo = createFoo();
}
return foo;
}
/**
* Factory method to create a new Foo object
* which allows derived classes to override this
* behaviour
*/
protected Foo createFoo() {
return new Foo();
}
This could maybe appear as syntax sugar as
private lazy property Foo foo {
create {
return new Foo();
}
}
The get set methods could be defaulted if not specified.
Easier events
=
Similar techniques to the above could be done to avoid developers having to
manage event listeners and write code to fire them etc.
foreach?
==
To help avoid repetive code of the form...
for ( Iterator iter = something.iterator(); iter.hasNext(); ) {
Foo foo = (Foo) iter.next();
foo.bar();
}
maybe introduce a C#-like foreach statement...
foreach( Foo foo in something.iterator() ) {
foo.bar();
}
Just thinking aloud here (as always ;-). Thoughts?
James
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Latka notes
I don't think I explained my idea 1 very well based on comments. The issue I'm facing is making sure my latka suite stays current with the site as developers maintain the site. For an initial import, I might have a webapp with 350 JSPs... I don't want to manually build the latka suite for that. More importantly, as the team of developers add more JSPs, I want to know that some schmuck didn't add a JSP to CVS and not add it to the functional test. I would start with just a file system dir list, recursing through subdirs and listing all *.jsp files. (no link checking or wget or anything complex... just pure dir.list() with recursion). This would create a list like: /test.jsp /index.jsp /login.jsp /contacts/list.jsp /contacts/add.jsp /contacts/edit.jsp It would take these URLs and build the latka suite file. If there already was a latka suite file, it would append the files not already in there. Really this is just a tool/script to maintain the latka suite file. I was getting somewhat ahead of myself with the meta decription, but I was thinking the filtering could get more advanced so that I included *.jsp and *.html, but excluded everything in /include since those pages are not directly called. Maybe I should just fashion this as an ant task so I can leverage it's include/exclude file pattern capabilities. On an unrelated note, I thought of two other validators... a) link checking, and b) xml validation (if your servlet is supposed to output XML instead of HTML). Anyone else working on these kind of validators? Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ - Original Message - From: Jeff Turner [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, March 05, 2002 5:34 PM Subject: Re: Latka notes On Tue, Mar 05, 2002 at 01:42:17PM -0500, Serge Knystautas wrote: I was just talking with a coworker about how to build some automated tests for our webapp, and sure enough Latka does a lot of what I was thinking. I had a few other todo items I might contribute, assuming I can get my client to pay or can otherwise find the time. I thought I'd bring up the ideas first to get some feedback on whether this is going in a good or bad direction: 1. meta process for test definition generation/maintenance I'd like to define a meta XML file for a webapp that could declare something like all HTML pages and JSPs in this webapp should be tested. Then new meta process code would use that meta XML to check that the Latka test definition meets these requirements... it would the recurse through the files in a webapp and look for them in the latka test file. How would you go about determining the URLs of all HTML pages and JSPs? Is this really *all* (ie you have inside information; it's your webapp you're testing), or just visible from the usual application workflow? Ie, is the list created by hand or created through a wget-like follow-the-links strategy? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [httpclient] Constructing Cookies with null domains (again)
Marc Saegesser wrote: I've spent a fair amount of time recently reading and re-reading RFC 2109 and the Netscape cookie spec-like-thing. Here's my current understanding. All cookies have a domain. A domain is required in order to determine which cookies should be sent with a given request. I suppose it depends on what you're calling a cookie. As far as the response header is concerned, domain is optional, from the RFC: Domain=domain Optional. The Domain attribute specifies the domain for which the cookie is valid. An explicitly specified domain must always start with a dot. As far as the client's concerned, it's a derived value if not specified in the header. A cookie's domain can come from two different places: 1) a domain attribute in the set-cookie header or 2) default to the host that sent the cookie. There are two ways that cookies get created in HttpClient, by calling a Cookie constructor or by parsing a set-cookie header. Both the constructors and parse take a value for the domain. So the question is what is the meaning of this domain value and what are the legal values. For the constructors, the case is fairly straight-forward. The constructor has no knowledge of the request, response or any headers, it simply creates the cookie with the given values. Since, as I claim above, all cookies must have a domain, allowing a null domain value to the constructor creates a cookie that isn't valid. Thus, the constructors should throw an IllegalArgumentException for null domains. I'll go against that one, and say that since there is an option for creating a header from an array of Cookies, and we should allow users to create the header without specifying the domain (might want to send the same cookie to multiple places), then domain in the cookie constructor should be able to be null. Domain passed to create cookie header shouldn't. The parse() method has access to the set-cookie header, but not the request or response. The domain parameter passed to parse() should be interpretted as the default domain for the cookie in case the set-cookie header doesn't contain a domain attribute. Since domain attributes are not required, and all cookies must have a domain, the domain passed to parse() should not null and the method should throw an IllegalArgumentException for null domains. Agreed. Ditto for createCookieHeader. Marc Saegesser -- dIon Gillard, Multitask Consulting http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] thoughts on Java pre processor
This is the perfect job for Velocity. :-) Just use Velocity to generate your .java code. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Latka notes
On Tue, Mar 05, 2002 at 09:54:55PM -0500, Serge Knystautas wrote: I don't think I explained my idea 1 very well based on comments. The issue I'm facing is making sure my latka suite stays current with the site as developers maintain the site. For an initial import, I might have a webapp with 350 JSPs... I don't want to manually build the latka suite for that. More importantly, as the team of developers add more JSPs, I want to know that some schmuck didn't add a JSP to CVS and not add it to the functional test. I would start with just a file system dir list, recursing through subdirs and listing all *.jsp files. (no link checking or wget or anything complex... just pure dir.list() with recursion). This would create a list like: /test.jsp /index.jsp /login.jsp /contacts/list.jsp /contacts/add.jsp /contacts/edit.jsp It would take these URLs and build the latka suite file. If there already was a latka suite file, it would append the files not already in there. Really this is just a tool/script to maintain the latka suite file. Perl, or shell would be easiest. If you want to keep location-independence (list URLs, not file paths), you could write a servlet that returns a list of directory contents as XML. Then use Ant's get to retrieve the XML listing, style to transform it into a Latka XML file, and off you go. I was getting somewhat ahead of myself with the meta decription, but I was thinking the filtering could get more advanced so that I included *.jsp and *.html, but excluded everything in /include since those pages are not directly called. Maybe I should just fashion this as an ant task so I can leverage it's include/exclude file pattern capabilities. Except in Ant you can't iterate over items in a fileset. Maybe there's some 3rd party tasks for that. On an unrelated note, I thought of two other validators... a) link checking, and b) xml validation (if your servlet is supposed to output XML instead of HTML). Anyone else working on these kind of validators? XML validation should be very easy (XPath does it for free). Link checking might need the JTidy one's capabilities first. AFAIK, no-one is working on them. --Jeff Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ - Original Message - From: Jeff Turner [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, March 05, 2002 5:34 PM Subject: Re: Latka notes -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] thoughts on Java pre processor
On Wed, Mar 06, 2002 at 01:55:25AM -, James Strachan wrote:
...
So the aim of the preprocessor would be to allow us to add some syntax
suguar to Java to save us some typing and avoid redundancy. I just wondered
what others thoughts are. Here's a couple of ideas for some syntax sugar...
...
foreach?
==
To help avoid repetive code of the form...
for ( Iterator iter = something.iterator(); iter.hasNext(); ) {
Foo foo = (Foo) iter.next();
foo.bar();
}
maybe introduce a C#-like foreach statement...
foreach( Foo foo in something.iterator() ) {
foo.bar();
}
and maybe throw in some logging syntax, which can be compiled to log4j,
the Commons logger or compiled out altogether.
--Jeff
(who once did write a preprocessor to let you embed declarative XML
statements like debug level=1This is a debug statement/debug in
Java. It worked by converting the marked up .java to XML, then applying
stylesheets ala XSP to transform debug to code, then stripping the XML
tags to get .java again. I thought it was neat :)
Just thinking aloud here (as always ;-). Thoughts?
James
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] thoughts on Java pre processor
Just thinking aloud here (as always ;-). Thoughts? My only thought is the lack of a directive to allow the compiler to tell you the file/line of any errors. I'm rusty on my C++, but I seem to recall they had a #file directive, so that the post-processed file, when compiled, could signal errors with regards to pre-processed source files. It'd be strange to have one of your 15-line files, and have the compiler report an error on line 38 (after expansion). What you're really doing is defining a new syntax to generate valid bytecodes, not unlike PythonJ (or whatever it's called). Why not just avoid the javac step, and emit bytecodes from your new syntax anyhoo. Sure, we miss out standard compiler optimizations, which could suck, but for the simple Easy-To-Write-JavaBean example, it may be sufficient. Or, maybe just glue a front-end onto the IBM Jikes back-end, where all we do is some AST translation into what the backend normally expects. -bob (I like to parse) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] thoughts on Java pre processor
On 3/5/02 8:55 PM, James Strachan [EMAIL PROTECTED] wrote:
To help avoid repetive code of the form...
for ( Iterator iter = something.iterator(); iter.hasNext(); ) {
Foo foo = (Foo) iter.next();
foo.bar();
}
maybe introduce a C#-like foreach statement...
foreach( Foo foo in something.iterator() ) {
foo.bar();
}
Just thinking aloud here (as always ;-). Thoughts?
We'd prefer if you'd refer to it as a Velocity-like foreach statement
;)
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: commons dbcp or pool problems
So in the event anyone is interested, the Poolman maintainer has retired. I no longer have time to maintain the PoolMan JDBC driver and resource pooling and caching utility, and am now seeking a qualified, comitted software engineer to assume control over its future. If interested, please send email to [EMAIL PROTECTED] with a brief summary of your qualifications. http://sourceforge.net/forum/forum.php?forum_id=44181 This really isn't my realm, but I thought I would bring it up in case any one here would be up to working with Neville to bring poolman here. There was some talk about that last year, so maybe it's time to revive the discussions. Of course, we'd have to get the license changed, et cetera. Meanwhile, I'm tucking the last production release away for safekeeping. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] thoughts on Java pre processor
This is kinda off topic but I've been musing lately about a preprocessor
for
Java. One of the early attractions to me about Java some 5-6 years ago
coming from a mostly C++ background was that there was no pre processor
and
obfuscation, so Java code was very easy to read.
However in theses groovy days of having Ant to do all our building, JUnit
for unit testing and the various logging packages for logging, we rarely
need much from an IDE these days but a basic editor (does anyone even use
debuggers any more?), so maybe diverging from the Java Language spec
wouldn't be too bad. .
But using a decent IDE such as Eclipse* eliminates the need for all that by
automating the generation of boilerplate code using templates. Using a
pre-processor to avoid typing code is pretty pointless, IMHO. Just get a
better tool.
Where pre-processor type activity *is* useful is for adding things like
generic types - in other words, where you are changing the semantics of the
code by enriching an existing concept. Having a generic (parameterized)
type means that you can enforce type-safety of of single-type collections,
e.g. declare a list of Strings that will throw an exception if you try to
add an Integer. JSR-14 is working on this already, so it could be
counter-productive to come up with something similar.
Okay, I'm being a bit harsh - the JavaBean property example is valid
enough, as is the event listener. I think the main thing is to distinguish
between shortcuts just to save typing (like the foreach) and real patterns
(like events and properties).
Another proposal that is more like your syntactic sugar usage is JSR-65 -
concise object array literals, which would convert:
ArrayList al = new ArrayList({ foo, 10, 0.75});
into:
ArrayList al = new ArrayList(new Object[] { foo, new Integer(10), new
Double(0.75)});
* Yes, I know there are other good IDEs out there. Emacs JDE, for example.
I believe there also something called NutBones or something like that :-)
Regards
Colin M Sharples
I/T Architect
IBM Global Services New Zealand
email: [EMAIL PROTECTED]
phone: 64-4-5769853
mobile: 64-21-402085
fax: 64-4-5765616
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: commons dbcp or pool problems
What is the status of commons dbcp? Apart from what look like minor edits from Craig, it's been 10 months (according to CVS) since any major work has been done. Is this considered done and production quality or it still in beta (or less?) I noticed that it's part of the Struts nightly build now.. Does that vouch for its completeness in any way? If dbcp is in good shape (which I'm trying to ask about), then is there any point in also trying to bring poolman here? Bryan On Tue, 2002-03-05 at 21:00, Ted Husted wrote: So in the event anyone is interested, the Poolman maintainer has retired. I no longer have time to maintain the PoolMan JDBC driver and resource pooling and caching utility, and am now seeking a qualified, comitted software engineer to assume control over its future. If interested, please send email to [EMAIL PROTECTED] with a brief summary of your qualifications. http://sourceforge.net/forum/forum.php?forum_id=44181 This really isn't my realm, but I thought I would bring it up in case any one here would be up to working with Neville to bring poolman here. There was some talk about that last year, so maybe it's time to revive the discussions. Of course, we'd have to get the license changed, et cetera. Meanwhile, I'm tucking the last production release away for safekeeping. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[DBCP] JSDK 1.4 migration
I am looking at a possibility of using commons-dbcp (and pool) as DataSource wrappers for my Cayenne project. I already have my own implementation of this, but dbcp/pool looks more flexible (besides it is probably better tested too :-)). One issues I need to solve is the ability to compile with JSDK 1.4. As you may know Sun added lots of new methods to java.sql.Connection, some of them call on their new classes (java.sql.Savepoint). So obviously some work is required to port the existing code. I've been in and out of this list, so I am not sure if any steps in this direction have been planned. I'd appreciate if somebody can enlighten me on that. If not, I will probably do the port myself. (If somebody applies my patches). It looks like for backwards compatibility (under JSDK 1.3 methods calling Savepoint won't compile), paralel implementation of conflicting classes is needed. build.xml will determine which one to include. This looks rather dirty, but I can't think of a better way. -- ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- - Andrei (a.k.a. Andrus) Adamchik Home of Cayenne - O/R Persistence Framework http://objectstyle.org/cayenne/ email: andrus-jk at objectstyle dot org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] thoughts on Java pre processor
From: Jon Scott Stevens [EMAIL PROTECTED] This is the perfect job for Velocity. :-) Just use Velocity to generate your .java code. I guess I walked right into that one ;-) I was more thinking of should we try define a Java++ language but I take your point. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] thoughts on Java pre processor
Because someone has to do it. How about a C# to bytecode compiler :) The opposite of MS' J# plugin for VisStudio. On Wed, 6 Mar 2002, James Strachan wrote: I was more thinking of should we try define a Java++ language but I take your point. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
