Re: HttpServletRequest.isUserInRole() and Orion
Peter, I'd recommend you check out OSUser at www.opensymphony.com. It is very good for doing custom user management for not only orion, but other app servers. -Pat - Original Message - From: Peter van Rensburg [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Tuesday, April 02, 2002 7:34 PM Subject: Re: HttpServletRequest.isUserInRole() and Orion Oops :) Missed the inner class inside SimpleUserManager, ignore comments about missing methods in Orion interfaces, doh! :) On Tue, 2002-04-02 at 14:30, Peter van Rensburg wrote: Hi I'm putting together a customer user manager for orion, extending com.evermind.security.AbstractUserManager, with UserWrapper and GroupWrapper classes implementing com.evermind.security.User and com.evermind.security.Group respectively. Now HttpServletRequest.isUserInRole() used to call User.isMemberOf() back in the days of = 1.4.0, this however does not seem to be the case anymore. isMemberOf() still gets called to satisfy the security-constraints in web.xml. Looking at the example on orionsupport.com, three abstract methods are mentioned: protected boolean userExists( String username ); protected boolean checkPassword( String username, String password ); protected boolean inGroup( String username, String groupname ); It doesn't appear that HttpServletRequest.isUserInRole() gets trunked through to inGroup() nor do I see these three methods in any Orion interface definition ? Does anyone know how to fix this? Or how HttpServletRequest.isUserInRole() gets handled by Orion ? I've search the mailing list archive and it seems that other users have also encountered these problems but it never got sorted out ? Many thanks for any assistance, Peter
Re: Cascade delete for CMP set mapping?
Cascade deletes aren't supported in Orion (yet), but I hear they should be soon. Hang tight :) -Pat - Original Message - From: Chris Turner To: Orion-Interest Sent: Tuesday, February 12, 2002 6:34 AM Subject: Cascade delete for CMP set mapping? Hi Everyone, I've got a CMP entity bean that manages a set of simple object via Orion's proprietary set-mapping features. It all works fine and the table holding the items in the set is updated and read correctly. The problem comes with deleting. If I delete the bean (by calling remove(pk) on the home interface) the data from the entity table goes, but the data in the table for the set items remains. Is this expected behaviour? I was expecting Orion to cascade delete this data! How do I makeOrion do a cascade delete of the table for the managed set? Or do I need to add a rule to the database to force it to do the cascade delete? My Orion version is 1.52 Chris _Alison AssociatesThe information contained in this e-mail and any attached files is intended only for the use of the person(s) to whom it is addressed and may be privileged, confidential and exempt from disclosure under applicable law. The views of the author may not necessarily reflect the views of the Company. If you are not the intended recipient please do not copy or convey this message or any attached files to any other person but delete this message and any attached files and notify us of incorrect receipt via e-mail to [EMAIL PROTECTED] _This message has been checked for all known viruses by MessageLabs.
Re: What is a Dirty Connection (using -Djdbc.debug=true)
I don't see how this helps with your question at all. You were asking about CMP, and he is talking about BMP. I too have the problems you are encoutering with CMP and stale connections being left over. I'd love to hear of solutions to this problem. -Pat - Original Message - From: Jeff Hubbach [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Tuesday, January 29, 2002 8:25 AM Subject: Fw: What is a Dirty Connection (using -Djdbc.debug=true) I'm forwarding this on to the list as it was very helpful with regard to my question, just incase anyone else has the same questions. Thanks, Avi. Jeff. Begin forwarded message: Date: Tue, 29 Jan 2002 08:50:25 +0200 From: Avi Abrami [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: What is a Dirty Connection (using -Djdbc.debug=true) Hi Jeff, I'm not subscribed to the Orion-Interest mailing list, but I monitor it through the OrionServer website. I hope you don't mind that I am answering you via a direct eMail. This is what I know about dirty connections. (Note that you may already know some of what I am about to tell you, I hope that's OK with you.) Orion wraps the JDBC driver classes. It seems to me, from debug messages displayed by the server, (but I haven't verified this yet) that Orion uses different wrapper classes depending on whether the server is running in debug mode or regular mode. I have had my application crash when running in debug mode, but work properly when working in regular (as in non-debug) mode. As far as I can ascertain, a dirty connection is one that has an associated open Statement or ResultSet or PreparedStatement, etc. object. I have found that the only way to properly close a Connection is to first close the ResultSet object, then the Statement object and finally the Connection object. Note that I am only working with the Oracle JDBC driver that comes with OC4J (and my version is 1.0.2.2 -- on SUN Solaris 2.7) Further, the following methods from the JDBC API do not work correctly (when using Orion's JDBC wrapper classes): ResultSet.getStatement() Statement.getConnection() These methods execute normally -- they don't throw exceptions at runtime and they compile without an problems. However, it seems like they do nothing! Basically a dirty connection means you have database resources (like Statement objects or ResultSet objects) still lying around -- which need to be disposed of (or closed). This is sort of like a memory leak, because eventually the Oracle database will exhaust all its resources and throw SQLExceptions in your application. The only way I found to properly close these database resource associated objects (Connection, Statement, ResultSet, etc) was to hold on to the references after I created the objects and only use those references to close those objects. So if, for example, you open a Connection in one method and that method returns a ResultSet to a calling method, the calling method will not be able to close the Connection unless you also pass a reference to the Connection to the calling method. Also note, that the Oracle JDBC driver also does not correctly implement the Connection.close() method. According to the API documentation, closing a Connection is supposed to also close any associated Statements, ResultSets, etc. However, the Oracle JDBC driver does not. You need to explicitly close the ResultSet, then the Statement, then the Connection. So in summary, I will answer your questions individually now with a short answer, below: Q:What is a Dirty Connection (when using -Djdbc.debug=true)? A:A connection with unclosed resources lying around. Q:What causes it? A:Not explicitly closing the resources. Q:What repercussions does it have? A:It can crash the database server. Q:Is a Dirty Connection a bad thing? A:Yes. Q:What can we do to avoid it (if anything)? A:Explicitly close all resources -- ResultSets, Statements, etc. Q:Are there any settings that control when and if they are cleaned up? A:If you are using pooled connections, perhaps the inactivity-timeout attribute in the data-sources.xml file can help -- I don't know for sure. Q:Are they cleaned up at all? A:As far as I can tell, no. A very long post -- I hope you don't mind, and I hope it can help you. Good Luck, Avi. -- Jeff Hubbach Internet Developer Sun Certified Web Component Developer New Media Division ITQ Lata, L.L.C. 303-745-4763 x3114
Re: What is a Dirty Connection (using -Djdbc.debug=true)
Yes, sounds like Orion isn't closing the Statements and ResultSets that it uses for CMP, instead it is just closing the Connection. If that is the case, either an update in the Oracle JDBC driver or an update with Orion would fix the bug. Let's hope one of the two comes out soon, because how it is now is very bad. -Pat - Original Message - From: Jeff Hubbach [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Tuesday, January 29, 2002 2:10 PM Subject: Re: What is a Dirty Connection (using -Djdbc.debug=true) Patrick, It helped in that noone else responded, and it points to the fact that something, either a statement or result set, isn't getting closed (if container-managed connections are dealt with the same as user-managed connections, which I'm assuming is true). I agree with you that he's talking about BMP, but the underlying connection stuff should be the same (except for the fact that the container is handling it instead of us, in which case you'd think it would be sure to close everything, but it doesn't look like it is). Some suggestions have been to move from CMP to BMP, but in my opinion that's taking a step backwards. It sounds like there's a problem in the container's handling of connections, but we have yet to hear anything from anyone with any code-level knowledge of Orion. Magnus, is this an issue? and if so, is it going to be fixed in Orion 1.5.4, and if so, when will we see it? Jeff. On Tue, 29 Jan 2002 11:28:18 -0800 Patrick Lightbody [EMAIL PROTECTED] wrote: I don't see how this helps with your question at all. You were asking about CMP, and he is talking about BMP. I too have the problems you are encoutering with CMP and stale connections being left over. I'd love to hear of solutions to this problem. -Pat - Original Message - From: Jeff Hubbach [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Tuesday, January 29, 2002 8:25 AM Subject: Fw: What is a Dirty Connection (using -Djdbc.debug=true) I'm forwarding this on to the list as it was very helpful with regard to my question, just incase anyone else has the same questions. Thanks, Avi. Jeff. Begin forwarded message: Date: Tue, 29 Jan 2002 08:50:25 +0200 From: Avi Abrami [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: What is a Dirty Connection (using -Djdbc.debug=true) Hi Jeff, I'm not subscribed to the Orion-Interest mailing list, but I monitor it through the OrionServer website. I hope you don't mind that I am answering you via a direct eMail. This is what I know about dirty connections. (Note that you may already know some of what I am about to tell you, I hope that's OK with you.) Orion wraps the JDBC driver classes. It seems to me, from debug messages displayed by the server, (but I haven't verified this yet) that Orion uses different wrapper classes depending on whether the server is running in debug mode or regular mode. I have had my application crash when running in debug mode, but work properly when working in regular (as in non-debug) mode. As far as I can ascertain, a dirty connection is one that has an associated open Statement or ResultSet or PreparedStatement, etc. object. I have found that the only way to properly close a Connection is to first close the ResultSet object, then the Statement object and finally the Connection object. Note that I am only working with the Oracle JDBC driver that comes with OC4J (and my version is 1.0.2.2 -- on SUN Solaris 2.7) Further, the following methods from the JDBC API do not work correctly (when using Orion's JDBC wrapper classes): ResultSet.getStatement() Statement.getConnection() These methods execute normally -- they don't throw exceptions at runtime and they compile without an problems. However, it seems like they do nothing! Basically a dirty connection means you have database resources (like Statement objects or ResultSet objects) still lying around -- which need to be disposed of (or closed). This is sort of like a memory leak, because eventually the Oracle database will exhaust all its resources and throw SQLExceptions in your application. The only way I found to properly close these database resource associated objects (Connection, Statement, ResultSet, etc) was to hold on to the references after I created the objects and only use those references to close those objects. So if, for example, you open a Connection in one method and that method returns a ResultSet to a calling method, the calling method will not be able to close the Connection unless you also pass a reference to the Connection to the calling method. Also note, that the Oracle JDBC driver also does not correctly implement the Connection.close() method. According to the API documentation, closing
Re: Best way to add user records to EJBUserManager...
Instead of coding to EJBUserManager directly, I would highly recommend you check out OpenSymphony's OSUser module. It is an abstracted user management layer that works with Orion, Jboss, and Resin, and soon Weblogic, Websphere, and JRun. Using OSUser will truly make your application work on any J2EE application. -Pat - Original Message - From: Alex Paransky [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Monday, January 07, 2002 9:43 PM Subject: Best way to add user records to EJBUserManager... I am using EJBUserManager for security in Orion. What is the best way to update users? Should I directly use EJBUser EJB or use the API's in the UserManager. If UserManager is the answer, then how do I get access to it while running in Orion? Thanks -AP_
RE: [orion-interest]EJB2.0 spec or implementation?
Might I recommend xdoclet then? xdoclet.sourceforge.net At 12:20 PM 12/28/2001 -0800, Aaron Tavistock wrote: I'm fairly sure that the SQL-92 spec calls for case insensitive column names (but don't quote me on that cause I'm not 100% sure). Also, since I'm in a UNIX shop switching to Microsoft is not really an option (even *if* I wanted to) - but thats not really the point. More importantly, I'm aware I can change the post-deployment descriptor created by Orion but thats a major pain-in-da-behind if I'm doing development and want to redeploy several times. When I've tried putting an partial orion-ejb-jar.xml into the package, its never worked right, implying that I need to copy a previously deployed version to modify - again extremely cumbersome. I was hoping that there was some way to do this without slicing up the post-deployment orion generated files. -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED]] Sent: Friday, December 28, 2001 10:26 AM To: Orion-Interest [EMAIL PROTECTED]; Aaron Tavistock Subject: Re: [orion-interest]EJB2.0 spec or implementation? On 28/12/01 12:56 pm, Aaron Tavistock [EMAIL PROTECTED] wrote: So heres the story - database field names are case insensitive, so common parlance for representing a space is an underscore (e.g. 'this_field'). Nope. MS SQLServer is not case insensitive. You could always tweak orion-ejb-jar.xml to map it to whatever column names your heart desires
Re: SV: MDB in orion 1.5.2 using Queue
Magnus, I created my own resource provider for Tibco JMS and it would work, but only for the Queue/Topic returned by getDefaultResource() (can't remember the exact method name off the top of my head). Anyway, my orion-ejb-jar.xml would like like: message-driven-deployment name=MyMessageDriven My queue would be located at java:comp/resource/TibcoProvider/myQueue But if I put in my orion-ejb-jar.xml file the complete signature, (jms/MyQueue), my MDB can't locate the proper queue/connection factory. It appears that jms/MyQueue would imply that the root of the lookup must take place at java:comp/env, which is a sibling to java:comp/resource. My JNDI knowledge is very limited, so if you can explain to me how I can specify which queue to use with my resource provider, that would be great! message-driven-deployment cache-timeout=60|never connection-factory-location=jms/MyQueueConnection destination-location=jms/MyQueue max-instances=50 min-instances=5 name=MyMessageDriven -Pat At 10:41 AM 10/19/2001 +0200, you wrote: Hi. 1) In 1.5.3 Orion will tell you if you havent implemented MessageDrivenBean and MessageListener in your MDB. 2) Orion will use the default JMS resource if you dont specify a destination-location etc in orion-ejb-jar.xml. ResourceProviders, made public in 1.5.2, lets you use 3rd party resources in a very simple way. A document on this issue is in progress and will be released shortly, with examples, samples and details. A MDB document is also in progress, but other documents have higher prio right now. WR -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]För Romen Law Skickat: den 19 oktober 2001 03:39 Till: Orion-Interest Ämne: RE: MDB in orion 1.5.2 using Queue ello, Thanks for all the replies. I must apologise: my MDB using Queue was working all along. It's just that I was using System.out.println() for logging so I couldn't see it on the console. But after using log4j I could see it. Well, there is first time for everything. I did find two things though: 1. someone posted before saying that in Orion you should not make MDB implement MessageListener, otherwise it will not work. I found that to be false. 2. I still do need to modify the destination-location in orion-ejb-jar.xml. If I don't it still works provided that I only have one Queue or Topic defined in jms.xml. Orion seems to use that one disregarding the queue name you specify in the sender. cheers romen
Re: What's in 1.5.3?
You can find the new orion.jar in 'private'. That's all I'll say... It will be released very soon I'm sure. I haven't found any changes.txt file though, so I can't tell you what is new. -Pat At 05:52 PM 10/9/2001 +0200, you wrote: Hi, Since 1.5.3 is in beta, is there anywhere where we can find a list of the changes that will be present in 1.5.3? Where is 1.5.3 in beta?
Re: Server sometime stop responding (prompt of server is freezed)
Yes, you are probably running windows and had some text in the command prompt screen selected. Windows locks up all processes run from that windows if text is selected. Pressing enter will also unfreeze this. My suggestion: be careful with what you select :) -Pat At 12:02 PM 8/6/2001 +0200, you wrote: hi, I have an application on an orion server who stop responding for unknown reasons. But I have no way to find what's is wrong. A CTRL-C comand make it go again (not stop and restart, just unfreeze the prompt ) Does any know why, and how to fix it? -- Decornet Christophe Ingénieur Développement Tel :01.44.97.71.44 Société Fluxus 28/30 rue du chateau des rentiers 75013 Paris
Re: cmp and saving a file to a blob
Yeah, the IO might work, except that it violates the spec. Doesn't really hurt orion, but makes your EJBs not very distributable, since they have to be on the same machine where the files are stored. I wrote a simple RMI server that sits on the file server and receives a byte[] from EJBs. Then you can put the EJBs wherever, and not worry about being tied to the file system. No, there is nothing wrong with using a blob either, might be a big slower too. And going with RMI, you could make things more optimized (like having a key and then emulating streaming across the network). Then you could find a middle group between network traffic and memory bandwidth on the VM. Sending one byte at a time a million times is SLOW, but sending a byte[100] will kill your server. Doing it with RMI will let you find that middle ground, doing it with BLOBS will require you to load up the entire file in to memory all at once. -Pat At 11:51 AM 7/23/2001 -0600, Nick Newman wrote: Two part answer ... 1) Another possible option is to make up a unique file name, and write the file to that. Keep the name of the file (plus mime type, etc) in the EJB. The getFile and setFile methods would read/write to this file. You could use the ejbRemove method to delete the file. (And perhaps you will need other code to keep the files consistent with the DB). This is not so pretty in some ways (you have extra things to keep straight) but it avoids the need for anything special in the DB. Then again, perhaps this violates the strict specs about use of file IO in an EJB? In any case, this is what I have (successfully) used. 2) I don't think there's any reason you couldn't use BLOBs. The specs don't include them, but the specs don't even assume you have a database, do they? Nick At 10:06 AM 7/23/01 -0700, you wrote: Problem, persisting a downloaded file in a cmp ejb. Has anybody solved this problem? It seems like this is a problem not solved by the specification. A plan of attack: 1. web user uploads file through a form. 2. servlet processes file as an ArrayList of bytes with Nick Newman's servlet (www.orionsupport.com/articles/downloads/UploadServlet.zip) with some modifications. 3. file (now a List) is a member of a cmp bean with a list type Byte. If we use this method, each byte is stored in a separate table. Kindof ugly. Talk about a large table! B plan of attack: 1. web user uploads file through a form. 2. servlet processes file as a byte array with Nick Newman's servlet (www.orionsupport.com/articles/downloads/UploadServlet.zip). 3. A class called FileBytes is created which implements Serializable, the only member is the byte array. 4. A cmp ejb with members mimetype, name, datetime, and filebytes. Both of these methods require no hacking of the orion-ejb-jar.xml. We would have to be satisfied with sql type long raw for most databases, however, since the ejb spec doesn't include blobs. This means a limit of 2 GB...not enough for a movie, but plenty large enough for anything else. Obviously we should limit the size of the file, since all of the bytes have to be in memory. Otherwise, we can break up the persitance into many 1 MB ejb's, each with part of the file. This way, we don't have to have the file all in memory at once. If anybody has done this, let me know. I would like to hear some comments, also. I will keep you posted on my experiences. Regards, the elephantwalker
RE: best way to build a link to work in different deployment configurations??
Or, to abstract one step further, just have a url tag: img src=taglib:url url=/images/foo.gif/ a href=taglib:url url=/index.html/ webwork has a tag that does exactly this. It's also a very nice framework... check it out. -Pat At 08:39 AM 7/20/2001 -0700, elephantwalker wrote: Another solution is to create a usr tld/tag for img user:img src=/images/logo.gif / regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Brian Thompson Sent: Friday, July 20, 2001 8:02 AM To: Orion-Interest Subject: best way to build a link to work in different deployment configurations??. I have an application that during development is deployed multiple times with the following... http://devwebsite/customerApp1 http://devwebsite/customerApp2 In production, I'd like to deploy the applications as... http://customerApp1 http://customerApp2 In the first case file references would look like the following img src=/customerApp1/images/logo.gif while in the second case it should be img src=/images/logo.gif My question is what is the best way to handle file references (links, images, etc) within the application to support both deployments. We could use the request.getContextPath() as a prefix to all file references img src=%=request.getContextPath()%/images/logo.gif but to do this across an entire application seems like extra overhead. It seems like there should be a more elegant solution. I've scoured the orion doc to see if there is a way to do this through configuring websites and webapps, but with no success. Has anyone discovered a better way?? Thanks.
Re: deployment
What happened is that you rebuilt the ejb-jar-ic.jar file incorrectly. Unjar the original jar (from the deploytool) and then unjar your new jar. You'll notice they product different directory structures. -Pat At 02:17 PM 7/17/2001 -0400, you wrote: If this question has been posted before please direct me to the archive location. I did not find any reference to this problem. I am using Sun's deploytool to create an ear file that I want to deploy in orion. The application deploys without difficulty with the deploytool and Sun's default j2ee server. (we're using jdk1.3.1 and j2sdkee1.3) On my first try to deploy with Orion, I get the following error message, Illegal use-caller-identity value, legal values are True and False.. So I viewed the ejb-jar.xml file and found that the tag had no value. Because the error msg gave me values I put 'False' in the tag and saved the file. Next I rebuilt the jar file with the modified ejb-jar.xml and then rebuilt the ear file. I tried this with jar and winzip. Now on to try and deploy with Orion again, and this time I get the error message, Unable to find/read assembly info for C:\temp\secondejb/mod-secondejb.ear/ejb-jar-ic.jar (META-INF/ejb-jar.xml) What has happened? Thank you, Jeanne
RE: Orion Bug or not?
Well, after some more hacking I narrowed it down to a simple test case, and
it is now posted as bug #433 on orion's bugzilla. Take a look and let me
know what I did wrong, I'm sure it isn't a bug with orion and i'm just
being dumb. :-)
-Pat
At 10:58 AM 5/4/2001 +0200, Douma, Ate wrote:
I think your problem has not so much to do with your example but more how
Orion implemented their console output handling.
This happens when to make the console output window active and have some
sort of interaction with it (a mouse click within it etc.). The output
stream handling seems to be blocking for Orion and only after you press a
key within the console window the application server will continue with its
(pending) operations.
I'm not sure if I would call it a bug but it certainly is anoying.
If you want something to be done about you could enter it as a problem in
Bugzilla.
-Original Message-
From: Patrick Lightbody [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 04, 2001 7:15 AM
To: Orion-Interest
Subject: Orion Bug or not?
I have a test.jsp file that is calling a class DocumentDelegate:
%
// 2304 is a test document
DocumentDelegate dd = new DocumentDelegate(2304);
dd.doAction(1, null, plightbo);
// this action is supposed to throw an exception
// because the action, 1, is not allowed right now
%
DocumentDelegate.doAction() in turn calls a session bean:
DocumentMgr.doAction(long docId, int action, Hashtable
params, String userId)
{
try {
Workflow workfow = new TACWorkflow();
workflow.action(docId, action, userId, params);
} catch (Exception e) {
throw new EJBException(e.getMessage());
}
}
In turn, the code in workflow.action() is doing:
throw new EJBException(This workflow step can't be called
right now);
--
Now that I got that out of the way... when I hit test.jsp on
the browser,
the exception shows up on the browser and I can see the
transaction.log
show up in the console. But... if I hit the page again with
the browser,
nothing happens at all. No transaction logs, no System.out.println()
statements, nothing. I have to click stop on the browser.
When I click
reload, now TWO transactions (and System.out.println())
statements show up
(this one and the last one). What is going on here?
I changed workflow.action() to just return; instead of throwing an
EJBException, then the transactions take place as they should
and the print
statements show up as they should. I tried chaning
EJBException to other
exceptions, and the same problem occurs. Why would a thrown
Exception cause
this behavior?
To recap: test.jsp calls class DocumentDelegate, which calls
DocumentMgr
session bean, which in turn loads up a class TACWorkflow and
calls a method
there.
-Pat
PS: this happens in 1.4.5 and 1.4.8
RE: Backward compatibility
Well, my first post (I finally coerced the mailing list to let me subscribe): get the latest version of jaxp.jar from java.sun.com. I had this problem when upgrading 1.4.5 to 1.4.8. I didn't get the problem when upgrade a clean copy of 1.4.5 to 1.4.8 though. Good luck! -Pat At 09:18 AM 5/3/2001 +0200, PHiL wrote: Humm... I just autoupdate from 1.4.7 (application was OK before) to 1.4.8. Orion doesn't start, here is the only trace I see: javax.xml.parsers.FactoryConfigurationError: com.sun.xml.parser.DocumentBuilderF actoryImpl at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderF actory.java:80) at com.evermind._yw.getJavaxDocument(Unknown Source) at com.evermind.xml.XMLUtils.getDocument(Unknown Source) at com.evermind.xml.XMLConfig._iw(Unknown Source) at com.evermind.xml.XMLConfig._iw(Unknown Source) at com.evermind._kh.run(Unknown Source) at java.lang.Thread.run(Thread.java:484) at com.evermind._jw.run(Unknown Source) It even do not tried to deploy something... Sounds like an XML trouble, you are rigth! Any idears to fix this ??? Thanks, Philippe PAGET. -Message d'origine- De : Mike Cannon-Brookes [mailto:[EMAIL PROTECTED]] Envoyé : jeudi 3 mai 2001 05:26 À : Orion-Interest Objet : RE: Backward compatibility In what way? I'm having no problems. The only possible problem area is XML (but only if you've coded your software to use Xerces directly - which is bad ;)) -mike Mike Cannon-Brookes - Technology Director, Asia Pacific internet.com Corporation - The Internet Industry Portal Ph: (612) 9290 1088 - Mob: 0416 106090 - The Media Network @ http://australia.internet.com - Meet A Guru @ http://www.breakfastforums.com.au - Subscribe Online @ http://www.enewsletters.com.au -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Adam Cassar Sent: Thursday, May 03, 2001 12:37 PM To: Orion-Interest Subject: Backward compatibility Orion 1.4.8 not backward compatbile with at least 1.4.7? Anyone else experience this problem? -- Adam Cassar Technical Development Manager ___ NetRegistry http://www.netregistry.au.com Tel: +61 2 9641 8609 | Fax: +61 2 9699 6088 PO Box 270 Broadway NSW 2007 Australia
Orion Bug or not?
I have a test.jsp file that is calling a class DocumentDelegate:
%
// 2304 is a test document
DocumentDelegate dd = new DocumentDelegate(2304);
dd.doAction(1, null, plightbo);
// this action is supposed to throw an exception
// because the action, 1, is not allowed right now
%
DocumentDelegate.doAction() in turn calls a session bean:
DocumentMgr.doAction(long docId, int action, Hashtable params, String userId)
{
try {
Workflow workfow = new TACWorkflow();
workflow.action(docId, action, userId, params);
} catch (Exception e) {
throw new EJBException(e.getMessage());
}
}
In turn, the code in workflow.action() is doing:
throw new EJBException(This workflow step can't be called right now);
--
Now that I got that out of the way... when I hit test.jsp on the browser,
the exception shows up on the browser and I can see the transaction.log
show up in the console. But... if I hit the page again with the browser,
nothing happens at all. No transaction logs, no System.out.println()
statements, nothing. I have to click stop on the browser. When I click
reload, now TWO transactions (and System.out.println()) statements show up
(this one and the last one). What is going on here?
I changed workflow.action() to just return; instead of throwing an
EJBException, then the transactions take place as they should and the print
statements show up as they should. I tried chaning EJBException to other
exceptions, and the same problem occurs. Why would a thrown Exception cause
this behavior?
To recap: test.jsp calls class DocumentDelegate, which calls DocumentMgr
session bean, which in turn loads up a class TACWorkflow and calls a method
there.
-Pat
PS: this happens in 1.4.5 and 1.4.8
