Maurice, great comments.
I'm trying to pull together a 1.0 and finding lots of trivial work like missing
files and things of that nature due to us moving cvs repos and from ant->maven.
When I get some form of this release out, we can start working through the
security issue. I'll split out the CMP performance issue to another thread and
Cc the related expert to make sure that goes somewhere as well.
Maybe you could do something for me. The default logging setup in OpenEJB is
pretty terrible, what have you worked up and do you mind sharing your log4j
config files?
Thanks,
David
On Thu, Jun 09, 2005 at 04:42:13AM -0700, Maurice Yarrow wrote:
> Gentlemen
>
> Thank you very much for your replies. Jacek, you asked a series
> of pertinent questions about usage, etc. First let me address
> the SecurityManager issue, and then I will attempt to answer the
> others as best I can in this letter.
>
> To the catalina.policy file I added:
>
> // The permissions granted to the context root directory apply to JSP pages.
> grant codeBase "file:${catalina.home}/webapps/openejb_loader-0.9.2/-" {
> permission java.security.AllPermission;
> };
>
>
> // The permissions granted to the context WEB-INF/classes directory
> grant codeBase
> "file:${catalina.home}/webapps/openejb_loader-0.9.2/WEB-INF/classes/-" {
> permission java.security.AllPermission;
> };
>
>
> // The permission granted to the context lib/openejb_loader-0.9.2.jar
> grant codeBase
> "jar:file:${catalina.home}/webapps/openejb_loader-0.9.2/WEB-INF/lib/openejb_loader-0.9.2.jar!/-"
>
> {
> permission java.security.AllPermission;
> };
>
>
> (These were the AllPermission's you had in mind?)
>
> But I still got:
>
> INFO: Installing web application at context path /openejb_loader-0.9.2
> from URL file:/opt/tomcat/webapps/openejb_loader-0.9.2
> java.security.AccessControlException: access denied
> (java.lang.RuntimePermission accessDeclaredMembers)
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
> at
> java.security.AccessController.checkPermission(AccessController.java:401)
> at
> java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
> at
> java.lang.SecurityManager.checkMemberAccess(SecurityManager.java:1637)
> at java.lang.Class.checkMemberAccess(Class.java:1443)
> at java.lang.Class.getDeclaredField(Class.java:1213)
> at org.openejb.util.JarUtils$1.run(JarUtils.java:96)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.openejb.util.JarUtils.setHandlerSystemProperty(JarUtils.java:91)
> at org.openejb.util.JarUtils.<clinit>(JarUtils.java:69)
> at org.openejb.OpenEJB.init(OpenEJB.java:148)
> at org.openejb.OpenEJB.init(OpenEJB.java:130)
> at org.openejb.loader.EmbeddedLoader.load(EmbeddedLoader.java:71)
> at org.openejb.loader.EmbeddingLoader.load(EmbeddingLoader.java:85)
> at
> org.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:65)
> at
> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662)
> at
> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243)
> at javax.naming.InitialContext.init(InitialContext.java:219)
> at javax.naming.InitialContext.<init>(InitialContext.java:195)
> at org.openejb.loader.LoaderServlet.init(LoaderServlet.java:84)
>
> etc., etc.
>
>
> Please note that I had a while back found the exchange at:
>
> http://www.mail-archive.com/[email protected]/msg00716.html
>
> but this did not propose a workaround. At the time I left the issue
> alone, and proceeded with my OpenEJB usage by simply not turning on the
> tomcat security manager at tomcat startup (i.e., did not add option
> "-security" to the tcstart.sh.). I believe that this has not created
> any real security holes on my site because (1) tomcat does such a darned
> good job sealing off the code tree, and (2) I and my colleague are only
> putting our own web apps up on our server, so we are not concerned with
> internally created application security violations.
>
> But our web apps do take user input, and there are some darned serious
> intruders out there who understand injection and buffer overrun attacks
> pretty well. So I decided to revisit this unresolved issue at the
> advent of your decision to make a OpenEJB 1.0 release.
>
>
> Now let me try to answer some of your other questions:
> I had written:
>
> > Some issues, I just used work-arounds, but that is another matter.
>
> You asked:
>
> > Would you mind reporting them in OpenEJB ... Or are they already
> > reported?
>
> The only issue I sent up was
>
> http://blog.gmane.org/gmane.comp.java.openejb.user
>
> (11 Mar 17:53, appears nearly two-thirds the way down the page.
> This was not answered at the time. The letter I sent contains all
> relevant error messages and all relevant configuration settings or
> files.) This issue concerned my first implementation of the web apps.,
> and utilized a bean jar for each of the apps. (I had not yet written
> the single-sign-on front-ent app., which essentially now functions as a
> user portal to the services to which individual users have subscribed.)
>
> What I decided at that time was simply merge the beans of the
> two bean jars into one bean jar, meaning, instead of separate
> databases, I used only one database, even though it now contained
> some tables with no common fields. This worked fine and is what
> I have been using, but of course, I would rather have separate
> databases for organizational reasons - it's the right way.
>
> And I decided at that time not to pursue the issue, because I had
> learned, from my experiences with OpenEJB, that invariably when
> things did not work, it was a result of a misconfiguration error
> on MY part. I know people send up basic errors about Hello bean,
> etc., and I see you guys are very patient and helpful, but I had
> seen that if I re-read your documentation very carefully, and thought
> about the relevant relationships, I could always find the error
> myself, so why bother you guys? It seemed you had plenty to do on your
> plates already.
>
> However, this particular issue of the two bean jars defied my efforts
> to debug; hence, my workaround. When I next thought about it again (in
> April) I decided that the problem had probably been a result of having
> my app configuration attributes and directives in both the
>
> /opt/openejb-0.9.2/conf/openejb.conf
>
> and also two app-specific conf files. I never did revisit this
> issue because the current single database is stable, and I have
> lots of other development issues on my hands at this time.
>
> Still, if you see anything in the above mentioned letter from March,
> don't hesitate to disabuse me of my ignorance. I would most grateful.
>
>
> Lastly, you asked:
>
> > Taking the opportunity to talk about your current OpenEJB use,
> > what would you change in the upcoming releases? What's missing?
> > Do you feel that the most important thing is to support the latest
> > EJB specs or you don't care about it too much, but rather would
> > prefer having more improvements in the area of Tomcat integration?
>
> Aside from the two issues I have raised, I am been very pleased with
> the product you have built, and it has served us well. I cannot
> intelligently answer you question about EJB 2.0 compliance because I
> have not studied the specs.
>
> Ah, here is one more interesting issue: a performance issue that I had
> when querying for records. The particular table has fields for
> username, list name, and a blob of the data in the list. When I needed
> to get all list names for a given user, performance was slow, because
> the blobs were being recovered along with the username/list names.
> For this, I decided to use JDBC. This, of course, put me outside
> the context of the OpenEJB transaction processing, and is therefore
> a little risky, but no information was being inserted, so I decided,
> temporarily, to do it this way. With direct access to only the fields
> I needed but not the blobs, performance dramatically improved.
> At the time, I did try a helper (OpenEJB) bean that accessed the
> indicated table, but did not request the blob. Performance was no
> better than it was when getting the entire record. I took this to
> mean that the blob was being requested even though my helper bean
> did not ask for it. Still, I will need at some point to revisit
> this issue, because my query will need to be transaction compliant.
>
> Anyhow, many thanks for you help. You guys obviously take your
> project very seriously, and should all be very proud the what you have
> built.
>
>
> Maurice Yarrow
