You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2009/01/19 10:13:27 UTC
Re: svn commit: r735626 - /incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
Just jumping on this commit to ask if you are using a Java coding
standard ? I guess it's pretty close to Sun's standard, but it would
be good to add a page on the (comming) web site. Many Apache project
already have one, so it's just a matter to copy/paste one of them, and
adapt it to the project's choice.
For instance, in this commit, if you follow the Java coding standard,
the "static final log = ..." should be "static final LOG = ..."
(http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367).
But it can stay the way it is if the project decide too. The main goal
is to have a common approach for all the code.
Thanks !
On Mon, Jan 19, 2009 at 9:09 AM, <lh...@apache.org> wrote:
> Author: lhazlewood
> Date: Mon Jan 19 00:09:43 2009
> New Revision: 735626
>
> URL: http://svn.apache.org/viewvc?rev=735626&view=rev
> Log:
> Modified to be more robust and based on common Subject lookup mechanisms (SecurityUtils). If not found there, only then fall back to a system property (previous behavior).
>
> Modified:
> incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
>
> Modified: incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
> URL: http://svn.apache.org/viewvc/incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java?rev=735626&r1=735625&r2=735626&view=diff
> ==============================================================================
> --- incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java (original)
> +++ incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java Mon Jan 19 00:09:43 2009
> @@ -19,11 +19,17 @@
> package org.jsecurity.spring.remoting;
>
> import org.aopalliance.intercept.MethodInvocation;
> +import org.apache.commons.logging.Log;
> +import org.apache.commons.logging.LogFactory;
> +import org.jsecurity.SecurityUtils;
> import org.jsecurity.session.Session;
> +import org.jsecurity.subject.Subject;
> import org.springframework.remoting.support.DefaultRemoteInvocationFactory;
> import org.springframework.remoting.support.RemoteInvocation;
> import org.springframework.remoting.support.RemoteInvocationFactory;
>
> +import java.io.Serializable;
> +
> /**
> * A {@link RemoteInvocationFactory} that passes the session ID to the server via a
> * {@link RemoteInvocation} {@link RemoteInvocation#getAttribute(String) attribute}.
> @@ -38,7 +44,7 @@
> */
> public class SecureRemoteInvocationFactory extends DefaultRemoteInvocationFactory {
>
> - //TODO - complete JavaDoc
> + private static final Log log = LogFactory.getLog(SecureRemoteInvocationFactory.class);
>
> public static final String SESSION_ID_KEY = Session.class.getName() + "_ID_KEY";
>
> @@ -53,13 +59,30 @@
> * @return a remote invocation object containing the current session ID as an attribute.
> */
> public RemoteInvocation createRemoteInvocation(MethodInvocation methodInvocation) {
> - String sessionId = System.getProperty(SESSION_ID_SYSTEM_PROPERTY_NAME);
> + Serializable sessionId = null;
> + Subject subject = SecurityUtils.getSubject();
> + if (subject != null) {
> + Session session = subject.getSession(false);
> + if (session != null) {
> + sessionId = session.getId();
> + }
> + }
> +
> if (sessionId == null) {
> - throw new IllegalStateException("System property [" + SESSION_ID_SYSTEM_PROPERTY_NAME + "] is not set. " +
> - "This property must be set to the JSecurity session ID for remote calls to function.");
> + if (log.isTraceEnabled()) {
> + log.trace("No Session found for the currently executing subject via subject.getSession(false). " +
> + "Attempting to revert back to the 'jsecurity.session.id' system property...");
> + }
> + }
> + sessionId = System.getProperty(SESSION_ID_SYSTEM_PROPERTY_NAME);
> + if (sessionId == null && log.isTraceEnabled()) {
> + log.trace("No 'jsecurity.session.id' system property found. Heuristics have been exhausted; " +
> + "RemoteInvocation will not contain a sessionId.");
> }
> RemoteInvocation ri = new RemoteInvocation(methodInvocation);
> - ri.addAttribute(SESSION_ID_KEY, sessionId);
> + if (sessionId != null) {
> + ri.addAttribute(SESSION_ID_KEY, sessionId);
> + }
>
> return ri;
> }
>
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: svn commit: r735626 - /incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
Posted by Emmanuel Lecharny <el...@gmail.com>.
Craig L Russell wrote:
>
>>
>> For instance, in this commit, if you follow the Java coding standard,
>> the "static final log = ..." should be "static final LOG = ..."
>> (http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367).
>
> This is the first time I've seen the upper case convention applied to
> a reference type. I've seen it applied to primitives, like int,
> String, float, etc. But never to Log or I18NHelper or the like.
http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html
IMHO, it enters into the 'constant' category. But this can be discussed,
this is just a matter of taste. (I have used both style, log and LOG,
depending on the projects I worked on. But in any case, when the
project's convention told me to use log, or LOG, I complied :)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: svn commit: r735626 -
/incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jan 19, 2009, at 1:13 AM, Emmanuel Lecharny wrote:
> Just jumping on this commit to ask if you are using a Java coding
> standard ? I guess it's pretty close to Sun's standard, but it would
> be good to add a page on the (comming) web site. Many Apache project
> already have one, so it's just a matter to copy/paste one of them, and
> adapt it to the project's choice.
>
> For instance, in this commit, if you follow the Java coding standard,
> the "static final log = ..." should be "static final LOG = ..."
> (http://java.sun.com/docs/codeconv/html/
> CodeConventions.doc8.html#367).
This is the first time I've seen the upper case convention applied to
a reference type. I've seen it applied to primitives, like int,
String, float, etc. But never to Log or I18NHelper or the like.
So can anyone find a reference to something looking like the proposed:
+ private static final Log LOG =
LogFactory.getLog(SecureRemoteInvocationFactory.class);
>
> But it can stay the way it is if the project decide too. The main goal
> is to have a common approach for all the code.
I agree that the dev team should adopt standards.
Craig
>
>
>
> Thanks !
>
> On Mon, Jan 19, 2009 at 9:09 AM, <lh...@apache.org> wrote:
>> Author: lhazlewood
>> Date: Mon Jan 19 00:09:43 2009
>> New Revision: 735626
>>
>> URL: http://svn.apache.org/viewvc?rev=735626&view=rev
>> Log:
>> Modified to be more robust and based on common Subject lookup
>> mechanisms (SecurityUtils). If not found there, only then fall
>> back to a system property (previous behavior).
>>
>> Modified:
>> incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/
>> remoting/SecureRemoteInvocationFactory.java
>>
>> Modified: incubator/jsecurity/trunk/support/spring/src/org/
>> jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
>> URL: http://svn.apache.org/viewvc/incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java?rev=735626&r1=735625&r2=735626&view=diff
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =====================================================================
>> --- incubator/jsecurity/trunk/support/spring/src/org/jsecurity/
>> spring/remoting/SecureRemoteInvocationFactory.java (original)
>> +++ incubator/jsecurity/trunk/support/spring/src/org/jsecurity/
>> spring/remoting/SecureRemoteInvocationFactory.java Mon Jan 19
>> 00:09:43 2009
>> @@ -19,11 +19,17 @@
>> package org.jsecurity.spring.remoting;
>>
>> import org.aopalliance.intercept.MethodInvocation;
>> +import org.apache.commons.logging.Log;
>> +import org.apache.commons.logging.LogFactory;
>> +import org.jsecurity.SecurityUtils;
>> import org.jsecurity.session.Session;
>> +import org.jsecurity.subject.Subject;
>> import
>> org.springframework.remoting.support.DefaultRemoteInvocationFactory;
>> import org.springframework.remoting.support.RemoteInvocation;
>> import org.springframework.remoting.support.RemoteInvocationFactory;
>>
>> +import java.io.Serializable;
>> +
>> /**
>> * A {@link RemoteInvocationFactory} that passes the session ID to
>> the server via a
>> * {@link RemoteInvocation} {@link
>> RemoteInvocation#getAttribute(String) attribute}.
>> @@ -38,7 +44,7 @@
>> */
>> public class SecureRemoteInvocationFactory extends
>> DefaultRemoteInvocationFactory {
>>
>> - //TODO - complete JavaDoc
>> + private static final Log log =
>> LogFactory.getLog(SecureRemoteInvocationFactory.class);
>>
>> public static final String SESSION_ID_KEY =
>> Session.class.getName() + "_ID_KEY";
>>
>> @@ -53,13 +59,30 @@
>> * @return a remote invocation object containing the current
>> session ID as an attribute.
>> */
>> public RemoteInvocation createRemoteInvocation(MethodInvocation
>> methodInvocation) {
>> - String sessionId =
>> System.getProperty(SESSION_ID_SYSTEM_PROPERTY_NAME);
>> + Serializable sessionId = null;
>> + Subject subject = SecurityUtils.getSubject();
>> + if (subject != null) {
>> + Session session = subject.getSession(false);
>> + if (session != null) {
>> + sessionId = session.getId();
>> + }
>> + }
>> +
>> if (sessionId == null) {
>> - throw new IllegalStateException("System property [" +
>> SESSION_ID_SYSTEM_PROPERTY_NAME + "] is not set. " +
>> - "This property must be set to the JSecurity
>> session ID for remote calls to function.");
>> + if (log.isTraceEnabled()) {
>> + log.trace("No Session found for the currently
>> executing subject via subject.getSession(false). " +
>> + "Attempting to revert back to the
>> 'jsecurity.session.id' system property...");
>> + }
>> + }
>> + sessionId =
>> System.getProperty(SESSION_ID_SYSTEM_PROPERTY_NAME);
>> + if (sessionId == null && log.isTraceEnabled()) {
>> + log.trace("No 'jsecurity.session.id' system property
>> found. Heuristics have been exhausted; " +
>> + "RemoteInvocation will not contain a
>> sessionId.");
>> }
>> RemoteInvocation ri = new RemoteInvocation(methodInvocation);
>> - ri.addAttribute(SESSION_ID_KEY, sessionId);
>> + if (sessionId != null) {
>> + ri.addAttribute(SESSION_ID_KEY, sessionId);
>> + }
>>
>> return ri;
>> }
>>
>>
>>
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: svn commit: r735626 - /incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
Posted by Les Hazlewood <lh...@apache.org>.
Sorry, I should have jumped on this earlier:
When I said 'template', I wasn't talking about a template for new files, I
was talking about a 'code formatting' template specific to the IDE. That
is, you can configure the source formatting rules and export it as a
template that other IDEs could import to ensure everyone is using the same
formatting rules.
A file template of what goes where in the file (constants vs constructors vs
mutators, etc) is a different case.
But I do believe that we should also have such a file template that is
defined in the wiki that people can use when creating new classes. In fact,
that wiki page should probably have as attachments the IDE-specific file
templates that can be imported depending on the IDE you use.
And I think it would be nice to have Jalopy or Checkstyle integrated in the
build to use as a gut check before you commit...
Cheers,
Les
On Mon, Jan 19, 2009 at 3:47 PM, Daniel J. Lauk <da...@gmail.com>wrote:
> If I may add my two cents:
> No offence meant, but IMHO you'd be way better of if you'd not use
> templates for new files, but instead enforce a common coding style
> through a source code pretty printer and share the syntax rule file
> for that.
> Then always before committing to the central repository you could run
> the code through that to get lost of developer specific favourite
> formattings etc.
> Also every developer can have their own little variations for their
> convenience and still commit in the same format.
>
> Cheers,
> DJ
>
> 2009/1/19 Emmanuel Lecharny <el...@gmail.com>:
> > On Mon, Jan 19, 2009 at 5:49 PM, Les Hazlewood <lh...@apache.org>
> wrote:
> >> Hi Emmanuel,
> >>
> >> We haven't really specified a formal standard per se, but you're right,
> it
> >> is essentially nearly identical to Sun's. Prior to joining the ASF
> >> Incubator, most of us (all of us?) used IntelliJ IDEA and just used its
> >> default formatting template, which is Sun's.
> >
> > That's all good. If you were to use some specific template (and I
> > think that, at some point, this is necessary), then you would have to
> > create the formatting for IDE used by the team, and describe what has
> > been changed from sun's standard.
> >
> > Typically, but this is more about template than formatting, being able
> > to create a class with the ASF header automatically injecteed, plus
> > the @author tag created, that's a way to remain consistent and will
> > make Rat happy.
> >
> > Then, inject those templates into subversion (here, this is a
> > different matter than the .project or .classpath, as it's not
> > something any build tool can generate).
> >
> >
> > Thanks !
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
> >
>
Re: svn commit: r735626 - /incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
Posted by Emmanuel Lecharny <el...@gmail.com>.
On Tue, Jan 20, 2009 at 7:46 AM, Daniel J. Lauk <da...@gmail.com> wrote:
> Now, to prevent that someone gets me wrong: I consider having code
> conventions a *good* thing! They provide guidance, which is very
> desirable.
I didn't get you wrong :) We are on the very same page here.
> But I think the way of applying/enforcing them *does* matter and I
> think that templates are the wrong one to choose.
Templates don't force you to anything if you don't apply them to your
IDE, and use yours instead ;) But for lazzy dev like me, if I can
apply a defined template, then I'm happy !
This is all what I suggest : define a template for a couple of IDE in
use, and let the users chose to apply them or not.
> Anyway, in case you're interested in my approach, I did a quick web
> search. Here are some promising pointers. I haven't tried any of them
> yet, due to a lack of spare time:
> * http://checkstyle.sourceforge.net/
> * http://jalopy.sourceforge.net/
> * http://java-source.net/open-source/code-beautifiers
All of those tools are valuable. I have used Jalopy for years, and
checkstyle a bit. I you are using one of those tools, that's just
fine, as soon as the code if formatted when saving the file. The
biggest advantages of those tools is that they can detect some code
with bad smell (like 'if' without '{'). I personally think that you
should use a code formatter and a template plus run either checkstyle,
Jalopy, or whatever tool you like.
(Btw, Eclipse let you use two tools : a template, which defines things
like headers, comments, etc when you create new files, and a
formatter, which format your file when you save it or explicitely when
you ask for a format. I think you have the same approach with IDEA)
Thanks Daniel!
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: svn commit: r735626 - /incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
Posted by "Daniel J. Lauk" <da...@gmail.com>.
Now, to prevent that someone gets me wrong: I consider having code
conventions a *good* thing! They provide guidance, which is very
desirable.
But I think the way of applying/enforcing them *does* matter and I
think that templates are the wrong one to choose.
So: Let's just agree to disagree.
Anyway, in case you're interested in my approach, I did a quick web
search. Here are some promising pointers. I haven't tried any of them
yet, due to a lack of spare time:
* http://checkstyle.sourceforge.net/
* http://jalopy.sourceforge.net/
* http://java-source.net/open-source/code-beautifiers
Cheers,
DJ
Re: svn commit: r735626 - /incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
Posted by Emmanuel Lecharny <el...@gmail.com>.
> No offence meant, but IMHO you'd be way better of if you'd not use
> templates for new files, but instead enforce a common coding style
> through a source code pretty printer and share the syntax rule file
> for that.
> Then always before committing to the central repository you could run
> the code through that to get lost of developer specific favourite
> formattings etc.
> Also every developer can have their own little variations for their
> convenience and still commit in the same format.
What is important is the result, not the path you have to follow in
order to get it :)
The only problem with your proposed approach is that you have to set
up some Subversion triggered formating.
IMO, it's also quite useless : most of the developpers will follow the
common rules as soon as they have been adopted.
Anyway, it's not really important. What is is to get a source we can
compare when merging or doing a diff, without being confronted with
thousands of differences because someone use tabs and others use
spaces, or brackets have been moved around to please each developers
:)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: svn commit: r735626 - /incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
Posted by "Daniel J. Lauk" <da...@gmail.com>.
If I may add my two cents:
No offence meant, but IMHO you'd be way better of if you'd not use
templates for new files, but instead enforce a common coding style
through a source code pretty printer and share the syntax rule file
for that.
Then always before committing to the central repository you could run
the code through that to get lost of developer specific favourite
formattings etc.
Also every developer can have their own little variations for their
convenience and still commit in the same format.
Cheers,
DJ
2009/1/19 Emmanuel Lecharny <el...@gmail.com>:
> On Mon, Jan 19, 2009 at 5:49 PM, Les Hazlewood <lh...@apache.org> wrote:
>> Hi Emmanuel,
>>
>> We haven't really specified a formal standard per se, but you're right, it
>> is essentially nearly identical to Sun's. Prior to joining the ASF
>> Incubator, most of us (all of us?) used IntelliJ IDEA and just used its
>> default formatting template, which is Sun's.
>
> That's all good. If you were to use some specific template (and I
> think that, at some point, this is necessary), then you would have to
> create the formatting for IDE used by the team, and describe what has
> been changed from sun's standard.
>
> Typically, but this is more about template than formatting, being able
> to create a class with the ASF header automatically injecteed, plus
> the @author tag created, that's a way to remain consistent and will
> make Rat happy.
>
> Then, inject those templates into subversion (here, this is a
> different matter than the .project or .classpath, as it's not
> something any build tool can generate).
>
>
> Thanks !
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: svn commit: r735626 - /incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
Posted by Emmanuel Lecharny <el...@gmail.com>.
On Mon, Jan 19, 2009 at 5:49 PM, Les Hazlewood <lh...@apache.org> wrote:
> Hi Emmanuel,
>
> We haven't really specified a formal standard per se, but you're right, it
> is essentially nearly identical to Sun's. Prior to joining the ASF
> Incubator, most of us (all of us?) used IntelliJ IDEA and just used its
> default formatting template, which is Sun's.
That's all good. If you were to use some specific template (and I
think that, at some point, this is necessary), then you would have to
create the formatting for IDE used by the team, and describe what has
been changed from sun's standard.
Typically, but this is more about template than formatting, being able
to create a class with the ASF header automatically injecteed, plus
the @author tag created, that's a way to remain consistent and will
make Rat happy.
Then, inject those templates into subversion (here, this is a
different matter than the .project or .classpath, as it's not
something any build tool can generate).
Thanks !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: svn commit: r735626 - /incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
Posted by Les Hazlewood <lh...@apache.org>.
Hi Emmanuel,
We haven't really specified a formal standard per se, but you're right, it
is essentially nearly identical to Sun's. Prior to joining the ASF
Incubator, most of us (all of us?) used IntelliJ IDEA and just used its
default formatting template, which is Sun's.
I agree that we should formally specify it now that the team is continuing
to grow - it would be good. Jeremy usually used a file template when
creating new classes that we've followed - that should be posted as well.
And you're right - all final attributes should be in all uppercase - it
helps with readability. For some reason though, Log instances seemed to
have sneaked in under the radar. It should be consistent :)
Cheers,
Les
On Mon, Jan 19, 2009 at 4:13 AM, Emmanuel Lecharny <el...@gmail.com>wrote:
> Just jumping on this commit to ask if you are using a Java coding
> standard ? I guess it's pretty close to Sun's standard, but it would
> be good to add a page on the (comming) web site. Many Apache project
> already have one, so it's just a matter to copy/paste one of them, and
> adapt it to the project's choice.
>
> For instance, in this commit, if you follow the Java coding standard,
> the "static final log = ..." should be "static final LOG = ..."
> (http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367).
> But it can stay the way it is if the project decide too. The main goal
> is to have a common approach for all the code.
>
> Thanks !
>
> On Mon, Jan 19, 2009 at 9:09 AM, <lh...@apache.org> wrote:
> > Author: lhazlewood
> > Date: Mon Jan 19 00:09:43 2009
> > New Revision: 735626
> >
> > URL: http://svn.apache.org/viewvc?rev=735626&view=rev
> > Log:
> > Modified to be more robust and based on common Subject lookup mechanisms
> (SecurityUtils). If not found there, only then fall back to a system
> property (previous behavior).
> >
> > Modified:
> >
> incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
> >
> > Modified:
> incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
> > URL:
> http://svn.apache.org/viewvc/incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java?rev=735626&r1=735625&r2=735626&view=diff
> >
> ==============================================================================
> > ---
> incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
> (original)
> > +++
> incubator/jsecurity/trunk/support/spring/src/org/jsecurity/spring/remoting/SecureRemoteInvocationFactory.java
> Mon Jan 19 00:09:43 2009
> > @@ -19,11 +19,17 @@
> > package org.jsecurity.spring.remoting;
> >
> > import org.aopalliance.intercept.MethodInvocation;
> > +import org.apache.commons.logging.Log;
> > +import org.apache.commons.logging.LogFactory;
> > +import org.jsecurity.SecurityUtils;
> > import org.jsecurity.session.Session;
> > +import org.jsecurity.subject.Subject;
> > import
> org.springframework.remoting.support.DefaultRemoteInvocationFactory;
> > import org.springframework.remoting.support.RemoteInvocation;
> > import org.springframework.remoting.support.RemoteInvocationFactory;
> >
> > +import java.io.Serializable;
> > +
> > /**
> > * A {@link RemoteInvocationFactory} that passes the session ID to the
> server via a
> > * {@link RemoteInvocation} {@link RemoteInvocation#getAttribute(String)
> attribute}.
> > @@ -38,7 +44,7 @@
> > */
> > public class SecureRemoteInvocationFactory extends
> DefaultRemoteInvocationFactory {
> >
> > - //TODO - complete JavaDoc
> > + private static final Log log =
> LogFactory.getLog(SecureRemoteInvocationFactory.class);
> >
> > public static final String SESSION_ID_KEY = Session.class.getName() +
> "_ID_KEY";
> >
> > @@ -53,13 +59,30 @@
> > * @return a remote invocation object containing the current session
> ID as an attribute.
> > */
> > public RemoteInvocation createRemoteInvocation(MethodInvocation
> methodInvocation) {
> > - String sessionId =
> System.getProperty(SESSION_ID_SYSTEM_PROPERTY_NAME);
> > + Serializable sessionId = null;
> > + Subject subject = SecurityUtils.getSubject();
> > + if (subject != null) {
> > + Session session = subject.getSession(false);
> > + if (session != null) {
> > + sessionId = session.getId();
> > + }
> > + }
> > +
> > if (sessionId == null) {
> > - throw new IllegalStateException("System property [" +
> SESSION_ID_SYSTEM_PROPERTY_NAME + "] is not set. " +
> > - "This property must be set to the JSecurity session
> ID for remote calls to function.");
> > + if (log.isTraceEnabled()) {
> > + log.trace("No Session found for the currently executing
> subject via subject.getSession(false). " +
> > + "Attempting to revert back to the '
> jsecurity.session.id' system property...");
> > + }
> > + }
> > + sessionId = System.getProperty(SESSION_ID_SYSTEM_PROPERTY_NAME);
> > + if (sessionId == null && log.isTraceEnabled()) {
> > + log.trace("No 'jsecurity.session.id' system property found.
> Heuristics have been exhausted; " +
> > + "RemoteInvocation will not contain a sessionId.");
> > }
> > RemoteInvocation ri = new RemoteInvocation(methodInvocation);
> > - ri.addAttribute(SESSION_ID_KEY, sessionId);
> > + if (sessionId != null) {
> > + ri.addAttribute(SESSION_ID_KEY, sessionId);
> > + }
> >
> > return ri;
> > }
> >
> >
> >
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>