RE: LogicalDriverManagerXAConnection not closed
It means that you forgot to close the connection when you
were finished using it.
-Original Message-
From: Jaco van Rooijen [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 09, 2000 12:08 AM
To: Orion-Interest
Subject: RE: LogicalDriverManagerXAConnection not closed
Anybody have any ideas?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jaco van
Rooijen
Sent: 06 October 2000 13:40
To: Orion-Interest
Subject: LogicalDriverManagerXAConnection not closed
I am developing against the stable 1.3.8
I get an output stating:
LogicalDriverManagerXAConnection not closed, check your code!
Created at:
java.lang.Throwable: OrionCMTConnection created
at com.evermind.sql.ai.init(JAX)
at com.evermind.sql.OrionCMTDataSource.getConnection(JAX)
at
com.agri24.data.LegalEntityBean.getConnection(LegalEntityBean.java:843)
at
com.agri24.data.LegalEntityBean.ejbFindByAgri24ID(LegalEntityBean.java:463)
at
LegalEntityHome_EntityHomeWrapper55.findByAgri24ID(LegalEntityHome_EntityHom
eWrapper55.java:1122)
at java.lang.reflect.Method.invoke(Native Method)
at com.evermind.server.rmi.bd.run(JAX)
at com.evermind.server.rmi.bb.hy(JAX)
at com.evermind.server.rmi.bb.run(JAX)
at com.evermind.util.f.run(JAX)
LegalEntityBean.java:843 says -
Connection newConn =
((javax.sql.DataSource)ctx.lookup("java:comp/env/jdbc/LegalEntityDataSource"
)).getConnection();
The call goes through, but the console has this exception on it. What does
that mean?
Regards
Jaco
RE: 1.3.8 on NT causing Dr. Watson
What you are experiencing is the wonderful native thread support under Linux where threads are really separate processes with shared code and data space. It is perfectly normal however, actually Sun's JDC has a nice article on it http://developer.java.sun.com/developer/technicalArticles/Programming/linux/ . Will -Original Message- From: Dale M. Boresz [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 03, 2000 7:17 AM To: Orion-Interest Subject: Re: 1.3.8 on NT causing Dr. Watson Vidur Dhanda wrote: Hello, Has anyone else experienced erratic java.exe (JDK1.3) failures while running 1.3.8 on a NT4.0SP6a box. All of a sudden I have started getting Dr Watson while running orion. I can't detect any pattern -- it can crash while it is doing nothing and when there is heavy load on the server. My configuration: JDK1.3, Orion 1.3.8, NTWS4.0SP6a, 384MB, AMD K6. Vidur Vidur, I can't comment about jdk/orion under NT, but ... For what it's worth, here's what I've noticed while running Sun's jdk1.3 under Linux: When Orion is started, there are about a dozen jdk1.3 processess that start up simultaneously! Under jdk1.2.2, there was only one. As I modify the server.xml file - adding or dropping sites, the number of jdk1.3 instances increases dramatically. If I kill the first jdk1.3 instance started, they all terminate. Under jdk1.2.2, I've never noticed any additional processes start up. I don't know what these processes are doing, or why this happens, but it's just something that I've noticed, and the fact that the number of processes rapidly increases is pretty alarming. So... I went back to jdk1.2.2 for now, and that works fine. I'd suggest that maybe you can check out the number of processes running under NT, and see if perhaps you're experiencing something similar. -Dale
RE: Reloading servlets, XSLT, AS/400 ?
Yes, the company I work for runs Orion on the AS/400. If you search the archives you might find some previous posts that will help. The IBM VM is pretty badly broken so you have to avoid using some features like security and EAR reloading. Also you'll have to disable the JIT... but otherwise it works quite well and we are shipping production code that uses it. Regards, Will -Original Message- From: Vitaly Lipovetsky [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 20, 2000 12:59 AM To: Orion-Interest Subject: Reloading servlets, XSLT, AS/400 ? 1. Does Orion support reloading servlets without restart server ? 2. Does Orion support XSLT ? 3. Has anyone tried to run Orion on AS/400 ?
RE: Deployment confusions
The FAQ http://www.orionserver.com/faq/ describes how to use the admin.jar tool to deploy to a remote server. There is no "command-line method to acquire the client support files from the Orion server." I'm not even sure what you mean by this, but if you question is about RMI stubs etc those are all transparently generated by the server. I don't know what "a command-line method to invoke a EJB client(s)." is either. If you are making a client.jar then it is up to you to make it an executable jar via the manifest Main-Class: attribute. You are welcome to "take this server off our list", but I have a feeling that you will have a very hard time finding a better server, or one that somehow does everything for you. I sympathize with your troubles learning J2EE and application servers that support the standard. It is big and complex as enterprise tools tend to be, so you will need a bit of patience. Regards, Will -Original Message- From: Richard Landon [mailto:[EMAIL PROTECTED]] Sent: Friday, September 08, 2000 1:16 PM To: Orion-Interest Subject: Deployment confusions I am probably stupid, but I still very confused about deployment using Orion. My understanding from the documentation is that I must edit the server.xml and add the code. No problem for me as a developer. But when it comes to migrating our application into pre-production or production, whoa-nellie, that ain't going to cut it. So, here's they same question I posted here repeatedly since yesterday. I need a command-line method to deploy the ear file once it gets built into the Orion server. I need a command-line method to acquire the client support files from the Orion server. I need a command-line method to invoke a EJB client(s). I guess I spend the rest of the day trying to figure it out, and then take this server off our list.
RE: J2EE Application Security
I am currently working on the security design for our application and seem to be working on the same issues that you are. I intend to provide a complete ACL based security infrastructure at the EJB level. J2EE's method level security is far from sufficient for my purposes. For example: SessionEJB.createPurchaseOrder(store, ...); access to that method is determined by the user's permissions at the _store_ level, not the method itself. I would be interested in further discussion outside of the bounds of this list, if anyone else is interested. My current thought is to use the EJBContext.getUserPrincipal() to identify the Principal, and then use that information to look up the proper ACLs (most likely entity EJBs), and then check the appropriate permissions for the Principal. Naturally I don't want to be passing the Principal to every method invocation, and the API appears to already provide a nice way. Tying my own infrastructure into the J2EE server itself could be a problem however, especially if other servers don't have the nice API that Orion does. Regards, Will -Original Message- From: WebDev [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 29, 2000 2:07 AM To: Orion-Interest Subject: Re: How does the env-entry tags work? Magnus, Thanks for your prompt reply. We thought about the method you described but there are a few things, we are worried about using this approach. First would be the overhead involved instantiating additional session beans, assuming stateful beans would fit the best, assigning one stateful session bean per user session to handle security and calling the required entity/session bean(s). The big drawback would be that this would require immense system ressources, database connections might 'run out' (we're using Interbase 6.0 SS on Linux and experienced a lack of connections at say 15 concurrent users even when using a pooled connection, which might not be an orion issue but rather related to Interbase), plus assuming the 'inter-beans' calls in the same container require marshalling via rmi (PLEASE prove me wrong on this one ;) thus an additional performance loss which we would avoid implementing the security in entity beans. Being relatively new to J2EE one of the big rumours is to avoid stateful session beans at all because of performance issues and re-modelling the controller of the application by means of stateless session beans/servlets/http-session management. Again, please prove me wrong, but due to the lack of documentation it is pretty unknown how orion internally handles such cases (do calls from bean to bean in the same container require marshalling? How do stateful session beans perform?) One more thing about the system we are implementing. The point we can't use security as orion provides it - even with its dynamic user/group management - is because we have to restrict access to an entity bean's methods depending on the user requesting it and of the instance of the bean. To illustrate it, user A may have access to say all methods of bean B if bean B contains data X, but only may have access to say 2 methods if the very same bean contains data Y. TIA, Markus Wolf On Mon, Aug 28, 2000 at 10:28:53PM +0200, Magnus Rydin wrote: Hi there, sorry for not understanding that you were talking about the descriptors. Why dont you logon through a sessionbean that handles all the fine-grained security stuff you want it to have? Normal procedure would be to have a page acting as a logon form, that will then call a session bean with the values you want, say username/password. Then lets say that sessionBean returns another sessionbean, that can only be created with a ValidUserObject (given by the first sessionBean if authentication was ok). Now ,the returned sessionbean could hold all the methods you want to enable for valid users.. I cant get my head arround why you do not want to send in the identifying values through a method.. Another way of sending data between the layers would of course be by using JMS messaging.. But how would you make a 'session' out of it? Hopefully, someone else on this list gets a better grip on what it is that you want to accomplish, as I fear that this is not totaly clear to me. WR -Original Message- From: WebDev [mailto:[EMAIL PROTECTED]] Sent: den 28 augusti 2000 21:55 To: Orion-Interest Subject: Re: How does the env-entry tags work? Magnus, We are trying to find a way to handle user authorization at the entity-bean level to be able to restrict access to methods at the lowest level. However we dont want to use users/group in the J2EE 'manner' but rather provide our own user-management. Orion got a wonderful interface to dynamically add/remove users and groups but it isn't as fine grained as we'd prefer to have it. Our first problem was to 'transfer' the logged in user-id from the servlet layer to the ejb-layer, thus we tried to send it via the
