atom feed60 messages in org.apache.incubator.sling-devRe: [jira] Commented: (SLING-249) All...
FromSent OnAttachments
Vidar S. Ramdal (JIRA)Feb 15, 2008 7:27 am 
Felix Meschberger (JIRA)Feb 15, 2008 7:35 am 
Bertrand Delacretaz (JIRA)Feb 15, 2008 2:23 pm 
eric...@acquitygroup.comFeb 15, 2008 5:52 pm 
Felix MeschbergerFeb 16, 2008 2:09 am 
Tobias Bocanegra (JIRA)Feb 17, 2008 9:14 am 
Vidar S. Ramdal (JIRA)Feb 18, 2008 12:24 am 
Vidar S. Ramdal (JIRA)Feb 18, 2008 12:26 am 
eric marts (JIRA)Feb 18, 2008 3:06 pm 
Vidar S. Ramdal (JIRA)Mar 26, 2008 3:09 am 
Bertrand Delacretaz (JIRA)Mar 26, 2008 3:19 am 
Carsten Ziegeler (JIRA)Apr 30, 2008 11:39 am 
Felix Meschberger (JIRA)Nov 20, 2008 3:06 am 
Felix Meschberger (JIRA)Nov 20, 2008 3:12 am 
Felix Meschberger (JIRA)Nov 20, 2008 3:14 am 
Vidar S. Ramdal (JIRA)Nov 20, 2008 3:36 am 
Felix Meschberger (JIRA)Nov 20, 2008 4:02 am 
Vidar S. Ramdal (JIRA)Nov 20, 2008 4:14 am 
Alexander KlimetschekNov 20, 2008 4:35 am 
Felix Meschberger (JIRA)Nov 20, 2008 5:36 am 
Bertrand Delacretaz (JIRA)Nov 20, 2008 5:50 am 
Alexander Klimetschek (JIRA)Nov 20, 2008 7:14 am 
Bertrand DelacretazNov 20, 2008 8:56 am 
Vidar S. Ramdal (JIRA)Nov 20, 2008 9:16 am 
Vidar S. Ramdal (JIRA)Nov 20, 2008 9:20 am 
Bertrand Delacretaz (JIRA)Nov 20, 2008 9:26 am 
Felix MeschbergerNov 20, 2008 11:16 pm 
Felix Meschberger (JIRA)Nov 20, 2008 11:24 pm 
Alexander KlimetschekNov 21, 2008 12:49 am 
Vidar RamdalNov 21, 2008 1:03 am 
Alexander KlimetschekNov 21, 2008 1:41 am 
Bertrand Delacretaz (JIRA)Nov 21, 2008 3:14 am 
Felix Meschberger (JIRA)Nov 21, 2008 3:28 am 
Felix MeschbergerNov 21, 2008 3:33 am 
Alexander KlimetschekNov 21, 2008 3:36 am 
Felix MeschbergerNov 21, 2008 3:46 am 
Felix MeschbergerNov 21, 2008 3:51 am 
Alexander KlimetschekNov 21, 2008 5:24 am 
Vidar RamdalNov 21, 2008 7:21 am 
Alexander KlimetschekNov 21, 2008 8:47 am 
Roy T. FieldingNov 21, 2008 4:11 pm 
David NueschelerNov 22, 2008 3:49 am 
Felix MeschbergerNov 23, 2008 10:30 am 
Felix MeschbergerNov 23, 2008 1:41 pm 
Vidar RamdalNov 24, 2008 12:59 am 
Felix MeschbergerNov 24, 2008 1:31 am 
Bertrand DelacretazNov 24, 2008 1:37 am 
Bertrand DelacretazNov 24, 2008 1:39 am 
Felix MeschbergerNov 24, 2008 5:06 am 
Felix MeschbergerNov 24, 2008 5:09 am 
Felix Meschberger (JIRA)Nov 25, 2008 3:29 pm 
Felix Meschberger (JIRA)Nov 25, 2008 4:07 pm 
Roy T. FieldingNov 26, 2008 2:45 pm 
Roy T. FieldingNov 26, 2008 2:54 pm 
Roy T. FieldingNov 26, 2008 3:04 pm 
Felix MeschbergerNov 27, 2008 4:25 am 
Felix MeschbergerNov 27, 2008 4:31 am 
Roy T. FieldingDec 3, 2008 3:35 pm 
Felix Meschberger (JIRA)Jan 26, 2009 4:31 am 
Vidar S. Ramdal (JIRA)Jan 27, 2009 4:36 am 
Subject:Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
From:Felix Meschberger (fmes@gmail.com)
Date:Nov 20, 2008 11:16:26 pm
List:org.apache.incubator.sling-dev

Hi all,

I am now taking this to the list for discussion, because it gets very interesting ;-)

We have just been discussion a slightly different approach, which may even replace existing configuration setup of the JcrResourceResolver !

For now, we have the following:

Vanity URLs : replace requested path with different path URL Mappings: replace path prefixes with different prefixes Regexps : regular expressions to resolve and map paths VanityPath : property set to an absolute path matched against URL VirtualHost : add path prefix based on Host: header (my proposal)

Lets now think of the following:

The sling:vanityPath property is multi-valued and contains URLs. These URLs may be absolute or relative. An absolute URI includes the scheme, authority and path. A relative omits the scheme and or authority part. In additiona relative URI may even be a relative path.

To resolve a request URL with Host: header and path, the resource resolver would first check whether there is an exact match for the path in the repository. If not, the resource resolver will then -- from the top of the resource tree -- look for a resource whose sling:vanityPath matches the Host: header plus (optionally) any prefix of the path. From there the path would be traversed down along resource names and relative sling:vanityPath entries to find the final resource.

This _is_ expensive and therefore absolutely requires caching. Therefore, we will introduce a small (something like 1000 entries or so), which may be used to directly map incoming requests to resources. The cache is managed very simply: on each change in the resource tree, the cache is just dropped.

To convert a resource path back to an URL (map method), the resource resolver looks for the resource and analyzes the sling:vanityPath properties of each ancestor resource until the root ressouce is reached or an absolute URI is contained in the property (only the first value of the property is considered thus defining sort of a primary vanity URL).

As a consequence the existing mechanisms would be dropped:

VanityURLs : just set the URL on the "target" URLMappings: just set the absolute path on the "target root" Regexps : just set the respective mappings on the "target" VirtualHost: just set the host on the "target root"

The sole remains of existing mechanisms is the sling:vanityPath, which is used as explained above.

Some use cases:

(1) Map www.domain1.com and domain1.com to /domain1:

/domain1 +-- sling:vanityPath = [ "http://www.domain.com", "http://domain1.com ]

Examples: http://www.domain1.com/some/entry.html --> /domain1/some/entry http://domain1.com/some/site.css --> /domain1/some/site.css http://www.domain2.com/some/dom.html --> /some/dom

(2) Map everything below /content to root (/)

/content +-- sling:vanityPath = [ "/" ] /another

Examples: http://www.host.com/the/path.html --> /content/the/path.html http://www.host.com/another.html --> /another.html

Regards Felix

PS: This should catchup the whole discussion, right ?

Bertrand Delacretaz (JIRA) schrieb:

[
https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649366#action_12649366
]

Bertrand Delacretaz commented on SLING-249:

-------------------------------------------

how about introducing a nodetype called "domainroot": [sling:domainRoot] mixin - sling:domains (string) multiple Then a domain root would be resolved by doing a query like
//*[contains(sling:domains, request.getHeader("Host"))]

I like this idea, it is similar to how we treat the vanityUrl stuff - and as the
domain mappings have to do with specific content trees, it makes perfect sense
to me to have this info in the content as opposed to OSGi configs.

It might seem more costly than a regexp-based configuration, but this domainRoot
info is easy to observe and cache: the mapper does a query on sling:domainRoot
when it starts, disables itself if not found, and observes that node type for
future updates.

Allow mapping nodes to internet domains

---------------------------------------

Key: SLING-249 URL: https://issues.apache.org/jira/browse/SLING-249 Project: Sling Issue Type: New Feature Components: Engine Affects Versions: JCR Resource 2.0.2 Reporter: Vidar S. Ramdal Assignee: Felix Meschberger Fix For: JCR Resource 2.0.4

Sling should support hosting multiple domains, with different JCR roots. E.g.: http://www.domain1.com could map to /content/domain1.com http://www.domain2.com could map to /content/domain2.com While developing a website, the fully qualified domain might not be available.
Ideally, the mapping could be configured in a flexible way. One option would be
to maintain a set of regular expressions to match against URLs. Each regexp
would then match to a path in the JCR.