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]
Re: possibility to have jslink give relative URIs ?
Fabrice Dewasmes wrote:
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]
Re: possibility to have jslink give relative URIs ?
Fabrice Dewasmes wrote: 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 finally found a quite elegant solution which is : override JetspeedProfilerService and its method makeDynamicURI() override getRoot method from BaseJetspeedLink make both these classes use my RelativeURI class which extends DynamicURI and overrides everything to delegate to super class and overrides the toString method to get rid of server name, port and scheme Agreed :) But the very best way to do this would have been a patch to turbine in order to have the DynamicURI beeing abstract and have a concrete implementation configurable This would allow to have an abstract generateURI method which everyone could implement to have its own behaviour... Turbine 2.3 has already changed how URI are built to something called TurbineURI that can output either type of URIs. If you're willing to convert all of J1 to this new API and update our dependency to Turbine 2.3 or 2.4, be our guest. Your patches are welcome :) -- 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]
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]
