RE: adding java classes into the jcr
Hi Jason I take it the idea is to strictly modularize on a CQ component level? While there is some support for placing java files in the JCR and use them as servlets for specific resources, this approach is somewhat exotic and you're better of providing application code - such as models - in OSGi bundles. This is much better in terms of separation of layers and concerns, and allows you to use all the OSGi goodness Felix provides, such as SCR (http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-pl ugin/scr-annotations.html) as well as any of the following solutions: 1.) The #1 way to provide specific models for resource in Sling is to use an AdapterFactory so you can .adaptTo(SpecificModel.class) from a resource, e.g. in a view, taglib, servlet and the like. (http://sling.apache.org/documentation/the-sling-engine/adapters.html) 2.) Nowadays, you can do so declaratively using Sling Models (http://sling.apache.org/documentation/bundles/models.html). This also gives you Resource - to - model mapping, i.e. mapping properties and resources onto a POJO java model. 3.) If you'd like to leverage google guice, you can use Slice from cognifide (http://www.cognifide.com/blogs/cq/make-your-cq-life-easier-with-slice/). This will also support .adaptTo and provides resource to model mapping. 4.) Finally, there is NEBA (http://neba.io), which gives you .adaptTo + resource to model mapping and Spring MVC plus some more features. I'm a bit biased towards that one - since I am NEBA's lead developer ;-) Kind regards, Olaf -Original Message- From: Jason Bailey [mailto:jason.bai...@sas.com] Sent: Mittwoch, 16. Juli 2014 21:07 To: users@sling.apache.org Subject: adding java classes into the jcr We're using CQ5 pretty extensively for our external web presence and I'm in the process of evaluating Sling for a wider range of use cases internally. One of the questions that comes up on a regular basis is whether we are able to define a java object alongside the JSP when we are creating a widget. So that we can potentially implement a very specific business logic and have it co-located with the presentation logic. There seems to be support in Sling for compiling java classes located in the JCR, but there's a lack of clarity on when/how that occurs. Any information would be appreciated. -Jason
RE: ResourceProvider not invoked when provider root path is called with HTML extension
Hi Justin
Thank you for the clarification! So, in summary, when /something is resolved
for /something.html, the question is not whether something.html is a child
of /something, but whether .html I an extension of the sibling resource
/something. That's where I got it wrong.
Kind regards,
Olaf
-Original Message-
From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of
Justin Edelson
Sent: Freitag, 17. Januar 2014 14:57
To: users@sling.apache.org
Subject: Re: ResourceProvider not invoked when provider root path is called
with HTML extension
Hi Olaf,
Sorry, I don't know how to explain this any better than what I said earlier
in the week. There is no inconsistency.
For a request like /root/child.html, Sling will try *first* for the full
resource path /root/child.html. Since your resource provider is rooted at
/root, it is asked for the reosurce at /root/child.html. If no resource can
be found at this path, Sling *next* tries to get the resource /root/child.
Since your resource provider is rooted at /root, it is asked for this
resource as well.
Sling will behave differently depending on which call returns a non-null
value.
getResource("/root/child.html") - Sling will try to serve the resource
directly to the client, usually by adapting it to an InputStream
getResource("/root/child") - Sling will then try to execute the "html"
or default script for this resource type.
You wrote this in your JIRA issue which I think identifies the problem:
> In essence, a ResourceProvider can not utilize any selectors or extensions
to parametrize the resolution of its root resource.
A ResourceProvider should *never* do this, whether on the root resource or
any other resource. Selectors and extensions are not meant to parameterize
resource resolution.
Justin
On Fri, Jan 17, 2014 at 3:38 AM, Olaf Otto wrote:
> Hello Justin
>
> I believe we have a misunderstanding: You are absolutely right - but I
> have no intention to alter the described behavior. What I mean is that
> the behavior of the resource resolution using a resolved provider is
> inconsistent as it differs between the root path and (potential) child
> paths of a ResourceProvider. Let me elaborate:
>
> Let /root be the root of the resource provider. When I resolve
> /root/child.html, the resource provider is looked up in the fashion
> you described below, and is subsequently asked to resolve the entire
> request path, i.e. /root/child.html. When /root.html is called, and
> there is no specific provider for /root.html, the provider is looked
> up in the fashion you described, and is subsequently called - and this
> is the important difference - with the *lookup path* for the provider -
i.e. /root.
>
> It is clear that /root.html is not a child of /root *by default*.
> However, when no specific provider for /root.html exists, the provider
> of /root becomes responsible for the resolution of the path, i.e.
> /root.html is then treated as a child of /root. Consequently, the
> provider should be asked to provide the *entire* path, i.e. including
> and extensions / selectors etc, just like for any other child resource it
is responsible for.
>
> The patch I attached to SLING-3319 does not alter the behavior you
> described below (that would indeed be very nasty) but simply provides
> the full path to be resolved to the provider responsible.
>
> This behavior would be consistent with the behavior for
JcrResourceProvider:
> As this provider has the root path "/", it will always be asked to
> resolve the entire resource path (including extensions and selectors)
> as "/.selectors.extensions" is usually not resolved, i.e. it is always
> asked to resolve a child.
>
> Kind regards,
> Olaf
>
> -Original Message-
> From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On
> Behalf Of Justin Edelson
> Sent: Dienstag, 14. Januar 2014 19:22
> To: users@sling.apache.org
> Subject: Re: ResourceProvider not invoked when provider root path is
> called with HTML extension
>
> Hi,
> IIUC, this is *entirely* expected.
>
> Your ResourceProvider's root is /content/child1/child2. When the
> request comes in for /content/child1/child2.html, Sling will first try
> to resolve that full path. Your provider will *not* be consulted at
> this point because /content/child1/child2.html is not a child of
> /content/child1/child2 (it is a sibling). When the full path cannot be
> resolved, Sling then does its path decomposition thing and tries to
> resolve /content/child1/child2, which succeeds via your ResourceProvider.
>
> When a request comes in for /content/child1/child2/child3.html, the
> same thing happens. First, Sling tries to resolve the full path and
> does consult your reso
RE: ResourceProvider not invoked when provider root path is called with HTML extension
Hello Justin I believe we have a misunderstanding: You are absolutely right - but I have no intention to alter the described behavior. What I mean is that the behavior of the resource resolution using a resolved provider is inconsistent as it differs between the root path and (potential) child paths of a ResourceProvider. Let me elaborate: Let /root be the root of the resource provider. When I resolve /root/child.html, the resource provider is looked up in the fashion you described below, and is subsequently asked to resolve the entire request path, i.e. /root/child.html. When /root.html is called, and there is no specific provider for /root.html, the provider is looked up in the fashion you described, and is subsequently called - and this is the important difference - with the *lookup path* for the provider - i.e. /root. It is clear that /root.html is not a child of /root *by default*. However, when no specific provider for /root.html exists, the provider of /root becomes responsible for the resolution of the path, i.e. /root.html is then treated as a child of /root. Consequently, the provider should be asked to provide the *entire* path, i.e. including and extensions / selectors etc, just like for any other child resource it is responsible for. The patch I attached to SLING-3319 does not alter the behavior you described below (that would indeed be very nasty) but simply provides the full path to be resolved to the provider responsible. This behavior would be consistent with the behavior for JcrResourceProvider: As this provider has the root path "/", it will always be asked to resolve the entire resource path (including extensions and selectors) as "/.selectors.extensions" is usually not resolved, i.e. it is always asked to resolve a child. Kind regards, Olaf -Original Message- From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of Justin Edelson Sent: Dienstag, 14. Januar 2014 19:22 To: users@sling.apache.org Subject: Re: ResourceProvider not invoked when provider root path is called with HTML extension Hi, IIUC, this is *entirely* expected. Your ResourceProvider's root is /content/child1/child2. When the request comes in for /content/child1/child2.html, Sling will first try to resolve that full path. Your provider will *not* be consulted at this point because /content/child1/child2.html is not a child of /content/child1/child2 (it is a sibling). When the full path cannot be resolved, Sling then does its path decomposition thing and tries to resolve /content/child1/child2, which succeeds via your ResourceProvider. When a request comes in for /content/child1/child2/child3.html, the same thing happens. First, Sling tries to resolve the full path and does consult your resource provider (because /content/child1/child2/child3.html is a descendant of /content/child1/child2). At this point, if your provider returns null (and no other provider returns a non-null result), the Sling engine will THEN ask your provider for /content/child1/child2/child3. HTH, Justin On Tue, Jan 14, 2014 at 12:53 PM, Felix Meschberger wrote: > Hi > > Well, this gets really tricky, because as has been said, this is not expected. > > The only advice I can give here is to do some (remote) debugging with a debugger and step through the process from the SlingMainServlet (actually probably RequestData.initResource). > > Regards > Felix > > Am 14.01.2014 um 00:56 schrieb Olaf Otto : > >> Hello >> >> Apparently, the behavior that the root path with .html extension was >> not resolved at all was due to some persistent invalid internal state >> of the resource resolver. After modifying an arbitrary resolver >> setting, the root resource is now resolved (I re-installed Sling and >> the entire application to make sure this remains the case). >> >> However, there still is an important difference: >> >> When requesting "/content/child1/child2/child3.html", the path passed >> to the resource provider is "/content/child1/child2/child3.html", >> i.e. includes the extension. When requesting >> /content/child1/child2.html, the resolver only sees the path >> "/content/child1/child2". Since I am doing a subsequent resource >> resolution, this results in a missing resolutionPathInfo=".html" of the resolved resource. >> >> Thus, the remaining question is: Why are extensions not passed to the >> provider in case the root path is requested? >> >> Kind regards, >> Olaf >> >> -Original Message- >> From: Olaf Otto [mailto:o...@x100.de] >> Sent: Dienstag, 14. Januar 2014 07:29 >> To: users@sling.apache.org >> Subject: RE: ResourceProvider not invoked when provider root path is >> called with HTML extension >> >> H
RE: ResourceProvider not invoked when provider root path is called with HTML extension
Hi everyone I invested more time into the analysis of the issue and did some updates (https://issues.apache.org/jira/browse/SLING-3319), including a patch. If someone could try / review / discuss it, that would be great. Regards, Olaf -Original Message- From: Olaf Otto [mailto:o...@x100.de] Sent: Donnerstag, 16. Januar 2014 08:49 To: users@sling.apache.org Subject: RE: ResourceProvider not invoked when provider root path is called with HTML extension Hi everyone I found the issue - luckily, it is a simple one: https://issues.apache.org/jira/browse/SLING-3319 In essence, the split() function of ResourceProviderEntry requires a fix. Kind regards, Olaf -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: Dienstag, 14. Januar 2014 18:54 To: users@sling.apache.org Subject: Re: ResourceProvider not invoked when provider root path is called with HTML extension Hi Well, this gets really tricky, because as has been said, this is not expected. The only advice I can give here is to do some (remote) debugging with a debugger and step through the process from the SlingMainServlet (actually probably RequestData.initResource). Regards Felix Am 14.01.2014 um 00:56 schrieb Olaf Otto : > Hello > > Apparently, the behavior that the root path with .html extension was > not resolved at all was due to some persistent invalid internal state > of the resource resolver. After modifying an arbitrary resolver > setting, the root resource is now resolved (I re-installed Sling and > the entire application to make sure this remains the case). > > However, there still is an important difference: > > When requesting "/content/child1/child2/child3.html", the path passed > to the resource provider is "/content/child1/child2/child3.html", i.e. > includes the extension. When requesting /content/child1/child2.html, > the resolver only sees the path "/content/child1/child2". Since I am > doing a subsequent resource resolution, this results in a missing > resolutionPathInfo=".html" of the resolved resource. > > Thus, the remaining question is: Why are extensions not passed to the > provider in case the root path is requested? > > Kind regards, > Olaf > > -Original Message- > From: Olaf Otto [mailto:o...@x100.de] > Sent: Dienstag, 14. Januar 2014 07:29 > To: users@sling.apache.org > Subject: RE: ResourceProvider not invoked when provider root path is > called with HTML extension > > Hello, > > Thank you for the quick replies! The /child2 path is exclusively > provided by the custom resource provider. Would anyone know a hint why > this just happens in case of a .html extension? There must be some > other actor influencing this behavior. > > Kind regards, > Olaf > > -Original Message- > From: Felix Meschberger [mailto:fmesc...@adobe.com] > Sent: Montag, 13. Januar 2014 23:38 > To: users@sling.apache.org > Subject: Re: ResourceProvider not invoked when provider root path is > called with HTML extension > > Hi > > As Alex said, this is not expected, but . > > Do you happen to have a node /content/child1/child2.html in the > repository ? > If so, this would overwrite the ResourceProvider because it has a full > path match as opposed to just ./child2. > > Regards > Felix > > Am 13.01.2014 um 14:09 schrieb Olaf Otto : > >> Hi all, >> >> >> >> I have created a resource provider adding content as children into a >> tree of existing JCR content, like this: >> >> >> >> /content/child1 ß JCR content >> >> /content/child1/child2 ß Provided by ResourceProvider >> >> >> >> This works as expected: child2 is returned as a child of child1, and >> invoking /content/child1/child2 yields the provided resource. >> However, when calling /content/child1/child2.html, the resource >> provider is never asked for a resource. Instead, the default get >> servlet returns a synthetic resource, causing a redirect to >> /content/child1/child2.html/, resulting in a 404. Using a different >> extension works - when I call /content/child1/child2.json, the >> provider is called. Children of the root path however work with a >> .html extension: A request to /content/child1/child2/child3.html is >> mapped > to the resource provider. >> >> >> >> I have played with the resource provider's properties, trying both >> /content/child1/child2 and /content/child1/child2/ as root and >> setting owns root to true. This had no effect - the provider is only >> called if /content/child1/child2.html is added as a root path. This, >> however, is not an acceptable solution as child1 features both child2 >> and child2.html as children afterwards. >> >> >> >> In summary, this looks like a bug to me - am I right or am I missing >> a piece of the puzzle? >> >> >> >> Kind regards, >> >> Olaf >> > > >
RE: ResourceProvider not invoked when provider root path is called with HTML extension
Hi everyone I found the issue - luckily, it is a simple one: https://issues.apache.org/jira/browse/SLING-3319 In essence, the split() function of ResourceProviderEntry requires a fix. Kind regards, Olaf -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: Dienstag, 14. Januar 2014 18:54 To: users@sling.apache.org Subject: Re: ResourceProvider not invoked when provider root path is called with HTML extension Hi Well, this gets really tricky, because as has been said, this is not expected. The only advice I can give here is to do some (remote) debugging with a debugger and step through the process from the SlingMainServlet (actually probably RequestData.initResource). Regards Felix Am 14.01.2014 um 00:56 schrieb Olaf Otto : > Hello > > Apparently, the behavior that the root path with .html extension was > not resolved at all was due to some persistent invalid internal state > of the resource resolver. After modifying an arbitrary resolver > setting, the root resource is now resolved (I re-installed Sling and > the entire application to make sure this remains the case). > > However, there still is an important difference: > > When requesting "/content/child1/child2/child3.html", the path passed > to the resource provider is "/content/child1/child2/child3.html", i.e. > includes the extension. When requesting /content/child1/child2.html, > the resolver only sees the path "/content/child1/child2". Since I am > doing a subsequent resource resolution, this results in a missing > resolutionPathInfo=".html" of the resolved resource. > > Thus, the remaining question is: Why are extensions not passed to the > provider in case the root path is requested? > > Kind regards, > Olaf > > -Original Message- > From: Olaf Otto [mailto:o...@x100.de] > Sent: Dienstag, 14. Januar 2014 07:29 > To: users@sling.apache.org > Subject: RE: ResourceProvider not invoked when provider root path is > called with HTML extension > > Hello, > > Thank you for the quick replies! The /child2 path is exclusively > provided by the custom resource provider. Would anyone know a hint why > this just happens in case of a .html extension? There must be some > other actor influencing this behavior. > > Kind regards, > Olaf > > -Original Message- > From: Felix Meschberger [mailto:fmesc...@adobe.com] > Sent: Montag, 13. Januar 2014 23:38 > To: users@sling.apache.org > Subject: Re: ResourceProvider not invoked when provider root path is > called with HTML extension > > Hi > > As Alex said, this is not expected, but . > > Do you happen to have a node /content/child1/child2.html in the repository ? > If so, this would overwrite the ResourceProvider because it has a full > path match as opposed to just ./child2. > > Regards > Felix > > Am 13.01.2014 um 14:09 schrieb Olaf Otto : > >> Hi all, >> >> >> >> I have created a resource provider adding content as children into a >> tree of existing JCR content, like this: >> >> >> >> /content/child1 ß JCR content >> >> /content/child1/child2 ß Provided by ResourceProvider >> >> >> >> This works as expected: child2 is returned as a child of child1, and >> invoking /content/child1/child2 yields the provided resource. >> However, when calling /content/child1/child2.html, the resource >> provider is never asked for a resource. Instead, the default get >> servlet returns a synthetic resource, causing a redirect to >> /content/child1/child2.html/, resulting in a 404. Using a different >> extension works - when I call /content/child1/child2.json, the >> provider is called. Children of the root path however work with a >> .html extension: A request to /content/child1/child2/child3.html is >> mapped > to the resource provider. >> >> >> >> I have played with the resource provider's properties, trying both >> /content/child1/child2 and /content/child1/child2/ as root and >> setting owns root to true. This had no effect - the provider is only >> called if /content/child1/child2.html is added as a root path. This, >> however, is not an acceptable solution as child1 features both child2 >> and child2.html as children afterwards. >> >> >> >> In summary, this looks like a bug to me - am I right or am I missing >> a piece of the puzzle? >> >> >> >> Kind regards, >> >> Olaf >> > > >
RE: ResourceProvider not invoked when provider root path is called with HTML extension
Hello Apparently, the behavior that the root path with .html extension was not resolved at all was due to some persistent invalid internal state of the resource resolver. After modifying an arbitrary resolver setting, the root resource is now resolved (I re-installed Sling and the entire application to make sure this remains the case). However, there still is an important difference: When requesting "/content/child1/child2/child3.html", the path passed to the resource provider is "/content/child1/child2/child3.html", i.e. includes the extension. When requesting /content/child1/child2.html, the resolver only sees the path "/content/child1/child2". Since I am doing a subsequent resource resolution, this results in a missing resolutionPathInfo=".html" of the resolved resource. Thus, the remaining question is: Why are extensions not passed to the provider in case the root path is requested? Kind regards, Olaf -----Original Message- From: Olaf Otto [mailto:o...@x100.de] Sent: Dienstag, 14. Januar 2014 07:29 To: users@sling.apache.org Subject: RE: ResourceProvider not invoked when provider root path is called with HTML extension Hello, Thank you for the quick replies! The /child2 path is exclusively provided by the custom resource provider. Would anyone know a hint why this just happens in case of a .html extension? There must be some other actor influencing this behavior. Kind regards, Olaf -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: Montag, 13. Januar 2014 23:38 To: users@sling.apache.org Subject: Re: ResourceProvider not invoked when provider root path is called with HTML extension Hi As Alex said, this is not expected, but Do you happen to have a node /content/child1/child2.html in the repository ? If so, this would overwrite the ResourceProvider because it has a full path match as opposed to just /child2. Regards Felix Am 13.01.2014 um 14:09 schrieb Olaf Otto : > Hi all, > > > > I have created a resource provider adding content as children into a > tree of existing JCR content, like this: > > > > /content/child1 ß JCR content > > /content/child1/child2 ß Provided by ResourceProvider > > > > This works as expected: child2 is returned as a child of child1, and > invoking /content/child1/child2 yields the provided resource. However, > when calling /content/child1/child2.html, the resource provider is > never asked for a resource. Instead, the default get servlet returns a > synthetic resource, causing a redirect to > /content/child1/child2.html/, resulting in a 404. Using a different > extension works - when I call /content/child1/child2.json, the > provider is called. Children of the root path however work with a > .html extension: A request to /content/child1/child2/child3.html is > mapped to the resource provider. > > > > I have played with the resource provider's properties, trying both > /content/child1/child2 and /content/child1/child2/ as root and setting > owns root to true. This had no effect - the provider is only called if > /content/child1/child2.html is added as a root path. This, however, is > not an acceptable solution as child1 features both child2 and > child2.html as children afterwards. > > > > In summary, this looks like a bug to me - am I right or am I missing a > piece of the puzzle? > > > > Kind regards, > > Olaf >
RE: ResourceProvider not invoked when provider root path is called with HTML extension
Hello, Thank you for the quick replies! The /child2 path is exclusively provided by the custom resource provider. Would anyone know a hint why this just happens in case of a .html extension? There must be some other actor influencing this behavior. Kind regards, Olaf -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: Montag, 13. Januar 2014 23:38 To: users@sling.apache.org Subject: Re: ResourceProvider not invoked when provider root path is called with HTML extension Hi As Alex said, this is not expected, but Do you happen to have a node /content/child1/child2.html in the repository ? If so, this would overwrite the ResourceProvider because it has a full path match as opposed to just /child2. Regards Felix Am 13.01.2014 um 14:09 schrieb Olaf Otto : > Hi all, > > > > I have created a resource provider adding content as children into a > tree of existing JCR content, like this: > > > > /content/child1 ß JCR content > > /content/child1/child2 ß Provided by ResourceProvider > > > > This works as expected: child2 is returned as a child of child1, and > invoking /content/child1/child2 yields the provided resource. However, > when calling /content/child1/child2.html, the resource provider is > never asked for a resource. Instead, the default get servlet returns a > synthetic resource, causing a redirect to > /content/child1/child2.html/, resulting in a 404. Using a different > extension works - when I call /content/child1/child2.json, the > provider is called. Children of the root path however work with a > .html extension: A request to /content/child1/child2/child3.html is mapped to the resource provider. > > > > I have played with the resource provider's properties, trying both > /content/child1/child2 and /content/child1/child2/ as root and setting > owns root to true. This had no effect - the provider is only called if > /content/child1/child2.html is added as a root path. This, however, is > not an acceptable solution as child1 features both child2 and > child2.html as children afterwards. > > > > In summary, this looks like a bug to me - am I right or am I missing a > piece of the puzzle? > > > > Kind regards, > > Olaf >
ResourceProvider not invoked when provider root path is called with HTML extension
Hi all, I have created a resource provider adding content as children into a tree of existing JCR content, like this: /content/child1 ß JCR content /content/child1/child2 ß Provided by ResourceProvider This works as expected: child2 is returned as a child of child1, and invoking /content/child1/child2 yields the provided resource. However, when calling /content/child1/child2.html, the resource provider is never asked for a resource. Instead, the default get servlet returns a synthetic resource, causing a redirect to /content/child1/child2.html/, resulting in a 404. Using a different extension works when I call /content/child1/child2.json, the provider is called. Children of the root path however work with a .html extension: A request to /content/child1/child2/child3.html is mapped to the resource provider. I have played with the resource providers properties, trying both /content/child1/child2 and /content/child1/child2/ as root and setting owns root to true. This had no effect - the provider is only called if /content/child1/child2.html is added as a root path. This, however, is not an acceptable solution as child1 features both child2 and child2.html as children afterwards. In summary, this looks like a bug to me am I right or am I missing a piece of the puzzle? Kind regards, Olaf
Re: Feasible Use Case?
Hi Sam I am having trouble really understanding the use case. OBRs serve the deployment of bundles, but I take it you are trying to centralize access to services provided by various bundles? What do you mean by "local" sling repository? An idenpendent JCR node in an independent OSGi container? Since OBRs are basically bundle sources (much like a maven repo), I am uncertain what you mean by gateway to an OBR. Could you elaborate a bit more on you goals? Regards, Olaf On 02/24/2013 11:08 AM, sam wrote: I have been coming up to speed over the past week and some on the various OSGi offerings and am specifically interested in what Sling has to offer for an upcoming project. Based on our requirements I have been toying with the idea of having a centralized local instance(s) of Sling to act as a gateway to several remote OBRs. This would permit administration and approval of what is visible to connecting parties. I think moving forward in a PoC with an approach like this it would be good to represent or possibly mirror the remote OBRs in a local Sling *Repository per remote OBR configuration*. Being fairly new to OSGi and the various offerings and ways of deployment I am not certain if this is a sound idea or possibly if a better alternative approach would be preferable? In addition, it is not clear to me how to best set this up with Sling. I have read the documentation covering the installation and upgrading of bundles but how to create a new and isolated repository in Sling is not clear. The idea is that remote OBR foo.bar is meant for product versions of foo.bar and all access to a local instance should not inter-mix with anything outside of this. So really having a node per product that represents a branch in one repository is not enough I think. For configuration, I'm looking at running Sling as a feature within Karaf. Also here I'm not sure if this ideal but the separation provided by Karaf in being able to easily add additional children is fairly attractive. Future deployments of web applications into a new war feature is very possible, the basic feature concept alone seems like it could be useful. I'm not sure if this done often or if it is better to run Sling standalone? Thanks -- View this message in context: http://apache-sling.73963.n3.nabble.com/Feasible-Use-Case-tp4021906.html Sent from the Sling - Users mailing list archive at Nabble.com.
Sling, rendering and multicore architectures
Hi all, I would like to gather a few ideas concerning a granular, perhaps even generic approach to better using multicore architectures in Sling. First, some context: Basically, I am facing a scenario where we are running a rather sophisticated web application (lot's of dynamic stuff, closed user groups, content inheritance, personalized navigation and the like). The complexity is well under control using a decent bundle-based modularization in conjunction with Spring, Adaptable etc. Currently, we have page rendering times* of about 300 - 500ms (with 0 caching whatsoever) on a multicore architecture with few but high powered cores (Intel xeon 3.5 Ghz+). However, some of our target platforms are SPARCs featuring many, but not very powerful cores (e.g. 1.2 Ghz per Thread, 32+ Threads). On such an architecture, the rendering time reaches around 1.5 - 3 Seconds, while, given the known average loads, most of the available CPUs are completely idle. We are working on reducing the rendering times further, but profiling clearly shows that there is not enough room for optimization left to bring this down to our goal of 500ms. * This means the time to render the complete HTML on the server side. Now, I'd of course like to make better use of the multicore architecture for rendering. However, it appears that parallel rendering of JSPs is a violation of specs (see for example this discussion: http://osdir.com/ml/java.jasig.uportal.devel/2006-09/msg00094.html). What I am wondering is if there is something in Sling that could be used to achieve parallel rendering, even if just for some dedicated components. I am thinking in the area of includes or maybe by extending the sling scripting support for JSPs. Some constraints for the sake of a greater challenge: - Changing the target architecture is not an option in the near future - Likewise is shifting some stuff to the client (i.e. more AJAX) - Caching is *not* the solution (we can only do this for part of the content, but the load times have to be acceptable when the cache is cleared...). - There is a 2 GB memory limit, thus thread contention means quick death :-) Any ideas, hints or opinions are highly appreciated. Regards, Olaf
Velocity scripting support - release?
Hi there I think the current velocity scripting support is, albeit some open issues persist, ready for a first release. I see there already is a 2.0.0 tag for it - will this version be deployed to the releases repository? I'd then use it in a vital development project, so we can collect issues improvements for the next version ;-) Regards, Olaf ___ Olaf Otto IKGE* externe Mitarbeiter, Unic AG, Bern CSS Versicherung Tribschenstrasse 21 CH-6002 Luzern Telefon +41 (0)58 277 11 11 Telefax +41 (0)58 277 12 12 olaf.o...@css.ch www.css.ch / www.intras.ch ___ CSS Kranken-Versicherung AG, CSS Versicherung AG, INTRAS Kranken-Versicherung AG, INTRAS Versicherung AG, Arcosana AG, Auxilia Kranken-Versicherung AG Von:Mike Müller An: "'users@sling.apache.org'" Datum: 25.08.2010 16:22 Betreff:RE: Velocity scripting support > On Wed, Aug 25, 2010 at 4:07 PM, Mike Müller > wrote: > > I just upgraded and tested the Velocity scripting > > support to the latest stable version 1.6.4. > > Thanks! > > > > > What about making Velocity scripting to a first citizen > > scripting bundle and move it to bundles/scripting/velocity?... > > My preference is to leave it under contrib/scripting/velocity, so as > to keep our core small. That doesn't prevent us from releasing it. Okay, that's fine for me. In this case I would like to make a release 2.0.0. best regards mike -- Der Inhalt dieses E-Mails ist streng vertraulich und möglicherweise gesetzlich besonders geschützt. Dieses E-Mail ist nur für den Adressaten bestimmt. Wenn Sie nicht der beabsichtigte Empfänger sind, ist es Ihnen nicht gestattet und stellt möglicherweise einen Gesetzesverstoss dar, dieses E-Mail zu kopieren, zu verbreiten oder anderweitig zu verwenden. In diesem Fall sollten Sie uns so schnell wie möglich benachrichtigen und dieses E-Mail löschen. Le contenu de ce courriel est strictement confidentiel et probablement légalement protégé. Il n'est adressé qu'aux destinataires mentionnés. Si vous n'en faites pas partie, vous n'avez pas l'autorisation de le copier, ni de le diffuser, ni même de le destiner à un autre usage - ce qui dans chaque cas peut en effet constituer une infraction à la loi. Dans ce cas, vous devriez nous en informer immédiatement et effacer ce courriel. Il contenuto del presente messaggio elettronico è da considerare di massima riservatezza e possibilmente è protetto in modo particolare dalla legge. La presente e-mail è riservata alla sola attenzione della persona destinataria. Se lei non è la persona che avrebbe dovuto ricevere la e-mail, non le è permesso e possibilmente rappresenta una violazione della legge, copiare la presente e-mail, diffonderla o utilizzarla in qualsiasi altro modo. In questo caso lei dovrebbe informarci al più presto possibile e cancellare la presente e-mail.
Antwort: Re: Re: Velocity scripting support
Hi Bertrand, I've completed my tests with the bundle and can report that it does not work with my setup, unless some issues are resolved. I have reported the problems in SLING-1700, SLING-1701 and SLING-1702. Once I had that fixed, thinks worked fine! I'd really like to know, though, why velocity scripts should not be executed in case of a POST request (see VelocityTemplatesScriptEngine). Regards, Olaf _______ Olaf Otto IKGE* externe Mitarbeiter, Unic AG, Bern CSS Versicherung Tribschenstrasse 21 CH-6002 Luzern Telefon +41 (0)58 277 11 11 Telefax +41 (0)58 277 12 12 olaf.o...@css.ch www.css.ch / www.intras.ch ___ CSS Kranken-Versicherung AG, CSS Versicherung AG, INTRAS Kranken-Versicherung AG, INTRAS Versicherung AG, Arcosana AG, Auxilia Kranken-Versicherung AG Von:Bertrand Delacretaz An: users@sling.apache.org Datum: 25.08.2010 16:31 Betreff:Re: Re: Velocity scripting support On Wed, Aug 25, 2010 at 4:23 PM, wrote: > ...I will also test the scripting support against the latest velocity release > tomorrow, thereby also testing whether it integrates with the latest Day > CQ5 distribution (I expect that should be interesting). The question of > course is what kind of tests must be performed before one would consider a > release... I'm no velocity expert...I'd suggest checking that all the velocity features that you need work as expected, and if possible run some stress tests and watch for memory leaks. > ...Perhaps it would be best to create release candidates beforehand > and use those within an actual project?... We'll rather create a release, and another one if problems are discovered. Release early, release often! Please let us know the results of your tests, and if things look good I can prepare a release in the next few days. -Bertrand -- Der Inhalt dieses E-Mails ist streng vertraulich und möglicherweise gesetzlich besonders geschützt. Dieses E-Mail ist nur für den Adressaten bestimmt. Wenn Sie nicht der beabsichtigte Empfänger sind, ist es Ihnen nicht gestattet und stellt möglicherweise einen Gesetzesverstoss dar, dieses E-Mail zu kopieren, zu verbreiten oder anderweitig zu verwenden. In diesem Fall sollten Sie uns so schnell wie möglich benachrichtigen und dieses E-Mail löschen. Le contenu de ce courriel est strictement confidentiel et probablement légalement protégé. Il n'est adressé qu'aux destinataires mentionnés. Si vous n'en faites pas partie, vous n'avez pas l'autorisation de le copier, ni de le diffuser, ni même de le destiner à un autre usage - ce qui dans chaque cas peut en effet constituer une infraction à la loi. Dans ce cas, vous devriez nous en informer immédiatement et effacer ce courriel. Il contenuto del presente messaggio elettronico è da considerare di massima riservatezza e possibilmente è protetto in modo particolare dalla legge. La presente e-mail è riservata alla sola attenzione della persona destinataria. Se lei non è la persona che avrebbe dovuto ricevere la e-mail, non le è permesso e possibilmente rappresenta una violazione della legge, copiare la presente e-mail, diffonderla o utilizzarla in qualsiasi altro modo. In questo caso lei dovrebbe informarci al più presto possibile e cancellare la presente e-mail.
Antwort: RE: Antwort: RE: Velocity scripting support
Hi Mike Indeed, the SlingScriptAdapterFactory appears to load the scripting providers using autodetection of the corresponding bundle metadata. However, the velocityengine has never been called so far, and I've managed to track down the problem, which itself was invisible due to a severely flawed exception handling in the ScriptEngineManager. Apparently, the default logging configuration of apache velocity 1.6.2 has classloading issues in OSGi. It appears the velocity LogManager performs in-bundle classloading and ends up having the same interface loaded from two different classloaders (the velocity scripting support bundle and the velocity bundle), thus failing to assert that the configured logger implements the org.apache.velocity.runtime.log.LogChute interface. I will look into this. Thanks, Olaf ___ Olaf Otto IKGE* externe Mitarbeiter, Unic AG, Bern CSS Versicherung Tribschenstrasse 21 CH-6002 Luzern Telefon +41 (0)58 277 11 11 Telefax +41 (0)58 277 12 12 olaf.o...@css.ch www.css.ch / www.intras.ch ___ CSS Kranken-Versicherung AG, CSS Versicherung AG, INTRAS Kranken-Versicherung AG, INTRAS Versicherung AG, Arcosana AG, Auxilia Kranken-Versicherung AG Von:Mike Müller An: "'users@sling.apache.org'" Datum: 26.08.2010 13:47 Betreff:RE: Antwort: RE: Velocity scripting support Hi Olaf You should be able to use velocity scripting just by install the bundle. There's no additional configuration needed. The scripts which should be resolved by velocity scripting must have .vlt as extension. That should also work with your version of sling. best regards mike > @Mike Müller: > > Hi, > How exactly did you get the velocity scripting to work? The > 2.0.0 snapshot > version does not have any scr metadata and the factory is not > detected by > Sling (I'm running felix 1.4x and Sling engine version 2.0.7 > R897784 btw, > and cannot change.). Did you simply install the scripting api > and velocity > bundles or was there additional configuration involved? > > Regards, > Olaf > > ___ > > Olaf Otto IKGE* > externe Mitarbeiter, Unic AG, Bern > CSS Versicherung > Tribschenstrasse 21 > CH-6002 Luzern > Telefon +41 (0)58 277 11 11 > Telefax +41 (0)58 277 12 12 > olaf.o...@css.ch > www.css.ch / www.intras.ch > ___ > > CSS Kranken-Versicherung AG, CSS Versicherung AG, > INTRAS Kranken-Versicherung AG, INTRAS Versicherung AG, > Arcosana AG, Auxilia Kranken-Versicherung AG > > > > Von:Mike Müller > An: "'users@sling.apache.org'" > Datum: 25.08.2010 16:22 > Betreff:RE: Velocity scripting support > > > > > On Wed, Aug 25, 2010 at 4:07 PM, Mike Müller > > wrote: > > > I just upgraded and tested the Velocity scripting > > > support to the latest stable version 1.6.4. > > > > Thanks! > > > > > > > > What about making Velocity scripting to a first citizen > > > scripting bundle and move it to bundles/scripting/velocity?... > > > > My preference is to leave it under contrib/scripting/velocity, so as > > to keep our core small. That doesn't prevent us from releasing it. > > Okay, that's fine for me. In this case I would like to make a > release 2.0.0. > > best regards > mike > > > -- > Der Inhalt dieses E-Mails ist streng vertraulich und > möglicherweise gesetzlich besonders geschützt. Dieses E-Mail > ist nur für den Adressaten bestimmt. Wenn Sie nicht der > beabsichtigte Empfänger sind, ist es Ihnen nicht gestattet > und stellt möglicherweise einen Gesetzesverstoss dar, dieses > E-Mail zu kopieren, zu verbreiten oder anderweitig zu > verwenden. In diesem Fall sollten Sie uns so schnell wie > möglich benachrichtigen und dieses E-Mail löschen. > > Le contenu de ce courriel est strictement confidentiel et > probablement légalement protégé. Il n'est adressé qu'aux > destinataires mentionnés. Si vous n'en faites pas partie, > vous n'avez pas l'autorisation de le copier, ni de le > diffuser, ni même de le destiner à un autre usage - ce qui > dans chaque cas peut en effet constituer une infraction à la > loi. Dans ce cas, vous devriez nous en informer immédiatement > et effacer ce courriel. > > Il contenuto del presente messaggio elettronico è da > considerare di massima riservatezza e possibilmente è > protetto in modo particolare dalla legge. La presente e-mail > è riservata alla sola attenzione della persona destinataria. &
Antwort: RE: Velocity scripting support
@Mike Müller: Hi, How exactly did you get the velocity scripting to work? The 2.0.0 snapshot version does not have any scr metadata and the factory is not detected by Sling (I'm running felix 1.4x and Sling engine version 2.0.7 R897784 btw, and cannot change.). Did you simply install the scripting api and velocity bundles or was there additional configuration involved? Regards, Olaf ___ Olaf Otto IKGE* externe Mitarbeiter, Unic AG, Bern CSS Versicherung Tribschenstrasse 21 CH-6002 Luzern Telefon +41 (0)58 277 11 11 Telefax +41 (0)58 277 12 12 olaf.o...@css.ch www.css.ch / www.intras.ch ___ CSS Kranken-Versicherung AG, CSS Versicherung AG, INTRAS Kranken-Versicherung AG, INTRAS Versicherung AG, Arcosana AG, Auxilia Kranken-Versicherung AG Von:Mike Müller An: "'users@sling.apache.org'" Datum: 25.08.2010 16:22 Betreff:RE: Velocity scripting support > On Wed, Aug 25, 2010 at 4:07 PM, Mike Müller > wrote: > > I just upgraded and tested the Velocity scripting > > support to the latest stable version 1.6.4. > > Thanks! > > > > > What about making Velocity scripting to a first citizen > > scripting bundle and move it to bundles/scripting/velocity?... > > My preference is to leave it under contrib/scripting/velocity, so as > to keep our core small. That doesn't prevent us from releasing it. Okay, that's fine for me. In this case I would like to make a release 2.0.0. best regards mike -- Der Inhalt dieses E-Mails ist streng vertraulich und möglicherweise gesetzlich besonders geschützt. Dieses E-Mail ist nur für den Adressaten bestimmt. Wenn Sie nicht der beabsichtigte Empfänger sind, ist es Ihnen nicht gestattet und stellt möglicherweise einen Gesetzesverstoss dar, dieses E-Mail zu kopieren, zu verbreiten oder anderweitig zu verwenden. In diesem Fall sollten Sie uns so schnell wie möglich benachrichtigen und dieses E-Mail löschen. Le contenu de ce courriel est strictement confidentiel et probablement légalement protégé. Il n'est adressé qu'aux destinataires mentionnés. Si vous n'en faites pas partie, vous n'avez pas l'autorisation de le copier, ni de le diffuser, ni même de le destiner à un autre usage - ce qui dans chaque cas peut en effet constituer une infraction à la loi. Dans ce cas, vous devriez nous en informer immédiatement et effacer ce courriel. Il contenuto del presente messaggio elettronico è da considerare di massima riservatezza e possibilmente è protetto in modo particolare dalla legge. La presente e-mail è riservata alla sola attenzione della persona destinataria. Se lei non è la persona che avrebbe dovuto ricevere la e-mail, non le è permesso e possibilmente rappresenta una violazione della legge, copiare la presente e-mail, diffonderla o utilizzarla in qualsiasi altro modo. In questo caso lei dovrebbe informarci al più presto possibile e cancellare la presente e-mail.
Antwort: Re: Re: Velocity scripting support
Sounds great - I will report the test results tomorrow until 16:00 MEST. Thanks, Olaf ___ Olaf Otto IKGE* externe Mitarbeiter, Unic AG, Bern CSS Versicherung Tribschenstrasse 21 CH-6002 Luzern Telefon +41 (0)58 277 11 11 Telefax +41 (0)58 277 12 12 olaf.o...@css.ch www.css.ch / www.intras.ch ___ CSS Kranken-Versicherung AG, CSS Versicherung AG, INTRAS Kranken-Versicherung AG, INTRAS Versicherung AG, Arcosana AG, Auxilia Kranken-Versicherung AG Von:Bertrand Delacretaz An: users@sling.apache.org Datum: 25.08.2010 16:31 Betreff:Re: Re: Velocity scripting support On Wed, Aug 25, 2010 at 4:23 PM, wrote: > ...I will also test the scripting support against the latest velocity release > tomorrow, thereby also testing whether it integrates with the latest Day > CQ5 distribution (I expect that should be interesting). The question of > course is what kind of tests must be performed before one would consider a > release... I'm no velocity expert...I'd suggest checking that all the velocity features that you need work as expected, and if possible run some stress tests and watch for memory leaks. > ...Perhaps it would be best to create release candidates beforehand > and use those within an actual project?... We'll rather create a release, and another one if problems are discovered. Release early, release often! Please let us know the results of your tests, and if things look good I can prepare a release in the next few days. -Bertrand -- Der Inhalt dieses E-Mails ist streng vertraulich und möglicherweise gesetzlich besonders geschützt. Dieses E-Mail ist nur für den Adressaten bestimmt. Wenn Sie nicht der beabsichtigte Empfänger sind, ist es Ihnen nicht gestattet und stellt möglicherweise einen Gesetzesverstoss dar, dieses E-Mail zu kopieren, zu verbreiten oder anderweitig zu verwenden. In diesem Fall sollten Sie uns so schnell wie möglich benachrichtigen und dieses E-Mail löschen. Le contenu de ce courriel est strictement confidentiel et probablement légalement protégé. Il n'est adressé qu'aux destinataires mentionnés. Si vous n'en faites pas partie, vous n'avez pas l'autorisation de le copier, ni de le diffuser, ni même de le destiner à un autre usage - ce qui dans chaque cas peut en effet constituer une infraction à la loi. Dans ce cas, vous devriez nous en informer immédiatement et effacer ce courriel. Il contenuto del presente messaggio elettronico è da considerare di massima riservatezza e possibilmente è protetto in modo particolare dalla legge. La presente e-mail è riservata alla sola attenzione della persona destinataria. Se lei non è la persona che avrebbe dovuto ricevere la e-mail, non le è permesso e possibilmente rappresenta una violazione della legge, copiare la presente e-mail, diffonderla o utilizzarla in qualsiasi altro modo. In questo caso lei dovrebbe informarci al più presto possibile e cancellare la presente e-mail.
Antwort: Re: Velocity scripting support
Excellent! I will also test the scripting support against the latest velocity release tomorrow, thereby also testing whether it integrates with the latest Day CQ5 distribution (I expect that should be interesting). The question of course is what kind of tests must be performed before one would consider a release. Perhaps it would be best to create release candidates beforehand and use those within an actual project? Regards, Olaf ___ Olaf Otto IKGE* externe Mitarbeiter, Unic AG, Bern CSS Versicherung Tribschenstrasse 21 CH-6002 Luzern Telefon +41 (0)58 277 11 11 Telefax +41 (0)58 277 12 12 olaf.o...@css.ch www.css.ch / www.intras.ch ___ CSS Kranken-Versicherung AG, CSS Versicherung AG, INTRAS Kranken-Versicherung AG, INTRAS Versicherung AG, Arcosana AG, Auxilia Kranken-Versicherung AG Von:Bertrand Delacretaz An: users@sling.apache.org Datum: 25.08.2010 16:12 Betreff:Re: Velocity scripting support On Wed, Aug 25, 2010 at 4:07 PM, Mike Müller wrote: > I just upgraded and tested the Velocity scripting > support to the latest stable version 1.6.4. Thanks! > > What about making Velocity scripting to a first citizen > scripting bundle and move it to bundles/scripting/velocity?... My preference is to leave it under contrib/scripting/velocity, so as to keep our core small. That doesn't prevent us from releasing it. -Bertrand -- Der Inhalt dieses E-Mails ist streng vertraulich und möglicherweise gesetzlich besonders geschützt. Dieses E-Mail ist nur für den Adressaten bestimmt. Wenn Sie nicht der beabsichtigte Empfänger sind, ist es Ihnen nicht gestattet und stellt möglicherweise einen Gesetzesverstoss dar, dieses E-Mail zu kopieren, zu verbreiten oder anderweitig zu verwenden. In diesem Fall sollten Sie uns so schnell wie möglich benachrichtigen und dieses E-Mail löschen. Le contenu de ce courriel est strictement confidentiel et probablement légalement protégé. Il n'est adressé qu'aux destinataires mentionnés. Si vous n'en faites pas partie, vous n'avez pas l'autorisation de le copier, ni de le diffuser, ni même de le destiner à un autre usage - ce qui dans chaque cas peut en effet constituer une infraction à la loi. Dans ce cas, vous devriez nous en informer immédiatement et effacer ce courriel. Il contenuto del presente messaggio elettronico è da considerare di massima riservatezza e possibilmente è protetto in modo particolare dalla legge. La presente e-mail è riservata alla sola attenzione della persona destinataria. Se lei non è la persona che avrebbe dovuto ricevere la e-mail, non le è permesso e possibilmente rappresenta una violazione della legge, copiare la presente e-mail, diffonderla o utilizzarla in qualsiasi altro modo. In questo caso lei dovrebbe informarci al più presto possibile e cancellare la presente e-mail.
Re: Re: Velocity scripting support
Thank you for the quick response, Betrand! So in that case I might give the snapshot version located here: https://repository.apache.org/content/repositories/snapshots/org/apache/sling/org.apache.sling.scripting.velocity/2.0.0-SNAPSHOT/ a quick try. If there is anyone already using velocity I'd be glad to know. Regards, Olaf ___ Olaf Otto IKGE* externe Mitarbeiter, Unic AG, Bern CSS Versicherung Tribschenstrasse 21 CH-6002 Luzern Telefon +41 (0)58 277 11 11 Telefax +41 (0)58 277 12 12 olaf.o...@css.ch www.css.ch / www.intras.ch ___ CSS Kranken-Versicherung AG, CSS Versicherung AG, INTRAS Kranken-Versicherung AG, INTRAS Versicherung AG, Arcosana AG, Auxilia Kranken-Versicherung AG Von:Bertrand Delacretaz An: users@sling.apache.org Datum: 25.08.2010 12:07 Betreff:Re: Velocity scripting support Hi Olaf, 2010/8/25 : > ...I am wondering what the state of the velocity scripting support for Sling > is. It appears to be mentioned here and there, but all I could find is a > snapshot version of it in the repository. Is there a release version of > velocity scripting available and is anyone using it?... We didn't release contrib/scripting/velocity yet, but if people are using it successfully I guess we could. The bundle just wraps the velocity engine, so there's not much that can be broken in it ;-) -Bertrand -- Der Inhalt dieses E-Mails ist streng vertraulich und möglicherweise gesetzlich besonders geschützt. Dieses E-Mail ist nur für den Adressaten bestimmt. Wenn Sie nicht der beabsichtigte Empfänger sind, ist es Ihnen nicht gestattet und stellt möglicherweise einen Gesetzesverstoss dar, dieses E-Mail zu kopieren, zu verbreiten oder anderweitig zu verwenden. In diesem Fall sollten Sie uns so schnell wie möglich benachrichtigen und dieses E-Mail löschen. Le contenu de ce courriel est strictement confidentiel et probablement légalement protégé. Il n'est adressé qu'aux destinataires mentionnés. Si vous n'en faites pas partie, vous n'avez pas l'autorisation de le copier, ni de le diffuser, ni même de le destiner à un autre usage - ce qui dans chaque cas peut en effet constituer une infraction à la loi. Dans ce cas, vous devriez nous en informer immédiatement et effacer ce courriel. Il contenuto del presente messaggio elettronico è da considerare di massima riservatezza e possibilmente è protetto in modo particolare dalla legge. La presente e-mail è riservata alla sola attenzione della persona destinataria. Se lei non è la persona che avrebbe dovuto ricevere la e-mail, non le è permesso e possibilmente rappresenta una violazione della legge, copiare la presente e-mail, diffonderla o utilizzarla in qualsiasi altro modo. In questo caso lei dovrebbe informarci al più presto possibile e cancellare la presente e-mail.
Velocity scripting support
Hi everybody, I am wondering what the state of the velocity scripting support for Sling is. It appears to be mentioned here and there, but all I could find is a snapshot version of it in the repository. Is there a release version of velocity scripting available and is anyone using it? Thanks and regards, Olaf ___ Olaf Otto IKGE* externe Mitarbeiter, Unic AG, Bern CSS Versicherung Tribschenstrasse 21 CH-6002 Luzern Telefon +41 (0)58 277 11 11 Telefax +41 (0)58 277 12 12 olaf.o...@css.ch www.css.ch / www.intras.ch ___ CSS Kranken-Versicherung AG, CSS Versicherung AG, INTRAS Kranken-Versicherung AG, INTRAS Versicherung AG, Arcosana AG, Auxilia Kranken-Versicherung AG -- Der Inhalt dieses E-Mails ist streng vertraulich und möglicherweise gesetzlich besonders geschützt. Dieses E-Mail ist nur für den Adressaten bestimmt. Wenn Sie nicht der beabsichtigte Empfänger sind, ist es Ihnen nicht gestattet und stellt möglicherweise einen Gesetzesverstoss dar, dieses E-Mail zu kopieren, zu verbreiten oder anderweitig zu verwenden. In diesem Fall sollten Sie uns so schnell wie möglich benachrichtigen und dieses E-Mail löschen. Le contenu de ce courriel est strictement confidentiel et probablement légalement protégé. Il n'est adressé qu'aux destinataires mentionnés. Si vous n'en faites pas partie, vous n'avez pas l'autorisation de le copier, ni de le diffuser, ni même de le destiner à un autre usage - ce qui dans chaque cas peut en effet constituer une infraction à la loi. Dans ce cas, vous devriez nous en informer immédiatement et effacer ce courriel. Il contenuto del presente messaggio elettronico è da considerare di massima riservatezza e possibilmente è protetto in modo particolare dalla legge. La presente e-mail è riservata alla sola attenzione della persona destinataria. Se lei non è la persona che avrebbe dovuto ricevere la e-mail, non le è permesso e possibilmente rappresenta una violazione della legge, copiare la presente e-mail, diffonderla o utilizzarla in qualsiasi altro modo. In questo caso lei dovrebbe informarci al più presto possibile e cancellare la presente e-mail.
