repost: FYI/PATCH: Log4j bug masks part of Orion's stack traces
Seems the original went missing, again.
-Original Message-
From: Geoff Soutter [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 26 March 2002 3:46 PM
To: 'Orion Interest List'
Cc: [EMAIL PROTECTED]
Subject: FYI/PATCH: Log4j bug masks part of Orion's stack traces
Hi there,
I've been having a weird problem with parts of my stack
traces disappearing.
After a few hours mucking around I've tracked it down to a
bug in log4j that I thought you may all wish to be aware of.
This shows up when you attempt to log an OrionRemoteException
in an application client which has been thrown from a session bean.
If I call System.out.printStackTrace() I get:
at com.evermind.server.ejb.EJBUtils.getUserException(.:207)
at
mySessionBean_StatelessSessionBeanWrapper3.mySessionBeanMet
hod(mySe
ssionBean_StatelessSessionBeanWrapper3.java:153)
at java.lang.reflect.Method.invoke(Native Method)
at com.evermind._dq._fs(.:79)
at com.evermind._bt.run(.:62)
at connection to localhost/127.0.0.1 as admin
at
com.evermind._dn.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(.:1447)
at com.evermind._dn.invokeMethod(.:1370)
at com.evermind._yp.invoke(.:53)
at __Proxy2.mySessionBeanMethod(Unknown Source)
But if I log the same exception through log4j I get only:
at
com.evermind._dn.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(.:1447)
at com.evermind._dn.invokeMethod(.:1370)
at com.evermind._yp.invoke(.:53)
at __Proxy2.mySessionBeanMethod(Unknown Source)
Turns out the reason for this is that there is a bug in the
way log4j deals with stack traces. In log4j, stace track
formatting is handled by a class called ThrowableInformation.
It contains a subclass of PrintWriter called VectorWriter
which only overrides the println() - all the other methods
are effectively disabled. This class is passed into
Throwable.printStackTrace(). Unfortunately, Orion's implementation of
OrionRemoteException.printStackTrace() is calling print() rather than
println() to pass part of the remote part of the stack trace
across. Thus, this part of the stack trace is simply thrown
away. Ouch.
This is a bug which impacts Orion and potentially any other
user of log4j which, in general, wishes to override the way that
printStackTrace() works. It has been reported before on the
log4j developers list
(http://www.mail-archive.com/log4j-dev@jakarta.apache.org/msg0
0926.html)
, but it appears Ceki is too busy to fix it :-).
Note, I'm using log4j 1.x at the moment but I had a quick
check of the CVS repository and it appears the bug is in
latest stuff as well.
I created a simplistic new version of
ThrowableInformation.getThrowableStrRep(), which sucks the
entire stack trace into a buffer and then parses it into
individual lines. It's probably kinda slow compared to the
old version, but at least it fixes the bug. I've included it
if you are interested.
public
String[] getThrowableStrRep() {
if(rep != null) {
return (String[]) rep.clone();
} else {
// NOTE: This is not particularly fast. This probably
needs to be
// re-architected to use JDK1.4's new parsed stack
trace stuff anyway,
// so I consider this to be only a temporary solution.
// First, obtain the _entire_ stack trace as a string
CharArrayWriter caw = new CharArrayWriter();
PrintWriter pw = new PrintWriter(caw);
throwable.printStackTrace(pw);
pw.flush();
String trace = caw.toString();
// Parse it into individual lines.
// This should handle both Win32 and Unix EOL markers
(hopefully).
StringTokenizer tok = new StringTokenizer(trace, \r\n);
Vector v = new Vector();
while (tok.hasMoreTokens()) {
v.add(tok.nextToken());
}
// Convert the result into an array, without using an
1.2 functionality
int len = v.size();
rep = new String[len];
for(int i = 0; i len; i++) {
rep[i] = (String) v.elementAt(i);
}
return rep;
}
}
Cheers
Geoff
--
To unsubscribe, e-mail:
mailto:log4j-dev- [EMAIL PROTECTED]
For
additional commands,
e-mail: mailto:[EMAIL PROTECTED]
RE: OC4J 9.0.3
Presumably this is based on 1.5.4? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of sana Sent: Wednesday, 27 March 2002 2:05 PM To: Orion-Interest Subject: OC4J 9.0.3 Hi, Oracle released OC4J 9.0.3 Developer Preview. http://otn.oracle.com/tech/java/oc4j/content_preview.html It supports most of J2EE 1.3 features. http://otn.oracle.com/tech/java/oc4j/htdocs/oc4j-feature-list.html Regards, sana __ Do You Yahoo!? Yahoo! BB is Broadband by Yahoo! http://bb.yahoo.co.jp/
RE: idea=$395.00USD was: RE: Java IDE?
Go Shane! This is one of the few sensible posts on IDE religion I've ever read! :-) Theres nothing like a little common sense to distinguish the smart developer from the average developer... :-) Anyway, my .2c (apart from what shane said) - I'd recommend any of these tools depending on the task at hand... - IDEA (best all round, brilliant for XP, reasonable price, no GUI or wizard hand-holding) - Together (if you have _lots_ of $ and you _must_ use UML) - JBlunder Enterprise (if you have _lots_ of $ and you really can't deal with J2EE without a Wizard to hold your hand) - CodeGuide (if you don't like NetBeans and you can't afford IDEA) - Netbeans (if you like the price and can handle the clunky interface) - Emacs / vi (if you are a Linux freak and bone-headed :-) - Textpad (if you are a Win32 user and if all else fails :-) Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Shane Whitehead Sent: Monday, 25 March 2002 8:21 AM To: Orion-Interest Subject: RE: idea=$395.00USD was: RE: Java IDE? I believe it comes down to the individual requirements of the developer. You can discuss it till your blue in the face, but if it doesn't fill comfortable, then, like most users, you won't use it. Go with what feels right for you and don't be to swayed with what other people think. I've been lucky that most of the places I've worked at have allowed me to use the editor of my choice and personally I prefer netbeans, but that's more to do with the fact that I was required to use at Uni and at the time their was only a hand full of editors and all of them (except Netbeans) seemed to use a propriety VM - but that's ancient history. Most of the experience is in Swing and I hand code 99% of all my UI, I've yet to meet a UI designer that can cut it. Essentially, try a few, find the one you like and hope it's not to expensive, but at the end of the day, if you can't live without it, you're going to have to pay for it... Good hunting! Shane
RE: OK, here's Real World: was: idea=$395.00USD was: RE: Java IDE?
And don't forget we'll all be using Drag and Drop Visual tools to do coding soon, so we won't even need tools like IDEA. I guess this will make Computer Science degrees irrelevant as well? LOL Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of The Boss Sent: Monday, 25 March 2002 10:27 PM To: Orion-Interest Cc: Jarrod Roberson Subject: OK, here's Real World: was: idea=$395.00USD was: RE: Java IDE? Hi Jarrod, I would like to share some IBM insights with you relevant to some of your comments ... So anyone that chants the FREE mantra keep using Tomcat and Vi and all the other free crap because in the end it will cost you HUNDREDS TIMES more than buying a proper tool and saving money over the long haul. Then again if you are lowballing jobs, and working on crappy little projects all this is moot, why are you using Orion then, why not use JBoss or any of the other FREE EJB containers. I mean you COULD move a mountian with a plastic spoon, hell they are FREE at every fast food joint, but would'nt a sane and reasonable person spend the money on real earth moving equipment and get the job done quickly so they could move on to the next paying job moving the next mountain. Some time ago I was involved in IBM's San Fransisco project, about which you may know. This enterrpise level tool was very large and free for development I understand. Various tool makers came up with ways of enhancing the development process including the integration of the Rational suite of products. OK. That was the story from the West. It turned out that the most productive developers of San Fransisco applications were NOT the people who used fancy, expensive Yankee IDE's or tools, but the teams of hundreds of Indian programmers around Mumbai. The Indian software houses could not afford to pay guys like you, and provide guys like you with tools to make you productive, and save you time, so you could be with your family. No. They could afford to hire hundreds of developers and provide them with cheap development tools, like 'vi' ;), and let them loose on a task. So from this International competitive perspective your comments are way off the mark, the kind of productivity you speak about, (great design guys, large scale projects, etc) are irrelevant in the global domain. It doesn't matter in the end how productive you are, or what tools you use, you will NEVER be able to compete with the developer farms of countries like India, and just wait till China comes on line! I guess the same thing that happened to the Western clothing industry WILL happen to the Western software development business - it will be moved off-shore into countries that have large volumes of super-cheap educated labour, using free development tools. Unfortunately your comments sound like those of an ageing Western prima donna whose tunes are increasingly less popular. Sure tools like Idea were built for prima donna Western software developers ... but with developer farms coming on line ... prima donnas and the tools that support them are becoming less and less of a good business proposition. Perhaps you could start a crappy little project that could make you a lot of money, so you could retire early? ;) Regards goffredo
Simple howto for launching application clients using applicationlauncher.jar
Hi there peeps, I've spent the last few hours looking at how to best launch application clients, and I couldn't find any documentation on how to do it nicely (apart from Joe Ottingers's stuff on auto started application clients - http://www.orionsupport.com/articles/appclient.html). I then discovered I was doing it the hard way, and it occurred to me that others may also be doing it this way, so here's what I discovered... Previously I was doing something basic like this to launch my application clients: java -jar %ORION_HOME%\orion.jar;%ORION_HOME%\many more orion jars;%ORION_HOME%/lib/log4j.jar;myapp-client.jar com.acme.MyAppClient And I had a jndi.properties in the same directory which specified how to connect to Orion. This is clunky and requires that you distribute all your jar files to the machine you wish to run it on. Yuck. Then, I discovered applicationlauncher.jar (it's not exactly hidden, it's in the Orion dir :-). This lets you launch application clients locally, even if they are installed on remote systems. Its seemingly like an Orion version of java web start. To use it, you need to ensure that your application client is deployed properly in a J2EE sense. For me, all I had to do was: - add a module and java tags to my application.xml like so: module javamyapp-client.jar/java /module - copy my shared libraries into a lib dir inside my .ear file - add a manifest for myapp-client.jar with the main class and any shared libraries like so: Manifest-Version: 1.0 Main-Class: com.acme.MyAppClient Class-Path: lib/log4j.jar Now, I can launch the application client by issuing the command java -jar c:\apps\orion\154\applicationlauncher.jar ormi://localhost/myapp/mayapp-client.jar user password This is cool because I don't have to frig about with the classpath or jndi.properties at launch time, presumably I could launch it on a remote machine if I wanted with similar ease (!). Presumably all you would need on the remote machine would be applicationlauncher.jar and orion.jar (rather than all your applications jar files), but I've not tested it... Anyone have any comments on this? Cheers Geoff
Orion doesn't pass stack traces from server to application client?
Hi there, I just noticed that the application client that I wrote for Orion is printing stack traces like so: javaxejbDuplicateKeyException: Entity already exists at comevermind_dnEXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(:1446) at comevermind_dninvokeMethod(:1369) at comevermind_ydinvoke(:53) at __Proxy2my method(Unknown Source) Which presumably means it is not passing the stack trace information across from the server to the client This means I can't see the part of the stack trace on the server, which is really annoying Is there a way around this? I'm sure lots of people would have this problem, so I'm probably just missing something obvious Cheers Geoff
RE: Orion crashes JVM
If you are on windows, try pressing Ctrl-Break on the Orion window (can't remember the kill number on unix). The JVM will print out a stack dump of all the threads. That should help you to see if there is a deadlock or something like that. Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Juan Fuentes Sent: Thursday, 28 February 2002 4:19 AM To: Orion-Interest Subject: Orion crashes JVM Hi list! After few moments of orion (1.5.2) been started, the cpu usage of the JVM that runs orion drops to 0%. Obviously, orion stops answering requests. We are trying to find the problem. Don't know if it's in our application (it runs OK in other machines with the same orion server), in the orion itself, or even in the operating system. Any idea?? Thanks. -- .. Juan Fuentes Nieto Essi Projects [EMAIL PROTECTED]t +34 977 221 182 http://www.essiprojects.com f +34 977 230 170 ..
RE: Uploading files to Orion webserver with MultipartParser API
Just be aware, MS don't number each release of their browser like NS do. For example, the original release of 5.5 was very buggy, but it's had at least a couple of Service Packs since then (5.5.1, 5.5.2, if you like). You need to indicate which service pack and which OS you are running on before you can really compare IE versions properly. You may also wish to ensure there are no proxies or anything like that in the middle between IE and Orion, as they can change the HTTP stream. Also, have you configured IE to use HTTP 1.0 or 1.1? Try running the same example code on Tomcat 4.x, with your different browsers. If that works you can pretty much blame Orion. Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Joan Josep Iglesias Sent: Thursday, 28 February 2002 3:14 AM To: Orion-Interest Subject: Re: Uploading files to Orion webserver with MultipartParser API Hi again Justine, I've just prove it with an IE 5.5 and I have'nt got any problem... I don't know what problem you can have... If you want, you can try to read the upload file byte by byte... the way I token (by the moment). Good luck Justine!! Joan On Wednesday 27 February 2002 10:17 am, you wrote: Hi Thanks for that, I wasn't aware of those classes, I gave them a go. Similar problem. Different error, but its occasionally failing. I also tried the non-brand-specific UploadServlet.java, similar results. However, I have gotten closer. It was failing on Internet Explorer 5.5. I tried Netscape 4.7, and it seemed fine. I tried it on 5.0 and IE 6 and it seemed fine. So it appears that it is a problem with IE 5.5. Very strange... Thanks for the help, much appreciated. Justin P.S. this is my second attempt at posting this, it appears the list does not pick up everything that is posted. -Original Message- From: Joan Josep Iglesias [mailto:[EMAIL PROTECTED]] Sent: 22 February 2002 09:33 To: Orion-Interest Subject: Re: Uploading files to Orion webserver with MultipartParser API Hi, I'm trying to upload files to my server, but I'm using the orion libreries to do it http://kb.atlassian.com/content/orionsupport/a rticles/fileupload.html Why don't you try with those libraries? Joan
RE: jndi.properties and ApplicationClientInitialContextFactory
That'd be cool. Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Magnus Rydin Sent: Wednesday, 27 February 2002 10:22 AM To: Orion-Interest Subject: SV: jndi.properties and ApplicationClientInitialContextFactory Hi there, You would pay for the 1 server and not for the 10 clients. Hopefully we will find time to generate a small client.jar to use instead of the larger jar files in the near future. WR Magnus Rydin IronFlare -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] För Brendan McKenna Skickat: den 26 februari 2002 09:06 Till: Orion-Interest Ämne: Re: jndi.properties and ApplicationClientInitialContextFactory Hi, Does the requirement to install orion.jar with every instance of the client application mean that you have to (in a commercial environment) purchase an Orion license for each seperate instance of the client you want to run. In other words, if I want to run 10 instances of my client, plus 1 of the server itself, how many licenses do I need to buy, 1 or 11? Brendan -- Brendan McKenna [EMAIL PROTECTED] Senior Partner Hallway Software Design Corp.
RE: A nonfatal internal JIT (3.10.107(x)) error ??
Title: Message By definition, it'sa JVM bug. There is no possible Java which may validly cause the VM to crash. (well, apart from Java which calls native code). Try turning off the JIT. It will be slower but at least it won't crash. Also, try different VMs, eg IBM, or JDK1.4. geoff -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of David TunkransSent: Monday, 25 February 2002 2:34 AMTo: Orion-InterestSubject: Re: A nonfatal internal JIT (3.10.107(x)) error ?? No. JDK1.3.x - Original Message - From: daniele rizzi To: Orion-Interest Sent: Friday, February 22, 2002 4:50 PM Subject: R: A nonfatal internal JIT (3.10.107(x)) error ?? do you use jdk1.2.2? d. -Messaggio originale-Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Per conto di David TunkransInviato: venerdì 22 febbraio 2002 11.51A: Orion-InterestOggetto: A nonfatal internal JIT (3.10.107(x)) error ?? Anyone know what this could be? $ java -jar orion.jar A nonfatal internal JIT (3.10.107(x)) error 'Relocation error: NULL relocation ta 'org/apache/crimson/parser/Parser2.maybeComment (Z)Z': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi
RE: Uploading files to Orion webserver with MultipartParser API
Hi there, Did you read the http://www.servlets.com/cos/faq.html? Cheers Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Justin Crosbie Sent: Friday, 22 February 2002 3:22 AM To: Orion-Interest Subject: Uploading files to Orion webserver with MultipartParser API Hi, I'm wondering if this has anything to do with the Orion webserver. I am using the com.oreilly.servlet.multipart.MultipartParser to upload files to my servlet. If you try the same file several times, it will sometimes work and sometimes fail with a Corrupt form data: no leading boundary IOException. It fails because normally it expects to see a valid boundary in the HttpServletRequest obj, but some of the time the Header is being sent with the content. So where it expects to see something like 12012133613061, it finds a POST url... HTTP1.1 etc It is strange that it sometimes works and sometimes not. Is there anything I can set on the webserver side to ensure that the content is as is expected? Thanks, Justin
(repost) FW: A word of warning: SwiftMQ and Resource providers.
Argh. Mailing lists that are not reliable annoy the out of me. -Original Message- From: Geoff Soutter [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 19 February 2002 9:32 AM To: 'Orion-Interest' Subject: RE: A word of warning: SwiftMQ and Resource providers. Hi Magnus, All I did was follow the instructions in the resource providers document (http://www.orionserver.com/docs/resource-providers/resource-providers.x ml) As soon as I added the resource-provider tag you quoted below, and restarted orion, I got: C:\apps\orion\154java -jar orion.jar Error deploying file:/C:/temp/newsfeed/build/newsfeed/newsfeed-ejb.jar homes: JMS Error: Queue 'testtopic' is not local! Can't create a Consumer on it! 2002-02-19 09:23:14,435 INFO StartupServlet - startup completed Orion/1.5.4 initialized Which is exactly the same error as originally reported below. Cheers, Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Magnus Rydin Sent: Monday, 18 February 2002 7:35 PM To: Orion-Interest Subject: RE: A word of warning: SwiftMQ and Resource providers. Geoff, It IS fixed in 1.5.4, so please let us know what fails for you. Here is a sample setup: 1. Set up and start SwiftMQ. 2. In your /config/application.xml have a setup like the following: resource-provider class=com.evermind.server.deployment.ContextScanningResourceProvider display-name=SwiftMQ resource name=SwiftMQ description SwiftMQ resource provider. /description property name=java.naming.factory.initial value=com.swiftmq.jndi.InitialContextFactoryImpl / property name=java.naming.provider.url value=smqp://localhost:4001 / property name=resource.names value=testtopic,testqueue@router1,plainsocket@router1 / /resource-provider 3. Start Orion, deploy the ATM sample (it uses a MDB with a topic) 4. Configure the ATM sample to use your resource provider with something like the following in your orion-ejb-jar.xml: message-driven-deployment name=mainLogger destination-location=java:comp/resource/SwiftMQ/testtopic connection-factory-location=java:comp/resource/SwiftMQ/plainsocket@rout er1 ejb-ref-mapping name=ejb/mainLog / /message-driven-deployment Could you please let me know where/how this fails for you? WR -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Geoff Soutter Sent: den 18 februari 2002 02:50 To: Orion-Interest Subject: RE: A word of warning: SwiftMQ and Resource providers. FYI, this was not fixed in 1.5.4. Naughty Magnus! :-) Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ray Harrison Sent: Monday, 14 January 2002 8:50 AM To: Orion-Interest Subject: Re: A word of warning: SwiftMQ and Resource providers. According to Magnus R, the problem will be fixed in the next release. I don't know if you can use SwiftMQ / Topics with the Oracle code base (OC4J), but maybe worth a shot. Hopefully soon from the good folks at Orion! --- Graham Bennett [EMAIL PROTECTED] wrote: On Tue, Nov 20, 2001 at 12:29:54PM +0200, Lachezar Dobrev wrote: Recently looking at the Resource-Providers docs, and EAGER to use an external JMS for my MDBs I and a colleague decided to run the demos. As quite a surprise the demo run ok. The MDB did everything when a message was sent to the Queue. The BIG disappointment was, when we tried to do the same with the topic. In short: It does not work. Error deploying file:/D:/Temp/Orion/applications/Orion2SwiftMQ/Orion2SwiftMQ.jar homes: JMS Error: Queue 'testtopic' is not local! Can't create a Consumer on it! has this now been fixed? I'm getting the same error with SwiftMQ and the latest build. cheers, -- Graham Bennett [EMAIL PROTECTED] __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
RE: (repost) FW: A word of warning: SwiftMQ and Resource providers.
Hmm. Strange. I'm definitely using 1.5.4, you can see it in the console output I included below. I tried doing an autoupdate and trying it again, made no difference. I even did a recursive diff against the .zip version and the autoupdate version and they are identical (despite the fact autoupdate claimed it was overwriting most of the files). There must be a logical explanation ... but I can't see it ... I'm using jdk 1.3.1_02 and SwiftMQ 2.1.3. Is that the versions you guys are using? geoff PS, I'm not using Topics myself, I was only providing a FYI for those that cared... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ray Harrison Sent: Wednesday, 20 February 2002 10:04 AM To: Orion-Interest Cc: [EMAIL PROTECTED] Subject: Re: (repost) FW: A word of warning: SwiftMQ and Resource providers. Interesting - I *don't* get that error any longer with 1.5.4, though I did with 1.5.3. --- Geoff Soutter [EMAIL PROTECTED] wrote: Argh. Mailing lists that are not reliable annoy the out of me. -Original Message- From: Geoff Soutter [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 19 February 2002 9:32 AM To: 'Orion-Interest' Subject: RE: A word of warning: SwiftMQ and Resource providers. Hi Magnus, All I did was follow the instructions in the resource providers document (http://www.orionserver.com/docs/resource-providers/resource-providers.x ml) As soon as I added the resource-provider tag you quoted below, and restarted orion, I got: C:\apps\orion\154java -jar orion.jar Error deploying file:/C:/temp/newsfeed/build/newsfeed/newsfeed-ejb.jar homes: JMS Error: Queue 'testtopic' is not local! Can't create a Consumer on it! 2002-02-19 09:23:14,435 INFO StartupServlet - startup completed Orion/1.5.4 initialized Which is exactly the same error as originally reported below. Cheers, Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Magnus Rydin Sent: Monday, 18 February 2002 7:35 PM To: Orion-Interest Subject: RE: A word of warning: SwiftMQ and Resource providers. Geoff, It IS fixed in 1.5.4, so please let us know what fails for you. Here is a sample setup: 1. Set up and start SwiftMQ. 2. In your /config/application.xml have a setup like the following: resource-provider class=com.evermind.server.deployment.ContextScanningResourceProvider display-name=SwiftMQ resource name=SwiftMQ description SwiftMQ resource provider. /description property name=java.naming.factory.initial value=com.swiftmq.jndi.InitialContextFactoryImpl / property name=java.naming.provider.url value=smqp://localhost:4001 / property name=resource.names value=testtopic,testqueue@router1,plainsocket@router1 / /resource-provider 3. Start Orion, deploy the ATM sample (it uses a MDB with a topic) 4. Configure the ATM sample to use your resource provider with something like the following in your orion-ejb-jar.xml: message-driven-deployment name=mainLogger destination-location=java:comp/resource/SwiftMQ/testtopic connection-factory-location=java:comp/resource/SwiftMQ/plainsocket@ro ut er1 ejb-ref-mapping name=ejb/mainLog / /message-driven-deployment Could you please let me know where/how this fails for you? WR -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Geoff Soutter Sent: den 18 februari 2002 02:50 To: Orion-Interest Subject: RE: A word of warning: SwiftMQ and Resource providers. FYI, this was not fixed in 1.5.4. Naughty Magnus! :-) Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ray Harrison Sent: Monday, 14 January 2002 8:50 AM To: Orion-Interest Subject: Re: A word of warning: SwiftMQ and Resource providers. According to Magnus R, the problem will be fixed in the next release. I don't know if you can use SwiftMQ / Topics with the Oracle code base (OC4J), but maybe worth a shot. Hopefully soon from the good folks at Orion! --- Graham Bennett [EMAIL PROTECTED] wrote: On Tue, Nov 20, 2001 at 12:29:54PM +0200, Lachezar Dobrev wrote: Recently looking at the Resource-Providers docs, and EAGER to use an external JMS for my MDBs I and a colleague decided to run the demos. As quite a surprise the demo run ok. The MDB did everything when a message was sent to the Queue. The BIG disappointment was, when we tried to do the same with the topic. In short: It does not work. Error deploying file:/D:/Temp/Orion/applications/Orion2SwiftMQ/Orion2SwiftMQ.jar homes: JMS Error: Queue 'testtopic' is not local! Can't create a Consumer on it! has this now been fixed? I'm getting the same error with SwiftMQ and the latest build. cheers, -- Graham Bennett [EMAIL PROTECTED
RE: Orion MDB reverses message order with SwiftMQ as well as OrionJMS (was RE: fyi: 1.5.4 still stacks rather than queues JMS messages)
Hi there, Actually I didn't read the EJB spec as I had guessed it was a JMS bug originally, so thanks for pointing that out. Very lazy of me. However, section 15.4.6 Concurrency of Message Processing of the EJB 2.0 spec says: the container should attempt to deliver messages in order when it does not impair the concurrency of message processing. I have max-instances set to 1, which means that there is _no_ concurrency. Thus, the container ought to deliver messages in order. Note also that the JMS spec mentions that messages ought to be delivered in order as well. Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Poop Sent: Tuesday, 19 February 2002 12:11 AM To: Orion-Interest Subject: Re: Orion MDB reverses message order with SwiftMQ as well as OrionJMS (was RE: fyi: 1.5.4 still stacks rather than queues JMS messages) Well, I just tested an MDB with SwiftMQ, and Orion still stuffs up the message ordering. --Geoff Soutter Please read the EJB2.0 spec before recording this as a bug. Message order is not guaranteed in MDB's. - Original Message - From: Geoff Soutter [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Sunday, February 17, 2002 10:45 PM Subject: Orion MDB reverses message order with SwiftMQ as well as OrionJMS (was RE: fyi: 1.5.4 still stacks rather than queues JMS messages) Well, I just tested an MDB with SwiftMQ, and Orion still stuffs up the message ordering. Presumably this means it's broken in the MDB implemenation rather than in Orion's JMS code, which is a pity. So, for all those using Orion MDBs, and relying on message ordering being preserved (if there are any apart from me :-), please check out bug 729 in Bugzilla. It contains demo code to demonstrate the problem under both Orion JMS and SwiftMQ. http://bugzilla.orionserver.com/bugzilla/show_bug.cgi?id=729 Cheers, Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Geoff Soutter Sent: Monday, 18 February 2002 9:18 AM To: Orion-Interest Subject: RE: fyi: 1.5.4 still stacks rather than queues JMS messages Hi Mike, I didn't see that comment. Unfortunately this list is so flakey that I only get about 75% of the messages. I just checked the JMS 1.02 spec, here's what it has to say about message order (in 4.4.10.1 Order of Message Receipt): JMS defines that messages sent by a session to a destination must be received in the order in which they were sent (see Section 4.4.10.2, Order of Message Sends, for a few qualifications). So it seems that, contrary to what that someone said, message order _is_ important with JMS. Cheers, Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mike Cannon-Brookes Sent: Saturday, 16 February 2002 8:43 AM To: Orion-Interest Subject: Re: fyi: 1.5.4 still stacks rather than queues JMS messages Geoff, Also as someone said on this list just a few days ago - as per the JMS spec there is no guarantee that your messages turn up in the sequence you sent them. Cheers, Mike Mike Cannon-Brookes [EMAIL PROTECTED] Atlassian :: www.atlassian.com Supporting YOUR world On 16/2/02 12:55 AM, Stephen Davidson ([EMAIL PROTECTED]) penned the words: Geoff Soutter wrote: Re the problem reported a couple weeks back by Jorge Jimenez and confirmed by myself, I tested 1.5.4 to see if they had fixed this problem, but it's still there. Just set max-instances to 1 and load up with a lot of messages, it works just like a stack. Doh. Maybe I'll have time to put this into Bugzilla next week... Is _everyone_ using a third party JMS with Orion? geoff I am using the Orion JMS, but the way the code is set up, it does not care about the order the messages arrived. I had never noticed the Out of Order issue, as it was not applicable. -Steve _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
RE: fyi: 1.5.4 still stacks rather than queues JMS messages
Hi Mike, I didn't see that comment. Unfortunately this list is so flakey that I only get about 75% of the messages. I just checked the JMS 1.02 spec, here's what it has to say about message order (in 4.4.10.1 Order of Message Receipt): JMS defines that messages sent by a session to a destination must be received in the order in which they were sent (see Section 4.4.10.2, Order of Message Sends, for a few qualifications). So it seems that, contrary to what that someone said, message order _is_ important with JMS. Cheers, Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mike Cannon-Brookes Sent: Saturday, 16 February 2002 8:43 AM To: Orion-Interest Subject: Re: fyi: 1.5.4 still stacks rather than queues JMS messages Geoff, Also as someone said on this list just a few days ago - as per the JMS spec there is no guarantee that your messages turn up in the sequence you sent them. Cheers, Mike Mike Cannon-Brookes [EMAIL PROTECTED] Atlassian :: www.atlassian.com Supporting YOUR world On 16/2/02 12:55 AM, Stephen Davidson ([EMAIL PROTECTED]) penned the words: Geoff Soutter wrote: Re the problem reported a couple weeks back by Jorge Jimenez and confirmed by myself, I tested 1.5.4 to see if they had fixed this problem, but it's still there. Just set max-instances to 1 and load up with a lot of messages, it works just like a stack. Doh. Maybe I'll have time to put this into Bugzilla next week... Is _everyone_ using a third party JMS with Orion? geoff I am using the Orion JMS, but the way the code is set up, it does not care about the order the messages arrived. I had never noticed the Out of Order issue, as it was not applicable. -Steve
Orion MDB reverses message order with SwiftMQ as well as OrionJMS (was RE: fyi: 1.5.4 still stacks rather than queues JMS messages)
Well, I just tested an MDB with SwiftMQ, and Orion still stuffs up the message ordering. Presumably this means it's broken in the MDB implemenation rather than in Orion's JMS code, which is a pity. So, for all those using Orion MDBs, and relying on message ordering being preserved (if there are any apart from me :-), please check out bug 729 in Bugzilla. It contains demo code to demonstrate the problem under both Orion JMS and SwiftMQ. http://bugzilla.orionserver.com/bugzilla/show_bug.cgi?id=729 Cheers, Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Geoff Soutter Sent: Monday, 18 February 2002 9:18 AM To: Orion-Interest Subject: RE: fyi: 1.5.4 still stacks rather than queues JMS messages Hi Mike, I didn't see that comment. Unfortunately this list is so flakey that I only get about 75% of the messages. I just checked the JMS 1.02 spec, here's what it has to say about message order (in 4.4.10.1 Order of Message Receipt): JMS defines that messages sent by a session to a destination must be received in the order in which they were sent (see Section 4.4.10.2, Order of Message Sends, for a few qualifications). So it seems that, contrary to what that someone said, message order _is_ important with JMS. Cheers, Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mike Cannon-Brookes Sent: Saturday, 16 February 2002 8:43 AM To: Orion-Interest Subject: Re: fyi: 1.5.4 still stacks rather than queues JMS messages Geoff, Also as someone said on this list just a few days ago - as per the JMS spec there is no guarantee that your messages turn up in the sequence you sent them. Cheers, Mike Mike Cannon-Brookes [EMAIL PROTECTED] Atlassian :: www.atlassian.com Supporting YOUR world On 16/2/02 12:55 AM, Stephen Davidson ([EMAIL PROTECTED]) penned the words: Geoff Soutter wrote: Re the problem reported a couple weeks back by Jorge Jimenez and confirmed by myself, I tested 1.5.4 to see if they had fixed this problem, but it's still there. Just set max-instances to 1 and load up with a lot of messages, it works just like a stack. Doh. Maybe I'll have time to put this into Bugzilla next week... Is _everyone_ using a third party JMS with Orion? geoff I am using the Orion JMS, but the way the code is set up, it does not care about the order the messages arrived. I had never noticed the Out of Order issue, as it was not applicable. -Steve
RE: fyi: 1.5.4 still stacks rather than queues JMS messages
Hi Russ, What exactly do you mean by stored/retrieved? Is there a reference in the spec you can point out? Cheers Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Russ White Sent: Monday, 18 February 2002 11:47 AM To: Orion-Interest Subject: RE: fyi: 1.5.4 still stacks rather than queues JMS messages Yes, they should be received in order, but not necessarily stored/retrieved in order. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Geoff Soutter Sent: Sunday, February 17, 2002 5:18 PM To: Orion-Interest Subject: RE: fyi: 1.5.4 still stacks rather than queues JMS messages Hi Mike, I didn't see that comment. Unfortunately this list is so flakey that I only get about 75% of the messages. I just checked the JMS 1.02 spec, here's what it has to say about message order (in 4.4.10.1 Order of Message Receipt): JMS defines that messages sent by a session to a destination must be received in the order in which they were sent (see Section 4.4.10.2, Order of Message Sends, for a few qualifications). So it seems that, contrary to what that someone said, message order _is_ important with JMS. Cheers, Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mike Cannon-Brookes Sent: Saturday, 16 February 2002 8:43 AM To: Orion-Interest Subject: Re: fyi: 1.5.4 still stacks rather than queues JMS messages Geoff, Also as someone said on this list just a few days ago - as per the JMS spec there is no guarantee that your messages turn up in the sequence you sent them. Cheers, Mike Mike Cannon-Brookes [EMAIL PROTECTED] Atlassian :: www.atlassian.com Supporting YOUR world On 16/2/02 12:55 AM, Stephen Davidson ([EMAIL PROTECTED]) penned the words: Geoff Soutter wrote: Re the problem reported a couple weeks back by Jorge Jimenez and confirmed by myself, I tested 1.5.4 to see if they had fixed this problem, but it's still there. Just set max-instances to 1 and load up with a lot of messages, it works just like a stack. Doh. Maybe I'll have time to put this into Bugzilla next week... Is _everyone_ using a third party JMS with Orion? geoff I am using the Orion JMS, but the way the code is set up, it does not care about the order the messages arrived. I had never noticed the Out of Order issue, as it was not applicable. -Steve
RE: Debugging using JPDA, FATAL ERROR
No worries, mate. I blame sun, the error message is hopeless. geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, 14 February 2002 6:54 PM To: Orion-Interest Subject: RE: Debugging using JPDA, FATAL ERROR Thanks Geoff, you were right. Tibor -Original Message- From: Geoff Soutter [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 13, 2002 11:34 PM To: Orion-Interest Subject: RE: Debugging using JPDA, FATAL ERROR Hmm, I seem to remember this one as well. Make sure you are using the java.exe from the JDK directory rather than the JRE, as in the latest 1.3.1 revision only the JDK java.exe seems to have access to JPDA (or at least, that's what I remember, YMMV) Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, 13 February 2002 8:10 PM To: Orion-Interest Subject: Debugging using JPDA, FATAL ERROR Hi, I'd need some urgent help on starting Orion with JDPA remote debugging enabled. I read through the docs and followed the instructions to start this way: java -classic -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000 -jar orion.jar But it came up with a FATAL ERROR : Transport dt_socket failed to initialize, rc = 509. FATAL ERROR in native method: No transports initialized abnormal program termination In case you have some ideas, share them with me. Thanks, Tibor
fyi: 1.5.4 still stacks rather than queues JMS messages
Re the problem reported a couple weeks back by Jorge Jimenez and confirmed by myself, I tested 1.5.4 to see if they had fixed this problem, but it's still there. Just set max-instances to 1 and load up with a lot of messages, it works just like a stack. Doh. Maybe I'll have time to put this into Bugzilla next week... Is _everyone_ using a third party JMS with Orion? geoff
RE: System Date.
Title: Message I've had problems with Java timezones before. As I remember, Unix inherits timezone settings from it's environment. Did you run your java test class with the same environment as Orion (eg the same user)? geoff -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Troy GibsonSent: Wednesday, 13 February 2002 6:00 AMTo: Orion-InterestSubject: System Date. Having trouble with system Date. In Orion our application converts dates based on our users time zone. For some reason our application is producing incorrect date times. The same piece of code when ran on its own as a Java class produces correct time conversions. Are there environment variables that Orion uses that may cause it to interprets the system date differently than what the system date really is? We use a staging and production instances of Orion running on two different Unix boxes. Both boxes have the same system date, the application running on staging produces correct dates, the one on production does not, further evidence that maybe the problem lies with the Orion instance and not the code or the servers. Thanks for any ideas you may have.
[announce] Log4J Appender for Orion's application.log
Hi there,
I've hacked up an Orion Appender to allow you to log to the
application.log file, via the Logger instance that Orion installs at
java:comp/Logger. Here it is in all it's glory, use it however you wish.
Cheers
Geoff
PS, did anyone figure out if it's possible to get orion to roll it's log
files when they get too big? ;-)
import com.evermind.util.LogEvent;
import com.evermind.util.Logger;
import org.apache.log4j.AppenderSkeleton;
import org.apache.log4j.Layout;
import org.apache.log4j.PatternLayout;
import org.apache.log4j.spi.ErrorCode;
import org.apache.log4j.spi.LoggingEvent;
import org.apache.log4j.spi.ThrowableInformation;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
/*
Example Test Code
Deploy OrionAppender with log4j in the Orion lib directory,
then add this code to an EJB or JSP and execute it.
Note it doesn't seem to be able to find a Logger instance when
running
in an application client, so in this case use a normal log4j
Appender.
Category log = Category.getInstance(for.bar.Category);
BasicConfigurator.resetConfiguration(); // for jsp reloading
BasicConfigurator.configure(new OrionAppender());
log.info(A test INFO message);
NDC.push(demo-ndc);
log.warn(A test WARN message with NDC);
NDC.pop();
log.fatal(A test FATAL message with exception, new
Exception(fatal));
*/
public class OrionAppender extends AppenderSkeleton {
// NOTE: Most simple layouts are not useful for this Appender
because
// the design of log4j is such that Layouts are responsible for
adding
// line endings, and we require that the Layout not add line
endings.
// This is IMHO a design flaw in log4j...
// NOTE: Orion includes a 2/5/02 5:46 PM format date in each log
entry.
// NOTE: Orion doesn't generate unique names for each thread, so the
thread
// name pattern entry is not much use.
// NOTE: Using a hardcoded layout now, can make this configurable
later.
// Basically it's priority category [ndc]: message
private static final Layout sLayout = new PatternLayout(
%-5p %c{1} [%x]: %m);
private Logger iLogger;
public OrionAppender() {
try {
Context lContext = new InitialContext();
Object lBoundObject = lContext.lookup(java:comp/Logger);
iLogger = (Logger) PortableRemoteObject.narrow(lBoundObject,
Logger.class);
} catch (Exception e) {
errorHandler.error(Error finding Orion Logger for appender
[ +
name + ]., e, ErrorCode.GENERIC_FAILURE);
}
}
public boolean requiresLayout() {
// Tell the configurator we have our own hardcoded layout.
// See PropertyConfigurator for how this method is used.
return false;
}
protected void append(LoggingEvent event) {
if (iLogger == null) {
errorHandler.error(No Logger for appender [ + name +
].);
return;
}
try {
LogEvent lEvent = null;
String lMessage = sLayout.format(event);
ThrowableInformation lInfo =
event.getThrowableInformation();
if (lInfo == null) {
lEvent = new LogEvent(lMessage);
} else {
lEvent = new LogEvent(lMessage, lInfo.getThrowable());
}
iLogger.log(lEvent);
} catch (Exception lEx) {
errorHandler.error(Could not log message in appender [ +
name
+ ]., lEx, ErrorCode.GENERIC_FAILURE);
}
}
public synchronized void close() {
iLogger = null;
}
}
Log4j appender for logging to application.log
Hi there, I've been doing some research about how to log using log4j with Orion. I was thinking that I'd like to have the log written to the Orion application log file so that you can see the order that things happen in. You can see other people have done similar things for other app servers, eg weblogic (see the source posted at http://www.geocrawler.com/lists/3/Web/8359/0/7380790/ and http://theserverside.com/discussion/thread.jsp?thread_id=2194). I noticed some discussion on the list about logging using log4j to the application.log file by writing an OrionAppender class which logs via the com.evermind.util.Logger and LogEvent which are supposedly located at java:comp/Logger (http://www.mail-archive.com/orion-interest@orionserver.com/msg11512.htm l, http://www.mail-archive.com/orion-interest@orionserver.com/msg06399.html , http://www.mail-archive.com/orion-interest@orionserver.com/msg06502.html ). Has anyone attempted to implement such logger? If not, I'm thinking of having a hack myself... Cheers Geoff
RE: Questionnaire
I was wondering what the (BS) stood for :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Robb (BS) Sent: Sunday, February 03, 2002 8:10 AM To: Orion-Interest Cc: [EMAIL PROTECTED] Subject: Re: Questionnaire If you cannot control your weblist from people who deploy viruses, how in the hell can you make a decent app server Please remove me from your list ASAP!! - Original Message - From: chen.hui To: Orion-Interest Sent: Saturday, February 02, 2002 9:31 AM Subject: Questionnaire
RE: Container leaving Dirty Connection in CMP with container-managed transactions
You could try using your own wrappers on the JDBC classes ala this article http://www.onjava.com/lpt/a/onjava/2001/12/05/optimization.html Then, you can see exactly what Orion is calling. At least that helps track the bug down a bit. Actually, maybe you could use this method to force Oracle to clean itself up better? That is, to enforce the contract of the Connection.close() method (as pointed out in Avi's email that you forwarded to the list). Actually, if what he says is true, maybe all us Oracle users could use some wrappers like that! :-) Cheers geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeff Hubbach Sent: Wednesday, January 30, 2002 3:44 AM To: Orion-Interest Subject: Container leaving Dirty Connection in CMP with container-managed transactions If an exception is thrown in a CMP entity bean with container-managed transactions, a Dirty Connection is left behind that is never cleaned up (or at least in 15 minutes). We've set inactivity-timeout in the data-sources and tweaked with all the transaction settings, all to no avail. Is anyone experiencing this? It does this with Oracle (running Oracle's driver as well as Merant's), PostgreSQL, and SQL Server (running Merant's driver). The biggest issue is that the dirty connection in Oracle and SQL Server is holding a lock to the row that caused the exception, preventing any further access, actually deadlocking the server (in PostgreSQL, further updates to that row go through just fine). Or at least this is what we _think_ is happening, as there's no better explanation that we've found. Jeff.
RE: Job Scheduler pattern
Hmm, want us to write it for you? But seriously, there are commercial apps for J2EE scheduling if that's the kind of thing you are after, just use google... Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Justin Crosbie Sent: Saturday, January 26, 2002 2:49 AM To: Orion-Interest Subject: RE: Job Scheduler pattern Yes I have seen that, it is very bare-bones. It doesn't even use the Timer classes. I need to know how to make this robust. Thanks, Justin -Original Message- From: Joseph B. Ottinger [mailto:[EMAIL PROTECTED]] Sent: 25 January 2002 12:04 To: Orion-Interest Subject: Re: Job Scheduler pattern The www.orionsupport.com site has a sample scheduler that can easily be converted to do something like this. On Fri, 25 Jan 2002, Justin Crosbie wrote: Hi, I'm not sure if I've asked this before, or if I should be asking on a general EJB list. I'd like to implement a job scheduler in J2EE. This would shcedule the execution of EJB methods at a specified time in the future. It would have to be persistent, and jobsd would be rescheduled upon appserver restart. Is it as simple as using the Timer and TimerTask in java.util to implement an app that is started with the client-module tag? Does it matter as far as Orion goes whether I use a java.util.Timer as a daemon or not? What can I do if the app, or the Timer object dies at any stage? I've had problems where after some time something goes wrong I get a strange Remote Exception, and the only solution is to restart the VM. What might cause this? Any opinions on this? How do I make this solution robust is what I am asking. Thanks for any help, Justin --- Joseph B. Ottinger [EMAIL PROTECTED] http://adjacency.org/ IT Consultant
RE: Integrating LOG4J into Orion...
It probably depends on how you have it configured. The main thing to remember is that J2EE uses multiple classloaders and each classloader can potentially have it's own version of a singleton. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Justin Crosbie Sent: Monday, 21 January, 2002 8:13 PM To: Orion-Interest Subject: RE: Integrating LOG4J into Orion... Hi, We have wrapped Log4J in a singleton, so the first call to it initialises it. I'm not sure if this is a good idea or not though, but we've had no problems so far. Any opinions? -Justin -Original Message- From: Romen Law [mailto:[EMAIL PROTECTED]] Sent: 20 January 2002 23:05 To: Orion-Interest Subject: Re: Integrating LOG4J into Orion... ello, What I did was to have a initialising SLSB and let the startup servlet call it. It works for me. cheers romen - Original Message - From: Alex Paransky [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Saturday, January 19, 2002 12:34 PM Subject: FW: Integrating LOG4J into Orion... One more time, the last one did not show up -Original Message- From: Alex Paransky [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 17, 2002 11:09 AM To: Orion-Interest Subject: Integrating LOG4J into Orion... I have a full EJB/JSP application running with Orion. Is there a preferred method of initializing LOG4J in this situation? Looking at the LOG4J documentation, they mention using a startup servlet to do the initialization. I am concerned as to how this would work with the CLASSLOADER hierarchy. If I initialize my LOG4J at the servlet (WEB) layer, will the EJB's be able to see the initialized LOG4J or will they attempt to re-initialize due to the different classloader? Thanks. -AP_
RE: stateful bean error
By definition, if the jvm crashes, it's a JVM bug (Unless you have loaded classes which use native code (like the Oracle OCI jdbc drivers). I'd suggest you try the latest Sun JVM with and without hotspot, and if that fails have a go with the IBM JVM. Cheers Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of SeaWolf Sent: Monday, 21 January, 2002 10:47 AM To: Orion-Interest Subject: stateful bean error Hi... can anybody explain it to me, what is this all about.. atjava.io.DataOutputStream.writeUTF DataOutputStream.java(CompiledCode)) at java.io.ObjectOutputStream.writeUTF(ObjectOutputStream.java:1529) at com.evermind.server.ejb.StatefulSessionObjectInfo.writeExterna l(StatefulSession ObjectInfo.java:31) at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.jav a(Compiled Code)) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java (Compiled Code)) at com.evermind.server.rmi.RMIOutputStream.writeType(RMIOutputStr eam.java(Compiled Code)) at com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java (Compiled Code)) at com.evermind.util.ThreadPoolThread.run(ThreadPoolThread.java(Compiled Code)) My application server crash(segmentation violation) when i invoke the stateful session bean. seawolf __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
RE: IronFlare bug fixing policy
Doh! Sorry. Well at least I figured out what happens when one reports a bug... Thanks to all who helped... Any ideas when the new release might be available? Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Magnus Rydin Sent: Wednesday, 16 January, 2002 8:26 PM To: Orion-Interest Subject: SV: IronFlare bug fixing policy Hi Geoff, your bug report 695 seems to be a copy of bug 670 which has already been fixed (not released though). WR Magnus Rydin -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]För Geoff Soutter Skickat: den 16 januari 2002 07:06 Till: Orion-Interest Kopia: Orion Interest List Ämne: RE: IronFlare bug fixing policy Hi there EW, Thanks for the response. The one I've reported (so far) is 695 (http://bugzilla.orionserver.com/bugzilla/show_bug.cgi?id=695). It doesn't include an .ear file or anything, but it seems to be it would be pretty trivial to track it down _if you had access to the source code_ - since I included the buggy portion of the generated wrapper it's clear to see where the bug is. In fact, I just did a search on the class files and I found the likely location of the bug. It's probably in _ql.class, since it's the only class which contains response.iterator() and it's this line which is throwing the NullPointerException. Grrr - closed source things annoy me!! So, seems like you're saying theres not much propect of bugs being fixed till the refactoring is over? Did they mention when this is likely to be? RSN I suppose :-) Cheers, Geoff BTW, seems like bugzilla is down at the moment? -Original Message- From: The elephantwalker [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 16 January, 2002 4:03 PM To: Orion-Interest; [EMAIL PROTECTED] Subject: RE: IronFlare bug fixing policy Geoff, Magnus Rydin told me that what they need are good examples for each bug so that they are absolutely reproducible. If you look at some of the bugs that are still open, these bugs don't have iron clad examples that are reproducible. So each of these bugs needs to be cleared...which means Magnus R. has to work on reproducing them (if they aren't immediately reproducible), which of course takes time. What he didn't say but reported on the list is a major refactoring going on now in Orion to bring it into compliance with j2ee 1.3. This includes EJB 2.0, Servlet 2.3 (not just the draft), and JSP 1.2, Connections, etc. As we all know, fixing bugs which are going to disappear in a refactoring is a bit of a waste of time. Of course, if its a bug that affects you directly, you may feel differently. Which bug numbers did you report? regards, the elephantwalker www.elephantwalker.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Geoff Soutter Sent: Tuesday, January 15, 2002 4:55 PM To: Orion-Interest Subject: IronFlare bug fixing policy Hi there, I reported a bug on BugZilla a few days back. It's reasonably serious - basically the generated wrapper for the finder method of an EJB is throwing NullPointerException when the EJB throws an exception, hiding the real cause of the problem. (And I just found another bug - ServletExceptions constructed with (string, exception) are reported without the String originally passed.) I haven't heard anything and the bug has not been touched apparently. Does anyone know what IronFlare's policy is regards fixing bugs? Do they tend to fix them quickly, or are they likely to just ignore bug reports? The reason I ask is that I'm happy to use something without much support, but if they refuse to fix bugs then I think I'll have to give up and try elsewhere... Cheers Geoff
RE: IronFlare bug fixing policy
Hi there EW, Thanks for the response. The one I've reported (so far) is 695 (http://bugzilla.orionserver.com/bugzilla/show_bug.cgi?id=695). It doesn't include an .ear file or anything, but it seems to be it would be pretty trivial to track it down _if you had access to the source code_ - since I included the buggy portion of the generated wrapper it's clear to see where the bug is. In fact, I just did a search on the class files and I found the likely location of the bug. It's probably in _ql.class, since it's the only class which contains response.iterator() and it's this line which is throwing the NullPointerException. Grrr - closed source things annoy me!! So, seems like you're saying theres not much propect of bugs being fixed till the refactoring is over? Did they mention when this is likely to be? RSN I suppose :-) Cheers, Geoff BTW, seems like bugzilla is down at the moment? -Original Message- From: The elephantwalker [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 16 January, 2002 4:03 PM To: Orion-Interest; [EMAIL PROTECTED] Subject: RE: IronFlare bug fixing policy Geoff, Magnus Rydin told me that what they need are good examples for each bug so that they are absolutely reproducible. If you look at some of the bugs that are still open, these bugs don't have iron clad examples that are reproducible. So each of these bugs needs to be cleared...which means Magnus R. has to work on reproducing them (if they aren't immediately reproducible), which of course takes time. What he didn't say but reported on the list is a major refactoring going on now in Orion to bring it into compliance with j2ee 1.3. This includes EJB 2.0, Servlet 2.3 (not just the draft), and JSP 1.2, Connections, etc. As we all know, fixing bugs which are going to disappear in a refactoring is a bit of a waste of time. Of course, if its a bug that affects you directly, you may feel differently. Which bug numbers did you report? regards, the elephantwalker www.elephantwalker.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Geoff Soutter Sent: Tuesday, January 15, 2002 4:55 PM To: Orion-Interest Subject: IronFlare bug fixing policy Hi there, I reported a bug on BugZilla a few days back. It's reasonably serious - basically the generated wrapper for the finder method of an EJB is throwing NullPointerException when the EJB throws an exception, hiding the real cause of the problem. (And I just found another bug - ServletExceptions constructed with (string, exception) are reported without the String originally passed.) I haven't heard anything and the bug has not been touched apparently. Does anyone know what IronFlare's policy is regards fixing bugs? Do they tend to fix them quickly, or are they likely to just ignore bug reports? The reason I ask is that I'm happy to use something without much support, but if they refuse to fix bugs then I think I'll have to give up and try elsewhere... Cheers Geoff
RE: Simple question re caching/pooling of BMP Entity Beans
Hi Sergey, Thanks for the reply. I didn't explain it very clearly did I? What I meant was: However, it appears that it goes to the database (i.e. calls _ejbLoad_ in the Entity Bean's implementation) for every call to findByPrimaryKey, regardless of whether it has previously read the instance with the specified key before. Have you been able to get pooling of BMP entity beans working? Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Sergey G. Aslanov Sent: Thursday, 10 January, 2002 6:29 PM To: Orion-Interest Subject: Re: Simple question re caching/pooling of BMP Entity Beans Hi Geoff Loading of beans have these stages: 1. calling ejbFindBy... to get the primKeys of the entities; 2. checking if entities with such keys are already pooled; 3. for every key checking: if not pooled - call ejbLoad, else - get instance from pool; As you see, ejbFindBy... are called always independently of entity is pooled or not. Thursday, January 10, 2002, 2:01:37 AM, you wrote: GS Hi there, GS I'm teaching myself how to use Orion and I've got a simple question GS about caching/pooling of BMP Entity Bean instances. GS I've created a simple app which lets me read a BMP Entity Bean GS through a Session Bean. I would expect that when I call GS findByPrimaryKey on my Entity Bean's home interface, Orion caches GS the instance it creates so that next time I call findByPrimaryKey GS for the same key, it just returns the instance it already has rather GS than creating a new one. However, it appears that it goes to the GS database (i.e. calls ejbFindByPrimaryKey in the Entity Bean's GS implementation) for every call to findByPrimaryKey, regardless of GS whether it has previously read the instance with the specified key GS before. GS I checked the list archive and it appears that someone has reported GS a similar problem a while back but there were no replies GS (http://www.mail-archive.com/orion-interest@orionserver.com/ms g17359 GS .htm GS l). GS I also checked the documentation and for orion-ejb-jar.xml it states GS that exclusive-write-access is true by default, and since I am not GS setting it I presume it's defaulting to true which should allow GS Orion to cache the entity beans. GS So, can anyone shed any light on how whether/how I can get Orion to GS cache BMP entity beans? GS Cheers GS Geoff -- Sergey G. Aslanov, CBOSS Group, Web-technologies department mailto:[EMAIL PROTECTED] tel: +7 095 7555655
RE: Simple question re caching/pooling of BMP Entity Beans
Hmm. Seems I am really getting myself confused. :-). I think I've got it now... I'm mistaking the db call in ejbFindByPrimaryKey with the db call in ejbLoad. Doh. So, the first time I call findByPrimaryKey, Orion calls ejbFindByPrimaryKey which goes to the database basically only to confirm the row hasn't been deleted. Then Orion calls ejbLoad which goes the the database again to load in the actual contents of the row. So, the row in question is accessed twice. Then, the second time, Orion still calls findByPrimaryKey, but avoids the ejbLoad. The thing is here, exclusive-write-access is set to true (by default), so why is Orion bothering to call findByPrimaryKey? Can't it just keep an internal primary key - ejb map and return the ejb instance directly? After all, if exclusive-write-access is on, the row can only be deleted by Orion itself... Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Geoff Soutter Sent: Friday, 11 January, 2002 9:09 AM To: Orion-Interest Subject: RE: Simple question re caching/pooling of BMP Entity Beans Hi Sergey, Thanks for the reply. I didn't explain it very clearly did I? What I meant was: However, it appears that it goes to the database (i.e. calls _ejbLoad_ in the Entity Bean's implementation) for every call to findByPrimaryKey, regardless of whether it has previously read the instance with the specified key before. Have you been able to get pooling of BMP entity beans working? Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Sergey G. Aslanov Sent: Thursday, 10 January, 2002 6:29 PM To: Orion-Interest Subject: Re: Simple question re caching/pooling of BMP Entity Beans Hi Geoff Loading of beans have these stages: 1. calling ejbFindBy... to get the primKeys of the entities; 2. checking if entities with such keys are already pooled; 3. for every key checking: if not pooled - call ejbLoad, else - get instance from pool; As you see, ejbFindBy... are called always independently of entity is pooled or not. Thursday, January 10, 2002, 2:01:37 AM, you wrote: GS Hi there, GS I'm teaching myself how to use Orion and I've got a simple question GS about caching/pooling of BMP Entity Bean instances. GS I've created a simple app which lets me read a BMP Entity Bean GS through a Session Bean. I would expect that when I call GS findByPrimaryKey on my Entity Bean's home interface, Orion caches GS the instance it creates so that next time I call findByPrimaryKey GS for the same key, it just returns the instance it already has rather GS than creating a new one. However, it appears that it goes to the GS database (i.e. calls ejbFindByPrimaryKey in the Entity Bean's GS implementation) for every call to findByPrimaryKey, regardless of GS whether it has previously read the instance with the specified key GS before. GS I checked the list archive and it appears that someone has reported GS a similar problem a while back but there were no replies GS (http://www.mail-archive.com/orion-interest@orionserver.com/ms g17359 GS .htm GS l). GS I also checked the documentation and for orion-ejb-jar.xml it states GS that exclusive-write-access is true by default, and since I am not GS setting it I presume it's defaulting to true which should allow GS Orion to cache the entity beans. GS So, can anyone shed any light on how whether/how I can get Orion to GS cache BMP entity beans? GS Cheers GS Geoff -- Sergey G. Aslanov, CBOSS Group, Web-technologies department mailto:[EMAIL PROTECTED] tel: +7 095 7555655
Anyone got old orionsupport sample application client / scheduler?
You can see it described in googles cache http://www.google.com/search?q=cache:4nkQslt9AjsC:www.orionsupport.com/a rticles/appclient.html+orion+application+clienthl=en If anyone has the source jar file, I'd really appreciate a copy! Cheers Geoff
Simple question re caching/pooling of BMP Entity Beans
Hi there, I'm teaching myself how to use Orion and I've got a simple question about caching/pooling of BMP Entity Bean instances. I've created a simple app which lets me read a BMP Entity Bean through a Session Bean. I would expect that when I call findByPrimaryKey on my Entity Bean's home interface, Orion caches the instance it creates so that next time I call findByPrimaryKey for the same key, it just returns the instance it already has rather than creating a new one. However, it appears that it goes to the database (i.e. calls ejbFindByPrimaryKey in the Entity Bean's implementation) for every call to findByPrimaryKey, regardless of whether it has previously read the instance with the specified key before. I checked the list archive and it appears that someone has reported a similar problem a while back but there were no replies (http://www.mail-archive.com/orion-interest@orionserver.com/msg17359.htm l). I also checked the documentation and for orion-ejb-jar.xml it states that exclusive-write-access is true by default, and since I am not setting it I presume it's defaulting to true which should allow Orion to cache the entity beans. So, can anyone shed any light on how whether/how I can get Orion to cache BMP entity beans? Cheers Geoff
