DO NOT REPLY [Bug 17756] - MVCPortlet Proposal

2003-03-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17756

MVCPortlet Proposal





--- Additional Comments From [EMAIL PROTECTED]  2003-03-07 03:07 ---
Created an attachment (id=5193)
MVCPortlet API and description, also found at URL

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 17756] - MVCPortlet Proposal

2003-03-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17756

MVCPortlet Proposal





--- Additional Comments From [EMAIL PROTECTED]  2003-03-07 03:07 ---
Created an attachment (id=5192)
source code for working prototype and jsp/velocity example portlets

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 17756] New: - MVCPortlet Proposal

2003-03-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17756

MVCPortlet Proposal

   Summary: MVCPortlet Proposal
   Product: Jetspeed
   Version: 1.4b4-dev /CVS
  Platform: Other
   URL: http://www.kuebler.org/MVCPortlet/MVCPortlet.html
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Portlets
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


See URL for specifics and attachements for source and javadocs

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: WebPageProxyPortlet

2003-03-06 Thread David Sean Taylor
On Thursday, March 6, 2003, at 04:18  PM, David G. Powers wrote:

On Thursday 06 March 2003 03:19 pm, David Sean Taylor wrote:
Will it be dependent on the HTTP protocol, or will it support other
protocols?
If it only works with HTTP, then HttpProxyPortlet sounds good (I know,
I've changed my mind again)


I working on an Http only version.  I'm not aware of any other 
practical
use.  The RSS stuff is best handled with XSLT, just as are other XML 
Web
services.  I think other candidate protocols would be handled in the 
near
term with this Http Proxy, i.e. SMTP/POP3 via WebMail.

That brings me back to the part of my inquiry that I care most about - 
I
like what I see in the Apache commons HttpClient.  I like it much more
than the java.net.HttpURLConnection.  I'm going to proceed using it
unless I read negative feedback on it.


The +1 that I typed  means - "Yes, I agree, you have my vote"
If  you don't get any -1 votes, then your fine to go ahead and use it
--
David Sean Taylor
Bluesunrise Software
[EMAIL PROTECTED]
+01 707 773-4646


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: WebPageProxyPortlet

2003-03-06 Thread David G. Powers
On Thursday 06 March 2003 03:19 pm, David Sean Taylor wrote:
> Will it be dependent on the HTTP protocol, or will it support other
> protocols?
> If it only works with HTTP, then HttpProxyPortlet sounds good (I know,
> I've changed my mind again)


I working on an Http only version.  I'm not aware of any other practical 
use.  The RSS stuff is best handled with XSLT, just as are other XML Web 
services.  I think other candidate protocols would be handled in the near 
term with this Http Proxy, i.e. SMTP/POP3 via WebMail.

That brings me back to the part of my inquiry that I care most about - I 
like what I see in the Apache commons HttpClient.  I like it much more 
than the java.net.HttpURLConnection.  I'm going to proceed using it 
unless I read negative feedback on it.




-- 
David G. Powers
PowerSource

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: WebPageProxyPortlet

2003-03-06 Thread David Sean Taylor
On Thursday, March 6, 2003, at 02:18  PM, David G. Powers wrote:

I'd like to use the HttpClient from Apache commons instead of a
java.net.HttpURLConnection.
( http://jakarta.apache.org/commons/httpclient/features.html )

+1

Will there be any objections to introducing this new dependency?

DP

P.S.  Good names can be so elusive.  Anyone have a good suggestion for 
a
new "Proxied Http Content Portlet"?

Will it be dependent on the HTTP protocol, or will it support other 
protocols?
If it only works with HTTP, then HttpProxyPortlet sounds good (I know, 
I've changed my mind again)

--
David Sean Taylor
Bluesunrise Software
[EMAIL PROTECTED]
+01 707 773-4646


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: Question about JspAction

2003-03-06 Thread Weaver, Scott
Hi Mark,

Here it is.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17747

Scott

> -Original Message-
> From: Mark Orciuch [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 06, 2003 5:50 PM
> To: Jetspeed Developers List
> Subject: RE: Question about JspAction
> 
> RE: Question about JspActionScott,
> 
> Your e-mail did not contain any attachments. I noticed lately people
> having
> their attachments stripped off. Recommend opening up a Bugzilla issue and
> attaching your stuff there. It's better for tracking anyway.
> 
> 
> Best regards,
> 
> Mark Orciuch - [EMAIL PROTECTED]
> Jakarta Jetspeed - Enterprise Portal in Java
> http://jakarta.apache.org/jetspeed/
> 
>   -Original Message-
>   From: Weaver, Scott [mailto:[EMAIL PROTECTED]
>   Sent: Thursday, March 06, 2003 4:46 PM
>   To: 'Jetspeed Developers List'
>   Subject: RE: Question about JspAction
> 
> 
>   Mark,
> 
>   This is what I have come up with so far.  I have tried to combine a lot
> of
> commonalities of the JspPortlet and VelocityPortlet into processor
> components so as not to upset the current object hierarchy.
> 
>   When you get a chance, take a quick look and let me know what you think.
> 
>   Scott
> 
>   > -Original Message-
>   > From: Mark Orciuch [mailto:[EMAIL PROTECTED]
>   > Sent: Thursday, March 06, 2003 2:35 PM
>   > To: Jetspeed Developers List
>   > Subject: RE: Question about JspAction
>   >
>   > Scott,
>   >
>   > >  Yes, all VelocityPortlets get their own context.  I am going try
>   > > using HashMap request attribute "templateMap" keyed by portlet id
>   > > to overcome this.  I am also going attempt break the template
>   > > logic into a single, separate component that can be used by
>   > > VelocityPortlets and JspPortlets.  That way when changes happen,
>   > > the impact on both types of portlets will be more apparent.  I
>   >
>   > That was my original goal, to create a base TemplatePortlet and
>   > TemplatePortletAction, but no time :( Please open up a Bugzilla issue
> for
>   > this. Thanks!
>   >
>   > BTW: The setTemplate issue is tracked here:
>   > http://issues.apache.org/bugzilla/show_bug.cgi?id=16443.
>   >
>   > > think I am one of those rare exceptions that use both Velocity
>   > > AND jsp portlets.
>   >
>   > I'm using both Velocity and JSP as well.
>   >
>   > Best regards,
>   >
>   > Mark Orciuch - [EMAIL PROTECTED]
>   > Jakarta Jetspeed - Enterprise Portal in Java
>   > http://jakarta.apache.org/jetspeed/
>   >
>   >
>   > -
>   > To unsubscribe, e-mail: [EMAIL PROTECTED]
>   > For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 



RE: Question about JspAction

2003-03-06 Thread Mark Orciuch
RE: Question about JspActionScott,

Your e-mail did not contain any attachments. I noticed lately people having
their attachments stripped off. Recommend opening up a Bugzilla issue and
attaching your stuff there. It's better for tracking anyway.


Best regards,

Mark Orciuch - [EMAIL PROTECTED]
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/

  -Original Message-
  From: Weaver, Scott [mailto:[EMAIL PROTECTED]
  Sent: Thursday, March 06, 2003 4:46 PM
  To: 'Jetspeed Developers List'
  Subject: RE: Question about JspAction


  Mark,

  This is what I have come up with so far.  I have tried to combine a lot of
commonalities of the JspPortlet and VelocityPortlet into processor
components so as not to upset the current object hierarchy.

  When you get a chance, take a quick look and let me know what you think.

  Scott

  > -Original Message-
  > From: Mark Orciuch [mailto:[EMAIL PROTECTED]
  > Sent: Thursday, March 06, 2003 2:35 PM
  > To: Jetspeed Developers List
  > Subject: RE: Question about JspAction
  >
  > Scott,
  >
  > >  Yes, all VelocityPortlets get their own context.  I am going try
  > > using HashMap request attribute "templateMap" keyed by portlet id
  > > to overcome this.  I am also going attempt break the template
  > > logic into a single, separate component that can be used by
  > > VelocityPortlets and JspPortlets.  That way when changes happen,
  > > the impact on both types of portlets will be more apparent.  I
  >
  > That was my original goal, to create a base TemplatePortlet and
  > TemplatePortletAction, but no time :( Please open up a Bugzilla issue
for
  > this. Thanks!
  >
  > BTW: The setTemplate issue is tracked here:
  > http://issues.apache.org/bugzilla/show_bug.cgi?id=16443.
  >
  > > think I am one of those rare exceptions that use both Velocity
  > > AND jsp portlets.
  >
  > I'm using both Velocity and JSP as well.
  >
  > Best regards,
  >
  > Mark Orciuch - [EMAIL PROTECTED]
  > Jakarta Jetspeed - Enterprise Portal in Java
  > http://jakarta.apache.org/jetspeed/
  >
  >
  > -
  > To unsubscribe, e-mail: [EMAIL PROTECTED]
  > For additional commands, e-mail: [EMAIL PROTECTED]





RE: Question about JspAction

2003-03-06 Thread Weaver, Scott
Title: RE: Question about JspAction





Mark,


This is what I have come up with so far.  I have tried to combine a lot of commonalities of the JspPortlet and VelocityPortlet into processor components so as not to upset the current object hierarchy.   

When you get a chance, take a quick look and let me know what you think.


Scott


> -Original Message-
> From: Mark Orciuch [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 06, 2003 2:35 PM
> To: Jetspeed Developers List
> Subject: RE: Question about JspAction
> 
> Scott,
> 
> >  Yes, all VelocityPortlets get their own context.  I am going try
> > using HashMap request attribute "templateMap" keyed by portlet id
> > to overcome this.  I am also going attempt break the template
> > logic into a single, separate component that can be used by
> > VelocityPortlets and JspPortlets.  That way when changes happen,
> > the impact on both types of portlets will be more apparent.  I
> 
> That was my original goal, to create a base TemplatePortlet and
> TemplatePortletAction, but no time :( Please open up a Bugzilla issue for
> this. Thanks!
> 
> BTW: The setTemplate issue is tracked here:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=16443.
> 
> > think I am one of those rare exceptions that use both Velocity
> > AND jsp portlets.
> 
> I'm using both Velocity and JSP as well.
> 
> Best regards,
> 
> Mark Orciuch - [EMAIL PROTECTED]
> Jakarta Jetspeed - Enterprise Portal in Java
> http://jakarta.apache.org/jetspeed/
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: WebPageProxyPortlet

2003-03-06 Thread David G. Powers
I'd like to use the HttpClient from Apache commons instead of a 
java.net.HttpURLConnection.

( http://jakarta.apache.org/commons/httpclient/features.html )

Will there be any objections to introducing this new dependency?

DP

P.S.  Good names can be so elusive.  Anyone have a good suggestion for a 
new "Proxied Http Content Portlet"?




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 15214] - Cleanup Logging

2003-03-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15214

Cleanup Logging





--- Additional Comments From [EMAIL PROTECTED]  2003-03-06 22:12 ---
Agreed.

Since we also should get rid of the (soon to be) deprecated 
org.apache.turbine.util.Log when migrating to Turbine 2.3, i suggest doing the 
other kind of cleanup and more useful use of categories (LOG4J-wise) at the 
same time. I volunteer for that work when the time is right to do so.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 15214] - Cleanup Logging

2003-03-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15214

Cleanup Logging





--- Additional Comments From [EMAIL PROTECTED]  2003-03-06 22:05 ---
+1 to debug *all* exceptions (Except those with a explicit comment saying it is
normal or expected behaviour).


WRT you other question, it is better several simpler and more secure patches 
than one big patch. So, in case you doubt, just skip over it (or flag it
with a TODO and skip it).

In a second pass we can keep on "cleaning"

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [patch] JetspeedLocalizationService

2003-03-06 Thread Santiago Gala
Jon Evans wrote:
Hi David,

David Sean Taylor wrote:

The patch isn't necessary I just committed a patch from
Missimilliano Dessi. It works fine as is. Although I thought we had
country flag icons with the original portlet.


I have just got round to using the latest CVS.  I like the fact that
the changeLanguage portlet is now a .vm, it will make it a lot easier
to change the look and feel for my site.
I'm still concerned though with
org.apache.jetspeed.services.customlocalization.JetspeedLocalizationService. 

It still doesn't seem to work if you have more than one bundle defined
in locale.default.bundles.  It only seems to look at the first bundle.
If you look at the class, it extends TurbineLocalizationService.
JetspeedLocalizationService implements an initBundleNames() method
which populates an instance variable String[] bundleNames.  But all of
the getString(...) methods call super.getString(...), where
TurbineLocalizationService will use its own instance variables and will
not find the strings.
Let me put it another way.  Each class defines an identical set of 
instance variables, like this:

JetspeedLocalizationService TurbineLocalizationService
=== ===
private Hashtable bundles;  private Hashtable bundles;
private String bundleNames[];   private String bundleNames[];
private Locale defaultLocale;   private Locale defaultLocale;
private String defaultLanguage; private String defaultLanguage;
private String defaultCountry;  private String defaultCountry;
After JetspeedLocalizationService.init() is called they look like this:

JetspeedLocalizationService TurbineLocalizationService
=== ==
bundles  null   bundles set
bundleNames[]setbundleNames[]   null
defaultLocalenull   defaultLocale   set
defaultLanguage  null   defaultLanguage set
defaultCountry   null   defaultCountry  set
when getString(String bundleName, Locale locale, String key) is called
in JetspeedLocalizationService, it calls super.getString(...).  This
calls getBundle(String, Locale), which is implemented in
JetspeedLocalizationService as a call to super.getBundle(String,
Locale), so we are back to the code in TurbineLocalizationService.
getBundle(String, Locale) in TurbineLocalizationService returns the
default bundle to the getString(...) method.
Back in getString(String bundleName, Locale locale, String key), we
look up the requested key in the bundle, using getStringOrNull(), which 
returns null because the string I'm looking for isn't in the first 
bundle, it's in the second.

The next test is intended to determine whether we need to check the
other bundles for the key.  The test is:
// Look for text in list of default bundles.
if (value == null && bundleNames.length > 0)
At this point we throw a NullPointerException because bundleNames is
null (it was never set in TurbineLocalizationService, only in
JetspeedLocalizationService).
The whole of the JetspeedLocalizationService class can be reduced to a 
single function, getLocale(RunData runData).

The attached patch does this, and seems to work.  Yes, I compiled from 
clean this time. :-)

Jon




It looks right, and removes a lot of code (I have no time to test it), 
but...

In the process of evolution that is coming towards us (I mean JSR 
results, etc.) it is quite possible that changes are needed, looking 
from the original proposal and industry trends. So, I would prefer a 
tested patch which would just stopped inheriting from the turbine one 
but is still functionally complete. I mean inheriting from 
TurbineBaseService, which limits dependency to initialization code.

I say so because Turbine is moving towards less coupled classes. 
Currently services are being decoupled and ported to fulcrum, for use in 
turbine 2.2+ and 3. So I think keeping the whole implementation here 
until we ensure that the needed changes are in Turbine does not look bad.

The way I propose will make easier in the future:
* backport our needed functionality to the service already present in 
Fulcrum
* just change the interfaces it implements and have it running in 
Fulcrum, through the magics of Avalon.

Regards,
 Santiago







Index: src/java/org/apache/jetspeed/services/customlocalization/JetspeedLocalizationService.java
===
RCS file: /home/cvspublic/jakarta-jetspeed/src/java/org/apache/jetspeed/services/customlocalization/JetspeedLocalizationService.java,v
retrieving revision 1.4
diff -u -r1.4 JetspeedLocalizationService.java
--- src/java/org/apache/jetspeed/services/customlocalization/JetspeedLocalizationService.java	26 Feb 2003 17:46:34 -	1.4
+++ src/java/org/apache/jetspeed/services/customlocalization/JetspeedLocalizationService.java	4 Mar 2003 12:49:37 -
@@ -62,14 +62,10 @@
  */

DO NOT REPLY [Bug 15214] - Cleanup Logging

2003-03-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15214

Cleanup Logging





--- Additional Comments From [EMAIL PROTECTED]  2003-03-06 21:29 ---
I see source files (ex: BaseClientRegistry) where there is a double check for 
debugging by using a private final static DEBUG like this:

if (DEBUG && Log.getLogger().isDebugEnabled())
This means that code changes are needed to activate debug-logging in these 
classes. I suggest removing the DEBUG, and rather use more fine grained LOG4J 
configuration. For this to be useful, I suggest to go thru the source files 
and add a 

static Logger logger = Log.getLogger(.class);

Comments?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 15214] - Cleanup Logging

2003-03-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15214

Cleanup Logging

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2003-03-06 20:59 ---
Started working on this.
I will first concentrate on enclosing (heavy) debug logging with isDebugEnabled
(), and I'm looking through all source files using org.apache.turbine.util.log.

Question/proposal: I see there are quite a few places where exception happen, 
but they are not logged. I'd prefer to add at least debug logging when i see 
these, as I work my way down the list.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [CONTRIBUTION] ic-no.gif

2003-03-06 Thread Harald Ommang
On Thu, 06 Mar 2003 12:40:09 -0800 (PST), "Harald Ommang" wrote:

> 
> On Thu, 06 Mar 2003 12:38:06 -0800 (PST), "Harald Ommang" wrote:
> 
> > 
> > Hi!
> > 
> > I noticed the flag images in webapp/images. No Norwegian flag there.
> > Here's one!
> > 
> > Harald
> 
> Seems like the attachement didn't go thru, somehow...
> 
> Trying again.
I love my mail system. (Any Domain Direct-ers reading this??)

Attaching it ZIP-ed...

ic-no.zip
Description: Zip compressed data
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [CONTRIBUTION] ic-no.gif

2003-03-06 Thread Harald Ommang
On Thu, 06 Mar 2003 12:38:06 -0800 (PST), "Harald Ommang" wrote:

> 
> Hi!
> 
> I noticed the flag images in webapp/images. No Norwegian flag there.
> Here's one!
> 
> Harald

Seems like the attachement didn't go thru, somehow...

Trying again.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

WebPageProxyPortlet

2003-03-06 Thread David G. Powers
On Thursday 06 March 2003 11:40 am, Glen Carl wrote:
> This is fine with me. I hope David Powers is seeing this email and can
> check out what was done with the WebBrowserPortlet and the
> IframeProxyPortlet. These portlets are included in the jar I
> referenced. Glen

Yep - I'm seeing it.  

Here's a very brief overview of what I'm prototyping

WebPageProxyPortlet - Enable navigation of a site within the context of a 
portlet frame.

The connection to the content provider will pass through the Jetspeed 
server.   I haven't given enough thought to ancillary page elements 
(images, applets, flash animations, ActiveX controls, etc...)  initially 
I will just let the browser handle retrieval of these.  Ideally this 
implementation should be a complete proxy elimination the need for a 
route from the browser to the content provider.

The admin / user will set the initial page parameters including:
URL
default HTTP headers
authorization (username/password/method)
cookies
user agent
general config
field-rename-prefix
method (GET, POST)
restrict-nav-to-domain(s) (regex list?)
restrict-resubmit-list (to prevent multiple payment confirm on reload)


Upon initial request of a proxied item the Portlet will use these default 
parameters to load the page.

A rewriter will filter the content and inject / extract attributes 
necessary to intercept navigation (GET or POST) and maintain state 
(session / authentication) within the content and make it available to 
the Proxy (Action or Servlet).

When a user acts upon a navigation element in the filtered content, the 
proxy (Action or Servlet) will intercept the request and save control 
info via the ProxyPersistenceLayer (interface - first implementation will 
use Session, second will store token in session an attributes in RDBMS).  
Control will then pass to the Portlet - getContent() will use the 
"current" settings to fetch and filter the content and render it.


The rewriter is the trickiest part of this puzzle.  It must at least:
rewrite href and action attributes to inject proxy URL
save current target URL in PPL (ProxyPersistenceLayer) stack
save any other request attributes (method, headers (cookies, etc...)
rewrite form object names
rewrite JavaScript function names

There is a reason for rewriting the form object names and JavaScript 
function names.  I experienced conflicts with content from a single 
provider.  They used generic javascript includes for form handling.  
Every form used the same function for "onsubmit()" and a set of "global" 
page variables.  I worked around this by renaming the functions and 
variables per requested page, thus I could have multiple Portlets from 
that content provider presented and handled on the same Jetspeed page.


I haven't gone back to edit what I just typed!  There might be some typos, 
glaring omissions, or outright mistakes.  I am very open to any and all 
comments, suggestions, and contributions.

DP


-- 
David G. Powers
PowerSource

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[CONTRIBUTION] ic-no.gif

2003-03-06 Thread Harald Ommang
Hi!

I noticed the flag images in webapp/images. No Norwegian flag there.
Here's one!

Harald
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 17632] - patch to add portlet.getContent() load time to PortletStats service

2003-03-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17632

patch to add portlet.getContent() load time to PortletStats service

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|jetspeed-   |[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |
 Status|ASSIGNED|NEW



--- Additional Comments From [EMAIL PROTECTED]  2003-03-06 20:00 ---
Todd,

It's a good idea to use the load time instead of page size. I'll apply this 
patch when I get around to it. Thanks!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Planning for Jetspeed 1.4b4

2003-03-06 Thread Mark Orciuch
Harald,

> I'm ready to start working on this.
> Just a question, as I'm fairly new to the apache way of
> contributing. (Don't
> worry I've been designing and developing and coding for ages...)
> In what form do
> you committers want me to send the updates for this? Patch pr.
> file?, Patch pr.
> package? Patch pr. "batch" of work I do?

I think the convention was to use "cvs diff -u" for creating patches. I'm
not sure if it's possible to create a single patch file for all the changes.
That would be ideal.

> Should I send them to this list, or attach to bugzilla 15214?

Definitely, attach to bugzilla 15214.

Best regards,

Mark Orciuch - [EMAIL PROTECTED]
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Planning for Jetspeed 1.4b4

2003-03-06 Thread Harald Ommang
On Thu, 06 Mar 2003 11:27:55 -0800 (PST), Santiago Gala wrote:

> 
> > 
> >  bug # 15214  
> > "Cleanup the logging. This is mainly housekeeping, but it include
ssurrounding
> > resource intensive debug logging with if (Log.getLogger().isDebugEnabled())
{}"
(snip) 
> The first one looks non-controversial and useful. If no one screams, go 
> for it.
> 
(snip)

I'm ready to start working on this.
Just a question, as I'm fairly new to the apache way of contributing. (Don't
worry I've been designing and developing and coding for ages...) In what form do
you committers want me to send the updates for this? Patch pr. file?, Patch pr.
package? Patch pr. "batch" of work I do? 
Should I send them to this list, or attach to bugzilla 15214?

Harald

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: ???NEW WebPageService/WebPageServlet NEW ???

2003-03-06 Thread Glen Carl
This is fine with me. I hope David Powers is seeing this email and can 
check out what was done with the WebBrowserPortlet and the 
IframeProxyPortlet. These portlets are included in the jar I referenced.
Glen

David Sean Taylor wrote:
On Wednesday, March 5, 2003, at 02:58  PM, Glen Carl wrote:

At http://buonvia.com/jetspeed is the proxyPortlets that Casimiro 
Lovato-Winston and I contributed to the Jetspeed Community. To my 
knowledge, these portlets were never checked in.

I want to contribute my enhanced versions of these, but I am swamped 
with client work. Maybe in a couple of weeks, I will be able to make 
the enhance versions available. For now, the proxyPortlets at my site 
may be helpful in the creation of your httpProxyPortlets.
You will need to extract the jar to get documentation on how to 
integrate.
Glen


I am -1 on this.
My vote is that you work with David Powers on making one good 
implementation.

--
David Sean Taylor
Bluesunrise Software
[EMAIL PROTECTED]
+01 707 773-4646


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: Question about JspAction

2003-03-06 Thread Mark Orciuch
Scott,

>  Yes, all VelocityPortlets get their own context.  I am going try
> using HashMap request attribute "templateMap" keyed by portlet id
> to overcome this.  I am also going attempt break the template
> logic into a single, separate component that can be used by
> VelocityPortlets and JspPortlets.  That way when changes happen,
> the impact on both types of portlets will be more apparent.  I

That was my original goal, to create a base TemplatePortlet and
TemplatePortletAction, but no time :( Please open up a Bugzilla issue for
this. Thanks!

BTW: The setTemplate issue is tracked here:
http://issues.apache.org/bugzilla/show_bug.cgi?id=16443.

> think I am one of those rare exceptions that use both Velocity
> AND jsp portlets.

I'm using both Velocity and JSP as well.

Best regards,

Mark Orciuch - [EMAIL PROTECTED]
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Question about JspAction

2003-03-06 Thread Weaver, Scott
> -Original Message-
> From: Todd Kuebler [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 06, 2003 2:09 PM
> To: Jetspeed Developers List
> Subject: RE: Question about JspAction
>
> This is why I think all templating portlet functions should be commonly
> held in something like the MVCPortlet I've proposed.
> (http://www.kuebler.org/MVCPortlet/MVCPortlet.html)  Actions, templates,
> etc should be handled the same way for all, which to me means a common
> portlet doing the handling.

Todd,

I agree with you 100% percent on this.  I am going to try a break up the 
VelocityPortlet and JspPortlet into as much a common component as I possibly can.  I 
am going to have VelocityPortlet and JspPortlet implement a common TemplatePortlet 
interface to help with this.  The MVCPortlet is a great idea, but we need to fix what 
current implementation portlet developers are used to before we radically change the 
paradigm.

Scott



RE: Question about JspAction

2003-03-06 Thread Weaver, Scott
> I seem to remember attempting to use
> data.getRequest().setAttribute(JspPortlet.TEMPLATE, template) to achieve
> per-request scope but I ran into problems. If I remember correctly, with
> multiple JspPortlets on the same page, overriding template this way
> changed
> the template for ALL JspPortlets. Isn't the request object shared between
> all instances of JspPortlet on single pane whereas each VelocityPortlet
> gets
> its own context object? Please set me straight on that.

 Yes, all VelocityPortlets get their own context.  I am going try using HashMap 
request attribute "templateMap" keyed by portlet id to overcome this.  I am also going 
attempt break the template logic into a single, separate component that can be used by 
VelocityPortlets and JspPortlets.  That way when changes happen, the impact on both 
types of portlets will be more apparent.  I think I am one of those rare exceptions 
that use both Velocity AND jsp portlets.

Scott

> -Original Message-
> From: Mark Orciuch [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 06, 2003 2:06 PM
> To: Jetspeed Developers List
> Subject: RE: Question about JspAction
> 
> >
> > Yup, it works ;)
> >
> 
> Cool, I'll make the change and un-deprecate the original method signature.
> 
> > In the same vein...
> >
> > I have also noticed inconsistencies between the VelocityPortlet
> > and JspPortlet in terms of overriding the template.
> > VelocityPortlet uses a per request template override via Context,
> > which is initialized every request.  On the other hand JspPortlet
> > is using per-session template override via
> > PortletSessionState.setAttribute.   This kind of threw when I
> > restored from by custom jsp portlet customizer and the customize
> > screen was there instead of the default template that, IMOHO,
> > should have been there.
> >
> 
> I seem to remember attempting to use
> data.getRequest().setAttribute(JspPortlet.TEMPLATE, template) to achieve
> per-request scope but I ran into problems. If I remember correctly, with
> multiple JspPortlets on the same page, overriding template this way
> changed
> the template for ALL JspPortlets. Isn't the request object shared between
> all instances of JspPortlet on single pane whereas each VelocityPortlet
> gets
> its own context object? Please set me straight on that.
> 
> > I think it should be decided on which way this should work for
> > all types of template-based portlets, either per-request or
> > per-session.  It could easily work both ways depending on the
> > portlet developer's intention by allowing the developer to
> > specify a "template.override.ttl" in the registry on a
> > per-portlet basis.  Values could be either "request" or "session"
> > and should default to "request" as it is what most developers
> > will be used to.
> >
> 
> I agree. You can log that as an enhancement in Bugzilla.
> 
> Best regards,
> 
> Mark Orciuch - [EMAIL PROTECTED]
> Jakarta Jetspeed - Enterprise Portal in Java
> http://jakarta.apache.org/jetspeed/
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


RE: Question about JspAction

2003-03-06 Thread Mark Orciuch
Todd,

>
> This is why I think all templating portlet functions should be commonly
> held in something like the MVCPortlet I've proposed.
> (http://www.kuebler.org/MVCPortlet/MVCPortlet.html)  Actions, templates,
> etc should be handled the same way for all, which to me means a common
> portlet doing the handling.
>

There's definitely interest in your proposal. It's just everyone is
preoccupied with other tasks right now. If you created a Bugzilla
enhancement request, it would ensure that it doesn't get forgotten. Thanks
again!

Best regards,

Mark Orciuch - [EMAIL PROTECTED]
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Question about JspAction

2003-03-06 Thread Todd Kuebler
This is why I think all templating portlet functions should be commonly 
held in something like the MVCPortlet I've proposed. 
(http://www.kuebler.org/MVCPortlet/MVCPortlet.html)  Actions, templates, 
etc should be handled the same way for all, which to me means a common 
portlet doing the handling.

-tk

At 01:53 PM 3/6/2003 -0500, Weaver, Scott wrote:
Yup, it works ;)

In the same vein...

I have also noticed inconsistencies between the VelocityPortlet and 
JspPortlet in terms of overriding the template.  VelocityPortlet uses a 
per request template override via Context, which is initialized every 
request.  On the other hand JspPortlet is using per-session template 
override via PortletSessionState.setAttribute.   This kind of threw when I 
restored from by custom jsp portlet customizer and the customize screen 
was there instead of the default template that, IMOHO, should have been 
there.

I think it should be decided on which way this should work for all types 
of template-based portlets, either per-request or per-session.  It could 
easily work both ways depending on the portlet developer's intention by 
allowing the developer to specify a "template.override.ttl" in the 
registry on a per-portlet basis.  Values could be either "request" or 
"session" and should default to "request" as it is what most developers 
will be used to.

My $0.02,
Scott


> -Original Message-
> From: Mark Orciuch [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 06, 2003 1:39 PM
> To: Jetspeed Developers List
> Subject: RE: Question about JspAction
>
> Scott,
>
> Either I didn't think about doing it this way OR it didn't work (I don't
> remember now but most likely I didn't think about it). Have you tried
> using
> your method? It seems that it should work though...
>
> Best regards,
>
> Mark Orciuch - [EMAIL PROTECTED]
> Jakarta Jetspeed - Enterprise Portal in Java
> http://jakarta.apache.org/jetspeed/
>
> > -Original Message-
> > From: Weaver, Scott [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, March 06, 2003 12:29 PM
> > To: 'Jetspeed Developers List'
> > Subject: Question about JspAction
> >
> >
> > Why was setTemplate(RunData data, String template) deprecated and
> > public void setTemplate(RunData data, Portlet portlet, String template)
> > added?  The same functionality could have been achieved like this
> > with out deprecating the existing method signature and adding a new one:
> >
> > public void setTemplate(RunData data, String template)
> > {
> >   Portlet portlet = (Portlet) data.getRequest().getAttribute("portlet");
> >   if(template != null)
> >   {
> > PortletSessionState.setAttribute(portlet, data,
> > JspPortlet.TEMPLATE,
> > template);
> >   }
> >   else
> >   {
> > PortletSessionState.clearAttribute(portlet, data,
> > JspPortlet.TEMPLATE);
> >   }
> >
> > }
> >
> > The Portlet is ALWAYS placed in the request by the
> > JspPortlet.getContent() prior ActionLoader.exec().  Is there
> > something I am missing here that is blatantly obvious?  Is there
> > a chance that JspAction.setTemplate() is invoked prior to
> > JspPortlet.getContent()?
> >
> > Thanks,
> > Scott
> >
> >
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: Question about JspAction

2003-03-06 Thread Mark Orciuch
>
> Yup, it works ;)
>

Cool, I'll make the change and un-deprecate the original method signature.

> In the same vein...
>
> I have also noticed inconsistencies between the VelocityPortlet
> and JspPortlet in terms of overriding the template.
> VelocityPortlet uses a per request template override via Context,
> which is initialized every request.  On the other hand JspPortlet
> is using per-session template override via
> PortletSessionState.setAttribute.   This kind of threw when I
> restored from by custom jsp portlet customizer and the customize
> screen was there instead of the default template that, IMOHO,
> should have been there.
>

I seem to remember attempting to use
data.getRequest().setAttribute(JspPortlet.TEMPLATE, template) to achieve
per-request scope but I ran into problems. If I remember correctly, with
multiple JspPortlets on the same page, overriding template this way changed
the template for ALL JspPortlets. Isn't the request object shared between
all instances of JspPortlet on single pane whereas each VelocityPortlet gets
its own context object? Please set me straight on that.

> I think it should be decided on which way this should work for
> all types of template-based portlets, either per-request or
> per-session.  It could easily work both ways depending on the
> portlet developer's intention by allowing the developer to
> specify a "template.override.ttl" in the registry on a
> per-portlet basis.  Values could be either "request" or "session"
> and should default to "request" as it is what most developers
> will be used to.
>

I agree. You can log that as an enhancement in Bugzilla.

Best regards,

Mark Orciuch - [EMAIL PROTECTED]
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Question about JspAction

2003-03-06 Thread Weaver, Scott
Yup, it works ;)

In the same vein...

I have also noticed inconsistencies between the VelocityPortlet and JspPortlet in 
terms of overriding the template.  VelocityPortlet uses a per request template 
override via Context, which is initialized every request.  On the other hand 
JspPortlet is using per-session template override via 
PortletSessionState.setAttribute.   This kind of threw when I restored from by custom 
jsp portlet customizer and the customize screen was there instead of the default 
template that, IMOHO, should have been there.  

I think it should be decided on which way this should work for all types of 
template-based portlets, either per-request or per-session.  It could easily work both 
ways depending on the portlet developer's intention by allowing the developer to 
specify a "template.override.ttl" in the registry on a per-portlet basis.  Values 
could be either "request" or "session" and should default to "request" as it is what 
most developers will be used to.

My $0.02,
Scott



> -Original Message-
> From: Mark Orciuch [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 06, 2003 1:39 PM
> To: Jetspeed Developers List
> Subject: RE: Question about JspAction
> 
> Scott,
> 
> Either I didn't think about doing it this way OR it didn't work (I don't
> remember now but most likely I didn't think about it). Have you tried
> using
> your method? It seems that it should work though...
> 
> Best regards,
> 
> Mark Orciuch - [EMAIL PROTECTED]
> Jakarta Jetspeed - Enterprise Portal in Java
> http://jakarta.apache.org/jetspeed/
> 
> > -Original Message-
> > From: Weaver, Scott [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, March 06, 2003 12:29 PM
> > To: 'Jetspeed Developers List'
> > Subject: Question about JspAction
> >
> >
> > Why was setTemplate(RunData data, String template) deprecated and
> > public void setTemplate(RunData data, Portlet portlet, String template)
> > added?  The same functionality could have been achieved like this
> > with out deprecating the existing method signature and adding a new one:
> >
> > public void setTemplate(RunData data, String template)
> > {
> >   Portlet portlet = (Portlet) data.getRequest().getAttribute("portlet");
> >   if(template != null)
> >   {
> > PortletSessionState.setAttribute(portlet, data,
> > JspPortlet.TEMPLATE,
> > template);
> >   }
> >   else
> >   {
> > PortletSessionState.clearAttribute(portlet, data,
> > JspPortlet.TEMPLATE);
> >   }
> >
> > }
> >
> > The Portlet is ALWAYS placed in the request by the
> > JspPortlet.getContent() prior ActionLoader.exec().  Is there
> > something I am missing here that is blatantly obvious?  Is there
> > a chance that JspAction.setTemplate() is invoked prior to
> > JspPortlet.getContent()?
> >
> > Thanks,
> > Scott
> >
> >
> >
> >
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


RE: Question about JspAction

2003-03-06 Thread Mark Orciuch
Scott,

Either I didn't think about doing it this way OR it didn't work (I don't
remember now but most likely I didn't think about it). Have you tried using
your method? It seems that it should work though...

Best regards,

Mark Orciuch - [EMAIL PROTECTED]
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/

> -Original Message-
> From: Weaver, Scott [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 06, 2003 12:29 PM
> To: 'Jetspeed Developers List'
> Subject: Question about JspAction
>
>
> Why was setTemplate(RunData data, String template) deprecated and
> public void setTemplate(RunData data, Portlet portlet, String template)
> added?  The same functionality could have been achieved like this
> with out deprecating the existing method signature and adding a new one:
>
> public void setTemplate(RunData data, String template)
> {
>   Portlet portlet = (Portlet) data.getRequest().getAttribute("portlet");
>   if(template != null)
>   {
> PortletSessionState.setAttribute(portlet, data,
> JspPortlet.TEMPLATE,
> template);
>   }
>   else
>   {
> PortletSessionState.clearAttribute(portlet, data,
> JspPortlet.TEMPLATE);
>   }
>
> }
>
> The Portlet is ALWAYS placed in the request by the
> JspPortlet.getContent() prior ActionLoader.exec().  Is there
> something I am missing here that is blatantly obvious?  Is there
> a chance that JspAction.setTemplate() is invoked prior to
> JspPortlet.getContent()?
>
> Thanks,
> Scott
>
>
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Question about JspAction

2003-03-06 Thread Weaver, Scott
Why was setTemplate(RunData data, String template) deprecated and
public void setTemplate(RunData data, Portlet portlet, String template)
added?  The same functionality could have been achieved like this with out deprecating 
the existing method signature and adding a new one:

public void setTemplate(RunData data, String template)
{
  Portlet portlet = (Portlet) data.getRequest().getAttribute("portlet");
  if(template != null)
  {
PortletSessionState.setAttribute(portlet, data, JspPortlet.TEMPLATE,   
template);
  }
  else
  {
PortletSessionState.clearAttribute(portlet, data, JspPortlet.TEMPLATE);
  }
 
}

The Portlet is ALWAYS placed in the request by the JspPortlet.getContent() prior 
ActionLoader.exec().  Is there something I am missing here that is blatantly obvious?  
Is there a chance that JspAction.setTemplate() is invoked prior to 
JspPortlet.getContent()?

Thanks,
Scott





DO NOT REPLY [Bug 17734] - SecurityCacheImpl overwites cached permissions

2003-03-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17734

SecurityCacheImpl overwites cached permissions





--- Additional Comments From [EMAIL PROTECTED]  2003-03-06 18:04 ---
Created an attachment (id=5185)
patch for SecurityCacheImpl

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: cvs commit: jakarta-jetspeed/src/java/org/apache/jetspeed/services/template JetspeedTemplateLocatorService.java

2003-03-06 Thread Mark Orciuch
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 02, 2003 1:40 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit:
> jakarta-jetspeed/src/java/org/apache/jetspeed/services/template
> JetspeedTemplateLocatorService.java
>

Raphael,

What exactly was the change to this class? I couldn't find any information
in Bugzilla or mailing list (perhaps I didn't look hard enough). I am trying
to figure out why this exception occurs intermittently:

[03 Mar 2003 20:12:35 ERROR] - Error rendering Velocity template:
layouts/default.vm: Unable to find resource 'layouts/default.vm'
[03 Mar 2003 20:12:35 ERROR] - Error rendering Velocity template:
layouts/default.vm: Unable to find resource 'layouts/default.vm'
org.apache.velocity.exception.ResourceNotFoundException: Unable to find
resource 'layouts/default.vm'
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(Resour
ceManagerImpl.java:501)
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(Resourc
eManagerImpl.java:384)
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java
:814)
at
org.apache.velocity.runtime.RuntimeSingleton.getTemplate(RuntimeSingleton.ja
va:355)
at org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java:482)
at org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java:461)
rethrown as
org.apache.turbine.util.TurbineException: Error rendering Velocity template:
layouts/default.vm: Unable to find resource 'layouts/default.vm'
at
org.apache.turbine.services.velocity.TurbineVelocityService.renderingError(T
urbineVelocityService.java:533)
at
org.apache.turbine.services.velocity.TurbineVelocityService.decodeRequest(Tu
rbineVelocityService.java:499)
at
org.apache.turbine.services.velocity.TurbineVelocityService.handleRequest(Tu
rbineVelocityService.java:336)
at
org.apache.turbine.services.velocity.TurbineVelocity.handleRequest(TurbineVe
locity.java:143)
at
org.apache.turbine.modules.layouts.VelocityDirectLayout.doBuild(VelocityDire
ctLayout.java:106)

I'm hoping that your fix addresses this problem.

Best regards,

Mark Orciuch - [EMAIL PROTECTED]
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Weird Jetspeed security caching behavior

2003-03-06 Thread Stuart Belden
Yup, it's a bug.  Bug report w/ patch coming shortly.

>>> [EMAIL PROTECTED] 03/05/03 12:19PM >>>
Environment: 1.4b3, Websphere, on Redhat 8

I'm getting really bizarre behavior with jetspeed security caching turned on; I'm 
wondering if it's my misunderstanding of how security caching works or if it's a bug.  
Here's the situation:





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 17734] New: - SecurityCacheImpl overwites cached permissions

2003-03-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17734

SecurityCacheImpl overwites cached permissions

   Summary: SecurityCacheImpl overwites cached permissions
   Product: Jetspeed
   Version: 1.4b4-dev /CVS
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Security
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


SecurityCacheImpl caches all existing roles and their associated permissions
when it is first invoked.  When assigning an existing role to any user,
SecurityCacheImpl adds that role for the user and then overwites that Role's
permissions with a blank HashMap.  This effectively removes all permissions for
that role for every user.

This can be fixed by checking to see if the Role has already been cached in
addRole(username, Role).  This check is already done in addRole(Role).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Updated MVC Portlet Proposal - website

2003-03-06 Thread Werner Ramaekers
looks great and i'm sure i can benefit from it, can not speak for others 
though,
please open a case in bugzilla so that we can have a look at the code 
(and also attach the contents of the page)

thanks

Werner

Todd Kuebler wrote:

Got this pretty well done and working for my project here at work and 
moving on to something else, but wanted to double check if there was 
any interest in it before I took the website down.  If there is 
positive interest I'll be happy to open a bugzilla case and attach the 
code, otherwise no sweat and saves us all a lot of work.  :)

-tk

At 02:37 PM 2/28/2003 -0800, Todd Kuebler wrote:

You can see the modified proposal, integrated UML diagram and 
javadocs at:

 http://www.kuebler.org/MVCPortlet/MVCPortlet.html

This is my home cable connection, so go gentle on it. ;)

%regards -tk

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
--
ir. Werner Ramaekers
Enterprise Java Solutions Architect - Shift@
BeJUG steering committee member
JBoss Certified Services Partner
Read my Blog at http://www.werner.be
"May the source be with you."
--


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [patch] JetspeedLocalizationService

2003-03-06 Thread Massimiliano Dessì
Attached to the mail is the new version portlet to
change the language with a servlet filter, the turbine
resources.prop to enable the jetspeed Localization
Service and localization tool and a diagram to explain
the flow.
I have modified the Localization service only to
change the language witout the browser role (language
header).
The language changes at runtime.
I don't understand your problem with the change
language.
Test this file and send a feedback to me ,
in this way i can help you

Massimiliano


 --- Jon Evans <[EMAIL PROTECTED]> ha scritto: > Hi
David,
> 
> David Sean Taylor wrote:
> 
> > The patch isn't necessary I just committed a patch
> from
> > Missimilliano Dessi. It works fine as is. Although
> I thought we had
> > country flag icons with the original portlet.
> 
> I have just got round to using the latest CVS.  I
> like the fact that
> the changeLanguage portlet is now a .vm, it will
> make it a lot easier
> to change the look and feel for my site.
> 
> I'm still concerned though with
>
org.apache.jetspeed.services.customlocalization.JetspeedLocalizationService.
> 
> It still doesn't seem to work if you have more than
> one bundle defined
> in locale.default.bundles.  It only seems to look at
> the first bundle.
> 
> If you look at the class, it extends
> TurbineLocalizationService.
> JetspeedLocalizationService implements an
> initBundleNames() method
> which populates an instance variable String[]
> bundleNames.  But all of
> the getString(...) methods call
> super.getString(...), where
> TurbineLocalizationService will use its own instance
> variables and will
> not find the strings.
> 
> 
> Let me put it another way.  Each class defines an
> identical set of 
> instance variables, like this:
> 
> JetspeedLocalizationService
> TurbineLocalizationService
> ===
> ===
> private Hashtable bundles;  private Hashtable
> bundles;
> private String bundleNames[];   private String
> bundleNames[];
> private Locale defaultLocale;   private Locale
> defaultLocale;
> private String defaultLanguage; private String
> defaultLanguage;
> private String defaultCountry;  private String
> defaultCountry;
> 
> After JetspeedLocalizationService.init() is called
> they look like this:
> 
> JetspeedLocalizationService
> TurbineLocalizationService
> ===
> ==
> bundles  null   bundles set
> bundleNames[]setbundleNames[]   null
> defaultLocalenull   defaultLocale   set
> defaultLanguage  null   defaultLanguage set
> defaultCountry   null   defaultCountry  set
> 
> when getString(String bundleName, Locale locale,
> String key) is called
> in JetspeedLocalizationService, it calls
> super.getString(...).  This
> calls getBundle(String, Locale), which is
> implemented in
> JetspeedLocalizationService as a call to
> super.getBundle(String,
> Locale), so we are back to the code in
> TurbineLocalizationService.
> 
> getBundle(String, Locale) in
> TurbineLocalizationService returns the
> default bundle to the getString(...) method.
> 
> Back in getString(String bundleName, Locale locale,
> String key), we
> look up the requested key in the bundle, using
> getStringOrNull(), which 
> returns null because the string I'm looking for
> isn't in the first 
> bundle, it's in the second.
> 
> The next test is intended to determine whether we
> need to check the
> other bundles for the key.  The test is:
> 
>  // Look for text in list of default
> bundles.
>  if (value == null && bundleNames.length >
> 0)
> 
> At this point we throw a NullPointerException
> because bundleNames is
> null (it was never set in
> TurbineLocalizationService, only in
> JetspeedLocalizationService).
> 
> The whole of the JetspeedLocalizationService class
> can be reduced to a 
> single function, getLocale(RunData runData).
> 
> The attached patch does this, and seems to work. 
> Yes, I compiled from 
> clean this time. :-)
> 
> Jon
>  
>  
>  
>  
>  
> -- 
>  
> Merlin Information Systems Limited, 
>  
> Merlin House, Gawcott Road, Buckingham, United
> Kingdom. MK18 1TN
>  
> Tel: +44 (0) 1280 824331  Fax: +44 (0) 1280 824112
>  
> 
>  
> http://www.misgl.com
>  
> Provider of IT Services and Online Portal Support
> Services. 
>  
>  
>  
> Confidentiality:
>  
> The information contained in this email (including
> any attachments) is confidential and is intended
> solely for the use of the named addressee. Access,
> copying or re-use of the information in it by any
> other person is not authorised. If you are not the
> intended recipient, please notify us immediately by
> telephone or by e-mail to [EMAIL PROTECTED]
>  
> 
>  
>  
>  
> *** This mail has been scanned for viruses ***
>  
> 
>  
> > Index:
>
src/java/org/apache/jetspeed/services/customlocalization/JetspeedLocalizationService.java
>
===
> RCS file:
>

Re: Updated MVC Portlet Proposal - website

2003-03-06 Thread Todd Kuebler
Got this pretty well done and working for my project here at work and 
moving on to something else, but wanted to double check if there was any 
interest in it before I took the website down.  If there is positive 
interest I'll be happy to open a bugzilla case and attach the code, 
otherwise no sweat and saves us all a lot of work.  :)

-tk

At 02:37 PM 2/28/2003 -0800, Todd Kuebler wrote:

You can see the modified proposal, integrated UML diagram and javadocs at:

 http://www.kuebler.org/MVCPortlet/MVCPortlet.html

This is my home cable connection, so go gentle on it. ;)

%regards -tk

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


DO NOT REPLY [Bug 17715] - JetspeedLocalizationService only looks at first resource bundle

2003-03-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17715

JetspeedLocalizationService only looks at first resource bundle





--- Additional Comments From [EMAIL PROTECTED]  2003-03-06 11:08 ---
Created an attachment (id=5177)
Patch to fix JetspeedLocalizationService

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 17715] New: - JetspeedLocalizationService only looks at first resource bundle

2003-03-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17715

JetspeedLocalizationService only looks at first resource bundle

   Summary: JetspeedLocalizationService only looks at first resource
bundle
   Product: Jetspeed
   Version: 1.4b4-dev /CVS
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Miscellaneous
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


All of my portlets are localized to 2 (in one project) or 5 (in another)
languages.  I have my own resource bundle set containing the strings for the
portlets.

I am using JetspeedLocalizationService because I need the users to be able to
switch locale on the fly by clicking a link on the page.  Also it's a great
sales feature when the customer sees that.

JetspeedLocalizationService doesn't work if you have more than one bundle
defined in locale.default.bundles.  It only looks at the first bundle.  You get
a null pointer exception when you try to look up a key that isn't in the first
bundle in the list.

If you look at the class, it extends TurbineLocalizationService.
JetspeedLocalizationService implements an initBundleNames() method
which populates an instance variable String[] bundleNames.  But all of
the getString(...) methods call super.getString(...), where
TurbineLocalizationService will use its own instance variables and will
not find the strings.

Let me put it another way.  Each class defines an identical set of instance
variables, like this:

JetspeedLocalizationService TurbineLocalizationService
=== ===
private Hashtable bundles;  private Hashtable bundles;
private String bundleNames[];   private String bundleNames[];
private Locale defaultLocale;   private Locale defaultLocale;
private String defaultLanguage; private String defaultLanguage;
private String defaultCountry;  private String defaultCountry;

After JetspeedLocalizationService.init() is called they look like this:

JetspeedLocalizationService TurbineLocalizationService
=== ==
bundles  null   bundles set
bundleNames[]setbundleNames[]   null
defaultLocalenull   defaultLocale   set
defaultLanguage  null   defaultLanguage set
defaultCountry   null   defaultCountry  set

when getString(String bundleName, Locale locale, String key) is called
in JetspeedLocalizationService, it calls super.getString(...).  This
calls getBundle(String, Locale), which is implemented in
JetspeedLocalizationService as a call to super.getBundle(String,
Locale), so we are back to the code in TurbineLocalizationService.

getBundle(String, Locale) in TurbineLocalizationService returns the
default bundle to the getString(...) method.

Back in getString(String bundleName, Locale locale, String key), we
look up the requested key in the bundle, using getStringOrNull(), which returns
null because the string I'm looking for isn't in the first bundle, it's in the
second.

The next test is intended to determine whether we need to check the
other bundles for the key.  The test is:

// Look for text in list of default bundles.
if (value == null && bundleNames.length > 0)

At this point we throw a NullPointerException because bundleNames is
null (it was never set in TurbineLocalizationService, only in
JetspeedLocalizationService).

The bizarre thing is that although it extends TurbineLocalizationService, it
needlessly re-implements most of the methods with bodies which just call
super..

The whole of the JetspeedLocalizationService class can be reduced to a single
function, getLocale(RunData runData).  I will attach a patch to this bug which
does this.  My development copy of Jetspeed is patched like this and it works fine.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Planning for Jetspeed 1.4b4

2003-03-06 Thread Santiago Gala
Harald Ommang wrote:
If you need help with any issues on the tod list, such as:

 bug # 15214  
"Cleanup the logging. This is mainly housekeeping, but it include ssurrounding
resource intensive debug logging with if (Log.getLogger().isDebugEnabled()) {}"

or

bug "#5440  
Move localization property files,
/src/java/org/apache/jetspeed/modules/localization/JetspeedLocalization.properties, to the WEB-INF/conf directory. This is simplify the configuration process,
i.e. the number of directories.. "

I might be able to spend a few hours on this, or any other pressing matters.

The first one looks non-controversial and useful. If no one screams, go 
for it.

The second I'm not so sure. Although again it looks simple. But it 
requires more testing.


Harald

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]