hey folks. i'm trying to put a hook into the jetspeed login process:
i'd like to tweak the file responsible for responding to the login.html, to
load a different outer frame for different users, but i can't tell where the
login message is going. help?
-bml
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 29, 2001 11:00 PM
> To: JetSpeed
> Subject: JetSpeed #385 - 01/29/01
>
>
> JetSpeed #385 - Monday, January 29, 2001
>
> Jetspeed Daily Build Results - Sun, 28 Jan 2001 20:16:56 GMT
> by "Jon S.Stevens" <[EMAIL PROTECTED]>
> Re: JetspeedJspPage error
> by "ingo schuster" <[EMAIL PROTECTED]>
> RE: New Profiler
> by "David Sean Taylor" <[EMAIL PROTECTED]>
> Re: Service initialization (WAS: Couldn't process
> URL:/ocs/local.ocs)
> by "Santiago Gala" <[EMAIL PROTECTED]>
> Re: Service initialization (WAS: Couldn't processURL:
> /ocs/local.ocs)
> by "Santiago Gala" <[EMAIL PROTECTED]>
> Re: [long] Layout system, part 2: functional description
> by <[EMAIL PROTECTED]>
> Navigation inside Portlets
> by "Mirko Buholzer" <[EMAIL PROTECTED]>
> FW: JetspeedPersistenceService.java
> by "Jon Stevens" <[EMAIL PROTECTED]>
> Re: Service initialization (WAS: Couldn't processURL:
> /ocs/local.ocs)
> by "Jon Stevens" <[EMAIL PROTECTED]>
> WebPagePortlet
> by "Ingo Rammer" <[EMAIL PROTECTED]>
> RE: JetspeedPersistenceService.java
> by "David Sean Taylor" <[EMAIL PROTECTED]>
> Re: Fwd: iCal
> by "Jeff Prickett" <[EMAIL PROTECTED]>
> RE: WebPagePortlet
> by "David Sean Taylor" <[EMAIL PROTECTED]>
> Re: WebPagePortlet
> by "Jon Stevens" <[EMAIL PROTECTED]>
> Re: JetspeedPersistenceService.java
> by "Jon Stevens" <[EMAIL PROTECTED]>
> AW: WebPagePortlet
> by "Ingo Rammer" <[EMAIL PROTECTED]>
> RE: WebPagePortlet
> by "Craig Berry" <[EMAIL PROTECTED]>
> RE: JetspeedPersistenceService.java
> by "David Sean Taylor" <[EMAIL PROTECTED]>
> Re: WebPagePortlet
> by "Ingo Rammer" <[EMAIL PROTECTED]>
> RE: WebPagePortlet
> by "Craig Berry" <[EMAIL PROTECTED]>
> Re: WebPagePortlet
> by "Jon Stevens" <[EMAIL PROTECTED]>
> Re: JetspeedJspPage error
> by "Michael Sallman" <[EMAIL PROTECTED]>
>
>
> ----------------------------------------------------------------------
>
> Subject: Jetspeed Daily Build Results - Sun, 28 Jan 2001 20:16:56 GMT
> From: "Jon S.Stevens" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 00:00:11 -0800 (PST)
>
>
> ----------------------------------------------------
> This email is autogenerated from the output from:
> <http://oss.software.ibm.com/developerworks/opensource/jakarta
> /proto/jetspeed.html>
> ----------------------------------------------------
>
>
> Buildfile: build\build.xml
>
> prepare:
>
> apis:
> [java] -- Suppressing non fatal warnings.
> [java] -- Suppressing non fatal warnings.
> [java] -- Suppressing non fatal warnings.
> [java] -- Suppressing non fatal warnings.
>
> core:
> [mkdir] Created dir: D:\jakarta\jetspeed\bin
> [mkdir] Created dir: D:\jakarta\jetspeed\bin\classes
> [echo] Compiling in ../src/java and saving to ../bin/classes
> [javac] Compiling 318 source files to
> D:\jakarta\jetspeed\bin\classes
> [javac] Note: 44 files use or override a deprecated API.
> Recompile with "-deprecation" for details.
> [javac] 1 warning
>
> dist:
> [jar] Building jar: D:\jakarta\jetspeed\bin\Jetspeed.jar
>
> BUILD SUCCESSFUL
>
> Total time: 52 seconds
>
> ----------------------------------------------------------------------
>
> Subject: Re: JetspeedJspPage error
> From: "ingo schuster" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 09:22:09 +0100
>
> At 18:49 01/27/01, msallman wrote:
> >Just an FYI,
> >
> >I just downloaded the latest stuff from cvs and built the war.
> >I got this error accessing the home page:
> >
> >Horrible Exception: java.lang.ClassNotFoundException:
> Requested Page not
> >found: JetspeedJspPage at
> >org.apache.turbine.modules.PageLoader.getInstance(PageLoader.
> java:166)
> >at org.apache.turbine.modules.PageLoader.exec(PageLoader.java:122) at
> >etc......
> >
> >In TurbineResources.properties:
> >page.default=JetspeedJspPage (which doesn't seem to exist (yet??))
>
> It does exist - however it's in a new directory. Try a clean
> checkout or
> make sure to checkout new directories during update.
>
> ingo.
>
>
> >Using page.default=DefaultPage seems to work.
> >
> >
> >Mike
> >
> >
> >
> >--
> >--------------------------------------------------------------
> >To subscribe: [EMAIL PROTECTED]
> >To unsubscribe: [EMAIL PROTECTED]
> >Search: <http://www.mail-archive.com/[email protected]/>
> >List Help?: [EMAIL PROTECTED]
>
>
> ----------------------------------------------------------------------
>
> Subject: RE: New Profiler
> From: "David Sean Taylor" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 00:56:47 -0800
>
> Santiago,
>
> I've checked in the new profiler integration for:
> - Customizer
> - Persistence Service
>
> I didn't write the ProfileFactory. No use writing it twice, since you
> already have one.
> Please check it in when you get a chance then I will update
> everything to
> use it.
> Also please check in the SessionCachedProfile, I can begin
> testing with it
> this week.
> Do you think the SessionCachedProfile should be the default jetspeed
> profile?
>
> Im still working on the customizer integration, it seems to
> work with HTML,
> but not WML.
> Anyway this will give you a chance to test it now.
>
> In order to test the new profiler, get the latest jr.p, and set
> services.ProfileManager.enable to 'true'
> It is currently set to false.
> (this is only temporary until this stabilizes)
>
> services.ProfileManager.enable=true
>
>
> Still some problems that Im aware of:
>
> -- when you create a new user, the Profiler needs to create a
> directory for
> that user
> -- the goback button from 'fullscreen' mode on non-default or
> group pages
> goes back to the default page
> -- WML does not store, and there may be a problem in general
> with storing to
> a file if its not there.
>
> i have some example of pages for groups and non-default
> pages. i will try to
> check those in later this week
> i also have example of the persistence service.
> It works fine, im storing the min/max session state of
> portlets amongst
> other specific stuff for my project, so it may not be useful to you,
>
> David
>
>
> ----------------------------------------------------------------------
>
> Subject: Re: Service initialization (WAS: Couldn't process
> URL:/ocs/local.ocs)
> From: "Santiago Gala" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 11:02:58 +0100
>
> Raphaël Luta escribió:
> >
> > [Rafal, I copy this message to you because I don't know if
> you are on the
> > Jetspeed list and this is Services related]
> >
> > Santiago Gala wrote:
> > >
> > > I think I found it. I will try to summarise, as an
> opportunity to get
> > > corrected if I make some error in my reasoning.
> > >
> > > The problem is with the sequence of initialization of services.
> > >
> > > Turbine provides two "rounds" of initialization for
> services. In the
> > > first round, services get called with a ServletConfig
> object. Here we
> > > perform most of our work. In the second round, services get called
> > > without any argument.
> > >
> >
> > That's quite accurate, most of our services perform early
> initialization
> > rather than late initialization.
> >
> > > The problem is that we don't implement the second round
> init(). The
> > > default behaviour in turbine for the secound round is to call
> > > setInit(true). So, the problem is that a lot of times,
> our services are
> > > requested while they are being initialized. The result is
> that turbine
> > > will return the "half cooked" services to the thread
> aking for them.
> > >
> > > I think the default behaviour in TurbineBaseService
> init() is wrong. A
> > > better default would be something like:
> > >
> > > init(Object), init(RunData) and
> init(ServletConfig) do setInit(true)
> > > (Turbine should guarantee that only one of these methods
> is called for
> > > each service)
> > >
> > > public void init() throws InitializationException {
> > >
> > > if(!getInit()) {
> > > throw new InitializationException("Not yet inited");
> > > }
> > >
> > > }
> > >
> > > As a default implementation it should not assume that any
> service is to
> > > be considered initialized when asked for, specially since
> the default
> > > first round init() does nothing. In the way I think it
> should be, a
> > > service that overrides early init takes responsibility of
> setting init
> > > to true, and one that does not override it gets inited
> right. The way it
> > > is now, a service should override both methods if it does any
> > > initialization, to avoid race conditions like the ones we have.
> > >
> > > I have fixed the problems by implementing late init
> methods in some
> > > services (I will check for all and every service that has
> initialization
> > > process). This implementation waits for getInit()
> returning true, while
> > > printing messages every 100 milliseconds, to avoid either
> having an
> > > exception thrown or delivering a service that is "on its way".
> > >
> > > Some of the services implementation used synchronized in
> the two init to
> > > have mutual exclusion between both initializations. It
> will not work,
> > > except by locking turbine if some service is requested during
> > > initialization of other service.
> > >
> >
> > I agree that Turbine Services should probably make sure the
> late init is
> > called on an object when early init is complete, however
> what you propose
> > will not completely solve the specific RegistryManager
> issue which, as far as
> > I can understand, is that early init in RegistryManager has
> an hidden dependency
> > on RegistryManager through EntryFactory and PortletEntryNormalizer.
> > Actually if you do block late init() on the RegistryManager
> as should be, you
> > have a deadlock...
>
>
> I think I made it run, but I will study the issue, since I still get
> some errors I cannot understand
>
> >
> > So the *real* fix for this specific bug is to remove this
> dependency, but digging
> > deep into the JetspeedConfig/PortletRegistry is not
> something I relish...
> >
>
> I had to enter the "mud", and I'm full of it currently :-)
>
> I will start commiting after I check the changes in turbine
> initialization.
>
> > I still agree with you that TurbineServices should ensure
> that late init is always
> > called when early init is complete to avoid race conditions
> and highlight the kind
> > of bugs we have
> >
> > --
> > Raphaël Luta - [EMAIL PROTECTED]
> > Vivendi Universal Networks - Services Manager / Paris
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Search:
> <http://www.mail-archive.com/[email protected]/>
> > List Help?: [EMAIL PROTECTED]
>
> ----------------------------------------------------------------------
>
> Subject: Re: Service initialization (WAS: Couldn't
> processURL: /ocs/local.ocs)
> From: "Santiago Gala" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 11:07:06 +0100
>
> Jon Stevens escribió:
> >
> > Ok,
> >
> > Just so you know, I just got through with a few fairly
> major changes to the
> > way that Services works and it is much cleaner now. I also
> tested a lot of
> > the functionality so I know that things are working pretty well.
> >
> > on 1/28/01 1:13 PM, "Raphaël Luta"
> <[EMAIL PROTECTED]>
> > wrote:
> >
> > > I agree that Turbine Services should probably make sure
> the late init is
> > > called on an object when early init is complete
> >
> > If you don't call setInit(true) in early init, then late
> init() will be
> > executed. I just tested this a few minutes ago and it works.
> >
> > > I still agree with you that TurbineServices should ensure
> that late init is
> > > always
> > > called when early init is complete to avoid race
> conditions and highlight the
> > > kind
> > > of bugs we have
> >
> > It is definitely called if getInit() returns false.
> >
> > In fact, here is the code...
> >
> > service = getServiceInstance(name);
> > if(!service.getInit())
> > {
> > notice("Initializing service (late): " + name);
> > service.init();
> > }
> >
>
> But what if the service is half way early initialization? That is the
> problem we get. I will check your new code, to ensure there are no
> problems with this.
>
> Our problem comes from the fact that early initialization of some
> services is fairly slow, so race conditions are easy to happen.
>
>
> > -jon
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Search:
> <http://www.mail-archive.com/[email protected]/>
> > List Help?: [EMAIL PROTECTED]
>
> ----------------------------------------------------------------------
>
> Subject: Re: [long] Layout system, part 2: functional description
> From: <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 13:33:51 +0100
>
>
>
>
> 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
> >
> > Raphaël 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 L&F (skin) of this pane -->
> > <window-manager ref="MyYahooWM"/>
> > <!-- responsible for the layout of the pane contents -->
> > <layout-manager ref="MultiColumnManager">
> > <column-max>3</column-max>
> > </layout-manager>
> > <!--
> > <entry ref="rss_jetspeed">
> > <column>0</column>
> > </entry>
> > <entry ref="rss_turbine">
> > <column>0</column>
> > </entry>
> > <entry ref="rss_jakarta.apache.org">
> > <column>1</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"/>
> > <url>http://jakarta.apache.org/overview.rss</url>
> > <show-description>false</show-description>
> > <max-items>5</max-items>
> > </screenlet>
> > <screenlet name="..."/>
> > </screenlets>
> > </configuration>
>
> I think it is a good idea to separate the layout/L&F 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
> > requiring a high-performance, distributed backend. ]
>
> Yes, potentially, the database may contain a record for each
> registered
> portlet, portlet view, pane, ...
>
> I think we need a carefully designed interface for accessing this
> information
> which should be equally suited for persistence in databases
> as well as XML
> files. Below the interface, providers for database or
> XML-file persistence
> should be pluggable.
>
> > The administrator may have to configure several
> configuration files for
> > supporting various usage profiles of his site.
> >
> > - general layout registry
> > This registry describes the available global layout
> elements available.
> > It mainly describes the window and layout managers available.
> >
> > example:
> >
> > <registry>
> > <layout-manager name="MultiColumnManager">
> >
> <classname>org;apache.jetspeed.managers.VelocityManager</classname>
> > <template>multi_column.vm</template>
> > </layout-manager>
> > <window-manager name="MyYahooWM">
> >
> <classname>org;apache.jetspeed.managers.VelocityManager</classname>
> > <template type="html">my_yahoo.vm</template>
> > <template type="wml">my_yahoo_wml.vm</template>
> > </window-manager>
> > </registry>
> >
> > [Note; this markup is just for description purpose and may
> be different
> > than the one actually implemented]
> >
> > - portlet registry
> > The administrator may also need to modify the portlet registry in
> > order to add specific portlets for his site.
> > The portlet registry is part of the reusable component model of
> > Jetspeed and will be described in the Portlet container
> desxcription.
> >
> > Note 1:
> > It's possible to emulate the current layout behavior by using the
> > following template
> >
> > jetspeed1_2.vm
> > $jetspeed.Pane("default")
> >
> > and defining as many configuration files as there are site
> pages, all
> > defining the "default" pane.
> >
> > Note 2:
> > The new PSML syntax will have the following properties :
> > - no recursive definitions: a pane element cannot contain
> another pane
> > - separation of contexts: the panes element will only
> contain layout and
> > skin properties, the entries element will only contain portlet
> operational
> > definitions.
> >
> > Managers
> > ========
> > 2 types of managers are used within the layout system:
> >
> > Window managers
> > ---------------
> > Their role is to decorate customizable elements with visual aids and
> > links for accessing the portal operation for a given
> element (for example
> > customize, maximize, minimize, reemove, etc...).
> > A window manager may be specified at the following place:
> > - in a configuration element: it applies for all the portal
> pages and all
> > the panes unless overridden by a more specific manager.
> > - in a pane element, it applies for all the pane elements
> but not the
> > pane itself
> > - in a template, where it applies either for the complete
> template when
> > speficied stand-alone (overriding any pane specific manager) or
> > applying only for a pane when specified as an argument to
> this pane.
> >
> > Layout managers
> > ---------------
> > Layout managers are responsible for positioning the contents of
> > a pane according to the layout properties attached to an entry and
> > render the complete pane content.
> >
> > Portal operations
> > =================
> >
> > Links
> > -----
> > In order to help building the site navigation between pages
> or between
> > portlets, panes, etc... The Jetspeed engine will also provide in the
> > template context a link object which can be used to build links to
> > other configurations, pages, panes, screenlets. This link may also
> > specify a pre-defined portal action.
> >
> > Example:
> >
> > $jetspeed.link
> > -> self-referential link
> > $jetspeed.link.setConfiguration("work_html")
> > -> display same template in another configuration
> > $jetspeed.link.setConfiguration("work_html").setAction("Customize")
> > -> customize the given configuration
> > $jetspeed.link.setPane("user_tools").setAction("Minimize")
> > -> minimize the user_tools pane in the current template
> > $jetspeed.link.setPane("user_tools").setEntry(2).setAction("Info")
> > -> display information on the third entry of the user_tools pane
> >
> > Customization
> > -------------
> > Portal customization will enable the user to do the
> following operations:
> > - create a new configuration
> > - modify the properties of a pane
> > - modify the contents of a pane (adding/removing entries or changing
> > their layout properties)
> > - modify the parameters of a given portlet
> >
> > If a user customizes any element, the portal will always implicitly
> > create a user-specific configuration if it does not already exists.
> > During a page layout, the user-specific configuration will always be
> > searched first for a given pane or entry. If its doesn't contain the
> pane,
> > the portal will fallback to the default configuration.
> > When a single entry is customized and the user specific
> configuration
> does
> > contain the appropriate pane, the whole pane is copied
> first in the user
> > configuration.
> >
> > Multi-device operation
> > ======================
> > * It is anticipated that a given portal configuration will
> usually only
> > support one media-type (for example: default HTML conf,
> default WML
> conf,
> > etc...).
> > This behavior is dependent on the Profiler implementation.
> > * A site page may or may not be media-type dependant,
> depending on the
> > administrator writing the page template
> > * A pane definition is meda-type independant but may contain
> media-dependant
> > elements. In case some element doesn't handle a given
> media-type when
> > rendered, it is ignored.
> > * For some media-type, the template rendered output may be
> post-processed
> > by an adapter which may modify the generated output.
> > * If an adpater is configured for a given media-type, it
> will also act
> > as an URL cache and returns responses without content
> regeneration.
> >
> > Example:
> >
> > * WML without adapter:
> >
> > user A - request home page --> RequestMapper (selects template)
> > |
> > V
> > Profiler (selects configuration)
> > |
> > V
> > user A <--- send response -- template rendering
> >
> > The rendered content may actually be unreadable by user A because of
> > size of the aggregated result
> >
> > * WML with adapter:
> >
> > user A - request home page --> RequestMapper (selects adapter)
> > |
> > V
> > WMLAdapter (selects template)
> > |
> > V
> > Profiler (selects configuration)
> > |
> > V
> > template rendering
> > |
> > V
> > Adapter (parses result and fragment
> > | result in smaller chunk)
> > V
> > user A <--- send response -- first result chunk
> > user A - request chunk 2 --> RequestMapper (selects adapter)
> > |
> > V
> > WMLAdapter (chunk required,
> fetch from
> cache)
> > |
> > V
> > user A <--- send response -- second result chunk
> >
> >
> > Items yet to be defined
> > =======================
> > * All the markup languages used for configuration need to
> be completely
> > specified
>
> I think we also have to specify a portal content model and an
> OO API to
> access it. Then we can define a default reperesentation of
> that model in
> an appropriate markup language.
>
> > * The jetspeed toolbox available whithin templates must be fully
> > described
>
> Can you give examples of the functionality you would envision in the
> toolbox ?
>
> > * Should we allow the use of variables as entry parameters
> within pane
> > definitions ?
>
> Can you give examples ?
>
> > * Are there any specific requirements for handling form
> submissions ?
>
> I think we need a generic mechanism transparent to portlet
> programmers that
> assures that form submissions are routed to the right
> destination (e.g.
> portlet)
> through the portlet container.
>
> >
> > --
> > Raphaël Luta - [EMAIL PROTECTED]
> > Vivendi Universal Networks - Services Manager / Paris
> >
>
>
>
> ----------------------------------------------------------------------
>
> Subject: Navigation inside Portlets
> From: "Mirko Buholzer" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 15:06:39 +0100 (MET)
>
> Does some one have an example dispatch routine for enabling navigation
> inside Portlets.
>
> How do you get the target URL to post any data from the portlet?
>
> Kind regards
> Mirko Buholzer
>
> --
> Sent through GMX FreeMail - http://www.gmx.net
>
>
> ----------------------------------------------------------------------
>
> Subject: FW: JetspeedPersistenceService.java
> From: "Jon Stevens" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 10:21:41 -0800
>
> I just want to make sure that you guys aren't caching RunData
> objects...that
> is BAD BAD BAD...those objects should *never* persist longer than the
> current request.
>
> Also, I *hate* it when people name their variables with "iFoo" or
> "aFoo"...this is Java, not C. There are no global variables
> in Java and it
> is trivial to tell which one you are dealing with within a
> Class and placing
> naming conventions on the variables like that just make things more
> confusing...not less...especially if the rest of the code
> base doesn't look
> anything like that.
>
> :-)
>
> -jon
>
>
> public void store ()
> {
> // store page by page (and let's hope that no
> exception occurs
> // -> missing transaction integrity is a major concern here!
>
> for (Enumeration e = getPages (); e.hasMoreElements (); )
> {
> Page page = (Page) e.nextElement ();
>
> page.store (iRunData);
> }
> }
>
>
>
> ----------------------------------------------------------------------
>
> Subject: Re: Service initialization (WAS: Couldn't
> processURL: /ocs/local.ocs)
> From: "Jon Stevens" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 10:46:38 -0800
>
> on 1/29/01 2:07 AM, "Santiago Gala" <[EMAIL PROTECTED]> wrote:
>
> > But what if the service is half way early initialization?
> That is the
> > problem we get. I will check your new code, to ensure there are no
> > problems with this.
> >
> > Our problem comes from the fact that early initialization of some
> > services is fairly slow, so race conditions are easy to happen.
>
> The start of the initialization services should be done in a
> synchronized
> block to prevent race conditions. Look at Turbine.java's code. :-)
>
> Also, when you reply to messages, please just include the
> relevant portions
> and not the entire email...
>
> thanks,
>
> -jon
>
>
> ----------------------------------------------------------------------
>
> Subject: WebPagePortlet
> From: "Ingo Rammer" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 20:19:49 +0100
>
> Hi,
>
> As I'll be finished in some hours I just wanted to know, whom
> I should send
> my 2 files for the WebPagePortlet to?
>
> [Features:
>
> * Rewriting of <A HREFs, <IMG SRCs, <FORMs (self-referencing
> forms as well)
> * Removal of <HEAD>, <SCRIPT>, <META>, <STYLE>
> * Removal of <OBJECT>, <EMBED>, <APPLET>
>
> ... and the code is quite readable as well ;)
>
> Tested under jdk 1.3 and jdk 1.2.2 using W2K; no external
> dependencies in
> any form ... not much resemblance with the two portlet's
> which got sent to
> me, because one had another external dependency and the other did the
> HTML-parsing/rewriting manually, even though there's some
> support for this
> in the java-language.
> ]
>
> Thanks for the information,
> Ingo
>
> ----------------------------------------------------------------------
>
> Subject: RE: JetspeedPersistenceService.java
> From: "David Sean Taylor" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 11:40:23 -0800
>
> Wow, the wrath of Jon, bummer...
>
> Let me *try* to defend myself:
>
> In creating JetspeedPersistenceService.java, I copied
> PersistenceServiceImpl.java.
> The code is basically the same, but the
> JetspeedPersistenceService uses a
> newer profiler.
> I didn't want to modify PersistenceServiceImpl.java, since
> others may still
> want to use the old profiler. Thus I created a new service impl.
>
> Let me state that I don't use "iFoo" conventions, please
> reference my other
> commits.
> I know you can argue that I *now* use "iFoo" conventions
> since I was too
> lazy, I rather believe I was too polite, so you do have a point there.
> I will change the variable names.
>
> I have also brought up the fact on this mailing list that
> invocations of the
> Persistence Service required multiple 'new' persistence services per
> request.
> So this means that since the lifetime of the service object
> is only for one
> request, its then safe to 'cache' the RunData, since the
> service object will
> be gone after the request.
>
> This is counter to how I believe services should work, again
> I've discussed
> this on the list.
> >From a performance and lifecycle mgt perspective, there are
> also issues....
>
> In defense of the authors, I believe that the
> PersistenceService was written
> as a 'temporary solution', since the underlying classes used
> by it i.e. the
> PortletSet and PSMLManager are due for some major overhauls.
> In that spirit,
> I left the service as is since it works for now.
>
> Im all for rewriting the Persistence Service to be a Turbine
> Service. But
> when I suggested that, it was argued that we are considering
> our own service
> model for the 'Portal API' that isn't dependent on anything else. The
> committers to this service will be able to describe this
> more, but they are
> in Europe so it probably won't be til tomorrow.
>
> Damn, now I suppose that everytime you see my name, you will
> think "iFoo",
> or even worse, the "iFoo Propagator".
> Where's there a corner I can hide in....
>
> -- iFoo
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Jon Stevens
> > Sent: Monday, January 29, 2001 10:22 AM
> > To: jetspeed
> > Subject: FW: JetspeedPersistenceService.java
> >
> >
> > I just want to make sure that you guys aren't caching RunData
> > objects...that
> > is BAD BAD BAD...those objects should *never* persist
> longer than the
> > current request.
> >
> > Also, I *hate* it when people name their variables with "iFoo" or
> > "aFoo"...this is Java, not C. There are no global variables
> in Java and it
> > is trivial to tell which one you are dealing with within a Class
> > and placing
> > naming conventions on the variables like that just make things more
> > confusing...not less...especially if the rest of the code base
> > doesn't look
> > anything like that.
> >
> > :-)
> >
> > -jon
> >
> >
> > public void store ()
> > {
> > // store page by page (and let's hope that no
> exception occurs
> > // -> missing transaction integrity is a major
> concern here!
> >
> > for (Enumeration e = getPages (); e.hasMoreElements (); )
> > {
> > Page page = (Page) e.nextElement ();
> >
> > page.store (iRunData);
> > }
> > }
> >
> >
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Search:
> <http://www.mail-archive.com/[email protected]/>
> > List Help?: [EMAIL PROTECTED]
> >
> >
>
>
> ----------------------------------------------------------------------
>
> Subject: Re: Fwd: iCal
> From: "Jeff Prickett" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 11:43:40 -0800 (PST)
>
>
>
> On Fri, 26 Jan 2001, Santiago Gala wrote:
>
> > ingo schuster escribió:
> > >
> > > I don't know much about iCalender. Anybody else?
> > > ingo.
> > >
> > > >From: Thierry Janaudy <[EMAIL PROTECTED]>
> > > >To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> > > >Subject: iCal
> > > >Date: Wed, 24 Jan 2001 18:21:34 -0000
> > > >X-Mailer: Internet Mail Service (5.5.2650.21)
> > > >
> > > >Hello,
> > > >
> > > >I am interested in your iCal implementation.
> > > >Can you please tell me its status, and if it has
> > > >been tested agaisnt iPortal, Micrsoft Exchange server?
> >
> > The only thing I know is that updates show cvs activity from time to
> > time, so it is not stopped. See a previous post by Raphael
> on the issue.
> >
>
> Hello,
> I am the person responsible for the iCalendar implementation.
> Its current
> status is.
>
> It saves Event and To Do objects in the database. As well as
> attendees and
> categories. There may be some more functionality which is largely
> untested.
>
> This includes
>
> 1. writing an iCalendar stream minus long line folding.
> 2. reading an iCalendar property from a stream after it has
> been folded.
>
> An overhaul of the Base Peer classes is in order as well as
> an overhaul
> of the private and protected methods of the iCalendar
> business objects.
>
> Right now I dont have a lot of flexibility with the overhaul
> as my company
> is trying to wrap up a product on this current version of the
> apache code.
>
> If any one is willing to help reengineer the backend please
> email me. I
> have some ideas on how we can extend turbines auto generated
> peers to work
> with iCalendar.
>
> Just dont have the time :(.
>
>
>
> Jeff Prickett
>
>
> ----------------------------------------------------------------------
>
> Subject: RE: WebPagePortlet
> From: "David Sean Taylor" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 12:35:39 -0800
>
> Ingo,
>
> I'd be glad to test it out.
> Include the source in an email to the list, so that others
> can test it too.
>
> David
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Ingo Rammer
> > Sent: Monday, January 29, 2001 11:20 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: WebPagePortlet
> >
> >
> > Hi,
> >
> > As I'll be finished in some hours I just wanted to know, whom I
> > should send
> > my 2 files for the WebPagePortlet to?
> >
> > [Features:
> >
> > * Rewriting of <A HREFs, <IMG SRCs, <FORMs (self-referencing
> > forms as well)
> > * Removal of <HEAD>, <SCRIPT>, <META>, <STYLE>
> > * Removal of <OBJECT>, <EMBED>, <APPLET>
> >
> > ... and the code is quite readable as well ;)
> >
> > Tested under jdk 1.3 and jdk 1.2.2 using W2K; no external
> dependencies in
> > any form ... not much resemblance with the two portlet's
> which got sent to
> > me, because one had another external dependency and the
> other did the
> > HTML-parsing/rewriting manually, even though there's some
> support for this
> > in the java-language.
> > ]
> >
> > Thanks for the information,
> > Ingo
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Search:
> <http://www.mail-archive.com/[email protected]/>
> > List Help?: [EMAIL PROTECTED]
> >
> >
>
>
> ----------------------------------------------------------------------
>
> Subject: Re: WebPagePortlet
> From: "Jon Stevens" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 13:33:26 -0800
>
> on 1/29/01 11:19 AM, "Ingo Rammer" <[EMAIL PROTECTED]> wrote:
>
> > * Rewriting of <A HREFs, <IMG SRCs, <FORMs
> (self-referencing forms as well)
> > * Removal of <HEAD>, <SCRIPT>, <META>, <STYLE>
> > * Removal of <OBJECT>, <EMBED>, <APPLET>
>
> Not sure what this is for, but if it is for security, you
> shouldn't specify
> what to *remove* but what to *keep*.
>
> -jon
>
>
> ----------------------------------------------------------------------
>
> Subject: Re: JetspeedPersistenceService.java
> From: "Jon Stevens" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 13:39:58 -0800
>
> on 1/29/01 11:40 AM, "David Sean Taylor"
> <[EMAIL PROTECTED]>
> wrote:
>
> > Wow, the wrath of Jon, bummer...
>
> Not wrath. I put a friggen :-) at the end of the email. Sigh.
>
> :-(
>
> > Let me *try* to defend myself:
> >
> > In creating JetspeedPersistenceService.java, I copied
> > PersistenceServiceImpl.java.
> > The code is basically the same, but the
> JetspeedPersistenceService uses a
> > newer profiler.
> > I didn't want to modify PersistenceServiceImpl.java, since
> others may still
> > want to use the old profiler. Thus I created a new service impl.
>
> Not a problem.
>
> > I will change the variable names.
>
> Great!
>
> > I have also brought up the fact on this mailing list that
> invocations of the
> > Persistence Service required multiple 'new' persistence
> services per
> > request.
> > So this means that since the lifetime of the service object
> is only for one
> > request, its then safe to 'cache' the RunData, since the
> service object will
> > be gone after the request.
>
> Ok. I was just checking.
>
> > This is counter to how I believe services should work,
> again I've discussed
> > this on the list.
>
> Then maybe implement it differently?
>
> > In defense of the authors, I believe that the
> PersistenceService was written
> > as a 'temporary solution', since the underlying classes
> used by it i.e. the
> > PortletSet and PSMLManager are due for some major
> overhauls. In that spirit,
> > I left the service as is since it works for now.
> >
> > Im all for rewriting the Persistence Service to be a
> Turbine Service. But
> > when I suggested that, it was argued that we are
> considering our own service
> > model for the 'Portal API' that isn't dependent on anything
> else. The
> > committers to this service will be able to describe this
> more, but they are
> > in Europe so it probably won't be til tomorrow.
>
> Ok, I'm *strongly* -1 on any more Services frameworks being built.
>
> Please look at the BaseService class in Turbine. It is a very clean
> framework for building Services. One could easily build a
> PortletService on
> top of BaseService....instead of having it built on top of
> TurbineServices.
>
> If you look at the BaseService, it does nothing more than
> import java.util.
> There is zero dependencies on any of the rest of the system.
>
> > Damn, now I suppose that everytime you see my name, you
> will think "iFoo",
> > or even worse, the "iFoo Propagator".
> > Where's there a corner I can hide in....
>
> Oh, don't say immature things when someone simply asks why
> things are being
> done the way that things are being done. This project has a
> long history of
> not doing things properly...work to fix it, not to make it worse.
>
> thanks,
>
> -jon
>
>
> ----------------------------------------------------------------------
>
> Subject: AW: WebPagePortlet
> From: "Ingo Rammer" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 23:08:51 +0100
>
> Hi,
>
> I'd rather send it to someone who could check it into cvs, so
> that in case
> of bugs we don't have too many different versions floating around.
>
> Simply checking it in, without changing the config-files
> would not break
> anything ... even if it wouldn't work at all ;))
>
> Ingo
>
> > -----Ursprüngliche Nachricht-----
> > Von: David Sean Taylor [mailto:[EMAIL PROTECTED]]
> > Gesendet: Montag, 29. Jänner 2001 21:36
> > An: JetSpeed
> > Betreff: RE: WebPagePortlet
> >
> >
> > Ingo,
> >
> > I'd be glad to test it out.
> > Include the source in an email to the list, so that others
> > can test it too.
> >
> > David
>
> ----------------------------------------------------------------------
>
> Subject: RE: WebPagePortlet
> From: "Craig Berry" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 14:39:42 -0800
>
> > From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, January 29, 2001 1:33 PM
> >
> > Not sure what this is for, but if it is for security, you
> > shouldn't specify
> > what to *remove* but what to *keep*.
>
> I'd imagine it's part of the general "scrub it to fit in a td
> cell" process,
> though why you'd have to strip objects and applets to get
> there is a bit
> confusing.
>
> I'm still not quite sure I understand the niche
> WebPagePortlet is trying to
> fill. If you're grabbing a page you control, why not use
> whatever process
> drives its content to drive a separate portlet content source
> (rss, for
> example) as well? And if you're grabbing a page you don't
> control, what are
> the odds that a page designed for at least a medium-sized
> window is going to
> scrunch into a portlet cell without looking like a complete
> mess, or making
> a mess of the rest of the portal layout?
>
> What am I missing? What's this thing for?
>
> --
> Craig Berry - (310) 570-4140
> VP Technology
> GlueCode
> 1452 Second St
> Santa Monica CA 90401
>
>
> ----------------------------------------------------------------------
>
> Subject: RE: JetspeedPersistenceService.java
> From: "David Sean Taylor" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 14:50:55 -0800
>
> >
> > Then maybe implement it differently?
> ...
> > Ok, I'm *strongly* -1 on any more Services frameworks being built.
> ...
> > If you look at the BaseService, it does nothing more than import
> > java.util.
> > There is zero dependencies on any of the rest of the system.
>
> absolutely
> We need to agree on a common base service.
> This discussion will help make that happen.
> Any arguments for BaseService or a portal api-based portal.service are
> welcome
>
>
>
> ----------------------------------------------------------------------
>
> Subject: Re: WebPagePortlet
> From: "Ingo Rammer" <[EMAIL PROTECTED]>
> Date: Tue, 30 Jan 2001 00:26:34 +0100
>
> > Von: Craig Berry [mailto:[EMAIL PROTECTED]]
> > Gesendet: Montag, 29. Jänner 2001 23:40
> > >
> > > Not sure what this is for, but if it is for security, you
> > > shouldn't specify
> > > what to *remove* but what to *keep*.
> >
> > I'd imagine it's part of the general "scrub it to fit in a td
> > cell" process,
> > though why you'd have to strip objects and applets to get
> > there is a bit
> > confusing.
>
> On one hand it's just for keeping the layout consistent
> (which means, there
> shouldn't be another <STYLE>-Tag in). On the other hand, a <META
> http-equiv="REDIRECT... -Tag wouldn't be nice in a portal anyway ...
>
> Every "scrubbing"-feature can be turned of for any page you
> want to include
> in the portal. (The only thing that can't be switched is the automatic
> opening/closing of missing tags ... so that a included
> "</table>" without
> corresponding "<table>" wouldn't mess up with your layout.
>
> > I'm still not quite sure I understand the niche
> > WebPagePortlet is trying to
> > fill. If you're grabbing a page you control, why not use
> > whatever process
> > drives its content to drive a separate portlet content source
> > (rss, for
> > example) as well? And if you're grabbing a page you don't
> > control, what are
> > the odds that a page designed for at least a medium-sized
> > window is going to
> > scrunch into a portlet cell without looking like a complete
> > mess, or making
> > a mess of the rest of the portal layout?
>
> It's mainly, because (at least here, I don't know about the
> rest of the
> world yet ;) ) some pages will be maintained by independent
> people/departments where you cannot force them to use anything but the
> corporate/departmental standard tool for website-design
> (which is in our
> case f.e. FrontPage). I nevertheless want to integrate some
> information from
> their pages in a portal.
>
> > What am I missing? What's this thing for?
>
> It was mainly because on one hand three people (including me) already
> started developing something like this and on the other hand,
> I needed it
> for said integration of already exisiting information on
> different project's
> pages which are maintained seperately.
>
> Ingo
>
> ----------------------------------------------------------------------
>
> Subject: RE: WebPagePortlet
> From: "Craig Berry" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 16:04:38 -0800
>
> > From: Ingo Rammer [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, January 29, 2001 3:27 PM
> >
> > Every "scrubbing"-feature can be turned of for any page you
> > want to include
> > in the portal. (The only thing that can't be switched is
> the automatic
> > opening/closing of missing tags ... so that a included
> > "</table>" without
> > corresponding "<table>" wouldn't mess up with your layout.
>
> Yow, hadn't even thought about all the mischief there...
>
> > > I'm still not quite sure I understand the niche
> > > WebPagePortlet is trying to fill.
> >
> > It's mainly, because (at least here, I don't know about the
> > rest of the
> > world yet ;) ) some pages will be maintained by independent
> > people/departments where you cannot force them to use
> anything but the
> > corporate/departmental standard tool for website-design
> > (which is in our
> > case f.e. FrontPage). I nevertheless want to integrate some
> > information from their pages in a portal.
>
> Okay, it's making more sense now. A combination of lack of
> direct control
> with predictability of form fits the bill pretty well.
>
> --
> Craig Berry - (310) 570-4140
> VP Technology
> GlueCode
> 1452 Second St
> Santa Monica CA 90401
>
>
> ----------------------------------------------------------------------
>
> Subject: Re: WebPagePortlet
> From: "Jon Stevens" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 16:37:32 -0800
>
> on 1/29/01 3:26 PM, "Ingo Rammer" <[EMAIL PROTECTED]> wrote:
>
> > On one hand it's just for keeping the layout consistent
> (which means, there
> > shouldn't be another <STYLE>-Tag in). On the other hand, a <META
> > http-equiv="REDIRECT... -Tag wouldn't be nice in a portal anyway ...
> >
> > Every "scrubbing"-feature can be turned of for any page you
> want to include
> > in the portal. (The only thing that can't be switched is
> the automatic
> > opening/closing of missing tags ... so that a included
> "</table>" without
> > corresponding "<table>" wouldn't mess up with your layout.
>
> A better methodology for this is to simply remove the tags
> that you don't
> know about and keep the ones that you want...this can be done
> with a regular
> expression. I suggest that you do it this way. :-)
>
> -jon
>
>
> ----------------------------------------------------------------------
>
> Subject: Re: JetspeedJspPage error
> From: "Michael Sallman" <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2001 18:50:01 -0600
>
> Ingo,
>
> Thanks. I just did a fresh checkout and everything seems ok.
> I guess I'll have to read up some more on CVS :-)
>
> Mike
>
> ingo schuster wrote:
>
> >
> > It does exist - however it's in a new directory. Try a
> clean checkout or
> > make sure to checkout new directories during update.
> >
> > ingo.
> >
>
>
> ----------------------------------------------------------------------
> End of JetSpeed
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/[email protected]/>
> List Help?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
