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
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
SV: IronFlare bug fixing policy
Your bug report 596 seems to be the same bug reported as bug 670. This bug is resolved, although a build containing the fix is not yet available. WR -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: Multiply datasources for one application??
We have configured data-sources.xml to point to multiple sources, the code references the relevant ejb-location value as a JNDI lookup. This works for Entity Beans and direct JDBC. Entity beans use the setEntityContext method to reference the corect source. They can also use the entity-deployment data-source= attribute in orion-ejb-jar.xml. If you are using an automatically generated one, be careful that it is referencing the correct source. -Justin -Original Message- From: The elephantwalker [mailto:[EMAIL PROTECTED]] Sent: 15 January 2002 23:48 To: Orion-Interest Subject: RE: Multiply datasources for one application?? Mike, You can use different data-sources by using a different location name for each data-source. You need to make sure that each data-source within your data-sources file has a distinct location name. You apps can use different data-sources.xml by including the data-sources.xml path in your orion-application.xml of your ear. This way you can have more than one ear, each with its own data-sources.xml. Regards, the elephantwalker www.elephantwalker.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, January 15, 2002 10:57 AM To: Orion-Interest Subject: Multiply datasources for one application?? Hi everyone, if there is anyone that can give me a hand I would really appreciate it. My Problem is that I have an application developed using orion and I works great but we are trying to set up multiply test environments using different database instances. My questions is can you set up one application with multiply datasources and if so how do you go about setting it up. We tried to set it up with different datasource declarations in one datasource but it always reads the last datasource declaration into the driver manager. Please help if you can, Thanks. Mike
pls help register EJB in web app
Hello guys , asking
for some help ...I get this error:"Error instantiating web-app JNDI-context: No location
specified and no suitable instanceof the type 'yp.ypSession' found for the ejb-ref
yp.ypSession"
1) I have this
EJBworking well from standalone app
2) When I try to use
it in simple JSP page , that I placed in default-webapp directoryI get the
error above/*this is how I look it up*/Object homeObject =
context.lookup("java:comp/env/yp.ypSession");
Can this be because beans are
registeredin a separate application andI try to get them from
another(default) application ?This
is web.xml contents of my default-web app
where this jsp page resides
ejb-ref
ejb-ref-nameyp.ypSession/ejb-ref-name
ejb-ref-typeSession/ejb-ref-type
homeyp.ypSessionHome/home
remoteyp.ypSession/remote
/ejb-ref
j_security_check not found
Hi list, Recently, I have updated to 1.5.2, and sometimes I get the error: 404 Not found with the URL /myapp/j_security_check. To re-create the problem: 1. Work on the application 2. Log out 3. The app must show you the initial login form 4. Restart orion 5. Type your login and password, and submit the form 6. You got it! 404 Not Found 7. Go to the starting page (protected with login form) 8. Orion shows the login form 9. Fill in the login form, and submit it 10. OK. You can work in the app. The problem is that some of our apps call j_security_check directly to validate users, but it seems this is not possible with orion 1.5.2 (it worked with previous versions) Thanks in advance. Greetings. -- ·· Juan Fuentes Nieto Essi Projects [EMAIL PROTECTED]t +34 977 221 182 http://www.essiprojects.com f +34 977 230 170 ··
remove
remove -- __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
MQSeries MDB Sample
I wanted to write an MVS Batch COBOL program that updates an MVS (OS/390) MQSeries queue and have it trigger a MDB on an Orion server. To do this, my MVS MQSeries has a remote queue definition pointing to an NT Server running MQSeries and Orion 1.5.2. Next I followed the Resource Providers documentation on www.orionserver.com and used the ContextScanningResourceProvider without any changes to be my MQSeries resource provider. I compiled this class and created a jar file, which I added to Orion/Lib, along with the various IBM MQSeries jars and the Sun JNDI File System provider jars. I then made the necessary Orion xml file updates and to my amazement it works. I can update an MVS MQSeries queue and have it trigger a Orion MDB on an NT server. The zip file contains all source code. mdb_orion_jms.ZIP Below is the sample output from the Orion DOS prompt. I tried writting to the MDB queue via a jsp = servlet = SLSB and from an MVS Batch COBOL program. Auto-unpacking C:\TEMP\orion\applications\mdb-orion.ear... done. Auto-unpacking C:\TEMP\orion\applications\mdb-orion\mdb-orion-web.war... done. Auto-deploying mdb-orion-web (Assembly had been updated)... Auto-deploying mdb-orion-ejb.jar (ejb-jar.xml had been touched since the previou s deployment)... done. Orion/1.5.2 initialized Auto-deploying ejb - servlet mdb test (Assembly had been updated)... SampleBeanSLSB: message = msg via jsp to servlet InitialDirContext ctx done: javax.naming.InitialContext@470b0d ctx QCF done: com.ibm.mq.jms.MQQueueConnectionFactory@bd614064 queueFactory.createQueueConnection() done: com.ibm.mq.jms.MQQueueConnection@3ef361 queueConnection.createQueueSession() done: (Queue)ctx.lookup() done: queueSession.createSender(queue) done: queueSession.createTextMessage() done: message.setText(msg) done: queueSender.send(queue, message) done: Bean got message: msg via jsp to servlet queueConnection.close() done: Bean got message: TEST MVS-TO-NT TALKING mdb_orion_jms.ZIP Description: Binary data
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-
Caching / Pooling of BMP Entity bean.
Hi, I am getting a weird error. I am using oracle oc4j 1.0.2.2. I am calling an entity bean from session bean. The error I get is when I call an entity bean for the first time it gives me proper result then I update the data and from next call onward it gives me the cached value that it loaded for the first time call. It even doesn't give me stored value. I try to trace it but I get the same error. From database it is retrieving proper value while doing ejbFindbyPrimarykey but doesn't give proper value. It never again call ejbload. That what I found by tracing it. Any help will be appreciated. Thanks -Ritesh
REMOVE
REMOVE
Lookup EJB's in another application
Hi, If you have two applications in the same orion container. One application with web components and another with just EJB's. From the application with web components, I want to lookup an EJB that is deployed in the other application - is that possible via the InitialContext or do I have to call it via an URL and getting the extra RMI call? I can get it to work using a provider URL to the other application, but using the InitialContext, the local context - it cannot find the bean, or more correct, the JNDI name could not be found. Any help is appreciated ! Thanks, Patrik __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
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 **
Re: Caching / Pooling of BMP Entity bean.
it's probably your code. BMP caching works no problem. your best bet is to post a code example of one of your entity beans. - Original Message - From: Shah, Ritesh [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Thursday, January 17, 2002 8:02 AM Subject: Caching / Pooling of BMP Entity bean. Hi, I am getting a weird error. I am using oracle oc4j 1.0.2.2. I am calling an entity bean from session bean. The error I get is when I call an entity bean for the first time it gives me proper result then I update the data and from next call onward it gives me the cached value that it loaded for the first time call. It even doesn't give me stored value. I try to trace it but I get the same error. From database it is retrieving proper value while doing ejbFindbyPrimarykey but doesn't give proper value. It never again call ejbload. That what I found by tracing it. Any help will be appreciated. Thanks -Ritesh
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 **
