RE: JSP on Win98
have you copies tools.jar to the main orion folder? The error seems to be an IE 'friendly HTTP error message'. You can turn those of (and the server-generated messages on ) from tools-options-advanced in IE. Jeroen T. Wenting [EMAIL PROTECTED] Murphy was wrong, things that can't go wrong will anyway -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Su, Yi Sent: Thursday, August 10, 2000 06:06 To: Orion-Interest Subject: JSP on Win98 Hi, I've tried Orion examples on Windows NT 4 and Windows 2000 server. They are all OK. But I couldn't get through in Win98 machine. The problem is whenever a page refers to a JSP page, a "Page not found" will be throwed. Could anyone please help me out? Thank you, Su Yi
RE: webapp design: how to handle connection pooling
This is VERY slow, and in some tests its 100's of times slower than implementing a connection pool. For the original sender (and Conrad if you are not aware of this), there are two methods I would choose over the others above. The first is connection pooling. Servlets in the same web app maintain a Servlet Context that is a good place to store "global" objects. This way seems like a good idea because it should be portable across J2EE compliant application servers right? Option 2 is better when you are dealing with application servers, especialy with Orion. Orion has a very easy built-in connection pooling capability. When you suggest this method, I assume you are talking about an Orion specific mechanism correct? This is convenient if Orion is the only server you're using. If you ever want to migrate your app to a new server, you have to use that server's method or resort to the custom connection pool class above. Have I grasped the situation, or is there a J2EE-based "standard" mechanism for connection pooling that is portable across application servers? Thanks, Kit Cragin VP of Product Development Mongoose Technology, Inc. www.mongoosetech.com
RE: webapp design: how to handle connection pooling
Option 2 is better when you are dealing with application servers, especialy with Orion. Orion has a very easy built-in connection pooling capability. When you suggest this method, I assume you are talking about an Orion specific mechanism correct? This is convenient if Orion is the only server you're using. If you ever want to migrate your app to a new server, you have to use that server's method or resort to the custom connection pool class above. Have I grasped the situation, or is there a J2EE-based "standard" mechanism for connection pooling that is portable across application servers? There is a J2EE standard for connection pooling in the works, from what I've heard, but it is not in the 1.2.1 release. Personally, I always use a 3rd party one, for exactly the reason you state: cross-server portability. I test on Orion and Tomcat, deploy on iPlanet, using different database engines as well. Jeroen T. Wenting [EMAIL PROTECTED] Murphy was wrong, things that can't go wrong will anyway
RE: webapp design: how to handle connection pooling
you do have to release the connections back to the pool, usually with a free(Connection) command or similar. the pool then handles closing the actual Connection for you. Maybe Orion's implementation wants the Connection to be closed outside the pool, but this seems illogical to me. Jeroen T. Wenting [EMAIL PROTECTED] Murphy was wrong, things that can't go wrong will anyway -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Joe Peer Sent: Thursday, August 10, 2000 09:21 To: Orion-Interest Subject: Re: webapp design: how to handle connection pooling Hi everybody, thank you for your responses! i forgot to say that i am already using orion's connection pooling capability (i never thought i would give up my old connection pooling package, but orion made it possible ;=) the reason why i wrote the original message to this list was that i knew i am making something wrong, because since i upgraded to orion 1.1.37 i got that interesting warning on my console: "DriverManagerConnectionPoolConnection not closed, check your code!" (and i get lots of them ;=) this made me think about how to manage connections in general. i did not know i had to CLOSE the connections (i thought a connection pool consists of OPEN connections) as you can see, i still don't understand this whole db-connection stuff, so every additional info is still very appreciated!! thanks, joe - to Keven: i haven't tried yet, but i don't see a reason why orion should NOT be able to pool connections to different databases Keven Duffey wrote: My input follows: * some people say, it's best practice to put 1 connection into 1 user's http session and use it for all requests of that user This only works if you don't have a lot of users concurrently, say a small intranet application, that doesn't care scalibility. The reason is database connection can't be serialized for sure and connection in http session can't be replicated across your web server farm. Hence each user in a session requires to use the same machine in your web farm. This could be terrible if you intend to serve thousands of users concurrently. Secondly database licensing is an issue. Some database vendors charge you by concurrent opened connection. If your site has a thousand users concurrently, you will need to purchase a thousand licenses (That is the thing scares me most). Agreed with replier..you would NEVER want to do this. If you are not careful you can lose the connections which will ultimately crash the database and/or the web server. VERY bad design. * other people say it's best practice to use a connection for every request. (and if more than one methods are involved, the connection should be given as a method parameter) I would rather use this per-requset approach. Only open a connection whenever a request comes in and needs database access. I can't think of a reason why passing around connection as parameter is a bad idea as long as it is in the same request. This isn't bad. There are better ways. * again other people argue that they don't care at all about reusing connection, they just open and close them when they need/want to I would not like this idea since opening a database connection is expensive unless there is a connection pooling mechanism in place. This is VERY slow, and in some tests its 100's of times slower than implementing a connection pool. For the original sender (and Conrad if you are not aware of this), there are two methods I would choose over the others above. The first is connection pooling. Servlets in the same web app maintain a Servlet Context that is a good place to store "global" objects. By making a connection pool class and putting it in the servlet context when the web app is first loaded, the connection pool is available to all servlets (and JSP pages). Beyond that, a connection pool allows you to open one or more connections and keep them alive while the web app is running. Because of this, instead of going over the network and opening a connection on each request, then closing that connection, you are given an immediate opened connection from the pool on every request. This class is relatively easy to implement as well. Option 2 is better when you are dealing with application servers, especialy with Orion. Orion has a very easy built-in connection pooling capability. Generally the EJB layer would use this to get and set data in the database, but your JSP/Servlets can do the same as well. Each Orion app server (assuming you are using a cluster for fail-over, load-balancing and scalability) can have its own connection pool settings. You provide the database driver, number of connections, and login/password. The rest is done through JDBC 2.0 DataSources. Now..I am not a pro at this yet..so I am taking a
Re: webapp design: how to handle connection pooling
Connections obtained through a datasource ar closed to indicate that they are available for re-use. The actual underlying connection to the database is not closed. Joe Peer wrote: Hi everybody, thank you for your responses! i forgot to say that i am already using orion's connection pooling capability (i never thought i would give up my old connection pooling package, but orion made it possible ;=) the reason why i wrote the original message to this list was that i knew i am making something wrong, because since i upgraded to orion 1.1.37 i got that interesting warning on my console: "DriverManagerConnectionPoolConnection not closed, check your code!" (and i get lots of them ;=) this made me think about how to manage connections in general. i did not know i had to CLOSE the connections (i thought a connection pool consists of OPEN connections) as you can see, i still don't understand this whole db-connection stuff, so every additional info is still very appreciated!! thanks, joe - to Keven: i haven't tried yet, but i don't see a reason why orion should NOT be able to pool connections to different databases Keven Duffey wrote: My input follows: * some people say, it's best practice to put 1 connection into 1 user's http session and use it for all requests of that user This only works if you don't have a lot of users concurrently, say a small intranet application, that doesn't care scalibility. The reason is database connection can't be serialized for sure and connection in http session can't be replicated across your web server farm. Hence each user in a session requires to use the same machine in your web farm. This could be terrible if you intend to serve thousands of users concurrently. Secondly database licensing is an issue. Some database vendors charge you by concurrent opened connection. If your site has a thousand users concurrently, you will need to purchase a thousand licenses (That is the thing scares me most). Agreed with replier..you would NEVER want to do this. If you are not careful you can lose the connections which will ultimately crash the database and/or the web server. VERY bad design. * other people say it's best practice to use a connection for every request. (and if more than one methods are involved, the connection should be given as a method parameter) I would rather use this per-requset approach. Only open a connection whenever a request comes in and needs database access. I can't think of a reason why passing around connection as parameter is a bad idea as long as it is in the same request. This isn't bad. There are better ways. * again other people argue that they don't care at all about reusing connection, they just open and close them when they need/want to I would not like this idea since opening a database connection is expensive unless there is a connection pooling mechanism in place. This is VERY slow, and in some tests its 100's of times slower than implementing a connection pool. For the original sender (and Conrad if you are not aware of this), there are two methods I would choose over the others above. The first is connection pooling. Servlets in the same web app maintain a Servlet Context that is a good place to store "global" objects. By making a connection pool class and putting it in the servlet context when the web app is first loaded, the connection pool is available to all servlets (and JSP pages). Beyond that, a connection pool allows you to open one or more connections and keep them alive while the web app is running. Because of this, instead of going over the network and opening a connection on each request, then closing that connection, you are given an immediate opened connection from the pool on every request. This class is relatively easy to implement as well. Option 2 is better when you are dealing with application servers, especialy with Orion. Orion has a very easy built-in connection pooling capability. Generally the EJB layer would use this to get and set data in the database, but your JSP/Servlets can do the same as well. Each Orion app server (assuming you are using a cluster for fail-over, load-balancing and scalability) can have its own connection pool settings. You provide the database driver, number of connections, and login/password. The rest is done through JDBC 2.0 DataSources. Now..I am not a pro at this yet..so I am taking a stab at how this actually works. I still use my old connection pool class. None the less, I am pretty sure its this easy. My only question to anyone that knows is..can Orion (and other app servers for that matter) have multiple connection pools per app server? On our site we maintain 3 different databases and each request needs a connection from one of the three..depending on where the user is on the site. I would assume this
Orion on SCO UnixWare 7
Title: Orion on SCO UnixWare 7 Hi, Has anyone had any experience running Orion on UnixWare 7? I have deployed live apps on Windows NT 4, but am having trouble getting Orion to run on SCO. I have JDK 1.2 for SCO installed and get an error message pertaining to a problem with the JIT compiler? Thanks George GEORGE HOLMES TWI Interactive Media House Burlington Lane LONDON W4 2TH ENGLAND TEL: +44 208 233 5631 FAX: +44 208 233 7701 CELL: +44 7968 918813
Download Ok: Startup Ok: How to stop?
I've downloaded the freebee and started the server. Everything seems to work ok. Q: How to stop the server after starting with java -jar orion.jar? Brgds John Pashley Information must be free --- Remember When ... A computer was something on TV from a science fiction show of note a window was something you hated to clean... And ram was the cousin of a goat --- Icarus Enterprises Ltd. Siriusstr. 10 CH-8044 Zürich Tel: +41-1-260 36 66 Fax: +41-1-260 36 65 Mobile: +41-79-400 36 66 Email: [EMAIL PROTECTED] Web: www.icarus.ch SITA: ZRHSUXS Compuserve: [EMAIL PROTECTED] Location: N 47.22.82 E 008.33.20 Altitude: 512m / 1680ft ---
Re: JSP on Win98
If Jikes is in your system path then the patch to Jikes is not needed in server.xml (otherwise it is of course). If you say to use Jikes, the the inline compiler is not used (and everything goes a lot quicker). JSP compilation and EJB deployment is about 10-15 times faster with Jikes. "Su, Yi" wrote: Hi, Jeroen, Thank you very much. This does clarify a lot on my understanding. Another question that I'm having is, since tools.jar contains the inline Java compiler, what should I do if I want to specify jikes as my compiler. I notice that in server.xml there is an option, but it doesn't tell the path of jikes (or should I specify the full path of jikes for the "compiler executable"?). How does it affect the inline compiler? (I thought the server always use javac as default compiler, inline compiler is really new to me, thanks) Regards, Su Yi -Original Message- From: J.T. Wenting [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 10, 2000 2:39 PM To: Su, Yi Subject: RE: JSP on Win98 I don't know if it's a bug. Under NT, placing it in the main folder also works, and this is the location stated in the documentation. If it works in the lib folder (as it should, I think) this is probably coincidence. tools.jar is of course not really an add-on library like a JDBC driver or XML parser, but rather an application that is called by the JSP engine (it contains the inline Java compiler to compile JSPs into classfiles). Jeroen T. Wenting [EMAIL PROTECTED] Murphy was wrong, things that can't go wrong will anyway -Original Message- From: Su, Yi [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 10, 2000 08:30 To: '[EMAIL PROTECTED]' Subject: RE: JSP on Win98 Hi, Jeroen, Ya, I've put the tools.jar in the lib folder under orion. It didn't work. However I follow your suggestion to put the tools.jar in the main orion folder, it works. This is strange, isn't it? In Windows NT, the tools.jar goes to lib folder under orion, do you have an idea that why Windows98 has a different requirement? Besides, the library path in the application.xml states library path="../lib" /. Is this a bug? Anyway, thanks a lot for your help. Regards, Su Yi -Original Message- From: J.T. Wenting [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 10, 2000 2:06 PM To: Su, Yi; [EMAIL PROTECTED] Subject: RE: JSP on Win98 have you copies tools.jar to the main orion folder? The error seems to be an IE 'friendly HTTP error message'. You can turn those of (and the server-generated messages on ) from tools-options-advanced in IE. Jeroen T. Wenting [EMAIL PROTECTED] Murphy was wrong, things that can't go wrong will anyway -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Su, Yi Sent: Thursday, August 10, 2000 06:06 To: Orion-Interest Subject: JSP on Win98 Hi, I've tried Orion examples on Windows NT 4 and Windows 2000 server. They are all OK. But I couldn't get through in Win98 machine. The problem is whenever a page refers to a JSP page, a "Page not found" will be throwed. Could anyone please help me out? Thank you, Su Yi begin:vcard n:Smith;Dave tel;cell:+44 797 0008867 tel;work:+44 1225 445610 x-mozilla-html:FALSE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] fn:Dave Smith end:vcard
Sharing code between web-app and ejbs
Hello everyone! This is maybe not orion-specific (off-topic) but may be relevant anyway. How can you in a manageable way include "library" code, i e common code in an EAR which should be accessible from both the WAR and the EJB-JAR, and also preferably be put in the same EAR. The only way I can think of now is to duplicate code between the EJB-JAR part and the WEB-INF/classes directory, which is not a very nice solution. Another way would be to link the external code through another JAR-file, and tie together using a Manifest, but I cannot resolve exactly which Manifest should be used (the EAR or the JAR?) and how this should be done. I have read the Sun specs aboutthe Jar-manifest format but either they are very unclear, or I have not found the right information. Any clarity in this matter would be greatly appreciated. /August
A very interesting problem with JSP's and Finland
There is a very funny bug in Orion. I think it is in JSPservlet, because it appears only when compiling jsp pages. I have the package fi.infomates in import clause, which leads to the following error: Ambigious name: fi is both a class and a package After a long search I succeeded to locate the problem to orion.jar, to com/server/ejb/administeration/fi.class. Is it that we Finnish developers aren't allowed to use JSP? :)
Re: A very interesting problem with JSP's and Finland
On Fri, 28 Jul 2000, Aleksi Kallio wrote: There is a very funny bug in Orion. I think it is in JSPservlet, because it appears only when compiling jsp pages. I have the package fi.infomates in import clause, which leads to the following error: Ambigious name: fi is both a class and a package After a long search I succeeded to locate the problem to orion.jar, to com/server/ejb/administeration/fi.class. Is it that we Finnish developers aren't allowed to use JSP? :) Yeah, those swedes have it in for you! :) --- Joseph B. Ottinger [EMAIL PROTECTED] http://cupid.suninternet.com/~joeo HOMES.COM Developer
Orion and Cloudscape
Hi all: Can I make Orion and Clouscape run in the same VM? In that case, how? Wrapping Cloudscape in a servlet and running it within Orion? Any particular measure I should take in that case? All suggestions would be very welcome. Thanks J.
support email-address problem
I attempted to send mail to [EMAIL PROTECTED], and got back the following error. Notice from the transacript that the address has been rewritten to be sent to '[EMAIL PROTECTED]', so with any luck he's just one of several recipients to which the mail is being forwarded... Sorry to send this to the orion-interest list, but I don't know where else to send it to! Gary -- Forwarded message -- Date: Thu, 10 Aug 2000 10:17:49 -0400 From: Mail Delivery Subsystem [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Returned mail: User unknown The original message was received at Thu, 10 Aug 2000 10:16:22 -0400 from c1074691-a.saltlk1.ut.home.com [24.9.174.226] - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (expanded from: karl) - Transcript of session follows - ... while talking to spock.thelogic.com.: MAIL From:[EMAIL PROTECTED] SIZE=1896 451 [EMAIL PROTECTED]... Sender domain must resolve ... while talking to mail.aventus.nu.: RCPT To:[EMAIL PROTECTED] 550 [EMAIL PROTECTED]... Relaying denied 550 [EMAIL PROTECTED] User unknown
Re: A very interesting problem with JSP's and Finland
The Orion folks use a code obfuscator on Orion so, many of the classes are named things like fi, ab, ac, aa, gg and so on. Although, I am surprised the compiler would complain about this. Don't really have an answer sadly. - Original Message - From: "Aleksi Kallio" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Friday, July 28, 2000 7:27 AM Subject: A very interesting problem with JSP's and Finland There is a very funny bug in Orion. I think it is in JSPservlet, because it appears only when compiling jsp pages. I have the package fi.infomates in import clause, which leads to the following error: Ambigious name: fi is both a class and a package After a long search I succeeded to locate the problem to orion.jar, to com/server/ejb/administeration/fi.class. Is it that we Finnish developers aren't allowed to use JSP? :)
RE: Sharing code between web-app and ejbs
If you just put all your classes in the EJB-JAR file, they can be 'seen' from the WAR (no need to worry about the classes dir) That's the way I do it. Probably not the best way, but it works. Mike -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of August LinnmanSent: Thursday, 10 August 2000 9:37To: Orion-InterestCc: Robin RosenbergSubject: Sharing code between web-app and ejbs Hello everyone! This is maybe not orion-specific (off-topic) but may be relevant anyway. How can you in a manageable way include "library" code, i e common code in an EAR which should be accessible from both the WAR and the EJB-JAR, and also preferably be put in the same EAR. The only way I can think of now is to duplicate code between the EJB-JAR part and the WEB-INF/classes directory, which is not a very nice solution. Another way would be to link the external code through another JAR-file, and tie together using a Manifest, but I cannot resolve exactly which Manifest should be used (the EAR or the JAR?) and how this should be done. I have read the Sun specs aboutthe Jar-manifest format but either they are very unclear, or I have not found the right information. Any clarity in this matter would be greatly appreciated. /August
Re: Orion on SCO UnixWare 7
George, What do you get if you start the virtual machine with -Djava.compiler="" on the command line? -- Thomas Munro [EMAIL PROTECTED] http://www.gi-technology.com/ GI Technology (Paris) On Thu, 10 Aug 2000, Holmes, George (TWIi London) wrote: Hi, Has anyone had any experience running Orion on UnixWare 7? I have deployed live apps on Windows NT 4, but am having trouble getting Orion to run on SCO. I have JDK 1.2 for SCO installed and get an error message pertaining to a problem with the JIT compiler? Thanks George GEORGE HOLMES TWI Interactive Media House Burlington Lane LONDON W4 2TH ENGLAND TEL: +44 208 233 5631 FAX: +44 208 233 7701 CELL: +44 7968 918813
RE: Orion on SCO UnixWare 7
Title: RE: Orion on SCO UnixWare 7 Thomas, Thanks, this was the work-a-round I hit on a couple of hours ago. I think the main issue lies with SCO's implementation of the JIT compiler. George GEORGE HOLMES TWI Interactive Media House Burlington Lane LONDON W4 2TH ENGLAND TEL: +44 208 233 5631 FAX: +44 208 233 7701 CELL: +44 7968 918813 -Original Message- From: Thomas Munro [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 10, 2000 5:16 PM To: Holmes, George (TWIi London) Cc: Orion-Interest Subject: Re: Orion on SCO UnixWare 7 George, What do you get if you start the virtual machine with -Djava.compiler= on the command line? -- Thomas Munro [EMAIL PROTECTED] http://www.gi-technology.com/ GI Technology (Paris) On Thu, 10 Aug 2000, Holmes, George (TWIi London) wrote: Hi, Has anyone had any experience running Orion on UnixWare 7? I have deployed live apps on Windows NT 4, but am having trouble getting Orion to run on SCO. I have JDK 1.2 for SCO installed and get an error message pertaining to a problem with the JIT compiler? Thanks George GEORGE HOLMES TWI Interactive Media House Burlington Lane LONDON W4 2TH ENGLAND TEL: +44 208 233 5631 FAX: +44 208 233 7701 CELL: +44 7968 918813
Lookups broken with outside JVMs ??
We are using the orion EJB server engine and orion servlet engine. When trying
ot connect to the EJB server from the serlvets, lookups are fine. Wnen coming
from outside orion in another JVM, the lookups FAIL with the error:
koala.dynamicjava.interpreter.InterpreterException:
javax.naming.NamingException: Lookup error: java.net.SocketException: errno:
101, error: Network is unreachable for fd: 36; nested exception is:
java.net.SocketException: errno: 101, error: Network is unreachable for
fd: 36
at
koala.dynamicjava.interpreter.TreeInterpreter.interpret(TreeInterpreter.java:110)
at
koala.dynamicjava.interpreter.TreeInterpreter.interpret(TreeInterpreter.java:123)
at koala.dynamicjava.interpreter.Main.main(Main.java:176)
javax.naming.NamingException: Lookup error: java.net.SocketException: errno:
101, error: Network is unreachable for fd: 36; nested exception is:
java.net.SocketException: errno: 101, error: Network is unreachable for
fd: 36
Are lookups broken using other JVMs?? Details of our configuration:
The deployment descriptors are as follows (extracted from a larger xml config
file)
enterprise-beans
entity
display-nameFolder Object/display-name
ejb-namebrica:Folder/ejb-name
homecom.tsis.brica.document.FolderHome/home
remotecom.tsis.brica.document.Folder/remote
ejb-classcom.tsis.brica.document.FolderImpl/ejb-class
persistence-typeBean/persistence-type
prim-key-classjava.lang.Long/prim-key-class
reentrantTrue/reentrant
resource-ref
res-ref-namejdbc/bricaData/res-ref-name
res-typejavax.sql.DataSource/res-type
res-authApplication/res-auth
/resource-ref
/entity
The client code using Dynamic Java is:
Properties props = new Properties();
props.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"com.evermind.server.rmi.RMIInitialContextFactory");
props.setProperty(Context.PROVIDER_URL, "ormi://127.0.0.0/brica");
Context context = new InitialContext(props);
FolderHome folderhome = (FolderHome)context.lookup("brica:Folder");
^Here is where the exception
occurs.
userThreads option in orion
HI: I am trying to start a background thread in the init method of one of my servlets in Orion. At one point, on orion start up, I got a message saying that thread was out of application scope and the orion server should be started with the -userThreads option. Does anyone know what the implications of this are and why we would need to start orion with this option? Thanks. Sumit
java.lang.NullPointerException in jsp:forward /
hi, i have a very strange problem with my orion server. whenever i try to use jsp:forward / or getServletConfig().getServletContext().getRequestDispatcher(string).forward(requ est, response) i get a java.lang.NullPointerException: 500 Internal Server Error java.lang.NullPointerException at com.evermind.server.http.du.rt(Compiled Code) at com.evermind.server.http.HttpApplication.getRequestDispatcher(Compiled Code) at com.evermind.server.http.EvermindPageContext.handlePageException(Compiled Code) at /ServiceFC.jsp._jspService(Compiled Code) at com.evermind.server.http.EvermindHttpJspPage.service(Compiled Code) at com.evermind.server.http.HttpApplication.t5(Compiled Code) at com.evermind.server.http.JSPServlet.service(Compiled Code) at com.evermind.server.http.di.pw(Compiled Code) at com.evermind.server.http.di.forward(Compiled Code) at com.evermind.server.http.dr.p1(Compiled Code) at com.evermind.server.http.dr.p0(JAX) at com.evermind.util.f.run(Compiled Code) this is on a solaris 8 x86 box running java version "1.2.1" Solaris VM (build Solaris_JDK_1.2.1_04c, native threads, sunwjit) on other boxes it works as expected. any hints? thanks, --nils
Re: A very interesting problem with JSP's and Finland
Hello, Yeah, JAX is generating some classes with "evil" names, we're fixing that. Regards, Karl Avedal "Joseph B. Ottinger" wrote: On Fri, 28 Jul 2000, Aleksi Kallio wrote: There is a very funny bug in Orion. I think it is in JSPservlet, because it appears only when compiling jsp pages. I have the package fi.infomates in import clause, which leads to the following error: Ambigious name: fi is both a class and a package After a long search I succeeded to locate the problem to orion.jar, to com/server/ejb/administeration/fi.class. Is it that we Finnish developers aren't allowed to use JSP? :) Yeah, those swedes have it in for you! :) --- Joseph B. Ottinger [EMAIL PROTECTED] http://cupid.suninternet.com/~joeo HOMES.COM Developer
Autoencode URLs
I noticed that autoencode URLs wasn't working for us, then realized that it's just for JSP pages. Is there any way to have URLs autoencoded if we're outputting a page straight from a servlet? Thank you, -- Joel Shellman Chief Software Architect The virally-driven B2B marketplace for outsourcing projects http://www.ants.com/90589781
RE: Jive
We are using hSQL + Orion in server mode as follows: 1) snip from data-source.xml note the line url="jdbc:HypersonicSQL:hsql://jaguar" which is the hsql "server mode" jdbc url data-source name="Default data-source" class="com.evermind.sql.ConnectionDataSource" location="jdbc/DefaultDS" pooled-location="jdbc/DefaultPooledDS" xa-location="jdbc/xa/DefaultXADS" ejb-location="jdbc/DefaultEJBDS" url="jdbc:HypersonicSQL:hsql://jaguar" connection-driver="org.hsql.jdbcDriver" username="sa" password="" schema="database-schemas/hypersonic.xml" / b) start hsql using "java -cp \orion\lib\hSql.jar org.hsql.Server" Works fine you can connect to the hsql server using the hSql DataBase manager concurrently with orion also to see what is being stored. Kind Regards Neville Burnell Business Manager Software -Original Message- From: Joseph B. Ottinger [mailto:[EMAIL PROTECTED]] Sent: Thursday, 10 August 2000 4:56 AM To: Orion-Interest Cc: [EMAIL PROTECTED] Subject: RE: Jive Sure. hsql serves just as a sort of "default database" for orion, so you'll always have SOMETHING, even though the default mode of hsql kinda sucks. (Anyone looked into getting hsql to run in server mode from inside orion?) On Wed, 9 Aug 2000, J.T. Wenting wrote: Will Orion survive without hSQL installed? I do not use it for anything myself, so if Orion can do without, so can I. I could always replace it with another database if that is possible (instantDb, Interbase, Oracle (at work), even MS Access...). Jeroen T Wenting [EMAIL PROTECTED] ICQ UIN #9191966 It's the end of the world as we know it and I feel fine (Michael Stipe) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Joseph B. Ottinger Sent: 09 August 2000 19:06 To: Orion-Interest Cc: Orion-Interest; Matt Adam Tucker Subject: Re: Jive Um, no. It's not a bug in orion. It's a classpath issue, and literally a problem with hsql.jar, as stated. $ORION/lib jars get put in the classpath, and since Tree.class in hsql is in the default package, it's exposed according to java's rules. If you want to blame Java, fine. Go for it. If you want to blame hsql, fine. Go for it. In either case, blame is deserved (well, mostly for hsql, but hey.) Orion is doing nothing to the classpath to make it behave oddly. The solution is to fix hsql.jar, really, not modify orion or jive. On Wed, 9 Aug 2000, Chris Miller wrote: Thanks for the reply Jeroen. As far as I can see, this is actually a bug in Orion - it's exposing the classes in hsql.jar (and probably the other /lib jars?) to JSP pages when it shouldn't be. I don't think Jive needs fixing? As for the hSQL scripts, I'm sorry but I don't have any - I'm actually using SQL Server (but I have a script for that if you want it?). My solution to the problem I described was to simply remove the hsql.jar file from /orion/lib since I'm not using it. - Original Message - From: "J.T. Wenting" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Cc: "Matt Adam Tucker" [EMAIL PROTECTED] Sent: Wednesday, August 09, 2000 3:38 PM Subject: RE: Jive I'm working on building Jive. I'll look into it and forward your message to the main maintainers. Jive probably does not see the class, but the JSP engine does. Maybe that's what is causing problems. Have you been able to create the Jive database on hSQL? If so, can you send in the SQL scripts for it? We want to have broad support. Jeroen T. Wenting [EMAIL PROTECTED] Murphy was wrong, things that can't go wrong will anyway -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Miller Sent: Wednesday, August 09, 2000 15:13 To: Orion-Interest Cc: [EMAIL PROTECTED] Subject: Jive Has anyone here used Jive (www.coolservlets.com/jive) with Orion (1.1.37)? I've just tried to set it up, and hit a problem because the orion/lib/hsql.jar file contains a class called 'Tree'. Jive also has a class called this, and when I try to use it in a JSP page, Orion finds Hypersonic's Tree class first. So the question is, should this Hypersonic class be visible to my JSP page? I would have thought not unless I explicitly used %@ page import ... % Has anyone else seen this problem? --- Joseph B. Ottinger [EMAIL PROTECTED] http://cupid.suninternet.com/~joeo HOMES.COM Developer --- Joseph B. Ottinger [EMAIL PROTECTED] http://cupid.suninternet.com/~joeo HOMES.COM Developer
