Jetspeed Daily Build Results -
This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/latest/jetspeed.html -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: (Possible) Demise of Hypersonic SQL
At 08:13 02/09/01, Johnny Cass wrote: Hi, I just saw a post on the Turbine list regarding Hypersonic SQL: http://sourceforge.net/forum/forum.php?forum_id=62074 How will the fact that Hypersonic will no longer be actively developed (for the time being?) affect Jetspeed. Will this prompt a change in the DB used or should we wait and see what happens? Guess we're simply switching to my-sql as the default database. I think that's what turbine uses as default anyway. The DB being used is (easily) configurable in TR.p, so there is almost no impact for jetspeed. Thanks for the information, ingo. - Johnny -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Beginner Question
Sarah,
It's a know problem in 1.3a1. Has to do with dependencies between services
- Sometimes they start in the wrong order. There is already a thread on
this list about this problem ("Couldn't process URL: /ocs/local.ocs"):
The reason, as I have tracked, is that FeedDaemon starts running before
RegistryManager is fully initialized. I managed to solve this, but now
the problem is that FeedDaemon starts producing feed before the
PortletRegistry gets initialized.
I think it's not fully solved yet, but people are working on it.
ingo.
At 20:29 02/08/01, Sarah Arnott wrote:
Hi!
I have Jetspeed 1.3a1 and Tomcat 3.2.1 installed on my linux box.
Sometimes when I run the tomcat startup script I get the following on
stdout
$./startup.sh
Guessing TOMCAT_HOME from tomcat.sh to ./..
Setting TOMCAT_HOME to ./..
Using classpath:
./../lib/ant.jar:./../lib/jasper.jar:./../lib/jaxp.jar:./../lib/parser.jar:./../lib/servlet.jar:./../lib/test:./../lib/webserver.jar:/usr/local/jdk1.3/bin/../lib/tools.jar
/usr/local/tomcat/bin# 2001-02-08 03:47:40 - ContextManager: Adding
context Ctx( /examples )
2001-02-08 03:47:40 - ContextManager: Adding context Ctx( /admin )
Starting tomcat. Check logs/tomcat.log for error messages
2001-02-08 03:47:40 - ContextManager: Adding context Ctx( )
2001-02-08 03:47:40 - ContextManager: Adding context Ctx( /test )
2001-02-08 03:47:40 - ContextManager: Adding context Ctx( /jetspeed )
initializing all services using
org.apache.tomcat.facade.ServletConfigImpl
initializing service: ResourcesService
end initializing all services
initializing all services using
org.apache.tomcat.facade.ServletConfigImpl
initializing service: TurbineAssemblerBrokerService
initializing service: TurbineSchedulerService
initializing service: TurbineLocalizationService
initializing service: DaemonFactory
initializing service: DaemonFactory
initializing service: TurbineUniqueIdService
initializing service: EngineContext
initializing service: JspService
initializing service: ProfileManager
initializing service: PortletCache
initializing service: ThreadPool
DCE: isLocal:
url=file:usr/local/tomcat/webapps/jetspeed/WEB-INF/cache/http_my.netscape.com_publish_formats_rss-0.91.dtd
file=
/usr/local/tomcat/webapps/jetspeed/WEB-INF/cache/http_my.netscape.com_publish_formats_rss-0.91.dtd
initializing service: ThreadPool
initializing service: RegistryManager
Error=FeedDaemon: Couldn't process URL: /ocs/local.ocs
Error=FeedDaemon: Couldn't process URL:
http://java.apache.org/jetspeed/channels/apache.ocs
end
Then it hangs here without starting up tomcat. The jetspeed.log file
outputs the following:
snip
[Thu Feb 08 15:47:43 NST 2001] -- NOTICE -- SimpleTransform:
transforming url: file:/usr/local/tomcat/webapps/jetspeed/ocs/local.ocs
with stylesheet:
file:/usr/local/tomcat/webapps/jetspeed/WEB-INF/xsl/ocs.xsl
[Thu Feb 08 15:47:46 NST 2001] -- NOTICE -- Determining portlets...
[Thu Feb 08 15:47:47 NST 2001] -- NOTICE -- FeedDaemon: Got new
portlets
[Thu Feb 08 15:47:47 NST 2001] -- NOTICE -- Found a total of: 5
portlets...
[Thu Feb 08 15:47:47 NST 2001] -- ERROR -- FeedDaemon: Couldn't
process URL: /ocs/local.ocs
[Thu Feb 08 15:47:47 NST 2001] -- ERROR --
Exception: java.lang.NullPointerException
Stack Trace follows:
java.lang.NullPointerException
at
org.apache.jetspeed.daemon.impl.util.feeddaemon.EntryInstantiator.process(EntryInstantiator.java:95)
at
org.apache.jetspeed.daemon.impl.FeedDaemon.run(FeedDaemon.java:218)
at
org.apache.jetspeed.daemon.DaemonThread.runDaemon(DaemonThread.java:147)
at
org.apache.jetspeed.daemon.DaemonThread.run(DaemonThread.java:100)
[Thu Feb 08 15:47:47 NST 2001] -- NOTICE -- BEGIN FEED -
http://java.apache.org/jetspeed/channels/apache.ocs
[Thu Feb 08 15:47:47 NST 2001] -- NOTICE -- Returning local cached URL
[Thu Feb 08 15:47:47 NST 2001] -- NOTICE -- Returning local URL because
it is cached: http://java.apache.org/jetspeed/channels/apache.ocs
[Thu Feb 08 15:47:47 NST 2001] -- NOTICE -- FeedDaemon: transforming
url:
file:usr/local/tomcat/webapps/jetspeed/WEB-INF/cache/http_java.apache.org_jetspeed_channels_apache.ocs
with stylesheet:
file:/usr/local/tomcat/webapps/jetspeed/WEB-INF/xsl/ocs.xsl
[Thu Feb 08 15:47:47 NST 2001] -- NOTICE -- Adding Local to cache list:
file:usr/local/tomcat/webapps/jetspeed/WEB-INF/cache/http_java.apache.org_jetspeed_channels_apache.ocs
[Thu Feb 08 15:47:47 NST 2001] -- NOTICE -- Returning local cached URL
[Thu Feb 08 15:47:47 NST 2001] -- NOTICE -- Returning local URL because
it is cached:
file:/usr/local/tomcat/webapps/jetspeed/WEB-INF/xsl/ocs.xsl
[Thu Feb 08 15:47:47 NST 2001] -- NOTICE -- SimpleTransform:
transforming url:
file:usr/local/tomcat/webapps/jetspeed/WEB-INF/cache/http_java.apache.org_jetspeed_channels_apache.ocs
with stylesheet:
file:/usr/local/tomcat/webapps/jetspeed/WEB-INF/xsl/ocs.xsl
[Thu Feb 08 15:47:48 NST 2001] -- NOTICE -- Determining
Re: Secure Portlets
At 13:10 08/02/2001 +0100, you wrote: Raphael, I think I do understand what you mean. "Well-formed XML" simply implies that the output of the portlet will be parseable by an XML parser but does not enforce (or even expect) any DTD or schema compliance. How on earth do you want to write a parser for a language that you don't know. Leaving out the DTD only means that the portlet is not technically bound, it would still need to compliant to some language. Unless --- unless you are talking about different parsers for mime-type which the aggregation module may be to handle. Even if the API does not mandate a DTD compliance, in order to aggregate and post-process the documents the portal will always assume that the portlet will output a known format (XHTML, WML, etc...). However this a portal implementation issue. But then, parsing the markup - even if it was well-formed - is an expensive operation. I don't think we should enforce this burden onto the portal just because we are not able to provide utility functions to do link substitution in place (that is, right in the template). Also, you cannot leave this decision open, because a portlet that relies on the portal to do certain substitions would not run properly on a portal that goes for performace and leaves everything through. I think this discussion is crucial to the future of Jetspeed. Looking forward to more arguments... It is a very important choice. I agree that parsing may be an expensive operation (although I believe SAX parsing is quite efficient) but, since I base my reasoning on the premise that in 80% of the requests, the portal will *have* to parse the result in order to aggregate correctly the portlet output, it's a cost that we'll encounter in most case and that we should try to minimize. The portlet to portal communication can be done through - streams - SAX events - string buffers - DOM tree We already decided on a stream oriented API so the choice can be restricted to : - char/byte streams - SAX event streams If the byte stream is chosen as the default communication medium between the portlet and the portal, we will have: if portlet natively generates byte streams : - optimal performance when the portal does not need to post-process output - degraded performance when the portal needs to post-process the output (parsing byte stream) if portlet natively generates XML events : - slightly degraded performance when the portal does not need to post-process output (event stream - byte stream conversion) - very degraded performance when the portal needs to post-process output (event - byte conversion and then reparsing by the portal) If SAX stream is the default communication with the portal: if portlet generates byte streams : - very degraded performance if the protal does not post-process (byte - SAX, then SAX - byte) - degraded performance (parsing byte - event) when the portal postprocess the events if portlets generates SAX events : - slightly degraded perf when no post-processing (event - byte serialization) - optimal performance when post-processing (already parsed) As you can see depending on your expected portal behavior and portlet development tools/methodology, either byte streams or SAX streams are the optimal choice. So my proposal for the Portlet API is : * add a getContentHandlet() method in the PortletResponse interface so that a portlet that wishes so can directly output events to the portal event handler. * allow the portlet either to use getWriter() or getContentHandler() but not both (mutually exclusive use just like ServletResponse.getWriter() and getOutputStream()). That way, it's the portal implementation of the PortletResponse which will decide which is the most efficient way to output data (depending on the whether the implementation parses the char stream into an event stream, serialize the event stream into a char stream or tries to handle natively both). Does that sound reasonable ? -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
Raphal Luta wrote: At 13:10 08/02/2001 +0100, you wrote: Raphael, I think I do understand what you mean. "Well-formed XML" simply implies that the output of the portlet will be parseable by an XML parser but does not enforce (or even expect) any DTD or schema compliance. How on earth do you want to write a parser for a language that you don't know. Leaving out the DTD only means that the portlet is not technically bound, it would still need to compliant to some language. Unless --- unless you are talking about different parsers for mime-type which the aggregation module may be to handle. Even if the API does not mandate a DTD compliance, in order to aggregate and post-process the documents the portal will always assume that the portlet will output a known format (XHTML, WML, etc...). However this a portal implementation issue. But then, parsing the markup - even if it was well-formed - is an expensive operation. I don't think we should enforce this burden onto the portal just because we are not able to provide utility functions to do link substitution in place (that is, right in the template). Also, you cannot leave this decision open, because a portlet that relies on the portal to do certain substitions would not run properly on a portal that goes for performace and leaves everything through. I think this discussion is crucial to the future of Jetspeed. Looking forward to more arguments... It is a very important choice. I agree that parsing may be an expensive operation (although I believe SAX parsing is quite efficient) but, since I base my reasoning on the premise that in 80% of the requests, the portal will *have* to parse the result in order to aggregate correctly the portlet output, it's a cost that we'll encounter in most case and that we should try to minimize. The portlet to portal communication can be done through - streams - SAX events - string buffers - DOM tree +1. That is what I was trying to say in my previous post. We already decided on a stream oriented API so the choice can be restricted to : - char/byte streams - SAX event streams A DOM oriented portlet could make use of a utility class to convert DOM into SAX (already there in most SAX parsers) If the byte stream is chosen as the default communication medium between the portlet and the portal, we will have: if portlet natively generates byte streams : - optimal performance when the portal does not need to post-process output - degraded performance when the portal needs to post-process the output (parsing byte stream) if portlet natively generates XML events : - slightly degraded performance when the portal does not need to post-process output (event stream - byte stream conversion) - very degraded performance when the portal needs to post-process output (event - byte conversion and then reparsing by the portal) If SAX stream is the default communication with the portal: if portlet generates byte streams : - very degraded performance if the protal does not post-process (byte - SAX, then SAX - byte) - degraded performance (parsing byte - event) when the portal postprocess the events if portlets generates SAX events : - slightly degraded perf when no post-processing (event - byte serialization) - optimal performance when post-processing (already parsed) As you can see depending on your expected portal behavior and portlet development tools/methodology, either byte streams or SAX streams are the optimal choice. So my proposal for the Portlet API is : * add a getContentHandlet() method in the PortletResponse interface so that a portlet that wishes so can directly output events to the portal event handler. Don't forget getLexicalHandler() I think it is the only way to manage CDATA and entities. * allow the portlet either to use getWriter() or getContentHandler() but not both (mutually exclusive use just like ServletResponse.getWriter() and getOutputStream()). In case of portlets that use SAX, I have the name SAXlets (c) Santiago Gala 2000. Look in the archives for the post where I copyrighted the name implicitly last year :) These methods could be put into servlet API, and I think they should. Something like an interface javax.servlet.sax.SAXlet. Servlets implementing this interface can be REQUESTED by the container to use getContentHandler and forbidden to use getWriter/getOutputStream. This again (c) Santiago Gala 2001. Feel free to quote it, since it is under Apache license. That way, it's the portal implementation of the PortletResponse which will decide which is the most efficient way to output data (depending on the whether the implementation parses the char stream into an event stream, serialize the event stream into a char stream or tries to handle natively both). Does that sound reasonable ? +1024. I see you have put all my current
BasePeer.initTableSchema(TABLE): null
Hi,
i have a problem with database connection using mySQL, with HyperSonic works
fine, see my turbine resource properties:
# D A T A B A S E S E T T I N G S
#Works fine
#database.default.driver=org.hsql.jdbcDriver
#database.default.url=jdbc:HypersonicSQL:${webapp.dir}/WEB-INF/db/jetspeed
#database.default.username=sa
#database.default.password=
#No work, return Database type org.gjt.mm.mysql.Driver not implemented
#database.default.driver=org.gjt.mm.mysql.Driver
#database.default.url=jdbc:mysql://localhost/turbine
#database.default.username=jetspeed
#database.default.password=1234
#No work, return an error
database.driver=org.gjt.mm.mysql.Driver
database.url=jdbc:mysql://localhost/turbine
#database.username=root
database.username=jetspeed
database.password=1234
Error
Exception: java.lang.Error: Error in BasePeer.initTableSchema(TURBINE_USER):
null
My enviroment:
.WIN NT 2000 SP1
.JDK 1.2.2
.Apache Jetspeed 1.3a1
.Tomcat Version 3.2.1
.Apache/1.3.14 Server at localhost Port 8000
.mySQL drive: mm.mysql-2.0.3.jar
.Jetspeed and Tomcat libs leave original in dist
.MySQL 3.23.31 running on localhost
[]'s
Anderson
--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/
List Help?: [EMAIL PROTECTED]
Re: Updated login-html portlet
Don't I need CVS write permission? or is this an "open" upload area? Steve B. - Original Message - From: "Raphal Luta" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] Sent: Friday, February 09, 2001 12:44 AM Subject: Re: Updated login-html portlet At 11:49 08/02/2001 -0800, you wrote: I have updated my portlet to post data to a site to retrieve tailored portlet information. I had to update this to make it compatible with the lates portlet Controls. At my company, we wanted to show users personal calendar on their home page within a portlet. In our case, the data-source is providing HTML-fragments, but I believe this could be easily modified to get personalized RSS, XML, etc content. I have not looked at the upcoming PortletAPI, so I expect my portlet will have to be modified again; but I will wait until the API is official (hopefully with a few samples ;) to update it again. Last time I posted this portlet (using the deprecated portlet controls), I got many requests for the code. What is the best way for me to share it? Put it in the /modules directory of the Jetspeed CVS -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Email browser
But GPL license. The advantage of jwma is it is BSD licensed which AFAIK is closer to Apache Software License. Steve B. - Original Message - From: "Norbert Huber" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] Sent: Friday, February 09, 2001 2:22 AM Subject: Re: Email browser Hi maybe this fits better for your needs take a look at http://jwebmail.sourceforge.net/ it has pop support allready. Greets nobbi To be done: WML Views, POP Support (currently only IMAP is supported). I will do the conversions soon. Any comments? Any WML experts want to do the WML views? Manjuka ___ Visit http://www.visto.com/info, your free web-based communications center. Visto.com. Life on the Dot. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
At 15:39 09/02/2001 +0100, you wrote: Raphal Luta wrote: We already decided on a stream oriented API so the choice can be restricted to : - char/byte streams - SAX event streams A DOM oriented portlet could make use of a utility class to convert DOM into SAX (already there in most SAX parsers) Yes, converting static - stream structures (either DOM - SAX or buffers - streams) is easy to do and there are already a lot of utility code for doing this. If the byte stream is chosen as the default communication medium between the portlet and the portal, we will have: if portlet natively generates byte streams : - optimal performance when the portal does not need to post-process output - degraded performance when the portal needs to post-process the output (parsing byte stream) if portlet natively generates XML events : - slightly degraded performance when the portal does not need to post-process output (event stream - byte stream conversion) - very degraded performance when the portal needs to post-process output (event - byte conversion and then reparsing by the portal) If SAX stream is the default communication with the portal: if portlet generates byte streams : - very degraded performance if the protal does not post-process (byte - SAX, then SAX - byte) - degraded performance (parsing byte - event) when the portal postprocess the events if portlets generates SAX events : - slightly degraded perf when no post-processing (event - byte serialization) - optimal performance when post-processing (already parsed) As you can see depending on your expected portal behavior and portlet development tools/methodology, either byte streams or SAX streams are the optimal choice. So my proposal for the Portlet API is : * add a getContentHandlet() method in the PortletResponse interface so that a portlet that wishes so can directly output events to the portal event handler. Don't forget getLexicalHandler() I think it is the only way to manage CDATA and entities. You're right, getLexicalHandler() is also needed. * allow the portlet either to use getWriter() or getContentHandler() but not both (mutually exclusive use just like ServletResponse.getWriter() and getOutputStream()). In case of portlets that use SAX, I have the name SAXlets (c) Santiago Gala 2000. Look in the archives for the post where I copyrighted the name implicitly last year :) These methods could be put into servlet API, and I think they should. Something like an interface javax.servlet.sax.SAXlet. Servlets implementing this interface can be REQUESTED by the container to use getContentHandler and forbidden to use getWriter/getOutputStream. This again (c) Santiago Gala 2001. Feel free to quote it, since it is under Apache license. Sorry to break your copyright, but this structure has already been proposed by Assaf Arkin as XMLServlet extension of the servlet API ;-) You can find it in Castor. That probably means it's a good idea :) That way, it's the portal implementation of the PortletResponse which will decide which is the most efficient way to output data (depending on the whether the implementation parses the char stream into an event stream, serialize the event stream into a char stream or tries to handle natively both). Does that sound reasonable ? +1024. I see you have put all my current thinking e-black on e-white. I think Thomas misunderstood my previous post, but this was exactly what I meant. If you want a good laugh provided by our friends at Xo3: http://www.portletsapi.org/ -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
Santiago, Raphael, What's wrong with doing the things you suggested in a derived portlet? Because the stream is the final result you can map (virtually) any other method like SAX, DOM, ECS, etc to the stream. This way the interface is not complicated any further, and portlet container writers are not burdened with several implementation paths. Also, doing this in derived portlets, mean we can easily add other mechanism including Cocoon2 (so I think), without any modifications to the API! Sounds very appealing to me Raphael, I disagree with your assumption that 80% of the portlet markup needs to parsed anyway. If that were so something is fundementally wrong. At any rate, Jetspeed 1.3a1 does not parse any of its generated markup for whatever reason, and it does what it is supposed to do. Cheers, Thomas B. - Original Message - From: "Santiago Gala" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] Sent: Friday, February 09, 2001 15:39 Subject: Re: Secure Portlets Raphal Luta wrote: At 13:10 08/02/2001 +0100, you wrote: Raphael, I think I do understand what you mean. "Well-formed XML" simply implies that the output of the portlet will be parseable by an XML parser but does not enforce (or even expect) any DTD or schema compliance. How on earth do you want to write a parser for a language that you don't know. Leaving out the DTD only means that the portlet is not technically bound, it would still need to compliant to some language. Unless --- unless you are talking about different parsers for mime-type which the aggregation module may be to handle. Even if the API does not mandate a DTD compliance, in order to aggregate and post-process the documents the portal will always assume that the portlet will output a known format (XHTML, WML, etc...). However this a portal implementation issue. But then, parsing the markup - even if it was well-formed - is an expensive operation. I don't think we should enforce this burden onto the portal just because we are not able to provide utility functions to do link substitution in place (that is, right in the template). Also, you cannot leave this decision open, because a portlet that relies on the portal to do certain substitions would not run properly on a portal that goes for performace and leaves everything through. I think this discussion is crucial to the future of Jetspeed. Looking forward to more arguments... It is a very important choice. I agree that parsing may be an expensive operation (although I believe SAX parsing is quite efficient) but, since I base my reasoning on the premise that in 80% of the requests, the portal will *have* to parse the result in order to aggregate correctly the portlet output, it's a cost that we'll encounter in most case and that we should try to minimize. The portlet to portal communication can be done through - streams - SAX events - string buffers - DOM tree +1. That is what I was trying to say in my previous post. We already decided on a stream oriented API so the choice can be restricted to : - char/byte streams - SAX event streams A DOM oriented portlet could make use of a utility class to convert DOM into SAX (already there in most SAX parsers) If the byte stream is chosen as the default communication medium between the portlet and the portal, we will have: if portlet natively generates byte streams : - optimal performance when the portal does not need to post-process output - degraded performance when the portal needs to post-process the output (parsing byte stream) if portlet natively generates XML events : - slightly degraded performance when the portal does not need to post-process output (event stream - byte stream conversion) - very degraded performance when the portal needs to post-process output (event - byte conversion and then reparsing by the portal) If SAX stream is the default communication with the portal: if portlet generates byte streams : - very degraded performance if the protal does not post-process (byte - SAX, then SAX - byte) - degraded performance (parsing byte - event) when the portal postprocess the events if portlets generates SAX events : - slightly degraded perf when no post-processing (event - byte serialization) - optimal performance when post-processing (already parsed) As you can see depending on your expected portal behavior and portlet development tools/methodology, either byte streams or SAX streams are the optimal choice. So my proposal for the Portlet API is : * add a getContentHandlet() method in the PortletResponse interface so that a portlet that wishes so can directly output events to the portal event handler. Don't forget getLexicalHandler() I think it is the only way to manage CDATA and entities. * allow the portlet either to use getWriter() or getContentHandler() but not both (mutually exclusive use just like
Re: Secure Portlets
I can't believe Xo3 did their own thing!!! How do we get them back on board? Thomas B. - Original Message - From: "Raphal Luta" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] Sent: Friday, February 09, 2001 15:58 Subject: Re: Secure Portlets At 15:39 09/02/2001 +0100, you wrote: Raphal Luta wrote: We already decided on a stream oriented API so the choice can be restricted to : - char/byte streams - SAX event streams A DOM oriented portlet could make use of a utility class to convert DOM into SAX (already there in most SAX parsers) Yes, converting static - stream structures (either DOM - SAX or buffers - streams) is easy to do and there are already a lot of utility code for doing this. If the byte stream is chosen as the default communication medium between the portlet and the portal, we will have: if portlet natively generates byte streams : - optimal performance when the portal does not need to post-process output - degraded performance when the portal needs to post-process the output (parsing byte stream) if portlet natively generates XML events : - slightly degraded performance when the portal does not need to post-process output (event stream - byte stream conversion) - very degraded performance when the portal needs to post-process output (event - byte conversion and then reparsing by the portal) If SAX stream is the default communication with the portal: if portlet generates byte streams : - very degraded performance if the protal does not post-process (byte - SAX, then SAX - byte) - degraded performance (parsing byte - event) when the portal postprocess the events if portlets generates SAX events : - slightly degraded perf when no post-processing (event - byte serialization) - optimal performance when post-processing (already parsed) As you can see depending on your expected portal behavior and portlet development tools/methodology, either byte streams or SAX streams are the optimal choice. So my proposal for the Portlet API is : * add a getContentHandlet() method in the PortletResponse interface so that a portlet that wishes so can directly output events to the portal event handler. Don't forget getLexicalHandler() I think it is the only way to manage CDATA and entities. You're right, getLexicalHandler() is also needed. * allow the portlet either to use getWriter() or getContentHandler() but not both (mutually exclusive use just like ServletResponse.getWriter() and getOutputStream()). In case of portlets that use SAX, I have the name SAXlets (c) Santiago Gala 2000. Look in the archives for the post where I copyrighted the name implicitly last year :) These methods could be put into servlet API, and I think they should. Something like an interface javax.servlet.sax.SAXlet. Servlets implementing this interface can be REQUESTED by the container to use getContentHandler and forbidden to use getWriter/getOutputStream. This again (c) Santiago Gala 2001. Feel free to quote it, since it is under Apache license. Sorry to break your copyright, but this structure has already been proposed by Assaf Arkin as XMLServlet extension of the servlet API ;-) You can find it in Castor. That probably means it's a good idea :) That way, it's the portal implementation of the PortletResponse which will decide which is the most efficient way to output data (depending on the whether the implementation parses the char stream into an event stream, serialize the event stream into a char stream or tries to handle natively both). Does that sound reasonable ? +1024. I see you have put all my current thinking e-black on e-white. I think Thomas misunderstood my previous post, but this was exactly what I meant. If you want a good laugh provided by our friends at Xo3: http://www.portletsapi.org/ -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: (Possible) Demise of Hypersonic SQL
At 09:13 09/02/2001 +0200, you wrote: Hi, I just saw a post on the Turbine list regarding Hypersonic SQL: http://sourceforge.net/forum/forum.php?forum_id=62074 How will the fact that Hypersonic will no longer be actively developed (for the time being?) affect Jetspeed. Will this prompt a change in the DB used or should we wait and see what happens? I think we should stick to HypersonicSQL as the default database for the sample webapp bundled with Jetspeed because it's very convenient. Jetspeed supports any database Turbine supports so we don't have any real dependency on HypersonicSQL. -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [Info - long] Templating System
on 2/8/01 6:26 AM, "ingo schuster" [EMAIL PROTECTED] wrote: * Screens no longer produce output, they can be used to do some preprocessing and choose a screenTemplate. - I can't see any use in screens any more, as this way they are just another action. I think we don't need to use screen in the future, just template(s) and action(s) should be sufficient. (Or am I mising something?) You are mostly correct. There *could* be a use for Screens for some types of security control, but in general purpose, screen's are dead. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ http://java.apache.org/turbine/ -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
CVS - how to install from it?
I have a problem with the 1.3a distribution ("Couldn't process URL:
/ocs/local.ocs") I found a message from ingo shuster stating I could fix it
with the files in the CVS directory. How to do an upgrade of the 1.3a
distribution with the files from the CVS.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Santiago Gala
Sent: Friday, February 09, 2001 9:48 AM
To: JetSpeed
Subject: Re: Beginner Question
ingo schuster wrote:
Sarah,
It's a know problem in 1.3a1. Has to do with dependencies between
services - Sometimes they start in the wrong order. There is already a
thread on this list about this problem ("Couldn't process URL:
/ocs/local.ocs"):
The reason, as I have tracked, is that FeedDaemon starts running
before
RegistryManager is fully initialized. I managed to solve
this, but now
the problem is that FeedDaemon starts producing feed before the
PortletRegistry gets initialized.
I think it's not fully solved yet, but people are working on it.
It should be completely solved under any recent cvs version, except that
maybe I have further patches in my local copy that I have not yet
submitted. I will check my diffs.
I have dual processors, so I'm very sensitive to race conditions (that's
the reason why, to ease deployment), and I have not seen any related
problem in the last couple of weeks.
ingo.
--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/
List Help?: [EMAIL PROTECTED]
--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/
List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
Raphal Luta wrote: In case of portlets that use SAX, I have the name SAXlets (c) Santiago Gala 2000. Look in the archives for the post where I copyrighted the name implicitly last year :) These methods could be put into servlet API, and I think they should. Something like an interface javax.servlet.sax.SAXlet. Servlets implementing this interface can be REQUESTED by the container to use getContentHandler and forbidden to use getWriter/getOutputStream. This again (c) Santiago Gala 2001. Feel free to quote it, since it is under Apache license. Sorry to break your copyright, but this structure has already been proposed by Assaf Arkin as XMLServlet extension of the servlet API ;-) You can find it in Castor. That probably means it's a good idea :) Yep. You are right. The idea, and the implementation, was already there. Then I can only claim having invented the word SAXlet. A search in Google only returned the two messages of the list in which it was mentioned... :) I still think javax.servlet.sax.SAXlet would be a catching name:) If you want a good laugh provided by our friends at Xo3: http://www.portletsapi.org/ Well, I find in more sad than other thing. Instead of working together in public, they seem to be trying to close and split the community. So bad. Why they did not put their ideas and discussions here? -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
on 2/9/01 6:24 PM, "Santiago Gala" [EMAIL PROTECTED] wrote: Well, I find in more sad than other thing. Instead of working together in public, they seem to be trying to close and split the community. So bad. Why they did not put their ideas and discussions here? Just guessing... I would suspect that because at the time when they were working with Jetspeed at ApacheCon, they were really put off by how bad Jetspeed had gotten and probably lost a lot of faith in this project and the quality of software produced here. Now, it isn't up to them to regain the faith on their own. It is up to the people of this project to help them regain the faith by trying to work with them and find a common ground together instead of just expecting them to come back... :-) -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ http://java.apache.org/turbine/ -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: (Possible) Demise of Hypersonic SQL
Raphal Luta wrote: At 09:13 09/02/2001 +0200, you wrote: Hi, I just saw a post on the Turbine list regarding Hypersonic SQL: http://sourceforge.net/forum/forum.php?forum_id=62074 How will the fact that Hypersonic will no longer be actively developed (for the time being?) affect Jetspeed. Will this prompt a change in the DB used or should we wait and see what happens? I think we should stick to HypersonicSQL as the default database for the sample webapp bundled with Jetspeed because it's very convenient. Jetspeed supports any database Turbine supports so we don't have any real dependency on HypersonicSQL. +1. Also, if you follow the link, there are already quite a few developers stepping in to follow development and maintenance. I don't think it will die. It is very convenient for small scale portals, and to bundle as a technology demonstrator. I had never used until you bundled it, but then I found it perfect for quick setup. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Jetspeed Daily Build Results -
This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/latest/jetspeed.html -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
