Re: votes for ingo and a call for ASF members
Jon Stevens wrote: i'm +1 on giving ingo cvs write, his patches look fine and he wants to work on things which is great! So, I think we need to get one more vote from an active developer as Santiago gave his vote as well. I'm +1 as well. Is there any other ASF members on this list? If so, who is going to take responsibility for watching over this project? I don't have the time/energy to do so right now and one of the things that we are advocating in the ASF is that at least one member be a "peer" of each and every project to help insure that things go the "ASF way". i put that in quotes cause it isn't written down yet, but it is communicated at the members level of the organization. I'm going to restate what I said in London: If there are no members who are willing to be a peer, we will probably end up turning this project into an "incubator" status when the merge of Java Apache and the Jakarta projects happen (see java.apache.org for more information) and it will loose its "right" to call it "Apache Jetspeed" until a member is willing to be a peer. it would be up to you guys to petition the members of the ASF to find someone who is willing to be a peer for this project. Thanks for the information, we now have to find a willing member... -- Raphaël Luta - [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: SecurityManager - work in progress ?
[EMAIL PROTECTED] wrote: The following class seems to be used nowhere in JetSpeed. Is this work in progress ? I think Kevin started something but I have no clue what it was about... -- Raphaël Luta - [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
No portlets appear after install
Title: No portlets appear after install Hey, I've installed Jetspeed 1.1 on Allaire JRun 3.01, Solaris 7, and everything seems to work except the default portlets themselves. I get the Jetspeed HTML banner, but all of the portlet content comes as this: !-- BEGIN JETSPEED ROOT DOCUMENT --!-- BEGIN PORTLET CONTROLLER --!-- PORTLET CONTROLLER - NUM_COLS = 3 --!-- PORTLET CONTROLLER - WIDTH = 100% --centertable width=100%tr align=centertd valign=top align=centertable width=100%/table/tdtd valign=top align=centertable width=100%/table/tdtd valign=top align=centertable width=100%/table/td/tr/table/center!-- END PORTLET CONTROLLER --!-- END JETSPEED ROOT DOCUMENT -- Any ideas? Jim Berrettini, iVillage, Inc.
[Proposal] Jetspeed: release and work plan
I propose that the work on Jetspeed is organised in the following fashion. * Improve the current 1.2 CVS code in order to release a clean and working software in the near future. This involves mostly short term work and will try to preserve compatibility with the 1.2 beta(s). Maybe we should release a new beta ASAP so that external people can checkout a code pretty similar to the one sitting in CVS, this will simplify user support. * In parallel to this, start working on a brand new Jetspeed 2 design along with a generic Portlet API. * As soon as the Portlet API is solidified, start a back-port of this API to the 1.2 branch, thus creating a new 1.x Portlet API implementation. We have thus a work plan like: Short term : * fix and clean 1.2 branch = 1.2 release * start design of new Portlet API = release a Portlet API Mid-term (depends on Portlet API work) : * start Jetspeed 2 design on top of Cocoon 2 = implement alpha quality implementation * backport Portlet API to 1.x branch * identify and componentized shared code between 2.x and 1.x branches = release of a 1.x Jetspeed Portal implemented on top of Turbine Long-term : * release Jetspeed 2 implementation on top of Cocoon 2 I didn't put any date or timeframe on this since it's a voluntary contributions ( hint... ;) ). I plan to work on the clean up and upgrade of the 1.2 branch and then focus entirely on the Jetspeed 2 implementation. -- Raphaël Luta - [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
RE: [Proposal] Jetspeed: release and work plan
Raphaël Luta wrote: I propose that the work on Jetspeed is organised in the following fashion. * Improve the current 1.2 CVS code in order to release a clean and working software in the near future. This involves mostly short term work and will try to preserve compatibility with the 1.2 beta(s). Maybe we should release a new beta ASAP so that external people can checkout a code pretty similar to the one sitting in CVS, this will simplify user support. This is the most important thing. And it necessary ASAP. Santiago and the rest of people in the spanish group will work hard in this address. * In parallel to this, start working on a brand new Jetspeed 2 design along with a generic Portlet API. * As soon as the Portlet API is solidified, start a back-port of this API to the 1.2 branch, thus creating a new 1.x Portlet API implementation. Portlet API is neccesary for all, but it's important to define correctly. We have thus a work plan like: Short term : * fix and clean 1.2 branch = 1.2 release * start design of new Portlet API = release a Portlet API Mid-term (depends on Portlet API work) : * start Jetspeed 2 design on top of Cocoon 2 = implement alpha quality implementation * backport Portlet API to 1.x branch * identify and componentized shared code between 2.x and 1.x branches = release of a 1.x Jetspeed Portal implemented on top of Turbine Long-term : * release Jetspeed 2 implementation on top of Cocoon 2 I didn't put any date or timeframe on this since it's a voluntary contributions ( hint... ;) ). I plan to work on the clean up and upgrade of the 1.2 branch and then focus entirely on the Jetspeed 2 implementation. The most important think: we will work hard (spanish group) to do JetSpeed 1.2 fine. ! "Ask not what JetSpeed can do for you--ask what you can do for JetSpeed." -- Roberto Rodriguez - [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: Cannot get around cache
I have received many request for this portlet code, so I am posting it at
the bottom of the message.
Here is the scenario. I have created several services which require a user
to login so that I can offer user-specific information. An example is I have
an ASP page which delivers an HTML table of the user's todo list. I wanted
to display this HTML-table within a Jetspeed portlet.
What I needed was a portlet which would:
- post the Turbine userid and password to the service
- the different services look for different variable-name. IE - userid=,
username=, loginid=...
- in case of a non-logged in user, I need a default id/password (I use this
for the company calendar)
- The content should NOT be cached
What I would like to add is
- option as to whether the info is POSTed or GETed
- Same features when fetching RSS content.
Anyway, here is the code. Please let me know if you find bugs and I will do
my best to correct them.
Steve B.
PS - this D*** MS-Outlook sometimes adds "file:" in front of "//" comments
in my code. Please be sure this has not occured before attempting to
compile.
PPS - After compiling, add the LoginURL.class to the
org.apache.jetspeed.portal.portlets folder of the Jetspeed.jar
/*
* This portlet will pass the Turbine Userid and password to a URL for
fetching
* HTML content. The content returned should only be a HTML page fragment
(ie - no HTML
* nor body tags).
* In the Jetspeed.jcfg (portal library file), you should define the variable
names that
* the target URL will be reading for these values. You should also specify
the default
* userid and password jetspeed should send in the case of a non-logged in
user. Here is
* an example entry:
*
* portlet-entry type="abstract" name="LoginURL" hidden="false"
application="false" admin="false"
* classnameorg.apache.jetspeed.portal.portlets.LoginURL/classname
* /portlet-entry
*
* portlet-entry type="ref" parent="LoginURL" name="eResourceManagerLogin"
hidden="false" application="false" admin="false"
*
urlhttp://myserver.mySite.com/eResourceManager/PortletScheduleDisplay.asp
/url
* parameter value="userid" name="userid_varname"/
* parameter value="password" name="password_varname"/
* parameter value="velos_intranet" name="default_userid"/
* parameter value="passkey" name="default_password"/
* meta-info
*titleeResourceManager/title
*descriptionA listing of events for today/description
* /meta-info
* /portlet-entry
*/
package org.apache.jetspeed.portal.portlets;
//Element Construction Set
import org.apache.ecs.html.*;
import org.apache.ecs.ConcreteElement;
import org.apache.ecs.ElementContainer;
import org.apache.ecs.StringElement;
//Jetspeed stuff
import org.apache.jetspeed.portal.*;
import org.apache.jetspeed.util.*;
import org.apache.jetspeed.cache.memory.*;
import org.apache.jetspeed.cache.disk.*;
//turbine
import org.apache.turbine.util.*;
//standard java stuff
import java.net.*;
import java.io.*;
//ecs stuff
import org.apache.ecs.*;
import org.apache.ecs.html.*;
/**
@author a href="mailto:[EMAIL PROTECTED]"Steve Belt/a
@version $Id: LoginURL.java,v 1.19 2000/11/08 21:19:56 belt Exp $
*/
public class LoginURL extends FileServerPortlet {
/**
@author a href="mailto:[EMAIL PROTECTED]"Steve Belt/a
@version $Id: LoginURL.java,v 1.19 2000/11/08 21:19:56 belt Exp $
*/
public void init() throws PortletException {
PortletConfig config = this.getPortletConfig();
RunData rundata = config.getRunData();
// Get the parameter names that need to be posted to the URL
String userid_varname =
his.getPortletConfig().getInitParameter( "userid_varname" );
if (userid_varname == null)
userid_varname = "userid";
String password_varname =
his.getPortletConfig().getInitParameter( "password_varname" );
if (password_varname == null)
password_varname = "password";
// Get the logged-in userid / password. If not defined, get the defaults
String userid = rundata.getUser().getUserName();
if ( userid == null )
userid = this.getPortletConfig().getInitParameter( "default_userid" );
String password = rundata.getUser().getPassword();
if ( password == null )
password =
this.getPortletConfig().getInitParameter( "default_password" );
String szPostString = userid_varname + "=" + userid +
"" + password_varname + "=" + password;
// Here is a version of the szPostString which hides the password (for
logging)
String szSecurePostString = "";
for ( int x=0; x password.length(); x++)
szSecurePostString += "*";
szSecurePostString = userid_varname + "=" + userid +
"" + password_varname + "=" +szSecurePostString;
//fetch the URL as a String...
try {
Log.note("accessing non-cached URL site "+config.getURL());
Log.note("posting string = "+szSecurePostString);
this.setContent( new ClearElement( this.getURL( config.getURL(),
szPostString ) ) );
}
catch (Exception e)
{
throw new PortletException(
RE: [Proposal] Jetspeed 1.2 TODO list
-Original Message- From: Raphael Luta [mailto:[EMAIL PROTECTED]] Sent: Donnerstag, 9. November 2000 07:56 To: JetSpeed Subject: [Proposal] Jetspeed 1.2 TODO list This a quick list of issues I think should be resolved before releasing 1.2. I've put some names behind some tasks because these people expressed their intention to implement the feature. * Componentization of the system Currently Jetspeed is both a portal layout system and a simple OCS syndication system. I think we should better separate both functionalities so that each can be run separately. Also we have also devleopped some nice portlets (such as JCM or Poll) which should be moved out of the engine, both to show that their use is optional and to give tham a better visibility. This componentization is really necessary. For people new to Jetspeed it's not easy to understand the complete architecture and system-flow. The reasons are clearly missing documentation (I will try to bring in some high-level docu soon) and no clear seperation into functional blocks. Also we will make a proposal in the next time to bring in some functionality for handling foreign content sources (cookies, URL-rewriting) to the core. I'm sure we will have an interesting dicussion where this functionality should resist. * Turbine support Jetspeed is really a Turbine application and yet has not followed Turbine progress in the recent months. Several items may be tackled : - allow the use of templates with PSML elements - integrate Turbine ACLs in registry [I've already started the work on using templates in Jetspeed and Marcus Schwartz and Ingo Schuster are willing to work on the user/ACL stuff]. we have an implementation of proposal 4, which enables to define security-permissions on each portlet and parts of it's functionality (edit, maximize, ...). This functionality is directly accessing Turbine's ACLs to retrieve the permissions/roles of the current user. We will post this stuff as soon as head has stabilized. * Provide a working customizer At least a basic customizer (or customizer hook) should exist for both portlets and the layout system. that's really important. Without this functionality the use of Jetspeed is dramatically decreased in "real" cases. We have a small solution for this, but I'm not sure if it's really fitting into the community's approach, because we are using "external" parsers/creators and UI's to visualize and edit the layouts. Also the possible functionality of PSML is reduced in some areas, because we don't need it (e.g. we are just supporting 2/3 columns and no complex nested structures). We will check, whether we can bring back parts of it to open source. * Fix multi-threaded operation / caching rework Make sure that the engine may be safely used in a multi-threaded, multi-user environment. If we want to avoid a major API change for the 1.2 release, this may require to disable or rework portlet caching. In any case, the caching system needs an audit to identify its shortcomings. * Create a WAR We should be able to provide Jetspeed as a WAR application. This may require to change the way some properties are used so that all properties URL or files can be considered relative to the webapp root. * Update documentation A lot of documentation has been contributed to the mailing-list but usually it's not correctly marked-up. Someone should review all the existing docs to make sure it's up to date and maybe markup new docs for installation/development support. I will post some new docs in the next weeks. But it will just cover parts of the whole thing. But better as nothing :-) * Castor support Some time ago, it was decided to drop Castor support and provide another XML - Java mechanism. This would imply a lot of factory rework. [I'd stick with Castor for 1.2 and remove it for the later releases] +1. It works and we should focus on things, which are not working * Cocoon support The Cocoon support provided by Jetspeed is currently a hack and I don't think it works with Cocoon 1.8, so we either need to drop this feature and use a simple XSL processor or re-design a Cocoon bridge. [I'd vote for moving the CocoonPortlet and Cocoon support to a modules directory and remove any dependency of the engine on Cocoon 1] +1. seperation is always good. I also don't like the current hack. OK, enough for now. Let's do some real work... :( Currently we have a high amount of internal stuff to do and will focus on "our" areas with full power starting in 3-4 weeks. Sorry for this delay :-( -- Raphaël Luta - [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] --
Re: lucene search engine!
on 11/9/2000 12:00 AM, "Mamei Marco" [EMAIL PROTECTED] wrote: Hi, I found a free open source search engine. I think it would be a cool add to jetspeed! Go to http://sourceforge.net/projects/lucene/ and download it. It is a great search engine framework, written (in Java) by someone with years of experience in doing search engines (he was the main Excite search guy, until he moved elsewhere just recently). bye, Marco This isn't news... Anyway, integration should happen at the Turbine (ie: framework) level. -jon -- http://scarab.tigris.org/| http://noodle.tigris.org/ http://java.apache.org/ | http://java.apache.org/turbine/ http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/ http://www.collab.net/ | http://www.sourcexchange.com/ -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: votes for ingo and a call for ASF members
on 11/9/2000 8:23 AM, "ingo schuster" [EMAIL PROTECTED] wrote: Thanks, I'll be glad to contribute to jetspeed directly! Two things I would definitely focus on is the integration off the new Turbine as soon as the security branch is merged back into the head. Another thing is to clean the jetspeed code, e.g. removing the remaining jyve dependencies. I already looked into it and made a list of files tht need to be updated. I'll send some diffs tomorrow. ingo. done (ingo, i emailed you privately). Also, since i'm not going to be watching this list _that_ closely, you guys are going to have to contact me directly for any additional cvs write needs. it will be up to you guys to manage yourselves like big kids. :-) thanks, -jon -- http://scarab.tigris.org/| http://noodle.tigris.org/ http://java.apache.org/ | http://java.apache.org/turbine/ http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/ http://www.collab.net/ | http://www.sourcexchange.com/ -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: New template branch
on 11/9/2000 7:55 AM, "Raphael Luta" [EMAIL PROTECTED] wrote: I've created a new branch for supporting my Turbine template integration work: template_01-branch so this work will not break the other bug fixing activity that may occur on the trunk. Anybody willing to join me and work on this issue is of course most welcome. Now, the thing to do would be to create a page like this on the Jetspeed website: http://java.apache.org/turbine/branches.html -jon -- http://scarab.tigris.org/| http://noodle.tigris.org/ http://java.apache.org/ | http://java.apache.org/turbine/ http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/ http://www.collab.net/ | http://www.sourcexchange.com/ -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: AW: [Proposal] Jetspeed: release and work plan
Christoph Sturm wrote: Hi! -Ursprüngliche Nachricht- Von: Raphael Luta [mailto:[EMAIL PROTECTED]] Mid-term (depends on Portlet API work) : * start Jetspeed 2 design on top of Cocoon 2 = implement alpha quality implementation * backport Portlet API to 1.x branch * identify and componentized shared code between 2.x and 1.x branches = release of a 1.x Jetspeed Portal implemented on top of Turbine Long-term : * release Jetspeed 2 implementation on top of Cocoon 2 Will jetspeed 2 also be based on turbine or is cocoon 2 a whole framework? That should be decided collectively here at due time. My current view is: Jetspeed is two things stick together: - a windowing engine and a desktop for the browser, highly customisable. - a simple tool for retrieving, syndicating and agreggating information channels as "windows". The second feature should remain there as a simple implementation, so that Jetspeed can be demoed and is a showcase of new technologies (Marketing ... :-) But any serious portal implementation will rework this part, and new projects are arising/will arise to tackle with this problem. Turbine provides excellent services, and templating is good for prototyping solutions. It aims to be a support for the development of webapps, and any portal will have/use webapps. It would act more like the Event Dispatcher and the OS of our network desktop. I see Cocoon as a very good conceptuallization of a "rendering engine" (our screen and printing driver and graphics libraries, if you follow the analogy), and in Cocoon 2 we can have good solutions for having Model/View/Controller webapps. While Cocoon is more oriented to publishing than to webapps, I think they are shifting their views as Cocoon 2 proceeds. So, I don't have an answer for your question. I would answer with standard metaknowledge: When you don't have a clear decision, try to postpone the decision point as much as reasonably possible. Other views on that? N.B. My knowledge of Cocoon 2 is really shallow. I have feelings more than certainties. WRT Turbine, I have looked at the code and I'm following the list since august or september, so I'm more informed. -Chris -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: AW: [Proposal] Jetspeed: release and work plan
I see Cocoon as a very good conceptuallization of a "rendering engine" (our screen and printing driver and graphics libraries, if you follow the analogy), and in Cocoon 2 we can have good solutions for having Model/View/Controller webapps. While Cocoon is more oriented to publishing than to webapps, I think they are shifting their views as Cocoon 2 proceeds. Other views on that? N.B. My knowledge of Cocoon 2 is really shallow. I have feelings more than certainties. WRT Turbine, I have looked at the code and I'm following the list since august or september, so I'm more informed. I think that Cocoon2 will be a step in the right direction regarding webapps over Cocoon1, but I'm still not convinced that all of the webapp MVC goals have been solved like they have been solved in Turbine. Given that Stefano has decided to drop off the planet, I'm also not certain of the future of Cocoon 2 as well. :-( I understand that any good project can have good people step up and take charge, just like this project, I'm just not convinced that Cocoon2's webapp goals are of completely sound design yet. Turbine has a primary goal of webapp design for nearly 3 years now and I think that we have pretty much gotten most of it worked out...Cocoon2 is still learning what the right way to do things is. So, my advice is to tread lightly and carefully. -jon -- Scarab - Java Servlet Based - Open Source Bug/Issue Tracking System http://scarab.tigris.org/ -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: Cannot get around cache
"Lerenc, Vedran" wrote:
Hi Steve,
please try to implement the follwing method to avoid caching:
/**
* Interface method needed to be implemented in order to control caching
behaviour.
* When returning true, the served resource is cachable, otherwise it's
not cachable
* and the init method will always be called for each request.
* @return flag indicating whether or not the served resource is
cachable
*/
public boolean isCacheable ( )
{
return false;
}
Cheers,
Vedran
-Original Message-
From: sbelt [mailto:[EMAIL PROTECTED]]
Sent: Mittwoch, 8. November 2000 09:12
To: JetSpeed
Subject: Cannot get around cache
I am trying to create a portlet which does not use the
Jetspeed cache when
fetching content from a URL. For some reason, I cannot skip
the Jetspeed
caching system. I see this by looking at the jetspeed log:
[Wed Nov 08 08:53:11 PST 2000] -- NOTICE --
JetspeedDiskCache::getEntry(...) cache hit:
http://development.mysite.com/todolist/PortletScheduleDisplay.asp
Also confusing to me is that if I go into the cache folder
and delete the
cached file, the log still shows a cache hit and the portlet displays
properly on the webpage.
I guess I am not clear when my portlet class is called by Jetspeed.
Apparently, if the file is in cache, there is no need to
access my portlet
code (which makes logical sense). So how do I either tell
jetspeed not to
put the file into cache when it is first retrieved, or, tell
jetspeed not to
check the cache when the portlet is called.
(BTW - I am trying to improve my Jetspeed coding skills, so
if someone will
tell me which classes are used by this process, I will try to
make the code
modifications myself)
Thankyou in advance for any assistance!
Steve B.
PS - Here is the portlet code I am using
bunch of imports snip...
public class LoginURL extends FileServerPortlet {
public void init() throws PortletException {
PortletConfig config = this.getPortletConfig();
Note: Rundata below should be taken ONLY from the (new) getContent(RunData data)
call. It has dissapeared from config currently due to heavy multithreading
issues with this implementation.
So, you are not allowed to use RunData in the init() method. The user and
password only makes sense in the context of a given request.
All initialization now is independent of RunData information.
PortletConfig is safe, but it will have only parameters from the registry
markup. Parameters from the user markup will be handled via the Session or the
Request parameters. (The PortletConfig stuff is not finished.)
RunData rundata = config.getRunData();
String userid = rundata.getUser().getUserName();
String password = rundata.getUser().getPassword();
//fetch the URL as a String...
try {
Log.note("accessing non-cached URL site "+config.getURL());
Log.note("userid = "+userid);
Log.note("password = "+password);
String szPostString = "userid="+userid+"password="+password;
this.setContent( new
earElement( this.getURL( config.getURL(),szPostString ) ) );
} catch (Exception e) {
throw new PortletException( e.getMessage() );
}
}
private String getURL(String url, String szMessage)
throws IOException {
int CAPACITY = 1024;
ByteArrayOutputStream buffer = new ByteArrayOutputStream();
// open connection to the url
URL srcUrl = new URL(url);
URLConnection connection = srcUrl.openConnection();
// send the string
connection.setDoOutput(true);
PrintWriter out = new PrintWriter( connection.getOutputStream());
Use getWriter to get a character stream from the URL and avoid issues with
content-encoding. Else, it will break when your server encoding is different
from the URL encoding.
out.println(szMessage);
out.close();
// Display the results
//now process the InputStream...
InputStream is = connection.getInputStream();
Agais, use getReader to read characters and avoid problems with character
encoding
byte[] bytes = new byte[CAPACITY];
char[] if you use getReader
int readCount = 0;
while( ( readCount = is.read( bytes )) 0 )
{
buffer.write( bytes, 0, readCount);
}
is.close();
return buffer.toString();
}
}
--
--
Please read the FAQ! http://java.apache.org/faq/
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: http://java.apache.org/main/mail.html
Problems?: [EMAIL PROTECTED]
--
--
Please read the FAQ! http://java.apache.org/faq/
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and
Re: Jetspeed installation help
Aron Kramlik wrote: Thanks, I have had a look in the archives and followed the detailed step-by-step guide as well. However, I have a few questions still. For Jetspeed to run do I need to have a database (if so, what is the schema, how do I connect, etc). The schema is in src/sql, or src/sql/external, depending on the database you are using. TurbineResources.properties is the file where you should set up the driver. Ensure that the jdbc driver is in the classpath. I tend to put all the jars in tomcat/lib to have it working. Do I have to install Jetspeed into the default (ROOT) webapp of Tomcat? My installation of Tomcat only has our 3 apps and none of the ones from the default Tomcat installation (examples, admon and ROOT). So has anyone ever configured it as a web app all by itself? I have it running in the js/ webapp. It worked allright. I don't remember any special hack to make it run. The trick is that the resource URIs for the /content branch are not taken relative to the webapp. I put them under "plain" Apache, in /home/http/html/content. We are working on a clear convention on this issue. I put jetspeed-content under http://myhost:8001/content/... to check HTTP PUT with a different server. This is experimental yet. A problem can happen if you put the classes in the webapp lib directory, as Cocoon will not be able to find them for compilation of the XSP pages. When I found this problem I was short of time, so I moved everything back to the main tomcat/lib directory. Has anyone configured it with Apache and T32 mod_jk? I am using mod_jserv, the one coming with Tomcat. Thanks again, Aron. -Original Message- From: Carol Jones/Raleigh/IBM [mailto:[EMAIL PROTECTED]] Sent: Sunday, November 05, 2000 5:21 PM To: JetSpeed Subject: Re: Jetspeed installation help Aron, Quite a few instructions have been posted here on this mailing list, starting around Oct 16-18 or so. You might want to dig through the archives, there was quite a bit of good information there. Carol -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: Website and Documentation
ingo schuster wrote:
At 15:04 2000-11-06 -0800, sbelt wrote:
Do you (or anyone) know how to override the cacheing mechanism? I have
modified the FileServerPortlet so that it will pass the turbine
userid/password to the target URL (using post method). I am trying to
retrieve personal task-list information in the portlet. For some reason, I
cannot get around the cache so that I get the first user's list on all
subsequent instances.
Any help/direction is appreciated.
This is an important concern! Ideally, there would be a way to mark certain
data sources as uncachable. A problem that we found lately:
The users' configuration files (user.psml) get cached as well - not if
they are local, however we are thinking of storing them remotely in a ldap
directory (and still access them through the http request). If now a user
can customize his/her portal page, the configuration file changes, but the
cache still returns the old version!
I never actually understood, why a JetspedDiskCacheEntry has a minimum
expiration time, but if we stick to this, we should provide a way to
invalidate a DiskCacheEntry (e.g. to be used by the UserProfiler/Customizer).
I therefore propose to add following method to the DiskCacheEntry interface:
public void invalidate();
The implementation for the JetspeedDiskCacheEntry would be:
public void invalidate() {
expires = 0;
}
I don't like that the user of a resource handles expiration of the resource. This
should be done by the resource itself or by the administrator of the site.
It would be better to have a mechanism to mark that some URL are what we now call
local (later we will call it dynamic or non-cacheable). The current
implementation does this only for URLs in the localhost. It should do this for a
set of URL prefixes or sufixes, that you can set in the configuration.
In this way, users of the Cache should not manage behaviour of the entries, but
the administrator will mark at deployment "uncacheable" resource extensions,
sites or parts of the space of a server (/cgi-bin, /servlet, etc.)
--
--
Please read the FAQ! http://java.apache.org/faq/
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: http://java.apache.org/main/mail.html
Problems?: [EMAIL PROTECTED]
--
--
Please read the FAQ! http://java.apache.org/faq/
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: http://java.apache.org/main/mail.html
Problems?: [EMAIL PROTECTED]
