Re: Portlet security
Santiago, I agree that it is possible to implement the PortletAccessControl interface based on JAAS, JAAS provides the Subject.doAs() method that allows to execute code under the identity of a particular user (I know the details of how to do this). There are cases and environments where it is more advantageous to use an authorization mechanism other than JAAS. The PortletAccessControl interface does not mean to reinvent things, it is just to provide an abstraction of what the PortletInvoker needs (decision whether a given user may perform a given action on a given portlet instance) and allows pluggable implementations to meet this need. +-+-+-+ +-+ | Portlet | Portlet | Portlet |...| Portlet | ++ +-+-+-+---+-+ | Portlet Access | | Portlet Invoker |-| Control I/F| +-+---+-+ ++ | Aggregation | Customization | Other Views | | +-+---+-+ v No-op ++ Custom +| Access Control | J2EE/JAAS +||Provider| ||++ |++ ++ The AccessControlProvider implementations can map the simple checkPermission(user, action, portletInstanceID) call to JAAS/J2EE calls or to other authorization mechanisms. In a J2EE/JAAS provider, of course all the J2EE/JAAS functionality can be used as you say. For service projects, it should be possible to write custom AccessControlProviders implementing the PortletAccessInterface which might for example do database querys against the customer's policy databases; that was the main reason to define the PortletAccessControl I/F. Probably, there also should be a no-op implementation of the PortletAccessControl interface that has a checkPermission method that always returns true to avoid imposing the JAAS access control runtime and configuration overhead on portals that only have public content. Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany Santiago Gala wrote: [EMAIL PROTECTED] wrote: I don't think Java 2 would really fit our needs. Currently, Java 2 provides code-source based access controls (access controls based on where the code originated from and who signed the code), but it lacks the ability to additionally enforce access controls based on who runs the code. That is true. You get this with JAAS standard extension. Your previous sentence reminded me of the Pistoia book, who says (page 670): "The Java 2 SDK provides a mean to enforce access controls based on *where code came from* and *who signed it*. The need for such access controls derives from the distributed nature of the Java platform, where , for instance, a remote applet may be downloaded over a public network and then run locally. "The Java 2 SDK, however, still lacks the means to enforce similar access controls based on *who runs the code*. To provide this type of access control, the security architecture of the Java 2 SDK requires additional support for authentication (determining who's actually running the code), and requires extensions to the existing authorization components to enforce new access controls based on who was authenticated. "The Java Authentication and Authorization Service (JAAS)(see http://java.sun.com/security/jaas/) extends the security architecture, providing mechanisms to authenticate subjects, execute code on behalf of subjects, and grant permissions to subjects. The result is that access control policies can be based on both what code is being executed and who is executing that code. (IBM Java 2 Network Security, Prentice Hall) We need to protect portlet instances based on the identity of the user from whom a request to display them or perform other actions on them originates. There may be lots of portlet instances that share the same portlet code and can have different customizations for different users. That is precisely my point. We should use code in java.security. to ensure that the Principal on behalf of which the request is being run has the right permissions to run the code. Or, we may need to use doPrivileged() to ensure that actions can be performed even if the portlet code executes with less privileges than Jetspeed code itself. There is plenty of code there for doing these things, and it would be a pain to reimplement it, specially since I seriously doubt that we can do a better job
Re: Portlet security
I don't think Java 2 would really fit our needs. Currently, Java 2 provides code-source based access controls (access controls based on where the code originated from and who signed the code), but it lacks the ability to additionally enforce access controls based on who runs the code. We need to protect portlet instances based on the identity of the user from whom a request to display them or perform other actions on them originates. There may be lots of portlet instances that share the same portlet code and can have different customizations for different users. I think the right thing to do is to specify an interface in JetSpeed that defines what we need and let the PortletInvoker use this interface. This will allow to plug whatever seems appropriate to a portal implementer - be it JAAS or some code that directly uses a policy database or policy files (see Figure below). +-+-+-+ +-+ | Portlet | Portlet | Portlet |...| Portlet | ++ +-+-+-+---+-+ | Portlet Access | | Portlet Invoker |-| Control I/F| +-+---+-+ ++ | Aggregation | Customization | Other Views | | +-+---+-+ v ++ +| Access Control | ||Provider| +|++ |++ ++ The portlet access control interface in JetSpeed needs to allow the PortletInvoker to find out whether a given Subject (User) may perform a given Action (display, edit, config, ...) on a given Object (Portlet). 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, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany Santiago Gala wrote: -- Jon Stevens wrote: on 2/22/01 4:17 PM, "Santiago Gala" [EMAIL PROTECTED] wrote: All of the java.security.* framework is interface based. So is Turbine's. I really don't see a need to use java.security.* when Turbine has a *MUCH* more complete implementation of a security framework than just java.security. -1 on java.security.* The need to use java.security framework comes from: - being able to reuse security support very well studied and engineered (java.policy, doPrivileged(), checkPermission() ) inside the VM and get fine grained support for cehcking permissions or specifying privileged actions. The java code is already there. It is a matter of using it. Now that java2 is our target, the effort is more than justified. - being able to integrate in J2EE framework servlet containers simply (EJB, JDBC, ...) - being able to integrate in a given corporate environment. java.security.Principal is the standard way to deliver privileges. I think TurbineUser should implement Principal. - surviving in a securityManaged servlet container. As an example of this, the admin portlet in Jetspeed will throw a SecurityException if standard security is on (ReadPropertyPermission on). It the turbine framework is based on these objects, it will get cached in the proper level and treated as a security exception. If not, it will be processed as a standard error. Also, the thread pool will have problems with calls trying to set thread priority or stopping threads. I'm not saying that you drop turbine security. I agree it is cood (nice typo=cool+good :). What I'm saying is that turbine should use the interfaces and methods there, for instance as a way to handle users ( java.security.Principal user.getPrincipal() ) or as a way to check for permissions (doPrivileged() and checkPermission() ). Also that we use the standard exceptions for security based exceptions, so that try-catch is simpler to program and we can survive when a SecurityManager is in effect in the servlet container. Don't you think that ignoring java security will bring problems in the future? -- -- 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
Re: Getting rid of xalan and xerces :-)
Santiago, I think it is better if you just update the EcsStylesheetElement properly, I don't think using SimpleTransform in ECSStylesheet element or somewhere else as a wrapper for the standard XML API is necessary. I think it is ok to call the standard XML API from the EcsStylesheetElement directly. Using the SimpleTransform class does not seem a lot simpler than just using the XML APIs. Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany --- Santiago Gala wrote: [EMAIL PROTECTED] wrote: Santiago, the EcsStyleSheet element works similarly to the EcsServletElement. The purpose of these classes is to allow for deferring exectution of a servlet/JSP or a stylesheet respectively until the ECS tree is traversed, so that the JSP or stylesheet processor can write directly to the output streem when it is time to do so instead of filling temporary buffers. Both the EcsStylesheetElement and the EcsServletElement are needed until we have template based, stream oriented aggregation with JSPs and Velocity. I understand it as: Please, don't do a dirty fix! :) I'll commit a cleaned up version, possibly adding stream support to SimpleTransform.java and calling it from the EcsStyleSheet class. I guess that, even if EcsStyleSheet is transient, stream support for XSLT transformations will continue to be needed in the future. Regards, Santiago -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Getting rid of xalan and xerces :-)
Santiago, the EcsStyleSheet element works similarly to the EcsServletElement. The purpose of these classes is to allow for deferring exectution of a servlet/JSP or a stylesheet respectively until the ECS tree is traversed, so that the JSP or stylesheet processor can write directly to the output streem when it is time to do so instead of filling temporary buffers. Both the EcsStylesheetElement and the EcsServletElement are needed until we have template based, stream oriented aggregation with JSPs and Velocity. Best regards, Thomas Thomas Schaeck PvC Portal Architect Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany - Santiago Gala wrote: What I really mean is that we found a problem while I was visiting Juan Carlos in Ciudad Real (related with how SAX1 implementations handle namespaces) that made it mandatory for us to try to go into SAX2 --- Xalan2. I did some experiments and I found that migrating Jetspeed to use only Xalan2.0.0 implies only changes in two files (SimpleTransform.java and ECSStylesheetElement.java). I have updated them, and everything seems to be OK. I will test a little bit more. I'm asking, in brief, if anybody oposes to switching to Xalan2.0.0. I can take care of commiting after more testing, maybe explaining needed changes in XSLT processing for other teams, ... It brings a lot of advantages if properly done, as Jetspeed (when some extra changes are done) will no longer depend from Xalan. Instead, it will depend on javax.xml.transform.*,org.xml.sax.* (TRAX) and javax.xml.parser.* (JAXP). This is not done yet, but I will do it in the next days if nobody oposes. BTW, there is a comment in EcsStylesheetElement.java saying that this class is transient. Is it needed still ? My adaptation is a quick fix, and I would prefer not to commit it. Another caveat: to make it work, I have to define export TOMCAT_OPTS="-Dorg.xml.sax.driver=org.apache.xerces.parsers.SAXParser" (before it was export TOMCAT_OPTS="-Dorg.xml.sax.parser=org.apache.xerces.parsers.SAXParser" ) I think it changes as gremlins move my versions of xerces.jar around :-) (1.2.3 -- 1.3.0 -- 1.2.3, ...) or from tomcat/lib to WEB-INF/lib (of cocoon and jetspeed and ... or maybe it was xalan.jar? ) You all know what I mean... You're happy if you don't :-) Anybody knows how to get rid of this definition in a sensible, cult and educated way? -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
RE: Portlet security
Craig Berry wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 22, 2001 6:18 AM We also have plans in this direction, I think we should agree on a common interface for what we do. Absolutely. That's why I threw out a skeletal proposal for discussion. Some first thoughts on this topic ... I think there are actually two points where access control must be applied: - Customization - users should only be offered portlets that they are allowed to use - Access to portlets - before displaying a portlet or allowing to perform an action on it, the portal needs to check whether the user still has access rights In either case, the access decision should be obtained via the same interface. Definitely need both, yes. That's what motivated my proposal of using getPortletSet as a filtering chokepoint, as anything using the portlets for any purpose will go through that API. That's one of the relevant points, it would involve access control in customization and display of portal pages which contain a set of portlets. However, this would not control access to portlets that does not go through aggregation or customization, e.g. via the maximized URL for a portlet. Some initial ideas how this may work - I think we need something like this in addition: +-+-+-+ +-+ | Portlet | Portlet | Portlet |...| Portlet | ++ +---+ | Access Control | |Portlet Invoker|-| Check I/F | +-+---+-+ ++ | Aggregation | Customization | Other Views | +-+---+-+ Every call to a portlet should go through an access control component. That component may have methods like public void service(PortletID id, String user/groupID, PortletRequest portletReq, PortletResponse portletRsp) public void actionPerformed(PortletID id, String user/groupID, ActionEvent actionEvent) ... etc. (Note that this is just for illustration, this is not intended as a concrete proposal) The PortletInvoker should make the required checks using the access control interface for checking permissions and then invoke portlets like this portlet.service(portletReq, portletRsp) actionPerformed(actionEvent) ... if the permission check was successful. All aggregation modules, customizers and other components in JetSpeed should invoke portlets only through the portlet invoker. This ensures that the invoker can always apply proper access control checking, calling the currently configured service via the JetSpeed access control interface. [snip] To accommodate usage of either store, JetSpeed should define an interface to check permissions, i.e. a call like checkPermission(user, portletID, action) or checkPermission(group, portletID, action) "action" may be something like display, edit, config, ... Makes sense. There should be pluggable services implementing this interface, e.g. one using settings in jetspeed.jcfg, one using a database, one using an authorization engine, etc. One option to implement the pluggable services would be Turbine Services, i.e. we would have Turbine Authorization Services that would be invoked through the JetSpeed Authorization Interface. I like the pluggable service model, and it should definitely be a Turbine service. That would most likely be a service that would be pert of the JetSpeed code base implementing the generic Turbine service interface and adding the portlet access control methods defined in the JetSpeed access control interface. -- Craig Berry - (310) 570-4140 VP Technology GlueCode 1452 Second St Santa Monica CA 90401 Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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
We also have plans in this direction, I think we should agree on a common interface for what we do. Some first thoughts on this topic ... I think there are actually two points where access control must be applied: - Customization - users should only be offered portlets that they are allowed to use - Access to portlets - before displaying a portlet or allowing to perform an action on it, the portal needs to check whether the user still has access rights In either case, the access decision should be obtained via the same interface. The latter is required to cover the case that a user has selected a portlet some time ago, when he was allowed to use it but meanwhile an administrator has revoked his access rights. Putting the info in the jetspeed.jcfg file is one option. Other options are putting this info in a database or in some kind of authoritzation engine , e.g. Policy Director or Siteminder. To accommodate usage of either store, JetSpeed should define an interface to check permissions, i.e. a call like checkPermission(user, portletID, action) or checkPermission(group, portletID, action) "action" may be something like display, edit, config, ... There should be pluggable services implementing this interface, e.g. one using settings in jetspeed.jcfg, one using a database, one using an authorization engine, etc. One option to implement the pluggable services would be Turine Services, i.e. we would have Turbine Authorization Services that would be invoked through the JetSpeed Authorization Interface. Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany The GlueCode team is preparing to pursue portlet-level security for Jetspeed -- that is, the ability to make portlets visible to only certain users. Of course, we want to build this on the existing Turbine group/role/permission scheme. Our initial thought is that adding attributes in jetspeed-config.jcfg of roughly this form viewable-by group="foo" role="bar" perm="baz" / would be a good way to encode the permissions. In the absence of any such attributes, the default would be viewable by all. A reasonable "choke point" at which to limit access to portlets would appear to be PortletConfig.getPortletSet(). The set returned could be filtered to remove portlets for which the user does not have permission. This would suffice to control access both to portlets on the portal page, and listing of portlets on the customization page (which we're working to extend, by the way). Thoughts on this approach, please? -- Craig Berry - (310) 570-4140 VP Technology GlueCode 1452 Second St Santa Monica CA 90401 -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: CVSupdate:jetspeed/src/java/org/apache/jetspeed/util/servle tEcsServletResponse.java EcsServletElement.java
Hi Raphael, the method you tried to use (EcsServletResponse) was the first idea we had when we wanted to support JSP/Servlet invocation from portlets. To avoid any potential Problems with Servlet Container behavior and also avoid unnecessary buffering of JSP output which lets memory usage drastically increase under high load, we implemented the EcsServletElement that defers invocation of the JSP or Servlet until the Ecs-Tree is finally traversed to generate output. This is the right time to invoke the Servlets/JSPs, in this case they can just write to the real servlet output stream which gives you maximum performance and avoids any problems with app server implementations. Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Styling by portlet container ?
low for aggregation of content before styling as I feel it will be the way to go in a short amount of time. So I guess a portlet.sax package like proposed in Ingo's most recent proposal that lets you use event streams would be acceptable for you ? I think I am getting constructive here. :) Indeed, your thoughts are always very interesting :) I am looking forward to your responses to my questions ! Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Summary and IBM Position (long)
fragments, as it allows for fast implementations and keeps complexity and thus development and maintenance costs low. If it necessary for a consensus, we can accept option b) as a compromise. i.e. allowing for both use of fragments *and* full documents. Option c), i.e. mandatory use of full documents that require post-processing is not acceptable for IBM because of the major performance impact of mandatory post-processing. 3. Internal structure of document fragments We prefer option a), option b) can potentially be accepted as a compromise if necessary, but requires more investigation. b)would add significant complexity to portlet container implementations, as they would need to merge multiple cards per portet into portal stacks, keeping in mind the buffer limitations of devices. 4. Implementation Option a) is the most desirable implementation for the April release from our point of view. Extension to b) is possible in the following release. Option b) is a possible compromise, but seems hardly achievable for an April release of JetSpeed before ApacheCon. Option c) is not acceptable for IBM. Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Summary and IBM Position (long)
Sam Ruby wrote: Thomas Schaeck wrote: Unlike the Servlet API, the Portlet API would additionaly provide explicit SAX support in the sax package and introduce a dependency on org.xml.sax, i.e. a separate package. Such a dependency of an API package to another API package that is not part of the core Java classes is rather uncommon. FYI - SAX is provided by JSR 5 (aka, JAXP). Sources tell me that JAXP will be included in JDK 1.4. - Sam Ruby Cool! I knew about JAXP, but so far I only heard statements that the XML APIs *may* be included in JDK 1.4. The *will* sounds much better. That should resolve the issue. Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
RE: servlet to portlet
David Sean Taylor wrote: Ingo, What you wrote here is of interest to me: (Note that the latter way is very easy, but it is generally bad practise to open HTTP connections from within a servlet container to a servlet in the same container. In systems under high load, the EcsServletElement sould only be used with remote servlets.) That's a misconception. The ECSServletElement does not open an HTTP connection, it just uses the request dispatcher to include the JSP or Servlet. This is just the normal way of adding content created by a JSP to a page. There is no performance problem here. A problem occurs only when a portlet opens a URL connection to a servlet in the same container, because under high load requests queue in front of the servlet container, waiting for a thread to become available. However, the threads waiting for their URL connection to return data cannot be used, as the request they sent are also queued in front of the container, but cannot handled because there are no free threads ... Nice loop. Isn't that what TurbineJspService does with a RequestDispatcher? This implies that the current Jetspeed/JSP impl. is 'bad practice'. Is this subject covered in the servlet spec? Could you point me to some sources on this subject? I'd like to learn more about the reasons why this is bad practice. If you remember, last week I posted a message about the Jetspeed-JSP code failing to run under one particular servlet container. Well, it turns out that problem is that the RequestDispatcher in TurbineJspService fails to include. I have reported a bug to the vendor, they have acknowledged that it is a bug, but I haven't heard back from them yet Thanks, - david Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API
Santiago Gala wrote: Do you mean that javax.servlet.* is more standard than javax.xml.* (Trax and Jaxp)? What I am trying to point out is that it is not good for a standard Java API depend on other Java APIs that are not part of the JDK classes. If you look at javax.servlet for example, it has no dependencies on any other Java extension, only on classes and interfaces in the JDK classes. Whenever possible, dependencies of Java APIs to classes/interfaces that are not JDK classes should be avoided. Maybe it is true, but I can't see it. The servlet API contains a specific method of creating output, namely writing to a response stream. Writing to the response stream just seems like the natural way of outputting content to me - and probably to many people used to write servlets. I think this is different than using SAX, DOM, or ECS. Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany Santiago Gala [EMAIL PROTECTED] on 02/14/2001 03:56:45 AM Please respond to "JetSpeed" [EMAIL PROTECTED] To: JetSpeed [EMAIL PROTECTED] cc: Subject: Re: [vote] Portlet API [EMAIL PROTECTED] wrote: I think it is useful to provide a little summary of the current state of the discussion. I tried to give a neutral summary on each item, followed by my opinion. Point 1: Should JetSpeed require portlets to produce full documents ? Producing full documents means that the portal implementations would need to decide which parts of complete documents returned by portlets should actually be embedded in the overall page created by the portal. The motivation behind this - as Raphael described it - is that there are no guidelines defined for fragments that should be returned by portlets for markups like (X)HTML, WML, SMIL, FO, VoiceXML, cHTML and that the guideline for portlet developers should be "Portlets must output well-formed (complete) documents conforming to the DTDs required by the client devices" instead of "Portlets should return well-formed document fragments suitable for aggregation in well formed documents conforming to the DTDs required by the client devices". The result of JetSpeed requiring portlets to produce full documents would be that all content generated by portlets would need to be post-processed by the portal implementation. There seems to be agreement that this introduces significant performance and memory overhead compared to portlets directly writing fragments to the portlet output stream without post-processing. There is disagreement on whether the resulting performance and memory overhead is acceptable or not. That depends on the use. I agree that imposing this requirement is not right. The decision to postprocess should be up to the implementor. (My Opinion (TS): We have implemented a portal that serves HTML, WML, VoiceXML and cHTML. The portlets directly write mark-up fragments to the output stream using JSPs or Stylesheets without post-processing, which is very fast. Forcing all content to be post processed through a SAX parser would impose an unacceptable performance degradation on our portal. We can make guidelines for content fragments that should be created by portlets available to resolve the issue of missing guidelines. My opinion is that we should under no circumstances require complete documents to be returned by portlets, as this woud introduce an inherent limitation of JetSpeed's performance.) I agree that postprocessing should not be mandatory. But if we don't have event processing in the API it is not optional, but nearly impossible. There is an activity for the specification of XML fragments (XHTML, WML, VoiceML, ...). http://www.xmlhack.com/read.php?item=1067 describes it. (Taken from Jetspeed xmlhack channel). To me, the requirement of outputting documents looks too strong, and short term sighted. There is ongoing effort to specify how to describe valid XML fragments, and the trend is to have markup languages that follow a schema/DTD (XML). Point 2: Should the Portlet API provide dedicated methods for SAX output ? This means that the methods getContentHandler() and getLexicalHandler() would be added to the PortletResponse interface. It could be done with other methods, possibly using only javax.xml.transform.* classes. The motivation behind this is that it should be possible for portlets to output SAX events rather than writing to the output stream so that portal implementations that internally process SAX events can provide document handlers that would directly be invoked by portlets rather than parsing the portlet response's output stream to create SAX events. It will allow the following things: - More modular design of a portal, as portl
Re: [vote] Portlet API
Raphael Luta wrote: At 23:56 13/02/2001 +0100, you wrote: I think it is useful to provide a little summary of the current state of the discussion. I tried to give a neutral summary on each item, followed by my opinion. Thomas, I think it's a very good summary of the issues. I have just 2 things to add/modify to this. - Point 1 should be titled: "Should the Portlet API require portlets to produce full documents ?" Yes, that's a better title, we are actually talking about the Portlet API here. Wer're not discussing (yet) the Jetspeed implementation, which may support both full documents and document fragments through configuration elements external to the proposed standard Portlet API (for example the portlet deployment descriptors that were proposed in the first Portlet API discussion 3 months ago) The document fragments need to be in the standard and the full documents need to be prohibited by the standard (see below). This not only my opinion, but also what our customers and other portal vendors I already talked to about Portlet API standardization are saying. If you look at the web sites of Oracle, BEA, and other portal vendors, you will see that they are also using document fragments (see also Ingo Rammer's note listing Oracle's guidelines). We'd hardly find a single major portal vendor who would be in favour of requiring full documents in the standard that require mandatory post-processing that will slow down his implementation and lead to bad benchmark results. Just today I visited a very large portal customer at their headquarters and talked to their technical experts and technical decision makers the whole day. One topic was of course aggregation and they were very happy with the approach to use portlets that write document fragments directly to the output stream one after the other. They asked whether we would create temporary objects/strings or do any post-processing and were only satisfied after I assured them that everything is written directly to the output stream without any performance or memory overhead. We cannot change this. Ok, I guess now I've stressed this point more than enough ;) - I think we should add to this summary the following notice: The Jetspeed community has decided to start specifying a portlet API that could be proposed as a standard for all portal implementations. Offering a standard API between portals only makes sense if the portals implementing the API can guarantee to the portlet writers complying to implementation they are deployed upon: "write once, deploy anywhere" This is the reason why the Portlet API should define both the programmatic API as such, but also the content guidelines that portlet writers should follow to achieve portability and possibly the deployment process. I absolutely agree that content guidelines (or better rules) that portlet programmers/designers must follow should be defined in addition to the programmatic Portlet API. I think these rules need to contain the following items: * A general statement saying that portlets must return document fragments suitable for aggregation in the client's expected mark-up language and may not return full documents. * Detailed Specs of Fragments for particular mark-up languages: - A HTML Fragment Specification for Portlets - A WML Fragment Specification for Portlets - A cHTML Fragment Specification for Portlets - A VoiceXML Fragment Specification for Portlets - Fragment Specifications for other mark-up languages We can provide the fragment specs for HTML, WML, cHTML and VoiceXML. These specs along with the specification of the programmatic Portlet API and the Portlet Archive format will enable "write-once, deploy everywhere" for portlets. Once these specifications are available, tools can be written that take templates created by visual tools and strip off the tags before deployment of portlets, rather than stripping off the tags at run-time in a post-processing step for each request. By the way, the rules we use for HTML fragments in our projects at IBM are basically identical to Oracle's that Ingo Rammer has posted, I guess it is just common sense that leads to these guidelines. The guidelines for the other mark-up languages may be a little bit trickier, but certainly doable. Point 1: Should JetSpeed require portlets to produce full documents ? Producing full documents means that the portal implementations would need to decide which parts of complete documents returned by portlets should actually be embedded in the overall page created by the portal. The motivation behind this - as Raphael described it - is that there are no guidelines defined for fragments that should be returned by portlets for markups like (X)HTML, WML, SMIL, FO, VoiceXML, cHTML and that the guideline for portlet developers should be "Portlets must output well-formed (complete) documents conforming to the DTDs required by the client devices"
Re: [vote] Portlet API
Raphael, I think we should not decide on these two points as isolated items, they need to be put into perspective to make sure that everybody fully understands the consequences and implications before voting. The larger question behind this is whether we want JetSpeed to be a high-performance, highly scalable portal engine usable for portals under a high load or whether we are willing to accept mediocre/poor performance/scalability which would inhibit use of JetSpeed in larger projects that need high performance and scalability. There will be more design decisions where we have to choose between performance/scalability/reliability on one side and something convenient, something nice or cool on the other side and these decisions will depend to a certain extent on our answer to the more fundamental question raised above. I think we should decide for the first option so that JetSpeed gets the chance to evolve into industry strength software like the Apache HTTP Server. To give you an example, our portal implementation uses JSPs or to generate all output, portlets may use JSPs or stylesheets, everything is written directly to the servlet's output stream, we have reduced per-request memory usage and per-request processor usage as far as possible to achieve the required performance and scalability. We have no need for any kind of post-processing, as our portlets create appropriate markup-fragmentsa and dynamic URL lookup within JSPs entirely avoids the need of URL postprocessing. If the vote on point 1 would be yes, this would result in severe performance problems: If the portlet API mandates full documents, this would require costly post-processing to strip off parts during content aggregation. It is much more efficient to have each portlet write a document fragment to the output stream at the appropriate point in time during page aggregation than to have each portlet create a complete document in the form of SAX events, send all these events to a document handler that drops the parts that are not required and finally writes the relevant parts to the output stream. Did you measure by which factor the SAX parsing will reduce performance and increase memory usage per request compared to straight JSP processing ? Even if there would be post-processing, portlets could still screw the entire portal by producing large amounts of valid XML, producing well-formed but invalid XML (e.g. invalid WML), or using up the JVMs memory. In all portal projects I have seen so far, portlets were tested before they were deployed and it was the responsibility of the portlets to produce correct mark-up. The introduction of a getContentHandler() method to the Portlet interface seems like a compromise that would allow for the SAX approach in addition to the stream-based appropach, but it would force all portal container implementations to implement both mechanisms and it would introduce a direct dependency of the portlet interface and thus the Portlet API to the interface org.xml.sax.DocumentHandler. Of courcse the org.xml.sax package will become a part of J2EE 1.3, but nonetheless I think the Portlet API should not depend on the XML API, it should only depend on core java classes as it currently does. As we intend to turn the Portlet API into a standard, we should not add special methods for such specific tasks as doing SAX event handling. Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- Raphael Luta wrote: Following the discussions on the Portlet API, there's no strong consensus on the following points of the Portlet API and so they should be voted upon. For those who did not follow the arguments, pleae read the "Secure Portlets" thread in the mail archive before voting. Point 1: Should the Portlet API mandate that portlet only output full documents rather than document fragments ? Point 2: Should we add a getContentHandler() and getLexicalHandler() in the PortletResponse interface ? A portlet will not be able to use both getWriter() and getContentHandler() in the same request response. -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Serlvet API error
Does the servlet you invoke implement the post and the get method ? The JetSpeed Implementation sonetimes uses the post method. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany Hi all, I'm building a Servlet portlet which is used EcsServletElement to get the content from a servlet. I added this portlet in jetspeed-config.jcfg file. After that I added this portlet into the Turbine home page via the customizer. The first time the Turbine home page is displaying, I get en servlet error for this portlet : "Servlet API error : sendError with commited buffer". After - when I "maximize" my servlet portlet -, I can see the right content and that's the same when I minimize this servlet portlet, the content is correct. So, do you have an idea why I get this exception when jetspeed display for the first time this servlet portlet ? Christophe _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Enterprise Applications
Great idea ! The portlets on the list all seem very useful to me. To answer the Portlet API part of question c) - there will be major changes in the Portlet API. These changes will affect the invocation of portlets and the way in which portlets access user data or store/retrieve persistent data. If you start developing portlets now, parts of the portlets will need to be changed when we introduce the new Portlet API. The good thing is that a lot of things will become a lot easier and that once you have adapted the portlets to the new Portlet API, changes in the layout system should not affect the portlets anymore. All invocations of portlets to render content for the layout system will be made through the new Portlet API. The new Portlet API will shield your portlets from any further changes in the JetSpeed or the Turbine implementations. You can review the current proposal for the new Portlet API in CVS to get an idea about to what extent the migration would impact your planned portlets. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Amal Sirvisetti [EMAIL PROTECTED] on 02/03/2001 05:07:56 AM Please respond to "JetSpeed" [EMAIL PROTECTED] To: JetSpeed [EMAIL PROTECTED] cc: Subject: Re: Enterprise Applications I think that kind of out-of-the-box applications will be nice to have! I am definitely interested in contributing. Depending upon the response and consensus, let us divide the work and conquer! Amal Manjuka Soysa wrote: Hi all, I am interested in developing some standard applications/portlets for Jetspeed: - email browser - to do list - problem / work assigment and tracking - time sheet entry - calendar (I heard this is being done) I'd like to find out if a) Anyone else is already doing these apps b) Anyone else is interested c) With the new layout system and portlet API being developed, is jetspeed to volatile to develop these now ___ Visit http://www.visto.com/info, your free web-based communications center. Visto.com. Life on the Dot. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- Regards, Amal = Amal Sirvisetti Ph: +1 732-563-6869 Sirvisetti Systems Fx: +1 732-563-6929 15 Kensington Drive http://www.sirvisetti.com Piscataway, NJ 08854 = -- -- 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]
Problems with Too many synchronized statements ?
We have done some performance measurements, running JetSpeed on RS/6000 machines with one and with four processors. The 4-way machine's processors are running about twice as fast as the 1-way's. Surprisingly, performance seems to increase proportionally with the speed of the processors, but seems not to improve with the number of processors. Did anybody observe similar behavior ? A potential explanation for this behavior might be synchronized statements in code that is called directly or indirectly from the service-method of a servlet. Are there known problems in this area ? Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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 /urlmanagerJetspeedURLManagerService.java
Santiago, thanks for the detailed explanation, now I understand. I was not concerned about the performance, but rather about potential deadlocks. It is good to hear that Turbine has already resolved the issue. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany [EMAIL PROTECTED] escribi: 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. It is part of the workaround for the bug in the turbine.jar we are using right now. We can get rid of it when we update turbine, although it should do no harm, as it is executed only once per life cycle. The idea is: If somebody calls init( conf ) twice, the second caller will wait until the first finishes (synchronized). When the first finishes, either: getInit() will return true (we are already initialized), so the second thread returns. getInit() will return false (we failed previously), so we try again in the second thread. To further complicate the picture, a third thread can ask for the service while these two (or more) threads are "fighting" to initialize the service. In case a service is asked for and getInit() returns false, turbine will call late init(). There we must wait until getInit() returns true. (the previous impl did not implement this call, and BaseService did setInit(true), returning a half-cooked service to the caller). I made a mistake when I synchronized late init() and at the same time waited there. This locked up turbine if some thread asked for the service (late init) BEFORE early init was called. This thread got the lock, and waited for something impossible to happen. Has I use wait()/notifyAll() instead of sleep() it would have worked. Currently, late init() is not synchronized, and waits for early init(conf) to finish. When we can be sure that turbine will call us only once (when we update to a more current release), we can get rid of both the synchronized and the if(getInit() ) return; (although I think they are not expensive and do no harm). I hope I explain it correctly. It took me quite a few hours to understand what was going on there ;) -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Problems with Too many synchronized statements ?
Santiago, thanks for confirming our observation. Currently, we get all user data and the user PSMLs from IBM Secure Way Directory Server (pretty scalable). Our traces/logs were switched off during the performance measurements. We are currently analyzing the trace staments across the JetSpeed code in detail, maybe we'll find a piece of code that sequentializes all the servlet threads. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany [EMAIL PROTECTED] escribi: We have done some performance measurements, running JetSpeed on RS/6000 machines with one and with four processors. The 4-way machine's processors are running about twice as fast as the 1-way's. Surprisingly, performance seems to increase proportionally with the speed of the processors, but seems not to improve with the number of processors. Did anybody observe similar behavior ? Yes. I observed similar behaviour under 2-way with Linux Sun jdk 1.3 Server Hotspot. In my tests, response time grows about 50% between 1 and 2 concurrent requests. From there on, response time growm linearly with the number of concurrent requests. With "perfect" concurrency, time should be the same between 1 and 2 concurrent requests. A potential explanation for this behavior might be synchronized statements in code that is called directly or indirectly from the service-method of a servlet. Are there known problems in this area ? I have not identified any such execution path. Potential problem areas are the factories and other singletons, where look up must be performed for components ( getPortlet(), ...) and also the database (I'm using Hypersonic for my tests). Which DB are you using? The logging is a big potential bottleneck, since the threads fight to get a lock on the logger stream. We are logging maybe 20 lines (=20 locks) per request. Do you have profiling data? The profiler does not work under linux hotspot :( -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: CVSupdate: jetspeed/src/java/org/apache/jetspeed/services /urlmanagerJetspeedURLManagerService.java
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
Thomas Schaeck
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail:
[EMAIL PROTECTED] Fax: +49-(0)7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany
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]
--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/
List Help?: [EMAIL PROTECTED]
Re: Threaded getContent() ...
I also thought about this approach some time ago. If you look at handling one request, you are certainly right. By sending off several requests at once, you can reduce the response time if a small number of requests is processed by the portal. However, the usual scenario for a portal is that you have a large number of users that use the portal in parallel. In that case, the picture probably looks different. For example, if you have only 100 requests concurrently processed by the portal and in average five portlets per page that make requests to external information sources, the portal would want to send off 500 requests from 500 threads. An alternative approach that often used to get better performance is to have a permanently updated replica of the content at the portal site. Many content providers provide special clients that take care of keeping the replica up to date with content on the internet. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany Hi all ... I am just writing some portlets connecting to external sources and had some ideas on how to enhance the request performance (processing time). As I understand, Jetspeed calls every getContent() of a portlet in a sequential way. This means if a portlet waits for an answer of a third party system, the hole request will wait till this third party system has answered. So if you have 3 portlets in a portal screen connecting to different third party systems a request in the jetspeed engine would look like this. -- request time - portlet01.getContent() - connect to third party system 10 ms - wait for result90 ms - porcess and return result 10 ms - portlet02.getContent() - connect to third party system 10 ms - wait for result 160 ms - porcess and return result 10 ms - portlet03.getContent() - connect to third party system 10 ms - wait for result 120 ms - porcess and return result 10 ms return result -- processing time 420 ms Another solution to handle this request is by a thread pool which will call the getContent() method of each portlet in parallel, the request would look like this. -- request time - portlet01.getContent() - connect to third party system 10 ms - portlet02.getContent() - connect to third party system 10 ms - portlet02.getContent() - connect to third party system 10 ms - wait for result 160 ms - porcess and return result 10 ms - porcess and return result 10 ms - porcess and return result 10 ms return result -- processing time 220 ms The processing time for a request would be pretty faster. Even when adding some time for thread handling and synchronization would beat the sequential method. Or do I oversee something? Comments, remarks, criticisms welcome... Mirko Buholzer -- Sent through GMX FreeMail - http://www.gmx.net -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [long] Layout system, part 2: functional description
Raphael Luta wrote: That's a programmer approach ;) The API will probably never be accessed outside of Jetspeed layout engine whereas the markup may be used by a lot of end users for customizing their sites. Which one is the most important in your opinion ? The API for the content model is very important, because it represents a clean interface between the data model on one side and layout engines and customizers and potentially other portal components that will want to access the content model programmatically. It should allow to implement different customizers (e.g. dragdrop, Yahoo!-like, ...) using the content model API, e.g. like this: +-+ +--+ | Customizers | | Layout Engine(s) |... +-+-+--+--+ | Content Model API | +--+--+ | XML Pers. Provider | DB Pers. Provider | +--+--+ The XML markup is important and must be easy to use. Administrators should be able to define layout patterns using XML markup, and these patterns need to be accessible through the content model API. There may be different kinds of customizers that create instances of the layout patterns and allow to add/remove portlets, flip columns, etc. I agree but this I don't want to tie the XML persisted markup with the persistence mechanism used. IMO, that's one of the issues with the current PSML which is designed to be nice with Castor but not necessarily with the end user. Yes, that's true. If providing user-editable XML markup is one of the deliverable of the project, we should first design a user friendly markup and a programmer friendly Java API and then see if there's a tool for persisting the specified API into the speciified markup. That's a good approach. If we don't need a user-editable XML markup, we might just as well drop this, always persist to the DB and write an administrative application for managing the configuration. I think even if a portal uses a database for persistence, the XML markup is useful as a medium to import layout patterns into the database. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany Raphael Luta wrote: [EMAIL PROTECTED] wrote: Raphael Luta wrote: Definitions: 3. Portlet A portlet is the base customizable content producing unit in Jetspeed. The functional description will usually not separate the portlet, as portal-independent component model and the portlet, as part of the Jetspeed layout system. When such a distinction is necessary, the former will be called "portlet" and the latter "screenlet". The meaning of the term "screenlet" cannot easily be found out without the definition. Perhaps we might use a more self-explaining term like "portlet view" ? That's a defirmation of teh writing because I have the implementation proposal written at the same time where screenlet is the base layout component and portlet view is a subclass of screenlet which is the portlet adapter. "Portlet view" is a totally adequate description. Actors: === This description may refer to the following actors: 1. Administrator: The administrator is the owner of the portal. He's responsible for designing the site templates and functionalities, configuring the initial properties files and defining the appropriate permissions. The administrator must understand the template language used by its site screens as well as the configuration files semantics. An administrator needs not necessarily be the owner of the entire portal. There may be cases where a portal consists of a number of independent portal instances. Each of these instances may have one or more administrators. Agreed, but I don't deal with access rights with this proposal, so did not want to create finer roles. You can also say that the administrator described above is also both a designer and an administrator. 2. User: The user is a client of the site, which is assigned specific portal configurations. A user does not necessary refer to a physical entity (it may be an anonymous user, a group, etc...). No specific knowledge is required for the user. What does the last sentence mean ? That use does not need to have any specific jetspeed knowledge before using a portal. Portal site definition == A portal site is defined by the portal administrator who needs to configure different files : - screen templates (which may use any template language supported by Turbine) defining the different pages for the site.
Re: [long] Layout system, part 2: functional description
Raphael,
thank you for taking the time to write this excellect description !
See some first comments and questions below.
Raphael Luta wrote:
[This document is a functional description of the new layout
system. Comments, remarks, criticisms welcome...
The actual implementation proposal will come after this
document requirements are somewhat stabilized]
Jetspeed layout system, part 2: Functional description
Raphal Luta [EMAIL PROTECTED]
Definitions:
1. Portal configuration
A portal configuration is a set of user properties, defined for a
complete portal site, that is used by Jetspeed engine to customize the
portal site. A configuration will usually be media type dependent. A
given
media type may be associated with several configurations for the same
user
profile.
2. Pane
A pane is a customizable layout component which can be included in the
main portal templates. Each pane is responsible for the layout and
rendering of its customized content elements.
3. Portlet
A portlet is the base customizable content producing unit in Jetspeed.
The functional description will usually not separate the portlet, as
portal-independent component model and the portlet, as part of the
Jetspeed layout system.
When such a distinction is necessary, the former will be called "portlet"
and the latter "screenlet".
The meaning of the term "screenlet" cannot easily be found out without the
definition. Perhaps we might use a more self-explaining term like
"portlet view" ?
Actors:
===
This description may refer to the following actors:
1. Administrator:
The administrator is the owner of the portal. He's responsible for
designing the site templates and functionalities, configuring the
initial properties files and defining the appropriate permissions.
The administrator must understand the template language used by
its site screens as well as the configuration files semantics.
An administrator needs not necessarily be the owner of the entire
portal. There may be cases where a portal consists of a number of
independent portal instances. Each of these instances may have one
or more administrators.
2. User:
The user is a client of the site, which is assigned specific
portal configurations. A user does not necessary refer to a
physical entity (it may be an anonymous user, a group, etc...).
No specific knowledge is required for the user.
What does the last sentence mean ?
Portal site definition
==
A portal site is defined by the portal administrator who needs
to configure different files :
- screen templates (which may use any template language supported
by Turbine) defining the different pages for the site.
Each template may access a jetspeed toolbox object which,
among other functionalities, will enable the administrator
to include configurable panes in the site templates.
What is the toolbox object ?
Example:
index.vm:
table width="100%" cellspacing="0" cellpadding="0"
tr
td valign="top"
$jetspeed.Pane("home_main")
/td
td valign="top"
$jetspeed.Pane("general_tools").Customize(false)
$jetspeed.Pane("user_tools")
/td
/tr
/table
[Note: the example markup proposed above is just used for
descriptive purpose]
When browsing this portal page, the named panes defintions
will be loaded from the current user configuration.
Is "$" used for macro-ivocation ?
- default portal configuration files
These files describe the various panes available for use within the
site as well as the portlets included in these panes.
example:
default.psml
configuration
panes
pane name="home_main"
!-- responsible for managing the LF (skin) of this pane --
window-manager ref="MyYahooWM"/
!-- responsible for the layout of the pane contents --
layout-manager ref="MultiColumnManager"
column-max3/column-max
/layout-manager
!--
entry ref="rss_jetspeed"
column0/column
/entry
entry ref="rss_turbine"
column0/column
/entry
entry ref="rss_jakarta.apache.org"
column1/column
/entry
/pane
pane name="user_tools"/
pane name="hobbies_left"/
pane name="hobbies_right"/
/panes
screenlets
screenlet name="rss_jakarta.apache.org"
portlet ref="RSS"/
urlhttp://jakarta.apache.org/overview.rss/url
show-descriptionfalse/show-description
max-items5/max-items
/screenlet
screenlet name="..."/
/screenlets
/configuration
I think it is a good idea to separate the layout/LF from the definition
of individual portlet views.
[Note; this markup is just for description purpose and may be different
than the one actually implemented]
[Note: The information stored within these files may actually be
persusted
in a relational SQL database or LDAP directory for complex sites
Re: Feature Proposals
Ingo Rammer wrote: Hi, three feature proposals. [And yes, I can do some java-developing myself *hint* *hint* ;)] #1 == Forgot Username/Password When a user logs in and username/password mismatch, a link called "Forgot your password?" will be displayed. On clicking it, a new screen will be shown, that allows the user to enter either Email-Address or Username. The user's password will then be sent to the specified email-address. This is a good idea. However, it is just one way of handling forgotten passwords. Another way is using a reminder phrase, for example. Ideally the mechanism for handling forgotten passwords should be pluggable. Perhaps it is possible to implement the handling for forgotten passwords in portlets. The page to which the forgotten password link points would then contain the forgotten-password-handling portlet of choice. #2 == Duplicate E-Mail Check -- When a new user signs up, a check will be done against the current user-database with email as the key. When a matching entry is found, the user isn't allowed to sign up again, but instead gets the possibility to get his password emailed to him. What would be the benefit of this behavior ? #3 == WebPagePortlet -- Like FileServerPortlet, but will rewrite A HREFs, so that they point back relative to the original website. IMG SRCs will be rewritten, so that they will be requested from the local cache. An extension to the diskcache has to be made, to allow cached entries to be directly requested by using http get's. Reason: Integration of seperately maintained (i.e. other host, other country, etc.) departmental pages into a company's intranet/portal. This one is pretty hard, but surely it would be very useful. There has been an extensive discussion of this topic some months ago, it might be worthwile for you to dig through the mailing-list archives. The complicated thing about this is that a truely generic portlet that should be able to run any web application in a portlet cell would also need to refwrite JavaScript. Probably the rewriting mechanism would need to include a portlet instance id in each url. thanks for more information, Ingo Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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 1.3a2
necessary. I've noticed that we now have three: 1. standard Turbine services 2. a kind of hybrid that Raphael and I started with: the RegistryManagerService and ProfileManagerService -- which I like, but there is a real problem with the way interfaces are duplicated 3. the new Service and ServiceFactory defined in portal/service. -- David It would surely be good if we could unify the different service concepts. I think we should not directly use Turbine services for services that are basically extensions to the portlet API, like persistence, user info and location. This would tie the Portlet API to the JetSpeed implementation. The Portlet API has to be selfcontained and may only rely on J2EE, so that portals other than JetSpeed may implement the same API in a different way. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: XSLPortlet , JetspeedContent
Raphael Luta wrote: Santiago Gala wrote: I'm using Observable for tests, but we can change this class by some other interface if needed after the concept is tested. I will look for similar patterns in Turbine/Avalon code. I thought that the Observer pattern was deprecated in Java and a Listener/Event model was the recommended way of doing things now. Yes, the listener/event pattern should be used instead. In any case, I think there are several issues with the disk cache system right now, the main one being that it's over-used throughout the current jetspeed code, as an interface for accessing remote documents, config files, etc... We have to stop this ! We should : 1- Define what is the *real* purpose of the DiskCache IMO, the cache should not try to be as intelligent as it is now 2- Define what kind of repository access we need in Jetspeed I can see at least 2: - remote syndicated document repository - configuration file repository others ? 3- Define facade class/interface for accessing these repositories * syndicated document = URLManager service * configuration files = Persistence service ? These interfaces need to be extensions to the portlet API. 4- Implement these services so that they (don't) use the DiskCache as they see fit I think one thing we should observe here is that often systems use proxys for caching. For that case, the URLManager service should be configurable, so that by specifying an optional parameter like mode=proxy, use of the disk cache is disabled. 5- Replace all the other references to the DiskCache in other parts of the code to references to the appropriate Facade classes. 6- Have a party :) This is a good plan, I especially like item 6 :) Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: XSLPortlet , JetspeedContent
Raphael Luta wrote: [EMAIL PROTECTED] wrote: Raphael Luta wrote: In any case, I think there are several issues with the disk cache system right now, the main one being that it's over-used throughout the current jetspeed code, as an interface for accessing remote documents, config files, etc... We have to stop this ! We should : 1- Define what is the *real* purpose of the DiskCache IMO, the cache should not try to be as intelligent as it is now 2- Define what kind of repository access we need in Jetspeed I can see at least 2: - remote syndicated document repository - configuration file repository others ? 3- Define facade class/interface for accessing these repositories * syndicated document = URLManager service * configuration files = Persistence service ? These interfaces need to be extensions to the portlet API. I'm not sure of what you mean here. I assume you say that the service should be compatible with the service-access API which is (should be) part of the Portlet API. Correct ? The Portlet API needs to include interfaces for - Persistence - Access to User Info - Access to URLs - Access to Location Info - etc so that portlets written using the Portlet API can ultimately run on all portal implementations that provide a portlet engine that implements the Portlet API. I hadn't thought of an interface to get URL content via a cache as a part of the Portlet API before, but its seems useful. It would allow a portlet to take advantage of a portal's caching mechanism without becoming dependent on a particular portal implementation. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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
For concerns about Tracing/Logging I suggest take a look at: http://www.log4j.org./ Josep Vela [EMAIL PROTECTED] RD Manager FIHOCA Avda. Roma, 25 8029 Barcelona (Spain) Thanks for the hint, the API looks quite good, it has the required isEnabledFor(Priority), isInfoEnabled() and isDebugEnabled() methods, also, it has explicit support for assertions which is very nice. However, a colleague just told me that the Turbine community has decided against using Log4J and is now working on improved tracing/logging, I think based on Avalon. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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 1.3a2
Raphael Luta wrote: Now that we have released a new 1.3a1 release that should hopefully dramatically cut down the installation issues of Jetspeed, it's time to really start working on Jetspeed 1.3a2 and what features we should include into this release. My personal target feature list for 1.3a2 is this : - fully catch up with Turbine * upgrade to the latest TDK Turbine * rework the TurbineUser dependent code to be only User dependent * start using ACLs * allow any Turbine templated system for layouts and screens with Velocity as default Personally, I'd prefer JSPs as the default, but as long as JSPs can be used alternatively Velocity as the default is fine. I'd like to add * Introduce conditional tracing (as soon as Turbine povides the required methods) - rework the layout system * integrate templates in the other Jetspeed elements The template systems we'd support first are JSPs and Velocity, I guess ? * rethink the PSML support I'd like to add * Introduce Unique Portlet Instance IDs I think we also need to introduce a concept for unique portlet instance ids, maybe consisting of a user id, page id and portlet id and sequence number in order to be able to implement persistence services that store portlet data in a database. (This is just a first idea, maybe this a more complex topic.) * use the new Portlet API - redesign the customizer * be layout aware * use some portlet-customization entry points in order to provide portlet level customization. - integrate the new Profiler - clean up the DiskCache - change the current Castor based persistence to something extensible Comments or other features requests are welcome. I'll commit in the CVS a TODO-RELEASE-1.3a2 file just like we've done for 1.3a1. It's too early right now to target a release date but I definitely want it before ApacheCon. That would be before 4/4/2001. Sounds very reasonable, we should definitively have another release before April. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Tracing/Logging in JetSpeed
Happy new Year !
As my first statement on the mailing list in the new year and millenium,
I'd like to thank all who helped creating the JetSpeed 1.3a1 release,
especially Raphael who must have worked day and night. Great job ! It's
very cool that JetSpeed can now be installed so easily.
In JetSpeed, there are statements like this in a lot of places:
// always creates 3 new String objects
Log.note("SimpleTransform: transforming url: " + url +
" with stylesheet: " + stylesheet_url );
These tracing statements are very useful during development, but when
JetSpeed is deployed in a production environment, it should be possible to
turn off tracing for performance reasons. To allow to effectively disable
all tracing overhead including creation of trace message strings,
statements like this
// creates new String objects only if Log is logging
if (Log.isLogging()) {
Log.note("SimpleTransform: transforming url: " + url +
" with stylesheet: " + stylesheet_url );
}
can be used. (Just doing filtering in the Log.note() method instead of
explcitly checking whether the log object is actually logging would still
result in creation of 3 new Strings per request for the example above.)
I think an isLogging() method should be added to Turbine's Log class and
that we should change the logging in JetSpeed to consistently use the
isLogging() method before making Log calls in order to minimize object
creation/garbage collection overhead when tracing is disabled.
What's your opinion ?
Best regards,
Thomas
Thomas Schaeck
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED]
Address: IBM Deutschland Entwicklung GmbH,
Schoenaicher Str. 220, 71032 Boeblingen, Germany
--
--
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
Raphael Luta wrote: That this code does not belong to Jetspeed but to the framework. ;) There are already way too many logging class around here and I don't see the point in implementing yet another one. Logging and debug features are important but should be (and maybe are already ) addressed by Turbine, so the extensions to the logging capabilities of Turbine should be discussed on Turbine. As for me, I'd be happy with any scheme right now because I don't think performance will be very important before 2 or 3 other alpha releases. I'd focus right now of usability and functionalities. Ok, we'll move the discussion to the Turbine mailing list. As soon as the Turbine Log class has the new mechanism, we should update the trace statements in JetSpeed appropriately so that new code that is written allows effective disabling of trace overhead from the beginning. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Locale Specific Portlet Titles
You've got a good point here. We see similar requirements for future versions of JetSpeed. One thing we also should consider is the scenario, where a user selects a language during registration or selfcare; in that case the language to use would have to be obtained from a user profile object. Currently, JetSpeed displays the title string specified in the user's PSML file (AbstractPortlet.getTitle()). Changing the signature of that method to public String getTitle(RunData runData) would probably solve your problem, but I think what we also need is a way to specify alternate titles for different languages, so that AbstractPortlet.getTitle() can do something like return getPortletConfig().getMetainfo().getTitle(locale); Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany [EMAIL PROTECTED] on 02.01.2001 23:59:36 Please respond to "JetSpeed" [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Locale Specific Portlet Titles -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm trying to write a portlet that will have a title that is displayed as a locale sensitive string. In other words, I want the portlet title to be displayed in the locale specified in the browser's Accept-Language header field. Locale sensitive information can be displayed in the getContent() method as this information is available via the RunData object (ie: RunData.getRequest().getLocale()). The problem (as I see it) is that there is no way to access the RunData object from within the getTitle() method of a Portlet. Can someone suggest an alternate way to accomplish this, or would this require an API change in the Portlet interface. Thanks in advance, - - Tim Taylor -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.8 for non-commercial use http://www.pgp.com iQA/AwUBOlJcQn0GulZt1ukUEQK+DQCg/ckFP2Xo38m19vOaFTSJ+/swhrUAoL8X ArYvoW3PJcOZYxCEb7fTmy7E =Xyk9 -END PGP SIGNATURE- -- -- 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 Documentation Format for 1.3a1
David Sean Taylor wrote: No, its very simple, you just have to use the correct Word styles, and then run a convert-program on the word doc. I can send it to you tomorrow. My collegue is working on it, and he is travelling today. Cool. Thank you ! Is your Developers Guide in the CVS ? No its not. I will check it in when I complete converting it from 1.2b1 to 1.3a1. I see there is a lot of new code being checked in for the persistence service and customizer as we speak. I would like to update the document to also describe those services in the next week. Is there a specific date when all this should be completed for 1.3a1? Ingo has committed the rest of our code to CVS yesterday night :-) We have written a guide that describes hwo to write portlets and how to register them. Would it make sense to include this description in your guide ? Yes, I think so. I can try incorporating the two doucments if you'd like. OK, we'll send you our part of the docu on Monday. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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: JetSpeed Documentation Format for 1.3a1
David Sean Taylor wrote: I still haven't had a chance to look at Anakia in depth. I am working on updating the Jetspeed Developers Guide that I wrote, which is in Word format, from 1.2b1 to 1.3a1. My collegue has a process where he can take a Word document, which uses a known set of styles, and transform it to Stylebook XML format. I was also looking into updating the installing xdoc to incorporate Raphael's new WAR installation process. Sounds cool. We are also using word, so this would be very useful for us. Is it complicated to set up this process ? Is your Developers Guide in the CVS ? We have written a guide that describes hwo to write portlets and how to register them. Would it make sense to include this description in your guide ? Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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: [API] inter-Portlet communication
One thing I thought of was sharing data between portlets. For example, you might have a portlet that displays stock quotes and a company news portlet that automatically displays news that relate to the same stocks that are tracked in the stock portlet. (I think I saw this at Yahoo! Finance) Do you mean something like this or portlets invokung other portlets and passing data ? Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany "Jon Hauksson" [EMAIL PROTECTED] on 05.12.2000 10:02:53 Please respond to "JetSpeed" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] cc: Subject: [API] inter-Portlet communication I'm curios to here your views on inter-Portlet communication, do you think the API should support it and to what extend. Cheers -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] -- -- 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
Something like that yes, although I was also playing with the idea of changing the portal OM, the control would become the display peer of a portlet thus completely hiding the portlet API from the rendering engine. This will allos to evolve the rendering/layout engine independently of the portlet API. Seems like a very good idea to me. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany [EMAIL PROTECTED] wrote: Raphael, thanks for the info. Would the template support in portlets/controls/controllers use nested invocation of templates like in the example below to avoid use of ECS for page generation ? Yes template1 (e.g. controller template) calls template11 (e.g. control template ) calls template111 (portlet template) calls template112 (portlet template) calls template12 (e.g. control template ) calls template121 (portlet template) Something like that yes, although I was also playing with the idea of changing the portal OM, the control would become the display peer of a portlet thus completely hiding the portlet API from the rendering engine. This will allos to evolve the rendering/layout engine independently of the portlet API. I assume that would that also be WebMacro templates ? I like Webmacro :) Maybe we might do something similar based on JSPs also ... Definitely, the framework will be template system abstracted. -- Raphaël Luta - [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED] -- -- 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: Html and Wap portlets?
There is another way to support WAP and HTML. We use different PSML pages for different devices that are provided through a multi-device profiler (ultimately this will be the profiler David is implementing :) Our PSML pages contain references to the same multi-device portlets, e.g. we have a stock portlet and a weather portlet which can be used from WAP phones as well as PCs. They look at the preferred mime type to determine the output required by the device on a per-request basis. We intend to give back the improved WAP support required to make this work, see the proposal that we recently posted. We have finished coding of the improved WAP support already, currently we are testing it. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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
Raphael, it may be that some of your work impacts our work in the areas of WAP support and JSP template support. Can you provide a brief overview on these items ? - reworking the screens/layouts/navigations to use Webmacro - implementation of template support in portlets/portletcontrols/ portletcontrollers Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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
Raphael, thanks for the info. Would the template support in portlets/controls/controllers use nested invocation of templates like in the example below to avoid use of ECS for page generation ? template1 (e.g. controller template) calls template11 (e.g. control template ) calls template111 (portlet template) calls template112 (portlet template) calls template12 (e.g. control template ) calls template121 (portlet template) I assume that would that also be WebMacro templates ? Maybe we might do something similar based on JSPs also ... Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany Raphael Luta wrote: [EMAIL PROTECTED] wrote: Raphael, it may be that some of your work impacts our work in the areas of WAP support and JSP template support. Can you provide a brief overview on these items ? - reworking the screens/layouts/navigations to use Webmacro This is just implementing the screens awith Webmacro templates just like Ingo did with JSP templates so have users have their choice of templating system. - implementation of template support in portlets/portletcontrols/ portletcontrollers I'll send to the list a proposal as soon as I have time. -- Raphaël Luta - [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: Profiler Proposal
David, great proposal ! See comments below. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany Hi All, Below is a proposal for a Jetspeed Profiler Service. It is not final and your input is welcome. David ... --- Localized Resources Resource names can optionally be localized. This is done by suffixing the resource name. The suffix is made up of a required ISO-639 standard two-character language abbreviation, and an optional IS0-3166 standard two-character country code abbreviation. The suffix is of the format: _lc_cc where: lc = language code cc = country code Some examples groups/accounting/html/default_fr_FR.psml// french language, France groups/accounting/html/default_fr.psml // french language, any country For a given locale of fr_FR, the search order for the default accounting resource would be: groups/accounting/html/default_fr_FR.psml groups/accounting/html/default_fr.psml groups/accounting/html/default.psml The profiler will look at the "Content Language" HTML header for locale specific settings. If there are multiple settings, all settings will be searched until the first resource is found. Localization can be configured in the JetspeedResources.properties file. You can configure a default language. This language will be considered the default language and no prefix will be necessary for their resources. # only french belgium profiler.language.default=fr_BE # default language any spanish profiler.language.default=es # all resources must be suffixed profiler.language.default= To turn on/off all localization checking: profiler.default=true/false For a complete list of ISO-639 standard language abbreviations, see: http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt For a complete list of ISO-3166 standard country code abbreviations, see: http://userpage.chemie.fu-berlin.de/diverse/doc/ISO_3166.html It is a very good idea to support multi-linguality. Would it be possible to have URIs that explicitly specify the language, e.g. http://server/servlet/jetspeed/portal/group/sales/SalesCenter/fr_FR ? Accepting this and returning the language specified in the request would allow implementing portals where users can select the language and e.g. bookmark a page in a certain language. Problems might occur if user's change their language settings in the browser. This way, the user might apparently loose customizations he made to a language specific page. --- Device Explicit Resource Names Optionally, names can include the media type explicitly. http://host/servlet/jetspeed/portal/media-type/html/user/BenefitsPage In this case, the 'media-type' prefix must follow the portal prefix, and then the actual media type is specified. The above example explicitly asks for the html resource for the BenefitsPage, and explicitly for the current user. First the profiler will look for the media type in the resource name. If it is not specified there, it will then query the CapabilityMap. Good ! --- Default Media-Type and Fallback If a request is for a given media type, and the resource is not found for the given media type, then the profiler will fallback to a default resource if available. This default resource is assumed to work for all media types without a specific resource. The default media type resource should be placed in the root directory for a given user, role or group. --- Anonymous Access and Profiles The default resource shown to anonymous logons is configured with profiler.anon.directory setting. A device specific path could be set here, but probably should not so that Jetspeed can autodectect the media type. # Directory used for anonymous access profiler.anon.directory=/user/default/ The actual resource displayed is then dependent on media type, language, and the default resource markup filename. Profiles available to anonymous users are configured with: profiler.anon.profiles=/role/TennisNewUserProfile profiler.anon.profiles=/role/RugbyNewUserProfile profiler.anon.profiles=/role/BadmintonNewUserProfile These are not used directly by the default profiler, but could be used by applications to provide choices of profiles available to anonymous users. The roles must actually have their security setup correctly to work, meaning that access should be given to 'everyone' on these roles. --- Authorized Profiles When a user first signs up, they could be given a choice of profiles available author
Re: Caching
Cache(s) | +---+---+ | +-+--+ | | | +++ +-+---+ +++ |JetSpeed Instance| |JetSpeed Instance| ... |JetSpeed Instance| +-+ +-+ +-+ | | | +-+--+ | +-+ | Central |-User Info | User Database |-User PSMLs |(e.g. DB or LDAP)| +-+ JetSpeed running on a single machine (e.g. portal prototypes) - PSML object trees stored on individual JetSpeed servers - Content and Content feeds stored in file cache as files ++++ | Content Server || Content Server | +---+++---++ | | +--+--+ | Internet | +++ |File Cache | +-+ |JetSpeed Instance| +-+ | User Database | |(e.g. DB or LDAP)| +-+ Which other scenarios might exist ? Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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 Source Code or Documentation
Adam, source code for Turbine should be available at http://java.apache.org/turbine/. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany [EMAIL PROTECTED] on 20.11.2000 19:37:05 Please respond to "JetSpeed" [EMAIL PROTECTED] To: JetSpeed [EMAIL PROTECTED] cc: Subject: Turbine Source Code or Documentation Could someone tell me where to find the source code or documentation for the Turbine classes?? I am trying to look at the Jetspeed classes and do not know what many of the methods being used do. Also I am looking for methods to do certain things but do not know if they exist. For example: I am trying change the NewAccount.java file, and want to move the textfields around, but I do not know how I would do that. Or I would like to add a radio button or drop down list. Some examples or documentation would be very helpful. Thanks... -- -- 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] -- -- 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
data, it is possible to react on each request in a way that depends on the request, current state (transient state in the PortletSession, persistent state in the persistent store) and user identity. I'd like to propose that portlet refs should have their instantiation and lifetime declaritively controlled like beans in JSP that can have scope page/request/session/application. The scope is applied per Profile. ( Please feel free to shoot holes in this idea. Its fairly new ) I'm not sure what you mean here, can you explain this in more detail ? My assumption would be that a portlet ref exists from the point in time where it is added to a PSML by a customizer until it is removed by a customizer. Whenever the page that contains it is displayed, the references portlet is displayed using the parameters specified in the portlet ref (or in the future perhaps using parameters references from within the portlet ref). A portlet's init params in a PSML are loaded via the Profiler. TODO: how are the init params passed to each portlet for each PSML in regards to scoping. This should be done via a PersistenceService that should be an extension of the Portlet API (see the Portlet API outline that we recently checked in). TODO: better describe portlet scoping. What else... -- The ProfilerService is a Turbine service and is specified in the turbine properties file. But we would have a ProfilerService interface and a ServiceFactory in JetSpeed so that the JetSpeed implementation would not depend on Turbine, I assume. Is that what you intend ? Thats it for now. Im depending on your feedback, David Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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
We have implemented a custom user profiler that provides multi-page capability that we use to support multiple devices per user. It returns a PSML depending on the preferred MIME type of the capability associated with a request. To do this, we use a directory structure like this: \userid1\default.psml \userid1\default_wml.psml \userid1\default_voicexml.psml ... \userid2\default.psml \userid2\default_wml.psml \userid2\page1.psml \userid2\page2.psml ... All users have dafault pages that are shown when no explicit page name is provided in a request. Multiple default pages for different devices may exist. If a page name comes with the request, the user's page that matches the name is returned. Would that fit with the upcoming Profiler proposal ? Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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: Caching
Raphaël Luta wrote: There 3 issues, which IMO should be clearly separated in Jetspeed : I totally agree with that - we really have to differentiate between the different kinds of caching. It should be possible to configure different cache service implementations for these different kinds of caching. - the caching needs of the layout system for optimizing performance (mainly in memory resource and content caching). This should not care about remote URLs or content write access concurrency - resource content management and integrity preservation. This complex issue should be addressed by a dedicated content management system (I know at least 2 such OSS project: Prowler and Slide, both Apache or Apache compatible). Jetspeed should define a content management interface for plugging to these systems for handling complex cases and provide a simple content management implementation for the out-of-the-box evaluation purpose or small load sites. - syndication caching Can be thought of as an extension of the content management issue but has some specific issues (mainly managing relations with the syndicators). Those interested in exploring the full scope of syndication issues may have a look a the ICE specification... Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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: Scalability problem in PortletSetFactory ?
PSML ? Assume we have a page customizer and a user changes his page layout. Would the page customizer remove or update the PSML in the cache ? Or would the cache check whether the file has changed each time it is accessed ? The only disadvantage I see to the MRU is that it will use a little more memory under small load (because the pages will be persisted in the cache and not released). Once the MRU is full or nearly full, the behavior and cost associated to the MRU should be about the same that the cost associated to the session cache. Am I missing something here ? Behavior under small load does not worry me. I understand that there are other cases, where PSML files can be shared between users. Is the time consumed for parsing the PSML and generating the object tree that represents it or memory usage per session the problem that you see when using the session approach ? My main concern about using a session cache is that we're making a usage pattern asssumption which may not be true in some installations. I'd like the portal engine to be agnostic to usage pattern. The MRU cache relies on the assumption that it is advantageous to cache the n last recently used elements. If for example you have 1 users with custom pages, who request their home page every ten minutes (home page, read article, back to home page, read article, back to home page, read article, ...) you get a mean of 1000 requests for the home page per minute. If you have a MRU cache with a size of 11000 you're fine, if the MRU cache can store 9000 elements, it may happen that you only get cache misses all the time, because a user's PSML is always discarded just before the user would have accessed his home page again. We can have the best of both worlds if we add implements HttpSessionBindingListener to the PortletSetFactory object, store it both in the session and as a Singleton, and have configurable behaviour to destroy it when the session expires and the number of stored entries in the SingletonHolder is above a certain value (The servlet engine should unbind any objects in the Session when the session is invalidated). It also looks simple to implement in our current source base. The idea just came to me. What do you think? I see, we'd e.g. have a CacheService that would try to get the PSML from the session, if it would not yet be there it would try to get it from the SingletonHolder. When a session would expire, the reference counter for the particular object tree would be decreased and if it reaches 0, the object would be discarded... Sounds like a workable compromise between Raphaels requirements and mine... ... It seems the UserProfiler also does some caching. Would this mean we cache the PSML file in the DiskCache and the object tree that is generated from it in the MRU cache ? I don't think there is caching there. Only retrieval of the user PSML, passing through the (missnamed) JetspeedDiskCache. It should be called JetspeedResourceManagerService or something similar. The classes are rather small but I can have read them wrong. The caching is done by the fact the the PortletSetFactory for each PSML is a singleton, stored under the PSML url key. In some cases there is caching though. We have a setup where the user PSMLs are obtained from a remote LDAP server via a servlet that gets the PSML out of LDAP and retuens it via HTTP (i.e. we have a central server from which all portal servers get user info as required) In this case, the JetSpeedDiskCache seems to put the user PSML on the local disk. When the code is refactored, I will send a proposal to have the JetspeedDiskCache as a pluggable ResourceManager service, with API to retrieve, expire, get a Reader or a Writer on a resource, etc. handling parallel requests of the same resource. That should allow to implement a distributed implementation that consists of a HTTP proxy on a dedicated machine and code on each portal server that accesses URLs via this proxy. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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: editable portlets for release 1.2
Marcus, could you provide a brief overview of how the implementation of editable portlets you are working on works ? Which classes would be added to JetSpeed and which ones would have to be changed ? Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany "Schwarz, Marcus" wrote: Additionally we have added for each portlet some special tags inside of the registry, which are handling the related URLs: functions function name="maximize" urlhttp://finance.yahoo.com/url /function /functions here one can specify which URL should be called if the button is pushed. The current way to allways call the same URL for each portlet (OK, it's a dynamic one, but still...) is surely not enough. In the above approach you can dynamically e.g. call a configuration URL of the portlet. Another possibility is surely to put these information into the "parameters" area of a portlet-entry. That's a great idea. A PortletControl could definitely query all the available functions on a Portlet and add them to the control bar. Default functions could be registered in the PortletControl entry. Sample registry entries: portlet-entry ... functions function name="maximize" urlhttp://wherever//url /function !-- override the default behavior to remove the close option -- function name="close"/ function name="edit" urlmy_custom_edit//url /function /functions /portlet-entry portle-control .. functions function name="maximize" iconstd_maximize_icon/icon urlstd_maximize_dynamic_URL/url /function function name="close" iconstd_close_icon/icon urlstd_close_URL/url /function function name="edit" iconstd_edit_icon/icon urlstd_edit_URL/url /function /functions /portlet-control Did I understand correctly ? -- Raphaël Luta - [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED] -- -- 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]
Portlet API Requirements
I've made available a document summarizing the current list of requirements for the Portlet API at http://sda1.lotus.com/jetspeed/PortletAPI/PortletAPIRequirements.htm User id: area51 Password: dilbert If you want to add requirements to the list, please post a brief description and a rationale to this mailing list under the topic "Re: Portlet API Requirements". We will also make available JavaDocs that show our current ideas for the Portlet API on this server very soon. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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: Portlet API Requirements List
Raphael Luta wrote: [EMAIL PROTECTED] wrote: I volunteer to put together a Portlet API Requirements List that we can put on the web site. Please post your requirements to the JetSpeed list with the topic "Portlet API Requirements", and I'll include them in the document. I'm looking forward to your input :) Great. I've added some comments to some of your requirements in order to foster discussion and provide my own requirements at the end. - The Portlet API should allow for definition of service interfaces and for registration of services implementing particular service interfaces, e.g. - User info (for getting user info like name, address, age...) - Persistence (for storing per-user, per-portlet settings) - Location (for obtaining the user's location) - Personalization (for storing/getting personalization info) - Data (access to databases, schema-to-object mappings) - Content (access to syndicated content) - Cache (access to URLs via caches) - ... Rationale: This allows to have a stable API core that can be extended by services as required. Portals implementing the Portlet API can provide implementations for a subset of the services defined in the Portlet API. I'm not sure what you're saying there: You want the Portlet API to provide a service lookup interface. Yes. The definition of the real services interface would be external to the Portlet API. Yes, the idea is to have a Portlet API and a set of additional standard service interfaces for tasks like the ones listed above. No portal would be required to implement a given service. Correct ? Yes. Each portal could decide which subset of services it wants to provide and how they should be implemented. However, I expect a persistence service and user info service would be provided by virtually all portals, because they are necessary to allow portlets to store settings and obtain info about the user in a standard way. My own requirement not previously listed : - the Portlet API should allow only well-formed XML compliant output from the Portlet. Rationale: this would guarantee that the portal can always post-process the portlet output if needed and would prevent a portlet from breaking the display with a non well-formed output. You mean XML, WML, XHTML, VoiceXML would be ok, but HTML with missing end tags should not be generated ? Is this really a requirement to the API or rather a requirement for portlets to "behave well" by generating only well-formed XML ? It's the only one I can add right now. -- Raphaël Luta - [EMAIL PROTECTED] Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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: Scalability problem in PortletSetFactory ?
home page again. Optimization for a given pattern should be handled at a pluggable component level. I surely agree with that. We might have an MRUCache and a "SessionCache". We could let them implement the same interface to make them exchangeable. I guess we'd have to pass RunData to allow a cache implementation to put data in the session if required. A property may be used to determine which strategy to use. It would be ok to start with a MRU cache if it is possible to replace it with a "cache" that uses the session to store data when required. The Profiler component is currently responible for implementing the usage pattern, maybe we can add methods to the Profiler API to allow a profiler to provide caching hints for a cache system ? A hint might be "per-user", "per-group" or "global", perhaps. For per-user data, the "SessionCache" might be used, for per-group or global data the MRU cache. That would add some additional complexity, though. It seems the UserProfiler also does some caching. Would this mean we cache the PSML file in the DiskCache and the object tree that is generated from it in the MRU cache ? Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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]
Portlet API Requirements List
We had very good discussions about the Portlet API for future versions of JetSpeed. I think that we should start to compose a requirements list to gather the requirements for the API, listing a description and rationale for each requirement. I volunteer to put together a Portlet API Requirements List that we can put on the web site. Please post your requirements to the JetSpeed list with the topic "Portlet API Requirements", and I'll include them in the document. I'm looking forward to your input :) (my input) - The Portlet API should be a generic API that does not expose JetSpeed intrinsics or components used by JetSpeed. Rationale: This allows to implement the Portlet API on different bases, which is necessary to give the Portlet API the potential to become a standard. - The Portlet API should clearly separate data that exists per portal, per portlet, per user, per-user and per-portlet, per user session or per request. Rationale: This is required to implement the API and portlets that use it in a scalable and thread-safe way. - The Portlet API should be similar to the Servlet API - Portlet similar to Servlet - PortletConfig similar to ServletConfig - PortletContext similar to ServletContext - PortletRequest/Response similar to ServletRequest/ Response - ... Rationale: This will give all programmers who know servlets a quick start and lead to good acceptance of the API, increasing chances that it becomes a standard. - The Portlet API should allow for definition of service interfaces and for registration of services implementing particular service interfaces, e.g. - User info (for getting user info like name, address, age...) - Persistence (for storing per-user, per-portlet settings) - Location (for obtaining the user's location) - Personalization (for storing/getting personalization info) - Data (access to databases, schema-to-object mappings) - Content (access to syndicated content) - Cache (access to URLs via caches) - ... Rationale: This allows to have a stable API core that can be extended by services as required. Portals implementing the Portlet API can provide implementations for a subset of the services defined in the Portlet API. - The Portlet API should be flexible enough to allow for rendering using different technologies (e.g. JSPs, XML/XSL...) as well as different mark-up (e.g. XML, WML, XHTML, HTML, VoiceXML, ...). Rationale: This allows to implement portlets that can support various devices, either by doing final rendering or by producing XML that can be further processed. - The Portlet API should provide abstract base classes for portlets. Rationale: This allows for quick implementation of portlets by only overwriting the relevant methods. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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: FW: AW: [Proposal] Jetspeed: release and work plan
I followed the discussion on use of Turbine and Cocoon 2 for future versions of JetSpeed. I tried to find some architecture and design info on Cocoon 2. At Google, I found http://java.apache.org/cocoon/cocoon2.html, but this document does not provide in depth information. Does anybody have a hint on where more information may be available on the web ? Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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: Scalability problem in PortletSetFactory ?
This will require that expired sessions are stored in database, having a special cookie value as the id, to be recovered later when the user comes back. This would allow to have two kind of sessions: - New sessions (Current default user) - Anonymous sessions (The system remembers you, even if it does not know who you are. It requires checking for a cookie, retrieving the persistent data, and storing the cookie back. You would have the default user rights, with your customisations to content and layout. If you log in from a different machine, you are a new user and your psml is not restored.) - User sessions (The system remembers you, knowing extra data about you. You can log in from different machines and have your preferences restored.) Thoughts or preferences on this? Technically, this is a brilliant idea, but users may think they had customized the portal after the cookie-based customization and may think the customization has been lost when using a different machine (if they are not web programmers like us ;) The alternative - registering and signing in before customization - would avoid that problem entirely. Users easily remain "de-facto anonymous" if they only provide a fantasy id and password when registring. Many portals only exist to make users register and get data for targeted ads to be displayed within the portal. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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]
Portlet Editing
During the last weeks there was some discussion on a generic Portlet Editing capability for JetSpeed. Is somebody currently working in this area or planning to start ? Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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]
Scalability problem in PortletSetFactory ?
There seems to be a scalability problem in the PortletSetFactory: For each user, a PortletSetFactory object is created that holds a Portlets tree representing the user's PSML file. I guess the tree can become quite big in terms of memory usage. The PortletSetFactory object is stored in the SingletonHolder and apparently is never removed. If the number of users is large, the memory of the server may be used up after running for some time. Is there a particular reason for not putting the PortletSetFactory object into the HttpSession ? This would allow the JVM to garbage-collect the PortletSetFactory and the referenced Portlets tree after the HTTP session expires. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- 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]
SecurityManager - work in progress ?
The following class seems to be used nowhere in JetSpeed. Is this work in
progress ?
/**
Handles
@author a href="mailto:[EMAIL PROTECTED]"Kevin A. Burton/a
@version $Id: SecurityManager.java,v 1.3 2000/11/06 12:53:37 sgala Exp $
*/
public class SecurityManager {
public static void checkAccess( PortletEntry entry, User user ) throws
SecurityException {
}
}
Best regards,
Thomas
Thomas Schaeck
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED]
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany
--
--
Please read the FAQ! http://java.apache.org/faq/
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: http://java.apache.org/main/mail.html
Problems?: [EMAIL PROTECTED]
Re: Portlet API
e PortletResponse as recipient of the Portlet markup, whereas in the XMLPortlet case, the Portal may either register itself as the ContentHandler for the build() output if it knows how to deal with the data markup or else pipe the events back to the XMLPortlet for rendering. I'm not sure how exactly this works ... Could you post a little example that shows how an XMLPortlet would generate an HTML page with some XML data and how it would output the XML data ? Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: Portlet API
nistrator. This will allow to easily adapt a component customization policy based on a site-wide policy. I think this discussion is very interesting, mainly because we have 2 different point of views of the issue: you're dealing with it from the portlet developper perspective, I'm mainly considering the portal administrator point of view. Comments most welcome. As I understand, your proposal would be a Portlet Definition Markup Language (PDML) that allows to specify - Portlet class file - Portlet title and description - Services required by the portlet - Capabilities required by the portlet - Parameter descriptions including name, type, description, defaults, choices, and roles that allow editing/viewing. The PDML would be processed by a customization engine that uses the PDML param entries to create a form, sends it to the user's browser, receives the post request from the form and stores the settings. Very interesting ! With such a PDML it sould be possible to deploy portlets by providing a jar file with the code and a PDML file to the portal. The portal would process the PDML, install the code, and create the required admin and user forms for the parameters defined for the particular roles in the PDML. More complex portlets would have jar files that e.g. contain their own specific JSPs and appropriate logic for customization. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: Portlet API
(Seems this mail did not get delivered, I hope you don't receive it twice) It's good to see such a positive reaction on my first note about the need for a standard Portlet API and that such a live discussion started. I guess we should go into more detail now. The figure below shows a portal that provides a Portlet API for portlets to make them independent of any specifics of the portal implementation (e.g. Turbine, ECS, Cocoon, for JetSpeed or something else for other portals). DB EJBs SOAP XML XML XML ||| | | | JSPs/Servlets Cocoon || +---++---+ |Portlet| ... |Portlet| +==+ | Portlet API| +==+ ++ +-+ DB --+ Persistence Service| | Location Service | ++ +-+ | Portal Framework | ++ +-+ LDAP-+ User Data Service | | Device Info Service | | ++ +-+ | +--+ | | Rendering Engine| | | WML | HTML | VoiceXML | CHTML | ...| - User PSML | +--+--+--+---+-+ | | Capability Detection/Rendering Selection | | +--+ +-|Authentication| +--+ /\ || || \/ Request Response We envision a standard Portlet API similar to the Servlet API, providing amongst others the following interfaces: - Portlet is used by the framework to invoke the portlet. Every portlet has to implement this interface. - PortletRequest encapsulates the request to the portlet. It provides access to parameters/attributes, locator and client information, etc. - PortletResponse encapsulates the response to the portlet. - PortletConfig provides the portlet with config info used by the portlet as well as the framework to render the content. - PortletContext provides the portlet with access to the framework's services. The context allows the portlet to store/retrieve information and access information that the portlet requires to render itself. - UserProfile provides access to the user data. - Client represents the user's client device. It provides methods to get manufacturer, model, user agent and check for capabilities. - Locator provides methods to determine the current location of a user's device, e.g. longitude/latitude, country, state, city, ZIP code. This is a preliminary, not-yet-complete list that we post to get early feedback from the JetSpeed community. Please let us know your comments! We also plan to submit a more detailled proposal soon. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: Source Code for Configurable ServletInvokerPortlet
Santiago,
thanks for fixing the little second/millisecond bug so quickly.
+1 on having this kind of examples for helping to handle legacy webapps.
But the servlet should not be printing HTML, HEAD, and BODY tags, just the
HTML
fragments. Also, it should possibly check the getContentType() call, and
deliver
HTML or WML as requested by the Portlet. But this last thing is not that
important,
as the current psml allows to specify mime types in the registry.
I just posted the serlvet as an example for a legacy servlet; HTML, HEAD
and BODY
tags were in there to verify that the portlet actually works for legacy
servlets
that return complete HTML pages. Netscape and IE seem to ignore the HTML,
HEAD and
BODY tags when they appear in a table, so it worked.
Extending the request info servlet to also support WML is a nice idea, so I
just
did it (see below). I also commented out the surrounding tags so that the
servlet
now returns fragments suitable for inclusion in portlets.
Also, we should point people using it that it is not the way to go for new
development, just a way to get this servlet you had written before
displayed in a
portlet.
Right, usually content should be rendered by the portlet, e.g. by invoking
a JSP or
executing a stylesheet. We are currently also working on support of
JSPs/servlets
through the Portlet API, we plan to submit a proposal for discussion soon.
snip
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
/**
* This example servlet returns some information about the incoming
request.
*
* @author Thomas Schaeck ([EMAIL PROTECTED])
*/
public class RequestInfoServlet extends HttpServlet
{
public void doGet (HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
if (req.getHeader("accept").indexOf("text/vnd.wap.wml") != -1) {
generateWML(req, res);
// add additional content types here
} else {
// default to HTML
generateHTML(req, res);
}
}
public void generateHTML(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
PrintWriter out;
res.setContentType("text/html");
out = res.getWriter ();
// Uncomment this tp obtain a valid HTML document
//out.println("HTMLHEADTITLERequest Info
Servlet/TITLE/HEADBODY BGCOLOR=\"#EE\"");
out.println("h4Request Information:/h4");
out.println("TABLE Border=\"2\" WIDTH=\"65%\" BGCOLOR=\"#FF\"");
out.println("trtdRemote user/tdtd" + req.getRemoteUser() +
"/td/tr");
out.println("trtdRemote address/tdtd" + req.getRemoteAddr() +
"/td/tr");
out.println("trtdRemote host/tdtd" + req.getRemoteHost() +
"/td/tr");
out.println("/tableBRBR");
Enumeration e = req.getHeaderNames();
if (e.hasMoreElements()) {
out.println("h4Request headers:/h4");
out.println("TABLE Border=\"2\" WIDTH=\"65%\"
BGCOLOR=\"#FF\"");
while (e.hasMoreElements()) {
String name = (String)e.nextElement();
out.println("trtd" + name + "/tdtd" + req.getHeader(name) +
"/td/tr");
}
out.println("/tableBRBR");
}
e = req.getParameterNames();
if (e.hasMoreElements()) {
out.println("h4Servlet parameters:/h4");
out.println("TABLE Border=\"2\" WIDTH=\"65%\"
BGCOLOR=\"#FF\"");
while (e.hasMoreElements()) {
String name = (String)e.nextElement();
out.println("trtd" + name + "/tdtd" +
req.getParameter(name) + "/td/tr");
}
out.println("/tableBRBR");
}
HttpSession session = req.getSession(false);
if (session != null) {
out.println("h4Session information:/h4");
out.println("TABLE Border=\"2\" WIDTH=\"65%\"
BGCOLOR=\"#FF\"");
out.println("trtdSession ID/tdtd" + session.getId());
out.println("trtdLast accessed time/tdtd" + new
Date(session.getLastAccessedTime()).toString() + "/td/tr");
out.println("trtdCreation time/tdtd" + new
Date(session.getCreationTime()).toString() + "/td/tr");
String mechanism = "unknown";
if (req.isRequestedSessionIdFromCookie()) {
mechanism = "cookie";
} else if (req.isRequestedSessionIdFromURL()) {
mechanism = "url-encoding";
}
out.println("Session-tracking mechanism" + mechanism);
out.println("/tableBRBR");
String[] vals = session.getValueNames();
if (vals != null) {
out.println("h4Session values/h4");
ou
Re: Source Code for Configurable ServletInvokerPortlet
Santiago,
thanks for fixing the little second/millisecond bug so quickly.
+1 on having this kind of examples for helping to handle legacy webapps.
But the servlet should not be printing HTML, HEAD, and BODY tags, just the
HTML
fragments. Also, it should possibly check the getContentType() call, and
deliver
HTML or WML as requested by the Portlet. But this last thing is not that
important,
as the current psml allows to specify mime types in the registry.
Extending the request info servlet to also support WML is a nice idea, so I
did it
(see below). I also commented out the surrounding tags so that the servlet
now returns fragments suitable for inclusion in portlets.
Also, we should point people using it that it is not the way to go for new
development, just a way to get this servlet you had written before
displayed in a
portlet.
Right, usually content should be rendered by the portlet, e.g. by invoking
a JSP or
executing a stylesheet. We are currently also working on support of
JSPs/servlets
through the Portlet API, we plan to submit a proposal for discussion soon.
snip
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
/**
* This example servlet returns some information about the incoming
request.
*
* @author Thomas Schaeck ([EMAIL PROTECTED])
*/
public class RequestInfoServlet extends HttpServlet
{
public void doGet (HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
if (req.getHeader("accept").indexOf("text/vnd.wap.wml") != -1) {
generateWML(req, res);
// add additional content types here
} else {
// default to HTML
generateHTML(req, res);
}
}
public void generateHTML(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
PrintWriter out;
res.setContentType("text/html");
out = res.getWriter ();
// Uncomment this tp obtain a valid HTML document
//out.println("HTMLHEADTITLERequest Info
Servlet/TITLE/HEADBODY BGCOLOR=\"#EE\"");
out.println("h4Request Information:/h4");
out.println("TABLE Border=\"2\" WIDTH=\"65%\" BGCOLOR=\"#FF\"");
out.println("trtdRemote user/tdtd" + req.getRemoteUser() +
"/td/tr");
out.println("trtdRemote address/tdtd" + req.getRemoteAddr() +
"/td/tr");
out.println("trtdRemote host/tdtd" + req.getRemoteHost() +
"/td/tr");
out.println("/tableBRBR");
Enumeration e = req.getHeaderNames();
if (e.hasMoreElements()) {
out.println("h4Request headers:/h4");
out.println("TABLE Border=\"2\" WIDTH=\"65%\"
BGCOLOR=\"#FF\"");
while (e.hasMoreElements()) {
String name = (String)e.nextElement();
out.println("trtd" + name + "/tdtd" + req.getHeader(name) +
"/td/tr");
}
out.println("/tableBRBR");
}
e = req.getParameterNames();
if (e.hasMoreElements()) {
out.println("h4Servlet parameters:/h4");
out.println("TABLE Border=\"2\" WIDTH=\"65%\"
BGCOLOR=\"#FF\"");
while (e.hasMoreElements()) {
String name = (String)e.nextElement();
out.println("trtd" + name + "/tdtd" +
req.getParameter(name) + "/td/tr");
}
out.println("/tableBRBR");
}
HttpSession session = req.getSession(false);
if (session != null) {
out.println("h4Session information:/h4");
out.println("TABLE Border=\"2\" WIDTH=\"65%\"
BGCOLOR=\"#FF\"");
out.println("trtdSession ID/tdtd" + session.getId());
out.println("trtdLast accessed time/tdtd" + new
Date(session.getLastAccessedTime()).toString() + "/td/tr");
out.println("trtdCreation time/tdtd" + new
Date(session.getCreationTime()).toString() + "/td/tr");
String mechanism = "unknown";
if (req.isRequestedSessionIdFromCookie()) {
mechanism = "cookie";
} else if (req.isRequestedSessionIdFromURL()) {
mechanism = "url-encoding";
}
out.println("Session-tracking mechanism" + mechanism);
out.println("/tableBRBR");
String[] vals = session.getValueNames();
if (vals != null) {
out.println("h4Session values/h4");
out.println("TABLE Border=\"2\" WIDTH=\"65%\"
BGCOLOR=\"#FF\"");
for (int i=0; ivals.length; i++) {
String name = vals[i];
out.println("trtd" + name + "/tdtd" +
session.getValue(name) + "/td/tr");
Source Code for Configurable ServletInvokerPortlet
I've written a configurable ServletInvokerPortlet that invokes
servlets/JSPs.
(It uses the workaround for embedding JSPs in ECS trees recently posted
by Christian Sell, see EcsServletElement.)
Maybe this is useful for others as well:
The URL of the servlet to be invoked can be set by specifying a parameter
named "url" in the portlet entry in the portlet registry section in the
file "jetspeed-config.jcfg":
snip
portlet-entry type="abstract" name="ServletInvokerPortlet"
classnameorg.apache.jetspeed.portal.portlets.ServletInvokerPortlet/classname
/portlet-entry
portlet-entry type="ref" parent="ServletInvokerPortlet"
name="RequestInfoPortlet"
parameter name="url" value="/RequestInfo/"/
meta-info
titleRequest Info/title
descriptionThis portlet shows some request info./description
/meta-info
/portlet-entry
snap
The example defines a portlet named "RequestInfoPortlet" that invokes a
servlet
accessible under the URL "/RequestInfo/" whenever it is displayed.
The entry in default.psml or a personal psml file may look like this:
...
entry type="ref" parent="RequestInfoPortlet"
layout position="1"/
/entry
...
This is the source for the ServletInvokerPortlet:
snip
package org.apache.jetspeed.portal.portlets;
import org.apache.ecs.ConcreteElement;
import org.apache.ecs.ElementContainer;
import org.apache.ecs.StringElement;
import org.apache.jetspeed.portal.*;
import org.apache.jetspeed.util.*;
import org.apache.turbine.util.*;
import org.apache.jetspeed.portal.portlets.AbstractPortlet;
import org.apache.jetspeed.util.servlet.EcsServletElement;
/**
* The ServletInvokerPortlet invokes a servlet or JSP and displays the
result.
*
* @author Thomas Schaeck ([EMAIL PROTECTED])
*/
public class ServletInvokerPortlet extends AbstractPortlet {
/**
* Returns an ECS concrete element that includes the servlet/JSP.
*
* The servlet/JSP will be invoked when the ECS tree is written
* to the servlet output stream and add its output to the stream.
*/
public ConcreteElement getContent() {
// --
// Note: Rundata should not be obtained from the portlet config,
// but I found no other way to get it in the current JetSpeed version
// (as of 10/30/200). Normally, this should be per-request info, not
// per-portlet config info. If a new request comes in before this code
// is reached and the rundata in the portlet config is overwritten,
// we might get the wrong request here.
// --
RunData rundata = this.getPortletConfig().getRunData();
PortletConfig pc = this.getPortletConfig();
String servletURL = null;
try {
servletURL = (String)
this.getPortletConfig().getInitParameter("url");
return new EcsServletElement(rundata, servletURL);
} catch (Exception e) {
String message = "ServletInvokerPortlet: Error invoking "
+ servletURL + ": " + e.getMessage();
Log.error(message, e);
return new StringElement(message);
}
}
}
snap
Here is a modified version of the code originally posted by Christian Sell.
snip
package org.apache.jetspeed.util.servlet;
import java.io.IOException;
import java.io.OutputStream;
import java.io.PrintWriter;
import java.io.OutputStreamWriter;
import javax.servlet.*;
import org.apache.turbine.util.RunData;
import org.apache.turbine.util.Log;
import org.apache.ecs.ConcreteElement;
import org.apache.ecs.Element;
/**
* EcsServletElement encapsulates a servlet/JSP within the context of ECS
* HTML-generation.
*
* This is a workaround to allow invoking servlets from JetSpeed Portlets.
* The servlet will be invoked when traversal of an ECS tree during writing
* reaches the EcsServlet element.
*
* This is a modified version of Christian Sell's original code.
*/
public class EcsServletElement extends ConcreteElement
{
/** RunData object to obtain HttpServletRequest/Response from. */
private RunData rundata;
/** URL of servlet to include */
private String url;
/**
* Construct an ECS element from a given rundata object and URL.
*
* @param rundata Rundata object that holds the
HttpServletRequest/Response
*objects to be used for servlet invocation.
* @param url The URL of the servlet to invoke.
*/
public EcsServletElement(RunData rundata, String urlString) {
this.url = urlString;
this.rundata = rundata;
}
public void output(OutputStream out) {
output(new PrintWriter(out));
}
/**
* Add element to the designated PrintWriter.
*/
public void output(PrintWriter out) {
ServletContext ctx = rundat
Little Bug
Kevin, in the method org.apache.jetspeed.turbine.screens.Home.getPSMLContent there is a log statement that prints the time per request in seconds. On a fast PC I get 0 s for all requests as the code does a /1000. You may want to change this to print out the elapsed time in milliseconds. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: ApacheCon Jetspeed talks
I read the mails that followed ApacheCon with a lot of interest; unfortunately other obligations prevented me from being there. After working on a portal project for a while with my team, I'd like to share some of our ideas. We see a big need for a standard Portlet API for Java that enables application developers to implement portlets that are independent of the underlying infrastructure. The Portlet API should provide standard interfaces, e.g. for tasks like accessing user info, storing/retrieving per-user per-portlet settings, accessing session info, accessing location info, etc. It has to provide good support for personalization of portlets. The Portlet API needs to be flexible enough to support different technologies (e.g. JSPs/servlets, XML/stylesheets) to generate portlet content. We'd like to evolve JetSpeed's portlet API in this direction and provide a portlet programmer's guide to give portlet developers a quick start. As we are working in the pervasive computing space, we have to deal with different devices like PCs, WAP phones, normal phones and PDAs. This results in the need for support of mark-up languages like HTML and WML now, VoiceXML in the near future. We'd like to enable JetSpeed to compose pages from portlets for all the above devices. We also want to enable multi-page support, so that a user e.g. can have a personalized page to be shown when using a PC and another one to be shown when using a WAP phone, with a different set of portlets. Efficient and convenient handling of XML is very important. I'm really curious about Raphaël's proposal... Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: iCalendar
Eva, you can download Turbine from this URL: http://java.apache.org/turbine/index.html Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany [EMAIL PROTECTED] (Eva Codina Sanuy) on 27.10.2000 08:59:21 Please respond to "JetSpeed" [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: iCalendar Hi, I am trying to implement a Calendar service and I would like to use the classes of icalendar in jetspeed. Can anybody tell me if is it possible ?? I think I will need Turbine as well. Where can I download it ?? Thank you, Eva -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: A stock ticker in Jetspeed?
You can find info on use of stock info at Yahoo! at http://help.yahoo.com/help/fin/fin-03.html . The most important statement that Yahoo! makes here is "Any redistribution of quotes data displayed on Yahoo is strictly prohibited, but you are welcome to add links to Yahoo quotes from web pages you are creating. " Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany [EMAIL PROTECTED] (Kevin A. Burton) on 26.10.2000 14:23:36 Please respond to "JetSpeed" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] cc: Subject: Re: A stock ticker in Jetspeed? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 "Neeme Praks" [EMAIL PROTECTED] writes: well I have dealt with this problem and you can get tickers from yahoo site in quite good format: use URL http://finance.yahoo.com/d/quotes.csv?f=sl1d1t1c1ohgve=.csv and for each symbol you want to get a quote for, add "s" parameter. For example: http://finance.yahoo.com/d/quotes.csv?f=sl1d1t1c1ohgve=.csvs=MSFTs=SUNW would retrieve the quotes of Microsoft (MSFT) and Sun (SUNW). The format of the output is comma delimited list with the following fields: ticker, last close, date, time, change, open, high, low, volume I have experienced that sometimes their data is not very correct and not up to date, but most of the time it is quite ok. Maybe helps you... snip (sorry about the dated reply) Holy *hit! Where did you find that? I am sure that would almost certainly violate their licensing with NASDAQ/NYSE :). They probably put it out there so that their browser 'companions' (MSIE plugins) can grab the data. Excite@Home did something similar for their client (when I was there) but we used a somewhat decent auth mechanism.. Kevin - -- Kevin A Burton ([EMAIL PROTECTED], [EMAIL PROTECTED], UIN: 73488596) To fight and conquer in all your battles is not supreme excellence; supreme excellence consists in breaking the enemy's resistance without fighting. - Sun Tzu, 300 B.C. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE5+CJIAwM6xb2dfE0RAmLfAJ9Sz1Ug+d/m6OjbEEfJgRmz2C4UsgCbBxKt NjRLQnE50FJizSUcL3tLbCA= =8tO4 -END PGP SIGNATURE- Ortega Serbian Qaddafi Nazi security Treasury AK-47 Khaddafi Peking plutonium Saddam Hussein munitions World Trade Center cracking Mossad -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: JSP portlet
How to use JSPs within Jetspeed is a very relevant question. I can
imagine the following "workaround" to use JSPs together with ECS:
You could write a class that implements the interface HTTPServletResponse
and uses an output stream that writes to a buffer. You may get the content
out of the buffer after invocation of the JSP and put it into an ECS
concrete element that you return.
Whether this approach works may depend on the application server you're
using. Some app servers may require their particular HTTPServletResponse
implementations to be passed as second parameter of the include-method,
in this case this workaround wouldn't work and you'd get a class cast
exception when the servlet engine tries to cast your class to the
expected servlet-engine specific class.
To really allow for good integration of servlets or JSPs,the portal
page generation mechanism needs to follow the servlet paradigm:
Each component would have a service method and would sequentially call
the service methods of all its sub-components. During traversal of the
component tree, all markup elements would be written to the servlet
output stream of the response that gets passed through from component
to component. The following example shows how this works:
component1.service(req,rsp)
writes "TABLE"
calls component11.service(req,rsp)
- writes "TABLE"
- calls portlet111.service(req,rsp)
-- writes "TABLE ... portlet 111 markup ... /TABLE"
- calls portlet112.service(req,rsp)
-- writes "TABLE ... portlet 112 markup ... /TABLE"
- writes "/TABLE"
calls component12.service(req,rsp)
- writes "TABLE"
- calls portlet121.service(req,rsp)
-- writes "TABLE ... portlet 121 markup ... /TABLE"
- writes "/TABLE"
writes "/TABLE"
Using an ECS-portlet with stream-based page aggregation like described
above works like this: The service-method would get the content from
the ECS portlet and let the ECS tree write itself to the servlet output
stream of the response object.
Best regards,
Thomas
Thomas Schaeck
Pervasive Computing Division
Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED]
Address: IBM Deutschland Entwicklung GmbH,
Schoenaicher Str. 220, 71032 Boeblingen, Germany
"David Sean Taylor" [EMAIL PROTECTED] on 24.10.2000 20:25:41
Please respond to "JetSpeed" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: JSP portlet
Im trying to write a JspPortlet.
My approach is flawed, and Im wondering if anyone else has discovered a way
for this to work.
Im using a RequestDispatcher, and the problem is that the JSP writes its
output directly to the Response
So the JSP output cannot be incorporated into ECS since (i believe) ECS
must
render its entire element tree before setting it into the response
Has anyone ever 'redirected' the output of another servlet (.i.e. JSP) and
found a way to take this output
and put it into ECS, which is not flushed to the Response until the
complete
ECS elements are rendered.
Here's the code from my JspPortlet implementation:
public ConcreteElement getContent() {
RunData rundata = this.getPortletConfig().getRunData();
PortletConfig pc = this.getPortletConfig();
String url = "/jsp/dates/date.jsp";
String myContent = null;
try {
String jspOutput = null;
ServletContext ctx = rundata.getServletContext();
RequestDispatcher dispatcher = ctx.getRequestDispatcher(url);
try
{
//rundata.getOut().flush();
// include the JSP
dispatcher.include( rundata.getRequest(),
rundata.getResponse() );
} catch (Exception e) {
String message = "JSPPortlet: Could not include the following
URL: " + url + " : " + e.getMessage();
Log.error( message, e );
return new StringElement( message );
}
ElementContainer content = new ElementContainer();
// there is nothing to add to ecs since dispatcher.include() has
already
written into the response
--
--
Please read the FAQ! http://java.apache.org/faq/
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: http://java.apache.org/main/mail.html
Problems?: [EMAIL PROTECTED]
--
--
Please read the FAQ! http://java.apache.org/faq/
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: http://java.apache.org/main/mail.html
Problems?: [EMAIL PROTECTED]
JetSpeed on IBM WebSphere Application Server 3.52
Hi, there's news for those who run JetSpeed on WebSphere: Fix pack 2 is now available at http://www-4.ibm.com/software/webservers/appserv/efix.html . The fix pack includes support of the Java Servlet API 2.2 and Xalan/Xerxes. After installing the fix pack, I observed that JetSpeed performed much better than before. We'll soon post a JetSpeed install guide for WebSphere App Server 3.52. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division e-mail: [EMAIL PROTECTED] Phone: +49-(0)7031-16-3479 -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
