Re: Data Sources Help
Gary Shea said...
> On Today, David Kenzik ([EMAIL PROTECTED]) wrote:
> >ds = (DataSource) ctx.lookup("java:comp/env/jdbc/d123DS");
>
> Well, it took me a couple weeks (not full time!) to figure out that
> even though they tell you to use java:comp/env/jdbc... it doesn't
> actually work. Instead do your lookup on just "jdbc/d123DS".
Yes, Greg Matthews sent me a note shortly after receiving my inquiry with
that same answer-- this is the case, "java:comp/env/jdbc..." won't work, you
must shorten it to simply "jdbc/SOURCENAME".
Now that is out of the way, and it __was__ working for a bit. Really!
However, I wanted to restart Orion and pass it some debugging info to find a
pesky connection leak. Now my Orion won't startup:
Error initializing server: DriverManagerDataSource driver
'oracle.jdbc.driver.OracleDriver' not found
I've changed nothing and can't figure out what the heck would've caused
this.
My oracle.zip jdbc drivers are available because if I comment out my
tag and start Orion, my servlets that use the Oracle jdbc
driver directly (without the Orion driver manager) work just fine.
I'm totally boggled at this point. Any ideas?
Also, does anyone else notice that it takes nearly an hour for messages to
make it to the list distribution, or is it just my location versus the
Evermind mail server I guess I'm used to instant email. ;-)
--
David S. Kenzik
[EMAIL PROTECTED] - http://kenzik.com
Original Music - http://mp3.com/text
RE: Orion in production
I agree that sometimes support can be lacking, but I've worked out the key - specific questions! I find if I send them a specific question (usually with a working example I'll whip up), they can deploy it and get an answer to me quite quickly (1-2 days). If you ask a vague question like "How do JNDI bindings work in local apps?" it generally doesn't illicit a response ;) Just my experiences, Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Gary Shea Sent: Monday, October 23, 2000 1:34 PM To: Orion-Interest Subject: RE: Orion in production On Today, Duffey, Kevin ([EMAIL PROTECTED]) wrote: > I don't think I could say it better myself. I totally agree with you. The > fact is, while a few people in the organization I work for believe a small > company has little or no support, Magnus, Karl and a number of competent > Orion users have given me far better support than I have got from Allaire or > BEA..at least 100x better. I mean this. I get answeres EVERY DAY about > things I have questions for. I wish I could say the same. I've asked maybe five questions, and received exactly one answer. That one took a week or so. I've basically given up on the support address. And I'm a paying customer! Not too excited about buying any more licenses at this point. Gary Shea iTransact.com, Inc.
Re: Data Sources Help
On Today, David Kenzik ([EMAIL PROTECTED]) wrote:
> ds = (DataSource) ctx.lookup("java:comp/env/jdbc/d123DS");
Well, it took me a couple weeks (not full time!) to figure out that
even though they tell you to use java:comp/env/jdbc... it doesn't
actually work. Instead do your lookup on just "jdbc/d123DS".
At least, that's what worked for me...
Gary
> --
> David S. Kenzik
> [EMAIL PROTECTED] - http://kenzik.com
> Original Music - http://mp3.com/text
>
>
RE: Orion in production
On Today, Duffey, Kevin ([EMAIL PROTECTED]) wrote: > I don't think I could say it better myself. I totally agree with you. The > fact is, while a few people in the organization I work for believe a small > company has little or no support, Magnus, Karl and a number of competent > Orion users have given me far better support than I have got from Allaire or > BEA..at least 100x better. I mean this. I get answeres EVERY DAY about > things I have questions for. I wish I could say the same. I've asked maybe five questions, and received exactly one answer. That one took a week or so. I've basically given up on the support address. And I'm a paying customer! Not too excited about buying any more licenses at this point. Gary Shea iTransact.com, Inc.
java:comp/UserTransaction not found
dear all, i'm sort of still learning about entity beans and wondered if anyone had any pointers for an error i'm getting. i receive *no* error when i try to obtain a reference to a UserTransaction from a stateless server bean under orion. i receive the following error when i try to obtain a reference to a UserTransaction from a java program running *outside* orion, that is similar to CartClient in the orion examples. javax.naming.NameNotFoundException: java:comp/UserTransaction not found i can get around this error by having a stateless session bean do the UserTransaction stuff, and act as a facade to the other various entity and session bean methods but was wondering if there was a way around the above problem. thanks, greg.
Data Sources Help
Can anyone provide a step-by-step 'hello world' procedure for setting up
data-sources.xml properly and calling the resource from within a servlet?
Alternatively, can someone review my setup and comment on what might be
wrong?
The section of my data-sources.xml looks like this:
I'm attempting to create a connection within my servlet. Snippets of
the relevant code:
public class DSTest extends HttpServlet
{
InitialContext ctx;
DataSource ds;
...
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType("text/html");
PrintWriter out = res.getWriter();
try {
ctx=new InitialContext();
ds = (DataSource) ctx.lookup("java:comp/env/jdbc/d123DS");
con = ds.getConnection();
...
}
...
catch (NamingException e) { System.out.println(e); }
}
It is catching the NamingException, telling me:
javax.naming.NamingException: Error instantiating web-app JNDI-context: No
location specified for resource-ref d123DS
So I went and added to my application's web.xml, since this isn't under the
default orion application:
d123DS
jdbc/d123DS
Test Data Source
d123DS
javax.sql.DataSource
Container
And it still catches the same exception.
Am I missing something simple? I'll gladly write up a tutorial for this for
orionsupport.com if I can get this working.
My environment: jdk 1.3, orion 1.4.0
Any help would be wonderful.
--
David S. Kenzik
[EMAIL PROTECTED] - http://kenzik.com
Original Music - http://mp3.com/text
RE: EJB Help..
Hi Kevin... Accessing entity beans through session beans is usually the recomended procedure, but it does depend on what your doing. Jim --On Sunday, October 22, 2000 10:32 AM -0700 "Duffey, Kevin" <[EMAIL PROTECTED]> wrote: > Thanks. > > Good news...I used ANT 1.1 and made a simple build script that compiles my > com.company.ejb folder into a .jar file including the META-INF dir. I was > finally able to get EJB deployed!!! So i am stoked about that. I do have a > lot to learn still, and the spec from what I heard was mostly for vendors > to understand..didn't help developers too much. But I will read it again. > I am also still reading on an EJB book from ORiely press that covers EJB > 1.1. It talks more about CTM's than EJB J2EE servers to my surprise, but > I suppose they are the same thing. > > I really want to use stateless EJB session objects that work with entity > objects. I don't want my web/client side to access entity objects > directly...I don't know if thats the right way or not. What do you think? > One of our developers here thinks we should just use Entity objects > directly, but I don't see how that will help locate our logic on the ejb > server. Do ejb session objects work directly with entity objects? > > Ahh..so much to learn..so little time. I think I'll be just in time for > EJB 2.0! :) > > >> -Original Message- >> From: Juan Lorandi (Chile) [mailto:[EMAIL PROTECTED]] >> Sent: Friday, October 20, 2000 2:52 PM >> To: Orion-Interest >> Subject: RE: EJB Help.. >> >> >> the create method must reside in the Home interface and must match an >> ejbCreate method in the bean class... >> >> the Home And Remote interfaces (Login.java and LoginHome.java) must be >> implemented somewhere, >> because the Bean class doesn't implement it... >> >> EJB Servers/Containers, at deploy time, build a class that >> implements them >> and calls your ejb-- >> providing an indirection pattern which enables to provide transaction, >> security, caching and pooling support >> >> I suggest you read (again) extra carefully the ejb spec, and >> don't skip any >> section, specially the ones about >> Container responsabilities, this will give you the insight to >> know why your >> app isn't behaving well... >> >> HTH, >> >> Rifle >> >> PS: Copies of your Login*.java and the ejb-jar.xml would be welcome... >> >> -Original Message- >> From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] >> Sent: Viernes, 20 de Octubre de 2000 17:22 >> To: Orion-Interest >> Subject: RE: EJB Help.. >> >> >> HI, >> >> > Double check your ejb-jar.xml--are you setting LoginHome as >> your Home >> > interface in there? Is there a LoginHome.create() method >> > declared? Is there >> > a LoginBean.ejbCreate() method defined? >> >> Hmm..I don't have a LoginHome.create()..the Orion Primer >> didn't show that. I >> have a Login.java, LoginBean.java and LoginHome.java. I think >> Login.java is >> the only one with a create() method in it. Should both the "interface" >> classes have a create() in it? >> >> Also, why is Orion trying to compile it if its already >> compiled? Or is this >> some sort of "assembly" routine Orion does? I assume from >> what I read that >> the EJB server "implements" the interfaces..so is it >> generating its own code >> at runtime and that is what compiling is failing? >> >> Thanks again. >>
RE: Orion in production - new howto
I've just added a new HowTo to orionsupport.com. Details one approach to running Orion securely on UNIX/Linux. Also includes a useful shell script for administering Orion with. http://www.orionsupport.com/articles/unixprocess.html This is just one way of securing Orion... as Mike said, we'd love to hear how others approached the problem. -Joe Walnes -- At 05:28 22/10/2000, Mike Cannon-Brookes wrote -- This sounds fascinating - I'd love to know more about *ix permissions, securing Orion properly etc. You sound like you've got it all down pat, if you wouldn't mind, I'd love to learn more about your setup - as I'm sure other Orion users would. How about writing a quick how to doc about securing Orion on *ix? The OrionSupport team will love you for it ;)
RE: Orion in production
Hi, > One thing we'll probably end up doing is getting a pricey app > server so we > can tell outside folks we have it, and then continue using > Orion so that we > can assure ourselves that things will work. Seems stupid, but > that's the way > things are. Thats a good ideas as long as they don't use any netcraft website style stuff..where they can enter a domain name and see the server and version info! :) > One valid concern our business folks have is, "what is > Orion's future?" _I_ > don't know where they stand from a business viewpoint > (revenue, profits, > business plan) and so it's really tough to know whether > they'll be around in > a year. What's to stop them being bought out? For this reason > we'll end up > using Orion in production to some degree, but we'll also have a shiny > stand-by app server migration plan, JIC. That is a concern of ours as well. I am hoping with WebLogic 6.0 I can easily move our app from Orion to WebLogic so that I can "prove" to my boss that its moveable. I have experienced the same pains you have..in that while our app is fully Java (and hopefully soon J2EE), it doesn't seem to be easily moveable as once thought. I think its probably 99% server related..I haven't had to change any code to run on different servers. But it does require some tweaking, and I have yet to move my Orion app successfully to WebLogic. I think that is because WebLogic is far from implementing J2EE as Orion has. (Pretty sad when you compare the small team of Orion compared to the large team of developers WebLogic has).
Re: EJB 2.0 Dependent Object problem - NPE on deploy
Jim,
Try adding a field-name tag in your dependent cmp-field declarations:
addrDo
Test20CmpDo.eb.AddrDo
street
city
state
zip
I can't remember how I discovered this - it worked for me when I first
looked into ejb 2.0 / cmr / orion a couple of months ago.
Also, the ejb-name for the entity must match exactly with the role-source
ejb-name in the relationship. You have Temp20CmpDo.eb.Person in the former
and and Temp20CmpDo.eb.PersonEJB in the latter.
Hope this helps,
Earl
Earl S. Marwil, Ph.D. / Senior Scientist / SCIENTECH, Inc.
__o / TEL: (208) 525-3717 / 1690 International Way
-\<, / FAX: (208) 529-4721 / Idaho Falls, ID 83402
0/ 0__ / net: [EMAIL PROTECTED]
RE: Remote object callback from a session bean
What your are proposing seems like it should work. I am surprised it doesn't. Why would it not work? Does it not work with RMI? If you can call methods on an object from the client to the server, why can't it be the reverse..where the client object passed in (this) is like a "server" object to the server (which would assume the role of a client in this case). I thought RMI is two way..so I can't make sense of why this wouldn't work. > -Original Message- > From: Juan Lorandi (Chile) [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 20, 2000 2:54 PM > To: Orion-Interest > Subject: RE: Remote object callback from a session bean > > > Message Beans, regretably, they're only a public draft at > this moment, tough > orion already provides some support for them > > -Original Message- > From: John D'Ausilio [mailto:[EMAIL PROTECTED]] > Sent: Viernes, 20 de Octubre de 2000 17:22 > To: Orion-Interest > Subject: Remote object callback from a session bean > > > Tell me if I'm insane or not ... > > I have a session bean, and one of the services it provides is > a long-running > process which needs to inform the object on whose behalf it > is running when > various events occur. > > 1. Client gets the session bean and calls > createProcess(processID, this) ... > passing itself along > 2. Session bean does it's thing, create a process and gives > it the client > object reference > 3. As the process processes, at various points it calls > receiveEvent() on > the client object reference > > Seems to me that this should be feasible using standard RMI > stuff .. I made > an interface extending Remote that exposes the receiveEvent > call, made the > client class extend UnicastRemoteObject, and ran rmic on the class to > generate a stub. The stub source looks sensible. Everything > actually runs > without error, but the client callback never gets executed > and the client > finishes but never terminates, as there are a couple of > RMI-related threads > that never die. > > I've successfully tested some vanilla RMI stuff and made remote object > calls, but I had to create a .java.policy file. Is there some > equivalent > mechanism that needs to be set up for Orion? > > Has anyone tried anything this funky? Is there an > easier/saner way to do > this? > > Thanks! > jd >
RE: EJB Help..
Thanks. Good news...I used ANT 1.1 and made a simple build script that compiles my com.company.ejb folder into a .jar file including the META-INF dir. I was finally able to get EJB deployed!!! So i am stoked about that. I do have a lot to learn still, and the spec from what I heard was mostly for vendors to understand..didn't help developers too much. But I will read it again. I am also still reading on an EJB book from ORiely press that covers EJB 1.1. It talks more about CTM's than EJB J2EE servers to my surprise, but I suppose they are the same thing. I really want to use stateless EJB session objects that work with entity objects. I don't want my web/client side to access entity objects directly...I don't know if thats the right way or not. What do you think? One of our developers here thinks we should just use Entity objects directly, but I don't see how that will help locate our logic on the ejb server. Do ejb session objects work directly with entity objects? Ahh..so much to learn..so little time. I think I'll be just in time for EJB 2.0! :) > -Original Message- > From: Juan Lorandi (Chile) [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 20, 2000 2:52 PM > To: Orion-Interest > Subject: RE: EJB Help.. > > > the create method must reside in the Home interface and must match an > ejbCreate method in the bean class... > > the Home And Remote interfaces (Login.java and LoginHome.java) must be > implemented somewhere, > because the Bean class doesn't implement it... > > EJB Servers/Containers, at deploy time, build a class that > implements them > and calls your ejb-- > providing an indirection pattern which enables to provide transaction, > security, caching and pooling support > > I suggest you read (again) extra carefully the ejb spec, and > don't skip any > section, specially the ones about > Container responsabilities, this will give you the insight to > know why your > app isn't behaving well... > > HTH, > > Rifle > > PS: Copies of your Login*.java and the ejb-jar.xml would be welcome... > > -Original Message- > From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] > Sent: Viernes, 20 de Octubre de 2000 17:22 > To: Orion-Interest > Subject: RE: EJB Help.. > > > HI, > > > Double check your ejb-jar.xml--are you setting LoginHome as > your Home > > interface in there? Is there a LoginHome.create() method > > declared? Is there > > a LoginBean.ejbCreate() method defined? > > Hmm..I don't have a LoginHome.create()..the Orion Primer > didn't show that. I > have a Login.java, LoginBean.java and LoginHome.java. I think > Login.java is > the only one with a create() method in it. Should both the "interface" > classes have a create() in it? > > Also, why is Orion trying to compile it if its already > compiled? Or is this > some sort of "assembly" routine Orion does? I assume from > what I read that > the EJB server "implements" the interfaces..so is it > generating its own code > at runtime and that is what compiling is failing? > > Thanks again. >
RE: Orion in production
I don't think I could say it better myself. I totally agree with you. The fact is, while a few people in the organization I work for believe a small company has little or no support, Magnus, Karl and a number of competent Orion users have given me far better support than I have got from Allaire or BEA..at least 100x better. I mean this. I get answeres EVERY DAY about things I have questions for. Not only was BEA slow in responding (over 1 week), but the people they have their answering questions, first of all are not the developers, second of all don't know the product very well, and third..those that know it can only explain the "basic" things. Technical questions seem to elude all but the developers of BEA and you can't talk to them directly. > -Original Message- > From: Sven van 't Veer [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 20, 2000 2:29 PM > To: Orion-Interest > Subject: Re: Orion in production > > > > > "Duffey, Kevin" wrote: > > > > easiest to set up. I played around with WebLogic for two > weeks (on and off) > > and still couldn't get my simple JSP page to show up. > WebSphere was a > > nightmare, and while Resin was easy to work with, its not a > full J2EE app > > server. > > > IBM WebSphere..about a year late for the full J2EE support. > I can't even > > believe IBM WebSphere still doesn't support Servlet 2.2 and > JSP 1.1! I don't > > care how many billions you put into your software..if it > doesn't even meet > > the standards that have been in place for almost a year > now..it sure doesn't > > say a lot to me that the money is being spent in the right places! > > > Meanwhile, > > you have little itty bitty Orion (Ok..they are big to me! > ;) over here > > support EJB 2.0, Servlet 2.3, full J2EE support, > clusterable, easy to set > > up, fast, etc.. > > > > I sound like I am a sales man for Orion, but you know..I > tend to read up and > > test alot of the latest stuff and Orion kicks the > competitions ass hands > > down. > > AFIK Orion is a very small company, only a hand full of > people which is > great. IMHO lagre companies waste a lof of time and money on meetings > and stuff like that which is really bad for productions. > Before starting > for myself I worked in a couple of those and, eventhough the salary is > generally very good the working climate sucks. I hate > meetings, 90 % of > the time is wasted discussing off-topic issues. The company I > worked for > had about 50 developers working which isn't even that big (considering > Weblogic witb it's 1500). Every day started with a staff > meeting of one > hour with the section heads and one hour of the section heads > with all > the section members, resulting in about man hours lost per section per > day. > > If there is anything that makes small companies great, it's their > agility. Orion has already implemented mos t of the EJB 2.0 > specs while > weblogin has just launched it's fully 1.1 compliant server. > > I'd take Orion over any othjer server, and not only because of it's > price, but because it seems there are some really competent people > working on this server. > > sven > > -- > == > > Sven E. van 't Veer > http://www.cachoeiro.net > Java Developer > [EMAIL PROTECTED] > == > >
Problem with Cookies
Dear Friends, When I was trying to set a cookie using a JSP Page using Orion Server, it is working once in while. I don't know the exact problem. Whereas the same code i tried with Jakarta-Tomcat, i is working properly. Please reply to [EMAIL PROTECTED] Thanking you saif Khan --- Waheed Rahuman +91-431-459604 _ Get Your Free ScanMail and Email At http://www.bharatmail.com
Re: Orion in production
>IMHO the docs from the better-known app server vendors are just more pretty. >In most cases they aren't actually better. The best docs I've ever seen for >applications of this kind are those for open-source CORBA ORBs - ORBacus >springs to mind. Maybe Orion can emulate those. I dont know what docs you have been looking at. For me, looking at the JRun 3.0 documentation makes me feel like a desert wanderer hitting an oasis. I think a nicely written, consistent, complete, tutorial-like introduction IS a real value. Now, when relating to the issues covered by the J2EE standard, I can accept that we have the spec and are excpected to read it (thoroughly and completely). But when it comes to server-specific issues, I think full, well-written docs are a must. Also, regarding the pricing issue. I dont think those management types are all that stupid. The fact that a company has 1500 employees, has a huge service force and has been in the business for a decade or more may well be worth a few bucks. Its all a matter of perspective, and there is more than one justified perspective IMO. I as a techie running a small shop am well (somewhat) able to cope with orions deficiencies (only a handful of developers, strange definition of "documentation", etc.) in favor of its qualities. But I do accept that a management type running a 300+ heads shop sees things from a different angle. I thinks it is also fair to reflect that in the pricing..
