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.
The above will work for cases where you just use $jslink in your templates but will indeed fail if you use $jslink.getAction() or other calls that return a new DynamicURI instead of the BaseJetspeedLink.
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 ?
Since there no RelativeURI(DynamicURI) constructor and you need a RunData object to correctly initialize a *URI Turbine object, you can't really rely on the super.getRoot() results. I guess the easiest way is just to cut/paste the BaseJetspeedLink.getRoot() and replace all DynamicURI with RelativeURI in here.
You'll also have to modify the Porfiler service so that the makeDynamicURI returns a RelativeURI when needed. I guess the best way to do this is to subclass the JetspeedProfiler implementation, add a new
config parameter that specifies whether you want RelativeURI or DynamicURI and rewirte the makeLink() method to use this parameter as necessary.
-- 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]
