Re: Stored procedures and J2EE
I'm interested as to how you cansay this... we just did a series of tests here to see what the effect of pulling out some fairly complex stored procedures into CMP beans, and the performance impact was enormous. We've actually gone the other way, that is, developing stored procedures for each anticipated database. The fallback is that the logic is done in the beans, but that is a worst-case scenario. Now, I realize that this would be considered such bad form in a Sun-controlled world of pure J2EE that I hesitate to even mention it... but in the real world, any significant hit on performance is enough to convince us to denormalize a bit, so to speak. I don't think that you can say "there's absolutely no hit on performance" not to use stored procedures, particularly if that procedure requires repeated queries of the data in a pseudo-recursive way. Do you really think that any performance hit that we've seen is a result of poor design? I'm really interested in your reasoning. Rian - Original Message - From: The elephantwalker To: Orion-Interest Sent: Thursday, September 06, 2001 2:23 AM Subject: RE: Stored procedures and J2EE As for distributing your business logic between the datastore and middle tier...aren't you making your life more complex than it needs to be? There is absolutely no hit on performance if you pull out all of your business logic into a slsb or cmp...there's just no need to use store procedures any more.
Re: How to run Jetspeed (Open Source Enterprise Portal) on Orion
Hi Steve, I hate this kind of I had that too follow-up, but in this case, it's probably relevant... I had that too. I got *exactly* the results that you did, and then we gave up since we were actually trying to get a project done. Please do keep us up-to-date if you learn anything. Rian - Original Message - From: [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Monday, August 13, 2001 6:59 AM Subject: How to run Jetspeed (Open Source Enterprise Portal) on Orion Hi, I've already posted this, but I've had no response so I'm giving it another go. I'd really appreciate it if some of the Orion experts here could give this a try. It only takes 10-15 minutes to duplicate the problem and the solution is probably obvious to everyone but me. I took the following steps in order to run Jetspeed within Orion. The installation was easy, but I am receiving an error when trying to access the portal that doesn't happen under other servlet containers. Jetspeed is an Enterprise Information Portal and is freely available. It is available from the Jakarta project as open source. It is distributed as a WAR file archive here: http://jakarta.apache.org/builds/jakarta-jetspeed/release/v1.3-a1/Jetspeed-1 .3a1-war.zip http://jakarta.apache.org/builds/jakarta-jetspeed/release/v1.3-a1/Jetspeed-1 .3a1-war.tar.gz and it is also distributed in source form here: http://jakarta.apache.org/builds/jakarta-jetspeed/release/v1.3-a1/Jetspeed-1 .3a1-src.zip http://jakarta.apache.org/builds/jakarta-jetspeed/release/v1.3-a1/Jetspeed-1 .3a1-src.tar.gz I installed the WAR file into the Orion default web application as a quick way to deploy it to see how well it runs under Orion. First, I shut down Orion. Being a development machine, I can avoid needing to hot-deploy. I then followed Joseph Ottinger's instructions for adding a web application to the default web site: http://www.orionsupport.com/articles/addwebapp.html Specifically, I added the following line to $ORION/config/application.xml: web-module id=jetspeed path=/home/smeacham/Jetspeed-1.3a1/jetspeed.war / I also added the following line to $ORION/config/default-web-site.xml: web-app application=default name=jetspeed root=/jetspeed/ / I then started Orion again and the application auto-unpacked just fine. I then tried to access Jetspeed with a browser: http://localhost/jetspeed/ Orion gives a 403 forbidden error, saying that directory browsing is not allowed. I suppose that Orion doesn't use the index.jsp by default. I then tried to access index.jsp directly: http://localhost/jetspeed/index.jsp Orion then returned a 500 Internal Server Error. By looking at the logs, I noticed an exception being thrown about a properties the Turbine Resource File not being found. Since the path to the file looked wrong (the jetpeed/WEB-INF path didn't have the slash), I added one by editing jetspeed/WEB-INF/web.xml by adding a leading forward slash to the appropriate line (line 19 of 47). Then I tried this address again: http://localhost/jetspeed/index.jsp Everything got much farther along and the log file has a huge amount of logging informaiton from Jetspeed. The end result, however, is another 500 Internal Server Error: Here is the beginning of the exception: java.lang.IllegalStateException: OutputStream already retrieved at com.evermind[Orion/1.5.2 (build 10460)].server.http.EvermindHttpServletResponse.getWriter(Unknown Source) at org.apache.turbine.util.RunData.getOut(RunData.java:280) at org.apache.jetspeed.services.jsp.tags.JetspeedNavigationTag.doStartTag(J etspeedNavigationTag.java:142) at /WEB-INF/templates/jsp/layouts/html/default.jsp._jspService(/WEB-INF/tem plates/jsp/layouts/html/default.jsp.java:129) (JSP page line 19) at com.orionserver[Orion/1.5.2 (build 10460)].http.OrionHttpJspPage.service(Unknown Source) ... I understand what the error seems to be saying. You shouldn't obtain the outputstream from within a JSP. I've spend several hours trying to see what Jetspeed is doing to annoy Orion, but I haven't found it. Could somebody please help out? I'm a veteran developer and have quite a bit of web-based experience as well over the last two years, but I believe that I may have reached the limits of my JSP understanding and experience at this point. I believe that I got very close to getting Jetstream to deploy on Orion. Tis would be a big benefit to the Orion community, having an inexpensive (free) EIP that can be easily downloaded and deployed on our favorite platform. Steven
Re: Container Managed Bean Persistence
Look in the docs for orion-ejb-jar.xml. It's in there. Rian -- Rian Schmidt Fine Brand Media, Inc. Internet Professional Services http://www.finebrand.com/ - Original Message - From: [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Tuesday, July 24, 2001 12:04 PM Subject: Container Managed Bean Persistence Hi all Can someone please tell me how Orion knows what datasource to associate with a container managed entity bean. I follow how to setup container managed fields but I don't understand how to relate it to one of several datasource entries that I have setup. Thanks
Disappearing env-entry-mapping from orion-ejb-jar.xml
Hi, Does anyone have any idea why we would be seeing an env-entry-mapping disappear from orion-ejb-jar.xml upon deployment? There is a stateless session bean that reads a value env-entry-mapping name=databaseTypeMSSQL/env-entry-mapping from a stateless session beans entry in orion-ejb-jar.xml. And upon deployment the first time, it spits out the right value over and over (we're forcing it to read the value each time another bean uses the stateless session bean to read it). But when we restart the server, the bean reports the default value instead of the mapped one. What's more, the entry is completely gone from the orion-ejb-jar.xml file. I can provide more information, but I thought I'd check first if this smacks of anything obvious. Thanks, Rian
Re: JSP page in another window
I do believe you can use the: response.setHeader(Window-target,_blank); approach to do such a thing, but I also recall that it's non-standard, and so you should check it to make sure it works with your target browser. Rian - Original Message - From: Kemp Randy [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Saturday, June 30, 2001 7:14 AM Subject: JSP page in another window If I have JSP page A and I want to open up JSP page B in a seperate and smaller window, while keeping JSP page A, is there a way to do this? I know it can be done with JavaScript. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
findBy referencing another entity reference
Hi all, How about this scenario: There are three entities: manufacturer, model, car (as an example) model knows directly which manufacturer it is, car knows which model it is, but car has to do a model.getManufacturer to find out its manufacturer... OK, so what I wanna know is can I write a findByManufacturer for car? I'd like to be able to do something like this: query="$model.manufacturer = $1" Now, I know that I could specify a sub-query with the actual persistence name of the other entity's thang, something like: query="$model in (select $model from model where manufacturer_id = $1)" but it strikes me that Orion won't know what I'm going on about, and best case, will have to talk to the database each time. Either way, I had to put the persistence name into the orion-ejb-jar.xml file, which is not goodness. Is it possible maybe to say something like: query="model in ($1)" where $1 is a Collection of models taken from ModelHome.findByManufacturer? Any thoughts on the best way to approach this? Thanks, Rian -- Rian Schmidt [EMAIL PROTECTED]
Re: findBy referencing another entity reference
Oh boy... OK, maybe that was a bad example. "Read more about entity beans" is not very useful advice in any case. I just didn't want to explain our business model to ask the question. Try the situation where the top level is Vehicle - Manufacturer - Model or something many-to-many on each layer. My point is that I want to be able to "skip a layer" in the finder. Is that possible? If you don't know, or the answer is no, please just say that or ignore my question and move on. If you have an actual answer or alternative approach that might work, I'd be very appreciative to hear it. For what it's worth, I want to do it this way, as opposed to using some kind of bean-based (logical model) test or pseudo-BMP thing because, due to the volume of "3rd level (in my example)" entities running a findAll on them is performance-limiting and I'd rather not stick SQL directly in my beans. Thanks, Rian -- Rian Schmidt [EMAIL PROTECTED] - Original Message - From: "elephantwalker" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Monday, April 16, 2001 2:54 PM Subject: RE: findBy referencing another entity reference Rian, This is much too sql centric. You should resolve your entity beans around business methods. So I would start off by reading more about entity beans. Theserverside.com, for example has a download on an excellent book for entity beans. As for the sql, you are talking a one to one relationship for the car/model and a one to many relationship for the manufacturer/model. There should be some examples of this on the sun's j2ee site. I know that they specifically discuss this issue. Regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rian Schmidt Sent: Monday, April 16, 2001 2:23 PM To: Orion-Interest Subject: findBy referencing another entity reference Hi all, How about this scenario: There are three entities: manufacturer, model, car (as an example) model knows directly which manufacturer it is, car knows which model it is, but car has to do a model.getManufacturer to find out its manufacturer... OK, so what I wanna know is can I a findByManufacturer for car? I'd like to be able to do something like this: query="$model.manufacturer = $1" Now, I know that I could specify a sub-query with the actual persistence name of the other entity's thang, something like: query="$model in (select $model from model where manufacturer_id = $1)" but it strikes me that Orion won't know what I'm going on about, and best case, will have to talk to the database each time. Either way, I had to put the persistence name into the orion-ejb-jar.xml file, which is not goodness. Is it possible maybe to say something like: query="model in ($1)" where $1 is a Collection of models taken from ModelHome.findByManufacturer? Any thoughts on the best way to approach this? Thanks, Rian -- Rian Schmidt [EMAIL PROTECTED]
Re: Migratingfrom GSP
What the heck, as long as I'm here already... I'd say that you want to look at setting up filters to handle the pre-request action. You can basically catch every request for your site in a filter, make sure that it is appropriate, that sessions and application are set-up right, and even do funky model 2 (request.setAttribute) stuff in there before the actual JSP gets it. Look at: servlet-mapping and filter-mapping in web.xml http://www.orionserver.com/docs/web.xml.html That should cover both pre-JSP action and catchall servlet mapping. The load balancing business is usually pretty implementation specific, so I don't have much to offer there. Rian -- Rian Schmidt [EMAIL PROTECTED] - Original Message - From: "Topher LaFata" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Monday, April 16, 2001 3:12 PM Subject: Migratingfrom GSP Hi all. I am new to the orion/JSP/EJB sort of paradigm. Anyways, I am attempting to migrate a substantially sized GSP(Gnu Server Pages)/JServ application to the Orion platform for evaluation. I have a lot of functionality in place which relies on hooks present in GSP which do not seem to be obviously present in JSP/Orion. Namely when using the JSP facilites of Orion I need hooks into the following: *when the servlet is loaded -it seems that I have to overide the init method of the Orion JSPServlet. HOwever, how do i indicate that my application should use this new subclassed servlet to handle JSP requests? *when the session is created per user -in GSP there is a sessionStart() hook. *when the request is recieved before it is handed to the JSP for further processing. -in GSP there is a requestStart() hook I also have a fair amount of custom code doing session persistence among multiple servers. Is there a particular interface thgat I could wrap my code with so Orion would use this stuff to do its session handling. These are probably stupid questions but I just started looking at JSP/Tomcat/Orion a couple of days ago and I am finding the amount of configuration a bit daunting. Thanks. toph
Re: ORION RISE FROM THE DEAD!
Boy, do I ever second those sentiments. So far, we've had *great* luck with Orion, including CMP EJBs/JSP/taglibs/filters... I've worked with the commercial servers, Enhydra, and jBoss as well, and I really hope that Orion is released into the open-source community if they're going to tank as a business. My impression is that this is a well-written product, particularly in terms of speed. It would be shame to see it disappear. By the way, if some help is needed to host (or provide an alternative to) orionsupport, please let me know. I know the boss here; I'm sure we could work something out. Thanks, Rian -- Rian Schmidt [EMAIL PROTECTED] - Original Message - From: [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Thursday, April 12, 2001 11:34 AM Subject: ORION RISE FROM THE DEAD! I've been watching Orion for awhile using/testing. It so close to being ideal for me and my clients and we are ready to buy. But development seems to have stopped lately. Updates to the web site are virtually non-existant (ie ORION 1.2 released on main site)...meanwhile we are up to 1.4.5 since Jan 22. I am happy with its current state. I just sucessfully tested SSL with it. I haven't done much in terms of EJB yet, but my experiences with orion still have been great. SO ORION - Please get your act together. Or if you must go out of businessdo it soonso I can look at enhydra/weblogic/websphere again...I haven't looked at them in awhile because I have been happy with orion. It's for your own good. You obviously have some great programmers who developed this product. They should either keep working on it, or find another product to work on. Best of luck David
forward with a null request...
Hi,
Just out of curiosity, can anyone explain why it is that I have to set the
request to null to prevent our login page from being displayed twice?
Here's the setup:
Client makes a request for a page in the /client directory, a filter is
invoked on the request looking for a 'userSession' session attribute, if
it's not there, the requestURI is stashed in a session attribute and control
is forwarded to the /login/index.jsp page. As an aside, I put a line in to
output to the console when the forward happens, and it's only printed out
once per request in either of the following cases.
If I forward like this:
getFilterConfig().getServletContext().getRequestDispatcher("/login/index.jsp
").forward(request,response);
I get the login page displayed twice in the browser (which strikes me as
weird... two complete copies in one browser).
Whereas if I do this:
getFilterConfig().getServletContext().getRequestDispatcher("/login/index.jsp
").forward(null,response);
it works like you'd expect.
As I said, we've got it working, but I'm curious what this is about. Thanks
for any insight.
Rian
--
Rian Schmidt
[EMAIL PROTECTED]
Re: A modification to ejbtags.jar
Consider this a friendly pat on the back... I had this on my list of things to get done for a big, nasty internal project, and this fits the bill perfectly. Maybe I'll send you a netcentive, or possibly a been, or even a flooz... unit? Uh... nah... nevermind. Thanks, Rian - Original Message - From: Michael A Third [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Friday, April 06, 2001 3:14 PM Subject: RE: A modification to ejbtags.jar Since I had already modified the Iterate tag to support sliding windows, I went ahead and incorporated Rafael's sorting tag and enhanced it to support descending order. I've only attached the IterateTag.java and a sample tld if anyone would like to use it. Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rafael Alvarez Sent: Tuesday, March 06, 2001 9:42 AM To: Orion-Interest Subject: Re: A modification to ejbtags.jar Ok. that resolve it :) I made two mistakes: 1) This mail was intended for Karl, but I misclicked in my email manager. 2) The version I sent is not a working one. I just realized that I lost the last version in the last crash of our CVS... Mea culpa not having a backup. Anyway, here is the working version. I'm interested in performance metrics, since it uses reflection... -- Best regards, Rafaelmailto:[EMAIL PROTECTED]
Re: orion with mysql?
Sounds like you need to turn off exclusive-write-access in orion-ejb-jar.xml while you're putzing with the database outside of the application. We're running with SQL Server 7 (*gasp*) and Orion will try to "fix" any manual changes we make to the database through the admin console. Otherwise, we have to shutdown Orion, make the changes, and restart. The performance hit is huge, so you wouldn't want to leave it turned off, but Orion will basically go talk to the database at every accessor to make sure that it's got the latest data and not assume that Orion knows best. Rian - Original Message - From: Armin Michel [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Thursday, April 05, 2001 12:25 AM Subject: Re: orion with mysql? [...] We also tried Hypersonic, but it seems that when both Orion and JBuilder communicate with the db the db gets confused. At least the changes we make in JBuilder don't get updated. That's propably because Orion caches data of the DB. If you stop Orion, then update the DB and then restart Orion, you shouldn't perceive any update problems. Greetings Armin
Re: Hot deployment not so hot
I'd suggest something a little less radical first... go into the orion-ejb-jar.xml file in your deployment directory and make sure that your updates were reflected there. In particular, make sure that Orion not only added what you did, but that it removed what you did. Orion seems to, thankfully, be pretty conservative about changing the deployed descriptors. If you don't have anything in there that you care about (custom mappings, finders, whatever...), then you could just nuke that file, touch the orion-application.xml to redeploy, and you should be golden. Rian - Original Message - From: [EMAIL PROTECTED] To: Orion-Interest Sent: Friday, March 30, 2001 6:46 AM Subject: Re: Hot deployment not so hot When we had similar problems we would remove the application from the application directory, the ear and the files from the applications-deployment directory. Make sure you stop the server before doing this. Jonathan BrickerLilly Research LabsJava ATG Dan North [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 03/30/2001 06:13 AM Please respond to Orion-Interest To: Orion-Interest [EMAIL PROTECTED] cc: Subject:Hot deployment not so hotHi all.I've been having a number of problems with hot deployment ever since I started using orion, and I wondered if anyone could shed any light?Typically it happens when I change an interface rather than just internal bean logic or code: orion says it is redeploying whatever-xyz.jar, but will complain that:- A cmp-field is missing (that I have removed from both the bean and the ejb-jar.xml)- A method doesn't exist (that I have just added to both the bean and the remote i/f)- etc.All the messages I get seem to come down to a conflict between some cached version of the bean and the new version. If I shut down and restart orion, all the problems go away and it deploys the new version fine.This hasn't been a problem during development, but I'm concerned that I might be doing something wrong, and obviously once the system goes live I can't just stop and restart the server when I deploy changes, so what's the Right Way to redeploy a session or entity bean into a running server and tell orion to forget everything it knew about the previous version?(I'm running 1.4.7 on Sun's jdk1.3 on Windows 2000 if it makes any difference.)Thanks,Dan/tastapod--Dan NorthVP Development - Cadrion Software Ltd - +44 (0)20 7440 9550CONFIDENTIALITYThis e-mail and any attachments are confidentialand may also be privileged. If you are not the named recipient,please notify the sender immediately and do not disclose thecontents to another person, use it for any purpose, or storeor copy the information in any medium
Re: findByXXX() with an ORDER BY parameter for Container-managed bean?
I'd guess, though I haven't tried it, that you could declare a finder with
two arguments- your object and a String. Something like:
findByGroupNameSorted(GroupName gn, String dir)
where dir would be asc or desc (either constants or a special
mini-bean{tm})
Then, in your orion-ejb-jar.xml, do this:
finder-method query=$1=$groupName ORDER BY $groupName $2
Rian
- Original Message -
From: Meo Van Le [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Cc: Magnus Rydin (E-mail) [EMAIL PROTECTED]
Sent: Friday, March 30, 2001 6:35 AM
Subject: findByXXX() with an ORDER BY parameter for Container-managed bean?
Dear all,
Could you tell me how to pass an ORDER BY parameter ( ASC or DESC )
for a finder-method of Container-Managed bean?
For example:
I have an Entity Bean was deployed as a Container-Managed
bean. The following lines were extracted from my orion-ejb-jar.xml:
entity-deployment name=psv.rws.ejbs.RwsGroup
table=Rws_Group data-source=jdbc/RWS_EJB_DS
primkey-mapping
cmp-field-mapping name=groupId
persistence-name=rws_group_id /
/primkey-mapping
cmp-field-mapping name=groupName
persistence-name=rws_group_name /
finder-method query=$1=$groupName ORDER BY
$groupName ASC
method
ejb-namepsv.rws.ejbs.RwsGroup/ejb-name
method-namefindByGroupNameAsc/method-name
method-params
method-paramjava.lang.String/method-param
/method-params
/method
/finder-method
finder-method query=$1=$groupName ORDER BY
$groupName DESC
method
ejb-namepsv.rws.ejbs.RwsGroup/ejb-name
method-namefindByGroupNameDesc/method-name
method-params
method-paramjava.lang.String/method-param
/method-params
/method
/finder-method
/entity-deployment
I have to write 2 finder methods for an normal finder method with
ascending order and descending order: findByGroupNameAsc and
findByGroupNameDesc.
Are there any way to combine them become a finder method?
Thanks in advance!
--
--
--
* Le Van Meo
* Senior Developer
* Tel: 8 251 250
* Mobil: 091 64 26 36
* [EMAIL PROTECTED]
--
--
Re: redhat 7
Likewise. We're doing a variety of benchmarks for a redesign of our site maintenance work request system (currently running a ColdFusion front-end over Java objects for the back-end) against, among other things, a fully Orion-based (JSP/taglib/EJB) system, and we're seeing performance improvements of 20X very consistently. Both environments are running on the same RedHat 7 system. Rian -- Rian Schmidt [EMAIL PROTECTED] Fine Brand Media, Inc. Internet Professional Services http://www.finebrand.com/ - Original Message - From: "David Morton" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Thursday, March 22, 2001 3:56 PM Subject: Re: redhat 7 I am having great success with Redhat 7.0 jdk 1.3/MySQL/javaexchange.com connection broker (autoreconnect=true) and the mm.mysql driver JDBC driver. David At 01:37 PM 3/22/01 -0800, you wrote: Any experience with the latest redhat distro and orion? Has anybody seen any conflicts?
Looking up an EJB in a different application...
Hi, Can anyone give me a pointer on how I might successfully lookup an EJB from within another EJB in a different application (both in Orion)? Here's the scenario: Application 'two'- EJB TwoBean looks up - Application 'one'- EJB OneBean Make sense? Now, java:comp/env/One and java:comp/env/Two both work from external clients. But TwoBean cannot see OneBean. I've tried using hard-coded jndi.properties, a jndi.property file, and 1500 (or so)variations on the names of the beans. I've got an ejb-ref entry in my ejb-jar.xml for application 'two,' but the kicker seems to be that no matter what I do to the properties, the result of printing the list from TwoBean shows: List: --java:comp: javax.naming.Context --Two: TwoHome I'm setting the jndi.properties to look for ormi:localhost/one... but that's not happening. So, the short version is: How can I look up a bean in one application's EJB under Orion from another application's EJB? Is there any way to "step outside" an application's JNDI naming context? Thanks, Rian
Re: Looking up an EJB in a different application...
Follow up for posterity... Turns out that there's an, apparently, Orion-specific thing... the "parent=..." tag in the server.xml file in /config (specifically the application tag therein.) The closest I could get without that was to be able to lookup the home just like an external client... but even then, no dice on narrow... ClassCastException. Now, it strikes me that this seems to imply that you can basically match up two and only two apps? I mean, sounds like the ultimate enterprise class problem of sharing lots of beans between lots of applications won't work. And while odd, doesn't prevent us from getting at least from point A to point 2. Happy coding. Hi, Can anyone give me a pointer on how I might successfully lookup an EJB from within another EJB in a different application (both in Orion)? Here's the scenario: Application 'two'- EJB TwoBean looks up - Application 'one'- EJB OneBean Make sense? Now, java:comp/env/One and java:comp/env/Two both work from external clients. But TwoBean cannot see OneBean. I've tried using hard-coded jndi.properties, a jndi.property file, and 1500 (or so)variations on the names of the beans. I've got an ejb-ref entry in my ejb-jar.xml for application 'two,' but the kicker seems to be that no matter what I do to the properties, the result of printing the list from TwoBean shows: List: --java:comp: javax.naming.Context --Two: TwoHome I'm setting the jndi.properties to look for ormi:localhost/one... but that's not happening. So, the short version is: How can I look up a bean in one application's EJB under Orion from another application's EJB? Is there any way to "step outside" an application's JNDI naming context? Thanks, Rian
