Why Entity EJBs?
Hi The more I study the J2EE technology, the more I wonder why I should use it. The main reasons why I would use it are these: - Forget about the database layer while only using CMP entity beans. - Faster. - Scalable. - Easier to manage transactions. - Clear separation between client-workflow-persistence (JSP - Session beans - Entity beans). In our current system we use simple JSP, JavaBeans and a few connections to our database. We have made a few mistakes but we envisage cleaning up the system by starting from scratch. It is important that we choose the right technology but I get more and more sceptical about the EJB technology. We have experienced, when doing listings from a search page, that reading from the database and instantiating a few beans (not EJBs) takes a long time. The fastest way is to loop the resultset in the JSP-page, but it does have a few drawbacks and I would prefer to use another architecture. I thought that the pooled entity beans would speed up the system and started to study EJB. Then, Richard Monson-Haefel states in his book that listings shall be done directly between the Session bean and the database. Otherwise it would be too slow. I don't want to bother with SQL anymore and I would like to forget about the database layer, but it seems very difficult to get away with this requirement. To communicate between the JSP, the Session beans and the Entity beans, I get advised to use Data Access Objects. If I were to ignore the Monson-Haefel advise I would first create a bunch of Entity beans from a finder method, instantiate a collection of DAOs and send them back to the requesting Session bean. I wonder what kind of performance I would get from this system? I guess that this can become very heavy weight. It will probably become even more heavy weight when n-m OR-mapping becomes available. This will force us into a solution were we would have to use clusters and the scalability features of EJB comes handy. Is this the strategy from Sun - to make us buy more SUN servers? Now, what did I miss? Is there something that I have completely misunderstood? Please tell me what strategy we should use while developing CMP entity beans with Orion's OR-mapping features. I have found that another paradigm and framework that will simplify the development and reduce the amount of SQL-coding. http://jrf.sourceforge.net/ejb.html http://jrf.sourceforge.net/ Why shouldn't we use this framework? Best regards /johan _ Do You Yahoo!? [EMAIL PROTECTED] - skaffa en gratis mailadress p http://mail.yahoo.se
Re: How to install 128 bit cert....
I am not sure because I tried it long time ago, but in my case this was caused by copy-paste operation on cert in my Explorer5 window. When I changed encoding in my Explorer5 settings it was O.K. Regards Petr - Original Message - From: mohan krishna [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, March 20, 2001 5:44 AM Subject: How to install 128 bit cert Hi to all, I have been following the how-to "Setting up a secure site using ssl" on Windows NT+jdk 1.3 and I get the following error C:\certificateskeytool -keystore keystore -keyalg "RSA" -import -trustcacerts - file my.host.com.cer -storepass 123456 keytool error: java.security.cert.CertificateException: Unsupported encoding 1.Plz let me know whether the problem is with ORION or with the cert? 2.Is ORION1.3.8 in a position to support 128bit encryption? 3.Have we to download / set any other things to make Orion to use 128bit? I have tried with Netscape 4.7 and Explorer 5. Any idea? Get free email and a permanent address at http://www.netaddress.com/?N=1
Re: Can anyone campare JRUN with Orion1.3.8
Sure, I've had to use JRun for a client and here's my experience with it:
JRun does not support hot deployments. Any deployment requires a server
restart.
JRun does not automatically pick up .war file changes. Really, I found war
file support to be minimal, compared to Orion. There's very little that
'drops in', everything has to be through the management console (in my
experience, they might provide for dynamic changes to configs, but it's
subtle and not something I could access!)
Orion performs much better
JRun does not support servlet 2.3 API (nor will they in their 3.1 release,
which is in beta right now).
There are small differences in JSP parsing:
Orion allows myTags:stuff
param1=%=request.getParameter("foo")%blahblah/myTags:stuff, JRun does
not (it barfs on the inner quotation mark)
JSP error reporting is much better in JRun.
The management console for JRun seems slick initially, but rapidly becomes
a pain in the ass if you're the kind of person who doesn't worship the
web, and believes that changing text config files is faster and better.
On Mon, 19 Mar 2001, waheed_rahuman wrote:
Can anyone using orion can campare the JRun webserver regarding
servlets,JSP and EJB with postgresql.
regards
waheed
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
RE: Dependents remove not supported
The PFD spec says that you do not need to specify a remove method (container will do that automatically) Having said all that, you should not ignore all the warnings about using dep objs. There's a VERY strong chance that they're being gotten rid of. I also suspect that because of that, Orion's impl of dependent objects won't have much effort or time put into it, until their fate is resolved one way or another. By the way, this isn't just 'mere speculation', the removal of dependent objects is something that many people directly involved with the expert group have hinted at. On Mon, 19 Mar 2001, Christian Billen wrote: RE: Dependents in 1-N don't go awayThanks, I found it 9.4.4.2 page 119 in EJB2.pdf, and tried to use it by putting the method remove in my DO : abstract remove(); however Orion doesn't seem to support it and pukes on startup: "Illegal abstract method in dependent class com.mytest.ejb.MyDo: public abstract void com.mytest.ejb.MyDo.remove()" bummer! that seriously make me reconsider using the whole thing, or is my method signature incorrect? Christian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Drury Sent: Sunday, March 18, 2001 1:58 PM To: Orion-Interest Subject: RE: Dependents in 1-N don't go away You may want to look at 9.4.4.2 in the proposed final draft which defines the remove() function of a DO. I don't have PD1 to tell you what section it is there. -tim -Original Message- From: Christian Billen [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 18, 2001 12:30 PM To: Orion-Interest Subject: RE: Dependents in 1-N don't go away Is that remove() method an abstract method to be implemented in the DO? they inherit Object and the only required method to implement on them is the deepCopy(), I don't see where the remove() method is or come from. Since they are Depedent by nature shouldn't the remove call on the parent set or collection remove them permanently as well in the design? maybe it is a bug in Orion ? Thanks, Christian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Drury Sent: Sunday, March 18, 2001 10:25 AM To: Orion-Interest Subject: RE: Dependents in 1-N don't go away I understand. You have removed the DO from the parents list, but you have not removed the DO from the database. This is because you did not call the removed method of the DO. Try: getDependents().remove(dependent); // remove DO from parent's list dependent.remove(); // remove DO from database/container -tim -Original Message- From: Christian Billen [mailto:[EMAIL PROTECTED]] Sent: Saturday, March 17, 2001 9:29 PM To: Orion-Interest Subject: RE: Dependents in 1-N don't go away Hi Tim, thanks for the info, by my problem is different my issue is I want to remove a dependent from the java.utill.Set in its parent object and that if I call getDependents().remove(dependent) from the parent object the dependent doesn't go away from the list (even though it has been found since I implemented the equal method) Any help on this is really greatly appreciated. Thanks, Christian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Drury Sent: Saturday, March 17, 2001 9:10 AM To: Orion-Interest Subject: RE: Dependents in 1-N don't go away Dependent objects (DO) do not go away automatically. There is an un-implemented option in the deployment descriptor called cascade-delete, but alas, it is unimplemented. The DO life-cycle is one of the main issues with DOs in the spec and one reason they may be changed. For now, just implement ejbRemove in your entity and DOs so they call the remove of their children. -tim -Original Message- From: Christian Billen [mailto:[EMAIL PROTECTED]] Sent: Friday, March 16, 2001 7:43 PM To: Orion-Interest Subject: Dependents in 1-N don't go away Hi everyone, I am having an issue with my 1-n dependents relationship. My dependents don't get deleted when I remove them from the cmr Set. I have a PhoneNumber dependent class which has a field type, countrycode, number, etc... I implemented the equal method in my class such that two phonenumber having the same type are equal, these type being like "business", "fax", "cell",
RE: Impossible getting the attention of the orion (support) team. Are they still around?
As of today, we receive the maillist directly again. Furthermore, I received my bugzilla account password and already entered our problem in bugzilla (bug 368). The mailserver problem thus seems to be resolved by orion (we didn't have to do anything). Thumbs up for orion for the quick response. Now if they could resolve our real problem (almost) just as quickly ... :-) All in all, my confidence in orion has been partly restored. Lets hope they get their application server support back into high speed soon. Ate -Original Message- From: Douma, Ate [mailto:[EMAIL PROTECTED]] Sent: Monday, March 19, 2001 12:47 PM To: Orion-Interest Subject: RE: Impossible getting the attention of the orion (support) team. Are they still around? FYI: I received a very quick response from Karl Avedal on me previous posting. It looks like their mail doesn't get through to our mailserver since they switched servers early january. We are again in contact and I'm very much relieved about that. Hopefully, we can resolve our problems quickly now. Ate Douma. -Original Message- From: Douma, Ate Sent: Monday, March 19, 2001 11:24 AM To: 'Orion-Interest' Subject: Impossible getting the attention of the orion (support) team. Are they still around? Hello all, I've been trying for weeks now getting any response from the orion team to no avail. First of all, I wanted to post a serious problem in Bugzilla but for that I need a account password. I've tried and tried, but never ever received a password after creating a new account or after requesting the account password to be send again. Then I tried sending a message directly to orion support. No response. Then I posted my problem to this list http://www.mail-archive.com/orion-interest@orionserver.com/msg 09692.html (Serious problem with Orion transaction processing: multiple connections used within a single transaction) februari 13, 2001, including a test case. I mailed this problem again to [EMAIL PROTECTED] februari 19, 2001. No response. I mailed Magnus Stenman directly on februari 27 explaining these problems and requesting access to Bugzilla. No response. I'm not clear what options are left, but we are seriously considering other application servers right now as this kind of support is really not acceptable in the long run. At least a simple acknowledgment of the reception of the problem would give us the idea that someone is actually monitoring [EMAIL PROTECTED] mailbox. It doesn't seems to be the case right now. Having to switch to another application server is something I really don't like. Overall I like the orion application server very much (certainly for development). We consider the bug we encountered as very, very serious which will have to be solved otherwise we just don't have another option. The bad (non-existing?) support makes this truly serious. If anyone did have some contact with the orion team (mailbased or otherwise) in the last month's I would be very grateful to know how they did that. The same question I have for anyone how was able to create a Bugzilla account recently. Lastly, somewhat less important: does anyone receive the orion-interest maillist still directly to their mailbox? Since Januari 11, 2001, we didn't receive any mail anymore, and can therefore only access the maillist at http://www.mail-archive.com/orion-interest@orionserver.com. (re)Subscribing again didn't help a bit, not even using new mailaccount. Ate +---+ | Ate Douma iWise B.V. | |Hoofdstraat 2a-4a | | mailto:[EMAIL PROTECTED] 4941 DC Raamsdonksveer | | Phone ++31 (0)162 517167 The Netherlands| | Fax++31 (0)162 516872 http://www.iwise.nl| +---+
Re: Hypersonic website / docs
Try Mimer SQL. Free for developer. You can also find a type 4 JDBC driver from their developer website: http://developer.mimer.se/. Julian Richardson wrote: Hi, What's the correct url for the hypersonic website? I thought the official one was hsql.oron.ch, which I'm sure worked until a few weeks ago but doesn't now - I get a forbidden error when accessing it. Interestingly it comes back with www.hypersonicsql.com in the error page, but that site doesn't seem to exist in any form... What gives? Is anyone on this list anything to do with Hypersonic and knows what's happening with the site (it's been this way for a few days, and I've just double-checked that it's not our web proxy) Failing any kind of online help, are there docs buried within the Orion document tree for Hypersonic? I couldn't see anything at all. What I'm actually after is some kind of command-line SQL client - does Hypersonic have one? I know it's got that applet for administration (does that even come as part of the Orion install?) but I don't want to fire up a browser or mess around with appletviewer unless I have to. I do have a homebrew client but it was written against Oracle so I don't know (yet) what'll be involved in getting it to work with Hypersonic... thanks Jules begin:vcard n:; x-mozilla-html:FALSE url:www.snt.com.my org:SiliconNet Technologies Sdn Bhd;Development version:2.1 email;internet:[EMAIL PROTECTED] title:IS Executive adr;quoted-printable:;;Lot 352, Lorong 12, Jalan Rubber=0D=0A;Kuching;Sarawak;93400;Malaysia fn:Richard Goh Muk Ling end:vcard
Re: Why Entity EJBs?
Hi! I fully agree with your opinion. We in our company have decided to use ONLY stateful session beans(SSB) for database access. Yes, it is necessary to create some proprietary persistence stuff, but we see a lot of benefit from it mainly because there is only one instance of SSB per database table (or more tables) for each user. Each finder or query request for database row (also create, delete,..) results only in changing state in appropriate SSB. This solution is very simple. For me the question is why to have separate instances of Entity beans for each database row. All methods are the same for all rows, aren't they? What is changing are the fields. So the same effect could be achieved through changing the state in one instance of session bean which represents one entity (database table,...). Yes, I know that one instance of entity bean can serve many users, but to implement simple task like - FOR EACH Item: Item.price = Item.price + 10. END. - through some collections of thousands or million remote objects is for me inacceptable. Regards Petr - Original Message - From: Johan Lundberg [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Tuesday, March 20, 2001 8:22 AM Subject: Why Entity EJBs? Hi The more I study the J2EE technology, the more I wonder why I should use it. The main reasons why I would use it are these: - Forget about the database layer while only using CMP entity beans. - Faster. - Scalable. - Easier to manage transactions. - Clear separation between client-workflow-persistence (JSP - Session beans - Entity beans). In our current system we use simple JSP, JavaBeans and a few connections to our database. We have made a few mistakes but we envisage cleaning up the system by starting from scratch. It is important that we choose the right technology but I get more and more sceptical about the EJB technology. We have experienced, when doing listings from a search page, that reading from the database and instantiating a few beans (not EJBs) takes a long time. The fastest way is to loop the resultset in the JSP-page, but it does have a few drawbacks and I would prefer to use another architecture. I thought that the pooled entity beans would speed up the system and started to study EJB. Then, Richard Monson-Haefel states in his book that listings shall be done directly between the Session bean and the database. Otherwise it would be too slow. I don't want to bother with SQL anymore and I would like to forget about the database layer, but it seems very difficult to get away with this requirement. To communicate between the JSP, the Session beans and the Entity beans, I get advised to use Data Access Objects. If I were to ignore the Monson-Haefel advise I would first create a bunch of Entity beans from a finder method, instantiate a collection of DAOs and send them back to the requesting Session bean. I wonder what kind of performance I would get from this system? I guess that this can become very heavy weight. It will probably become even more heavy weight when n-m OR-mapping becomes available. This will force us into a solution were we would have to use clusters and the scalability features of EJB comes handy. Is this the strategy from Sun - to make us buy more SUN servers? Now, what did I miss? Is there something that I have completely misunderstood? Please tell me what strategy we should use while developing CMP entity beans with Orion's OR-mapping features. I have found that another paradigm and framework that will simplify the development and reduce the amount of SQL-coding. http://jrf.sourceforge.net/ejb.html http://jrf.sourceforge.net/ Why shouldn't we use this framework? Best regards /johan _ Do You Yahoo!? [EMAIL PROTECTED] - skaffa en gratis mailadress p http://mail.yahoo.se
RE: Dependents remove not supported
Christian look at : http://www.mail-archive.com/orion-interest@orionserver/msg113324.html Not a very good solution, but it is one. regards /Theis.
RE: How to install 128 bit cert....
If you are getting the Cert from Thawt make sure that you are selecting the "Test SSL Chained Cert" If you are selecting the 128 it wont work I just tried it. You do get 128 Bit Encryption if you use the Chained Cert.. -Original Message- From: mohan krishna [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 12:45 AM To: Orion-Interest Cc: [EMAIL PROTECTED] Subject: How to install 128 bit cert Hi to all, I have been following the how-to "Setting up a secure site using ssl" on Windows NT+jdk 1.3 and I get the following error C:\certificateskeytool -keystore keystore -keyalg "RSA" -import -trustcacerts - file my.host.com.cer -storepass 123456 keytool error: java.security.cert.CertificateException: Unsupported encoding 1.Plz let me know whether the problem is with ORION or with the cert? 2.Is ORION1.3.8 in a position to support 128bit encryption? 3.Have we to download / set any other things to make Orion to use 128bit? I have tried with Netscape 4.7 and Explorer 5. Any idea? Get free email and a permanent address at http://www.netaddress.com/?N=1
Fwd: Why Entity EJBs?
Hi Johan. two-pence-worth I've been developing EJBs in a very (a) intensive and (b) short development cycle for about 5 months now. I've found that my methodology has leant towards what the JRF guys are talking about, but in a less formal way. From the backend forwards: I tend to use entity beans for storing/retrieving and most manipulation of data - ie. I have quite "fat" beans rather than just purely getters and setters. I then use session beans for workflow that doesn't seem to belong with any particular single bean, such as generating reports or anything that requires a few home interfaces' finders. I also use session beans for their transactional integrity when populating new beans from an HTML (JSP) form, especially when several beans will be created from a single form's contents and I want the whole lot to be atomic. We tend to use JSP and regular form beans for most of the other workflow stuff, and sometimes we'll have quite complex finder methods in the EJBs that join across several tables. The benefits to EJBs, and specifically orion, for me are: - Database independence: we're deploying on MS SQL Server but it's trivial to deploy to eg. Oracle for scalability or Hypersonic for local testing. - Network independence: I need to change no code to cluster orion on several hosts and also to split its responsibilities between being a web server on one host talking to another orion instance being an app server on another host. - Speed of development: I don't have to worry about how or where my data is being stored - I have orion's _fantastic_ OR mapping to do that for me. It seems to me that the JRF is taking the "best practice" approach, which is a fine and noble thing to do, but then overcomplicating the issue by wandering off into its own specification. All my SQL for each package is in one place (orion-ejb-jar.xml), and I don't have to worry about scalability or portability. If it says J2EE on the box, it'll usually have J2EE in the box. (Apart from the usual niggles with app servers being behind spec - again orion is pretty good for being up-to-date in this regard.) So I have all the benefits of JRF but with the backing of a technology as widely-adopted as J2EE. /two-pence-worth Disclaimer: I don't work for orion, I just love their product. And J2EE has been the most useful technology I've discovered since I picked up OO about 10 years ago! Regards, Dan. ps. That passage in the EJB book about having a session bean talk straight to a database is again (imo) a throwback to the technology being pretty immature and inefficient when the book was written. I have had no problems with orion's ability to manipulate and cache data for me comparably well with direct database access - but with the added benefit of lots of data integrity checking and no SQL on my part. In fact you get two levels of caching - the database and the app server. Date: Tue, 20 Mar 2001 09:22:52 +0100 (CET) From: Johan Lundberg [EMAIL PROTECTED] Subject: Why Entity EJBs? To: Orion-Interest [EMAIL PROTECTED] X-Mailer: Orion ListServer Reply-To: Orion-Interest [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] X-MIME-Autoconverted: from 8bit to quoted-printable by druid.evermind.net id KAA23094 Hi The more I study the J2EE technology, the more I wonder why I should use it. The main reasons why I would use it are these: - Forget about the database layer while only using CMP entity beans. - Faster. - Scalable. - Easier to manage transactions. - Clear separation between client-workflow-persistence (JSP - Session beans - Entity beans). In our current system we use simple JSP, JavaBeans and a few connections to our database. We have made a few mistakes but we envisage cleaning up the system by starting from scratch. It is important that we choose the right technology but I get more and more sceptical about the EJB technology. We have experienced, when doing listings from a search page, that reading from the database and instantiating a few beans (not EJBs) takes a long time. The fastest way is to loop the resultset in the JSP-page, but it does have a few drawbacks and I would prefer to use another architecture. I thought that the pooled entity beans would speed up the system and started to study EJB. Then, Richard Monson-Haefel states in his book that listings shall be done directly between the Session bean and the database. Otherwise it would be too slow. I don't want to bother with SQL anymore and I would like to forget about the database layer, but it seems very difficult to get away with this requirement. To communicate between the JSP, the Session beans and the Entity beans, I get advised to use Data Access Objects. If I were to ignore the Monson-Haefel advise I would first create a bunch of Entity beans from a finder method, instantiate a collection of DAOs and send them back to the requesting Session bean. I wonder what kind of performance I would get from this system? I
Re[2]: Character encoding problem
but bugzilla sad that it's fixed is it mean that i can get 1.4.8 through autoupdate?
Re: Thanks alot and one more doubt
Hi
Now, I am developing an e-commerce site for of my own, which is fully depend
on java and my server is currently Orion.1.3.8 and i am using JSP as my
server pages.
The problem which i am facing is the following:
My application consists of six steps for customizing the car.
In designing process the client can jump between the steps
when i use METHOD POST in the forms its giving me a blank page.
So now i am using METHOD =GET and its working great.
But its funny, to pass all these value in the address bar like
http://211.22.11.32/jsp-bin/colorcar.jsp?body='red'door='black'checked='n
o'model='123'
and this problem is coming only in the remote server when i tried same jsp
file in the local orion server its working great, but when i upload this to
my remote server it giving me the blank page.
What i can do for this..
Any suggestion whether i have to change my server to JRun or any solutions
is there
Please send me your suggestion i am expecting your reply as soon as possible
Thanking you
Regards
waheed rahuman
Sure, I've had to use JRun for a client and here's my experience with
it:
JRun does not support hot deployments. Any deployment requires a server
restart.
JRun does not automatically pick up .war file changes. Really, I found
war
file support to be minimal, compared to Orion. There's very little that
'drops in', everything has to be through the management console (in my
experience, they might provide for dynamic changes to configs, but it's
subtle and not something I could access!)
Orion performs much better
JRun does not support servlet 2.3 API (nor will they in their 3.1
release,
which is in beta right now).
There are small differences in JSP parsing:
Orion allows myTags:stuff
param1=%=request.getParameter("foo")%blahblah/myTags:stuff, JRun
does
not (it barfs on the inner quotation mark)
JSP error reporting is much better in JRun.
The management console for JRun seems slick initially, but rapidly
becomes
a pain in the ass if you're the kind of person who doesn't worship the
web, and believes that changing text config files is faster and better.
On Mon, 19 Mar 2001, waheed_rahuman wrote:
Can anyone using orion can campare the JRun webserver regarding
servlets,JSP and EJB with postgresql.
regards
waheed
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Autostarted client hangs
Hello, With 1.4.5, I'm having some timing issues with autostarted application clients. Apparently, they get invoked before Orion has fully started and therefore hang when performing a JNDI lookup. Is there a workaround? I recall reading a similar message before but can't find it now. Thanks, Vidur
RE: Impossible getting the attention of the orion (support) team. Are they still around?
Is release 1.4.8 already available, because I'm having the same bug? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Douma, Ate Sent: mardi, 20. mars 2001 14:42 To: Orion-Interest Subject: RE: Impossible getting the attention of the orion (support) team. Are they still around? FYI: My reported bug was fixed by the orion team (to be release in 1.4.8) within 2.5 hours after entering it into Bugzilla. Can't really ask for more, can I? Ate -Original Message- From: Douma, Ate [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 11:04 AM To: Orion-Interest Subject: RE: Impossible getting the attention of the orion (support) team. Are they still around? As of today, we receive the maillist directly again. Furthermore, I received my bugzilla account password and already entered our problem in bugzilla (bug 368). The mailserver problem thus seems to be resolved by orion (we didn't have to do anything). Thumbs up for orion for the quick response. Now if they could resolve our real problem (almost) just as quickly ... :-) All in all, my confidence in orion has been partly restored. Lets hope they get their application server support back into high speed soon. Ate -Original Message- From: Douma, Ate [mailto:[EMAIL PROTECTED]] Sent: Monday, March 19, 2001 12:47 PM To: Orion-Interest Subject: RE: Impossible getting the attention of the orion (support) team. Are they still around? FYI: I received a very quick response from Karl Avedal on me previous posting. It looks like their mail doesn't get through to our mailserver since they switched servers early january. We are again in contact and I'm very much relieved about that. Hopefully, we can resolve our problems quickly now. Ate Douma. -Original Message- From: Douma, Ate Sent: Monday, March 19, 2001 11:24 AM To: 'Orion-Interest' Subject: Impossible getting the attention of the orion (support) team. Are they still around? Hello all, I've been trying for weeks now getting any response from the orion team to no avail. First of all, I wanted to post a serious problem in Bugzilla but for that I need a account password. I've tried and tried, but never ever received a password after creating a new account or after requesting the account password to be send again. Then I tried sending a message directly to orion support. No response. Then I posted my problem to this list http://www.mail-archive.com/orion-interest@orionserver.com/msg 09692.html (Serious problem with Orion transaction processing: multiple connections used within a single transaction) februari 13, 2001, including a test case. I mailed this problem again to [EMAIL PROTECTED] februari 19, 2001. No response. I mailed Magnus Stenman directly on februari 27 explaining these problems and requesting access to Bugzilla. No response. I'm not clear what options are left, but we are seriously considering other application servers right now as this kind of support is really not acceptable in the long run. At least a simple acknowledgment of the reception of the problem would give us the idea that someone is actually monitoring [EMAIL PROTECTED] mailbox. It doesn't seems to be the case right now. Having to switch to another application server is something I really don't like. Overall I like the orion application server very much (certainly for development). We consider the bug we encountered as very, very serious which will have to be solved otherwise we just don't have another option. The bad (non-existing?) support makes this truly serious. If anyone did have some contact with the orion team (mailbased or otherwise) in the last month's I would be very grateful to know how they did that. The same question I have for anyone how was able to create a Bugzilla account recently. Lastly, somewhat less important: does anyone receive the orion-interest maillist still directly to their mailbox? Since Januari 11, 2001, we didn't receive any mail anymore, and can therefore only access the maillist at http://www.mail-archive.com/orion-interest@orionserver.com. (re)Subscribing again didn't help a bit, not even using new mailaccount. Ate +---+ | Ate Douma iWise B.V. | |Hoofdstraat 2a-4a | | mailto:[EMAIL PROTECTED] 4941 DC Raamsdonksveer | | Phone ++31 (0)162 517167 The Netherlands| | Fax++31 (0)162 516872 http://www.iwise.nl| +---+
Re: Creating subscribers in JMS
i manage to create a subscriber using topicSession.createSubscriber(Topic, null, false), I think i've seen a bug reported for the topicSession.createSubscriber(Topic), I'm using orion1.4.5, however, I get this error javax.jms.InvalidDestinationException: Invalid topic, when trying to create a subscriber using a TemporaryTopic, Is this a bug I have written a test case which i will submit to bugzilla. regards colin - Original Message - From: "Vidur Dhanda" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Monday, March 19, 2001 3:40 PM Subject: Creating subscribers in JMS Hello, Is it legal to call topicSession.createSubscriber(Topic) on a TopicSession that was created via topicConnection.createTopicSession(...) after the topicConnection has been started? In 1.4.5 and 1.4.7 Orion hangs at the createSubscriber call. Thanks, Vidur -- Vidur Dhanda Active Solutions tel: 617/566-1252 [EMAIL PROTECTED] www.active-solutions-inc.com
Java Mail and javax.activation.DataSource
Hello all, I'm setting up J2EE program and I'm having trouble getting the Java mail to work. I am getting a java.lang. NoClassDefFoundError: javax/activation/DataSource error when I call Message msg = new MimeMessage(session); Everything else is set up and my code is nearly identical to the ATM example. My mailing code is in a stateless session bean. Anyone see anything like this before? Jonathan Bricker Lilly Research Labs Java ATG
Thanks alot and one
- Original Message -
From: Hani Suleiman [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Tuesday, March 20, 2001 1:19 PM
Subject: Re: Can anyone campare JRUN with Orion1.3.8
Sure, I've had to use JRun for a client and here's my experience with it:
JRun does not support hot deployments. Any deployment requires a server
restart.
JRun does not automatically pick up .war file changes. Really, I found war
file support to be minimal, compared to Orion. There's very little that
'drops in', everything has to be through the management console (in my
experience, they might provide for dynamic changes to configs, but it's
subtle and not something I could access!)
Orion performs much better
JRun does not support servlet 2.3 API (nor will they in their 3.1 release,
which is in beta right now).
There are small differences in JSP parsing:
Orion allows myTags:stuff
param1=%=request.getParameter("foo")%blahblah/myTags:stuff, JRun does
not (it barfs on the inner quotation mark)
JSP error reporting is much better in JRun.
The management console for JRun seems slick initially, but rapidly becomes
a pain in the ass if you're the kind of person who doesn't worship the
web, and believes that changing text config files is faster and better.
On Mon, 19 Mar 2001, waheed_rahuman wrote:
Can anyone using orion can campare the JRun webserver regarding
servlets,JSP and EJB with postgresql.
regards
waheed
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
RE: Impossible getting the attention of the orion (support) team. Are they still around?
You're right - they're useless! What were they doing for the other 2 1/4 hours is what I want to know. At 14:41 20/03/2001 +0100, you wrote: FYI: My reported bug was fixed by the orion team (to be release in 1.4.8) within 2.5 hours after entering it into Bugzilla. Can't really ask for more, can I? Ate -Original Message- From: Douma, Ate [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 11:04 AM To: Orion-Interest Subject: RE: Impossible getting the attention of the orion (support) team. Are they still around? As of today, we receive the maillist directly again. Furthermore, I received my bugzilla account password and already entered our problem in bugzilla (bug 368). The mailserver problem thus seems to be resolved by orion (we didn't have to do anything). Thumbs up for orion for the quick response. Now if they could resolve our real problem (almost) just as quickly ... :-) All in all, my confidence in orion has been partly restored. Lets hope they get their application server support back into high speed soon. Ate -Original Message- From: Douma, Ate [mailto:[EMAIL PROTECTED]] Sent: Monday, March 19, 2001 12:47 PM To: Orion-Interest Subject: RE: Impossible getting the attention of the orion (support) team. Are they still around? FYI: I received a very quick response from Karl Avedal on me previous posting. It looks like their mail doesn't get through to our mailserver since they switched servers early january. We are again in contact and I'm very much relieved about that. Hopefully, we can resolve our problems quickly now. Ate Douma. -Original Message- From: Douma, Ate Sent: Monday, March 19, 2001 11:24 AM To: 'Orion-Interest' Subject: Impossible getting the attention of the orion (support) team. Are they still around? Hello all, I've been trying for weeks now getting any response from the orion team to no avail. First of all, I wanted to post a serious problem in Bugzilla but for that I need a account password. I've tried and tried, but never ever received a password after creating a new account or after requesting the account password to be send again. Then I tried sending a message directly to orion support. No response. Then I posted my problem to this list http://www.mail-archive.com/orion-interest@orionserver.com/msg 09692.html (Serious problem with Orion transaction processing: multiple connections used within a single transaction) februari 13, 2001, including a test case. I mailed this problem again to [EMAIL PROTECTED] februari 19, 2001. No response. I mailed Magnus Stenman directly on februari 27 explaining these problems and requesting access to Bugzilla. No response. I'm not clear what options are left, but we are seriously considering other application servers right now as this kind of support is really not acceptable in the long run. At least a simple acknowledgment of the reception of the problem would give us the idea that someone is actually monitoring [EMAIL PROTECTED] mailbox. It doesn't seems to be the case right now. Having to switch to another application server is something I really don't like. Overall I like the orion application server very much (certainly for development). We consider the bug we encountered as very, very serious which will have to be solved otherwise we just don't have another option. The bad (non-existing?) support makes this truly serious. If anyone did have some contact with the orion team (mailbased or otherwise) in the last month's I would be very grateful to know how they did that. The same question I have for anyone how was able to create a Bugzilla account recently. Lastly, somewhat less important: does anyone receive the orion-interest maillist still directly to their mailbox? Since Januari 11, 2001, we didn't receive any mail anymore, and can therefore only access the maillist at http://www.mail-archive.com/orion-interest@orionserver.com. (re)Subscribing again didn't help a bit, not even using new mailaccount. Ate +---+ | Ate Douma iWise B.V. | |Hoofdstraat 2a-4a | | mailto:[EMAIL PROTECTED] 4941 DC Raamsdonksveer | | Phone ++31 (0)162 517167 The Netherlands| | Fax++31 (0)162 516872 http://www.iwise.nl| +---+ -- Dan North VP Development - Cadrion Software Ltd - +44 (0)20 7440 9550 CONFIDENTIALITY This e-mail and any attachments are confidential and may also be
communication link failure
Hello all! I've got an application-level object that grabs a pool of database connections (MySQL using the mm.mysql JDBC driver). All works well until there is not activity for some extended period of time (overnight) and then all attempts to access the database get "communication link failure" errors. Is there any way to configure Orion or MySQL to not give up on a database connection. Or do I have to move the connections to some other level. I know the app objects are surviving because I can query them, but just can't reestablish with the db. Anyone else have similar problems or any ideas??? -- -Geoff Marshall, Director of Development ... t e r r a s c o p e (415) 951-4944 54 Mint Street, Suite 110 direct (415) 625-0349 San Francisco, CA 94103 fax (415) 625-0306 ...
RE: Customizing the web authentication service
Title: Customizing the web authentication service Sun specifically leaves security mapping to each vendor/platform. The only thing that's specified is roles, but how do they map really it's up to the vendor and more than often is platform dependant (especially with Windows Auth) HTH JP -Original Message-From: elephantwalker [mailto:[EMAIL PROTECTED]]Sent: Monday, March 19, 2001 11:49 PMTo: Orion-InterestSubject: RE: Customizing the web authentication service Ben, Sun has specified the way security should behave, but not the implementation. Each j2ee vendor has chosen a different method, so it is truly one pain in the "arse" (forgive my old english). Regards, Elephantwalker -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ben WarnerSent: Monday, March 19, 2001 6:41 PMTo: Orion-InterestSubject: RE: Customizing the web authentication service Thanks, my passwords in the database are encrypted by a one way hash algorithm so I don't think this DataSourceUserManager will do all that I want. I have found and read the thread on "Custom UserManager" in this list and have deciphered the hard truth that I will have to implement my own UserManager... RoleManager... User etc From this and other threads on similar topics I have also concluded that there is no J2EE standard for defining and using your own Authentication module. Is someone able to confirm this for me with certainty? regards, bw. -Original Message-From: Magnus Rydin [mailto:[EMAIL PROTECTED]]Sent: Monday, March 19, 2001 5:51 PMTo: Orion-InterestSubject: SV: Customizing the web authentication service Take a look at http://www.orionsupport.com/articles/datasourceusermanager.html WR -Ursprungligt meddelande-Från: Ben Warner [mailto:[EMAIL PROTECTED]]Skickat: den 18 mars 2001 20:00Till: Orion-InterestÄmne: Customizing the web authentication service Hi, I'm trying to do something simple but I'm frustrated by my lack of success in finding information about it. I have scoured the list, the web, J2EE doco and would appreciate any information that may help me. Thanks in advance. I'm running a J2EE application in orion using form based authentication. The problem is that users are authenticated by the webserver according to the contents of the principals.xml file for my application. In my application users (including username password) are stored in the database and I don't want to use the principals.xml file to store all my user logins. What I want is for the webserver to call my own custom authentication method to authenticate the user and let me decide if the login is valid or not and set the appropriate user principal in the session if it is valid. I'm sure this has been done a million times... I must be looking in the wrong places... Thanks again, bw.
Re: communication link failure
Geoff Marshall ([EMAIL PROTECTED]) wrote: Hello all! I've got an application-level object that grabs a pool of database connections (MySQL using the mm.mysql JDBC driver). All works well until there is not activity for some extended period of time (overnight) and then all attempts to access the database get "communication link failure" errors. Is there any way to configure Orion or MySQL to not give up on a database connection. Or do I have to move the connections to some other level. I know the app objects are surviving because I can query them, but just can't reestablish with the db. Anyone else have similar problems or any ideas??? I was just reading the mm documentation the other day, and as I recall there's a parameter that can be set in the jdbc URL that tells it to retry opening the connection to mysql if the connection has closed. The parameter defaults to false, i.e., not retrying. Gary -- -Geoff Marshall, Director of Development ... t e r r a s c o p e (415) 951-4944 54 Mint Street, Suite 110 direct (415) 625-0349 San Francisco, CA 94103 fax (415) 625-0306 ...
RE: Sharing sessions between sites
I hope this helps. I manage this by making sure that all URLs used in the web app are absolute (of course they can be absolute and still be dynamic). and include the appropriate protocol. This of course includes form actions. Then I can enforce that certain portions of the web app are only accessible via HTTPS by including the something like this in my web.xml: security-constraint web-resource-collection web-resource-nameyour-resource/web-resource-name descriptionyour-desc/description url-pattern/root/page.jsp/url-pattern /web-resource-collection auth-constraint descriptionyour-desc/description role-nameuser-or-whatever/role-name /auth-constraint user-data-constraint descriptionyour-desc/description transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint Now the server enforces that the url indicated by the security constraint can only be delivered by HTTPS. BW Russ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Krevs Sent: Tuesday, March 20, 2001 12:12 AM To: Orion-Interest Subject: RE: Sharing sessions between sites Hi all - just worked this one out I think The shared attribute i think allows 2 web apps THAT HAVE THE SAME NAME to share sessions As soon as I specified default-web-app application="sectest" name="sectest-web" shared="true"/ as the default web app in both web-site.xml files then session sharing started to work I can now run a https and http version of my web app at the same time and have sessions shared between the 2 web apps The only thing I have to work out now is how to elegantly intercept requests, work out whether they should be using https or http, and then redirect them to use the correct protocol I thought that maybe servlet filtering would be a good way of doing this? eg any url that contains "/secure" in it could be redirected to https, while all others would use plain old http. Has anyone done this before? Anyone have any good examples/ideas? Thanks Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Krevs Sent: Tuesday, 20 March 2001 1:23 PM To: Orion-Interest Subject: Sharing sessions between sites I am having a few problems sharing sessions between a secure and a non-secure web site Having read various posts to the forum I thought that adding shared="true" to the default-web-app element in each web-site.xml would do the trick. Not for me. Each web site is creating its own session when it is hit for the first time (within the same browser window) So... I have 2 web apps. They both use the same application (as specified in server.xml). Each web app has its own web-site.xml One of the web apps is secured ie SSL. web-site.xml for the non-secure site is as follows -- ?xml version="1.0"? !DOCTYPE web-site PUBLIC "Orion Web-site" "http://www.orionserver.com/dtds/web-site.dtd" web-site host="[ALL]" port="80" display-name="SecTest site" default-web-app application="sectest" name="sectest-web" shared="true" load-on-startup="true"/ access-log path="log/default-web-access.log" / /web-site web-site.xml for the secure site is as follows -- ?xml version="1.0"? !DOCTYPE web-site PUBLIC "Orion Web-site" "http://www.orionserver.com/dtds/web-site.dtd" web-site host="[ALL]" secure="true" display-name="SecTest secure site" default-web-app application="sectest" name="sectestsecure-web" shared="true" load-on-startup="true"/ ssl-config keystore="keystore" keystore-password="123456" / access-log path="log/default-web-access.log" / /web-site Can anyone see what I'm doing wrong? I assume what I'm trying to do is possible. Thanks Matt
RE: Why Entity EJBs?
I also am questioning entity beans, after 5 months of intensive development with them. If you run Hypersonic in server mode and watch the sql output to the console, it should be readily apparent why... CMP produces *WAY* too many queries for fine-grained entity beans. The biggest problem is finder methods. Since all beans are lazy-loaded, iterating through the finder results of 1000 beans will produce 1001 SQL calls. There isn't any reason specwise that beans cannot be eager-loaded, but few (if any) appservers seem to support this. Does anyone know if there is any support for eager-loading of finder results in Orion? There doesn't appear to be from the documentation. I'm really disappointed in the entity bean concept. CMP should give us faster development times, faster code (with caching), and database independence, but at the moment we get *none* of the above. By stating in the blueprints that entity beans should only model course-grained objects and _not_ "one row of the table" they are effectively saying DO NOT USE CMP, because what is a CMP bean if not one row of a table? I noticed that most of the new J2EE patterns Sun recently posted are aimed at BMP. Sun's schizophrenia on this really pisses me off; with one face they like to show off entity beans and CMP because MS doesn't have it, with another they tell us to go back to the bronze age of handwritten SQL because the technology doesn't work. Gr. Jeff -Original Message- From: Dan North [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 4:41 AM To: Orion-Interest Subject: Fwd: Why Entity EJBs? Hi Johan. two-pence-worth I've been developing EJBs in a very (a) intensive and (b) short development cycle for about 5 months now. I've found that my methodology has leant towards what the JRF guys are talking about, but in a less formal way. From the backend forwards: I tend to use entity beans for storing/retrieving and most manipulation of data - ie. I have quite "fat" beans rather than just purely getters and setters. I then use session beans for workflow that doesn't seem to belong with any particular single bean, such as generating reports or anything that requires a few home interfaces' finders. I also use session beans for their transactional integrity when populating new beans from an HTML (JSP) form, especially when several beans will be created from a single form's contents and I want the whole lot to be atomic. We tend to use JSP and regular form beans for most of the other workflow stuff, and sometimes we'll have quite complex finder methods in the EJBs that join across several tables. The benefits to EJBs, and specifically orion, for me are: - Database independence: we're deploying on MS SQL Server but it's trivial to deploy to eg. Oracle for scalability or Hypersonic for local testing. - Network independence: I need to change no code to cluster orion on several hosts and also to split its responsibilities between being a web server on one host talking to another orion instance being an app server on another host. - Speed of development: I don't have to worry about how or where my data is being stored - I have orion's _fantastic_ OR mapping to do that for me. It seems to me that the JRF is taking the "best practice" approach, which is a fine and noble thing to do, but then overcomplicating the issue by wandering off into its own specification. All my SQL for each package is in one place (orion-ejb-jar.xml), and I don't have to worry about scalability or portability. If it says J2EE on the box, it'll usually have J2EE in the box. (Apart from the usual niggles with app servers being behind spec - again orion is pretty good for being up-to-date in this regard.) So I have all the benefits of JRF but with the backing of a technology as widely-adopted as J2EE. /two-pence-worth Disclaimer: I don't work for orion, I just love their product. And J2EE has been the most useful technology I've discovered since I picked up OO about 10 years ago! Regards, Dan. ps. That passage in the EJB book about having a session bean talk straight to a database is again (imo) a throwback to the technology being pretty immature and inefficient when the book was written. I have had no problems with orion's ability to manipulate and cache data for me comparably well with direct database access - but with the added benefit of lots of data integrity checking and no SQL on my part. In fact you get two levels of caching - the database and the app server. Date: Tue, 20 Mar 2001 09:22:52 +0100 (CET) From: Johan Lundberg [EMAIL PROTECTED] Subject: Why Entity EJBs? To: Orion-Interest [EMAIL PROTECTED] X-Mailer: Orion ListServer Reply-To: Orion-Interest [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] X-MIME-Autoconverted: from 8bit to quoted-printable by druid.evermind.net id KAA23094 Hi The more I study the J2EE technology, the more I wonder why I should use it.
RE: How to install 128 bit cert....
The problem for me was the the type selection (as noted below) and the cert file NEEDS a carriage return at the end of it. Just open it up in an editor and go to the end of the file and hit enter once or twice. -Original Message- From: McLellan, Richard [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 5:14 AM To: Orion-Interest Subject: RE: How to install 128 bit cert If you are getting the Cert from Thawt make sure that you are selecting the "Test SSL Chained Cert" If you are selecting the 128 it wont work I just tried it. You do get 128 Bit Encryption if you use the Chained Cert.. -Original Message- From: mohan krishna [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 12:45 AM To: Orion-Interest Cc: [EMAIL PROTECTED] Subject: How to install 128 bit cert Hi to all, I have been following the how-to "Setting up a secure site using ssl" on Windows NT+jdk 1.3 and I get the following error C:\certificateskeytool -keystore keystore -keyalg "RSA" -import -trustcacerts - file my.host.com.cer -storepass 123456 keytool error: java.security.cert.CertificateException: Unsupported encoding 1.Plz let me know whether the problem is with ORION or with the cert? 2.Is ORION1.3.8 in a position to support 128bit encryption? 3.Have we to download / set any other things to make Orion to use 128bit? I have tried with Netscape 4.7 and Explorer 5. Any idea? Get free email and a permanent address at http://www.netaddress.com/?N=1
RE: Dependents remove not supported
Title: RE: Dependents remove not supported It doesn't support ejbCreate either. The container never calls this method and if you have arguments (i.e. ejbCreate(String pleaseWork) it would result in an error from Orion. hmm, I have ejbCreate() with and without args. While I never called my DO's with args, it doesn't give an error. I always call the default ctor then use setters. I ought to call the ctors with args to see what happens. Relations between dependents are not supported. Orion returns an error on the abstract create method. This is very true. I discovered this some time ago - bug #185. My solution to the DO issue was to use EJBs for everything. This may have been a good choice since DO's in the spec are under a lot of fire and may be radically changed. EJB-EJB calls within the same container are optimized to local call-by-value method calls (at least in orion), so speed between all these EJBs isn't much of an issue. -tim
Re: Why Entity EJBs?
Orion should execute one SQL query for a finder (even with 1000 rows) unless: You're using BMP. You're using exclusive-write-access="false" and are outside of a TX. BMP is less than slim when it comes to SQL activity, we generally recommend CMP unless the condition is exceptional. Another "common mistake" in EJB usage is not using transactions. The same code can generate 100x+ as many calls when run outside of a TX as inside a TX. Why this is specific to EJB is that EJB treats data integrity very carefully, while your "home brewed" (hope that word isnt offensive) access may delay persistance into larger chunks etc (a "semi TX"). So: avoid exclusive-write-access="false" unless absolutely needed, use CMP if possible, and identify where your app is really "TXs" logically but isnt defined to be. What you get: cleaner and more easily abstracted code if all goes well. Transactional (and distributed, stay tuned some longer for that to come clustering doc) cache (it is fairly easy to make a cache, but another issue alltogether to make a transactional cache that scales, totally different tasks). More ease in code migration between programmers since you're closer to the "default", more of the backbone has been provided/standardized. Weakest side of entities as of now: batch updates. No candidate to that one, it is the biggest limitation (but can be worked around). As for "general design standpoint" it is usually not good custom for a vendor to push a practice; but we can say as much as that our recommendations are pretty much in line of those described by Dan North in a recent reply to this thread (CMP, logic in entities that apply to that entity - ignore the recommendation stating that they're simply data storage items, they're objects, and inter-bean logic in sessions). Just a short note... we rarely mix into this category of discussions (the ones bordering on religious beliefs ;) but I thought I'd shed some technical light on some of the issues - everyone's free to chose their own architecture, but it's sad when it's done due to lack of knowledge of architecture X's facts and benefits. Have a nice day! /Magnus Stenman, the Orion team PS. On the issue of "coarse grained" - entities fit perfectly well for fine grained access, but this is a political battle. You may have heard rumours about "local" entities, which consist more or less of entities allover but "allowed for fine grained access" this time. Our current position on that matter is that locals are superflous, what needs to change is just the notion of EJBs always being coarse grained. This is, of course, a very preliminary position. If there turns out to be genuine technical merits for the separation (things that cannot be done feasably via switch tags in the descriptor, see for instance copy-by-value in orion-ejb-jar.xml) that weight enough we'll reposition. /Magnus Stenman, the Orion team - Original Message - From: "Jeff Schnitzer" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Tuesday, March 20, 2001 6:31 PM Subject: RE: Why Entity EJBs? I also am questioning entity beans, after 5 months of intensive development with them. If you run Hypersonic in server mode and watch the sql output to the console, it should be readily apparent why... CMP produces *WAY* too many queries for fine-grained entity beans. The biggest problem is finder methods. Since all beans are lazy-loaded, iterating through the finder results of 1000 beans will produce 1001 SQL calls. There isn't any reason specwise that beans cannot be eager-loaded, but few (if any) appservers seem to support this. Does anyone know if there is any support for eager-loading of finder results in Orion? There doesn't appear to be from the documentation. I'm really disappointed in the entity bean concept. CMP should give us faster development times, faster code (with caching), and database independence, but at the moment we get *none* of the above. By stating in the blueprints that entity beans should only model course-grained objects and _not_ "one row of the table" they are effectively saying DO NOT USE CMP, because what is a CMP bean if not one row of a table? I noticed that most of the new J2EE patterns Sun recently posted are aimed at BMP. Sun's schizophrenia on this really pisses me off; with one face they like to show off entity beans and CMP because MS doesn't have it, with another they tell us to go back to the bronze age of handwritten SQL because the technology doesn't work. Gr. Jeff -Original Message- From: Dan North [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 4:41 AM To: Orion-Interest Subject: Fwd: Why Entity EJBs? Hi Johan. two-pence-worth I've been developing EJBs in a very (a) intensive and (b) short development cycle for about 5 months now. I've found that my methodology has leant towards what the JRF guys are talking about, but
Unsuscribe
= Francisco Mariategui [EMAIL PROTECTED] [EMAIL PROTECTED] (425) 487-9336 __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
RE: Impossible getting the attention of the orion (support) team.Are they still around?
1.4.8 is not available yet (you can find out with a simple java -jar autoupdate.jar), the latest release seems to be 1.4.7 On Tue, 20 Mar 2001, Elhadi barkat wrote: Is release 1.4.8 already available, because I'm having the same bug? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Douma, Ate Sent: mardi, 20. mars 2001 14:42 To: Orion-Interest Subject: RE: Impossible getting the attention of the orion (support) team. Are they still around? FYI: My reported bug was fixed by the orion team (to be release in 1.4.8) within 2.5 hours after entering it into Bugzilla. Can't really ask for more, can I? Ate -Original Message- From: Douma, Ate [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 11:04 AM To: Orion-Interest Subject: RE: Impossible getting the attention of the orion (support) team. Are they still around? As of today, we receive the maillist directly again. Furthermore, I received my bugzilla account password and already entered our problem in bugzilla (bug 368). The mailserver problem thus seems to be resolved by orion (we didn't have to do anything). Thumbs up for orion for the quick response. Now if they could resolve our real problem (almost) just as quickly ... :-) All in all, my confidence in orion has been partly restored. Lets hope they get their application server support back into high speed soon. Ate -Original Message- From: Douma, Ate [mailto:[EMAIL PROTECTED]] Sent: Monday, March 19, 2001 12:47 PM To: Orion-Interest Subject: RE: Impossible getting the attention of the orion (support) team. Are they still around? FYI: I received a very quick response from Karl Avedal on me previous posting. It looks like their mail doesn't get through to our mailserver since they switched servers early january. We are again in contact and I'm very much relieved about that. Hopefully, we can resolve our problems quickly now. Ate Douma. -Original Message- From: Douma, Ate Sent: Monday, March 19, 2001 11:24 AM To: 'Orion-Interest' Subject: Impossible getting the attention of the orion (support) team. Are they still around? Hello all, I've been trying for weeks now getting any response from the orion team to no avail. First of all, I wanted to post a serious problem in Bugzilla but for that I need a account password. I've tried and tried, but never ever received a password after creating a new account or after requesting the account password to be send again. Then I tried sending a message directly to orion support. No response. Then I posted my problem to this list http://www.mail-archive.com/orion-interest@orionserver.com/msg 09692.html (Serious problem with Orion transaction processing: multiple connections used within a single transaction) februari 13, 2001, including a test case. I mailed this problem again to [EMAIL PROTECTED] februari 19, 2001. No response. I mailed Magnus Stenman directly on februari 27 explaining these problems and requesting access to Bugzilla. No response. I'm not clear what options are left, but we are seriously considering other application servers right now as this kind of support is really not acceptable in the long run. At least a simple acknowledgment of the reception of the problem would give us the idea that someone is actually monitoring [EMAIL PROTECTED] mailbox. It doesn't seems to be the case right now. Having to switch to another application server is something I really don't like. Overall I like the orion application server very much (certainly for development). We consider the bug we encountered as very, very serious which will have to be solved otherwise we just don't have another option. The bad (non-existing?) support makes this truly serious. If anyone did have some contact with the orion team (mailbased or otherwise) in the last month's I would be very grateful to know how they did that. The same question I have for anyone how was able to create a Bugzilla account recently. Lastly, somewhat less important: does anyone receive the orion-interest maillist still directly to their mailbox? Since Januari 11, 2001, we didn't receive any mail anymore, and can therefore only access the maillist at http://www.mail-archive.com/orion-interest@orionserver.com. (re)Subscribing again didn't help a bit, not even using new mailaccount. Ate +---+ | Ate Douma iWise B.V. | |Hoofdstraat 2a-4a |
RE: Why Entity EJBs?
I'm using EJB 1.1 CMP; It gives me as much DB independence as I need. I have to rewrite some finders when porting from DB to DB; hopefully EQL will remove this burden too. Orion performs caching of instances, check out exclusive-write-access and validity-timeout atrributes for entity-deployment tag in orion-ejb-jar.xml. However, if you have a distributed environment, cache's like the one in Orion are a threat to data integrity-- so they *must* be deactivated. Also, an orion-dependant feature, the boolean isModified(), which in WLS is called boolean isDirty(), plus a correct use of declarative transactions allow to minimize the impact on the DB. I believe CMP is the way to go, but it is very much server-dependant. The (apparent) poor performance of CMP is due to the need for this solution to address many things we all want from the server, such as data integrity, distribution across hosts of the business logic, declarative transactions and security. There's a price inherent to all this features, and the larger the spec, the higher the price we all must pay, basically, by leveling down. MS's single vendor approach actually levels up, but when they don't have the answers pre-packaged, all crumbles down and somehow we(as developers) must pay for the loses. Eventually, the servers *will* perform as expected, but until the spec matures, we will be stuck with some minor problems. I'm now living in Chile, and the budgets are pretty tight here, but still, the customer'd rather pay for an extra box to scale up than to pay extra to the programmers to do a more optimized job and scale out. I'm aware that this is vastly simplifying the issue, but the point still stands. Perhaps the true problem is that we, all the J2EE developer community, are pushing it too far *and* too broad. This is what happened with CORBA, leaving us with very little common ground. Some servers implement mor of the spec, some less. Some scale(but forbid Singleton's, for instance) and some don't. And there is no single way of making two OTS from two different vendors to cooperate. CORBA was even taller than the Everest, so nobody climbed it. Of course, I also have those rush moments where I wonder why I quitted my older job, but that's definitely not the time to contribute to anything. My 2c, JP -Original Message- From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 1:31 PM To: Orion-Interest Subject: RE: Why Entity EJBs? I also am questioning entity beans, after 5 months of intensive development with them. If you run Hypersonic in server mode and watch the sql output to the console, it should be readily apparent why... CMP produces *WAY* too many queries for fine-grained entity beans. The biggest problem is finder methods. Since all beans are lazy-loaded, iterating through the finder results of 1000 beans will produce 1001 SQL calls. There isn't any reason specwise that beans cannot be eager-loaded, but few (if any) appservers seem to support this. Does anyone know if there is any support for eager-loading of finder results in Orion? There doesn't appear to be from the documentation. I'm really disappointed in the entity bean concept. CMP should give us faster development times, faster code (with caching), and database independence, but at the moment we get *none* of the above. By stating in the blueprints that entity beans should only model course-grained objects and _not_ "one row of the table" they are effectively saying DO NOT USE CMP, because what is a CMP bean if not one row of a table? I noticed that most of the new J2EE patterns Sun recently posted are aimed at BMP. Sun's schizophrenia on this really pisses me off; with one face they like to show off entity beans and CMP because MS doesn't have it, with another they tell us to go back to the bronze age of handwritten SQL because the technology doesn't work. Gr. Jeff -Original Message- From: Dan North [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 4:41 AM To: Orion-Interest Subject: Fwd: Why Entity EJBs? Hi Johan. two-pence-worth I've been developing EJBs in a very (a) intensive and (b) short development cycle for about 5 months now. I've found that my methodology has leant towards what the JRF guys are talking about, but in a less formal way. From the backend forwards: I tend to use entity beans for storing/retrieving and most manipulation of data - ie. I have quite "fat" beans rather than just purely getters and setters. I then use session beans for workflow that doesn't seem to belong with any particular single bean, such as generating reports or anything that requires a few home interfaces' finders. I also use session beans for their transactional integrity when populating new beans from an HTML (JSP) form, especially when several beans will be created from a single form's contents and I want the whole lot to be atomic. We
Re: Java Mail and javax.activation.DataSource
You are missing the JavaBeans Activation Framework classes (also known as Glosgow), which are in the JAR activation.jar. http://java.sun.com/products/javabeans/glasgow/jaf.html tim. Hello all, I'm setting up J2EE program and I'm having trouble getting the Java mail to work. I am getting a java.lang. NoClassDefFoundError: javax/activation/DataSource error when I call Message msg = new MimeMessage(session); Everything else is set up and my code is nearly identical to the ATM example. My mailing code is in a stateless session bean. Anyone see anything like this before? Jonathan Bricker Lilly Research Labs Java ATG
Servlet Mapping Tag
I don't understand how Orion has implemented the servlet-mapping tag for the web.xml file. According to the documentation, I need to declare a pattern /*.thePattern. When I do something like the following, it works. However, I need a separate pattern for each servlet in order for Orion to invoke a unique servlet. My questions are: 1. Is the servlet-mapping tag necessary. (I couldn't invoke a servlet without it.) 2. How is Orion expecting this to be used? servlet servlet-namesnoop/servlet-name servlet-classSnoopServlet/servlet-class /servlet servlet-mapping servlet-namesnoop/servlet-name url-pattern/*.1/url-pattern /servlet-mapping servlet servlet-namedh/servlet-name servlet-classdh.TestServlet/servlet-class /servlet servlet-mapping servlet-namedh/servlet-name url-pattern/*.2/url-pattern /servlet-mapping
How to do this servlet-mapping?
Here's a challenge. It was for me. For all URLs that start with /app (e.g. /app/login, /app/mainmenu, /app/ball.gif), have all requests go to a servlet for processing. If the servlet recognizes the URL, perform an action and return the appropriate output. If the URL is not recognized, treat the URL as a filename and return the named resource. Hence, if the URL /app/login was recognized and requested, the servlet takes an action on them. If the URL /app/ball.gif was requested, the servlet doesn't recognize it as an action to be performed, and tries to return the contents of /app/ball.gif to the user. I've tried using the servlet-mapping of /app/* and pointing this to the servlet. While this makes requests go to the servlet, if, within that servlet, I try to get a request dispatcher to /app/ball.gif and forward there, I get back into the servlet again , presumably because /app/ball.gif maps to the servlet. This, of course, creates an recursive infinite loop and soon the server dies. One alternative that might work, but seems somehow "wrong" to me is to name every action in the web.xml file, e.g. individually map /app/login, /app/logout, /app/dothis, /app/dothat, etc. and then have /app/* for all other resources. I'd like to avoid this particular solution. Any bright ideas?
RE: Why Entity EJBs?
May I suggest an architecture that we are employing without using EJB, but will easily adapt to moving to EJB if need be. First, I can't agree more about getting rid of dealing with the persistence layer. A Java developer generally doesn't want to worry about the SQL, database issues, etc. It would be nice if we had simple methods that would get one or more objects based on some search mask we supply, or store one or more objects. I believe EJB is a step in the right direction to acheive this, when dealing with CMP. However, CMP as I have read about it has limitations, but at the same time allows the application server to make performance enhancements. EJB 2.0 doesn't look very simple to work with and I haven't given it much time as of yet. What I do suggest is something fairly simple. Set up your class structure like so and use a Model 2 front-end archtecture. I have one readily available that handles XSLT processing for you as well. First, you will want to set up folders like so (as per my suggestion, you can do it how you want) com.mycompany.* /src /src/com /src/com/mycompany /src/com/mycompany/ejb /src/com/mycompany/ejb/session /src/com/mycompany/ejb/entity /src/com/mycompany/core /src/com/mycomapny/core/entity /src/com/mycompany/presentation /src/com/mycompany/presentation/actions /src/com/mycompany/presentation/beans /src/com/mycompany/presentation/servlets The above is a start. The /ejb package doesn't necessarily mean EJB, but it assumes EJB is the business logic of your code. Entity EJB package would contain special "beans" that handle the load/store/find capabilities of objects, including any one to one, one to many, and so on. We currently write SQL in these beans and they would basically be BMP in the EJB domain. By simply implementing two interfaces and adding some methods, you turn your version of an entity bean into a CMP (or BMP) EJB entity bean. The ejb/session package is where you put your session "business logic" classes. These two can start off as normal classes, and be turned into EJB session bean classes by implementing two interfaces and adding a few methods to the main session class. As for how you access the "logic"..its quite simple. With my front-end framework or another one called Struts, you use a single entry ControllerServlet for all requests, and call upon action classes (basically servlets that are instantiated and kept in memory via the ControllerServlet) to handle each incoming request. Each action class would create a new stateless session class (before using EJB) or do a JNDI lookup on the EJB session bean (if you move to EJB) to get a reference to a "logic" class. The action class then calls methods of the session class, passing to it objects (Strings, Integer, your own classes, etc) and getting results back. Keep in mind, you should ALWAYS make sure everything you pass to a session class and any results you get back are objects that implement Serializable, so that if and when you do move to EJB, you don't have to figure out a reworking of any given method or class so that it will work. EJB serailizes objects when passing them to and from other classes (such as your front-end action classes or a desktop client program for example). You asked what you get by moving to EJB. If your a small company with a small site, or doing your own stuff that is not very big, I don't think you'll see a significant improvement in performance for your site, nor will you find it as easy to develop with EJB's than if you just put the logic in an action class, a servlet or directly in the JSP. However, what you do get even if you are small, is what I consider "proper" development. You break out your code into easily manageable tiers (and thus your packaging is easier to find classes, organized, etc). You move any and all logic work into a "session" class and ALL database access is done from this class. You remove ALL back-end database ties from any JSP pages, servlets or action classes. Thus, your front-end HTTP based stuff can now be plugged in to any existing database back-end and any database without direct locks to one database. Ofcourse, using JDBC pretty much does this for you too, but by moving ALL database access to session beans (non-EJB parlance this would be session/logic classes, EJB = session beans), you further simplify your development process and a BIG advantage is IF your business grows, you now have a much more manageable code base to hire more developers in to. You can also more easily find problems. Is it a logic problem? Go to a session class. IS it a front-end problem? Go to an action or servlet class. Now, if your a larger organization, especially one that may be acquiring one or more companies, having to work with legacy applications, and integrate with other companies, you get a very nice advantage to moving to EJB. You can now centrally locate ALL of your company's business logic in one place (following the ASP model) and access it from anywhere in the
RE: Why Entity EJBs?
Please take me off this list as I have no interest in this conversation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juan Lorandi (Chile) Sent: Tuesday, March 20, 2001 12:11 PM To: Orion-Interest Subject: RE: Why Entity EJBs? I'm using EJB 1.1 CMP; It gives me as much DB independence as I need. I have to rewrite some finders when porting from DB to DB; hopefully EQL will remove this burden too. Orion performs caching of instances, check out exclusive-write-access and validity-timeout atrributes for entity-deployment tag in orion-ejb-jar.xml. However, if you have a distributed environment, cache's like the one in Orion are a threat to data integrity-- so they *must* be deactivated. Also, an orion-dependant feature, the boolean isModified(), which in WLS is called boolean isDirty(), plus a correct use of declarative transactions allow to minimize the impact on the DB. I believe CMP is the way to go, but it is very much server-dependant. The (apparent) poor performance of CMP is due to the need for this solution to address many things we all want from the server, such as data integrity, distribution across hosts of the business logic, declarative transactions and security. There's a price inherent to all this features, and the larger the spec, the higher the price we all must pay, basically, by leveling down. MS's single vendor approach actually levels up, but when they don't have the answers pre-packaged, all crumbles down and somehow we(as developers) must pay for the loses. Eventually, the servers *will* perform as expected, but until the spec matures, we will be stuck with some minor problems. I'm now living in Chile, and the budgets are pretty tight here, but still, the customer'd rather pay for an extra box to scale up than to pay extra to the programmers to do a more optimized job and scale out. I'm aware that this is vastly simplifying the issue, but the point still stands. Perhaps the true problem is that we, all the J2EE developer community, are pushing it too far *and* too broad. This is what happened with CORBA, leaving us with very little common ground. Some servers implement mor of the spec, some less. Some scale(but forbid Singleton's, for instance) and some don't. And there is no single way of making two OTS from two different vendors to cooperate. CORBA was even taller than the Everest, so nobody climbed it. Of course, I also have those rush moments where I wonder why I quitted my older job, but that's definitely not the time to contribute to anything. My 2c, JP -Original Message- From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 1:31 PM To: Orion-Interest Subject: RE: Why Entity EJBs? I also am questioning entity beans, after 5 months of intensive development with them. If you run Hypersonic in server mode and watch the sql output to the console, it should be readily apparent why... CMP produces *WAY* too many queries for fine-grained entity beans. The biggest problem is finder methods. Since all beans are lazy-loaded, iterating through the finder results of 1000 beans will produce 1001 SQL calls. There isn't any reason specwise that beans cannot be eager-loaded, but few (if any) appservers seem to support this. Does anyone know if there is any support for eager-loading of finder results in Orion? There doesn't appear to be from the documentation. I'm really disappointed in the entity bean concept. CMP should give us faster development times, faster code (with caching), and database independence, but at the moment we get *none* of the above. By stating in the blueprints that entity beans should only model course-grained objects and _not_ "one row of the table" they are effectively saying DO NOT USE CMP, because what is a CMP bean if not one row of a table? I noticed that most of the new J2EE patterns Sun recently posted are aimed at BMP. Sun's schizophrenia on this really pisses me off; with one face they like to show off entity beans and CMP because MS doesn't have it, with another they tell us to go back to the bronze age of handwritten SQL because the technology doesn't work. Gr. Jeff -Original Message- From: Dan North [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 4:41 AM To: Orion-Interest Subject: Fwd: Why Entity EJBs? Hi Johan. two-pence-worth I've been developing EJBs in a very (a) intensive and (b) short development cycle for about 5 months now. I've found that my methodology has leant towards what the JRF guys are talking about, but in a less formal way. From the backend forwards: I tend to use entity beans for storing/retrieving and most manipulation of data - ie. I have quite "fat" beans rather than just purely getters and setters. I then use session beans for workflow that doesn't seem to belong with any particular single bean, such as generating reports or anything that
Sharing sessions among different applications?
Is it possible to share session objects among different applications? I've tried using the shared="true" attribute in web-site.xml, but with no success. Matt Krevs said that he got it to work when the "name" attribute was the same, but that only works if you're hosting the same application on multiple parts of the site. What if soemone wants to host multiple applications across multiple hosts and want to share session information that way? - Brian Chan
Looking up an EJB in a different application...
Hi, Can anyone give me a pointer on how I might successfully lookup an EJB from within another EJB in a different application (both in Orion)? Here's the scenario: Application 'two'- EJB TwoBean looks up - Application 'one'- EJB OneBean Make sense? Now, java:comp/env/One and java:comp/env/Two both work from external clients. But TwoBean cannot see OneBean. I've tried using hard-coded jndi.properties, a jndi.property file, and 1500 (or so)variations on the names of the beans. I've got an ejb-ref entry in my ejb-jar.xml for application 'two,' but the kicker seems to be that no matter what I do to the properties, the result of printing the list from TwoBean shows: List: --java:comp: javax.naming.Context --Two: TwoHome I'm setting the jndi.properties to look for ormi:localhost/one... but that's not happening. So, the short version is: How can I look up a bean in one application's EJB under Orion from another application's EJB? Is there any way to "step outside" an application's JNDI naming context? Thanks, Rian
Re: How to do this servlet-mapping?
Why not have your servlet "forward" any request that it does not recognize to another namespace. In other words, using your example, you would forward "/app/ball.gif" to "/images/ball.gif", thus eliminating the "/app" mapping. tim. I've tried using the servlet-mapping of /app/* and pointing this to the servlet. While this makes requests go to the servlet, if, within that servlet, I try to get a request dispatcher to /app/ball.gif and forward there, I get back into the servlet again , presumably because /app/ball.gif maps to the servlet. This, of course, creates an recursive infinite loop and soon the server dies. One alternative that might work, but seems somehow "wrong" to me is to name every action in the web.xml file, e.g. individually map /app/login, /app/logout, /app/dothis, /app/dothat, etc. and then have /app/* for all other resources. I'd like to avoid this particular solution. Any bright ideas?
RE: Why Entity EJBs?
A! You are absolutely right, and I marvel at my own foolishness! It was something in my code that made it look like finders were issuing n+1 calls. That, combined with my expectation of trouble because this question (about n+1 sql calls for a finder) comes up with some regularity on the ejb-interest mailing list. I don't think many of the (other) appserver vendors have a satisfactory solution. My faith in CMP has been restored. I'm finding that hacking around case-sensitivity in String values is annoying, but it still beats handwriting SQL. Thanks Magnus! It's too bad that Sun doesn't espouse this same line of thought; it's pretty clear to me now that the arguments against fine-grained entities are largely a product of deficient container implementations. This should be a FAQ. Jeff -Original Message- From: Magnus Stenman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 10:33 AM To: Orion-Interest Subject: Re: Why Entity EJBs? Orion should execute one SQL query for a finder (even with 1000 rows) unless: You're using BMP. You're using exclusive-write-access="false" and are outside of a TX. BMP is less than slim when it comes to SQL activity, we generally recommend CMP unless the condition is exceptional. Another "common mistake" in EJB usage is not using transactions. The same code can generate 100x+ as many calls when run outside of a TX as inside a TX. Why this is specific to EJB is that EJB treats data integrity very carefully, while your "home brewed" (hope that word isnt offensive) access may delay persistance into larger chunks etc (a "semi TX"). So: avoid exclusive-write-access="false" unless absolutely needed, use CMP if possible, and identify where your app is really "TXs" logically but isnt defined to be. What you get: cleaner and more easily abstracted code if all goes well. Transactional (and distributed, stay tuned some longer for that to come clustering doc) cache (it is fairly easy to make a cache, but another issue alltogether to make a transactional cache that scales, totally different tasks). More ease in code migration between programmers since you're closer to the "default", more of the backbone has been provided/standardized. Weakest side of entities as of now: batch updates. No candidate to that one, it is the biggest limitation (but can be worked around). As for "general design standpoint" it is usually not good custom for a vendor to push a practice; but we can say as much as that our recommendations are pretty much in line of those described by Dan North in a recent reply to this thread (CMP, logic in entities that apply to that entity - ignore the recommendation stating that they're simply data storage items, they're objects, and inter-bean logic in sessions). Just a short note... we rarely mix into this category of discussions (the ones bordering on religious beliefs ;) but I thought I'd shed some technical light on some of the issues - everyone's free to chose their own architecture, but it's sad when it's done due to lack of knowledge of architecture X's facts and benefits. Have a nice day! /Magnus Stenman, the Orion team PS. On the issue of "coarse grained" - entities fit perfectly well for fine grained access, but this is a political battle. You may have heard rumours about "local" entities, which consist more or less of entities allover but "allowed for fine grained access" this time. Our current position on that matter is that locals are superflous, what needs to change is just the notion of EJBs always being coarse grained. This is, of course, a very preliminary position. If there turns out to be genuine technical merits for the separation (things that cannot be done feasably via switch tags in the descriptor, see for instance copy-by-value in orion-ejb-jar.xml) that weight enough we'll reposition. /Magnus Stenman, the Orion team - Original Message - From: "Jeff Schnitzer" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Tuesday, March 20, 2001 6:31 PM Subject: RE: Why Entity EJBs? I also am questioning entity beans, after 5 months of intensive development with them. If you run Hypersonic in server mode and watch the sql output to the console, it should be readily apparent why... CMP produces *WAY* too many queries for fine-grained entity beans. The biggest problem is finder methods. Since all beans are lazy-loaded, iterating through the finder results of 1000 beans will produce 1001 SQL calls. There isn't any reason specwise that beans cannot be eager-loaded, but few (if any) appservers seem to support this. Does anyone know if there is any support for eager-loading of finder results in Orion? There doesn't appear to be from the documentation. I'm really disappointed in the entity bean concept. CMP should give us faster development times, faster code (with caching), and database independence, but at the moment we get *none* of the
RE: Why Entity EJBs?
somebody suscribed a whole lotta of criticalmass people to this list; can't we have a subscribe/unsubscribe confirmation?? JP -Original Message- From: Carla Marcyniuk [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 5:53 PM To: Orion-Interest Subject: RE: Why Entity EJBs? Please take me off this list as I have no interest in this conversation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juan Lorandi (Chile) Sent: Tuesday, March 20, 2001 12:11 PM To: Orion-Interest Subject: RE: Why Entity EJBs? I'm using EJB 1.1 CMP; It gives me as much DB independence as I need. I have to rewrite some finders when porting from DB to DB; hopefully EQL will remove this burden too. Orion performs caching of instances, check out exclusive-write-access and validity-timeout atrributes for entity-deployment tag in orion-ejb-jar.xml. However, if you have a distributed environment, cache's like the one in Orion are a threat to data integrity-- so they *must* be deactivated. Also, an orion-dependant feature, the boolean isModified(), which in WLS is called boolean isDirty(), plus a correct use of declarative transactions allow to minimize the impact on the DB. I believe CMP is the way to go, but it is very much server-dependant. The (apparent) poor performance of CMP is due to the need for this solution to address many things we all want from the server, such as data integrity, distribution across hosts of the business logic, declarative transactions and security. There's a price inherent to all this features, and the larger the spec, the higher the price we all must pay, basically, by leveling down. MS's single vendor approach actually levels up, but when they don't have the answers pre-packaged, all crumbles down and somehow we(as developers) must pay for the loses. Eventually, the servers *will* perform as expected, but until the spec matures, we will be stuck with some minor problems. I'm now living in Chile, and the budgets are pretty tight here, but still, the customer'd rather pay for an extra box to scale up than to pay extra to the programmers to do a more optimized job and scale out. I'm aware that this is vastly simplifying the issue, but the point still stands. Perhaps the true problem is that we, all the J2EE developer community, are pushing it too far *and* too broad. This is what happened with CORBA, leaving us with very little common ground. Some servers implement mor of the spec, some less. Some scale(but forbid Singleton's, for instance) and some don't. And there is no single way of making two OTS from two different vendors to cooperate. CORBA was even taller than the Everest, so nobody climbed it. Of course, I also have those rush moments where I wonder why I quitted my older job, but that's definitely not the time to contribute to anything. My 2c, JP -Original Message- From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 1:31 PM To: Orion-Interest Subject: RE: Why Entity EJBs? I also am questioning entity beans, after 5 months of intensive development with them. If you run Hypersonic in server mode and watch the sql output to the console, it should be readily apparent why... CMP produces *WAY* too many queries for fine-grained entity beans. The biggest problem is finder methods. Since all beans are lazy-loaded, iterating through the finder results of 1000 beans will produce 1001 SQL calls. There isn't any reason specwise that beans cannot be eager-loaded, but few (if any) appservers seem to support this. Does anyone know if there is any support for eager-loading of finder results in Orion? There doesn't appear to be from the documentation. I'm really disappointed in the entity bean concept. CMP should give us faster development times, faster code (with caching), and database independence, but at the moment we get *none* of the above. By stating in the blueprints that entity beans should only model course-grained objects and _not_ "one row of the table" they are effectively saying DO NOT USE CMP, because what is a CMP bean if not one row of a table? I noticed that most of the new J2EE patterns Sun recently posted are aimed at BMP. Sun's schizophrenia on this really pisses me off; with one face they like to show off entity beans and CMP because MS doesn't have it, with another they tell us to go back to the bronze age of handwritten SQL because the technology doesn't work. Gr. Jeff -Original Message- From: Dan North [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 4:41 AM To: Orion-Interest Subject: Fwd: Why Entity EJBs? Hi Johan. two-pence-worth I've been developing EJBs in a very (a) intensive and (b) short development cycle for about 5 months now. I've found that my
Fw: Please help me, How to get Orion's Environment Such as HostName, Port...???
- Original Message - From: urey To: Larry Velez Sent: Sunday, March 18, 2001 5:40 PM Subject: Re: Please help me, How to get Orion's Environment Such as HostName, Port...??? Hi Larry, It's sorry for my mistake. I want to write some Ejbs, and running them on Orion. the one of the Ejb for to store all the config info, and I have two methods for to load and reload all the config files( *.xml) in it, The config files( *.xml) all in my ear package. I don't know how to access my config files flexible in my Ejb. hope this help you to know my question Thanks you yours Urey - Original Message - From: Larry Velez To: 'urey' Sent: Saturday, March 17, 2001 12:38 AM Subject: RE: Please help me, How to get Orion's Environment Such as HostName, Port...??? I am not sure I understand your question but it looks like you are having trouble with your classpath. How are you launching Orion? What OS are you running? -Larry -Original Message-From: urey [mailto:[EMAIL PROTECTED]]Sent: Friday, March 16, 2001 4:48 AMTo: Larry VelezCc: Larry VelezSubject: Re: Please help me, How to get Orion's Environment Such as HostName, Port...??? Hello Larry, Thanks for your hint. I reread the web-site.xml.html just now. Really, I can getsome Orion server's environment transit itself config/ *.xml in my application programme. But, I think there are some trouble with me. Must Icodingsome parse for the *.xml?? If not, How will I do in my application programme?? and I can't get Orion's running really PATH from its config/*.xml. in its config/*.xmlonly have relative PATH. How could I do? Could you Please give me some helpful hint again, Thanks you again yoursUrey - Original Message - From: Larry Velez To: Urey Sent: Friday, March 16, 2001 3:46 PM Subject: RE: Please help me, How to get Orion's Environment Such as HostName, Port...??? These settings can be found in the web-site.xml file. You can read up on the details here: http://www.orionserver.com/docs/web-site.xml.html Larry Original Message-From: Urey.u [mailto:[EMAIL PROTECTED]]Sent: Thursday, March 15, 2001 9:23 PMTo: Orion-InterestCc: Urey; Orion-InterestSubject: Please help me, How to get Orion's Environment Such as HostName, Port...??? Dear All, When Orion Server was started. Could you please tell me,how to get Orion's environment Such as HostName,Port,Running Pathand so on in my application class file , not applet, servlet or JSP file?. Regards yoursUrey
Load Balancing
Hi, Where can i get documentation on Load Balancing. As i have 5 servers i want to make changes to my architecture. Thanks Sarathy _ Get your FREE download of MSN Explorer at http://explorer.msn.com
RE: Why Entity EJBs?
How about using a tool like TopLinks to do BMP for you? Then you can manage the model from a GUI standpoint, and the interfaces, code, descriptors, etc is all written for you. You then simply add in the business logic to session beans and let TopLinks handle the persistence of entity beans. I am not sure that this is how it really works, but I know we are going to be switching to a tool similar to that. One of our engineers built a "pre-ejb" tool that used Swing to connect instance variables to columns in a table, and generated all the code, including the tables, mappings, etc. He is modifying his tool to work with EJB 1.1 right now so that we may use it to manage all of our EJBs and not deal with all the inner workings. -Original Message- From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 9:31 AM To: Orion-Interest Subject: RE: Why Entity EJBs? I also am questioning entity beans, after 5 months of intensive development with them. If you run Hypersonic in server mode and watch the sql output to the console, it should be readily apparent why... CMP produces *WAY* too many queries for fine-grained entity beans. The biggest problem is finder methods. Since all beans are lazy-loaded, iterating through the finder results of 1000 beans will produce 1001 SQL calls. There isn't any reason specwise that beans cannot be eager-loaded, but few (if any) appservers seem to support this. Does anyone know if there is any support for eager-loading of finder results in Orion? There doesn't appear to be from the documentation. I'm really disappointed in the entity bean concept. CMP should give us faster development times, faster code (with caching), and database independence, but at the moment we get *none* of the above. By stating in the blueprints that entity beans should only model course-grained objects and _not_ "one row of the table" they are effectively saying DO NOT USE CMP, because what is a CMP bean if not one row of a table? I noticed that most of the new J2EE patterns Sun recently posted are aimed at BMP. Sun's schizophrenia on this really pisses me off; with one face they like to show off entity beans and CMP because MS doesn't have it, with another they tell us to go back to the bronze age of handwritten SQL because the technology doesn't work. Gr. Jeff -Original Message- From: Dan North [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 4:41 AM To: Orion-Interest Subject: Fwd: Why Entity EJBs? Hi Johan. two-pence-worth I've been developing EJBs in a very (a) intensive and (b) short development cycle for about 5 months now. I've found that my methodology has leant towards what the JRF guys are talking about, but in a less formal way. From the backend forwards: I tend to use entity beans for storing/retrieving and most manipulation of data - ie. I have quite "fat" beans rather than just purely getters and setters. I then use session beans for workflow that doesn't seem to belong with any particular single bean, such as generating reports or anything that requires a few home interfaces' finders. I also use session beans for their transactional integrity when populating new beans from an HTML (JSP) form, especially when several beans will be created from a single form's contents and I want the whole lot to be atomic. We tend to use JSP and regular form beans for most of the other workflow stuff, and sometimes we'll have quite complex finder methods in the EJBs that join across several tables. The benefits to EJBs, and specifically orion, for me are: - Database independence: we're deploying on MS SQL Server but it's trivial to deploy to eg. Oracle for scalability or Hypersonic for local testing. - Network independence: I need to change no code to cluster orion on several hosts and also to split its responsibilities between being a web server on one host talking to another orion instance being an app server on another host. - Speed of development: I don't have to worry about how or where my data is being stored - I have orion's _fantastic_ OR mapping to do that for me. It seems to me that the JRF is taking the "best practice" approach, which is a fine and noble thing to do, but then overcomplicating the issue by wandering off into its own specification. All my SQL for each package is in one place (orion-ejb-jar.xml), and I don't have to worry about scalability or portability. If it says J2EE on the box, it'll usually have J2EE in the box. (Apart from the usual niggles with app servers being behind spec - again orion is pretty good for being up-to-date in this regard.) So I have all the benefits of JRF but with the backing of a technology as widely-adopted as J2EE. /two-pence-worth Disclaimer: I don't work for orion, I just love their product. And J2EE has been the most useful technology I've discovered
Re: Looking up an EJB in a different application...
Follow up for posterity... Turns out that there's an, apparently, Orion-specific thing... the "parent=..." tag in the server.xml file in /config (specifically the application tag therein.) The closest I could get without that was to be able to lookup the home just like an external client... but even then, no dice on narrow... ClassCastException. Now, it strikes me that this seems to imply that you can basically match up two and only two apps? I mean, sounds like the ultimate enterprise class problem of sharing lots of beans between lots of applications won't work. And while odd, doesn't prevent us from getting at least from point A to point 2. Happy coding. Hi, Can anyone give me a pointer on how I might successfully lookup an EJB from within another EJB in a different application (both in Orion)? Here's the scenario: Application 'two'- EJB TwoBean looks up - Application 'one'- EJB OneBean Make sense? Now, java:comp/env/One and java:comp/env/Two both work from external clients. But TwoBean cannot see OneBean. I've tried using hard-coded jndi.properties, a jndi.property file, and 1500 (or so)variations on the names of the beans. I've got an ejb-ref entry in my ejb-jar.xml for application 'two,' but the kicker seems to be that no matter what I do to the properties, the result of printing the list from TwoBean shows: List: --java:comp: javax.naming.Context --Two: TwoHome I'm setting the jndi.properties to look for ormi:localhost/one... but that's not happening. So, the short version is: How can I look up a bean in one application's EJB under Orion from another application's EJB? Is there any way to "step outside" an application's JNDI naming context? Thanks, Rian
Clustering
Does orion support clustering? The contents of this email are confidential. If you are not the intended recipient, you must not disclose, copy or use the contents in any way. If you have received this email in error, please delete it and notify us immediately by return email. It is the recipient's responsibility to screen this message and any attachments for computer viruses. Any views expressed in this email are not to be taken as the views of the company or any related business entity unless expressly stated to the contrary.
Bug in deployment descriptor?!
Hi, I wonder if you have met this situation before, I trying to deploy an entity bean with one of the field named "password". I have write the corresponding orion-ejb-jar.xml for the persistence mapping within database. Everything seems fine, the xml in the application-deployment directory is correct. Until the whole deployment is done, which orion compiled all the generated files, the seems to be correct orion-ejb-jar.xml has been updated with the "password" field mapping becomes "password_". Is this a bug or just my problem?! I have tried all the ways and nothing can stop orion change the from "password" to "password_"! When I change the mapping to something else such as "blahblahblah" its ok, but not "password". I really confused about this strange behavior Regards, Nevin Ng
