Keep the samples simple and provide documentation. -----Original Message----- From: Dan Becker <[EMAIL PROTECTED]> Sent: Tuesday, May 13, 2008 3:11 PM To: tuscany-dev@ws.apache.org Subject: Re: More Java security fixes on the way
Raymond Feng wrote: > I'm looking into the patch you contributed with > https://issues.apache.org/jira/browse/TUSCANY-2290. There is one issue > catching my eyes. We have samples in Tuscany today which use some > technology APIs, for example, to start the ActiveMQ JMS broker. To run > these samples with Java2 security enabled, we have to surround some of > the calls with privileged block. That seems to complicate/pollute the > samples. Should we leave these samples as-is without supporting Java2 > security (or grant permissions to the sample code directly with a policy > file)? Hi Raymond, Thanks for the code review. Those are excellent points you bring up which not only apply to the Tuscany-provided samples, but potentially also to user-solutions which exploit Tuscany as the samples do. Do you require such code to implement security blocks (and grant permissions with policy files) or do you simplify and not support security? In my opinion, the answer would depend on what you would expect the user to do and what the purpose of the user code would be. For instance with application level code and samples I would never expect the user to have to add privileged blocks or add security policy permissions. On the other hand, for extensions and code that used Tuscany SPIs, I would expect requirements for the extension to provide privileged blocks and security policy permissions. In the current situation you mention (starting the ActiveMQ JMS broker), I agree it does complicate the samples. But any user application that attempts to start the JMS broker and support Java 2 security would have to do the same thing. I am fine removing the complicating security code from the sample, but then I should write a wiki page or other documentation that shows how to support this. Other opinions? -- Thanks, Dan Becker
