RE: Oracle9i vs. Orion
Several of the Oracle9iAS developers told me that they bought a snapshot of the Orion code base approximately one year ago - since that time there have been significant modifications to the Oracle code base - which will never be a merged with Orion. They did point out however that a reasonable amount of the work on the Oracle code base was done by Ironflare and they said there is no significant reason why Ironflare couldn't re-implement the same features in the Orion code base. So they are two seperate trees and 'technically' maintained by two seperate groups. Just the group maintaining Oracles tree happens to include the entire group maintaining the Orion tree along with a bunch of Oracle engineers as well. :( -Original Message- From: Brian Chan [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 9:59 PM To: Orion-Interest Subject: Oracle9i vs. Orion How different is Oracle9i from Orion? I always thought it was the same thing but renamed. Are they essentially two different trees now maintained by different groups? - Brian
RE: is Orion dead?
Sometimes one cannot wait too long. I have a very significant growth issue that requires scaling up from 4 app servers to 15 within the next 2 months. Under the current limitations of Orion it simply won't work - so far we've cobbled solutions around the unreliable http session clustering and loadbalancing. Unless theres some change soon to deal with a lot of the big issues I can't imagine how I can stay with Orion. Definitely don't misunderstand me thats not intended to sound threatening, I love Orion and want to stay with it. I'm just pointing out that my needs may require me to switch to something where http clustering and loadalancing does work properly under high load. AJP support would go a long way to help that - because mod_jk seems to do a pretty decent job at handling stick sessions and removing machines from rotation that have died. Any ideas on when the next iteration would be released? Even a half way step or a new experimental release would be a sign that things are evolving. -Original Message- From: Joseph Ottinger [mailto:[EMAIL PROTECTED]] Sent: Friday, April 12, 2002 1:05 AM To: Orion-Interest Subject: Re: is Orion dead? ...except the wait is due to an internal refactoring that should yield significant benefits. Yourconclusion was predicted by the list in general, but I disagree; the team's still working on Orion, and I figure that people will be more happy once the new versions come out. You'd hope it would be incremental changes as it was in the past (anyone remember the three-versions-a-day times?) but that's simply not realistic considering the changes being put into place. Patience. Enjoy. - Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.comIT Consultant On Thu, 11 Apr 2002, Jarrod Roberson wrote: At 03:41 PM 4/11/2002, you wrote: Whats the current state of Ironflare and Orion? Nothing has changed in the 'stable release' of Orion for almost a year, even though there are glaring bugs in http session clustering (not even fixed in 1.5.4) and some significantly lacking components. Ironflare was supposed to be in the pavillion at JavaONE, but oddly they had no write up (apparently they didn't submit one), and didn't actually show up (so their booth was empty). There also seems to be a conspicuous infrequency to their responses here. I know that Oracle 9iAS is evolving and expanding, and I believe that IronFlare is doing a significant amount of work on the 9iAS code base (as consultants?). But whats to become of Orion? It almost appears that Oracel has consumed Orion completely and no development will happen on the old Orion. looks like someone finally figured it out! this is what happens when you get one big customer with a guaranteed revenue stream, can't much blame them myself.
AJP12
Last year at JavaONE Karl told me that Orion supported AJP12. I've tried mod_jk in several ways, tried looking for a place to set an AJP connector in Orion, and even poped open the orion.jar looking for a connector. It never worked - so I gave up many months ago. Now its becoming more important and I notice that the Oracle 9iAS supports AJP12. What gives? Karl? Magnus? AJP support?
is Orion dead?
Whats the current state of Ironflare and Orion? Nothing has changed in the 'stable release' of Orion for almost a year, even though there are glaring bugs in http session clustering (not even fixed in 1.5.4) and some significantly lacking components. Ironflare was supposed to be in the pavillion at JavaONE, but oddly they had no write up (apparently they didn't submit one), and didn't actually show up (so their booth was empty). There also seems to be a conspicuous infrequency to their responses here. I know that Oracle 9iAS is evolving and expanding, and I believe that IronFlare is doing a significant amount of work on the 9iAS code base (as consultants?). But whats to become of Orion? It almost appears that Oracel has consumed Orion completely and no development will happen on the old Orion.
Chained servlets and chained filters
I've got an interesting issue where I've got three chained filters running which all work great. One of these filters is a compression filter that modifies the Stream by compressing the final output. Unforutately I discovered that when the server sends a HTTP 500 response code, the result on the browser is not the typical ugly error page, but a blank page with a HTTP 200 response code. That won't do. I started looking through the J2EE spec and realized quickyl that the way to fetch the http response code is to deal with the raw stream (e.g. what Orion does, not me). Sure I can set the response code, but theres no way to examine find the HTTP status code. THe more I started thinking about this I started to believe this makes some sense, in almost every case you want the response code devlivered to the browser. The only time it becomes an issue is with doing chaining - and even then some chaining situations you still don't need it. It might be fair to say you only need to examine the status code when doing filters. Anywoo... Anyone given this a thought?
Another filter chaining question
I'm starting to get into some intersting space with filters and I've found yet another thing that seems like it would be a requirement for chaining filters. Order. It seems that theres no clearly defined way to know which filter will process a request first. I've been playing with placement in the web.xml and I don't seem to notice any particullar change in filter sequence. Anyone have any experience in this?
J2EE Security issue...
We've been using J2EE based security for some time now, its working great for us supporting several hundred users distributed across a handful of servers. Heres my issue - I have a set of things that happen on every page, a portion of which is looking for a 'new' login which then launches a series of things including doing database lookups, dropping stuff in the session, etc. Its occured to me that it would be significantly more effective if this was chained off the J2EE authentication, instead of checking on each page. I started looking into it and it looks like 1) its not part of the spec and 2) Orion has no specific implementation. The current implementation of J2EE security is so completely handled by the container that theres no way to get something in there. I then started going down the question of 'what is J2EE security except a filter?', so I could potentially chain a filter through there? It doesn't solve the problem because it still happens on each page hit. Anyone have any ideas on the best way to do 'postprocessing' when the user is authenticated?
RE: Caching Group Information
A HashMap would work fine unless you care to add/remove people or permissions without restarting your app server. If changing the security information is important to you, then you'll either need some method to expire old data or make sure that whatever you do to change the security information also changes the cache. I'm currently caching my group information using an object that extends HashMap but also does time-based and size-based expiration. So I have a 5 minute cache. -Original Message- From: Christian, Joanne To: Orion-Interest Sent: 3/6/2002 12:00 PM Subject: Caching Group Information Hi All, I am using a custom user manager that gets group and user information from the database. I would like to cache the database information when the user manager is initialized; and access the cache to get the user information. Can anyone suggest the best method for doing this? I am thinking about using a hashmap, but I'm not quite sure what is the best option. Thanks, Joanne
RE: Username and Password
Most of this material is not specific to Orion but defined in the J2EE specs. Part of the process is that j_username, etc are effectively 'special values' recognized by the app server when doing authentication, so you really won't ever have access to these values. But since it is defined in the spec there are very simple and standardized ways of getting some information. request.getRemoteUser() will tell you the username of the current login, and request.isUserInRole(somegroup) will tell you if the user is in a particullar role. I don't belive there is any standard way to find their password though (and you probably wouldn't want there to be if you were security minded). -Original Message- From: Christian, Joanne [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 06, 2002 9:30 AM To: Orion-Interest Subject: Username and Password HI All, I'm new to J2EE and Orion. I have set up form-based authorization using DataSourceUserManager. Super! From my initial jsp and/or servlet (not the login page), I would like to access the username of the person who just logged in. How can I do this? I have tried to get attributes from the ServletContext an the session. I have also tried various other things I'd rather not mention . . . So: How can I access the values of j_username and j_password once the user has been logged in? Also, where and what is j_security_check? Thanks, Joanne
RE: clustering
We have seen this behavior in earlier releases, 1.4.5 and 1.4.7, as well and reported it to Karl and Magnus at JavaONE 2001 (v1.5.2 came out right around then). We found that it always worked fine in low load environments and didn't discover this problem until we pushed clustering to our production servers. We've since been using independant non-clustered servers behind a hardware loadbalancer to distribute load, but we have no failover. I was getting ready to give it another shot soon. I guess I expected the Oracle agreement and having larger installations using Orion would have propelled this issue towards the top of the heap. But it looks like its still not quite ready. -Original Message- From: Mike Moulton [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 2:00 PM To: Orion-Interest Subject: RE: clustering My experience is that it is broken in 1.5.2 and 1.5.3 under heavy load; see bug number 687 at http://bugzilla.orionserver.com/bugzilla/. I have been working with Magnus Rydin to get the problem resolved but we haven't gotten vary far, hopefully they will find time to fix this problem soon. -Mike _ : mike moulton : meltmedia : : [EMAIL PROTECTED] : www.meltmedia.com : : 602.340.9440 : 602.432.2568 dig : 602.340.1005 fax : : monOrchid studios : 214 e roosevelt st : phoenix, az 85004 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Creaner Sent: Friday, February 01, 2002 9:36 AM To: Orion-Interest Subject: clustering hi, I was wondering if anyone out there has any solid information on clustering orion server thanks
RE: long sessions
The only real disadvantage is that you are making your memory footprint larger, but that can cause other sorts of situations (OutOfMemoryExceptions, making garbage collection take longer and potentially eat up more CPU, etc). Of course you could always just increase the memory allocated to the JVM. If the user object is the only thing in the session and its relatively light-weight, its probably not a big deal. If the user object is mid sized or larger, or you are storing other things in the session expect to see a noticable memory increase. -Original Message- From: Tim Courtney [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 29, 2002 7:17 PM To: Orion-Interest Subject: long sessions I have kind of a general app server question: I have a servlet that puts a user object into session - HttpSession session = req.getSession(true); session.setAttribute(user, user); - We use this object to check if a visitor has logged into the web site or not My boss has asked me to increase the timeout of this session to 8 hours !!! Apart from the obvious security issue, I was wondering about the load on the server. Is holding too many session at once a common cause of server failure ? I can't really give details about the number of users, but assume there will be a few hundred at any one time. The hardware specs of the app server are about mid range. thanks
RE: hot redeployment - how to preserve session state?
I'm not currently doing hot-deploy, but I've always wonder how it could posibly work given that a serialized class might have the underlying base class changed during hot-deploy (e.g. the classic 'run instance' is different than a 'new instance' problem that java throws a ClassCastException from). Its also theoretically problematic (I'm not sure if instanceof or reflection will work properly). Since this is a very low-level issue (e.g. Java simply doesn't have the facilities to really handle this), how does hot-deply work? The only reliable strategy would appear to be to preserver primatives (since they don't change), maybe preserve 'well-defined' objects (java.util.* is unlikely to change), and discard all the rest. Any thoughts? AT -Original Message- From: Peter Beck [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 29, 2002 7:41 AM To: Orion-Interest Subject: hot redeployment - how to preserve session state? After a forced redeployment of an application on Orion 1.5.3 by touching application.xml my session state seemst to be completely lost. I have set development=true in my global-web-application.xml, and the switch is present in the orion-web.xml in the application- deployment directory. The variables I try to serialize implement the Serializable interface. Some of them are simple JavaBeans, others just Strings. For testing I use a JSP which prints the variables in the session. Before the redeployment everything is there. and when a user is logged in, request.getRemoteUser() gives me the correct user name. After the redeployment session.toString() still gives me the same ID as before, but all variables in the session are gone. Even request.getRemoteUser() == null. What am I missing? Peter
RE: Generating descriptors
The Orion tools are flakey and have some unresolved bugs. But of course you're not using Orion because of its great IDE. :) My experience with the Orion tools is that they seem like more of a proof of concept than something practical to use. I typically write alot of the descriptors by hand, which is still one of the best ways I know of. But I've started using an opensource tool called EJBCreator, which seems to work well, do a lot of the monkey-work for you, and is reasonably reliable. In fact it does just about everything I want except its too verbose in alot of its in code comments (but thats just me and it *IS* opensource so I could change that if I really wanted to). CHeck it out at http://opensource.itplus.dk/ -Original Message- From: Michal Palicka [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 24, 2002 5:28 AM To: Orion-Interest Subject: Generating descriptors Hello, what tools do you use to generate various descriptors (beans, applications, etc.)? Do you prefer writing descriptors manualy? Could you give me any hints? I tried the EJB Assembler tool, which is a part of Orion, but I could not generate the EJB descriptor. I am able to generate the EJB jar file, but without the descriptor. When I try to save the descriptor I always get the following error: Couldn't save to that location: META-INF. Could you tell me, what are the correct steps to generate an EJB + the corresponding descriptor? Thanks in advance Michal Palicka, Cleverlance
RE: connection pipe problems
You can't really tell everyone on the internet to set back their browsers to HTTP 1.0. Is there someotherway to control this? FYI - I've seen the same problem but only from some browsers (specifically Windows IE 6), but not other browsers (Opera on Redhat, Netscape 4 on Windows). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 16, 2002 4:25 PM To: Orion-Interest Subject: RE: connection pipe problems HI It may be from your browser using HTTP1.1. When Orion sees HTTP 1.1 it may send stuff back: Transfer-Encoding: chunked If you switch your browser to use HTTP1.0 only, the problem may dissapear, worth a try. -Original Message- From: Robert S. Sfeir [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 16, 2002 2:24 PM To: Orion-Interest Subject: connection pipe problems -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello to all, I seem to have run into a bit of a riddle here with the Orion server (version 1.5.3 currently but 1.5.2 did this too, both running on Solaris though the problem is also exhibited on Linux) It seems that the http connection pipe doesn't complete and close whenever a page is loaded (Meaning the browser thinks there is more info coming its way and just sits there and spins), further it sometimes seems like everything loads except some of the images on the page, yet when someone hits reload on a page they get everything, then the connection to the browser is closed and all is fine and dandy. This happens with files coming from a servlet mostly, we don't have any flat html or jsp pages which we use, so I don't know if they would behave the same way. Has anyone else seen this, what is the possible solution to this issue? is there some kind of setting in Orion which I missed which will help this cause? Many thanks R -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.8 for non-commercial use http://www.pgp.com iQA/AwUBPEXvcFIHAfF2BMfREQIc1QCg7jtkS9LtTwprKJRdSh+ETBFYM30AoIli f1+9UxEvADYbDI0pOX85Qi43 =PsKx -END PGP SIGNATURE- ** THIS MESSAGE IS INTENDED ONLY FOR THE ADDRESSEE, IT MAY CONTAIN PRIVILEGED OR CONFIDENTIAL INFORMATION. ANY UNAUTHORISED DISCLOSURE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE NOTIFY US IMMEDIATELY SO THAT WE MAY CORRECT OUR INTERNAL RECORDS. PLEASE THEN DELETE THE ORIGINAL EMAIL. THANK YOU **
App server debugging -- HELP
I've got a very large web application (about 300 objects and about 1000 pages) which uses mostly straight JSP. This gets a reasonable number of hits with approximately 200 concurrant sessions operating. Recently, we introduced something thats causing something resembling a thread deadlock. Some unknown event occurs, then things start grinding to halt as threads get backed up. When this happens they only way to get out is to hard kill the server (e.g. - orions shutdown doesn't work, and kill -TERM doesn't work). This only really occurs under load, and we cannot reproduce it in a development environment (even with loading tools). We've crawled through every line of code carefully and have found some obscure race-conditions we hadn't considered (race conditions we never actually had occur). But so far nothing that has would fix our real problem, so I'm fairly convinced that I'm not going to find it easily by looking at java code. Now I've tried jdb and of course I can only see suspended threads (which is not too useful) and I've tried jprobe but that only shows the parent threads state. I even tried strace/truss but thats too lowlevel to make out whats happening. I'm starting to use 'kill -3' but that again only shows the parent thread. Does anyone have an suggestions on doing runtime debug on the thread level? I'd really just like to see whats actually happening in the locked threads. Anyone?
RE: RE Orion on Macintosh OSX setup
Hmm - I don't know much about aliases, I'm a UNIX head that just happened to have helped a friend get Orion running under OSX. :) Glad to know that works for ya! -Original Message- From: Pauline McNamara To: Orion-Interest Sent: 12/30/01 1:27 PM Subject: Re: RE Orion on Macintosh OSX setup Thanks Aaron, just got a bunch of practice with symlinks along the way to getting Orion set up ;) Not quite sure that what I did is actually the key, nor if I did it exactly right, but here's the story in case others might benefit from it: Located in the orion directory, I used the ln -s command like this: ln -s System/Library/Frameworks/JavaVMFramework/Versions/CurrentJDK/Classes/cl asses.jar tools.jar This created not a file, but an alias folder named tools.jar in the orion directory. In the OS's Finder program, double clicking on the folder gave an error message stating that it couldn't be opened because the original item could not be found. I put this folder in the trash. Afterwards Orion worked, but it may have been for other reasons. Could it be that the symlink still exists, even if there isn't an alias for it? Thanks for the tips, it's encouraging just to know that these kinds of things are being done successfully with OSX (didn't have to go out and buy a PC, yet). Regards, Pauline --- Aaron Tavistock wrote: I've gotten Orion setup on OSX and there are definately some nuances to it because of Apple's wacky implementation of things. On the tools.jar - you'll need to symlink the apple version of the tools.jar into the Orion directory. THough I can't remeber what apple called the file, I know this worked fine when I found the file (it might be classes.zip?). On the permission denied - its definately because you are trying to access a priveledged port (e.g. port 80). The change you made to the configuration file will work if you make sure to follow standard XML syntax and put the value in quotes (port=8080). -Original Message- From: Pauline McNamara [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 27, 2001 5:57 AM To: Orion-Interest Subject: Orion on Macintosh OSX setup Patience with a newbie please... I'm setting up Orion on a Mac with OSX 10.1 (so J2SE 1.3.1) and have come upon 2 stumbling blocks. Any advice is much appreciated. First: According to the installation instructions, the JDK's tools.jar file should be copied into the Orion directory. On the OSX the JDK is structured differently and the tools in the form of a .jar file are not to be found. Any hints? Second: I went ahead and started orion with and get the following error message: Error starting HTTP-Server: Permission denied Orion/1.5.2 initialized I understand that I can't access port 80 when not logged in at the root, and that I probably have to alter the web.xml file to change the port (to a port over 1024). I tried adding this: but got the same message. Could someone please point me in the right direction? Thanks in advance, Pauline __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com
RE: CMP Entity Bean Craziness
Mike - If I intentionally bundle an orion-ejb-jar.xml file in with my EJBs, thats effectively saying that these are the parameters I care about and should not be derived by Orion. I would presume that since these are being bundled with my EJB package they are values that are somewhat global to begin with otherwise they probably shouldn't be bundled in the package. So I would maintain that changes should be incorporated immediately without having to manually remove the old file. I can certainly see where there might be places where a deployment specific change has been hand edited in and how that would get nuked. But it still seems like it strips away the ability to drop a jar and run. Maybe the solution is what Morten suggested, a configuration file for specific deployment that is included in each overwrite. It also seems like 'always overwriting' would make rapid development easier (without using XDoclet). Magnus and Karl - theres a fat feature request here. :P Aaron -Original Message- From: Mike Cannon-Brookes To: Orion-Interest Sent: 12/30/01 4:35 AM Subject: RE: CMP Entity Bean Craziness On Sun, 2001-12-30 at 07:50, Ed Brown wrote: Quoting Aaron Tavistock [EMAIL PROTECTED]: Mike - Since this is a generated file in a deployment directory shouldn't it always be overwritten if there is a change in one of the package deployment descriptors? The only reason it would be a pain in the ass is if you changed the generated file to suit your needs and did not change the one you bundle with your package. Which is my thought as well. Apologies but that's not really the way I see it. The deployment files are specific to _each_ deployment - for example if you deploy the same EAR on multiple machines (ie in a cluster) you would want different deployment files on each machine. Thus changing the one in the EAR would overwrite all deployment files. As Hani (I think) mentioned, it's easy to get XDoclet to generate your deployment file, and Ant to remove the old one - if you're concerned about development speed. If this is intended behavior, IMHO it is significantly less intuitive. Its kind of like saying a class should only be recompiled if you delete the class before recompiling, where one would expect that changing the source would be enough. Just my two cents. Agreed. In fact, I believe that implementation stinks. Why go through the hassle of writing the orion-ejb-jar.xml file and specifying the fields if the server re-writes the file as it sees fit? There are some misconceptions here - the server will not 'rewrite deployment files as it sees fit', in fact it takes any settings in orion-ejb-jar.xml and builds ontop of those. The easiest way to build an orion-ejb-jar.xml file for deployment is to: - deploy your EAR without it - copy the created orion-ejb-jar.xml into your source tree - remove any sections you don't want to customise (thereby letting Orion autogenerate them - for example it's usually nicest to specify a default datasource in orion-application.xml and let Orion take care of the datasources in orion-ejb-jar.xml automatically) - customise any you do (ie field names, table names etc) - delete the deployed orion-ejb-jar.xml - redeploy This process only really needs to be done once. At all other times the deployed file should work, except when you modify the orion-ejb-jar.xml then you delete it before redeployment (as above this is usually rare occurrence, if not - use XDoclet to generate and Ant to delete it every build if you want). As for the class analogy it's very different. Classes are compiled once, and 100% autogenerated, deployment files are created and altered by the server continually and are not fully autogenerated (see J2EE spec roles definitions). Also compiled classes are the same in all occurrences (or should be ;)) whereas deployment files are certainly not. Hope this helps clear things up - I do like this healthy debate on the topic though, please tell me if the above sounds unreasonable. Cheers, Mike -- Mike Cannon-Brookes :: [EMAIL PROTECTED] Atlassian :: http://www.atlassian.com Supporting YOUR J2EE World
EJB2.0 spec or implementation?
I've toyed with EJBs for quite a while, all the way back to 1.0. But so far its been too cumbersome and offered little gain in most environments I've been working in (e.g. the overhead of remote calls, etc, outweighed the potential benefits). Now with the 2.0 spec its gotten to a good place where I feel like it will really offer some improvements to almost any environment. But I have a major gripe about CMP that I'd like to hear if anyone can 'justify'. So heres the story - database field names are case insensitive, so common parlance for representing a space is an underscore (e.g. 'this_field'). In Java, case is available and useful, here common parlance is representing a space by a capital letter (e.g. 'thisField'). Unfortunately with the typical CMP EJB implementation of accessor-methods are a bastardization of both of these schools (e.g. 'getThis_field'), which is not only ugly but also makes it much more difficult to move from typical javabean-style Java into EJB. Since the 2.0 spec already requires abstract classes where the engine builds the concrete class, it seems like it would be a no brainer to map 'getThisField()' to the 'this_field' database field and preserve conventions on both sides of the fence. I'm sure people can come up with cases where this appears impractical, or a way to change some generated config file in orion after the EJBs have been deployed, but does anyone have any good ideas on why this is not the default behavior?
RE: [orion-interest]EJB2.0 spec or implementation?
I'm fairly sure that the SQL-92 spec calls for case insensitive column names (but don't quote me on that cause I'm not 100% sure). Also, since I'm in a UNIX shop switching to Microsoft is not really an option (even *if* I wanted to) - but thats not really the point. More importantly, I'm aware I can change the post-deployment descriptor created by Orion but thats a major pain-in-da-behind if I'm doing development and want to redeploy several times. When I've tried putting an partial orion-ejb-jar.xml into the package, its never worked right, implying that I need to copy a previously deployed version to modify - again extremely cumbersome. I was hoping that there was some way to do this without slicing up the post-deployment orion generated files. -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED]] Sent: Friday, December 28, 2001 10:26 AM To: Orion-Interest [EMAIL PROTECTED]; Aaron Tavistock Subject: Re: [orion-interest]EJB2.0 spec or implementation? On 28/12/01 12:56 pm, Aaron Tavistock [EMAIL PROTECTED] wrote: So heres the story - database field names are case insensitive, so common parlance for representing a space is an underscore (e.g. 'this_field'). Nope. MS SQLServer is not case insensitive. You could always tweak orion-ejb-jar.xml to map it to whatever column names your heart desires
RE: CMP Entity Bean Craziness
Mike - Since this is a generated file in a deployment directory shouldn't it always be overwritten if there is a change in one of the package deployment descriptors? The only reason it would be a pain in the ass is if you changed the generated file to suit your needs and did not change the one you bundle with your package. If this is intended behavior, IMHO it is significantly less intuitive. Its kind of like saying a class should only be recompiled if you delete the class before recompiling, where one would expect that changing the source would be enough. Just my two cents. Aaron Tavistock -Original Message- From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED]] Sent: Friday, December 21, 2001 2:13 AM To: Orion-Interest Subject: Re: CMP Entity Bean Craziness You're not special at all (well you may be - but that's a different story ;)) - what you describe is exactly the intended behaviour of the server. You're editing the deployment files in your EAR which are only used _IF AND ONLY IF_ there is no existing deployment file. Otherwise the existing deployment file is used, and the one in the EAR ignored. This behaviour is as it should be because otherwise you'd end up overwriting your deployment settings all the time which would be a royal pain in the ass. HOWEVER to do what you want, simply delete the deployment directory and your edited files will be copied and used. You will see a message on the console telling you that the deployment file has been copied. Hope this helps clear things up. Cheers, Mike -- Mike Cannon-Brookes :: [EMAIL PROTECTED] Atlassian :: http://www.atlassian.com Supporting YOUR J2EE World On Fri, 2001-12-21 at 15:01, Ed Brown wrote: Okay, here is the situation. Database: Oracle on Solaris Orion server: 1.5.2 on Windows 2000 Operating System: Windows 2000 I have a database table named FOO. I want to create different entity beans to provide different views of the table named FOO. FOO is a table with many columns. (Sure, I could create one entity bean, and then create wrapper classes that provides the views of table FOO that I want, but I didn't want to do that). Many of those column names contain underscores. When I created the first CMP entity bean, I mapped all column names and used the table name as the entity bean name. I wrote the appropriate ejb-jar.xml and orion-ejb-jar.xml and packaged them. In the orion-ejb-jar.xml file, I used the persistence-name to map the Java attribute to the proper table column. For all attributes that mapped to a column name with an underscore, I removed the underscore and uppercased the next character. (A column named long_col_name would map to the attribute longColName). So I deployed the entity bean and there were deployment errors. Orion complained about illegal column names. Much later after going around in circles, I looked at the ejb-jar.xml file that Orion generated and I noticed that the values for the persistence-name mapped exactly to the column names of the database table. It *IGNORED* what I had placed there. I had to edit the deployed xml file to get the mapping correct and properly deployed. Now, that's not very nice. Next, I created another CMP entity bean to give a different view of table FOO. I used the entity name FooTimeView and used the table attribute of entity-deployment in the orion-ejb-jar.xml to map the entity to the FOO table. I deployed it and, again, I got errors. I had to edit the deployed xml file to get the correct mappings. I deployed again and it still failed. Only this time, it tried to create a table named FOOTIMEVIEW. (Actually, it *DID* create the table). That's not what I expected to happen. So, I looked at the deployed xml file again and I noticed that the table name had been changed from what I specified. This time, I also looked at the query that was generated and noticed that the column names with underscores had the underscores removed. Now, that's not very nice. I edited that and restarted the server. Now all is well. Okay, now I *KNOW* what I described should not happen. I want to know why it did happen. Has this happened to anyone else, or am I special? Ed Brown _ This mail sent via toadmail.com, web e-mail @ ToadNet - want to go fast? http://www.toadmail.com -- Cheers, Mike -- Mike Cannon-Brookes :: [EMAIL PROTECTED] Atlassian :: http://www.atlassian.com Supporting YOUR J2EE World
RE: [orion-interest]EJB2.0 spec or implementation?
You think fugly? It already does fugly reflection and decapitalization for the first letter just to match the accessor to a column name. Why is it any more fugly to process underscores? I do suppose that databases that do identify case within the column name could make things a little wierd (e.g. would getThisField() translate to 'this_field' or 'thisField'?). But still I believe the SQL-92 spec is for case insensitive column names. From a perfromance standpoint, its practically no difference (all happens when the concrete class is created at deployment time). I'll try the orion-ejb-jar.xml, but I'm guessing I'm going to need to provide a complete orion-ejb-jar.xml file, not just the hierarchy required for the cmp-field-mapping fields. Theres a lot of junk in there I don't want to follow and if I'm doing quick development I will need to far more than makes sense. Which definately makes our existing persistence, caching, and coding paradigm easier to use than CMP EJB, once again seems to indicate that EJB might still not be needed for most serverside applications (still more hype and 'neat' technology than is practical in the majority of situations, IMHO). -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED]] Sent: Friday, December 28, 2001 12:32 PM To: Aaron Tavistock; Orion-Interest [EMAIL PROTECTED] Subject: Re: [orion-interest]EJB2.0 spec or implementation? On 28/12/01 3:20 pm, Aaron Tavistock [EMAIL PROTECTED] wrote: More importantly, I'm aware I can change the post-deployment descriptor created by Orion but thats a major pain-in-da-behind if I'm doing development and want to redeploy several times. When I've tried putting an partial orion-ejb-jar.xml into the package, its never worked right, implying that I need to copy a previously deployed version to modify - again extremely cumbersome. Well, this IS the correct way to do it. I don't see why you can't just do it once. Having a partial orion-ejb-jar.xml certainly does work. You just need to make sure it has sufficient information in it and is usable. Start off with a complete one and start trimming things, and check it works after every trim! Adding an automatic underscoring thing is too too fugly!
RE: Orion on Macintosh OSX setup
I've gotten Orion setup on OSX and there are definately some nuances to it because of Apple's wacky implementation of things. On the tools.jar - you'll need to symlink the apple version of the tools.jar into the Orion directory. THough I can't remeber what apple called the file, I know this worked fine when I found the file (it might be classes.zip?). On the permission denied - its definately because you are trying to access a priveledged port (e.g. port 80). The change you made to the configuration file will work if you make sure to follow standard XML syntax and put the value in quotes (port=8080). -Original Message- From: Pauline McNamara [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 27, 2001 5:57 AM To: Orion-Interest Subject: Orion on Macintosh OSX setup Patience with a newbie please... I'm setting up Orion on a Mac with OSX 10.1 (so J2SE 1.3.1) and have come upon 2 stumbling blocks. Any advice is much appreciated. First: According to the installation instructions, the JDK's tools.jar file should be copied into the Orion directory. On the OSX the JDK is structured differently and the tools in the form of a .jar file are not to be found. Any hints? Second: I went ahead and started orion with java -jar orion.jar and get the following error message: Error starting HTTP-Server: Permission denied Orion/1.5.2 initialized I understand that I can't access port 80 when not logged in at the root, and that I probably have to alter the web.xml file to change the port (to a port over 1024). I tried adding this: web-site host=localhost port=8080 /web-site but got the same message. Could someone please point me in the right direction? Thanks in advance, Pauline __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com
RE: 1.5.3 is out, but what is so new?
True it has been 4 months without much noticable changes, but as I understand it there are a lot of under the cover changes. More importantly consider that Ironflare is based out of Sweden -- the last four months have been summer (e.g. it will be getting cold again very soon and people will be indoors more) and its common in Europe to take a month holiday during the summer (so you might say its only been three months :) wish I got a month of vacation). I'd expect a lot of really great improvements over the forthcoming months. -Original Message- From: Alex Paransky [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 17, 2001 10:32 AM To: Orion-Interest Subject: RE: 1.5.3 is out, but what is so new? These are really MINOR changes for 4 months of development. I have reported a pretty serious bug (#599) with stack traces, and instructions on how to duplicate, and that's not fixed. For all this time, these changes seem superficial. -AP_ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Russell White Sent: Wednesday, October 17, 2001 6:11 AM To: Orion-Interest Subject: 1.5.3 is out, but what is so new? I am somewhat disapointed in the new release. My EJB 2.0 local interfaces are still not supported. Bummer. Still at least there are some bug fixes. __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
RE: Clustering in Orion
Title: Clustering in Orion As I understand it clustering of session EJBs will soon be available. But thats just the rumor. -Original Message-From: GUNDA, Satish / RSAIFS - IOM [mailto:[EMAIL PROTECTED]]Sent: Friday, August 31, 2001 7:52 AMTo: Orion-InterestSubject: Clustering in Orion Hi all, What is the clustering support provided by Orion? Will my EJBs be replicated across the cluster? The documentation states the following. The HttpSession data (as long as it is Serializable or an EJB reference). Note that if the EJBs are located on a server that fails, the references might become invalid. The ServletContext data. Does it mean EJBs are not replicated acorss a cluster? I don't know how just replication at HTTPSession level can help a production site which requires 99.99 uptime. Any idea when (if) Orion is coming up with this support? Thanks, Satish
RE: Orion don't read my web.xml ...
As per the DTD and the J2EE specs the order in which tags appear in the web.xml file is important. In this particullar case the session-config tag must occur after all servlet declarations. In fact your welcome-file-list also should accour after the servlet tags (and after the session config) as well. -Original Message- From: remy.menetrieux [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 28, 2001 5:56 AM To: Orion-Interest Subject: Orion don't read my web.xml ... Hello, I work with oc4j(orion ) deliver with Oracle 9ias. I have deployed a web-app but I lost my session every minutes. I have a web.xml wich contains this : web-app session-config session-timeout120/session-timeout /session-config welcome-file-list welcome-fileindex.html/welcome-file /welcome-file-list servlet ... /web-app but when i log in my homepage http://localhost/myApp/ i obtain de directory browsing if directory-browsing=allow in my orion-web.xml else i have an error 403 (not permitted) but my servlets are good deployed Have you idea why orion reads servlet and don't read session config?? Thanks in advance
RE: SMP/Linux/Hotspot/Orion problem.
I currently have several SMP machines running Redhat 6.2 or 7.0, running Orion 1.5.2, and using Suns JDK 1.3.0_02 or 1.3.1. We did see some problems on hotspot when we were using 1.3.0 that caused long unexplainable pauses (although ours were about 30 to 60 seconds). We spent a long time watching things like memory footprint (thinking it was maybe garbage collection) and CPU load, but nothing seemed related. With a lot of beating our head into a wall and a week of high pressure, we found that using the interpretted switch (-Xint) fixed these problems but still retained a reasonable performance. It appeared that just-in-time compiling was causing big problems on SMP machines, but more interesting was that moving to a newer JDK (e.g. 1.3.0_02 or 1.3.1) appears to fix the problem without any options to the JVM. -Original Message- From: James Hill [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 21, 2001 1:35 PM To: Orion-Interest Subject: SMP/Linux/Hotspot/Orion problem. Did anyone find a real solution to this problem? I have 2 smp linux boxes that running -classic mode (which is painfully slow). I have considered removing (disabling) one of the CPS to fix it. The symptoms are long pauses of up to 5+ minutes, then everything is ok. Thanks, James
RE: When user hits STOP..any way to trap that and terminate an ongoin g request..
This is a fairly classic web issue and unfortunately there is simply no way to tell if the client has hit the stop button. No matter what happens your going to be stuck running that long query no way out... But on the resubmit issue and using the session to flag a large transaction, I would worry about this alot. For one, what if the user really didn't want that massive query, now they are being penalized until their query is completed. Personally I think the Jakarta Struts folks came up with a fairly decent way of curbing reposters. Basically they add a hidden field to every form with a unique token, that token is recorded when the form is submitted, and thereafter the same form will not be accepted. So the user can't just hit back and then OK, but they can go through the normal route to search again. -Original Message- From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] Sent: Monday, August 13, 2001 1:23 PM To: Orion-Interest Subject: When user hits STOP..any way to trap that and terminate an ongoin g request.. Hi al, I am almost positive the answer is no, but I thought I'd see if anyone has come up with a solution. All too often, we have some users that submit a large query, then hit the STOP button on the browser, then change something and submit again. In the meantime, their original query is still executing on the server-side. Sure..Orion throws an exception when it tries to send the response back and the connection to the browser is gone. But I am wondering if there is any way at all to just kill that particular request. Like..is there some way the app server or web server can send pings every say, 100ms to the browser to make sure its connection is still alive..and if not, just kill the request in some manner. Perhaps by having a special interface that an application can implement, so that a particular method can be called if the server detects that the connection to the browser is dead before the response has gone back. In this way, that method call can get ahold of the session, and perhaps get ahold of a connection being used, close it, etc. Ofcourse, you can use some client-side javascript to disable a button after its been clicked. We have done this, and we also inserted a transition page in particular areas where long queries might occur. In this case, the user sees an animated gif and a message that tells them not to hit stop or back. Ofcourse..you're still going to get those users that do this. My personal opinion is that if they call in, we tell them they are stupid, they should unplug their computer and quit their job because they can't follow instructions. Ofcourse..that wont fly, especially if they are a big money client. Besides, its ethically wrong to screw your clients over. ;) So, one possible idea I have had is to do the following. Each user has a session when they log in. Upon any request, a flag is set in the session of that user, indicating a transaction is starting. If the user hits STOP, then submits while that transaction is still going on, the server will see the flag is set, and send back a response indicating that a transaction is currently happening and they have to wait for it to be done before another submit can occur. There is a plus side to this..it prevents any user to doing more than one thing. The down side is, it is possible using the File - New - Window to open up another window with the same cookie/sessionID and the user could actually go to a different module and do MORE work at the same time. This would allow, for example a large query to be performing in one module and they could go do some work in another module. My method of a flag would prevent this type of multiple-module capability. The solution, ofcourse is to allow one flag per module, thus only one transaction per module could be performed, which is what I intend to implement to at least keep the user experience at a satisfactory level while preventing tons of form submissions from inundating the server. So anyone had this experience and resolve it in some manner? Thanks.
RE: [OT] Getting the machine name from JSP
Use java.net.InetAddress.getLocalHost().getName(); -Original Message- From: Anthony Farrell [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 09, 2001 5:44 AM To: Orion-Interest Subject: [OT] Getting the machine name from JSP Hello All, I would like to retrieve the actual machine name from JSP - Using the request.getServerName() returns the server name - but what i'm looking for is the name of the machine that the server is running on - thanks tony
RE: Why can't orion respond to their customers?
Ironflare consists of less than 5 people. I think its not from them not
wanting to respond or ignoring you, but from being very busy. Think about
how less than 5 people can create an awesome app server like this, what must
their daily schedules look like?
I also think they want to stay small and work on their product instead of
growing a massive company with a giant support center. They charge such a
small amount for such an awsome product probably exactly because they
realize they cannot provide you with very good support.
Of course you could always buy Oracle 9iAS (which is really Orion) and
you'll probably get awesome support, but you'll be paying $4 instead of
$1500 for more or less the same product. You decide.
-Original Message-
From: Troy Heninger [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 08, 2001 9:02 AM
To: Orion-Interest
Subject: RE: Why can't orion respond to their customers?
I second this! I have tried to report a bug both in bugzilla and email
directly to Orion. I have heard absolutely nothing. What's going on? If
you find some way to get any response from the company to bug reports please
let me know too.
Troy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, August 08, 2001 9:23 AM
To: Orion-Interest
Subject: Why can't orion respond to their customers? (was RE: FW: Logging in
to server twice does not work.)
My God, this is frustrating.
I have tried reporting the bug in bugzilla.
I have tried mailing to the list.
I have tried mailing Orion directly.
All I have received from Orion is complete and utter silence. I have not
even gotten a reply saying that the matter is being looked at, or even that
my mail has been received. If I had gotten any respnse at all I would not
have said this publicly, but since you refuse to acknowledge my mails, I
have to ask:
Why do you not take your paying customers seriously? Your support is
extremely bad. We have production systems running on your server, and we
need to know when the bugs will be fixed.
yours
Christian.
Does anyone have any email address the Orion guys will respond to?
-Original Message-
From: Mike Weissman [mailto:[EMAIL PROTECTED]]
Sent: 8. august 2001 15:34
To: Orion-Interest
Subject: Re: FW: Logging in to server twice does not work.
Christian,
We never found a way around this, we run from an applet. we were able
to use the RMIContextfactory and have repeated login attempts. We have
also abandoned rmi lookups due to performance and are going towards a
messaging paradigm for communication.
mike
[EMAIL PROTECTED] wrote:
In think the message was lost again, trying one more time. Sorry for the
repost...
Does anyone know how to login again when the first attempt fails?
Logging in twice seems to be impossible. How to reproduce:
import javax.naming.*;
import java.util.*;
/**
* InitialContext reconnection test.
* @author Christian Tellefsen
*/
// Make sure you:
// a) Have a META-INF/application-client.xml in the right place.
// b) Replace the server name below.
public class ContextTest {
static void connect() {
Hashtable env = new Hashtable();
env.put(
java.naming.factory.initial,
com.evermind.server.ApplicationClientInitialContextFactory);
env.put(
java.naming.provider.url,
ormi://localhost/appit); // replace with your server
try{
// This will show the login box the first time,
// but not the second time.
new InitialContext(env);
}
catch(Exception e) {e.printStackTrace();}
}
public static void main(String[] s) {
connect();
System.out.println(Once more unto the breach...);
connect();
}
}
Obviously I would like the login box to appear again. I cannot find any
way to tell the server to replace the old principal and credential. I
feel
weird telling my users that sorry, if you enter the wrong password you
have to restart the program. Obviously this is a showstopper.
I see that other people have asked the same question, but no answers. I
am
also reporting this as a bug (#577) in bugzilla.
Any help or workarounds would be greatly appreciated.
yours
Christian Tellefsen
--
##
Michael Weissman e-mail: [EMAIL PROTECTED]
Clarent Corporation 303-734-5003 Fax 303-734-4244
1221 W. Mineral Ave. Littleton, Co 80120
In the land of the dark, the ship of the sun is
drawn by the grateful dead -- Egyptian Book of the Dead
##
RE: APJ13 experiences?
Well, the release notes show Orion supporting AJP13 since version 1.48 and as I mentioned one of the Orion developers recommended this as a solution for some issue I was seeing - but I have yet to see it actually work. :) As for being Tomcat specific, I figure its just a protocol so I guess anyone could be able to support it as long as they matched the spec, right? -Original Message- From: James Fairbairn [mailto:[EMAIL PROTECTED]] Sent: Friday, July 27, 2001 4:56 AM To: Orion-Interest Subject: Re: APJ13 experiences? I wasn't even aware that Orion used the AJP12/13 protocols. AFAIK the AJP protocols are Tomcat connection protocols only. Somebody provide some illumination. James - Original Message - From: Aaron Tavistock [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Friday, July 20, 2001 8:12 PM Subject: APJ13 experiences? I'm currently using Apache as a frontend to Orion, where Apache and Orion are on different machines and different places in the network. Right now it works quite well but there are some little minor annoyances (like seeing the Proxy servers IP in Orions logs instead of the real client, et al). At JavaOne Karl told me that APJ13 would solve most of these problems, so I'm trying to get mod_jk working with Apache. While setting up mod_jk I notice that its pretty tomcat specific, but it seems like mod_jk or jserv are the only options. It would be nice to hear if there are any good or bad experiences out there with using APJ13 on Orion.
RE: Orion's JSP generated code
Regardless of whether you like it or not, I hate to say it but it is you that is including these not Orion. You can easily remove them, you just don't like the way to do it. In fact I'm fairly sure its part of the JavaServer Pages spec that everything is included on the resulting page. I would also disagree that its an oversight, personally I would rather have everything I put there rather than some filter to clean up after me. As a case in point I have a jsp page that generates a PDF file on the fly, if the line breaks were not included verbatim it would take alot of figuring out where the line breaks truly belong and artifically inserting them. If these \r\n's are that significant of a problem for you and you really find that you can't clean up these youself, you can always do things the hard way and avoid opening and closing the jsp delimiters, for example do includes like this: % pageContext.include(urlA); pageContext.include(urlB); % But then you're losing the clarity of your for a few bytes of saved space. -Original Message-From: Sergei Batiuk [mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 24, 2001 6:33 AMTo: Orion-InterestSubject: Re: Orion's JSP generated code % foo(); %% bar(); % This looks like a nice idea!However: IfI have several jsp's to include into one page, each will add the \r\n. My opinion is that this is not a philsophical difference, but something that orion server developers or JSP specification developers missed. I can always add as many \r\n's to my page as I wish. But there is no way to remove unnecessary ones. Best regards, Sergei. - Original Message - From: Aaron Tavistock To: Orion-Interest Sent: Monday, July 23, 2001 10:00 PM Subject: RE: Orion's JSP generated code Umm, the \r\n is probably something you are including inadvertently. I'm going to speculate that you have a construct that looks like this... % foo(); % % bar(); % between the first close and next open, you have a \r\n. While it looks uglier on the JSP page it should clear your line break if you did this... % foo(); %% bar(); % Now why JSP doesn't clean this up for you an PHP does probably boils down to a philosophical difference. PHP is cleaning it up for you, where JSP is giving you exactly what you asked for. I'd guess this is because PHP is pretty much pure web, where JSP is intended to be portable into other formats that may think whitespace is important. -Original Message-From: Sergei Batiuk [mailto:[EMAIL PROTECTED]]Sent: Friday, July 20, 2001 3:25 AMTo: Orion-InterestSubject: Orion's JSP generated code Hi forum, I have noticed that when I use scriplets or tags in my JSPs, orion puts "\r\n" into the outputstream code for each tag. This results in many blank lines in the generated HTML code. In comparison,PHPscripletsdo not produce these blank lines. Does anyone know how to "beautify" the generated code? Thanks in advance, Sergei.
RE: Orion's JSP generated code
Umm, the \r\n is probably something you are including inadvertently. I'm going to speculate that you have a construct that looks like this... % foo(); % % bar(); % between the first close and next open, you have a \r\n. While it looks uglier on the JSP page it should clear your line break if you did this... % foo(); %% bar(); % Now why JSP doesn't clean this up for you an PHP does probably boils down to a philosophical difference. PHP is cleaning it up for you, where JSP is giving you exactly what you asked for. I'd guess this is because PHP is pretty much pure web, where JSP is intended to be portable into other formats that may think whitespace is important. -Original Message-From: Sergei Batiuk [mailto:[EMAIL PROTECTED]]Sent: Friday, July 20, 2001 3:25 AMTo: Orion-InterestSubject: Orion's JSP generated code Hi forum, I have noticed that when I use scriplets or tags in my JSPs, orion puts "\r\n" into the outputstream code for each tag. This results in many blank lines in the generated HTML code. In comparison,PHPscripletsdo not produce these blank lines. Does anyone know how to "beautify" the generated code? Thanks in advance, Sergei.
APJ13 experiences?
I'm currently using Apache as a frontend to Orion, where Apache and Orion are on different machines and different places in the network. Right now it works quite well but there are some little minor annoyances (like seeing the Proxy servers IP in Orions logs instead of the real client, et al). At JavaOne Karl told me that APJ13 would solve most of these problems, so I'm trying to get mod_jk working with Apache. While setting up mod_jk I notice that its pretty tomcat specific, but it seems like mod_jk or jserv are the only options. It would be nice to hear if there are any good or bad experiences out there with using APJ13 on Orion.
RE: EJBUserManager not working?
Has anyone even used the EJBUserManager successfully? -Original Message- From: Aaron Tavistock [mailto:[EMAIL PROTECTED]] Sent: Friday, July 13, 2001 6:16 PM To: Orion-Interest Subject: EJBUserManager not working? I just setup the EJBUserManager, which seems like it would be a nice alternative to the DataSourceUserManager for a newproject I'm working on. Setting it up wasn't a problem -- Orion made the table, I've already got the security constrints working, thats all fine. But I do have a strange problem, that doesn't make sense and is a huge stumbling block. When I call the RoleManager.createPrinciple() do some operations and then call RoleManager.store() an entity is created, but oddly the entity only ever has a name (never a password or groups). I thought this was annoying, but I figured that I could get the entity and modify it directly using EJBUser.setPassword() and EJBUser.addToGroup(). Since EJBUser is an actual entity CMP EJB it should persist automatically. But these don't stick either... To add even more wierness into the mix, while I still have the original principle reference I can authenticate as the user using RoleManager.login(). But I can never reauthenticate as the user since the password is NULL in the database, this seems to imply that the data is valid in memory but is not being persisted. A final important note is that I have no problems with EJBs in general, have many CMP EJBs that work fine in the exact same deployment, so I'm pretty sure its not the environment. ANyone have any insight into the EJBUserManager?
EJBUserManager not working?
I just setup the EJBUserManager, which seems like it would be a nice alternative to the DataSourceUserManager for a newproject I'm working on. Setting it up wasn't a problem -- Orion made the table, I've already got the security constrints working, thats all fine. But I do have a strange problem, that doesn't make sense and is a huge stumbling block. When I call the RoleManager.createPrinciple() do some operations and then call RoleManager.store() an entity is created, but oddly the entity only ever has a name (never a password or groups). I thought this was annoying, but I figured that I could get the entity and modify it directly using EJBUser.setPassword() and EJBUser.addToGroup(). Since EJBUser is an actual entity CMP EJB it should persist automatically. But these don't stick either... To add even more wierness into the mix, while I still have the original principle reference I can authenticate as the user using RoleManager.login(). But I can never reauthenticate as the user since the password is NULL in the database, this seems to imply that the data is valid in memory but is not being persisted. A final important note is that I have no problems with EJBs in general, have many CMP EJBs that work fine in the exact same deployment, so I'm pretty sure its not the environment. ANyone have any insight into the EJBUserManager?
RE: Can't get taglibs to work in orion
Might be something to do with the fact that the web.xml dtd requires a certain ordering. I've run into this before and it was extremely difficult to figure out exactly what happened. After I discovered the problem I then could not fathom Sun wrote the dtd to require a particullaar order. Either way, try putting the taglib lines before your security constraint. -Original Message-From: Tim Pouyer [mailto:[EMAIL PROTECTED]]Sent: Tuesday, June 12, 2001 3:30 PMTo: Orion-InterestSubject: Can't get taglibs to work in orion I downloaded the custom tags provided on orion's site and installed them on my orion 1.5.2 server. But when I try to go to the jsp page that uses them I get a 'page cannot be displayed error'. I can run jsp's that do not utilize orion's taglibs so I think it might have something to do with my deployment descriptors. In my web.xml file in web-inf directory i have the following tags: ?xml version="1.0"? !DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd" web-app display-nameHolder Project/display-name login-config auth-methodBASIC/auth-method /login-config taglib taglib-uriutiltags/taglib-uri taglib-location/WEB-INF/lib/utiltags.jar/taglib-location /taglib /web-app and I put %@ taglib uri="utiltags" prefix="util" % at the top of my jsp.With all subsequent code referenced like this util:sometag if someone could please explain what I am doing wrong I would greatly appreciate it.
RE: image/servlet caching issue
First off, I have a similar servlet sending images running in Orion right now and it does not display this behavior (Although mine uses path info instead of request parameters so the URL still looks like an image). So I'm pretty sure its not Orion. Narrowing to a solution depends alot on whether the problem exists on the client or on the server. You should start out by forcing response headers to instruct the browser to not cache the results. This really can't do much harm so, its good to do even if the problem is on the server. Use these (assuming 'res' is an instance of HttpServletResponse) res.setHeader(Cache-Control, no-cache); res.setHeader(pragma, no-cache); res.setHeader(expires, System.currentTimeMillis()); If this doesn't fix the problem, I'd start looking at the servlet itself. I'd make absolutely sure that you have the appropriate things in the request scope verses the class scope. Its easy to miss something in the wrong scope and accidentally create this kind of behavior. -Original Message- From: Todd McGrath [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 11:25 AM To: Orion-Interest Subject: image/servlet caching issue I'm having what I believe to be a image/servlet issue cache issue with Orion 1.4.5: Situation: I'm creating dynamically generated graphs based on an authenticated user. The images are created by passing values to a graph generating servlet. HTML looks like this: img border=0 src=/Incentive1Graph?mgmt01=37500min=10009target=25024gold=37535 where Incentive1Graph is a servlet that produces the image based on mgmt01, min, target and gold values. The very first time the servlet is run it produces the correct image. However, on any subsequent calls with a different user, the original image is returned. I think the image/servlet is being cached by Orion and thus, always returns the first image that was created. If I restart Orion, log in with a different user, the image produced is correct. Here's what I've done to debug so far: 1) Verfied the values for mgmt01, min, etc. are changing with different users 2) Deleted all files in the persistence directory 3) Deleted my browser cache 4) Tried with both Netscape and IE 5) Verified that I'm not accessing the test site through a proxy 6) Searched the Orion mailing list for similar issues Any other ideas??? My questions are: 1) how do disable image/servlet caching in Orion config? 2) is there something I can write in the Incentive1Graph servlet that will prevent it from being cached? Thanks in advance, Todd
RE: Orion is case-sensitive?
Of course its case sensitive... -- Java is case sensitive. -- Most file systems (except some Microsoft filesystems) are case sensitive. -- URLs are typically case sensitive. -- I haven't checked but I wouldn't be surprised if the J2EE spec on Webcontainers requires case-sensitivity. To me its a good thing to be case sensitive, so I've never looked into disabling it. -Original Message- From: Arun Jayaprakash [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 23, 2001 2:36 AM To: Orion-Interest Subject: Orion is case-sensitive? Hello everybody, Is Orion case-sensitive where web-application names are concerned? I made two entries - BenchMark and lanmark. I found that if I changed the case for the above, I would get a Page cannot be displayed error. Is there any way to turn off this case-sensitiveness? Regards, Arun Jayaprakash. __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
RE: Alternate XML parser
Orion sets its own classpath within the jar manifest file, which is probably to keep people from accidentally using a different version of something needed by Orion. The only way to change that would be to unjar orion.jar, change the values in META-INF/MANIFEST.MF and then rejar the file. In terms of Orion being a well designed product, you are doing something aberant and cannot get it to work that doesn't detract from the design of the product. In fact, I would strongly question any solution that requires hammering somethinginto the appserver to get it to work. -Original Message-From: Bryant Bunderson [mailto:[EMAIL PROTECTED]]Sent: Wednesday, May 23, 2001 10:07 AMTo: Orion-InterestSubject: Alternate XML parser Does anyone know the correct wayto get Orion to use the Xerces parser? We are using an embedded entity reference in our XML files which crimson complains about. We are trying to use Xerces to parse the files. We have tried putting the xerces.jar file in our application lib directory and telling jdom to use it specifically and the application can't find the xercesclasses.We have tried putting xerces.jar in every classpath we can think of but the app still can't find it. We then tried to get Orion to use Xerces as it's default parser. Simply settingthe system properties for Jaxp doesn't work. Orion will fail to load because it can't find the xerces parser. We ended up setting the Jaxp properties AND removing the crimson parser and renaming the xerces.jar fileto crimson.jar. THIS IS SUCH A HACK! I generally think that Orion is a well designed product and that there must be a better way to do this. Thanks, Bryant
RE: Orion-based JSP bug -- The Case of the Exhibiting %00
Heh... I think that Joseph was joking. A particullar clue off is the fact that he's one of the orionsupport people. :) But of course sarcasm does carry well in email... -Original Message- From: Jeff Hubbach [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 01, 2001 3:26 PM To: Orion-Interest Subject: Re: Orion-based JSP bug -- The Case of the Exhibiting %00 Joseph, This IS fixed, and as was already posted to the list, just use a more recent version of Orion. I run 1.4.5 and can't duplicate this problem. Jeff. Joseph B. Ottinger wrote: I've replicated this bug in Orion 0.4.8b. I want this fixed NOW, as this is a critical problem! On Tue, May 01, 2001 at 12:53:56PM -0500, John Pletka wrote: I can reproduct this bug on Orion 1.4.0 under win2k, Sun JDK 1.3.0 -Original Message- From: Rex McFarlin [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 10:28 AM To: Orion-Interest Subject: Orion-based JSP bug -- The Case of the Exhibiting %00 Can anyone help us solve a perplexing JSP bug? We have been unsuccessful. If a %00 is attached to the end of a URL (as in, http://localhost:8008/dcr/index.jsp%00 http://localhost:8008/dcr/index.jsp%00 ) to a JSP page that is being served by Orion server, the user receives, not the rendered HTML page that he or she might be expecting, but a textual output of the raw JSP code for that page. We have found this to be true with the following configuration: Orion 1.4.1 Win2K JDK1.3 Thank you, Rex McFarlin [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- --- Joseph B. Ottinger [EMAIL PROTECTED] http://epesh.com/ IT Consultant -- Jeff Hubbach Internet Developer New Media Designs, Inc. www.nmd.com
RE: Orion-based JSP bug -- The Case of the Exhibiting %00
Doesn't happen for me on Orion 1.4.8, Jdk1.3, Redhat Linux 7.1 -Original Message-From: Rex McFarlin [mailto:[EMAIL PROTECTED]]Sent: Monday, April 30, 2001 8:28 AMTo: Orion-InterestSubject: Orion-based JSP bug -- The Case of the Exhibiting %00 Can anyone help us solve a perplexing JSP bug? We have been unsuccessful. If a "%00" is attached to the end of a URL (as in, http://localhost:8008/dcr/index.jsp%00) to a JSP page that is being served by Orion server, the user receives, not the rendered HTML page that he or she might be expecting, but a textual output of the raw JSP code for that page. We have found this to be true with the following configuration: Orion 1.4.1 Win2K JDK1.3 Thank you, Rex McFarlin [EMAIL PROTECTED]
RE: smp w/jdk
I *HAVE* seen problems with the HotSpot server under SMP with the Linux 6.2 kernel. Under heavily loaded conditions, the JVM would 'pause' for somewhere in the range of 30 to 60 seconds. This would occur more frequently when the load was higher. After struggling with many potentially solutions it was eventually solved by running in interpreted more (-Xint). -Original Message- From: elephantwalker [mailto:[EMAIL PROTECTED]] Sent: Friday, April 20, 2001 9:05 AM To: Orion-Interest Subject: RE: smp w/jdk Erik, This is very ugly. I have two more support calls with Sun on my support contract. I will call them to see what's happening with this bug. How they could release a product that has such a serious bug is beyond me. There seems to be a workaround, though: in Bash, try setting the environmental variable as follows: _JAVA_SR_SIGNUM=16 export _JAVA_SR_SIGNUM Regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Erik Bogghed Sent: Friday, April 20, 2001 8:24 AM To: Orion-Interest Subject: RE: smp w/jdk My experience is that almost all 1.3.* variants (Sun, IBM, Blackdown) breaks under heavy load on Linux (Redhat 7). It's a recognized bug and is said to be fixed (even thought I found out that that was not the case) in 1.3.1 RC1. See http://developer.java.sun.com/developer/bugParade/bugs/4355769.html for some info about this. The only JVM I tested that did not break under heavy load was JRockit. To simulate the load I used several instances of Apache JMeter. I ended up using Blackdowns 1.2.2. Regards, Erik Bogghed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: den 20 april 2001 06:07 To: Orion-Interest Subject: smp w/jdk I just noticed that the readme for Sun's 1.3.0.02 recommends against smp kernels on Linux. Is that an issue? I haven't noticed a problem, had anybody else noticed a problem with Linux and Sun's jvm with the smp kernel? Regards, The elephantwalker
RE: Is EJBMaker Worth it?
Well in general I don't like these kinds of GUI's, but when you are looking at a really big project thats starting from scratch its a nice to be able to look at it from this higher level view. I mean if you have 20+ sizable entities, a handful of dependant objects, and alot of relationships to maintain (especially in EJB2.0 stuff), its a really nice thing to have this guy crank out the stubs and the ejb-jar.xml for the top level. I really wish that the EJBMaker actually worked right. I can't get it to reload the .skeleton file, it also doesn't seem to make the object relationships -- HMPH.. -Original Message- From: Josh P. Motto [mailto:[EMAIL PROTECTED]] Sent: Friday, April 20, 2001 3:48 PM To: Orion-Interest Subject: Re: Is EJBMaker Worth it? I had the same experience as you - so I copy-and-paste everything right into the DD... it's a lot faster for me than trying to figure out what the GUI tool is doing to my files... --- Joe Fair [EMAIL PROTECTED] wrote: I've been working with EJBMaker for several hours now, and I can't help but think that it would have been faster to do it by hand. Does anyone else have an encouraging experience? Thanks, Joe __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
RE: clusting
Orion does cluster, and as clustering goes Orion is the easiest app server I've seen for setting up clusters. As far as how well? I'm not entirely sure. We've been porting a very large app that was not designed with J2EE compliance in mind. So far we've not had a lot of luck getting Orion clustering working flawlessly, but I know there have been some problems from our legacy code (objects that don't serialize properly, static objects, etc). More recently we thought we had it beat and had clustering working in a staging environment, but when we pushed to production we appeared to lose information under heavy load. Still I'm not sure where the problem lies; our code or Orion. :) My biggest gripe about Orion clustering is that certain changes in the cluster send the entire cluster into a wierd state. For example, alot of the config files are loaded by a server coming into the cluster, if ANYTHING has changed in the configs then the cluster seems to get wonky. Basically the clustering gets most of the way to permanent uptime, but it seems to have some kinks to work out. -Original Message- From: Terrance Davis [mailto:[EMAIL PROTECTED]] Sent: Friday, April 20, 2001 6:04 PM To: Orion-Interest Subject: clusting Does anyone know if Orion clusters, and more importantly,how well? - Terrance Davis Software Engineer emWare, Inc. (801) 993-7224 [EMAIL PROTECTED]
RE: productive comment.
'access' to the dev team? You mean that if you think its a bug then you should be able to get on the phone with developers as if they were tech support people? Whats wrong with Bugzilla and a quick development team? -Original Message- From: elephantwalker [mailto:[EMAIL PROTECTED]] Sent: Friday, April 13, 2001 9:35 AM To: Orion-Interest Subject: RE: productive comment. Great point. However, we can help expand on the functionality at orionsupport. But then there's that *paid* support issue. Companies need a place to go so they can *pay* for support when the chips are down, and the alligators are crawling around nipping at their tender parts. The great thing about mysql or borland's open source product is that when the chips are down, you can get *paid* support from thousands of independent consultants. The key bit that will help orion is support that is there for the asking...all you have to do is pay for it. If Joe Ottinger is reading this email, lets add this bit to your site. If you need a consultant to belly up to the bar, and help out, contact the elephantwalker. For the orion team at ironflare, I am willing to pay a *franchising* fee for every support call, email or site visit answered, as long as we get access to the dev team for *bugs*. Regards, the Elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dan North Sent: Friday, April 13, 2001 5:28 AM To: Orion-Interest Subject: RE: productive comment. Importance: High I love the enthusiasm, but I'm concerned about the solution. The orionsupport.com site is run and maintained by a small group of people with exactly the same ideas as those being expressed on this list. Let's not create splinter groups which start with a huge burst of enthusiasm and then fizzle out into another resource dead end. Instead, let's focus that energy on taking orionsupport to the level it needs to get to next. It is built on some great open source technology (www.opensymphony.com) which would make it a straightforward exercise to add threaded discussions, article feedback, printer-friendly page views etc. to the articles there. Joe Ottinger, who currently hosts the site, explains what his ideas are for orionsupport in his excellent (and conveniently short!) "Into the Future" article, which is currently available from google's cache at http://www.google.com/search?q=cache:www.orionsupport.com/articles/vision.ht ml+hl=en). So, some feedback to the site would be a good start (once Joe gets it back on-line :o) Invitations for mirroring would ensure the availability we need, a threaded discussion list (which could interact with this list?), client news (you know if you've bought a licence - so tell the rest of us), much greater breadth and depth of support articles, etc. The sentiment from many of you on this list is that (a) orion is a fantastic product, (b) the orion team don't give their website the time/inclination/priority many of us require, (c) between us we possess a lot of knowledge, (d) we're happy to share that with the community. So, in the absence of formal support partners/infrastructure can I suggest that everyone gives orionsupport.com the, umm, support it deserves? Thanks, Dan/tastapod At 00:47 13/04/2001 -0500, you wrote: RE: How do we take the next step? A sig is, classically a _S_pecial _I_nterest _G_roup, in the computer culture. orionsig.net, orionsig.org and orionsig.com are available. Pick 'em. Don't need a license from anyone to be a 'general purpose special interest group,' as long as you don't purport to be in any 'special' circumstance or make unfounded claims or use words that have obvious legal meaning. I've got a fixed IP, but it's on a slow and restricted connection. I know an ISP that is easy to work with, charges $39/mo, knows how to run services for Java, and is relatively small and responsive, and accesses through a multiple T3 (second-tier backbone access, they're actually a small CLEC). They also are an accredited registrar for all the above TLD's (turn-around is typically about 24 hours to propagate through BIND/DNS and the internic). I'd be willing to donate the first six months worth of host costs, and, after 30 days, pay for the Orion license myself (gotta run the site on Orion, don't we?) with these guys or anyone better. Let's just DO IT. Anyone else want to help? Michael Cannon mailto: [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Thursday, April 12, 2001 10:28 PM To: Orion-Interest Subject: RE: productive comment. List, We have an organic community here, but the list has been our only output. The support from the company is lacking. Orionsupport seems to have been a good outlet for some, but appears to be down for a spell. Many here have used the other commercial packages (I have used weblogic and iplanet), but had to suffer
RE: orion with mysql?
Actually MySQL does support transactions. You just need to use a database file format that supports transactions (e.g. Berkeley DB, et al). The mm.mysql driver also supports transactions, and its easy to setup to work with transactions. The real problem is that the driver doesn't handle transactions the way the specification wants them to. -Original Message- From: Kiss Tibor [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 05, 2001 1:31 AM To: Orion-Interest Subject: RE: orion with mysql? The cause for that could be that MySQL does not support transactions... -Original Message- From: Aaron Tavistock [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 05, 2001 3:28 AM To: Orion-Interest Subject: RE: orion with mysql? You only need a schema if you intend to do CMP EJBs. If you're not using EJB at all then theres no reason you couldn't use MySQL. But, while its not to hard to make a schema that complies with MySQL somewhere in between MySQL and the mm.mysql driver the EJB transaction support falls apart. My inclination is that its the mm.mysql driver itself, and the real problem is just that transaction support is not implimented in a way that complies with the EJB spec (e.g. javax.transaction doesn't occur anywhere in the source). So, while you can use MySQL with Orion you can't do EJB unless you switch over to SAPdb, PostgresSQL, or db. -Original Message- From: Geoff Marshall [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 04, 2001 3:52 PM To: Orion-Interest Subject: Re: orion with mysql? Am using MySQL with Orion without it's own db-schema. No problems, yet. Be sure to get the MM.MySQL driver... -- -Geoff Marshall, Director of Development ... t e r r a s c o p e (415) 951-4944 54 Mint Street, Suite 110 direct (415) 625-0349 San Francisco, CA 94103 fax (415) 625-0306 ... From: Peter Peltonen [EMAIL PROTECTED] Organization: Fivetec Solutions Oy Reply-To: Orion-Interest [EMAIL PROTECTED] Date: Wed, 04 Apr 2001 19:42:44 +0300 To: Orion-Interest [EMAIL PROTECTED] Subject: orion with mysql? Is it possible to use MySQL with Orion? Does it need a db-schema of it's own? We tried to use PostgreSQL but JBuilder4 didn't cope with it very well (JBuilder isn't able to show Postgre's tables). We also tried Hypersonic, but it seems that when both Orion and JBuilder communicate with the db the db gets confused. At least the changes we make in JBuilder don't get updated. Any ideas about a good open-source db that would work with both Orion and JBuilder would be appreciated! Regards, Peter
RE: orion with mysql?
You only need a schema if you intend to do CMP EJBs. If you're not using EJB at all then theres no reason you couldn't use MySQL. But, while its not to hard to make a schema that complies with MySQL somewhere in between MySQL and the mm.mysql driver the EJB transaction support falls apart. My inclination is that its the mm.mysql driver itself, and the real problem is just that transaction support is not implimented in a way that complies with the EJB spec (e.g. javax.transaction doesn't occur anywhere in the source). So, while you can use MySQL with Orion you can't do EJB unless you switch over to SAPdb, PostgresSQL, or db. -Original Message- From: Geoff Marshall [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 04, 2001 3:52 PM To: Orion-Interest Subject: Re: orion with mysql? Am using MySQL with Orion without it's own db-schema. No problems, yet. Be sure to get the MM.MySQL driver... -- -Geoff Marshall, Director of Development ... t e r r a s c o p e (415) 951-4944 54 Mint Street, Suite 110 direct (415) 625-0349 San Francisco, CA 94103 fax (415) 625-0306 ... From: Peter Peltonen [EMAIL PROTECTED] Organization: Fivetec Solutions Oy Reply-To: Orion-Interest [EMAIL PROTECTED] Date: Wed, 04 Apr 2001 19:42:44 +0300 To: Orion-Interest [EMAIL PROTECTED] Subject: orion with mysql? Is it possible to use MySQL with Orion? Does it need a db-schema of it's own? We tried to use PostgreSQL but JBuilder4 didn't cope with it very well (JBuilder isn't able to show Postgre's tables). We also tried Hypersonic, but it seems that when both Orion and JBuilder communicate with the db the db gets confused. At least the changes we make in JBuilder don't get updated. Any ideas about a good open-source db that would work with both Orion and JBuilder would be appreciated! Regards, Peter
RE: Any news from Orion yet??
Wasn't this from *WAY* back in January... I know that Orion 1.4.5 was released around January 22nd, there has been the updates to 1.4.7, *AND* there were rumors about 1.4.8. But, there really hasn't been any news about the goings on of Evermind/IronFlare. How are you guys doing? Whats the state of IronFlare? It would be nice to hear whats going on... -Original Message- From: Karl Avedal [mailto:[EMAIL PROTECTED]] Sent: Monday, January 15, 2001 3:15 PM To: Orion-Interest Subject: Re: Any news from Orion yet?? Hello everyone, Time is well overdue for some information from us about the release schedule and when you can see your bugs fixed. I'm sorry to say that I can't give any information now either about when the next release can be available and when the different bugs can be fixed. We have been pretty silent lately and things have moved much slower than we hoped. We understand very well that many of you are in tough positions with bugs standing in the way of using Orion for your projects. The silence from us has provoked a discussion about whether we are dead like so many other IT companies, and I just wanted to take this opportunity to say that we are not. We will provide more information and I sincerely hope that we will soon get back on track with the release schedule. More information will be sent to this list later this week. Regards, Karl Avedal
RE: Performance problems (More Info).
Well I found the problem with this and I thought I'd let everyone know for the sake of posterity. I found that this problem did not occur on my non-SMP machines, so I played around and found that the HotSpot server behaves wierd with SMP. Switching to pure interpretted mode fixes the problem. It wasn't Orion... phew -Original Message- From: Aaron Tavistock [mailto:[EMAIL PROTECTED]] Sent: Monday, March 26, 2001 12:11 PM To: Orion-Interest Subject: RE: Performance problems (More Info). JVM Settings -- My normal settings are "-server -Xincgc -Xms128m -Xmx384m". I've tried playing around with different JVM options including turning off server, using normal gc, running in interpreted mode, running in classic mode, et al. I even tried running under JDK1.2.2. While these definately effect performance in dramatic ways, none seems to fix this problem. Garbage Collection -- I tried watching the heap by turning on verbosegc, and the pauses do not appear to be timed with a full gc. So thats not it either, definately a good thought though... DB Server -- The DB server itself is performing fine, CPU and memory utilization is low. The database is completely accessable via sqlplus or an alternative app while these pauses occur. Connection Pooling vs Orions DataSource Manager -- Interestingly the problem seems to go away when I turn off Orions datasources, and run with a third party ConnectionPool manager (such as BitMechanic).While this fixes my immediate problem it will prevent me from using Orion as an EJB container, which is not good. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Tavistock Sent: Monday, March 26, 2001 1:09 PM To: Orion-Interest Subject: Performance problems... I've been working on getting Orion running in a production environment for a little while now and just when I thought everything was working fine I go to push to production and something load/volume related is creating massive slowdowns. Basically every 250 database accesses or so there is a long pause (20 to 60 second), where nothing occurs. During this pause the CPU load *drops* to practically nothing and our entire site is frozen. I'm not sure exactly where the problem exists; it could be our code, our configuration, or even a bug in Orion. The environment is Redhat 6.2, JDK1.3, Oracle 8i. Its a pure J2EE app, but we're not using EJB. I initially thought it might be a memory issue, but I've played with the JDK heap size and carefully watched memory utilization and thats also not the issue. I even considered that maybe Evermind/IronFlare might have a throttle (to push you to get a license) so I put one of our production licenses on the QA box. I've since gotten a load tester and can reproduce the problem. Oddly, it only happens on pages which require database access. Even more interesting is that it occurs more frequently on pages which utilize more than one connection. But thats about as far as I can narrow it. I've tried the 8.15 and 8.17 type4 jdbc drivers from oracle and we've tried Oracles ConnectionCacheImpl and Orions XADataSource implimentation, both show the same behavior (though both are using the Oracle Driver). I've also tried Orions jdbc debug and it shows nothing of interest. So far I've put about a week straight into finding it, and I've just about run out of ideas. I'd really be appreciative if anyone has any good suggestions on where to look. ANyone seen behavior like this before?
Performance problems...
I've been working on getting Orion running in a production environment for a little while now and just when I thought everything was working fine I go to push to production and something load/volume related is creating massive slowdowns. Basically every 250 database accesses or so there is a long pause (20 to 60 second), where nothing occurs. During this pause the CPU load *drops* to practically nothing and our entire site is frozen. I'm not sure exactly where the problem exists; it could be our code, our configuration, or even a bug in Orion. The environment is Redhat 6.2, JDK1.3, Oracle 8i. Its a pure J2EE app, but we're not using EJB. I initially thought it might be a memory issue, but I've played with the JDK heap size and carefully watched memory utilization and thats also not the issue. I even considered that maybe Evermind/IronFlare might have a throttle (to push you to get a license) so I put one of our production licenses on the QA box. I've since gotten a load tester and can reproduce the problem. Oddly, it only happens on pages which require database access. Even more interesting is that it occurs more frequently on pages which utilize more than one connection. But thats about as far as I can narrow it. I've tried the 8.15 and 8.17 type4 jdbc drivers from oracle and we've tried Oracles ConnectionCacheImpl and Orions XADataSource implimentation, both show the same behavior (though both are using the Oracle Driver). I've also tried Orions jdbc debug and it shows nothing of interest. So far I've put about a week straight into finding it, and I've just about run out of ideas. I'd really be appreciative if anyone has any good suggestions on where to look. ANyone seen behavior like this before?
RE: Orion and mysql: turning autocommit off?
I have been playing with Orion at home using mySql and have found the same problem, and I looked into it a bunch. While mySql has support for transactions, its still a little immature. Typically the DBD or Gemini libraries need to be obtained and for mySql to compile against so that the tables can be managed with AUTOCOMMIT off. But this is more of an inconvenience than a real showstopper. But more importantly the JDBC driver itself seems to not quite be ready for handling CMP transactions. For example, the class org.gjt.mm.mysql.MysqlDataSource works if you instantiate it and set the properties yourself but it doesn't follow the spec so theres no way for Orion to properly configure it. Even more important greping through the source code for the driver reveals that there is nothing from javax.transaction package anywhere which is required by the EJB 1.1 spec. So the long and short of it is... I've tried using mySql, it won't work yet. So far as both PostgresSQL and Oracle work very well as alternatives. -Original Message- From: Henrik Rn (LMD) [mailto:[EMAIL PROTECTED]] Sent: Monday, March 19, 2001 7:58 AM To: Orion-Interest Subject: Orion and mysql: turning autocommit off? Hi all In the archive there are several mails describing problems with autocommit when using MySQL (3.23.32) and the org.gjt.mm.mysql.Driver (2.0.4) The Cabin example from Monson-Haefel's book, which uses CMP, fails as autocommit is not turned off: [snip from application.log] 19-03-01 15:56 Error in bean Cabin java.sql.SQLException: Can't call commit when autocommit=true at org.gjt.mm.mysql.Connection.commit(Connection.java:520) at com.evermind.sql.an.commit(JAX) at com.evermind.sql.aj.commit(JAX) at com.evermind.server.ejb.DataSourceConnection.commit(JAX) at CabinHome_EntityHomeWrapper2.create(CabinHome_EntityHomeWrapper2.java:429) 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) [end snip] I've tried to use the property: jdbc.nontx.autocommit=false in the orion.properties file, but this does not turn off autocommit. I've also tried turning autocommit off in the MySQL DB (SET AUTOCOMMIT=0) itself, but with no effect. Has any one found out how to turn off autocommit? Regards Henrik -Original Message- From: Tim Endres [mailto:[EMAIL PROTECTED]] Sent: 30. januar 2001 22:16 To: Orion-Interest Subject: Re: orion and mysql? I found it very easy...I use: http://mmmysql.sourceforge.net/ - jdbc driver http://javaexchange.com/ - connection pooling One variable i had was w/javaexchange's DBBroker, set AutoReconnect=true... so far so good...been using awhile Which mysql are you using? Not all versions support transactions. tim.
RE: https second session problems...
This makes sense if you think about it since the secure server and the non-secure server are different web-apps. I got around this problem by adding shared='true' to the web-app tag for both web-apps. Now sessions and context information is the same and no more problem. Now -- I'm not sure that this is the right solution, but it makes sense and it works in this limited case. -Original Message- From: Geoff Marshall [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 9:30 AM To: Orion-Interest Subject: https second session problems... First, a thank-you to Jay Armstrong for his SimplePortTester. Indeed, Apache had port 443 locked up even though I thought I had stopped Apache. Here's the problem of the day: I'm only using JSP and Beans. It seems when I switch between http and https, Orion crreates a 'second session'. I have inserted a System.err.println in EVERY method of my SessionBean which has a single boolean property: loggedOn. My comments (//) // run orion [root@daphne orion]# Orion/1.4.5 initialized // with browser hit my index page in http // index page instantiates two DataAccess objects, and // one SessionBean with session scope DataAccess.DataAccess() - constructing... DataAccess.DataAccess() - constructing... SessionBean.SessionBean() - constructing... SessionBean.getCustId() - SessionBean.isLoggedOn() - false // fill out log-on form on index page and log on (re-submits page as https) DataAccess.DataAccess() - constructing... DataAccess.DataAccess() - constructing... SessionBean.SessionBean() - constructing... // ...there you have it, all three session // beans are being instantiated again!!! // EVEN THOUGH my JSESSIONID does not change // (looked at it in my brower) SessionBean.getCustId() - SessionBean.setCustId() - SessionBean.logOn() - // cust now logged on in https // still there on next https page. SessionBean.isLoggedOn() - true SessionBean.getCustId() - 2 // switch to http page, and cust is gone. SessionBean.isLoggedOn() - false // back to https and cust is there again. SessionBean.isLoggedOn() - true SessionBean.getCustId() - 2 SessionBean.isLoggedOn() - false SessionBean.getCustId() - 2 Is this a bug or a feature? If it's a bug or a feature, is there a work-around? It makes no sense to me why you would want to create a second 'session'. -- -Geoff Marshall, Director of Development ... t e r r a s c o p e (415) 951-4944 54 Mint Street, Suite 110 direct (415) 625-0349 San Francisco, CA 94103 fax (415) 625-0306 ...
RE: Any news from Orion yet??
I'm in a similar situation of trying to get our exec-team to okay going ahead with Orion instead of WebLogic or ATG. Its certainly not easy to convince non-technical people that the underdog product is actually better -- Its becoming harder due to the stagnating site at orionserver.com and the lack of any news about the goings on at evermind/ironflare. I have to say that as my timeline gets tighter I'm losing hope. Any news from Orion? Whats the state of things? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tony Wilson Sent: Sunday, January 14, 2001 3:43 PM To: Orion-Interest Subject: RE: Any news from Orion yet?? Ditto. We are seriously considering Orion for our production system. However, it seems like support for this product has stopped, and is lacking. We might have to go elsewhere. Just a few words about what is going on at Orion will help out a lot. Tony Wilson -Original Message- From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 13, 2001 5:45 PM To: Orion-Interest Subject:Any news from Orion yet?? Hi all, Has anyone heard from the team lately? I know I saw a post about a month or so ago. Its been about 3 or 4 months since anything has changed on their site, if not longer and now its getting me worried. I can understand them trying to organize the company, but did production stop on the app server? I wish there was some news once every couple of weeks or so from them on their site letting us know what is happening. Thanks.
