has this solution been implemented yet, if not how can I implement it, I've read the documentation
http://portals.apache.org/jetspeed-2/guides/guide-profiler.html http://svn.apache.org/repos/asf/portals/jetspeed-2/trunk/design-docs/src/profiler/J2-page-manager-profiling.sxw http://donaghy.blogspot.com/2006_09_01_donaghy_archive.html#115717649154931733 is there anymore documentation on the subsites ? my usecase sinario is I have two websites, lets call them http://one.com and http://two.com I would have one.com point to subsite and two.com point to two.com the userbase would be for both websites but the user would see whichever homepage they originaly requested ie, if they went to one.com they would see the subsite homepage if they went to two.com they would see subsite2 homepage. but they would only have to register once on either website to get access to both. each website would have its own template and set of psml files. It would also be nice to still retain all of the profiling features of a full blown jetspeed website like the users/roles/groups. Is it currently possible to implement this with the current J2-dev version of jetspeed. if not what do I have to learn or where do I have to look to implement it myself. Thanks, Dominique On 11/28/06, Elif Guner <[EMAIL PROTECTED]> wrote:
Hi David, In my case it is like http://somecompany.com, http://somecompany2.com, http://somecompany3.com I'm wondering if you'd consider this situation as well? Thanks... Elif On 11/28/06, David Sean Taylor <[EMAIL PROTECTED]> wrote: > Bhaskar wrote: > > > > Hi David, > > > > Can you bit explain, how this mapping to be done, like > > http://employees.somecompany.com/jetspeed/ -> maps to employee-subsite > > http://customers.somecompany.com/jetspeed/ -> maps to customer-subsite > > http://partners.somecompany.com/jetspeed/ -> maps to partner-subsite > > > > I looked at the documentation, didn't get it through. > > > This mapping does not currently exist. I was proposing writing and > contributing a new profile resolver based on the host string. > The idea is we would have a new profiling rule that used this resolver > as its first criteria. It could parse the host up, find the substring up > to the first ".", and use that to map to a subsite. Thus all requests > going to employees.* would then map to the "employee" subsite. > I would combine this with role-based declarative security, so that > customers would get access denied exceptions if they tried to access a > URL for employees, for example. > > --------------------------------------------------------------------- > 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]
