velocity $skin variable in top.vm or bottom.vm
How can I make the $skin variable available top.vm or bottom.vm files? Judging from the Java code, this line is used to put the skin variable in the Velocity context for the portlets: context.put( skin, this.getPortlets().getPortletConfig().getPortletSkin() ); Is there any way that the variable is also visible in the top and bottom Velocity files? Roel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Portlet titles gone in J2-M2?
Correct, in the portlet.xml. What's strange, is that the first time I started-up the portal (using M2), I was able to see the titles ... but after paging around a bit, they vanished. - Frank -Original Message- From: Randy Watler [mailto:[EMAIL PROTECTED] Sent: Monday, April 11, 2005 06:38 PM To: Jetspeed Users List Subject: Re: Portlet titles gone in J2-M2? Frank, I have heard there were some issues that cropped up right around the M2 release regarding titles. How are you defining them? In portlet.xml? Randy Frank Villarreal wrote: To all: Is it just me, or did the portlet title functionality get bugged out between release M1 and M2? I upgraded my installation of J2 and now all my portlet titles have vanished ... they display empty strings ?!? Of course perhaps I screwed something up during my upgrade process. Just curious if anyone else out there is experiencing the same issue. - Frank - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Portlet titles gone in J2-M2?
I was running on my default locale (en_US), however what classes did you (Bhave to update? If possible, I'd like to isolate and just download the (Bpatched classes. (B (BThanks, (B (BFrank (B (B -Original Message- (B From: Shinsuke SUGAYA [mailto:[EMAIL PROTECTED] (B Sent: Monday, April 11, 2005 07:44 PM (B To: Jetspeed Users List (B Subject: Re: Portlet titles gone in J2-M2? (B (B (B Hi Frank, (B (B If you run J2 on locales other than en_US, it might occur.. (B After M2 release, I have fixed the portlet title handling issue. (B So, I think you can see the fix on CVS HEAD right now. (B (B Thanks, (B shinsuke (B (B To all: (B (B Is it just me, or did the portlet title functionality get (B bugged out between release M1 and M2? (B I upgraded my installation of J2 and now all my portlet titles (B have vanished ... they display (B empty strings ?!? Of course perhaps I screwed something up (B during my upgrade process. Just (B curious if anyone else out there is experiencing the same issue. (B (B - Frank (B (B (B __ (B Do You Yahoo!? (B Upgrade Your Life (B http://bb.yahoo.co.jp/ (B (B (B - (B To unsubscribe, e-mail: [EMAIL PROTECTED] (B For additional commands, e-mail: [EMAIL PROTECTED] (B (B (B (B (B- (BTo unsubscribe, e-mail: [EMAIL PROTECTED] (BFor additional commands, e-mail: [EMAIL PROTECTED]
Re: Portlet titles gone in J2-M2?
Updated the following files: (B (Bshinsuke2005/04/08 17:24:45 (B (B Modified:components/registry/src/java/org/apache/jetspeed/om/impl (BLanguageImpl.java LanguageSetImpl.java (B components/registry/src/java/org/apache/jetspeed/om/portlet/impl (BPortletDefinitionImpl.java (B portal/src/java/org/apache/jetspeed/tools/pamanager (BPortletApplicationManager.java (B portal/src/java/org/apache/jetspeed/util/descriptor (BPortletApplicationDescriptor.java (BPortletApplicationWar.java (B (BThanks, (B shinsuke (B (B (BFrank Villarreal wrote: (B I was running on my default locale (en_US), however what classes did you (B have to update? If possible, I'd like to isolate and just download the (B patched classes. (B (B Thanks, (B (B Frank (B (B (B-Original Message- (BFrom: Shinsuke SUGAYA [mailto:[EMAIL PROTECTED] (BSent: Monday, April 11, 2005 07:44 PM (BTo: Jetspeed Users List (BSubject: Re: Portlet titles gone in J2-M2? (B (B (BHi Frank, (B (BIf you run J2 on locales other than en_US, it might occur.. (BAfter M2 release, I have fixed the portlet title handling issue. (BSo, I think you can see the fix on CVS HEAD right now. (B (BThanks, (B shinsuke (B (B (BTo all: (B (BIs it just me, or did the portlet title functionality get (B (Bbugged out between release M1 and M2? (B (BI upgraded my installation of J2 and now all my portlet titles (B (Bhave vanished ... they display (B (Bempty strings ?!? Of course perhaps I screwed something up (B (Bduring my upgrade process. Just (B (Bcurious if anyone else out there is experiencing the same issue. (B (B- Frank (B (B (B__ (BDo You Yahoo!? (BUpgrade Your Life (Bhttp://bb.yahoo.co.jp/ (B (B (B- (BTo unsubscribe, e-mail: [EMAIL PROTECTED] (BFor additional commands, e-mail: [EMAIL PROTECTED] (B (B (B (B (B (B - (B To unsubscribe, e-mail: [EMAIL PROTECTED] (B For additional commands, e-mail: [EMAIL PROTECTED] (B (B (B__ (BDo You Yahoo!? (BUpgrade Your Life (Bhttp://bb.yahoo.co.jp/ (B (B (B- (BTo unsubscribe, e-mail: [EMAIL PROTECTED] (BFor additional commands, e-mail: [EMAIL PROTECTED]
User Prefernces
Hi all, How do I add user Preferences directly in the database? I know that we can add it from the administrative portlets, but it is not feasible for me because I have an existing system with hudreds of users, and I cannot manually do that. I tried to enter records into PREFS_PROPERTY_KEY, and PREFS_PROPERTY_VALUE, and I used the node of /usr/admin/userinfo from the PREFS_NODE table when inserting in the PREFS_PROPERTY_VALUE table. Then I tried to login as admin/admin, but I only see user.name.given and user.name.family. I tried to change the values of tasteDudely to somethingElse and that something else does show up on the webpage. So it reads the DB, but doesn't show up the preference that I wrote in the DB. I think I am missing something else, but not sure what ... Thanks, Amit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
found fusion/pluto interaction bug
Hi all,
this mail should be of particular interest for David and Ate.
A few days ago I posted msg15905.html entitled Something weird happening with
fusion/pluto. In fact the navigational state IS the cause of the problem. I'd
like to have your opinion about how to workaround this as several solutions are
possible. Before explaining the solutions, here is the problem :
When you want to set the action of a form or have a link calling a portlet
action you must use either a portlet:actionURL or use
response.createActiontURL() method. This in turns calls the
PathInfoEncodingPortalURL which extends AbstractPortalURL. This implementation
of AbstractPortalURL adds a _ns:xxx element ni the request URL just after
contextPath+servletPath (this is for example /jetspeed/portal/) and then
appends the rest of the original request. This gives something like this :
/jetspeed/portal/_ns:xx/media-type/html/user/admin/page/new.psml/js_peid/PXXX
BUT the problem is that turbine reads the URL to get its parameter hashmap ready
this way : first element after context path + servlet path is meant to be
parameter name, and then URL is supposed to be constructed as an alternance
between paramter names and parameters values. This means that if you have such
a (normal jetspeed)URL :
/jetspeed/portal/media-type/html/user/admin/page/new.psml/js_peid/PXXX
the resulting hashmap will be :
{
media-type=html
user=admin
page=news.psml
js_peid=PXXX
}
but it the case of the URL returned by pluto, eveything is mixed up because
first element is navigational state which is not what turbine expects and has
nothing to do with a key value pair. This leads to such a hashmap :
{
_ns:xx=media-type
html=user
admin=page
js_peid=news.psml
PXX=
}
and of course when jetspeed wants to get the profile, it uses the parameters
found in runData object and searches for the page parameter which it doesn't
find. Jetspeed then constructs a default profile, pointing to default.psml
page. And this is why when you click on an action button in a JSR168 portlet
contained in a PSML page which is NOT default.psml you get redirected to
default.psml page (which is of course not what we want).
Now possible solutions are :
- rewrite DefaultJetspeedParameterParser and override setRequest method so that
it ignores the _ns:XXX element in URL (if it exists) and begins parsing right
after. This is not very elegant and is clearly a workaround
- Maybe configure pluto to use QueryStringEncodingPortalURL implementation of
AbstractPortletURL so that ns is put as a paramter in the URL. But I would know
how this is done in JSFusion and I don't know if jetspeed will be happy with
this knew and unknown parameter.
Question is : Ate and David what do you think about the best way to circumvent
this? Do you think it's possible to tell pluto not to add the ns element at all
?
Thanks for your help
Fabrice
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
CSS with TwoColumnLayout
Hello again - We are using the jetspeed-layout:VelocityTwoColumns layout successfully with JSPs on J2 M2. We have a CSS which defines styles for heading titles, etc. Can someone tell me where the CSS should be specified, given the HTML HEAD, BODY, etc. restrictions? Tried putting it in the JSP but that did not work. Should it go in a layout or decorator definition somewhere? Sample code would be much appreciated; not a Velocity guru... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: found fusion/pluto interaction bug
Fabrice,
First of all, thanks for diving into this problem.
I try to answer below but bear in mind I'm doing it just from the head as
my laptop crashed this morning and I'm in the middle of trying to recover
from it what I can...
Fabrice Dewasmes said:
Hi all,
this mail should be of particular interest for David and Ate.
A few days ago I posted msg15905.html entitled Something weird happening
with
fusion/pluto. In fact the navigational state IS the cause of the problem.
I'd
like to have your opinion about how to workaround this as several
solutions are
possible. Before explaining the solutions, here is the problem :
When you want to set the action of a form or have a link calling a portlet
action you must use either a portlet:actionURL or use
response.createActiontURL() method. This in turns calls the
PathInfoEncodingPortalURL which extends AbstractPortalURL. This
implementation
of AbstractPortalURL adds a _ns:xxx element ni the request URL just after
contextPath+servletPath (this is for example /jetspeed/portal/) and then
appends the rest of the original request. This gives something like this :
/jetspeed/portal/_ns:xx/media-type/html/user/admin/page/new.psml/js_peid/PXXX
BUT the problem is that turbine reads the URL to get its parameter hashmap
ready
this way : first element after context path + servlet path is meant to be
parameter name, and then URL is supposed to be constructed as an
alternance
between paramter names and parameters values. This means that if you have
such
a (normal jetspeed)URL :
/jetspeed/portal/media-type/html/user/admin/page/new.psml/js_peid/PXXX
the resulting hashmap will be :
{
media-type=html
user=admin
page=news.psml
js_peid=PXXX
}
but it the case of the URL returned by pluto, eveything is mixed up
because
first element is navigational state which is not what turbine expects and
has
nothing to do with a key value pair. This leads to such a hashmap :
{
_ns:xx=media-type
html=user
admin=page
js_peid=news.psml
PXX=
}
and of course when jetspeed wants to get the profile, it uses the
parameters
found in runData object and searches for the page parameter which it
doesn't
find. Jetspeed then constructs a default profile, pointing to default.psml
page. And this is why when you click on an action button in a JSR168
portlet
contained in a PSML page which is NOT default.psml you get redirected to
default.psml page (which is of course not what we want).
Now possible solutions are :
- rewrite DefaultJetspeedParameterParser and override setRequest method so
that
it ignores the _ns:XXX element in URL (if it exists) and begins parsing
right
after. This is not very elegant and is clearly a workaround
- Maybe configure pluto to use QueryStringEncodingPortalURL implementation
of
AbstractPortletURL so that ns is put as a paramter in the URL. But I would
know
how this is done in JSFusion and I don't know if jetspeed will be happy
with
this knew and unknown parameter.
I think for just testing out your solution, the last option is the easiest
and quickest to realize and test (in the end, the first might be the
better solution or maybe even another, but for that I'll have to
investigate this first).
Using the QueryStringEncodingPortalURL is configured against Jetspeed, not
Pluto.
You should be able to do so in the jetspeed-spring.xml under
WEB-INF/assembly. Lookup the NavigationalStateComponent bean definition.
One of the constructor arguments (I think the second) defined the
PortalURL implementation to use.
Just try it out. If it solves your problem we will try to define the real
solution after that.
Regards, Ate
Question is : Ate and David what do you think about the best way to
circumvent
this? Do you think it's possible to tell pluto not to add the ns element
at all
?
Thanks for your help
Fabrice
-
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: found fusion/pluto interaction bug
Hi, I think for just testing out your solution, the last option is the easiest and quickest to realize and test (in the end, the first might be the better solution or maybe even another, but for that I'll have to investigate this first). Using the QueryStringEncodingPortalURL is configured against Jetspeed, not Pluto. You should be able to do so in the jetspeed-spring.xml under WEB-INF/assembly. Lookup the NavigationalStateComponent bean definition. One of the constructor arguments (I think the second) defined the PortalURL implementation to use. yes I found this parameter just after having sent my email. Just try it out. If it solves your problem we will try to define the real solution after that. Changing navaigational state component strategy works like a charm. The only thing I'm unsure is (but I will have to double check QueryStringEncodingPortalURL) how this class handles previously existing parameter in the URL: are they preserved ? Anyway, maybe that we should look for a better way to circumvent the problem. What's your opinion ? regards Fabrice Regards, Ate Question is : Ate and David what do you think about the best way to circumvent this? Do you think it's possible to tell pluto not to add the ns element at all ? Thanks for your help Fabrice - 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] -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: found fusion/pluto interaction bug]
Sorry, didn't notice at first I responded to Fabrice directly and not to the list. Original Message Subject: Re: found fusion/pluto interaction bug From:Ate Douma [EMAIL PROTECTED] Date:Tue, April 12, 2005 17:44 To: Fabrice Dewasmes [EMAIL PROTECTED] -- Fabrice Dewasmes said: Hi, I think for just testing out your solution, the last option is the easiest and quickest to realize and test (in the end, the first might be the better solution or maybe even another, but for that I'll have to investigate this first). Using the QueryStringEncodingPortalURL is configured against Jetspeed, not Pluto. You should be able to do so in the jetspeed-spring.xml under WEB-INF/assembly. Lookup the NavigationalStateComponent bean definition. One of the constructor arguments (I think the second) defined the PortalURL implementation to use. yes I found this parameter just after having sent my email. Just try it out. If it solves your problem we will try to define the real solution after that. Changing navaigational state component strategy works like a charm. Great! The only thing I'm unsure is (but I will have to double check QueryStringEncodingPortalURL) how this class handles previously existing parameter in the URL: are they preserved ? Yes. No difference there. Anyway, maybe that we should look for a better way to circumvent the problem. I agree. What's your opinion ? I don't have any at the moment. I would need time to investigate this more, but I won't have time for that before the end of this week. I expect that David will be able to give a better response (if he reads the mailing list today, I know he too is covered in work till at least Thursday). Regards, Ate regards Fabrice Regards, Ate Question is : Ate and David what do you think about the best way to circumvent this? Do you think it's possible to tell pluto not to add the ns element at all ? Thanks for your help Fabrice - 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] -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: found fusion/pluto interaction bug]
I was planning on release 1.6 today and getting it over with. I'll look into once I get started here. join me out on irc if you get a chance (i'll be starting here in 30 min or so) how bad is the hard drive situation? Ate Douma wrote: Sorry, didn't notice at first I responded to Fabrice directly and not to the list. Original Message Subject: Re: found fusion/pluto interaction bug From:Ate Douma [EMAIL PROTECTED] Date:Tue, April 12, 2005 17:44 To: Fabrice Dewasmes [EMAIL PROTECTED] -- Fabrice Dewasmes said: Hi, I think for just testing out your solution, the last option is the easiest and quickest to realize and test (in the end, the first might be the better solution or maybe even another, but for that I'll have to investigate this first). Using the QueryStringEncodingPortalURL is configured against Jetspeed, not Pluto. You should be able to do so in the jetspeed-spring.xml under WEB-INF/assembly. Lookup the NavigationalStateComponent bean definition. One of the constructor arguments (I think the second) defined the PortalURL implementation to use. yes I found this parameter just after having sent my email. Just try it out. If it solves your problem we will try to define the real solution after that. Changing navaigational state component strategy works like a charm. Great! The only thing I'm unsure is (but I will have to double check QueryStringEncodingPortalURL) how this class handles previously existing parameter in the URL: are they preserved ? Yes. No difference there. Anyway, maybe that we should look for a better way to circumvent the problem. I agree. What's your opinion ? I don't have any at the moment. I would need time to investigate this more, but I won't have time for that before the end of this week. I expect that David will be able to give a better response (if he reads the mailing list today, I know he too is covered in work till at least Thursday). Regards, Ate regards Fabrice Regards, Ate Question is : Ate and David what do you think about the best way to circumvent this? Do you think it's possible to tell pluto not to add the ns element at all ? Thanks for your help Fabrice - 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] -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
3rd request Please remove brent@castandcrew.com from list
Thank you.
Re: 3rd request Please remove brent@castandcrew.com from list
goto http://portals.apache.org/jetspeed-2/mail-lists.html :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: found fusion/pluto interaction bug
Fabrice Dewasmes wrote:
Hi all,
this mail should be of particular interest for David and Ate.
A few days ago I posted msg15905.html entitled Something weird happening with
fusion/pluto. In fact the navigational state IS the cause of the problem. I'd
like to have your opinion about how to workaround this as several solutions are
possible. Before explaining the solutions, here is the problem :
When you want to set the action of a form or have a link calling a portlet
action you must use either a portlet:actionURL or use
response.createActiontURL() method. This in turns calls the
PathInfoEncodingPortalURL which extends AbstractPortalURL. This implementation
of AbstractPortalURL adds a _ns:xxx element ni the request URL just after
contextPath+servletPath (this is for example /jetspeed/portal/) and then
appends the rest of the original request. This gives something like this :
/jetspeed/portal/_ns:xx/media-type/html/user/admin/page/new.psml/js_peid/PXXX
BUT the problem is that turbine reads the URL to get its parameter hashmap ready
this way : first element after context path + servlet path is meant to be
parameter name, and then URL is supposed to be constructed as an alternance
between paramter names and parameters values. This means that if you have such
a (normal jetspeed)URL :
/jetspeed/portal/media-type/html/user/admin/page/new.psml/js_peid/PXXX
the resulting hashmap will be :
{
media-type=html
user=admin
page=news.psml
js_peid=PXXX
}
but it the case of the URL returned by pluto, eveything is mixed up because
first element is navigational state which is not what turbine expects and has
nothing to do with a key value pair. This leads to such a hashmap :
{
_ns:xx=media-type
html=user
admin=page
js_peid=news.psml
PXX=
}
and of course when jetspeed wants to get the profile, it uses the parameters
found in runData object and searches for the page parameter which it doesn't
find. Jetspeed then constructs a default profile, pointing to default.psml
page. And this is why when you click on an action button in a JSR168 portlet
contained in a PSML page which is NOT default.psml you get redirected to
default.psml page (which is of course not what we want).
Now possible solutions are :
- rewrite DefaultJetspeedParameterParser and override setRequest method so that
it ignores the _ns:XXX element in URL (if it exists) and begins parsing right
after. This is not very elegant and is clearly a workaround
- Maybe configure pluto to use QueryStringEncodingPortalURL implementation of
AbstractPortletURL so that ns is put as a paramter in the URL. But I would know
how this is done in JSFusion and I don't know if jetspeed will be happy with
this knew and unknown parameter.
Question is : Ate and David what do you think about the best way to
circumvent
this? Do you think it's possible to tell pluto not to add the ns element at all
?
I would personnally say that the best way would be to define a new
FusionEncodingPortalURL that behaves just like PathInfoEncoding except
that it adds the follwoing string : _ns/_ns: instead of simply _ns:
It would change anything for j2 since it specically looks for '_ns:' as
an identifier and will allow Turbine to recognize a new _ns parameter
which it would care about but at least will not break the othher parts
of the URL.
The Fusion assembly script needs to use the FusionPortalURL instead of
any of the regular ones.
What do you think ?
--
Raphaël Luta - [EMAIL PROTECTED]
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: found fusion/pluto interaction bug
Raphaël Luta wrote: I would personnally say that the best way would be to define a new FusionEncodingPortalURL that behaves just like PathInfoEncoding except that it adds the follwoing string : _ns/_ns: instead of simply _ns: It would change anything for j2 since it specically looks for '_ns:' as an identifier and will allow Turbine to recognize a new _ns parameter which it would care about but at least will not break the othher parts of the URL. The Fusion assembly script needs to use the FusionPortalURL instead of any of the regular ones. What do you think ? Looks Turbine friendly to me. Are you going to write it ? Im going to try releasing 1.6 today. If we could get the fix in now I'd be glad to incorporate it in the release -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: found fusion/pluto interaction bug
David Sean Taylor wrote: Raphaël Luta wrote: I would personnally say that the best way would be to define a new FusionEncodingPortalURL that behaves just like PathInfoEncoding except that it adds the follwoing string : _ns/_ns: instead of simply _ns: It would change anything for j2 since it specically looks for '_ns:' as an identifier and will allow Turbine to recognize a new _ns parameter which it would care about but at least will not break the othher parts of the URL. The Fusion assembly script needs to use the FusionPortalURL instead of any of the regular ones. What do you think ? Looks Turbine friendly to me. Are you going to write it ? Im going to try releasing 1.6 today. I thought we would first go through Release candidates for 1.6 before announcing an official 1.6 release ? If we could get the fix in now I'd be glad to incorporate it in the release I can write it easily but I don't have currently the environment to test it :) I've not yet run Fusion... I'll commit a patch later this evening. -- Raphaël Luta - [EMAIL PROTECTED] Aptiwan, l'intelligence du réseau - http://www.aptiwan.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: found fusion/pluto interaction bug
Raphaël Luta wrote: David Sean Taylor wrote: Raphaël Luta wrote: I would personnally say that the best way would be to define a new FusionEncodingPortalURL that behaves just like PathInfoEncoding except that it adds the follwoing string : _ns/_ns: instead of simply _ns: It would change anything for j2 since it specically looks for '_ns:' as an identifier and will allow Turbine to recognize a new _ns parameter which it would care about but at least will not break the othher parts of the URL. The Fusion assembly script needs to use the FusionPortalURL instead of any of the regular ones. What do you think ? Looks Turbine friendly to me. Are you going to write it ? Im going to try releasing 1.6 today. I thought we would first go through Release candidates for 1.6 before announcing an official 1.6 release ? If we could get the fix in now I'd be glad to incorporate it in the release I can write it easily but I don't have currently the environment to test it :) I've not yet run Fusion... I'll commit a patch later this evening. anyway this is a good idea. I've got some time tomorrow to write and test it. I can submit something tomorrow at around 12:00. Is that OK for you ? Fabrice -- Fabrice Dewasmes Responsable du domaine urbanisation des systèmes d'information [EMAIL PROTECTED] 06.89.88.65.37 -- Open Wide 14 rue Gaillon 75002 PARIS www.openwide.fr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
possibility to have jslink give relative URIs ?
Hi, Another question : when using velocity, URIs are rendered using $jslink variable. In fact This URI is rendered by the toString Method of a DynamicURI object coming from Turbine. But this gives absolute URI and not relative ones. For me this is problematic especially when you sit behind a reverse proxy as this is our case, or even when you have custering problematics in mind. Is there a simple way to change this behaviour or do I have to rewrite DynamicURI class and simply replace it within turbine jar ? (kind of brute force patch isn't it ;) ?) Regards, Fabrice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possibility to have jslink give relative URIs ?
Fabrice Dewasmes wrote: Hi, Another question : when using velocity, URIs are rendered using $jslink variable. In fact This URI is rendered by the toString Method of a DynamicURI object coming from Turbine. But this gives absolute URI and not relative ones. For me this is problematic especially when you sit behind a reverse proxy as this is our case, or even when you have custering problematics in mind. Is there a simple way to change this behaviour or do I have to rewrite DynamicURI class and simply replace it within turbine jar ? (kind of brute force patch isn't it ;) ?) $jslink works fine behind a proxy configure your jvm to use the proxy -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possibility to have jslink give relative URIs ?
Fabrice Dewasmes wrote:
Hi,
Another question : when using velocity, URIs are rendered using $jslink
variable. In fact This URI is rendered by the toString Method of a
DynamicURI object coming from Turbine. But this gives absolute URI and
not relative ones.
For me this is problematic especially when you sit behind a reverse
proxy as this is our case, or even when you have custering problematics
in mind.
Agreed, it's a pain in those situations when your host name is meaningless.
Is there a simple way to change this behaviour or do I have to rewrite
DynamicURI class and simply replace it within turbine jar ? (kind of
brute force patch isn't it ;) ?)
Luckily for you we have better options :)
$jslink is actually a reference to class
org.apache.jetspeed.util.template.BaseJetspeedLink
as configured in the TurbineResources.properties
So you can subclass the above class,
rewrite the toString() method not to output the host part of the URL and
use your subclass as jslink instead of the default one
by overiding the Turbine tool definition in your my.properties file.
your toString() may look like this:
public String toString()
{
String url= super.toString();
return base.substring(url.indexOf('/',url.indexOf(//)+1),url.length);
}
--
Raphaël Luta - [EMAIL PROTECTED]
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: found fusion/pluto interaction bug
Fabrice Dewasmes wrote: I can write it easily but I don't have currently the environment to test it :) I've not yet run Fusion... I'll commit a patch later this evening. anyway this is a good idea. I've got some time tomorrow to write and test it. I can submit something tomorrow at around 12:00. Is that OK for you ? Fabrice It's fixed in Jetspeed 2 CVS but you're welcome to test it out in Fusion. You'll have to update the Fusion assembly script to use FusionPathEncodingPortalURL instead of PathEncodingPortalURL and also move the dependencies to J2-M3-dev and build yourself the M3-dev artefact for it to work though. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: found fusion/pluto interaction bug
Raphaël Luta wrote: Fabrice Dewasmes wrote: I can write it easily but I don't have currently the environment to test it :) I've not yet run Fusion... I'll commit a patch later this evening. anyway this is a good idea. I've got some time tomorrow to write and test it. I can submit something tomorrow at around 12:00. Is that OK for you ? Fabrice It's fixed in Jetspeed 2 CVS but you're welcome to test it out in Fusion. You'll have to update the Fusion assembly script to use FusionPathEncodingPortalURL instead of PathEncodingPortalURL and also move the dependencies to J2-M3-dev and build yourself the M3-dev artefact for it to work though. I've moved the patch to Jetspeed 1 Fusion CVS directly so you'll just need to cvs update and test it out if David can't complete the RC1 release today. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
