Re: How to bind session to a newly logged in session
Hello Joshua, You can authenticate the JCR session by adding the parameter sling:authRequestLogin (details in [1]) to a request. So, for instance, you can access your content with the URL http://localhost:/content/mynode.html?sling:authRequestLogin and the user will be prompted by credentials, which will be used to login to the JCR session. Then you can use the access control features of JCR (Section 6.9 of the specification) to prevent unauthorized access to your resource without proper authentication. Kind regards, Douglas [1] https://svn.apache.org/repos/asf/incubator/sling/trunk/extensions/httpauth/src/main/java/org/apache/sling/httpauth/impl/AuthorizationHeaderAuthenticationHandler.java On Mon, Feb 9, 2009 at 21:36, Joshua Oransky cazza...@gmail.com wrote: Hello, I am logging in users via the Repository.login method which returns me a JCR session. How do I bind this new authorized session so that if I call currentNode.getSession() it returns me the authorized one and not the anonymous one from before? Or do I have to store the JCR session in an HTTP session? Thanks - Josh -- Douglas Jose http://douglasjose.com - Use free software. Help us make a free world.
Re: Source Tree Structure
Hi all, first of all +1 for a restructuring. Separating the contrib stuff from the main code, but still having the possibility to check out everything in one place, makes a lot of sense. If more and more new bundles come in (ala CookingEggServiceBundle), which won't be actively maintained most of the time, Sling needs some rules and a good location for those. On Thu, Feb 12, 2009 at 8:26 AM, Carsten Ziegeler cziege...@apache.org wrote: With this structure we give a clean sign what we really support and which parts we would like to support but may be are not able to. We can/ will have release out of the contrib dir as well, but this are single module releases then and driven by community requests. We, Felix and I, also thought about doing something like: /sling/trunk - the maintained stuff /sling/contrib - the contrib stuff But this directory layout creates too much of a friction. People checking out Sling never see the Contrib stuff. You are right, non-trunk stuff is quite hidden. We could also do something like /sling/trunk/core (I've no good name for this, so I just choose core) /sling/trunk/contrib But this looks ugly from a directory layout perspective as well. So I think the current proposal is a best efforts. I might look a bit ugly, but it gives a clearer separation, just as felix put an empty line between the core stuff and contrib/examples in his draft of the structure. The only way to do that in a folder structure is to add a level. contrib would be in the middle of 11 other folders, and I personally favor a self-explaining directory structure. Instead of core (which is probably misleading a bit, as one expects some kind of core engine there), here are some other ideas (pure brainstorming, so please ignore the bad ones ;-)): - main - sling - released - framework - heart And some Google Set help for inspiration: http://labs.google.com/sets?hl=enq1=coreq2=mainq3=frameworkq4=centralq5=heartbtn=Large+Set Just my 2 cents, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: Source Tree Structure
On Thu, Feb 12, 2009 at 11:04 AM, Alexander Klimetschek aklim...@day.com wrote: I might look a bit ugly, but [...] Well, this might be true (you decide), but what I really wanted to say was: It might look a bit ugly... ;-) Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
JCR meetup in Amsterdam?
Hi, [cross-posting since this is for both Jackrabbit and Sling people] Last year we had a JCR meetup event during the ApacheCon in Amsterdam [1]. Now there's a chance of doing one again this year during the ApacheCon at the end of March [2]. The three-hour event would take place in the evening either on Monday 23rd or on Tuesday 24th. The location is the Mövenpick hotel in central Amsterdam. The meetup will only happen if we can find enough attendees, presentations and sponsors. Please let me know, preferably already by the end of this week, if you'd be interested in participating. [ ] I'd like to attend on Monday, March 23 [ ] I'd like to attend on Tuesday, March 24 Presentations can be anything JCR-related and may last between five minutes and about half an hour. [ ] I'd like to present X on Monday, March 23 [ ] I'd like to present X on Tuesday, March 24 The event will be free for everyone to attend, but we still need to cover the rent of the meeting room and other related costs. To cover these costs we're looking for companies to sponsor the event. Sponsoring is not expensive, and by sponsoring you get to support the Jackrabbit and Sling projects and get your name attached to the event. You can contact me for more details. [1] http://wiki.apache.org/jackrabbit/JcrMeetupApril2008 [2] http://www.eu.apachecon.com/c/aceu2009/ BR, Jukka Zitting
Re: Source Tree Structure
Hi, On Thu, Feb 12, 2009 at 8:26 AM, Carsten Ziegeler cziege...@apache.org wrote: Please keep in mind that Sling is a very modular system consisting mainly of a variety of bundles. Sling has the intent to separately release single modules (bundles). This is one of the number one priorities for Sling - the big bang releases are just for convenience. OK. I just want to make it easy for a Sling user to grasp what a given release (or a trunk checkout) is about. For example, if I have all these individual component releases, how do I combine them to get a functional Sling installation? Perhaps we should better highlight the Sling Launchpad releases as the base that you need to get started, and other component releases as something that you can deploy to upgrade an already existing Sling installation. Both the current and the proposed layouts make the Launchpad look like just another OSGi bundle, and you'll need to dig deep into the READMEs to figure out how to get started. How about structuring the top level of the source tree like below to make the Launchpad components more prominent? trunk/ +--- parent/ +--- launchpad/ +--- bundles/ +--- contrib/ +--- examples/ +--- tests/ The bundles directory would contain all the bundles included by default in the Launchpad, and the contrib directory would contain other components that we don't think are ready yet for inclusion in the default installation. We could still group similar bundles together using subdirectories inside the bundles and contrib directories. BR, Jukka Zitting
RE: tomcat + JNDI + sling 3
Hi Tyson
JNDI context for each type of resource seems to be different in each server, so
in order to support different application servers and servlet engines I find
that JNDI names should include the context and not let the lookup make any
decisions about the context root since there seems no to be a standard in place.
Instead of specifying JNDIResource in properties use
java:comp/env/JNDIResource when running in Tomcat, and use just
JNDIResource when running in Weblogic since in Weblogic JNDI resources are on
the global namespace.
Env = tomcat
tomcat.jndiResourceName = java:comp/env/JNDIResource
weblogic.jndiResourceName = JNDIResource
Regards,
Javier
-Mensaje original-
De: Tyson Norris [mailto:tnor...@organic.com]
Enviado el: miércoles, 11 de febrero de 2009 3:33
Para: sling-dev@incubator.apache.org
Asunto: Re: tomcat + JNDI + sling 3
Thanks Felix.
That mostly worked- I can now look up the repo in Sling, but it is
found at java:repository instead of java:comp/env/repository.
For now I just hacked my custom naming context impl to look in java:
in case java:comp/env fails.
Thanks
Tyson
On Feb 10, 2009, at 12:05 AM, Felix Meschberger fmesc...@gmail.com
wrote:
Hi Tyson,
Tyson Norris schrieb:
First, thanks for sling!
You are welcome - Glad you like it ;-)
Next, I have a question about using sling - I'd like to access my JCR
repository via JNDI within Tomcat.
I have to admit, that both Tomcat and JNDI are almost a book with
seven
seals to me ... But I give it a try ...
I believe that I have tomcat properly configured, because I can
deploy
jackrabbit org.apache.jackrabbit.j2ee.RepositoryAccessServlet
within a
webapp that does NOT deploy an embedded repository, and I can access
the repository without a problem.
However, when I deploy a similar config with sling, I believe I am
running into classloader problems, because the JNDI context does NOT
have anything bound to it.
It looks like you might really have a class loading issue. Since the
InitialContext might not be correclty set up. What you might try is to
set the Thread context ClassLoader before instantiating the
InitialContext in your SimpleInitialContextFactory class, someting
like:
ClassLoader old = Thread.currentThread.getContextClassLoader();
try {
Thread.currentThread.setContextClassLoader(
getClass().getClassLoader());
Context initCtx = new InitialContext();
Context ctx = (Context) initCtx.lookup(java:comp/env);
finally {
Thread.currentThread.setContextClassLoader(old);
}
Regards
Felix
Exception stack is below; basically I get
javax.naming.NameNotFoundException: Name java:comp is not bound in
this
Context when my (custom) jndi context impl lookup method is
executing:
Context initCtx = new InitialContext();
Context ctx = (Context) initCtx.lookup(java:comp/env);
(note that this works fine with jackrabbit webapp).
I am deploying the prepacked sling webapp from
http://incubator.apache.org/sling/site/downloads.cgi
http://incubator.apache.org/sling/site/downloads.cgi
I downloaded the src from same site, and built the
org.apache.sling.jcr.jackrabbit.client-2.0.2-incubator.jar, and
added to
sling\WEB-INF\resources\bundles.
In WEB-INF/sling.properties I added:
sling.repository.url=jndi://
magnoliaAuthor22:java.naming.factory.initial
=org.
myo.jndi.simple.SimpleInitialContextFactory,java.naming.provider.ur
l=localhost
I also added to both sling.properties AND jcr-client.properties:
sling.
bootdelegation.class.org.myo.jndi.simple.SimpleInitialContextFacto
ry = \
org.myo.jndi.simple,javax.naming,org.apache.naming
sling.bootdelegation.class.javax.naming.InitialContext = \
javax.naming
sling.bootdelegation.class.org.apache.naming.NamingContext = \
org.apache.naming
sling.bootdelegation.simple = org.myo.jndi.simple
I will try a few more things like, newer codebase of sling (I know
some
minor changes have been made to processing of sling.repository.url
property) as well as deployment in jboss.
Any ideas how to make this work in tomcat?
Thanks for any help.
Tyson
09.02.2009 15:00:54.157 *INFO* [Repository Pinger]
org.apache.sling.jcr.base.util.RepositoryAccessor Unable to acquire R
epository 'magnoliaAuthor22' via JNDI,
context={java.naming.provider.url=localhost,
java.naming.factory.initial=org.myo.
jndi.simple.SimpleInitialContextFactory}
javax.naming.NameNotFoundException: Name java:comp is not bound in
this
Context
at
org.apache.naming.NamingContext.lookup(NamingContext.java:770)
at
org.apache.naming.NamingContext.lookup(NamingContext.java:153)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at
org.myo.jndi.simple.SimpleContext.lookup(SimpleContext.java:270)
at
org.myo.jndi.simple.SimpleContext.lookup(SimpleContext.java:287)
Accessing sling/jsr content from other OSGi bundles
Hi all, Does sling provide any OSGi services for looking up/retrieving rendered/formatted content via code? Mark ...and then Buffy staked Edward. The End.
Re: Accessing sling/jsr content from other OSGi bundles
On Thu, Feb 12, 2009 at 9:55 PM, Mark Derricutt m...@talios.com wrote: Does sling provide any OSGi services for looking up/retrieving rendered/formatted content via code? Not sure what you mean Do you want to get the result of a request (eg. the HTML from a response) programmatically inside a bundle running in Sling? I guess you can do it via standard servlet API by retrieving the SlingMainServlet and calling the service method on it - but you have to provide your own request and response objects for it, since Sling expects http as environment. Don't know if there are wrappers available Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: tomcat + JNDI + sling 3
On 12 Feb 2009, at 03:27, Tyson Norris wrote: [...] However, the templating system (of Magnolia 3.6 - I will mention 4.0 later) is based on JSPs that must be managed via filesystem deployment. Please let me know if you have comments/suggestions on this approach. Did you look into the file system provider for Sling? It allows resources to be located on disk and thus would allow legacy support for JSPs stored as files through slings JSP support. -- Torgeir Veimo torg...@pobox.com
