Re: possibility to have jslink give relative URIs ?
Agreed, it's a pain in those situations when your host name is meaningless.
YES !
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
Yes, I saw this.
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);
}
Unfortunately this is wrong. The toString method called is the DynamicURI object
one not the link object one. So what I did is very special and wanted to have
your point of view.
I've subclassed DynamicURI and FusionJetspeedLink. MyFusionJetspeedLink
overrides the getRoot method from BaseJetspeedLink so that it returns a
RelativeURI class (which extends DynamicURI). The toString method from
RelativeURI does not make use of serverScheme, name and port.
This works but i'm unsure about the way i'm constructing RelativeURI object as I
simply use the super constructor from DynamicURI DynamicURI(ServerData data).
This gives the following getRoot method in MyFusionJetspeedLink :
protected getRoot(){
DynamicURI uri = super.getRoot();
RelativeURI relative = new RelativeURI(uri.getServerData();
return relative;
}
Does the newly created object
have all the information from the originating DynamicURI object ? I guess not,
because the PathInfo and several other private variables will be lost... Have
you other ideas to improve what I did ?
thanks for your help
Fabrice
-
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]
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]
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: Something weird happening with fusion/pluto
Le 30 mars 05, à 18:45, David Sean Taylor a écrit :
Fabrice Dewasmes wrote:
Hi all !
I'm using JS1 + fusion (without the latest deployment model)
1. The user logs in (let's say he's in role 'dummy')
2. the default dummy psml page is rendered
3. the user chooses another PSML Page using the drop down menu at
the top right of the page and is now on a psml page from anon user.
4. User clicks on a link which has been rendered by a
renderResponse.createActionURL().toString() on a JSR168 portlet. And
that's
where the trick happens... He's redirected on the default user's psml
page
('dummy' psml page).
(Which of course is not what we want : the previously clicked portlet
is even
not displayed). So the problem won't occur if the JSR168 porlet is in
the
'dummy' psml page.
After investigating it seems that the rendered URL is something like
/jetspeed/portal/_ns:XXX/media-type/html/language/-1/user/
anon/Accueil.psml/js_pane/P-XX-10003
(XXXs are to be replaced with a alphanumeric sequence)
and if I remove the _ns: part everything works fine !
Am I wrong ? What is this mysterious _ns:part ?
Thats the navigational state for JSR 168 portlets.
I tried your case against a running version of Fusion here, and it
works fine (it stays on the same page and tab). Unfortunately all of
my work (and installed applications) with Fusion was before the new
navigational state implementation in Jetspeed-2.
Thanks for your reply and interest David. In fact I'm using Jetspeed
1/fusion that depends on the M1 release of J2. Is it your case ?
Be careful that everything works pretty fine when you're on the user
default psml page. Did you use another psml page in which is the JSR168
portlet ?
Thanks again for your help. I will test this evening with latest from
CVS head.
Fabrice
I will need to upgrade my Fusion installs soon.
Hope to get some time to work on this over the next week.
Will look out for this bug, thanks
--
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Something weird happening with fusion/pluto
Fabrice Dewasmes wrote:
Le 30 mars 05, à 18:45, David Sean Taylor a écrit :
Fabrice Dewasmes wrote:
Hi all !
I'm using JS1 + fusion (without the latest deployment model)
1. The user logs in (let's say he's in role 'dummy')
2. the default dummy psml page is rendered
3. the user chooses another PSML Page using the drop down menu at
the top right of the page and is now on a psml page from anon user.
4. User clicks on a link which has been rendered by a
renderResponse.createActionURL().toString() on a JSR168 portlet.
And that's
where the trick happens... He's redirected on the default user's
psml page
('dummy' psml page).
(Which of course is not what we want : the previously clicked
portlet is even
not displayed). So the problem won't occur if the JSR168 porlet is
in the
'dummy' psml page.
After investigating it seems that the rendered URL is something like
/jetspeed/portal/_ns:XXX/media-type/html/language/-1/user/
anon/Accueil.psml/js_pane/P-XX-10003
(XXXs are to be replaced with a alphanumeric sequence)
and if I remove the _ns: part everything works fine !
Am I wrong ? What is this mysterious _ns:part ?
Thats the navigational state for JSR 168 portlets.
I tried your case against a running version of Fusion here, and it
works fine (it stays on the same page and tab). Unfortunately all of
my work (and installed applications) with Fusion was before the new
navigational state implementation in Jetspeed-2.
Thanks for your reply and interest David. In fact I'm using Jetspeed
1/fusion that depends on the M1 release of J2. Is it your case ?
Be careful that everything works pretty fine when you're on the user
default psml page. Did you use another psml page in which is the
JSR168 portlet ?
Thanks again for your help. I will test this evening with latest from
CVS head.
Fabrice
David,
I've tested the same scenario against the latest from head + the fusion
refactoring sync. The same problem appears...
This is really bad news for us as we definitely need to switch between
psml pages
Please could you help us ? I've investigated a bit but it's difficult to
find my way. Any pointers ?
Fabrice
I will need to upgrade my Fusion installs soon.
Hope to get some time to work on this over the next week.
Will look out for this bug, thanks
--
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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]
Something weird happening with fusion/pluto
Hi all !
I'm using JS1 + fusion (without the latest deployment model)
1. The user logs in (let's say he's in role 'dummy')
2. the default dummy psml page is rendered
3. the user chooses another PSML Page using the drop down menu at
the top right of the page and is now on a psml page from anon user.
4. User clicks on a link which has been rendered by a
renderResponse.createActionURL().toString() on a JSR168 portlet. And that's
where the trick happens... He's redirected on the default user's psml page
('dummy' psml page).
(Which of course is not what we want : the previously clicked portlet is even
not displayed). So the problem won't occur if the JSR168 porlet is in the
'dummy' psml page.
After investigating it seems that the rendered URL is something like
/jetspeed/portal/_ns:XXX/media-type/html/language/-1/user/anon/Accueil.psml/js_pane/P-XX-10003
(XXXs are to be replaced with a alphanumeric sequence)
and if I remove the _ns: part everything works fine !
Am I wrong ? What is this mysterious _ns:part ?
Thank you very much for your help.
Best regards
Fabrice
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graffito - Jetspeed CMS framework
David Sean Taylor a écrit : Fabrice Dewasmes wrote: Hi, This is great news. My first question would be : do you think it can work within JS1 with fusion ? Graffito (and Graffito portlets) will run inside Fusion. Just need to add the Graffito components to the Spring configuration I've tried to use it. In fact the maven scripts don't work 'out of the box' for hsql. There are a few bugs. Here are those that I remember : - empty password for DB is not valid - torque SQL scripts generation doesn't generate a good script for creation of content table because of the BLOB field (the field has no type) -- should have been set to OBJECT type ? - SQL scripts are maybe not generated at the right place (src/sql/... vs target/src/sql/...) - J2 deploy doesn't deploy assembly at the right place (WEB-INF/assembly instead of WEB-INF/conf/assembly) At the end, everything deploys well within JS1+Fusion. BUT I don't understand how to use the portlet. When in view mode, the portlet tells me that i'm connected to [server]jetspeed but that there is no content and I should use edit mode. But in edit mode the portlet appears empty and no log in the console What did I miss ? Thanks Fabrice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
localize struts portlet
Hi, I'm using JS1+fusion and i'm developping struts portlets. I'd like toknow if it's possible to have portlets switch language when the portal is switching language (for example using changelanguage portlet). Is there an API usable by portlets to know portal Locale ? I've tried to use getLocale from HttpServletRequest but it seems that the portal doesn't use it (for example portal header is in english and getLocale returns fr). Thanks in advance, Fabrice -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graffito - Jetspeed CMS framework
Hi, This is great news. My first question would be : do you think it can work within JS1 with fusion ? In fact we are planning to integrate a CMS solution in Jetspeed 1.6 using fusion. It could be a good opportunity to work with you if this can fit our environment. In fact we were planning to integrate slide within jetspeed and develop a set of JSR 168 portlets to interact with slide. Fabrice Le 15 mars 05, à 17:20, LOMBART Christophe a écrit : Marky, Of course, we want to support JSR 170. Oliver Kieesler is working on a cms object mapping for a JSR repository. Now, I'm going to work with him and check how we can integrate his work into Graffito. If you join the Graffito dev mailing you will see a JCR proposal for Graffito ASAP. You are welcome to join the team and exchange with us some idea and experience. Christophe -Original Message- From: Marky Goldstein [mailto:[EMAIL PROTECTED] Sent: Tue 3/15/2005 4:30 PM To: Jetspeed Users List Cc: Subject:Re: Graffito - Jetspeed CMS framework propably you should also have a look into magnolia.info They have integrated the JackRabbit adapter into their CMS efforts. Maybe the two efforts could be joined. I myself can help, but more on a project management level such as organization, documentation, etc. Greets, Marky Raphaël Luta wrote: Marky Goldstein wrote: Great. Please also support JSR 170 (Content Repository Standard). We are interested to join the effort. Given the very reduced number of active developpers on Graffito right now, the best way to see this happening quickly is to join the graffito-dev list, and start to work with us on supporting JCR (probably through a JackRabbit adapter) The more and the sooner interested parties can collaborate on getting this done, the better the end product will be. Christophe has done a great job so far on UI/portlet components and slide support but we definitely need help to accelerate the development. - 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: Jetspeed 1.6-Fusion HELP!!!!
I'd like to give Jeff and Hema my support : first, we've chosen to start with JS1+Fusion as we had two major requirements : being JSR 168 compliant and have lots of nice features. This means that we obviously had to go with JS1+fusion (And i'm not talking about maturity). We plan to migrate in the future to JS2 but for us is the fusion alternative a perfect migration path and would be disastrous for us if fusion is deprecated. So I also give a -1 for such a deprecation ;) second, it seems to me that fusion code is not that large and could be quite easily put back on its feet. Code changes in J2 by Ate seem to be pragmatic and well founded and it reassured me that Ate took into account that fusion exists. finally I agree to have JS1.6.1 with JS2M2 release and JS1.6.2 with JS2final only if schedules can't match better. I mean : if JS2 is about to release final at about the same time that JS1.6, maybe could JS1.6 and JS2 be synchronised at first shot. Fabrice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: using jetspeed 1 plugin with fusion
here is the answer which is quite simple : as you succeed in building JS with fusion build a zip dist (maven dist) and deploy it in jetspeed/distributions. Fabrice Le 21 févr. 05, à 17:26, Fabrice Dewasmes a écrit : Hi all, Has anyone tried to use jetspeed 1 plugin (for example jetspeed:deploy goal) with jetspeed-fusion ? I have compiled JS1 with fusion but when using jetspeed;deploy in my own projet the resulting war seems not to be fusion aware. Any idea ? Thanks 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]
using jetspeed 1 plugin with fusion
Hi all, Has anyone tried to use jetspeed 1 plugin (for example jetspeed:deploy goal) with jetspeed-fusion ? I have compiled JS1 with fusion but when using jetspeed;deploy in my own projet the resulting war seems not to be fusion aware. Any idea ? Thanks Fabrice -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to deploy JSR-168 portlets with fusion
Fabrice Dewasmes a écrit : David Sean Taylor a écrit : Fabrice Dewasmes wrote: Hi, I've built and installed fusion following instructions on the wiki (http://wiki.apache.org/portals/Jetspeed2/Fusion) and using latest from CVS. It seems to work fine but when I drop a war or exploded webapp into WEB-INF/deploy directory, I don't see anything happening in the logs and the portlet does not appear in portlet list when I want to add a portlet to a page. The JSR 168 portlets I tried to deploy were struts-demo and RSS demo taken from js2. Is there something special to do to deploy the portlets ? Check your log files. There must be something going wrong . Did you run this target in a different shell to start the J2 database?: maven db.fusion.start David, thanks for your kind reply. the database is started using the db.fusion.start goal in fusion subdirectory. Tomcat logs at startup seems OK : Starting Up Fusion Service APP ROOT = /usr/java/jakarta-tomcat-5.0.28/webapps/jetspeed/ PROP FILE = /usr/java/jakarta-tomcat-5.0.28/webapps/jetspeed/WEB-INF/conf/fusion.properties JNDI System Property flag null INFO: Using PDEF NAME portlet_definition INFO: Using PAPP NAME portlet_application INFO: Deployment server port: 8080 INFO: Deployment server: localhost INFO: Starting auto deployment service: org.apache.jetspeed.deployment.impl.StandardDeploymentManager INFO: Deployment scanning delay: 1 INFO: Deployment staging directory: /usr/java/jakarta-tomcat-5.0.28/webapps/jetspeed/WEB-INF/deploy INFO: Deployment scanner successfuly started! Fusion Service: Initialization Done however when I put struts-demo.war in WEB-INF/deploy nothing happens either in the logs and in portlet listing. What could be the error ? OK I found the problem : first : it seems that even if you set in ~/build.properties the following line org.apache.jetspeed.catalina.version.major=5 it is not used correctly to generate fusion.properties file located in WEB-INF/conf of jetspeed. So i've correctly put the property directly in fusion.properties. second : the JSR 168 apps must be deployed not as a war file but must be exploded. Then everything works fine ! Thanks for help Fabrice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
