RE: [logging] parent-first classloaders
I don't know much about classloaders, but I was working with the WebSphere administration console today and I noticed a drop down for choosing parent-first or child-first classloaders. There's quite a good description of WebSphere's classloader policies at: http://tinyurl.com/6l98v Also follow the Class loaders link in Related concepts at the bottom Colin Sharples IBM Advisory IT Specialist Email: sharples-at-nz.ibm.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Http Client- How to send and recieve Serialized Object using Http Client
Assuming it's not just because of the typo in the content type (should be
application/octet-stream), you could try base 64 encoding the object output
stream, and then you can just use text/plain content type. On the other end you
base 64 decode the response body before passing it to the object input stream.
There are plenty of examples of how to do base 64 encode/decode on the web.
Colin Sharples
IBM Advisory IT Specialist
Email: [EMAIL PROTECTED]
-Original Message-
From: Sanjeev Tripathi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 8 February 2005 8:18 a.m.
To: commons-dev@jakarta.apache.org
Subject: Http Client- How to send and recieve Serialized Object using
Http Client
Hi,
I am working on thick client proxy that will connect to servlet and
retrive and save data to database. I am using Http Client for
communication.
I am able to send string values using parameter in request
as follows.
//
**
NameValuePair userid = new NameValuePair(LOGIN_NAME,
login);
NameValuePair password = new NameValuePair(LOGIN_PASSWORD,
password);
NameValuePair thickClient = new NameValuePair(ThickClient,
ThickClient);
authpost.setRequestBody(
new NameValuePair[] {action, url, userid,
password,thickClient});
//
**
I am able to send xml string as parameter and able to receive it back
from response as String.
But I am getting problem in serialized user defined objects
communication. Following is not working
//*In Servlet*
if (request.getParameter(ThickClient).equals(ThickClient)) {
response.setContentType(application/octel-stream);
ObjectOutputStream oos = new
ObjectOutputStream(response.getOutputStream());
oos.writeObject(new
com.parago.communication.SubmissionVO(1,Controll
Servlet));
oos.flush();
oos.close();
return;
}
In Thick Client Proxy *
client.executeMethod(authpost);
System.out.println(Login form post: +
authpost.getStatusCode());
ObjectInputStream ois = new
ObjectInputStream(authpost.getResponseBodyAsStream());
SubmissionVO vo = (SubmissionVO)ois.readObject();
System.out.println(id : +vo.getSubmissionId() +: desc: +
vo.getDescription());
//**Here SubmissionVO is Serialized Object***
public class SubmissionVO implements java.io.Serializable{
public SubmissionVO(int id,String desc) {
this.submissionId = id;
this.description = desc;
}
private int submissionId;
private String description;
public int getSubmissionId () {
return submissionId;
}
public String getDescription() {
return description;
}
}
//***
Please suggest me. How to send and receive Serialized User
Defined Value
Objects in using Http Client.
Thanks.
Sanjeev Tripathi
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [digester] initial code for Digester2.0
My major concern is that if we are going to warn people not to implement the Action interface, then what really is the point of providing it in the first place? As I said above, I just cannot think of any situation where a class would want to be an Action *and* extend some other class. Maybe I wasn't clear enough - I didn't say that the Action interface should not be implemented by anything except the default implementation (what indeed would be the point of that?). The point is, the majority of Actions that people create would extend the default implementation, and would be (mostly) immune to API evolution. People who decide to implement Action directly are free to do so - and they accept that if they do so then they will need to evolve with the API. As Oliver said, if you use an interface then you have some extra options for how you add functionality, such as adding new interfaces that extend Action. Colin Sharples IBM Advisory IT Specialist Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [digester] initial code for Digester2.0
- Why is Action an abstract class? So that we can later add new functionality to Action without breaking custom Action subclasses that users have written. As long as we can provide a suitable default implementation in the Action abstract class, everything runs smoothly. One example is the bodySegment callback that is now in Action. In Digester 1.x we could not have added this to Rule without breaking all custom Rule classes. But if digester2.0 had been released without it, we could have added it later with no source or binary compatibility problems. Of course because of Java's single-inheritance policy, it would be impossible for a class to extend both Action and some other class. But (a) this is extremely unlikely, and (b) using an adapter class works around this anyway if it absolutely has to be done. I prefer interface + default abstract implementation, the way Swing provides e.g. Action* and AbstractAction. That way a class can still implement the interface even if it extends from something else, and use a delegate to implement the interface. You can still evolve the interface without breaking existing classes that extend the abstract class. Of course, there is nothing to force people to extend the abstract class, but you can make it clear in the doco for the interface that not to extend the abstract class is an explicit design choice that may have dire consequences. * yes, the name Action is quite overused. Not that I can think of a better alternative... ;-) Colin Sharples IBM Advisory IT Specialist Email: [EMAIL PROTECTED] Mobile: +64 21 402 085 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AW: AW: AW: [proposal] avoiding jar version nightmares
And, in my experience watching work done with tools like Gump, any time people do weird trickery with package names, like Sun renaming some packages from x.y.z to com.sun.x.y.z, this inevitably seems to cause lots of problems somewhere down the line. Exactly. Remember the howls of protest when Sun changed the Swing package names from com.sun.java.swing to javax.swing? They wanted Swing to be part of the core JDK, but there couldn't be any com.sun packages in the core JDK, so they had to find a way to bring a new package into the JDK. The javax.* namespace was created precisely *because* renaming packages is such a PITA - this provided a way for anybody to write an extension to the Java libraries in such a way that they could eventually make it into the core libraries. The fact is, when package names change, it's just way too much trouble to keep up to date. I bet there is still JDK1.1 code out there using the old Swing package names even today. Colin Sharples IBM Advisory IT Specialist Email: [EMAIL PROTECTED] Mobile: +64 21 402 085 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AW: AW: AW: [proposal] avoiding jar version nightmares
I do not think you can compare JDK APIs to commons APIs as you hardly have more than one version of JDK API in your classpath ;) You mean you've never written an RMI app where the client and server were running different JVM levels? ;-) Colin Sharples IBM Advisory IT Specialist Email: [EMAIL PROTECTED] Mobile: +64 21 402 085 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Migrate to SVN?
I doubt Eclipse will ever have built-in svn support because there are several third party plugins available. Since adding a plugin update site is so trivial in Eclipse I wouldn't think this would be a big deal. The plugin I use with Struts svn is http://subclipse.tigris.org/. It works largely the same as Eclipse's cvs plugin. I'm sure Eclipse *will* have built-in svn support at some point. If the Subclipse plug-in provides more or less the same functionality as the standard cvs plug-ins, and conforms to the VCM architecture, then there is every chance that it could be hosted by Eclipse and provided as an alternative to the cvs stuff. The key will be the adoption rate of svn in the wider community - the more projects like Apache/Jakarta that use it, the greater will be the demand for Eclipse to support it... One of those chicken and egg things... ;-) Colin Sharples IBM Advisory IT Specialist Email: sharples-at-nz.ibm.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [workflow] new contributor
I'm going to make Colin happy :-), and go through his outstanding patches this evening (Pacific time in the US), applying what I can. :-)) Thanks, Craig. My project has its first release in a couple of weeks, so after that I will start to take a look at harvesting out re-usable stuff and submitting that back. Colin Sharples IBM Business Consulting Services, New Zealand sharples -at- nz.ibm.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [workflow] new contributor
I have used commons-workflow on a couple of projects - using it right now in fact. I'm using it for two purposes which are I think a little beyond the original scope: 1) As a lightweight RPC mechanism, to locate and run server activities from any arbitrary client (e.g. struts action, browser client, or any client capable of consuming XML over HTTP). 2) As a control framework for a Java client, allowing me to reuse presentation tier logic across multiple channels (e.g. I can re-use non-visual logic process flows in a struts based web app). I'm also thinking about working on an editor for composing activity flows, rather than having to hand edit XML files. I may even end up generating code so that the activities end up as compiled classes, rather than dynamically constructed from an external definition. I would be using Eclipse EMF for this part, so I guess this wouldn't end up in Jakarta, but I would probably make it available through some other means. Colin Sharples IBM Business Consulting Services, New Zealand sharples -at- nz.ibm.com -Original Message- From: Michael Colbert [mailto:[EMAIL PROTECTED] Sent: Thursday, 15 July 2004 6:47 a.m. To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [workflow] new contributor I'd like to volunteer to contribute time and code to the commons-workflow project. I've written two workflow engines in the past two years for two seperate organizations and have some new ideas I would like to explore in open-source. I see the commons-workflow project as a good starting point. Having said that, I'd like to get a feel for the commons-workflow community. Who is using it? What are you using it for? What do you see are the strengths and weaknesses of the project as it stands? How can I help? Thanks, Mike Colbert [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [workflow] outstanding bugs
i'd probably be willing to take a look at the patches once things are a little less hectic (which the way things have been going might be quite a long while) but i suspect that the best plan would be wait until after java one when craig is going to have some more time. Thanks, Robert, I appreciate the response. Of course, I do know the best way to become a committer is to keep on submitting stuff, so I might have a look at a component that's a bit more active ;-) i admire your dedication and if you could remind us again once digester and validator have been released, that'd be very much appreciated. I'll do that. Incidentally, it's likely that the project I'm working on will have quite a bit of stuff that could be submitted back into workflow. Our first release is at the end of July, and after that I'll have a bit of time to look at harvesting some assets. Colin Sharples IBM IT Architect Email: [EMAIL PROTECTED] Mobile: +64 21 402 085 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [workflow] outstanding bugs
Well, if no-one else wants to do it, how do I get committer rights so that I can do it? ;-) -Original Message- From: Sharples, Colin Sent: Thursday, 13 May 2004 10:31 a.m. To: Commons-Dev (E-mail) Subject: [workflow] outstanding bugs Hi, I have a few bugs outstanding on the Workflow component that I would quite like to see fixed - I have supplied patches. Craig is a very busy person, so I don't know if he has time to look at those. Is there anyone else who can take a look at them and apply the patches? The bug numbers are: 26902 26903 28238 Thanks. Colin Sharples IBM IT Architect Email: [EMAIL PROTECTED] Mobile: +64 21 402 085 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[workflow] outstanding bugs
Hi, I have a few bugs outstanding on the Workflow component that I would quite like to see fixed - I have supplied patches. Craig is a very busy person, so I don't know if he has time to look at those. Is there anyone else who can take a look at them and apply the patches? The bug numbers are: 26902 26903 28238 Thanks. Colin Sharples IBM IT Architect Email: [EMAIL PROTECTED] Mobile: +64 21 402 085
Workflow status
I've been off the list for a while, but I've started a new project on which I'm using the workflow component. Has anything been happening on that lately? The CVS repository looks pretty quiet. I have a couple of patches I'd like to submit - should I put them into bugzilla or send them to the list? Colin Sharples IBM IT Architect Email: [EMAIL PROTECTED] Mobile: 021 402 085
