[ADMIN] READ THIS NOW!
Hey all, I'm going to be shutting down this mailing list ASAP as well as moving the CVS tree and website over to jakarta.apache.org ASAP. The issue is that I need to get off of the working-dogs.com servers ASAP and this is something we have needed to do for years now anyway. This also means that Jetspeed will become a Jakarta project. There will be a period of "under construction" that goes on. In other words, I will need help updating the various websites and making sure that everything is setup correctly. Your patience here is appreciated. You will need to re-subscribe to the new mailing lists. So, the new mailing list information is: [EMAIL PROTECTED] [EMAIL PROTECTED] CVS commits will get forwarded to the -dev list. If you have a CVS account and you do not have an apache.org account. Please let me know in private email and I will get your account created and get you the appropriate access. Sorry if I missed anything. I'm sick and have a temperature right now. thanks, -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Portlet security
on 2/24/01 6:45 AM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: Using the Turbine groups, roles, permissions etc to determine whether the access is allowed is just one special case. Often, customers have their own user / group / access control management databases and tools, so often custom Access Control Providers will be required. Best regards, That is why Turbine's is interfaced based and pluggable (ie: factory based). You can easily provide your own back end implementations. thanks, -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: Trailing slashes education
on 2/21/01 12:30 AM, "ingo schuster" [EMAIL PROTECTED] wrote: Ok, know that a trailing slash after a file doesn't make sense (the trailing slashes in the example above on ".rdf" shouldn't be from me). But what's about URLs that end neither with a directory nor with a file (like "http://www.xmlhack.com")? What is the recommended way? It doesn't matter in that case because the request looks like this: GET / HTTP/1.0 If you haven't done this already, I suggest that everyone here take a few hours and read through the HTTP specifications at www.w3.org. They are boring and dry, but they have a lot of good information. P.S.: Thanks btw that you are reading our commits - another pair of eyes that findes problems. :-) Yup. The power of OSS. Keep preaching inside of IBM for us, ok? :-) thanks, -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: [Admin] Documentation generation change
on 2/21/01 1:19 AM, "Raphal Luta" [EMAIL PROTECTED] wrote: I think it would be prefer to only use "standard" jakarta-site2 macros, unless really necessary, so that we don't have to use or own vsl macros definitions. FYI, you can define your own macros very easily (and this is perfectly acceptable): #1. Create a VM_global_library.vm file. #2. Put all your macro's in it. #3. Put the file in your resource.loader.1.resource.path (as defined in your velocity.properties file) You can also submit patches to the site.vsl in the jakarta-site2 module that adds additional functionality. Send your patches directly to me and I will commit them. thanks, -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: Portlet security
on 2/22/01 3:52 PM, "David Sean Taylor" [EMAIL PROTECTED] wrote: Im not sure if Torque can persist to XML files. My guess is that it always needs to go thru a JDBC driver... yup. the design is JDBC based persistence. saving out to a XML file doesn't buy you anything since you can do that by having a JDBC-XML export. -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: Newbie Stupid CVS question
on 2/20/01 10:35 AM, "John Menke" [EMAIL PROTECTED] wrote: I am trying to use JCVS (Java CVS Client) to login to the CVS server. It asks me for a username I try anon with a password of anon and it fails. Below is a full description of the problem. I seem to be connecting to the CVS server correctly, but I cannot authenticate. How can I login for read-only access? JCVS asks for the following information Don't use JCVS? It works fine with every other CVS client. -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]
Chat
on 2/19/01 2:53 PM, "Raphal Luta" [EMAIL PROTECTED] wrote: I'm stuck with a new system installation tomorrow evening :( Let's say Wednesday, February 21, 19h30 GMT IRC: cvs.working-dogs.com Channel: jetspeed Ok for everybody ? Jon, do you mind if we use your IRC server for this ? No problem. Guys, please change the subject line to be appropriate. -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]
Chat
on 2/20/01 2:50 AM, "ingo schuster" [EMAIL PROTECTED] wrote: The time if ok for me. However I have trouble connecting to the server. Which port has to be used? ingo. Standard IRC port 6667 It does sometimes take a while to connect to the server if you don't have reverse DNS or identd running. -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Trailing slashes education
User: ingo Date: 01/02/20 04:27:57 Modified:xdocscontent-syndication.xml developer-notes.xml features.xml resources.xml usejetspeed.xml wap.xml Log: [docs] trailing slashes in URLs ul - lia href="http://www.xmlhack.com"XMLHack/a/li + lia href="http://www.xmlhack.com/"XMLHack/a/li lia href="http://w.moreover.com/"Moreover/a/li lia href="http://www.mozilla.org/news.rdf/"Mozilla/a/li lia href="http://www.slashdot.org/slashdot.rdf/"SlashDot/a/li Ok, I think we need more education here. :-) Trailing slashes are ONLY needed in the following case: If the URI ends with a directory. No other time is a trailing slash needed. If a URI looks like the URL's above, you don't need it. In fact, in the case of a URI that ends with a suffix (ie: file vs. directory), you will get an error. In other words, the above links to the .rdf files return "Not Found" errors now. So, here is an example HTTP session of me trying to connect working-dogs.com and GET a directory that doesn't have a trailing slash. As you can see, the web server (apache) creates a 301 Location Moved Permanently response. This means that because of that little missing trailing slash, we have to make a round trip connection to the server. telnet www.working-dogs.com 80 Trying 205.227.191.23... Connected to www.working-dogs.com. Escape character is '^]'. GET /cvsweb HTTP/1.0 HTTP/1.1 301 Moved Permanently Date: Tue, 20 Feb 2001 18:37:53 GMT Server: Apache/1.3.9 (Unix) PHP/3.0.17-dev ApacheJServ/1.1.1b1 AuthMySQL/2.20 mo d_ssl/2.4.0 OpenSSL/0.9.4 Location: http://www.working-dogs.com/cvsweb/ Connection: close Content-Type: text/html !DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN" HTMLHEAD TITLE301 Moved Permanently/TITLE /HEADBODY H1Moved Permanently/H1 The document has moved A HREF="http://www.working-dogs.com/cvsweb/"here/A.P HR ADDRESSApache/1.3.9 Server at www.working-dogs.com Port 80/ADDRESS /BODY/HTML Connection closed by foreign host. -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]
FW: [Fwd: Commercial Support for Jetspeed?]
Someone care to respond to him? Don't respond to just the list, make sure to CC this guy in your response. -jon -- From: "Nicholson, Ronald W." [EMAIL PROTECTED] Date: Monday, February 19, 2001 9:21 AM To: "'[EMAIL PROTECTED]'" [EMAIL PROTECTED] Subject: Commercial Support for Jetspeed? We have a Federal Government client that has expressed interest in Jetspeed. Is commercial support and training available for the Jetspeed portal solution? Thanks, Ron Nicholson, eBusiness Architect Unisys U.S. Federal Government Group 2894 State Hwy N. Albany, MO 64402 Phone: 660-726-3749 Cell: 816-262-0314 -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Next Release
on 2/16/01 12:42 AM, "Anthony W. Marino" [EMAIL PROTECTED] wrote: It appeared to me that for a period of time JetSpeed development had reached a quiet period with not much happening, however, there now seems to be a resurgence. Is there anything that has changed within the project administrative structure that has led to this appearance or is it just me? Thank You, Anthony Subscribe to the [EMAIL PROTECTED] list and watch the commits go by. Jetspeed has nearly daily CVS activity. -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]
[ADMIN] READ NOW!
Hey all, Please only copy the relevant portions of email messages (ie: to keep the context of the discussion) and delete the rest. I see some of you replying to a message and then only putting a couple lines into the middle of a message and sending it. By doing that, it makes it very hard for others to read the digest versions of the emails as well as the fact that it simply fills my server hard disk with unneeded stuff. If you have questions about this, please email me privately as more discussion about this on the list will just add even more junk to the digests. :-) thanks, -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [Admin] Documentation generation change
on 2/17/01 2:12 PM, "David Sean Taylor" [EMAIL PROTECTED] wrote: it looks nice - imo, nicer than stylebook 'build docs' worked without a problem i fixed 3 bad links on index.xml and there are a few more minor things i need to sort out, but overall looks great! -- david FYI, please put a trailing "/" after URI's that end with a directory. For instance, you have http://jakarta.apache.org/velocity when it should be: http://jakarta.apache.org/velocity/. that little "/" prevents another round trip HTTP connection. -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: Next Release
on 2/15/01 8:08 AM, "Robert Fournerat" [EMAIL PROTECTED] wrote: Humm... Sarah asks a good question. Jon's reply is true, but it doesn't tell you anything. Jon must work for Microsoft. ;) Robert I see the ;) but making claims that I work for the evil empire is not funny. :-) In case you missed it, I work for CollabNet which is about as far from M$ as you can possibly get right now. :-) -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: Next Release
on 2/14/01 5:55 AM, "Sarah Arnott" [EMAIL PROTECTED] wrote: Hi! Can anyone tell me the proposed date of the next release of a stable version of Jetspeed? Thanks, Sarah When it is ready. -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: turbine keywords
on 2/12/01 4:59 AM, "Thomas F. Boehme" [EMAIL PROTECTED] wrote: Santiago, I guess the better solution would be to have URL mangling. That is, each URL passed in a response should be an abbreviated one (albeit still unique) which matches up with a URL stored in some session-related cache. Ideally, a mechanism to do so should be in Turbine. Jon, how about that? Cheers, Thomas Yes, using mod_rewrite you can do this no problem. -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: [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]
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: updated to TDKa11
on 2/6/01 1:46 AM, "ingo schuster" [EMAIL PROTECTED] wrote: - I'm not sure if we will use the ScheduledJobService, commented it out in TR.P for the time being - I don't know, hat the difference between log4j and log4j-core is - the core seems to be sufficient at the moment. Jon can you tell us more? ingo. There are two .jar files that come with log4j. I believe that extra functionality, such as syslogd support, is included in the second .jar file. I just included it because it seemed like the right thing to do. I'm not sure which one is actually needed for your application. At some point, I might just combine the two together and distribute them that way. -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: Connection Pooling in Turbine - J2EE
on 2/6/01 12:34 AM, "ingo schuster" [EMAIL PROTECTED] wrote: Be it as it may, we (at IBM) are committed to JSPs and we'll therefore take care that JSP will always be a good alternative to Velocity in Jetspeed. I have to admit that I'm still learning about how templating is supposed to be used with turbine and that our JSPs are not 100% code free, but I'm working to gradually improve it. ;-) ingo. How about this hypothesis based on your comments above: If the people at IBM knew more about template tools like Velocity, they wouldn't use JSP. :-) -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: Connection Pooling in Turbine - J2EE
on 2/6/01 3:29 AM, "Mica Davis" [EMAIL PROTECTED] wrote: If used properly, JSP fits the MVC model just fine. Key words here. The problem is that JSP is almost NEVER used properly. Even the examples on all of the javaworld.com articles on JSP don't use it properly. What good is that? Your always going to have some type of code in your presentation level. Whether it is VTL or Java shouldn't matter. VTL is still code...Try to teach a creative designer how to write VTL. You'll have no more luck than trying to teach them Java basics. Actually, that is where you are wrong. There are very fundamental differences between VTL and "code". VTL has a well defined small subset of functionality that prevents it from being used improperly, where with JSP you must actually make more effort to use it improperly. What is the difference between: Your example is fundamentally flawed in that you are not giving an example of a pull based application. What you should really do is provide an example of doing that with a pull based system. You missed all the parts where, in your JSP page, in order to do pull based systems, you have to do things like this: jsp:useBean id="cart" scope="request" class="com.mycompany.MyApp.MyCart"/ Ok, right there, you have screwed up the View portion of the model because you are embedding the scope of the use of the bean within the template...that is not part of the View This is not something that a designer wants to know about or can even know about. Let me also state that the syntax of that blows. What designers are going to actually remember how to type all of that? Personally I would rather use java. VTL is clunky. Right, but you know how to write Java. That is where you just totally missed the boat. Your designers don't know how to write Java and therefore VTL is much easier for them. -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: Connection Pooling in Turbine - J2EE
on 2/6/01 7:48 AM, "Josep Vela" [EMAIL PROTECTED] wrote: IMHO the Turbine added value is to provide a lot of utilities/tools that constitutes a core for easy doing web applications, i.e. the users framework, the scheduler, the DB pooling, etc... not only the Velocity ... May be the same is true for JetSpeed, the standard portlet API will be nice, but all the facilities and applications for content sindication, RSS, RDF, iCalendar, etc.. make up the advantage for developping portals or new generation of web applications. Josep Vela [EMAIL PROTECTED] Yes. You are very correct in that statement. -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: CVS update: jetspeed/lib jdbc-se2.0.jar
on 2/6/01 9:19 AM, "Java Apache CVS Development" [EMAIL PROTECTED] wrote: User: ingo Date: 01/02/06 09:19:51 Added: lib jdbc-se2.0.jar Log: TDKa11 seems to use jdbc... Revision ChangesPath 1.1 jetspeed/lib/jdbc-se2.0.jar Binary file I posted about this earlier on your list...I made Turbine's connection pooling code implement the JDBC standard extensions. -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: Connection Pooling in Turbine - J2EE
on 2/6/01 11:54 AM, "Ethan Adams" [EMAIL PROTECTED] wrote: I am looking to move my web based mail application written using JSP and Beans to a MVC model. I like what I see in Turbine and Velocity. Great! Any performance issues due to parsing the *.vm files? Or, is there some type of caching involved? Tons of caching is enabled (it is disabled by default) and the parser is quite fast. The parser is based on JavaCC...the same parser behind the javac parser. In other words, no major performance issues. Anyone have some good examples for the Turbine/Velocity combo? Scarab is going to be a good example, there is also several examples in the TDK. -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]
FW: XSLPortlet
Maybe one of the IBM people here can help her out? -jon -- From: "Veronique Moses" [EMAIL PROTECTED] Date: Mon, 5 Feb 2001 21:18:14 -0500 To: [EMAIL PROTECTED] Subject: XSLPortlet Question: I'll preface that I'm new to the portlet and JetSpeed technology and I have a question regarding the XSLPortlet in JetSpeed. I have an XML document that I want to use to render to the browser using the XSL Portlet. Thus, in my jetspeed-config.jcfg, I've registered and created porlet entries as follows: When the data is rendered in the browser, only the static data in the XSL is rendered. For example, this is a partial view of the XSL document: In the browser, ONLY "Major League Baseball Statistics AND the "/" are displayed. . Could you please help, I've been surfing through documents for days and can't seem to find anything detailed. xsl:for-each select="SEASON" - H1 xsl:value-of select="@YEAR" / Major League Baseball Statistics /H1 - xsl:for-each select="LEAGUE" - H2 xsl:value-of select="@NAME" / / /H2 portlet-entry type="abstract" name="XSL" classnameorg.apache.jetspeed.portal.portlets.XSLPortlet/classname /portlet-entry portlet-entry type="ref" parent="XSL" name="VLMXML" url/XML/baseball_xsl.xml/url parameter name="stylesheet" value="/XML/baseballstats.xsl"/ meta-info title Veronique's XML portlet /title descriptionThis portlet renders XML data./description /meta-info /portlet-entry Veronique L. Moses WebSphere Solution Content T/L 444-6692 OUTSIDE (919) 254-6692 INTERNET [EMAIL PROTECTED] http://www.software.ibm.com/webservers/ -- "We are what we repeatedly do.EXCELLENCE, then, is not an act, but a habit" - ARISTOTLE -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Connection Pooling in Turbine - J2EE
on 2/5/01 6:02 PM, "David Sean Taylor" [EMAIL PROTECTED] wrote: Jon Stevens wrote: How is that? You are asking me to compare Velocity and JSP, but you aren't really saying why other than it concerns you. If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous My suspicions are that JSP is painful as in difficult to debug. That part about 'pain to new levels' is very concerning for anyone planning on working with JSP on a big project. Isn't that what you intended, for people to ask why it is so painful? Yep. I'm also working on an essay titled: "You make the decision." It will be a stark compare and contrast between Turbine+Velocity and Struts+JSP. I think it will make it plain as day how badly broken the MVC model is with Struts+JSP based sites are compared with Turbine+Velocity. Another quick way to see how bad JSP really is, is to take a look at all of the JSP related articles on Javaworld.com. *Every* single article completely misses the MVC separation point in their examples. There is stuff as bad as not using taglibs to having Java code in the JSP template. Anyway, Thanks for the quick response, now you really have my interest! Great! Id like to start developing with the Pull Service Model. Is the Pull Service still being designed and developed, can I start writing Application Tools with it today? I looked at the classes last week (1/28 build), and there wasn't much there yet. (Dont get me wrong, simplicity is often brilliance) Yep, it is fully implemented and working. How would one go about writing Application Tools? There is an example one in the org.apache.turbine.util.pull package called UIManager which is done by Jason van Zyl. Is it as simple as writing any class and inheriting from an ApplicationTool? Yep. Then the methods are found with introspection... You don't even have to inherit from ApplicationTool. That is simply if you want to work within the Pull Service. *any* object placed into the Context can have its methods found with introspection. Is there some kind of persistent registry of tools? That would be tools implemented in the Pull Service. Looking at the impl of TurbinePullService, there is a Map: private Map toolBox; Are there plans for hierarchies or categories of application tools? That is up to you to implement. You can have a single tool which has methods to retrieve other tools. $app.MyPrimaryTool.MySecondaryTool Look forward to reading your page on the negatives of JSP So do I. I think this is going to be good. thanks, and sorry for all the questions, but this is very interesting to me, and hopefully the other jetspeeders, Ive seen the database stuff linking to form input fields, that is cool and worth checking out Oh, that is just the tip of the iceberg. John Mcnally is working on making it possible to take a *single* form input tag and move it to another page without having to modify a *single* line of Java code and also having it perform complete form validation using regular expressions. -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: Connection Pooling in Turbine - J2EE
on 2/5/01 9:48 PM, "Johnny Cass" [EMAIL PROTECTED] wrote: I've read a lot of opinions like this one all over the net (that JSP sucks). Though my intuition tells me that using Velocity *must* somehow be better than using JSP, I haven't actually been able to determine *why* this is the case. I have only been using JSP for about two weeks (so I may just be naive) but have so far enjoyed it's: - Ease of use (but not debugging) Right, it is so easy to just put a few lines of Java code in your page, isn't it? Right there you just broke the MVC separation that everyone is so into. - The thorough specification and documentation Yes, that part is good. However, when you have a large corporation backing the development with millions of $, you would expect such a thing. - Level of integration (with tools like NetBeans IDE) Yes, that part is good. However, when you have a large corporation backing the development with millions of $, you would expect such a thing. Again, I'm working on my essay...it should be ready in a few days. -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: CVSupdate: jetspeed/proposals/portletAPI/javadoc/api/org/apache/jetspeed/portlet AccessDeniedException.html Capability.html Client.html DynamicData.html package-frame.html package-summary.html package-tree.html Portlet.html Portlet.Mode.html PortletAction.html PortletConfig.html PortletContext.html PortletData.html PortletException.html PortletLog.html PortletMessage.html PortletPage.html PortletRequest.html PortletResponse.html PortletSession.html PortletTitle.html PortletURI.html PortletWindow.html UnavailableException.html User.html UserProfile.html
Ingo, Why are you checking in generated Javadoc? That is just plain silly. -1. Remove that and make it possible for people to generate that themselves easily using Ant build scripts. -jon on 2/2/01 1:51 AM, "Java Apache CVS Development" [EMAIL PROTECTED] wrote: User: ingo Date: 01/02/02 01:51:40 Added: proposals/portletAPI/javadoc/api/org/apache/jetspeed/portlet AccessDeniedException.html Capability.html Client.html DynamicData.html package-frame.html package-summary.html package-tree.html Portlet.html Portlet.Mode.html PortletAction.html PortletConfig.html PortletContext.html PortletData.html PortletException.html PortletLog.html PortletMessage.html PortletPage.html PortletRequest.html PortletResponse.html PortletSession.html PortletTitle.html PortletURI.html PortletWindow.html UnavailableException.html User.html UserProfile.html Log: [JavaDoc PortletAPI] new version -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Portlet API 2
on 2/2/01 4:50 AM, "Thomas F. Boehme" [EMAIL PROTECTED] wrote: Folks, a few minutes ago we (ie. Ingo) posted the javadocs for Portlet API 2. It is in /proposals department in CVS. All those interested in a common standard for portlets (hopefully even beyond Jetspeed implementations) are invited to comment on the API. ahhh...I see (ignore my email about why checking in javadoc is bad), why didn't you also check in the code? Window and message handling should be well-known concepts, but action handling may not be that obvioius. The intention here is to enable a portlet to attach its own actions to a url without having to deal with the url itself. As soon as a portlet does more than replaying information it found in other places on the web, you get to a point where the portlets needs links or buttons in its content. For example, to finish personalizing a portlet you a "Save" or "Finish" button, or a to-do-list portlet may have an entry field and an "Add" button at the bottom of the current list to add new to-dos. Implementing these has been very tricky so far, because the next screen may be different from the activity you want to perform. The "Save" button, for example, needs to bring the portlet from PERSONALIZE mode to DEFAULT mode, but before doing so the portlet needs to save the posted data which is obviously not the part of the DEFAULT but of the PERSONALIZE mode. This is where actions come in. The url will be constructed for the destination mode (DEFAULT in this case), but a SaveAction can be implemented and attached to the DEFAULT url (whatever it may look like). When the request comes in from the browser, the action(s) are dealt with first, before the service() method is called, similar to the way actions and screens are called in Turbine (thanks Jon for this paradigm). Now, I shall add that all events (actions, messages, and window) are delivered to the respective portlet(s) before the service() methods are called. Therefore, the portlet has a chance to save the posted data before the markup for the new page is generated. Why aren't you just using Turbine's action processing? I don't see a need to abstract this at all. The log() methods on the context have been morphed into a separate class (PortletLog) which provides simplistic log levels. I think this should now be more than enough for that the portlet may log. Plus it's high-level enough to plug different mechanism underneath. -1. Use Turbine's Logging mechanism. This has been recently completely revamped and is *excellent* now as it is backed by Log4J. thanks, -jon -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: WARNING. You sent a potential virus or unauthorised code
on 2/2/01 12:18 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: The message identifier was [EMAIL PROTECTED] The message recipients were [EMAIL PROTECTED] Hey all, I'm tempted to remove this person from this list for using stupid Virus software that doesn't work. Anyone object? fyi, this list doesn't accept attachments, so sending a virus through here is pretty well impossible unless it is embedded as text/plain. -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Portlet API 2
on 2/2/01 1:16 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: the intent of this Portlet API is not only to be used in JetSpeed, we envision this API to evolve into a standard. +1 I'm an idiot. -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: CVS update:jetspeed/src/java/org/apache/jetspeed/services /urlmanagerJetspeedURLManagerService.java
on 1/31/01 1:21 AM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: The init method is synchronized - is there a particular reason for this ? I looked at some other JetSpeed services, their init method was not synchronized. Best regards, Thomas There is no need to have the init() method synchronized either as the whole initialization of Services is now fully synchronized. -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
FW: CVS update:jetspeed/webapp/WEB-INF/conf TurbineResources.properties
What I suggest that you do is use a stock TR.props file as your basis and then include= your JetspeedResources.props at the bottom. The JR.props file will override the TR.props file settings. thanks, -jon -- From: Java Apache CVS Development [EMAIL PROTECTED] Reply-To: "Java-Apache Development" [EMAIL PROTECTED] Date: Wed, 31 Jan 2001 22:11:59 -0800 (PST) To: [EMAIL PROTECTED] Subject: CVS update: jetspeed/webapp/WEB-INF/conf TurbineResources.properties User: taylor Date: 01/01/31 22:11:58 Modified:webapp/WEB-INF/conf TurbineResources.properties Log: removed one remaining 'mail.server' parameter since the other params are in JetspeedResources.properties Revision ChangesPath 1.17 +1 -13 jetspeed/webapp/WEB-INF/conf/TurbineResources.properties Index: TurbineResources.properties === RCS file: /products/cvs/jetspeed/jetspeed/webapp/WEB-INF/conf/TurbineResources.propert ies,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- TurbineResources.properties 2001/01/31 12:33:25 1.16 +++ TurbineResources.properties 2001/02/01 06:11:58 1.17 @@ -1,5 +1,5 @@ # --- -# $Id: TurbineResources.properties,v 1.16 2001/01/31 12:33:25 ingo Exp $ +# $Id: TurbineResources.properties,v 1.17 2001/02/01 06:11:58 taylor Exp $ # # This is the configuration file for Turbine. # --- @@ -28,18 +28,6 @@ # turbine.logs=security # turbine.log.security=/turbine/logs/turbine-security.log # turbine.log.database=/turbine/logs/turbine-database.log - -# --- -# -# M A I L S E R V E R -# -# --- -# Your mail server for outgoing email. -# -# Default: null -# --- - -mail.server=localhost # --- # -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
FW: CVS update:jetspeed/src/java/org/apache/jetspeed/util FileCopy.java
What is "Together"? Where is the license on this file? -jon -- From: Java Apache CVS Development [EMAIL PROTECTED] Reply-To: "Java-Apache Development" [EMAIL PROTECTED] Date: Wed, 31 Jan 2001 23:31:02 -0800 (PST) To: [EMAIL PROTECTED] Subject: CVS update: jetspeed/src/java/org/apache/jetspeed/util FileCopy.java User: taylor Date: 01/01/31 23:31:01 Added: src/java/org/apache/jetspeed/util FileCopy.java Log: new utility to copy files Revision ChangesPath 1.1 jetspeed/src/java/org/apache/jetspeed/util/FileCopy.java Index: FileCopy.java === /* Generated by Together */ package org.apache.jetspeed.util; import java.io.*; import java.net.URL; public class FileCopy { public static final int BUFFER_SIZE = 4096; public static final void copy(String source, String destination) throws IOException { byte[] buffer = new byte[BUFFER_SIZE]; BufferedInputStream input; BufferedOutputStream output; input = new BufferedInputStream(new FileInputStream(source)); output = new BufferedOutputStream(new FileOutputStream(destination)); copyStream(input, output, buffer); input.close(); output.close(); } public static final void copyFromURL(String source, String destination) throws IOException { byte[] buffer = new byte[BUFFER_SIZE]; URL url = new URL(source); BufferedInputStream input; BufferedOutputStream output; input = new BufferedInputStream(new DataInputStream(url.openStream())); output = new BufferedOutputStream(new FileOutputStream(destination)); copyStream(input, output, buffer); input.close(); output.close(); } public static final void copyStream(InputStream input, OutputStream output, byte[] buffer) throws IOException { int bytesRead; while((bytesRead = input.read(buffer)) != -1) output.write(buffer, 0, bytesRead); } } -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: CVSupdate: jetspeed/src/java/org/apache/jetspeed/services/urlmanagerJetspeedURLManager Service.java
on 2/1/01 1:33 AM, "Raphal Luta" [EMAIL PROTECTED] wrote: Now why did you move the PROPERTIES_PATH_KEY into TurbineServices rather than TurbineResourceService ? The latter is the only class which actually uses this constant and it's definitely resources implementation related. (there's also TurbineConfig but in a backward compatible constructor which assumes a specific kind of resources implementation, so it doesn't count) Send me a patch. :-) -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: CVS update:jetspeed/src/java/org/apache/jetspeed/util FileCopy.java
on 2/1/01 9:53 AM, "David Sean Taylor" [EMAIL PROTECTED] wrote: Its already fixed. Keep reading further down your CVS update mailing list -- I caught that one later too... I will be doing some more work on this utility soon, I want to move the mkdirs() stuff in the Profiler up into the utility. Hope its not redundant, I searched thru Turbine but didnt find anything. Right, but it is general purpose, therefore, it should have been put into Turbine so that a wider audience can take advantage of the code. Please try to keep that in mind when checking in code into Jetspeed. I do the same with Scarab development. :-) One more thing, this code may actually be a duplication of what is in Ant. However, I'm not quite sure how well abstracted Ant's file copy code is. btw - I have access to commit to Jetspeed, does that also give me rights to commit to Turbine? Nope. But you can ask for commit access on the Turbine list and let people vote on it. http://www.togethersoft.com/, my new-favorite Java/UML-IDE of the month. It even has a debugger, it has potential although a little frustrating on this release Please confirm that code generated by Together is not under any sort of restrictive license. I'm sure it isn't, just confirm it please. :-) thanks, -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re:CVSupdate: jetspeed/src/java/org/apache/jetspeed/services/urlmanager JetspeedURLManagerService.java
on 1/31/01 12:53 AM, "Raphal Luta" [EMAIL PROTECTED] wrote: Yeah, that is just a paranoid check of mine because when the service was written there was weird behavior with the service initialization order and Rfal was working on the subject so I didn't want to investigate. When we'll upgrade the Turbine dependency, I'll check again all the initialization code based on your modifications. Is the Turbine build stable enough right now to upgrade or should we still wait a few days for the Logging and services change to settle ? Yea, wait a day or two...there are a couple changes that might go on still... Sam jetspeed build is broken... Yep...I was actually doing cleanup related to removing dependencies on Turbine.java ... :-) In other words...making you guys happy. -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [ApacheCon] Jetspeed session??
If none of the proposals are accepted, I'm pretty sure that there will be the ability to have a BOF session on Jetspeed. It won't necessarily be official, but there is no reason why we can't just pick a date/time where people can gather to watch others speak about Jetspeed. -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: JetspeedPersistenceService.java
on 1/30/01 7:12 AM, "Santiago Gala" [EMAIL PROTECTED] wrote: I imagine that we will converge eventually towards Avalon. I expect this to happen, so that we can merge freely turbine services, cocoon services, etc. I have read that you are considering this for turbine once it is released, and I think this is a move in the right direction for everybody, as we will have better use of our developer base if services are maintained for several projects together. Nope. We aren't moving to Avalon at this point in time. There isn't a need or a close fit yet (that I can see) and converting Turbine to use Avalon would require more API changes to Turbine than I am willing to submit people to at this point. Again, I just don't see where the two fit together. I can see Avalon being used as the basis for Tomcat, but I don't see how it would be used as the basis for Turbine...even the services architecture. My suggestion to you is to use Turbine Services for singleton objects primarily because you already depend on Turbine and it offers this for you in a very clean fashion. Adding another dependency (ie: on Avalon) in order to get any duplicated functionality is a bad thing. That said, I'm -1 on using Avalon for providing services in Jetspeed. It just isn't the right fit IMHO. -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [long] Layout system, part 2: functional description
Ok, I just finally read this proposal and I think it is excellent. Great job Raphael. You have shown an excellent ability to pick up the Pull concepts and bring them into Jetspeed. I don't think I have any more comments to make. +1 -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [long] Layout system, part 2: functional description
on 1/30/01 4:30 AM, "Raphal Luta" [EMAIL PROTECTED] wrote: That's because you don't use a proper template engine ;P The syntax of Velocity/Webmacro is very simple on purpose to prevent designers from using complex constructs and embedding logic into their pages. They mainly let the designer access "business" objects which encapsulate/mask all the business logic. The "pull" methodology adds the advantage over the push methodology that the "business logic" programmer does not need to know in which page the objects will be used (this may change each time a site is redesigned even if then logic is unchanged). As such, it provides a better separation of contexts between the page designer work and the business logic programmer. Perfectly stated. I can now confirm that Raphael "gets it". :-) -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: WebPagePortlet
on 1/30/01 2:19 PM, "Santiago Gala" [EMAIL PROTECTED] wrote: A better methodology for this is to simply remove the tags that you don't know about and keep the ones that you want...this can be done with a regular expression. I suggest that you do it this way. :-) One interesting approach could be to remove everything except for "inline" (em, strong, ...) markup, line breaks, paragraphs and lists, something like what Slashdot does in their editor. It is fairly safe, I think. UhhThat's what I just said...:-) I also think that this code should be utility code and moved up into Turbine. Such code would be useful for allowing some markup in the JetspeedContent weblog. I doubt, nevertheless, that this code could make sense of most editor-made pages out there, filled with tables inside tables with font inside fonts tags :) The issue is larger than that. Someone with a syndication service could put HTML into your portlet that would then be displayed to all users. This is known as the Cross Site Scripting Bug...please see the relevant CERT advisories regarding this. -jon -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: CVSupdate: jetspeed/src/java/org/apache/jetspeed/services/urlmanager JetspeedURLManagerService.java
on 1/30/01 4:35 PM, "Java Apache CVS Development" [EMAIL PROTECTED] wrote: public synchronized void init( ServletConfig config ) { +//We have already been initialized... +if( getInit() ) return; + If you are using Turbine's Services, then this won't be needed as this method will only be called if getInit() returns false. -jon -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Service initialization (WAS: Couldn'tprocessURL: /ocs/local.ocs)
on 1/29/01 2:07 AM, "Santiago Gala" [EMAIL PROTECTED] wrote: But what if the service is half way early initialization? That is the problem we get. I will check your new code, to ensure there are no problems with this. Our problem comes from the fact that early initialization of some services is fairly slow, so race conditions are easy to happen. The start of the initialization services should be done in a synchronized block to prevent race conditions. Look at Turbine.java's code. :-) Also, when you reply to messages, please just include the relevant portions and not the entire email... thanks, -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: WebPagePortlet
on 1/29/01 11:19 AM, "Ingo Rammer" [EMAIL PROTECTED] wrote: * Rewriting of A HREFs, IMG SRCs, FORMs (self-referencing forms as well) * Removal of HEAD, SCRIPT, META, STYLE * Removal of OBJECT, EMBED, APPLET Not sure what this is for, but if it is for security, you shouldn't specify what to *remove* but what to *keep*. -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: JetspeedPersistenceService.java
on 1/29/01 11:40 AM, "David Sean Taylor" [EMAIL PROTECTED] wrote: Wow, the wrath of Jon, bummer... Not wrath. I put a friggen :-) at the end of the email. Sigh. :-( Let me *try* to defend myself: In creating JetspeedPersistenceService.java, I copied PersistenceServiceImpl.java. The code is basically the same, but the JetspeedPersistenceService uses a newer profiler. I didn't want to modify PersistenceServiceImpl.java, since others may still want to use the old profiler. Thus I created a new service impl. Not a problem. I will change the variable names. Great! I have also brought up the fact on this mailing list that invocations of the Persistence Service required multiple 'new' persistence services per request. So this means that since the lifetime of the service object is only for one request, its then safe to 'cache' the RunData, since the service object will be gone after the request. Ok. I was just checking. This is counter to how I believe services should work, again I've discussed this on the list. Then maybe implement it differently? In defense of the authors, I believe that the PersistenceService was written as a 'temporary solution', since the underlying classes used by it i.e. the PortletSet and PSMLManager are due for some major overhauls. In that spirit, I left the service as is since it works for now. Im all for rewriting the Persistence Service to be a Turbine Service. But when I suggested that, it was argued that we are considering our own service model for the 'Portal API' that isn't dependent on anything else. The committers to this service will be able to describe this more, but they are in Europe so it probably won't be til tomorrow. Ok, I'm *strongly* -1 on any more Services frameworks being built. Please look at the BaseService class in Turbine. It is a very clean framework for building Services. One could easily build a PortletService on top of BaseServiceinstead of having it built on top of TurbineServices. If you look at the BaseService, it does nothing more than import java.util. There is zero dependencies on any of the rest of the system. Damn, now I suppose that everytime you see my name, you will think "iFoo", or even worse, the "iFoo Propagator". Where's there a corner I can hide in Oh, don't say immature things when someone simply asks why things are being done the way that things are being done. This project has a long history of not doing things properly...work to fix it, not to make it worse. thanks, -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: WebPagePortlet
on 1/29/01 3:26 PM, "Ingo Rammer" [EMAIL PROTECTED] wrote: On one hand it's just for keeping the layout consistent (which means, there shouldn't be another STYLE-Tag in). On the other hand, a META http-equiv="REDIRECT... -Tag wouldn't be nice in a portal anyway ... Every "scrubbing"-feature can be turned of for any page you want to include in the portal. (The only thing that can't be switched is the automatic opening/closing of missing tags ... so that a included "/table" without corresponding "table" wouldn't mess up with your layout. A better methodology for this is to simply remove the tags that you don't know about and keep the ones that you want...this can be done with a regular expression. I suggest that you do it this way. :-) -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
FW: CONFIGURATION CHANGE
fyi... -jon -- From: Jon Stevens [EMAIL PROTECTED] Reply-To: "Turbine" [EMAIL PROTECTED] Date: Sun, 28 Jan 2001 12:03:50 -0800 To: Turbine [EMAIL PROTECTED] Subject: CONFIGURATION CHANGE Make sure to add this line to your TR.props file... services.TurbineAssemblerBrokerService.scheduledjob= org.apache.turbine.util.assemblerbroker.java.JavaScheduledJobFactory -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Service initialization (WAS: Couldn't processURL: /ocs/local.ocs)
Ok, Just so you know, I just got through with a few fairly major changes to the way that Services works and it is much cleaner now. I also tested a lot of the functionality so I know that things are working pretty well. on 1/28/01 1:13 PM, "Raphal Luta" [EMAIL PROTECTED] wrote: I agree that Turbine Services should probably make sure the late init is called on an object when early init is complete If you don't call setInit(true) in early init, then late init() will be executed. I just tested this a few minutes ago and it works. I still agree with you that TurbineServices should ensure that late init is always called when early init is complete to avoid race conditions and highlight the kind of bugs we have It is definitely called if getInit() returns false. In fact, here is the code... service = getServiceInstance(name); if(!service.getInit()) { notice("Initializing service (late): " + name); service.init(); } -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [CVS cleanup] ?
on 1/28/01 1:20 PM, "Raphal Luta" [EMAIL PROTECTED] wrote: In the current Turbine "push" model, i'd say that: View = template Controller = screen (active processing) [ + action (reactive processing) ] No. You shouldn't have Screen's anymore other than for things like determining security. All major active processing should be done through Toolbox objects. -jon -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Anyone using Jetspeed on Tomcat 4.0 (Catalina)?
on 1/25/01 12:53 AM, "Raphal Luta" [EMAIL PROTECTED] wrote: The Turbine.jar is the same (the current Turbine.jat in Jetspeed is copied from TDK a10). Maybe Jason can tell you if he had to modify some things to make Turbine work on Catalina. All of my development for Scarab is currently being done with a very recent turbine.jar and Catalina (a fairly recent snapshot after b1...as b1 has some bugs). I know it works. Given that Catalina is beta software now, I would recommend that if you are going to use turbine with it, then you be prepared to use newer snapshots of the server.jar (catalina) and the turbine.jar... -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [PATCH] Demonstration hack to get around registratione-mail not being sent
on 1/23/01 10:07 AM, "Michael D Harris" [EMAIL PROTECTED] wrote: +// --- +// @pvc start changes : hack the confirmation number into the entryfield for demo purposes +// --- + +// @pvc : new code +org.apache.jetspeed.util.RecordExtractor recEx = new org.apache.jetspeed.util.RecordExtractor (data); +String secretkey = recEx.getConfirmValue ( username ) ; + +// @pvc : here's previous code which was replaced +//table.addElement ( new TR() +// .addElement ( new TD().addElement (Localization.getString("CONFIRMREGISTRATION_SECRETKEYTITLE")) +// .addElement ( new TD().addElement ( new Input(Input.TEXT, "secretkey", data.getParameters().getString("secretkey", ""))) +// .setAlign(AlignType.right; Note...CVS does a perfectly good job of producing diff's between versions. There is no reason to send patches with commented code in them. thanks, -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: CVSupdate: jetspeed/src/java/org/apache/jetspeed/services/jsp/tagsDynamicURITag.java
shouldn't this stuff be going into Turbine? -jon on 1/18/01 1:10 AM, "Java Apache CVS Development" [EMAIL PROTECTED] wrote: User: ingo Date: 01/01/18 01:10:34 Added: src/java/org/apache/jetspeed/services/jsp/tags DynamicURITag.java Log: allow to generate "proper" links in JSP screens with new dynamicUriTag. Revision ChangesPath 1.1 jetspeed/src/java/org/apache/jetspeed/services/jsp/tags/DynamicURITag.java Index: DynamicURITag.java === package org.apache.jetspeed.services.jsp.tags; /* * Copyright (c) 1997-1999 The Java Apache Project. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. All advertising materials mentioning features or use of this *software must display the following acknowledgment: *"This product includes software developed by the Java Apache *Project for use in the Apache JServ servlet engine project *http://java.apache.org/." * * 4. The names "Apache JServ", "Apache JServ Servlet Engine", "Turbine", *"Apache Turbine", "Turbine Project", "Apache Turbine Project" and *"Java Apache Project" must not be used to endorse or promote products *derived from this software without prior written permission. * * 5. Products derived from this software may not be called "Apache JServ" *nor may "Apache" nor "Apache JServ" appear in their names without *prior written permission of the Java Apache Project. * * 6. Redistributions of any form whatsoever must retain the following *acknowledgment: *"This product includes software developed by the Java Apache *Project for use in the Apache JServ servlet engine project *http://java.apache.org/." * * THIS SOFTWARE IS PROVIDED BY THE JAVA APACHE PROJECT "AS IS" AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE JAVA APACHE PROJECT OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED * OF THE POSSIBILITY OF SUCH DAMAGE. * * This software consists of voluntary contributions made by many * individuals on behalf of the Java Apache Group. For more information * on the Java Apache Project and the Apache JServ Servlet Engine project, * please see http://java.apache.org/. * */ import javax.servlet.jsp.*; import javax.servlet.jsp.tagext.*; // Turbine Classes import org.apache.jetspeed.util.Util; import org.apache.turbine.util.*; import org.apache.turbine.services.jsp.JspService; /** * Supporting class for the DynamicURI tag. * Basically routes the call to dynamicUri * * FIXME: make "screen" an optional parameter and add "action" as an optional parameter. * * @author a href="mailto:[EMAIL PROTECTED]"Raphal Luta/a * @version $Id: DynamicURITag.java,v 1.1 2001/01/18 09:10:33 ingo Exp $ */ public class DynamicURITag extends TagSupport { /** * type parameter defines the screen that is requested */ private String screen; /** * The setter for screen parameter */ public void setscreen(String screen) { this.screen = screen; } public int doStartTag() throws JspException { RunData data = (RunData)pageContext.getAttribute(JspService.RUNDATA, PageContext.REQUEST_SCOPE); DynamicURI uri = new DynamicURI( data, screen); try { if (uri != null) { pageContext.getOut().print(uri.toString()); } } catch (Exception e) { String message = "Error processing dynamicUri-tag, parameter: screen="+ screen; Log.error(message, e); try { data.getOut().print( message ); } catch(java.io.IOException ioe) {} } return EVAL_BODY_INCLUDE; } } -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Jetspeed Daily Build Results - Mon, 15 Jan 2001 04:52:52 GMT
on 1/17/01 12:00 AM, "Jon S.Stevens" [EMAIL PROTECTED] wrote: Buildfile: build\build.xml Property ${ant.home} has not been set Come on guys...why aren't you even fixing the simple problems? -jon -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Jetspeed Daily Build Results - Mon, 15 Jan 2001 04:52:52 GMT
on 1/17/01 3:07 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: This error most likely happens because Sam is not using our build scripts (they correctly set the variables). Yes. He is. -jon -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Jetspeed Daily Build Results - Mon, 15 Jan 2001 04:52:52 GMT
on 1/17/01 7:53 PM, "Sam Ruby" [EMAIL PROTECTED] wrote: No. He is not. I am using jetspeed's build.xml, but not using jetspeed's build.bat or build.sh. It is the build.{bat,sh}'s responsibility to set this variable. My bad. Ah. Ok. My bad. I miscorrectly interpreted "build scripts" as being simply the build.xml. Duh. I'm an idiot. -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: JSP screens instead of ECS screens
on 1/16/01 9:29 AM, "Santiago Gala" [EMAIL PROTECTED] wrote: I got exactly the same error. When I try to remove and commit, I get nothing known about `webapp/WEB-INF/templates/jsp/screens/Error.jsp'cvs [commit aborted]: correct above errors first! So, I think that finally, the problem is in the server. Yep. It looks like the file is corrupt on the server... cat Error.jsp,v head ; access ; symbols ; locks; strict; comment @# @; desc @@ I have rm'd the file on the server and you guys are going to have to either do a clean checkout or edit your CVS/Entries file in that directory. thanks, -jon -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: cannot download cvs - file locked
on 1/16/01 1:28 PM, "sbelt" [EMAIL PROTECTED] wrote: I am trying to download the latest cvs. The download hangs saying, "waiting for jon's lock in /products/cvs/jetspeed/jetspeed/webapps/WEB-INF/templates/jsp/screens". It has remained this way for at least 1-hour. Should I wait until tomorow to try again? Steve B. try now. -jon -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: cannot download cvs - file locked
on 1/16/01 4:42 PM, "sbelt" [EMAIL PROTECTED] wrote: Sorry, but still no luck. It stops in the same place with the same message. I have tried on both my Linux and Win2K machines, so I am guessing the problem is at the server. Steve B. ok, please try a *clean* fresh checkout and not a cvs. i just rm'd screens/Attic/error.jsp,v hopefully that will fix any more issues. -jon -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: CVS update:jetspeed/webapp/WEB-INF/templates/jsp/screens error.jsp
on 1/15/01 1:32 AM, "ingo schuster" [EMAIL PROTECTED] wrote: At 18:51 01/13/01, Santiago Gala wrote: Jon Stevens escribi: This is a perfect example of why JSP sucks. +1024 on that one. True, it was a quick hack, just copied the code out of Error.java. But you'll admit that generating the error screen ecs based isn't better. How many times do I need to repeat that using ECS as a screen generation tool has been deprecated? So, yes, I admit using ECS isn't better, but if you are going to come up with another solution, you should do it right. Usually I would process everything in the calling code, place a JavaBean in the request and only read this bean in the JSP. However using a JavaBean is no option for the _error_ page, as when the error occurs, it might be already too late to execute a respective action... Yep. I tried to clean it up a bit but I dont like those many open code close code tags either. Neither do I. Again, this is why JSP sucks and tools like Velocity are better suited to doing sites than JSP. BTW, I wanted to rename error.jsp to Error.jsp to make sure that there won't be trouble with unix file systems, but deleting a file and adding it with uppercase letters didn't work in CVS. So I renamed the file to ErrorGeneral.jsp meaning that it'll display all errors that don't have their specific error screen. Hmmm...that should work. Even if JSPs won't stay the standard tempalting system, we should continue to support it - it's still some sort of an industry standard... Lots of things are industry standards, however, that doesn't mean that you should support it. This is a big beef of mine personally. M$'s ASP is an "industry standard" yet you don't use that! Why should you use JSP then? :-) Yes, it's currently HTML specific. But so is the Login page, Edit Account and basically all other screens except the Home screen. If we are honest, Jetspeed (and turbine) are both still biased towards HTML. But a mechanism like the one used for the layout JSP would easily allow to have error pages specific to the output format. Yes, I don't mind being biased towards HTML. I'm still wary of people who think that they are going to surf the web entirely from their kitchen toaster or their cell phone. :-) None of those ideas have really caught on because not enough people are really interested in doing so. Imagine trying to get your mother to check on the status of her toast via a computer. :-) thanks, -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: JSP screens instead of ECS screens
on 1/15/01 9:04 AM, "ingo schuster" [EMAIL PROTECTED] wrote: In my opinion, a screen shouldn't execute "real" code, i.e. no processing on the model, no calculating of results. They should be pure views. (That rather a description of what I'd like to have that how it's done at the moment :-( ) However, Login.java, ConfirmRegistration.java, NewAccount.java are already not used any more. ingo. Yes. Totally +1. You should be able to do an application without having more than a single Default.java screen (at most). In fact, I'm finding that I don't even need to have one of those. I think Screen modules will eventually be deprecated into being implemented strictly within the core part of Turbine and applications on top of Turbine will not need to extend any of the Screen modules. Again, please read: http://java.apache.org/turbine/pullmodel.html While I do strongly prefer using Velocity for this, JSP is a slightly acceptable model here as well. :-) thanks, -jon -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: JSP screens instead of ECS screens
on 1/15/01 9:44 AM, "David Sean Taylor" [EMAIL PROTECTED] wrote: I had the exact same problem. I couldn't get it working either. If I remember, Jon did something on the server to fix it Nope. Didn't change a thing. -jon -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: The TINDERBOX and CJAN.
on 1/15/01 2:04 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: Agreed, especially since Jon sends to the mailing list the output of the build scripts, we don't even have to go to the website... ;) Note that this doesn't show failures if any other projects depend on Jetspeed. So, going to the site to check the status is still recommended and the reason why I include the link in each and every email. My main concern with the update is that I believe that Kevin manually modified some auto-generated java files... :( Oh my. -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: The TINDERBOX and CJAN.
on 1/14/01 3:46 PM, "Kevin A. Burton" [EMAIL PROTECTED] wrote: They are called dependencies. There is NO way we can have a global build system without using CVS tags for supported versions. If Jetspeed it forced to work out of the Turbine HEAD all the time then this is not going to work. Things will be failing left and right. Kevin Jetspeed makes a release which should be able to depend on a specific version of Turbine. Right now, we all agreed to make that based on TDK releases by tagging Turbine with the TDK. However, the CVS HEAD version of Jetspeed should always be working against the CVS HEAD of Turbine. Period. Either way, you are going to have to make the changes to be compatible with Turbine (or whatever other dependency you have) on the next release. -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: CVSupdate: jetspeed/src/java/org/apache/jetspeed/modules/actions SendConfirmationEmail.java
on 1/14/01 9:40 PM, "Java Apache CVS Development" [EMAIL PROTECTED] wrote: + Properties props = System.getProperties(); + String mailServerMachine = TurbineResources.getString( "mail.server" ); + props.put ( "mail.host", mailServerMachine ); + props.put("mail.smtp.host", mailServerMachine); Why is it that I see Jetspeed commits that are stating to remove tabs and then I see someone doing commits with tabs in them? Please decide on a standard and STICK TO IT! -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: CVSupdate: jetspeed/src/java/org/apache/jetspeed/modules/actions SendConfirmationEmail.java
on 1/14/01 10:16 PM, "David Sean Taylor" [EMAIL PROTECTED] wrote: Its even worse, that person is the same, me. Please don't blame the Jetspeed team, we do have a standard. I'm trying a new editor, and thought I had tabs off, but it appears that they weren't. That last commit was left over from before I switched the option. dont mess with the tab police lol! :-) oh well...just remember that ppl watch your commits... -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
The TINDERBOX and CJAN.
on 1/13/01 9:43 AM, "Santiago Gala" [EMAIL PROTECTED] wrote: I think you are using last turbine and also a mismatched castor version. Build succeeds with turbine.jar and castor.jar in jetspeed/lib. I have tested a build clean and then build. There are plenty of deprecation warnings (we are late WRT versions of xerces, xalan, castor and turbine), but it should compile. Try to unset classpath before the build, or at least prune it of these two files. Sigh. No, you are totally confused. It isn't *me* doing that. That site is now our automated tinderbox/build system and is using the latest CVS of everything there. The point is to show incompatibility between dependencies and should motivate you to fix things when they break instead of waiting until further down the line when it becomes more difficult to fix things. Deprecation warnings are NOT build failures. What you have is complete build failures. If any of your users or you even take the latest Turbine from CVS then you will get these build errors that you just saw. That is a bad thing since this is also the CVS head of Jetspeed, not a released version that he is compiling against. I have setup a cron/perl script that will email a copy of that site to this list on a daily basis so that you can see where things are going to break in the future when you update the files in the jetspeed/lib directory. If the subject line doesn't change, you can safely just delete the email as that means that the build system hasn't been updated since the script last ran. This is all going to be part of a "service" that eventually we are going to provide to all Jakarta projects on a consistent basis. This will also eventually be part of a CJAN system which will allow you to not have to check *any* .jar files into CVS as you will be able to pull them out of the build system with your Ant build scripts. Much like Perl has the CPAN service. I hope that makes things a bit more clear for you. -jon -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
FW: CVS update:jetspeed/webapp/WEB-INF/templates/jsp/screens error.jsp
This is a perfect example of why JSP sucks. You have embedded HTML code within your Java code... ex: + out.println("trtdb"+key+"/b/tdtd = " + value + "/td/tr"); All programming practices tell us not to do that. -jon -- From: Java Apache CVS Development [EMAIL PROTECTED] Reply-To: "Java-Apache Development" [EMAIL PROTECTED] Date: Fri, 12 Jan 2001 00:06:21 -0800 (PST) To: [EMAIL PROTECTED] Subject: CVS update: jetspeed/webapp/WEB-INF/templates/jsp/screens error.jsp User: ingo Date: 01/01/12 00:06:21 Modified:webapp/WEB-INF/templates/jsp/screens error.jsp Log: add same functionality that turbine's error.java has Revision ChangesPath 1.2 +63 -8 jetspeed/webapp/WEB-INF/templates/jsp/screens/error.jsp Index: error.jsp === RCS file: /products/cvs/jetspeed/jetspeed/webapp/WEB-INF/templates/jsp/screens/error.j sp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- error.jsp2001/01/11 16:03:061.1 +++ error.jsp2001/01/12 08:06:201.2 @@ -1,28 +1,82 @@ %@ taglib uri='/WEB-INF/templates/jsp/tld/template.tld' prefix='jetspeed' % %@ page import = "org.apache.turbine.util.*" % +%@ page import = "java.util.*" % % RunData rundata = (RunData)request.getAttribute("rundata"); % table border=1 cellpadding="5" - tr -td - br - h2There has been an Error/h2 -/td - /tr +% // Error Message % tr td br - h3Details:/h3 + h2There has been an Error!/h2 + Reason: pre % out.println( rundata.stackTraceException.toString() ); % /pre -/td +/td /tr + +% // HTTP Parameters % + % + Enumeration keys; + String key; + String value; + + keys = rundata.getParameters().keys(); + if (keys.hasMoreElements()) { + % +tr + td +br +h3Get/Post Data:/h3 + table border=0 + % + keys = rundata.getParameters().keys(); + while ( keys.hasMoreElements() ) + { + key = (String) keys.nextElement(); + value = rundata.getParameters().getString(key); + out.println("trtdb"+key+"/b/tdtd = " + value + "/td/tr"); + } + % +/table + /td +/tr + % + } + % + +% // Debug Keys % + % + keys = rundata.varDebug.keys(); + if (keys.hasMoreElements()) { + % +tr + td +br +h3Debugging Data:/h3 + table border=0 + % + while ( keys.hasMoreElements() ) + { + key = (String) keys.nextElement(); + value = rundata.varDebug.get(key).toString(); + out.println("trtdb"+key+"/b/tdtd = " + value + "/td/tr"); + } + % +/table + /td +/tr + % + } + % + +% // Stacktrace % tr td br @@ -32,4 +86,5 @@ /pre /td /tr + /table -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
build failure
http://oss.software.ibm.com/developerworks/opensource/jakarta/proto/jetspee d.html -jon -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Tracing/Logging in JetSpeed
on 1/9/2001 9:11 AM, "Victor Ganora" [EMAIL PROTECTED] wrote: For a look at another good Logger implementation see: http://protomatter.sourceforge.net/1.1.2/javadoc/com/protomatter/syslog/pack age-summary.html I'm no suggesting you use it, but you may get some useful ideas from the organization of their API. -Vik No. The correct tool to use is log4j. It will be a Jakarta project in a few days or so (it already is, it just isn't live on the website yet). -jon -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
FW: [Fwd: ]
Forwarding to the right address. Santiago got it typo'd. :-) -jon -- From: Santiago Gala [EMAIL PROTECTED] Organization: High Sierra Technology Reply-To: "JetSpeed" [EMAIL PROTECTED] Date: Thu, 04 Jan 2001 12:55:22 +0100 To: [EMAIL PROTECTED] Cc: JetSpeed [EMAIL PROTECTED] Subject: Re: FW: [Fwd: ] As far as we know, the problem is fixed both in Jetspeed release and in the java.apache.org web site. Nevertheless, you could still experience the problem, as some people can be using the documentation delivered with old versions of Jetspeed. In this cases, the referrer field will not be "java.apache.org", but something else. Please, report the problem to the webmaster of the offending site. Thanks for helping us to improve the quality of Jetspeed. Regards, Santiago Gala Jon Stevens wrote: Please fix. -jon -- From: Rodent of Unusual Size [EMAIL PROTECTED] Organization: The Apache Software Foundation Date: Wed, 03 Jan 2001 15:14:23 -0500 To: Jon Stevens [EMAIL PROTECTED] Subject: [Fwd: ] Not acked.. -- #kenP-)} Ken Coarhttp://Golux.Com/coar/ Apache Software Foundation http://www.apache.org/ "Apache Server for Dummies" http://Apache-Server.Com/ "Apache Server Unleashed" http://ApacheUnleashed.Com/ From: "Nancy Abila" [EMAIL PROTECTED] Date: Thursday, December 7, 2000 6:30 AM To: [EMAIL PROTECTED], [EMAIL PROTECTED] Hi, On your page http://java.apache.org/jetspeed/site/overview.html you are pointing to a page on our site (www.xml.com). The link is "really good article" and it points to http://www.xml.com/print/2000/05/15/jetspeed/index.html. That url is incorrect and goes to an error page. The correct url is: http://www.xml.com/pub/a/2000/05/15/jetspeed/index.html Would you please be so kind as to make the change to the url. Thanks in advance, Nancy ~ Nancy Abila * [EMAIL PROTECTED] Director of Production * O'Reilly Network 707-829-6516 -- -- 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]
FW: [Fwd: ]
Please fix. -jon -- From: Rodent of Unusual Size [EMAIL PROTECTED] Organization: The Apache Software Foundation Date: Wed, 03 Jan 2001 15:14:23 -0500 To: Jon Stevens [EMAIL PROTECTED] Subject: [Fwd: ] Not acked.. -- #kenP-)} Ken Coarhttp://Golux.Com/coar/ Apache Software Foundation http://www.apache.org/ "Apache Server for Dummies" http://Apache-Server.Com/ "Apache Server Unleashed" http://ApacheUnleashed.Com/ From: "Nancy Abila" [EMAIL PROTECTED] Date: Thursday, December 7, 2000 6:30 AM To: [EMAIL PROTECTED], [EMAIL PROTECTED] Hi, On your page http://java.apache.org/jetspeed/site/overview.html you are pointing to a page on our site (www.xml.com). The link is "really good article" and it points to http://www.xml.com/print/2000/05/15/jetspeed/index.html. That url is incorrect and goes to an error page. The correct url is: http://www.xml.com/pub/a/2000/05/15/jetspeed/index.html Would you please be so kind as to make the change to the url. Thanks in advance, Nancy ~ Nancy Abila * [EMAIL PROTECTED] Director of Production * O'Reilly Network 707-829-6516 -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Digital Dashboard
on 12/28/2000 11:00 AM, "Mark Wardell" [EMAIL PROTECTED] wrote: Ok: Just so you everyone knows -- I evaluated Jetspeed first and took it to mgmt and it was rejected. I took them Dashboard They loved it. Jetspeed was rejected because of the open source issue. I thought that was a plus. But anyhow for now I am of to go implement a sight with MS Digital Dashboard. Mark Wardell. Bummer, maybe you aren't doing a good enough job of evangelizing OSS in your company. One of the primary pluses of OSS is the fact that anyone can contribute to making the software better. In fact, that has happened with this project. The primary developer flew the coop and a bunch of people stood up, took over and made the project much much much better. That is the power of OSS. Next month, when M$ decides to kill the Dashboard project, what are you going to do? What happens when you find a bug in it? What happens if you want to add a feature to it that isn't supported? Blah blah blah... p.s. Gratuitous sales pitch: Collab.Net specializes in doing consulting in this area. -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [1.3a1] Branch closed and merged
on 12/22/2000 11:12 AM, "ingo schuster" [EMAIL PROTECTED] wrote: Thank you very much, all of you that helped to make this release happen! I think it's a release that we can be proud of - as there have been many imporant improvements. Now that it has become so much easier for new developers to start working with (and on) jetspeed, hopefully our community will grow faster. Special thanks to Raphael for his effort: You did a great job the last days, thanks! Hope you find some more sleep now... I will take a christmas break as well, mine will last until January 3th, but then I'm back to commit again. Already got some minor points on my todo... ;-) So I wish a merry christmas as well, have a good start into the new millenium! ;-) ingo. Yes. I was afraid this project was on the verge of death and I see Ingo and Raphael and others pick it up from the ashes and make it live again. Very good job. -jon -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [FAQs] call for FAQs
on 12/19/2000 9:18 AM, "David Sean Taylor" [EMAIL PROTECTED] wrote: Also noticed there is a FAQ-O-Matic at java.apache.org on Jetspeed. It has some good info there, along with dated info on installation. Does anyone know how to edit the FAQs there? Problem is with the software, no new accounts can be created because of a goof up. No one has time to fix it either. Mike Haberman is supposed to be working on Jyve 2.0, but nothing yet. :-( -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
uppercase directories
i made them lowercase. ie: directories like this (except WEB-INF of course) jetspeed/webapp/WEB-INF/psml/USER/TURBINE/HTML/default.psml you may have to check out from cvs again or edit your CVS/Entries files by hand. -jon -- Honk if you love peace and quiet. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: [proposal][vote] Pre-christmas alpha release new documentset
on 12/13/2000 1:15 AM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: In summary, let me know : - if you agree that we should release a new alpha release ASAP. - if there are some features that you deem necessary for an alpha release that are not yet there - if you have some ideas on how to improve the base document set included in the webapp. I want to hear more success stories of people actually installing it from CVS and having it working first. Don't be in such a hurry. One of my ideas on the last topic: Create an Apache OCS feed and make it available under the Jetspeed website, configure the default Jetspeed distribution to use this feed, let all the current Apache projects define their own RSS channel registered within the feed, so that Jetspeed can act as global multi-device "What's new" for the ASF. I'm open to any other ideas for illustrating Jetspeed. I suggest that you find another server to host it. The JVM on freebsd is really really bad. thanks, -jon -- Honk if you love peace and quiet. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
FW: bad link
could someone fix this please? thanks, -jon -- From: "Steve McCannell" [EMAIL PROTECTED] Date: Thu, 7 Dec 2000 09:31:17 -0800 To: [EMAIL PROTECTED] Subject: bad link I'm not sure if you're the right person for this, but I couldn't find a contact email on the site. Anyhow, on the page http://java.apache.org/jetspeed/site/overview.html you have a link to an XML.com article that is broken. the link should be http://www.xml.com/pub/a/2000/05/15/jetspeed/index.html Thanks! Steve McCannell XML.com -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: Jestpeed 1.2: status
on 12/6/2000 6:52 AM, "Raphael Luta" [EMAIL PROTECTED] wrote: Yes, but currently there's still some support classes missing for Velocity and most important: the templates are the same so switching for Webmacro to Velocity will just be an issue of changing the default configuration in TR.p. AFAIK, in the latest Turbine, Webmacro is still the default templating system. However, in the TDK, Velocity is. We will 120% support WebMacro, but people will be strongly encouraged to use Velocity instead. -jon -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: Requested Screen not found
on 12/6/2000 2:49 PM, "sbelt" [EMAIL PROTECTED] wrote: Perhaps this was just a typo in your post, but at least on my system, .../screen/Admin requires capital-A. The screen names are case-sensitive - even on an NT based system. Steve B. Of course they are case-sensitive, it is java class names. -jon -- Honk if you love peace and quiet. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: Requested Screen not found
on 12/6/2000 3:17 PM, "Mike Warne" [EMAIL PROTECTED] wrote: Exception: java.lang.NoSuchMethodError: org.w3c.dom.Node: method normalize()V not found at org.apache.xerces.dom.ElementImpl.normalize(ElementImpl.java, Compiled Code) I wonder if the ordering of the jars in CLASSPATH are critical. In this single case, they are. It has to do with xerces including dom. Play with the XML/DOM related .jar files in your classpath. -jon -- Honk if you love peace and quiet. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: CVS update: jetspeed/xdocs Profiler.xml
on 12/2/2000 4:46 PM, "Java Apache CVS Development" [EMAIL PROTECTED] wrote: Added: xdocsProfiler.xml Log: added new profiler xdocs probably a better idea to make the name of the file all lowercase. you also need to update the site-book.xml file as well. -jon -- Honk if you love peace and quiet. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: [profiler] cvs write access
on 11/30/2000 3:33 AM, "Raphael Luta" [EMAIL PROTECTED] wrote: +1 as well. Jon, can you give David write access ? Thanks, done -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: Need informations
on 11/28/2000 7:59 AM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: Regards, Jean-Pierre Drascek. Java and Websphere I/T Specialist Tel : 36 4458 (ext. 04.92.11.44.58) GSM : 06 85 74 85 24 E-mail : [EMAIL PROTECTED] What is all this IBM interest in Jetspeed? (just curious, you guys must really need this functionality) -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: Profiler Proposal
on 11/28/2000 1:00 AM, "Christian Sell" [EMAIL PROTECTED] wrote: Jon, can you tell me how to get site2 (or anything else) from the jakarta cvs? In the online instructions, it mentions to use cvs login, but nowhere is the password given... http://jakarta.apache.org/site/cvsindex.html The password is blank -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: Profiler Proposal
on 11/28/2000 3:44 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: Not quite true. Meanwhile, after digging out some old script I was able to find out that "anoncvs" does the job. However, when accessing jakarta-site2, I now get a "cannot find module" message any help? The password not showing on the page has been resolved. Check back in a day or so on the other issue. It is just a configuration issue and I have contacted the necessary people to resolve it. :-) thanks, fyi, this should be resolved now. -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: WAR status and new Beta release
on 11/27/2000 2:08 PM, "Kevin A. Burton" [EMAIL PROTECTED] wrote: That is not bad. ... "release early, release often"... still something we don't do here under Apache :) That has never been a requirement in the entire ASF. Apache is about releasing solid code, not about releasing early or releasing often. -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: RegistryManager service landed
on 11/27/2000 4:23 PM, "Raphael Luta" [EMAIL PROTECTED] wrote: There's only 1 package to implement as a service before we can remove the JetspeedServlet: the daemon stuff. Congrats! -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: WAR status and new Beta release
on 11/27/2000 4:23 PM, "Gunnar R|nning" [EMAIL PROTECTED] wrote: The theory behind release early, release often is that you at every point during your development lifecycle has something to showoff. By doing this you reduce risk, improve quality, improve progress visibility etc. Isn't most apache projects encouraged to have working CVS versions at all times ? This implies that Apache projects indeed practice release early and often - which in turn leads to higher quality of the code that is _labeled_ as released. Right, but if you look at the httpd project, lets see, version 2.0 has been about 3 years in the making and releases are made only after much careful testing. In fact, before a release is made live, it is tested on the new-httpd list first. That is why some version numbers have been skipped in the past. None of these practices have happened under the Jetspeed project. If you want release often, then download a daily snapshot. Those are labeled with the date that they were built. Again, the ASF is simply about quality releases that you can count on as production quality software. I personally think that more OSS projects should work like that as the people who are going to be contributing to your software are generally the same people who can figure out how to get it from CVS. -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: Profiler Proposal
on 11/27/2000 2:52 PM, "Kevin A. Burton" [EMAIL PROTECTED] wrote: hm.. do you mean stylebook? It would be nice if the ./docs/proposals were human readable with just a text editor... of course it would also be nice if they were on the website someone make a call besides me... The old proposals would have to be upgraded to stylebook. Kevin For documentation for projects that live under the jakarta website (which jetspeed will someday), the new "recommended" methodology has been documented on the jakarta website. http://jakarta.apache.org/site/jakarta-site2.html there is even a sample website deal to get you started and converting from stylebook .xml DTD to Anakia is very easy. stylebook is being deprecated real quick. it has lived much longer than it should have. -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: Profiler Proposal
on 11/25/2000 2:41 AM, "David Sean Taylor" [EMAIL PROTECTED] wrote: Hi All, Below is a proposal for a Jetspeed Profiler Service. It is not final and your input is welcome. David Wow. That is one of the best proposals I have ever seen. :-) Excellent job. -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: WAR status and new Beta release
on 11/25/2000 6:33 AM, "Raphael Luta" [EMAIL PROTECTED] wrote: Jon, I agree on the principle but 1.2b1 is already out. I don't see how we can swith to an "alpha" without jumping to 1.3. Ok. 1.3a1 and simply note on the website that the Jetspeed project is essentially taking a step back to make sure that it is implemented properly before another "real" release. -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: WAR status and new Beta release
on 11/24/2000 7:07 AM, "Raphael Luta" [EMAIL PROTECTED] wrote: I think we should release as soon as possible a new "beta" release of jetspeed 1.2 in order to avoid unnecessary install and operation questions. -1 on a beta. It should be alpha at best. -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: JSP templates
on 11/24/2000 7:30 AM, "ingo schuster" [EMAIL PROTECTED] wrote: We shouldn't need to use this, your right. However, the standard JspLayout assumes that the layout template is already set, but the "services.TurbineTemplateService.default.layout.template" key isn't evaluated. As I'm not sure what this key is meant to be for, I introduced a new one ("services.JspService.default.layout") and this value is used to set the template in JetspeedJspLayout: String templateJsp = TurbineResources.getString( "services.JspService.default.layout","/default.jsp"); data.getTemplateInfo().setLayoutTemplate( templateJsp ); If you don't do this, you get a 404 error, "/layoutsnull not found" - this has been reported on the turbine list several times, however I haven't figured out yet how it's dealt with properly. I want to clean this (as soon as I find more time...) ingo. ingo. the right thing to do here is to spend time tracking down the source of the problem and submit patches to the turbine list. just checking in a fork of the code because you don't necessarily understand the problem, into jetspeed isn't real conducive towards working together imho. FYI: services.TurbineTemplateService.default.layout.template That is clearly defined in the TurbineResources.properties file. thanks, -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: JSP templates
on 11/24/2000 5:50 AM, "ingo schuster" [EMAIL PROTECTED] wrote: I checked in some JSP templates that can be used as an alternative to the ecs Layouts/Navigations. Regard this as an proposal, I know that JSPs are not the preferred apache templating system and Raphael is working on a Velocity based solution, however I think there might be people that will want to use JSPs. Yea, I'm -0 on this decision. I don't have a good enough argument to go to a -1 other than I just think that JSP's suck and that probably isn't good enough around here. :-) -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: Latest turbine
on 11/20/2000 3:54 PM, "Kevin A. Burton" [EMAIL PROTECTED] wrote: - -1 on the names. Please don't use version numbers in your filenames. This breaks scripts that require us to rewrite. If you just use 'velocity.jar' instead of 'velocity-0.7.jar' you have a much cleaner situation. If you want to keep track of the version number simply update README in lib/ to reflect files and version mapping. If you do it this way no one will need to update their classpath :) snip Huh? Ant now handles this for you with the path and classpath tasks, so there is no reason why putting version numbers in .jar files is a bad thing. My issue is that people don't update the README file. -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: Mailing list reorg???
on 11/20/2000 4:11 PM, "Kevin A. Burton" [EMAIL PROTECTED] wrote: Ug. This mailing list is becoming WAY to confusing. We need to break this out into [EMAIL PROTECTED] and [EMAIL PROTECTED] Any objection to doing this NOW??? I am sick of going over issues on the current mailing list which are user issues when I only want to look at devel issues :). First off, it would need to follow the naming conventions of the lists that are currently on the Jakarta site. So, it would be: [EMAIL PROTECTED] [EMAIL PROTECTED] Next, the issue would be the confusion between working-dogs.com and jakarta/java apache which I'm not ready to deal with quite yet. So, I'm +1 on this proposal with the names I mentioned above...AFTER...I get the rest of Jakarta and Java Apache merged together which I'm working hard on right now. Also, Kevin, I think it is pretty bad of you to ignore your users. Of all people, you should be the most interested in what your users are doing and the problems they are facing so that you can improve Jetspeed based on their feedback. thanks, -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: CVS update: jetspeed/libfreemarker-jdk1.2.jar webmacro-jdk1.2.jar
on 11/22/2000 2:36 AM, "Java Apache CVS Development" [EMAIL PROTECTED] wrote: User: ingo Date: 00/11/22 02:36:32 Added: lib freemarker-jdk1.2.jar webmacro-jdk1.2.jar Log: Template services for turbine Revision ChangesPath 1.1 jetspeed/lib/freemarker-jdk1.2.jar Binary file 1.1 jetspeed/lib/webmacro-jdk1.2.jar Binary file Ingo, Why is this being added into Jetspeed? Unless you are actually going to be using these classes, you don't need them. Instead, you should disable their services in your TurbineResources.properties file and the classes will not get used. -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: Turbine security branch...
on 11/22/2000 3:13 AM, "Santiago Gala" [EMAIL PROTECTED] wrote: We were looking into this in the last days. There is job to do: DBBroker is deprecated, but it is simply a matter of changing it by PoolBrokerService everywhere. That has been this way for about 2 months now. Most important, TurbineUser no longer has a getId() method, and a lot of code in out mail checking, etc. is accessing directly the DB. Read the code more carefully. TurbineUser extends BaseObject which has a getId() method. -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: Next Release of Jetspeed
on 11/21/2000 6:58 AM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: I was curious if there is a target date for the next release of Jetspeed?? It will be released when it is ready. If you help, it will be released sooner. -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]