Multiple application clients sharing oneMETA-INF/application-client.xml file?
For some reason the VM in JBuilder 3.5 looks in the class output directory for META-INF/application-client.xml. Two questions about this: 1. Is there a way to specify where this will be loaded from? Since all of our applications output to the same Classes directory, there's only one application-client.xml. It isn't working because not all of the EJB apps are serving the same EJBs. When the InitialContext() is created it's failing for EJB references to other apps. 2. If there isn't a way to tell the context factory in the client where to load this from, is there a way to have one context look at multiple apps? Then at least the unused references wouldn't throw NamingExceptions. /* Eric Hodges, Chief Technology Officer Mongoose Technology, Inc. "We chase cobras so you don't have to." */
HttpSession question
Is there a way, from a client, to iterate through all the open sessions in a web server? I'm looking for something like Context.listBindings(), but for sessions. I have the feeling that this would be an unacceptable security hole and so is not possible, but figured someone in 'the constellation' might have the definitive answer. Thanks Reid
RE: R: R: frustrated - jdbc: No suitable driver
I think I am becomming more confused now. If you use a DataSource, and then DataSource.getConnection() you should have no need of JDBC drivers on the client side. You would need the javax.sql.* package but not the database dependent drivers. Otherwise what was the sense in switching to a DataSource? If I have to change my client if my database changes then I may as well just get connections the old way. Admittedly I have very rarely had a database change once an app was deployed... The other thing is that when calling EJB's you are only dealing with the remote interface, so you are not actually instantiating a connection on your machine (assuming an application client) so again there would be no need of jdbc drivers on the client machine. With all that, I cannot think of any instance where a DataSource is used where you need them, could you perhaps elaborate the situation where you do? After all maybe I am being dense and missing something. :) Al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer Sent: Wednesday, January 31, 2001 12:15 AM To: Orion-Interest Subject: RE: R: R: frustrated - jdbc: No suitable driver While I agree that the client code should have no knowledge of what driver it is using, somehow the JDBC driver classes do need to eventually find their way to the client machine. Since J2EE doesn't specify the process by which client files get to the client machine (and for good reason), there are a lot of ways to do it. >From you description, it looks like the weblogic launcher will automatically download the JDBC driver. I stand corrected :-) I wonder how they deal with licensing issues... I doubt they let just anyone download their jDrivers :-) And why didn't they make a launcher that downloads *all* the necessary classes so you can have a zero install footprint on the client machine? Looking at their docs, it looks like ClientDeployer wants the whole ear file to be installed on the client. Yuck. But I'll agree, downloading some classes is probably better than no classes. Orion is not so friendly. You've got to package everything up in the client jar file, including the interface classes of the ejbs you want to use. The good news is that in this process it's simple to put the minimum subset of classes into the client package :-) And dynamically downloading the class files is slow anyways :-) :-) :-) Jeff
Re: embedded servlet tag
[Gerald Gutierrez] > What would this do? > > There is the include tag that lets you include the output of a servlet in > another. > > this is a run-time include > and an include directive for "verbatim" include of another JSP page: > > <%@ include file="..."%> this is a compile-time include This may, in fact, be the same thing you were saying... just wanted to clarify :) -- James Manning <[EMAIL PROTECTED]> GPG Key fingerprint = B913 2FBD 14A9 CE18 B2B7 9C8E A0BF B026 EEBB F6E4
auto-deploying without editing config/*.xml
I asked this once before as part of another thread and didn't get an answer, so I'll try in a new thread :) The feature I like about jBoss the most is the auto-deploy directory where i can just drop in a .war/.ear/.jar and it gets deployed as per the xml files already in the file. From what I've seen, if you're using Orion you're forced to edit config/server.xml and config/default-web-site.xml for the application, and then the webapp inside it, to be deployed. Is this correct? If not (I hope :), how can I setup such a dir? (or at least not have to edit config/default-web-site.xml on each new webapp). FWIW, this is mainly for a mass-migration of webapps off of tomcat :) James -- James Manning <[EMAIL PROTECTED]> GPG Key fingerprint = B913 2FBD 14A9 CE18 B2B7 9C8E A0BF B026 EEBB F6E4
Problems with web-server/EJBServer on different machines
I have Orion web-server on machine A, and application server on machineB. Machine B is specified as the host in the tag. Orion-application.xml specifies remote="yes" and the myAppejb.jar is also present on MachineA. Please keep in mind that I have successfully exercised the application on MachineB with a stand-alone client on Machine A. When I invoke orion on machineA by doing: "java -jar orion.jar" I get the following behavior: On Machine A 1. RMI IO error: port is already in use, which is probably because... 2. I get a whole bunch of native threads invoking -jar orion.jar On Machine B, I get the following stack-trace. At least this implies that MachineA is trying to talk to MachineB. As always, I appreciate the help I've received on this list. java.lang.NullPointerException at com.evermind.server.rmi.ba.gq(JAX) at com.evermind.server.rmi.ba.resolveClass(JAX) at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:9 18) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at com.evermind.server.rmi.bd.hf(JAX) at com.evermind.server.rmi.bd.run(JAX) at com.evermind.util.f.run(JAX) Thanks __ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
Re: Re: message-driven beans from a topic
If the observable (sender) has knowledge of who the observers/listeners are, you can use the MessageDrivenBean as a notification service. The observable delegates notification to the MessageDrivenBean, and includes recipients as part of the message. There will be just one instance of the MessageDrivenBean. _ Get your free E-mail at http://www.ireland.com
Error messages from Orion have invalid XML format - bug?
My JSPs return XML which is transformed using XSL. When Orion locates syntax errors or encounters Exceptions it produces som HTML which contains the error message AND some HTML markup which presents the error message. This Orion markup happens to contain standalone tags. In case of an exception it looks like this: at com.evermind.server.http.d3.sw(JAX) at com.evermind.server.http.d3.su(JAX) at com.evermind.server.http.ef.s1(JAX) at com.evermind.server.http.ef.do(JAX) at com.evermind.util.f.run(JAX) As everybody knows, using standalone tags compromises XML syntax - XML would expect either or . Unfortunately this forces you to follow this debugging process: 1. Remove the lines in the JSP which links it to the stylesheet: 2. Rebuild the web application 3. Have Orion deploy the new build 4. Invoke the JSP and read the error 5. Correct the error in the JSP 6. Rebuild and redeploy 7. Check the error was corrected 8. Reinsert the line in the JSP which links it to the stylesheet. A rather long way to go, I think. This raises the question of whether this could be made easier. I have a feeling, I am not the only developer using XML, so maybe it would be a great idea if Orion Server presented Exceptions using tags which are valid in both HTML and XML. If the tag was replaced with , errors would be visible in both HTML and XML results. Moreover, if the whole error was enclosed in a valid XML tag you can have your XSL deliver the error as output. For instance at com.evermind.server.http.d3.sw(JAX) at com.evermind.server.http.d3.su(JAX) at com.evermind.server.http.ef.s1(JAX) at com.evermind.server.http.ef.do(JAX) at com.evermind.util.f.run(JAX) This is valid HTML and one can easily write XSL which checks for the occurance of this error and produces a result which can be seen in the output to the browser. This is just one quick idea of how to accomplish both valid HTML and valid XML - there are probably many other ways to accomplish this aswell. Of course, there might be a good reason why things are the way they are, but any comments to these thoughts would be welcomed. And should anyone at Ironflare have the time to comment on this too, I would be very grateful. Thanks Randahl -Original Message- From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]] Sent: 2. februar 2001 11:32 To: Orion-Interest Subject: Source XML Error: Expected "" to terminate element starting on line 51. Occasionally I get a strange result when there are syntax errors in my JSPs. If I have a JSP that works fine I can make Orion return a weird result by introducing a line like the following into the JSP: <% rubishrubishrubish %> I would expect Orion to compile the JSP and give me back a syntax error somewhere. Instead I get the following in my browser when I invoke the JSP: Source XML Error: Expected "" to terminate element starting on line 51. I know this sounds weird - that is exactly why I am asking: Has this occured to anyone else on the list? - Do you know why this happens? In hopes it is not my inner CPU which has some kind of bug... R.
