On Fri, Mar 19, 2010 at 12:37 PM, Kalle Korhonen <[email protected]> wrote: > On Tue, Mar 16, 2010 at 2:28 PM, Les Hazlewood <[email protected]> wrote: >> I don't like catching an exception much either, but I think the >> isSecurityManagerAvailable() method might cause us problems - >> SecurityUtils is a very public-facing API and having that method might >> confuse people - in most cases, a SecurityManager should always be >> available. That one wouldn't be available is a client-tier-only very >> special case. >> Maybe catching the exception for now is ok until after 1.0? Maybe we >> can deal with it a little cleaner after the release? > > Agree, that's the practical solution for now. It's only in the support > module so it's not hugely critical.
Agreed. >> Also, if we change the JNLP file from using properties to using >> arguments (<argument>...), we won't need to sign the .jars at all. >> That should be ok. > > Very good. Yes, using the property was really the only reason why they > needed to be signed. I'd rather not if that can be avoided. It's been > awhile since I've last worked on webstart apps myself. I'll see if I > can easily get it working by using an argument instead. Cool. This should help: http://java.sun.com/javase/6/docs/technotes/guides/javaws/developersguide/syntax.html#application_desc >> Another idea is, once we become a top-level project is to maybe move >> all of the samples to a samples/recipes project? Kind of like >> Wicket's wicket-stuff project or similar? > > Making it an independently releasable module serves the same purpose > with less overhead. I'd only make it sub-project if there were > sufficient number of people interested in working only on that > sub-project. For a sample, I don't see it happening. Yeah, I agree - I guess I was thinking more along the lines of extended integration across multiple technologies in addition to samples - kind of like why wicket-stuff exists. It is also interesting that their project exists outside of Apache so the community can write samples and integration code for whatever they want, even if it's not Apache compatible (GPL, LGPL, etc). Something to think about if the community finds a need for something like this. Cheers, Les
