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
