Re: RP: JMS messages to autostarted clients
How are you autostarting your bean? Is it operating as a daemon within Orion or is it a Servlet? Sorry I could not help with your post Thanks, Cory At 12:54 AM 11/15/00 -0500, Vidur Dhanda wrote: Hello, I didn't hear from anyone on this and have posted this as a bug against 1.4.4. -- Bug 188. I'm really interested in hearing others' opinions on this subject. Vidur - Hello, I just installed 1.4.3. The good news is that my previous problems with JMS subscribers, when running as auto-started clients, not getting messages delivered is resolved. However, it appears that the auto-started client's message handler (onMessage()) is invoked within the transaction context of the publishing EJB call. Is this expected behavior? I would think that the message handlers would be invoked outside of the transaction. If this is expected behavior, how can I design around it? Here's a stacktrace that shows the calls (the non-reentrant exception, I believe, is an artifact of the problem) The flow is that the EntityBean (datawatchItemBean), in its postCreate publishes a message and an auto-started client (DataWatchEngine) subscribes to these messages. I'm not an expert on JMS (barely getting started with messaging) and would appreciate all help. Thanks, Vidur com.evermind.server.rmi.OrionRemoteException: Recursive call to non-reentrant be an at com.evermind.server.ejb.AbstractEJBObject.startCall(JAX) at DataWatchItem_EntityBeanWrapper18.getDataWatchEntry(DataWatchItem_Ent ityBeanWrapper18.java:1014) at com.epistemic.km.server.DataWatchEngine$NotificationHandler.onNotify( DataWatchEngine.java:195) at com.epistemic.km.server.ServerNotificationListener$MessageListenerImp l.onMessage(ServerNotificationListener.java:30) at com.evermind.server.jms.ct.lr(JAX) at com.evermind.server.jms.cu.lr(JAX) at com.evermind.server.jms.EvermindTopicConnection.l8(JAX) at com.evermind.server.jms.JMSServer.lq(JAX) at com.evermind.server.jms.ch.k9(JAX) at com.evermind.server.jms.cu.l5(JAX) at com.evermind.server.jms.cv.publish(JAX) at com.evermind.server.jms.cv.publish(JAX) at com.epistemic.km.server.Notifier.publish(Notifier.java:87) at com.epistemic.km.server.Notifier.notifyCreate(Notifier.java:101) at com.epistemic.km.server.DataWatchItemBean.ejbPostCreate(DataWatchItem Bean.java:69) at DataWatchItemHome_EntityHomeWrapper51.create(DataWatchItemHome_Entity HomeWrapper51.java:506) at com.epistemic.km.server.DataWatchServiceBean.addWatch(DataWatchServic eBean.java:110) at DataWatchService_StatelessSessionBeanWrapper8.addWatch(DataWatchServi ce_StatelessSessionBeanWrapper8.java:138) at java.lang.reflect.Method.invoke(Native Method) at com.evermind.server.rmi.bf.do(JAX) at com.evermind.util.f.run(JAX)
Re: URGENT: talking with other app server?
Yes RMI is the protocol used to communicate between an EJB client and server. JNDI is what you use to find the server and set your context. That is standard for EJB client - server communication. Cory At 02:07 AM 11/11/00 +1100, James Ho wrote: Hi there, I had to build the two servers, one is the central server, and the other is the service provider. The central server would grab the remote server's home bean, and then do whatever to it. How would I do that? You mentioned RMI, and i think that's what I used when i create the JNDI context using rmi.RMInitialContext. Is there any other way to obtain the home bean of the remote servers? If so, any more details description/code snippets ? as of ORB, I'd prefer to leave that out..and use EJB only...possible? Thanks once again. James. On Fri, 10 Nov 2000 16:59:17 -0500, you wrote: As I understand it Corba objects can call EJBs via RMI-IIOP which is supported not at the server level (Orion) but by the VM. Didn't RMI-IIOP become standard with the JDK 1.3? The limitation is that you can not run a Corba object as an EJB so that you could make outbound Corba calls from your app server and use Orion or other as a Corba object server. If you want to do that you will have to use Inprise's App server which is built upon the Visigenics Corba Orb. But I don't know if you are asking specifically about the use of an Orb. It appears as though you are trying to just implement the Trader Service with EJB much like the OMG specified Corba Trader Service. If this is the case you could use RMI to communicate with a specific EJB server to query for all of the Objects and home interfaces as well as JNDI locations of resources within your service range (Corba guys call the service range a federation). Then you could have one location in an enterprise that could be querried for available services even though the services might reside on different machines and different networks within the enterprise. Cory At 10:33 PM 11/10/00 +1100, James Ho wrote: Hi there. What I am doing for a project, to allow different service providers to join my central service. Each of the service providers would have to implement a Bean wiht the home and remote interface specified by the central service, and the central service uses EJB to communicate with those servers...it is rather a dynamic systemThus the central service would be likely to interact with many DIFFERENT type of app servers. As of your client jars suggestion, do u mean the client proram the bean..'jar' it, and send it to the central service? ORB? then I'd have to touch CORBA then? and ORB acts as a wrapper to my bean? If so, why EJB? If I use a separate LDAP for the service providers to deployed their bean at...would that solve the problem? Thanks :) James. you can't... yet (No IIOP in Orion yet) and mostly, what IIOP(Internet Inter-ORB Protocol) provides is ORB communication, the ORB (Object Request Broker) is the one that provides your beans services, and provides beans to its clients... In an EJB architecture, it may be easy to implement distrubuted transactions, for instance, thanks to IIOP + 2PC commit/ OpenXA transactions, but applying security (which is server specific) can become hell Also, if the JNDI of a given server doesn't support it, it can be tricky to code the beans; My advise is to create/obtain client jars which are mainly the remote home interfaces; Always narrow Objects PortableRemoteObject.narrow (MyBean.Class) Perhaps if you elaborate further the List may be of assistance HTH, JP (P.S.: I hope you don't want to interact with Oracle App Servers, OAS or IAS... for the mission isn't hard, it's just impossible ;-) -Original Message- From: James Ho [mailto:[EMAIL PROTECTED]] Sent: Viernes, 10 de Noviembre de 2000 13:19 To: Orion-Interest Subject: Re: URGENT: talking with other app server? "Juan Lorandi (Chile)" wrote: To connect different App servers (diff vendors) IIOP will be used How can I do that with Orion? James
Re: URGENT: talking with other app server?
As I understand it Corba objects can call EJBs via RMI-IIOP which is supported not at the server level (Orion) but by the VM. Didn't RMI-IIOP become standard with the JDK 1.3? The limitation is that you can not run a Corba object as an EJB so that you could make outbound Corba calls from your app server and use Orion or other as a Corba object server. If you want to do that you will have to use Inprise's App server which is built upon the Visigenics Corba Orb. But I don't know if you are asking specifically about the use of an Orb. It appears as though you are trying to just implement the Trader Service with EJB much like the OMG specified Corba Trader Service. If this is the case you could use RMI to communicate with a specific EJB server to query for all of the Objects and home interfaces as well as JNDI locations of resources within your service range (Corba guys call the service range a federation). Then you could have one location in an enterprise that could be querried for available services even though the services might reside on different machines and different networks within the enterprise. Cory At 10:33 PM 11/10/00 +1100, James Ho wrote: Hi there. What I am doing for a project, to allow different service providers to join my central service. Each of the service providers would have to implement a Bean wiht the home and remote interface specified by the central service, and the central service uses EJB to communicate with those servers...it is rather a dynamic systemThus the central service would be likely to interact with many DIFFERENT type of app servers. As of your client jars suggestion, do u mean the client proram the bean..'jar' it, and send it to the central service? ORB? then I'd have to touch CORBA then? and ORB acts as a wrapper to my bean? If so, why EJB? If I use a separate LDAP for the service providers to deployed their bean at...would that solve the problem? Thanks :) James. you can't... yet (No IIOP in Orion yet) and mostly, what IIOP(Internet Inter-ORB Protocol) provides is ORB communication, the ORB (Object Request Broker) is the one that provides your beans services, and provides beans to its clients... In an EJB architecture, it may be easy to implement distrubuted transactions, for instance, thanks to IIOP + 2PC commit/ OpenXA transactions, but applying security (which is server specific) can become hell Also, if the JNDI of a given server doesn't support it, it can be tricky to code the beans; My advise is to create/obtain client jars which are mainly the remote home interfaces; Always narrow Objects PortableRemoteObject.narrow (MyBean.Class) Perhaps if you elaborate further the List may be of assistance HTH, JP (P.S.: I hope you don't want to interact with Oracle App Servers, OAS or IAS... for the mission isn't hard, it's just impossible ;-) -Original Message- From: James Ho [mailto:[EMAIL PROTECTED]] Sent: Viernes, 10 de Noviembre de 2000 13:19 To: Orion-Interest Subject: Re: URGENT: talking with other app server? "Juan Lorandi (Chile)" wrote: To connect different App servers (diff vendors) IIOP will be used How can I do that with Orion? James
RE: BMP vs CMP with Orion
I just received JBuilder 4 Enterprise and I will say that it does an amazing job at EJB so far. You can connect to a datasource via JDBC and pick your tables and keys for Entity CMP. It's amazing. I'm still tweaking the deployment descriptors for Orion. Man the money you can save on Orion should go toward also purchasing JB4 Enterprise. The two together could be a very cutting edge solution. It does also have support for EJB 2.0 style descriptors Haven't tested this yet though. Cory At 09:37 AM 11/7/00 +0100, Frank Eggink wrote: I guess I'm using neither. The clue is that, when you stick to the rules, you have to write the minimum one panel and one table per dataobject as all the access to the properties is done via methods and each of those methods is specific for the dataobjects (e.g. getName(), setName(x)). When you have a lot of dataobjects that is a bore. The 'pattern' I'm using abstracts away (= marketing speak) from the clean OO model. The generator generates standard bean access (getProperty(index), setProperty(index, x) and by using descriptors for the dataobjects and its relations is it possible to generate default screens. Something you would most likely use reflection for when that was possible. Using reflection has two problems: - It does not work with Orion. - It works only on a per object basis. You could solve those by adding on the client side wrapper objects that implement Just-Another-Layer. You can use reflection for that layer and if you device you object in a clever way (using clever naming patterns) you -can- use reflection. Why the complex stuff and not generating the tables and the panel. Well, in the system I'm using I plan to implement the option for users/systemmanager to tailor their screens. You can do that when you generate screen on the fly, you can't when they are already compiled. It is a bit of an excercise but I am always strongly in favour to use as less as possible code to build your final system. A lot of bugs stem from silly mistakes: the less code, the less silly mistakes. And if in the above generator there is a silly mistake it is reproduced in a lot of places: more chance to be discovered. I guess the same model could be used for dynamic creation of HTML. Frank On Monday, November 06, 2000 11:16 AM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: Are you using the command or business object pattern? At 08:49 AM 11/6/00 +0100, Frank Eggink wrote: I'm using Swing instead of JSP. On Sunday, November 05, 2000 9:04 PM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: Thanks for that update. Do you or does anyone else know of the MVC (model - view - control) pattern used with JSP - Servlets and EJB? I have read that a single servlet becomes that controlling mechanism to the EJBs. I wondering how that is done? Cory At 10:23 PM 11/5/00 +0100, Frank Eggink wrote: My personal trade off was: Why not CMP 2.0 style: - Too scared to use it for real as it is not even officially there ... Why choose for CMP 1.1? - CMP is more portable (across db's). - Working already towards EJB2.0. - The claim is CMP can be optimized better (I would be happy to know more details about that, until that time it is a bit of a bet on a blackhorse for me). Why choose for BMP? - I do not know yet whether I'll run into trouble with complex and highly flexible queries requirements for Query By Example forms. The requirement for extra flexibility could become an argument. I would say if you can spend the time learning enough about CMP 1.1 I would go for that as a first option. The EJB1.1 specs are even written so that you can sub class a CMP bean to create a BMP bean. One of the biggest disadavantages of EJB's is the tremendous amount of redundant code you have to write. Add for instance a field to a bean. You'll have to change three files minimum and don't make mistakes as that will cost you time. This disadavantage applies to both CMP and BMP and will apply to EJB2.0 as well. What I'm doing is using EJB1.1 CMP and generate beans and stuff using a slightly more advanced bean generator then the standard ones. Based on a datamodel (Entity-Relation) it generates a set of beans for your application (including the remote and home interfaces and the *.xml files of course). The generated beans include the fields, the finder queries, the additional methods to retrieve related beans etc. As an additional bonus the beans include a more abstract way to access the properties (myBean.getProperty(int index)) as the client side of orion does not allow reflection. I use that to generate forms and tables on the client. The generator adds a tremendous flexibility (I can switch to BMP / EJB2.0 easily), makes CMP 1.1 managable and keeps me away from EJB2.0 while it is still too early for me. For the rest: Im a notoruios mifftyper and am able to spend tons
Re: There has GOTTA be a BETTER way !!!!
JBuilder 4 Enterprise allows you do build Entity CMP beans this way. You can connect to a datasource and then select tables and keys for your beans. It's wild. I'm still getting used to it. Can anybody else with more experience using this tool give us a little insight? Thanks, Cory At 10:34 AM 11/7/03 -0500, Keith Kwiatek wrote: Hello, EJB's are great if you like tripling the amount of code you have to write How is everyone building their web apps with hand coded programs, or using automagic tools? It sure seems like there should be some sort of tool that you can just point at database tables, and have it build the jsp or ejb entity bean. AND shouldn't there be a tool that you can just drop the bean on an html template thus allowing visual access to the bean fields? You can't access ejb's directly from a jsp page (like a normal bean) can you? Any tools that will automagically wrap an ejb in a bean for presentation in a JSP? Am I off base here, or are ejb's a lot more work? How can people talk about how EJB's "speed development time"?!? Keith
RE: BMP vs CMP with Orion
It appears as though you can define/select any number of tables and or fields from different tables to define what makes up the fields within an entity bean. Cory At 10:12 PM 11/7/00 +0100, Frank Eggink wrote: Hi Cory, How do they recognize relations between tables? Frank On Tuesday, November 07, 2000 3:32 PM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: I just received JBuilder 4 Enterprise and I will say that it does an amazing job at EJB so far. You can connect to a datasource via JDBC and pick your tables and keys for Entity CMP. It's amazing. I'm still tweaking the deployment descriptors for Orion. Man the money you can save on Orion should go toward also purchasing JB4 Enterprise. The two together could be a very cutting edge solution. It does also have support for EJB 2.0 style descriptors Haven't tested this yet though. Cory At 09:37 AM 11/7/00 +0100, Frank Eggink wrote: I guess I'm using neither. The clue is that, when you stick to the rules, you have to write the minimum one panel and one table per dataobject as all the access to the properties is done via methods and each of those methods is specific for the dataobjects (e.g. getName(), setName(x)). When you have a lot of dataobjects that is a bore. The 'pattern' I'm using abstracts away (= marketing speak) from the clean OO model. The generator generates standard bean access (getProperty(index), setProperty(index, x) and by using descriptors for the dataobjects and its relations is it possible to generate default screens. Something you would most likely use reflection for when that was possible. Using reflection has two problems: - It does not work with Orion. - It works only on a per object basis. You could solve those by adding on the client side wrapper objects that implement Just-Another-Layer. You can use reflection for that layer and if you device you object in a clever way (using clever naming patterns) you -can- use reflection. Why the complex stuff and not generating the tables and the panel. Well, in the system I'm using I plan to implement the option for users/systemmanager to tailor their screens. You can do that when you generate screen on the fly, you can't when they are already compiled. It is a bit of an excercise but I am always strongly in favour to use as less as possible code to build your final system. A lot of bugs stem from silly mistakes: the less code, the less silly mistakes. And if in the above generator there is a silly mistake it is reproduced in a lot of places: more chance to be discovered. I guess the same model could be used for dynamic creation of HTML. Frank On Monday, November 06, 2000 11:16 AM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: Are you using the command or business object pattern? At 08:49 AM 11/6/00 +0100, Frank Eggink wrote: I'm using Swing instead of JSP. On Sunday, November 05, 2000 9:04 PM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: Thanks for that update. Do you or does anyone else know of the MVC (model - view - control) pattern used with JSP - Servlets and EJB? I have read that a single servlet becomes that controlling mechanism to the EJBs. I wondering how that is done? Cory At 10:23 PM 11/5/00 +0100, Frank Eggink wrote: My personal trade off was: Why not CMP 2.0 style: - Too scared to use it for real as it is not even officially there ... Why choose for CMP 1.1? - CMP is more portable (across db's). - Working already towards EJB2.0. - The claim is CMP can be optimized better (I would be happy to know more details about that, until that time it is a bit of a bet on a blackhorse for me). Why choose for BMP? - I do not know yet whether I'll run into trouble with complex and highly flexible queries requirements for Query By Example forms. The requirement for extra flexibility could become an argument. I would say if you can spend the time learning enough about CMP 1.1 I would go for that as a first option. The EJB1.1 specs are even written so that you can sub class a CMP bean to create a BMP bean. One of the biggest disadavantages of EJB's is the tremendous amount of redundant code you have to write. Add for instance a field to a bean. You'll have to change three files minimum and don't make mistakes as that will cost you time. This disadavantage applies to both CMP and BMP and will apply to EJB2.0 as well. What I'm doing is using EJB1.1 CMP and generate beans and stuff using a slightly more advanced bean generator then the standard ones. Based on a datamodel (Entity-Relation) it generates a set of beans for your application (including the remote and home interfaces and the *.xml files of course). The generated beans include the fields, the finder queries, the additional methods to retrieve related beans etc
RE: BMP vs CMP with Orion
Are you using the command or business object pattern? At 08:49 AM 11/6/00 +0100, Frank Eggink wrote: I'm using Swing instead of JSP. On Sunday, November 05, 2000 9:04 PM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: Thanks for that update. Do you or does anyone else know of the MVC (model - view - control) pattern used with JSP - Servlets and EJB? I have read that a single servlet becomes that controlling mechanism to the EJBs. I wondering how that is done? Cory At 10:23 PM 11/5/00 +0100, Frank Eggink wrote: My personal trade off was: Why not CMP 2.0 style: - Too scared to use it for real as it is not even officially there ... Why choose for CMP 1.1? - CMP is more portable (across db's). - Working already towards EJB2.0. - The claim is CMP can be optimized better (I would be happy to know more details about that, until that time it is a bit of a bet on a blackhorse for me). Why choose for BMP? - I do not know yet whether I'll run into trouble with complex and highly flexible queries requirements for Query By Example forms. The requirement for extra flexibility could become an argument. I would say if you can spend the time learning enough about CMP 1.1 I would go for that as a first option. The EJB1.1 specs are even written so that you can sub class a CMP bean to create a BMP bean. One of the biggest disadavantages of EJB's is the tremendous amount of redundant code you have to write. Add for instance a field to a bean. You'll have to change three files minimum and don't make mistakes as that will cost you time. This disadavantage applies to both CMP and BMP and will apply to EJB2.0 as well. What I'm doing is using EJB1.1 CMP and generate beans and stuff using a slightly more advanced bean generator then the standard ones. Based on a datamodel (Entity-Relation) it generates a set of beans for your application (including the remote and home interfaces and the *.xml files of course). The generated beans include the fields, the finder queries, the additional methods to retrieve related beans etc. As an additional bonus the beans include a more abstract way to access the properties (myBean.getProperty(int index)) as the client side of orion does not allow reflection. I use that to generate forms and tables on the client. The generator adds a tremendous flexibility (I can switch to BMP / EJB2.0 easily), makes CMP 1.1 managable and keeps me away from EJB2.0 while it is still too early for me. For the rest: Im a notoruios mifftyper and am able to spend tons of time debug typos in 2638 lines of very closely resembling code. That problem is solved as well :-) Frank On Saturday, November 04, 2000 12:10 AM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: At 11:44 PM 11/3/00 +0100, Robert Krueger wrote: At 11:23 03.11.00 , you wrote: I have looked through the 2.0 spec and find the chapters regarding CMP to be daunting. It appears as though the complexity of writing my own SQL in BMP has to be balanced against learning an entire new way of managin persistence within the XML deployment descriptors which seems to be no less or perhaps even more complicated than BMP Or am I missing something with regard to CMP being easier? yes, two things: 1. your code including the queries is guaranteed to be portable between ejb servers and databases (that's the theory) 2. you cannot possibly make optimizations using BMP that the container can make using CMP why do you have to use ejb2.0 CMP? you didn't mention 1.1 cmp as an alternative? Hmmm. I can find even less regarding 1.1 CMP. I have the ORielly book as well as the Mastering EJB books. The 2.0 spec is what I'm using because I would think (perhaps wrongly) that EJB 2.0 would maybe be easier and or offer more functionality??? Chapters 9 and 10 are over 100 pages which have to do with CMP. The last thing I need to do is learn another query language which is what some of the 2.0 spec seemed to indicate I would need to do I also understand points 1 and 2 above but they do not address my original question of the relative complexity between BMP and CMP. Basically 1 and 2 are irrelevant to me if I can not implement CMP and can not practically compare the relative complexity between the two because I just don't understand CMP so I will keep digging through examples and utilize the post that has been helpful that somebody posted earlier today : http://www.execpc.com/~gopalan/java/entity.html . Thanks, Cory regards, robert Thanks, Cory (-) Robert Kruger (-) SIGNAL 7 Gesellschaft fur Informationstechnologie mbH (-) Bruder-Knau?-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
RE: BMP vs CMP with Orion
Thanks for that update. Do you or does anyone else know of the MVC (model - view - control) pattern used with JSP - Servlets and EJB? I have read that a single servlet becomes that controlling mechanism to the EJBs. I wondering how that is done? Cory At 10:23 PM 11/5/00 +0100, Frank Eggink wrote: My personal trade off was: Why not CMP 2.0 style: - Too scared to use it for real as it is not even officially there ... Why choose for CMP 1.1? - CMP is more portable (across db's). - Working already towards EJB2.0. - The claim is CMP can be optimized better (I would be happy to know more details about that, until that time it is a bit of a bet on a blackhorse for me). Why choose for BMP? - I do not know yet whether I'll run into trouble with complex and highly flexible queries requirements for Query By Example forms. The requirement for extra flexibility could become an argument. I would say if you can spend the time learning enough about CMP 1.1 I would go for that as a first option. The EJB1.1 specs are even written so that you can sub class a CMP bean to create a BMP bean. One of the biggest disadavantages of EJB's is the tremendous amount of redundant code you have to write. Add for instance a field to a bean. You'll have to change three files minimum and don't make mistakes as that will cost you time. This disadavantage applies to both CMP and BMP and will apply to EJB2.0 as well. What I'm doing is using EJB1.1 CMP and generate beans and stuff using a slightly more advanced bean generator then the standard ones. Based on a datamodel (Entity-Relation) it generates a set of beans for your application (including the remote and home interfaces and the *.xml files of course). The generated beans include the fields, the finder queries, the additional methods to retrieve related beans etc. As an additional bonus the beans include a more abstract way to access the properties (myBean.getProperty(int index)) as the client side of orion does not allow reflection. I use that to generate forms and tables on the client. The generator adds a tremendous flexibility (I can switch to BMP / EJB2.0 easily), makes CMP 1.1 managable and keeps me away from EJB2.0 while it is still too early for me. For the rest: Im a notoruios mifftyper and am able to spend tons of time debug typos in 2638 lines of very closely resembling code. That problem is solved as well :-) Frank On Saturday, November 04, 2000 12:10 AM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: At 11:44 PM 11/3/00 +0100, Robert Krueger wrote: At 11:23 03.11.00 , you wrote: I have looked through the 2.0 spec and find the chapters regarding CMP to be daunting. It appears as though the complexity of writing my own SQL in BMP has to be balanced against learning an entire new way of managin persistence within the XML deployment descriptors which seems to be no less or perhaps even more complicated than BMP Or am I missing something with regard to CMP being easier? yes, two things: 1. your code including the queries is guaranteed to be portable between ejb servers and databases (that's the theory) 2. you cannot possibly make optimizations using BMP that the container can make using CMP why do you have to use ejb2.0 CMP? you didn't mention 1.1 cmp as an alternative? Hmmm. I can find even less regarding 1.1 CMP. I have the ORielly book as well as the Mastering EJB books. The 2.0 spec is what I'm using because I would think (perhaps wrongly) that EJB 2.0 would maybe be easier and or offer more functionality??? Chapters 9 and 10 are over 100 pages which have to do with CMP. The last thing I need to do is learn another query language which is what some of the 2.0 spec seemed to indicate I would need to do I also understand points 1 and 2 above but they do not address my original question of the relative complexity between BMP and CMP. Basically 1 and 2 are irrelevant to me if I can not implement CMP and can not practically compare the relative complexity between the two because I just don't understand CMP so I will keep digging through examples and utilize the post that has been helpful that somebody posted earlier today : http://www.execpc.com/~gopalan/java/entity.html . Thanks, Cory regards, robert Thanks, Cory (-) Robert Kruger (-) SIGNAL 7 Gesellschaft fur Informationstechnologie mbH (-) Bruder-Knau?-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
Re: Orion JBuilder 4 Enterprise
Joshua, Did you get a hold of an eval copy? If so how could I? Also did you make any progress with JB4 and Orion? Thanks, Cory At 07:05 PM 10/31/00 +0100, you wrote: I've just started testing JBuilder 4 Enterprise Edition. One of the nice things about it is the integration with the (included) Inprise Application Server. The OpenTools IDE includes hooks for integration with pretty much any application server, especially for EJB deployment. So, before I start coding the glue to join JB4E up with Orion, is anyone else already working on this (even Evermind?). Joshua -[ Joshua Goodall ]--- -[ Chief IP Systems Architect ]-- Cook, Geek, Lover -- -[ [EMAIL PROTECTED] ]--- [EMAIL PROTECTED] --
Re: Beginner: Step by step tutorial?
You would always use JDBC. You do have a choice of which driver to use though. If you want to use the OCI native drivers you can specify those in the JDBC datasource. Download the Oracle JDBC drivers from Oracle's site and you can choose between using the Thin or OCI drivers. There are some great servlet jsp books like the Sun Press book Core Servlets and Java Server Pages Cory At 01:31 AM 11/4/00 +0800, Winnie Leung wrote: HI, I am a total beginner to Orion (and somewhat of a beginner to Java). I would be really grateful if some one could point me to a really beginner's step-by-step tutorial on how to write a servlet, to do standard web type stuff like (a) post form variables, and (b) access data from the database (oracle -- is there a way to use OCI directly, instead of JDBC?) Thanks very much in advance, Winnie
BMP vs CMP with Orion
I have looked through the 2.0 spec and find the chapters regarding CMP to be daunting. It appears as though the complexity of writing my own SQL in BMP has to be balanced against learning an entire new way of managin persistence within the XML deployment descriptors which seems to be no less or perhaps even more complicated than BMP Or am I missing something with regard to CMP being easier? Thanks, Cory
Re: BMP vs CMP with Orion
At 11:44 PM 11/3/00 +0100, Robert Krueger wrote: At 11:23 03.11.00 , you wrote: I have looked through the 2.0 spec and find the chapters regarding CMP to be daunting. It appears as though the complexity of writing my own SQL in BMP has to be balanced against learning an entire new way of managin persistence within the XML deployment descriptors which seems to be no less or perhaps even more complicated than BMP Or am I missing something with regard to CMP being easier? yes, two things: 1. your code including the queries is guaranteed to be portable between ejb servers and databases (that's the theory) 2. you cannot possibly make optimizations using BMP that the container can make using CMP why do you have to use ejb2.0 CMP? you didn't mention 1.1 cmp as an alternative? Hmmm. I can find even less regarding 1.1 CMP. I have the ORielly book as well as the Mastering EJB books. The 2.0 spec is what I'm using because I would think (perhaps wrongly) that EJB 2.0 would maybe be easier and or offer more functionality??? Chapters 9 and 10 are over 100 pages which have to do with CMP. The last thing I need to do is learn another query language which is what some of the 2.0 spec seemed to indicate I would need to do I also understand points 1 and 2 above but they do not address my original question of the relative complexity between BMP and CMP. Basically 1 and 2 are irrelevant to me if I can not implement CMP and can not practically compare the relative complexity between the two because I just don't understand CMP so I will keep digging through examples and utilize the post that has been helpful that somebody posted earlier today : http://www.execpc.com/~gopalan/java/entity.html . Thanks, Cory regards, robert Thanks, Cory (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
RE: EJB Help..
Jim, How could a CMP managed entity bean handle a create for say an Oracle database table that used db specific sql for describing the key using a sequence? Where the sql itself might look like insert into customer (id, name, address) values(cust_sequence.NEXTVAL, "Jim" "12 Willow Street"); Maybe this is trivial. Better yet could I ask you to provide some of the sources of information that you use to help all of us better understand how to do CMP with perhaps complex RDBMS entity relationships? Thanks, Cory At 09:07 PM 10/20/00 -0400, Jim Archer wrote: What types of relationships do you feel EJB 2.0 can't adequately support? I have been studying 2.0 CMP carefully, and it seems to be quite powerfull. There may be holes in it, but it can handle the majority of real works cases. Jim --On Friday, October 20, 2000 12:28 PM -0700 [EMAIL PROTECTED] wrote: If you don't use an object-relational mapping tool you're still in for a lot of hurt with EJB if you have a complex data model. I don't think CMP really addresses the kind of data models large systems have. Nor does the relationship support in EJB 2.0 either. I think you'll end up doing JDBC BMP with your Session and Entity beans. Performance is only an issue when you make everything a stateful session bean or an entity bean. There are rules for when it's appropriate to make things entity beans. There still isn't a whole lot of useful information around on design EJBs yet though with most of it only explaining the basics including the ORA book. On Fri, 20 Oct 2000, Duffey, Kevin wrote: Thanks. I only meant to use the /classes folder because my ejb code is in the same project as the rest of my code (Servlets, javabeans, action classes, etc). Since it all compiles to the same one folder, I assume I will have to "move" the ejb compiled classes every time I compile them. What I was hoping for was a way to not have to do this..instead, just let the whole project compile to the WEB-INF/classes folder (all my code), and then have Orion pick up on the ejb changes from that point. It appears to me from what everyone is saying I will have to use some sort of script every time I make a change to an ejb, which my first thoughts is a pain in the ass. Its very easy to develop servlets, action classes, javabeans, core classes, but ejb not only requires 3 classes per component, but lots of "special" work just to get the thing deployed. Then, every time you make a change, it requires the same process. I would think turn-around time for ejb development is on the order of a couple of minutes for every change you make. That results in a lot slower development cycle than I am currently using. Worse, I have started hearing alot of people turn away from ejb and going back to servlets because of development time, and performance. Supposedly the ejb stuff isn't living up to all the hype. However, I look at what the ejb container does for you (connection pooling, transactions, security, instance pooling, etc) and it seems there is alot of stuff I wont have to do on the side of persistence, transactions and security..so maybe the extra time is worth it? ;) Anyways..I did as one person suggested in this list, I set up in my application.xml like so: module ejb/path/www/WEB-INF/classes//ejb /module and Orion seems to be finding the classes (the ejb). However, I keep seeing an error appear. It says something like: Error compiling class c:/path/www/WEB-INF/classes/ Login.java LoginBean.java LoginHome.java can't find method create()in LoginBean.java Its a very strange message to me. If I change the module path, it tells me it can't find the classes. If I delete the classes, it also tells me it can't find them. So I assume the path is set correctly in the module ejb tag..as it is finding the classes. I am just not sure why the heck its giving me some compiler error..or why its even trying to compile them..they are already compiled. Anyways..I'll keep plugging away. -Original Message- From: Stanislav Maximov [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 19, 2000 6:34 PM To: Orion-Interest Subject: RE: EJB Help.. Kevin, look inside the news-application example bundled with Orion, lots of things will become clear for you after that. www-dir/WEB-INF/classes directory is for servlet classes, not for EJBs. You'll see how to deploy EJBs in that example and in documentation as well. stas@ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin Sent: Friday, October 20, 2000 3:45 AM To: Orion-Interest Subject: RE: EJB Help.. Thanks for the note. One thing..since I compile all of my classes into the www/WEB-INF/classes dir, should I put a META-INF in the /classes dir, and just point the module to the WEB-INF/classes folder? Would that work? Not that I want you to tell me
RE: EJB Help..
Jim, Thanks for the reply. I have not looked over the 2.0 spec. in detail yet but I will. Are you mapping cmp entity beans to an existing db structure most of the time? Cory At 07:28 PM 10/21/00 -0400, you wrote: Hi Cory... I doubt we'll see anything thats database engine specific supported in CMP. I agree that sequences are extremely usefull and wish that there was a standard way on implementing them on database engines so that JDBC (and therefore J2EE) could take full advantage. PostgreSQL has a sequence and MS SQL Server has an identity field and so on. Unfortunatly, database vendors have no standard for implementing them. You can write code to generate a unique value for a primary key. You could code up a session bean that uses JDBC to create a new record in a table with no fields but the identity field. Of course, this bean would be database specific and it would be used by the non-database specific CMP entity beans. Orion makes a key generator available called counter.jar, which you can read about in the Orion FAQ (although I don't know what its licensing terms are - check this before you rely on it in your app). Setting aside the question of sequence types and primary key generation, I have not yet run into a RDBMS data structure I don't think I could replicate using EJB 2.0 CMP. Even if I did, I could isolate part with BMP or session beans and use CMP for the rest. I expect if I found something so strange 2.0 CMP could not handle it that I would try to redesign it so that it could be handled. I would probably end up with a better and simpler design. With EJB 2.0 CMP, I have a very good chance of getting my J2EE app to run on whatever database on whatever compliant server on whatever operating system. And, all the work it does for me is nice as well. Also, with EJB 2.0, its entirely possible to create a tool that would let you draw a UML diagram and generate almost the entire back end of an app - deployment descripters, code, maybe everything but the QL- automatically and then make changes a snap. There is no such tool now, but give some time. The best source of how to do CMP, unfortunatly, is still the spec. Anyhow, I thought EJB 1.1 was of limited utility. I think 2.0 is much, much better and can probably handle most systems. Just my opinion. Jim --On Saturday, October 21, 2000 3:11 AM -0400 Cory Adams [EMAIL PROTECTED] wrote: Jim, How could a CMP managed entity bean handle a create for say an Oracle database table that used db specific sql for describing the key using a sequence? Where the sql itself might look like insert into customer (id, name, address) values(cust_sequence.NEXTVAL, "Jim" "12 Willow Street"); Maybe this is trivial. Better yet could I ask you to provide some of the sources of information that you use to help all of us better understand how to do CMP with perhaps complex RDBMS entity relationships? Thanks, Cory At 09:07 PM 10/20/00 -0400, Jim Archer wrote: What types of relationships do you feel EJB 2.0 can't adequately support? I have been studying 2.0 CMP carefully, and it seems to be quite powerfull. There may be holes in it, but it can handle the majority of real works cases. Jim --On Friday, October 20, 2000 12:28 PM -0700 [EMAIL PROTECTED] wrote: If you don't use an object-relational mapping tool you're still in for a lot of hurt with EJB if you have a complex data model. I don't think CMP really addresses the kind of data models large systems have. Nor does the relationship support in EJB 2.0 either. I think you'll end up doing JDBC BMP with your Session and Entity beans. Performance is only an issue when you make everything a stateful session bean or an entity bean. There are rules for when it's appropriate to make things entity beans. There still isn't a whole lot of useful information around on design EJBs yet though with most of it only explaining the basics including the ORA book. On Fri, 20 Oct 2000, Duffey, Kevin wrote: Thanks. I only meant to use the /classes folder because my ejb code is in the same project as the rest of my code (Servlets, javabeans, action classes, etc). Since it all compiles to the same one folder, I assume I will have to "move" the ejb compiled classes every time I compile them. What I was hoping for was a way to not have to do this..instead, just let the whole project compile to the WEB-INF/classes folder (all my code), and then have Orion pick up on the ejb changes from that point. It appears to me from what everyone is saying I will have to use some sort of script every time I make a change to an ejb, which my first thoughts is a pain in the ass. Its very easy to develop servlets, action classes, javabeans, core classes, but ejb not only requires 3 classes per component, but lots of "special" work just to get the thing deployed. Then, every time you make a change, it requires the same
Re: Modified Servlets
Look in the global-web-application.xml for: orion-web-app jsp-cache-directory="./persistence" servlet-webdir="/servlet" development="true" If you set development=true Orion will not only pickup the change in the java source file but it will even recompile if for you. This really aids in development time in that it saves you a step within your editor. Otherwise I believe that Orion will always pick up a modified servlet. This may not be true for supporting classes. Somebody else mentioned touching a particular file to make the servlet engine pull the classes in again Cory At 09:33 AM 10/20/00 -0400, [EMAIL PROTECTED] wrote: To whom this may concern: What do I need to set in Orion to allow it to realize when a servlet has been modified that it should use that new version of the servlet. Thanks, Andy
RE: HARDWARE FOR J2EE apps
How much time do you have? I say that becuase you may burn a lot of time trying to solve those database issues that are solved in some of the other commercial products. For replication you could use snapshots wither by doing exports/imports or data copying on a periodic basis so that you could at least recover fairly quickly I have not used DB2 but people have mentioned that it is fairly inexpensive when compared to Oracle. I would have thought that the SAP product would have had failover and perhaps even Postgress??? Cory At 11:37 PM 10/11/00 +0200, David Kinnvall wrote: Hi! On Wed, 11 Oct 2000, Robert Krueger wrote: [description of budget-friendly Orion setup - snip] sounds very nice but what about the database? how do you cluster that without spending an arm and a leg? our experience is, that it's not that hard to set up clustered web services with static pages and servlets but the really expensive part is, when you want that high availability for your database. it doesn't buy you much if you have highly available ejbs when the database server goes down. many people use clustered apache/jserv on linux and cheap pc-hardware for high volume transactional websites but have a large enterprise sun running oracle in the back. anyone out there running a configuration with orion that includes a database with failover that doesn't blow up the budget too much (compared to other components)? Ah. Deja Vu. :-) I'm involved with a startup company here in Sweden, and considering Orion as app server we are also contemplating what non-arm-and-a-leg-spending ways there are to enable a database for failover and load-balancing functionality. We are looking at either PostgreSQL, InterBase, SAP-DB or MySQL (yeah, I know) as our database. We have not seen any currently freely available solutions for failover for either of those (anybody?). So, we are thinking about implementing something by ourselves. Nothing definite so far, but: - The synchronizing of data will be done on the application-level, not by the database servers themselves. See below. - We'll avoid numeric sequences for record keys to make this easier. We will implement some unique key-generation scheme based on whatever is needed to make keys unique but still not rely on strict monotone numeric sequences or similar ( md5(table_name+timestamp()), perhaps? ). - We'll code a DB-abstraction layer that takes care of executing all update queries against all configured database servers and all read queries against one of them known to be alive and lightly loaded (or not recently accessed, or some other scheme). - I guess that if we need database-specific stuff such as stored procedures or similar we need to use the same database software for all failover machines. - If we stay away from database-specifics we could possibly allow failover between different database products. Would be cool. Using straight, standard SQL, could make this feasible. These are very premature thoughts, we are getting closer to the planning and design stage, but we haven't actually started yet. Any thoughts? Ridiculously naive? Or possible to pull off? robert /David Reach me by - Email: [EMAIL PROTECTED], WWW: http://www.dtek.chalmers.se/~d0dak/ - --/David---
Re: New batch of documentation
Karl, Also the database schema link seems to have a link to a local file file:///c%7C/orion091b/orion/docs/database-schema.xml.html I would have dropped it in Bugzilla but that seemed to be confined to core app bugs... Great job. Thanks, Cory At 04:02 PM 9/28/00 +0200, Karl Avedal wrote: Hello Chris, Thanks! The link was wrong, it should be fixed now. Regards, Karl Avedal Chris Miller wrote: Karl and the rest of the Orion team, I just want to say thank you vey much for this update, it looks good (and will keep myself and many others busy for a while I suspect ;-). One small thing I noticed, this link is broken (or perhaps just hasn't been uploaded yet): http://www.orionserver.com/docs/tutorials/tools/ Thanks again, keep it coming! Chris - Original Message - From: "Karl Avedal" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Thursday, September 28, 2000 1:02 PM Subject: New batch of documentation Hello, To give you an update on the documentation work, today we added a few documents and put up other documentation improvements on the site: * New more thorough index page * New "debugging" document meant to help debug Orion applications, with info about logs and how to get more verbose info from Orion * New auto-generated docs for the .xml configuration files (attribute alphabetical listing and tag alphabetical listing) * Overview of the distribution (directories, files and what they are) * Overview of J2EE applications, roles, and development lifecycle * Improved CMP primer * Tools reference And a few other things. There's still much to come in the coming weeks though, documentation is high on our priority list. The added documenation will shortly be available for download in a zip, for local access. Regards, Karl Avedal
RE: OR mapping of table joins for CMP
If I have two tables and I would like to join them using CMP how would I accomplish that? So in essence I'm trying to do something like: select table1.id, table1.first_name, table1.job_id, table2.job_description from table1, tables2 where table1.job_id = table2.job_id; And perhaps any description on how to do the OR mapping for EJB. I have all of the books and can not seem to find the detail that I need to do CMP. Thanks, Cory At 03:55 PM 9/11/00 +0100, Joe Walnes wrote: Can somebody please point me to a good reference for managing joins across multiple tables while using CMP? There was a thread on the list that somebody pointed me to previously but it did not really give the information I needed. I just want to be able to specify tables and fields to do joins on with Orion for CMP. If you could go into a bit more detail about the problem, I'm sure someone could help you out. This might be what you're after: http://www.orionsupport.com/complex-or.html -Joe Walnes
Re: CMP / OR tutorial, info, etc?
This is exactly what I wanted to see in my previous post. At 01:45 PM 9/11/00 -0700, Kevin Duffey wrote: RE: classpath for third party tools Hi, I am finaly getting ready to make the dive into OR / CMP. To be honest, I don't know a whole heck of a lot about it. I do know though that I want to stick to J2EE based standards while building my own site. So instead of using JDBC 1, and trying to figure out some way to map database tables to my classes, storing, searching, deleting, etc..I would like to find out where I can get more info on exactly how to use OR and CMP. I would really like to start with the basics as I don't know much about designing tables, databases, etc. I need to learn the best way(s) to model entity beans after database tables, how CMP works, O/R, etc. So any tutorials online, or even a book, would be great. Also, how does Orion work with these? Is CMP and O/R a standard with J2EE, even though each vendor can implement them in their own way? Thanks.
Re: RMI-IIOP
Karl, Do you have an approximate timeframe for implementation of this feature? Thanks, Cory At 12:10 AM 9/9/00 +0200, Karl Avedal wrote: Hello Cory, RMI-IIOP is scheduled to be implemented for the full EJB 2.0 release but is not yet. Regards, Karl Avedal Cory Adams wrote: Has anybody implemented RMI-IIOP to interoperate from an EJB to a different system? If so how is it supported within ORION or does it totally depend upon the JDK's support for RMI-IIOP? Also how to you implement RMI-IIOP usage in an EJB? Can the container pool those connections. Thanks, Cory
OR mapping of table joins for CMP
Can somebody please point me to a good reference for managing joins across multiple tables while using CMP? There was a thread on the list that somebody pointed me to previously but it did not really give the information I needed. I just want to be able to specify tables and fields to do joins on with Orion for CMP. Thanks, Cory
RMI-IIOP
Has anybody implemented RMI-IIOP to interoperate from an EJB to a different system? If so how is it supported within ORION or does it totally depend upon the JDK's support for RMI-IIOP? Also how to you implement RMI-IIOP usage in an EJB? Can the container pool those connections. Thanks, Cory
Re: Calling Servlet from another servlet error using orion
When you use the forward methodology below how will the receiving Servlet
handle the request forwarded from another servlet? Is it handled by the
doGet or doPost or can it be forwarded to a specific method within the
BookDBServlet Servlet?
Thanks,
Cory
At 01:49 PM 9/6/00 +0200, Lars Heller wrote:
getServletConfig().getServletContext()
.getServlet("bookstore.BookDBServlet");
The method ServletContext.getServlet(String) is deprecated since version
2.1. In the spec it is stated, that servlet engines should always return
null.
Instead (for forwarding to this servlet), use the RequestDispatcher:
getServletConfig().getServletContext()
.getRequestDispatcher("bookstore.BookDBServlet")
.forward(request, response);
Re: JBuilder 4
Which version did you use of JBuilder 3.5? Was it standard, pro or enterprise? Did it offer the ability to build EAR and WAR files? Thanks, Cory At 02:29 PM 9/6/00 +0100, Chris Miller wrote: I'd tend to agree with Sven. My experiences with JBuilder 3.5 and Orion have been very positive, so I can't see why there would be any regressions with 4.0. But give people a chance to get hold of the thing and try it first! :-) - Original Message - From: "Sven van 't Veer" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Wednesday, September 06, 2000 12:36 PM Subject: Re: JBuilder 4 Cory Adams wrote: JBuilder 4.0 just came out and the Enterprise edition will let you develop fully J2EE compliant apps. Does anybody have any experience using this version of JBuilder 4 and Orion? Well, since it's 'just out' it will be hard to find anyone with experience. However, since you can debug j2ee apps in JBuilder-Orion with JB 3.5, I guess it will be possible with JBuilder 4 too. sven -- == Sven van 't Veer http://www.cachoeiro.net Java Developer [EMAIL PROTECTED] ==
JBuilder 4
JBuilder 4.0 just came out and the Enterprise edition will let you develop fully J2EE compliant apps. Does anybody have any experience using this version of JBuilder 4 and Orion? Thanks, Cory
Re: RMI vs. HTTPTunneling
Also RMI is supposed to automatically use http tunneling if it can not make a connection on a particular port. You have to install a proxying cgi function on your web server (behind the firewall) that will provide the forwarding. Check java.sun.com and search for HTTP Tunneling. Cory At 09:17 PM 8/28/95 -0400, Al Fogleson wrote: Both are protocols... in http tunneling you encapsulate some other protocol within http. thus you could make an RMI connection tunneled through http Al - Original Message - From: "Roman Kagan" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Monday, August 28, 2000 7:56 PM Subject: RMI vs. HTTPTunneling Hi! Maybe someone knows: What the difference in RMI vs. HTTPTunnelling ? Sincerely, Roman Kagan
Re: http session timeouts
For each user session add a datestamp at the session creation. For each
subsequent request that uses an existing session check the datestamp
against the current time. If the difference has exceeded your max session
timeout send the user to a relogin page that contains the message using the
RequestDispatcher to forward the request to your destination relogin page:
RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher("/relogin.html");
dispatcher.forward(request, response);
Also why the use of a bean when the HttpSession object should do the trick
for you?
Hope that helps.
Cory
At 09:18 PM 8/20/00 -0500, Todd McGrath wrote:
The site I'm working has a custom login component where users must have
a valid username/ password combination. I would like to redirect or
present a user with a message when a Http session timeout has
occurred. You know, "your session has expired, so you must re-login"
message or something similar.
I'm in the beginning stages of the code. So far, the app stores certain
information about the user in a http session Java Bean, so I'm thinking
of checking for the existence of this bean in a Controller servlet to
determine if the Http session has timed out:
if (javabean == null) {
String message = "Your session has timed out, please login again";
}
else ...
Any opinions on this? (including other, better ways to achieve this
functionality)
-Todd
RE: Performance
It is the HelloWorldServlet with the addition of a few lite mathematical operations and a counter. The testing tool is something I built to monitor http, smtp and gopher servers using a threaded Swing tool. Cory At 02:14 PM 8/21/00 -0700, Kevin Duffey wrote: Its impressive, but that depends on what your testing it with, and what the test is doing. Is it just a simple JSP page return with static html in it..or are you hitting the database such as a login process? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Cory Adams Sent: Sunday, August 20, 2000 9:33 PM To: Orion-Interest Subject: Performance I don't normally send gifs around but this is only 11 kb. It shows the orionconsole (1.2.0). Check the Hits averages for the last minute and hour. The machine is a Pentium III 650 (notebook), Orion 1.2.0, jdk 1.3 with two instances of the test app (each running a separate vm on the box as well) hitting a modified HelloWorldServlet that does several small calculations. Does anybody else think that is impressive performance or not? I don't have much to compare against. Thanks, Cory
Re: what are you missing in apache-like functionality?
But don't you think that would cause Orion to deviate from the Sun J2EE spec.? PHP is great to work with but it is definately not something that is anywhere close to being part of J2EE. You could implement many of the same types of PHP functions perhaps with custom TagLibs or rewrite to JSP. Cory At 08:21 AM 8/19/00 -0500, Andrew Panagos wrote: List So far 1) mod_rewrite 2) mod_expires 3) I would like php to the list so desired Apache to Orion wants. We have alot of investment in php files. It would be great to be able to use them with Orion instead of having to run Apache and Orion Andrew
Re: POLL: what are you missing in apache-like functionality?
Actually I'm looking heavily at Pramati. It costs more but has an integrated development environment for developing and deploying. The email support is really good as well. The added cost benefit goes a long way to getting a development shop up and running quickly. They also give a one month eval with email support. The thing that spooks me the most about Orion is of course the lack of docs but also some of the posts that I read on this list with regard to some of the more serious problems that I see people encountering. Orion looks like it could be great for servlets and maybe simple ejb deployments but I'm not sure that the docs, deployment tools and the overall package is ready for me to put into a production environment? Does anybody else have any experience with these guys? Thanks? Cory At 01:31 PM 8/19/00 +0200, Robert Krueger wrote: Hi, I was just getting curious how many of you fellow orion users out there have thought: "wow, what a great server, if only it had this feature xyz that I heavily used with apache". now to get things a little organized and maybe help evermind get a better picture of what their users would like I thought I'd start a little poll. maybe some of these things are so easy to implement that they will listen. let's give it a try. Poll Question: What apache (or other webserver) core or module functionality are you missing most in your daily work with orion? I'll start (ordered by importance): 1. mod_rewrite (just so simple and powerful, you can do almost anything with it) 2. mod_expires (absolute necessity to tweak the behaviour of high volume websites in terms of performance and correctness especially with all those proxies around) btw. if anyone has implemented stuff like that as filters and you're ready to share, it would be great if we could have a contrib area either at the orion or the orionsupport site. robert (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
