Re: Planning for Jetspeed 1.4b4
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]
DO NOT REPLY [Bug 17715] New: - JetspeedLocalizationService only looks at first resource bundle
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17715. 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.method. 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]
DO NOT REPLY [Bug 17715] - JetspeedLocalizationService only looks at first resource bundle
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17715. 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]
Re: Updated MVC Portlet Proposal - website
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]
Re: [patch] JetspeedLocalizationService
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: /home/cvspublic/jakarta-jetspeed/src/java/org/apache/jetspeed/services/customlocalization/JetspeedLocalizationService.java,v retrieving revision 1.4 diff -u -r1.4
Re: Updated MVC Portlet Proposal - website
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]
DO NOT REPLY [Bug 17734] New: - SecurityCacheImpl overwites cached permissions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17734. 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: Weird Jetspeed security caching behavior
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: snip - 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
-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]
DO NOT REPLY [Bug 17734] - SecurityCacheImpl overwites cached permissions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17734. 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]
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
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
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
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
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
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
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
-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
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: ???NEW WebPageService/WebPageServlet NEW ???
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: Planning for Jetspeed 1.4b4
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: Planning for Jetspeed 1.4b4
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]
DO NOT REPLY [Bug 17632] - patch to add portlet.getContent() load time to PortletStats service
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17632. 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]
[CONTRIBUTION] ic-no.gif
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]
WebPageProxyPortlet
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]
Re: [CONTRIBUTION] ic-no.gif
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]
Re: [CONTRIBUTION] ic-no.gif
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]
DO NOT REPLY [Bug 15214] - Cleanup Logging
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15214. 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]
DO NOT REPLY [Bug 15214] - Cleanup Logging
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15214. 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.class); Comments? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] JetspeedLocalizationService
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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15214. 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]
DO NOT REPLY [Bug 15214] - Cleanup Logging
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15214. 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]
Re: WebPageProxyPortlet
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]
RE: Question about JspAction
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
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: WebPageProxyPortlet
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]
DO NOT REPLY [Bug 17756] New: - MVCPortlet Proposal
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17756. 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]
DO NOT REPLY [Bug 17756] - MVCPortlet Proposal
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17756. 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]
