Re: RE: LogicalDriverManagerXAConnection not closed
I think not. This is the first time I GET the connection, and it complains that I did
not close it. Also, according to my understanding, I do not have to explicitly close
pooled connections. At least, when we were using 1.0.3 the documentation said
something to that effect.
Thanx for responding, I thought I wasn't getting my message through.
Jaco
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Will Glozer
Sent: 09 October 2000 19:09
To: Orion-Interest
Subject: RE: LogicalDriverManagerXAConnection not closed
It means that you forgot to close the connection when you
were finished using it.
-Original Message-
From: Jaco van Rooijen [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 09, 2000 12:08 AM
To: Orion-Interest
Subject: RE: LogicalDriverManagerXAConnection not closed
Anybody have any ideas?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jaco van
Rooijen
Sent: 06 October 2000 13:40
To: Orion-Interest
Subject: LogicalDriverManagerXAConnection not closed
I am developing against the stable 1.3.8
I get an output stating:
LogicalDriverManagerXAConnection not closed, check your code!
Created at:
java.lang.Throwable: OrionCMTConnection created
at com.evermind.sql.ai.init(JAX)
at com.evermind.sql.OrionCMTDataSource.getConnection(JAX)
at
com.agri24.data.LegalEntityBean.getConnection(LegalEntityBean.java:843)
at
com.agri24.data.LegalEntityBean.ejbFindByAgri24ID(LegalEntityBean.java:463)
at
LegalEntityHome_EntityHomeWrapper55.findByAgri24ID(LegalEntityHome_EntityHom
eWrapper55.java:1122)
at java.lang.reflect.Method.invoke(Native Method)
at com.evermind.server.rmi.bd.run(JAX)
at com.evermind.server.rmi.bb.hy(JAX)
at com.evermind.server.rmi.bb.run(JAX)
at com.evermind.util.f.run(JAX)
LegalEntityBean.java:843 says -
Connection newConn =
((javax.sql.DataSource)ctx.lookup("java:comp/env/jdbc/LegalEntityDataSource"
)).getConnection();
The call goes through, but the console has this exception on it. What does
that mean?
Regards
Jaco
Re: Orion and MySQL
Title: Orion and MySQL Hi Dube , Craig . I have deployedan entity bean[CMP] inthe MySQL database. I am specifyingdatabase-schemas\mysql.xml modifications in data-sources.xml as it is. 1]database-schemas\mysql.xml ?xml version="1.0"?!DOCTYPE database-schema PUBLIC "-//Evermind//- Database schema" "http://www.orionserver.com/dtds/database-schemas.dtd"!-- Author : Shailesh Joshi --database-schema name="Mysql" not-null="not null" null="" primary-key="primary key"type-mapping type="java.lang.String" name="varchar(255)" /type-mapping type="int" name="integer" /type-mapping type="float" name="float" /type-mapping type="double" name="double" /type-mapping type="byte" name="smallint" /type-mapping type="char" name="char(1)" /type-mapping type="short" name="integer" /type-mapping type="boolean" name="bit" /type-mapping type="java.util.Date" name="datetime" /disallowed-field name="password" /disallowed-field name="username" /disallowed-field name="date" /disallowed-field name="text" //database-schema 2]Part added to data-sources.xml data-source name="MySQL" class="com.evermind.sql.ConnectionDataSource" location="jdbc/DefaultDS" pooled-location="jdbc/DefaultPooledDS" xa-location="jdbc/xa/DefaultXADS" ejb-location="jdbc/DefaultEJBDS" url="jdbc:mysql://IPAddress/Test" [Test is my database] connection-driver="org.gjt.mm.mysql.Driver" username="x" password="x" inactivity-timeout="30" schema="database-schemas/mysql.xml" / Shailesh Joshi Java Programmer Versaware(India) Ltd. - Original Message - From: Dube, Craig To: Orion-Interest Sent: Tuesday, October 10, 2000 1:24 AM Subject: Orion and MySQL I am trying to set up orion to use MySQL instead of HypersonicSQL. I'm looking for some advice on how to properly setup Orion to use the MySQL database that I have installed. So far I have used the MySQL admin tool to creat a database called oriondb. I have also edited the "data-sources.xml" and added a "mysql.xml" file under the database-schemas directory. Here is a piece of the "data-sources.xml" file and a piece of the "mysql.xml": data-sources.xml data-source class="com.evermind.sql.DriverManagerDataSource" name="MySQL" location="jdbc/DefaultCoreDS" xa-location="jdbc/xa/DefaultXADS" ejb-location="jdbc/DefaultDS" pooled-location="jdbc/DefaultPooledDS" connection-driver="org.gjt.mm.mysql.Driver" username="root" password="root" url="jdbc:mysql://localhost/mysql/data/oriondb" inactivity-timeout="30" schema="database-schemas/mysql.xml" / mysql.xml - database-schema name="MySQL" not-null="not null" null="" primary-key="primary key" type-mapping type="java.lang.String" name="char (255)" / type-mapping type="int" name="int" / type-mapping type="long" name="int" / type-mapping type="float" name="float" / type-mapping type="double" name="double" / type-mapping type="byte" name="smallint" / type-mapping type="char" name="char" / type-mapping type="short" name="short" / type-mapping type="java.util.Date" name="timestamp" / disallowed-field name="password" / disallowed-field name="username" / disallowed-field name="date" / disallowed-field name="order" / /database-schema I was very unsure as to what I should use for the "location" tags in the data-sources file. Also, with the "mysql.xml" file, I copied the Hypersonic schema file and removed the boolean type-mapping (I thought this might be my problem). The error I get when I deply states "SQL error: Communication link failure: Bad handshake". If anyone has successfully deployed MySQL with Orion, I would be very much interested in the contents of their xml files. - CJD
Orion JMS locks up
Firstly, where do I find the source for the ATM
code. I believe it has message driven beans??? But more importantly,
the following code puts orion in a
spin:
QueueConnection
connection = null; QueueSession session =
null; Queue queue =
null; QueueSender sender =
null; TextMessage message = null;
try
{ connection =
CatsUtils.getJMSConnection();
connection.start();
session
= connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
queue =
(Queue)CatsUtils.lookup(CatsUtils.EJB_ENVIRONMENT_NAME + "jms/CatsInQueue",
Queue.class);
QueueBrowser browser =
session.createBrowser(queue); int
i = 0; Enumeration e =
browser.getEnumeration(); while
(e.hasMoreElements())
{
i++;
} System.out.println("There are
currently " + i + " message(s) on the queue.");
// sender
=
session.createSender(queue);
message =
session.createTextMessage();//
message.setJMSDestination(queue);//
message.setText(xmlString);
sender.send(message);
} catch (Exception
e)
{
e.printStackTrace();
} finally
{
try
{ if (sender !=
null)
{
sender.close();
} if (session !=
null)
{
session.close();
} if (connection !=
null)
{
connection.close();
}
} catch (Exception
e)
{ // Ignore
it
} }
RE: EJB vs Servlets
Here is what we are at ... By the mere fact we are using Swing we can't use Servlets. I'm working on an application that we will run as a webservice. That is, you will be able to enter/retrieve data in a Swing applet. We choose for the Swing route, because using HTML/ASP/JSP doesn't give you a good enough interface for anything beyond casual usage. We use applets because the ease of installation. Assuming the Java Plugin and code signing runs fine (and you don't need to transfer too many sizeable jar files) the whole thing will run nicely and limited bandwidth and you have on the server side full control over the client configuration. That -is- a tempting proposition. Setting up your environment: blazing speed is possible using EJB. With respect to coding things three times. That is only a sizable waiste of time when you do that often and in that case you write a program that generates these files. We have even gone beyond generating the three/four standard classes by generating wrappers around the client objects/interfaces to generalize access to the EJBs to make it easy to create table listing, record entry etc. I'm still developping on it, but it all looks like it is going to work even better then I expected. By the end of the month I expect to be able to 'generate' a standard data entry/retrieval application from a 'data-design' in just a few days (fingers crossed). I have to admit I don't know if that is easily done using Servlets, as I have not investigated that technology. Frank On Tuesday, October 10, 2000 10:13 AM, Frank Eggink [SMTP:[EMAIL PROTECTED]] wrote: On Monday, October 09, 2000 9:24 PM, Reddy Krishnan [SMTP:[EMAIL PROTECTED]] wrote: hi Kevin, Could not agree with you more. I am developing a system using EJBs and it takes 2-3 times as much effort to do the same stuff what could have been done with jsps and servlets. The only saving grace seems to be OR mapping in EJB 2.0 where you can avoid writing JDBC code. I get a feeling of writing the same code three times ( in xml descriptor, ejb accessor methods, details java object as dependents cannot be directly exposed). I think the full use of EJB will come into effect if there are some cool GUI tools that allow to you drag and drop and wire a business application with all code automatically generated for you, for most of the code seems to be mechanical once the design is done. Would definately like to get a good answer from this forum. Cheers Krishnan -Original Message- From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] Sent: Monday, October 09, 2000 10:22 AM To: Orion-Interest Subject: EJB vs Servlets Hey all, I know this is a little off-topic, but seeing as how Orion is about the only fully compliant EJB server, I figured this would be a better place to ask. Lately I have talked to a number of people that have been moving towards EJB and pulled back because they have found it to be more tedious to develop, as well as the end result was slower than just using Servlets. I ask this because it appears to me that the servlet engine (at least with 2.2) being able to be failed over, load-balanced, etc, seems to be quite as capable for scalability and fault-tolerance as the ejb engine used to be. I do realize that the EJB container offers transaction management, but connection pooling is available in the servlet engine at the server level as well. So, if you lose speed in development time and performance, what is the real benefits of moving to EJB? I should say this with caution..I am sure the EJB engine/container offers some things the servlet container doesn't, but I would think its possible to actually put those abilities in the servlet container. Anyways..I'll be interested in hearing any feedback on this. Thanks.
RE: EJB vs Servlets
Here is what we are at ... By the mere fact we are using Swing we can't use Servlets. I'm working on an application that we will run as a webservice. That is, you will be able to enter/retrieve data in a Swing applet. We choose for the Swing route, because using HTML/ASP/JSP doesn't give you a good enough interface for anything beyond casual usage. We use applets because the ease of installation. Assuming the Java Plugin and code signing runs fine (and you don't need to transfer too many sizeable jar files) the whole thing will run nicely and limited bandwidth and you have on the server side full control over the client configuration. That -is- a tempting proposition. Setting up your environment: blazing speed is possible using EJB. With respect to coding things three times. That is only a sizable waiste of time when you do that often and in that case you write a program that generates these files. We have even gone beyond generating the three/four standard classes by generating wrappers around the client objects/interfaces to generalize access to the EJBs to make it easy to create table listing, record entry etc. I'm still developping on it, but it all looks like it is going to work even better then I expected. By the end of the month I expect to be able to 'generate' a standard data entry/retrieval application from a 'data-design' in just a few days (fingers crossed). I have to admit I don't know if that is easily done using Servlets, as I have not investigated that technology. Frank On Monday, October 09, 2000 9:24 PM, Reddy Krishnan [SMTP:[EMAIL PROTECTED]] wrote: hi Kevin, Could not agree with you more. I am developing a system using EJBs and it takes 2-3 times as much effort to do the same stuff what could have been done with jsps and servlets. The only saving grace seems to be OR mapping in EJB 2.0 where you can avoid writing JDBC code. I get a feeling of writing the same code three times ( in xml descriptor, ejb accessor methods, details java object as dependents cannot be directly exposed). I think the full use of EJB will come into effect if there are some cool GUI tools that allow to you drag and drop and wire a business application with all code automatically generated for you, for most of the code seems to be mechanical once the design is done. Would definately like to get a good answer from this forum. Cheers Krishnan -Original Message- From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] Sent: Monday, October 09, 2000 10:22 AM To: Orion-Interest Subject: EJB vs Servlets Hey all, I know this is a little off-topic, but seeing as how Orion is about the only fully compliant EJB server, I figured this would be a better place to ask. Lately I have talked to a number of people that have been moving towards EJB and pulled back because they have found it to be more tedious to develop, as well as the end result was slower than just using Servlets. I ask this because it appears to me that the servlet engine (at least with 2.2) being able to be failed over, load-balanced, etc, seems to be quite as capable for scalability and fault-tolerance as the ejb engine used to be. I do realize that the EJB container offers transaction management, but connection pooling is available in the servlet engine at the server level as well. So, if you lose speed in development time and performance, what is the real benefits of moving to EJB? I should say this with caution..I am sure the EJB engine/container offers some things the servlet container doesn't, but I would think its possible to actually put those abilities in the servlet container. Anyways..I'll be interested in hearing any feedback on this. Thanks.
RE: Orion JMS locks up
Hi !
Your enumeration is never enumerated... You should call nextElement !
hasMoreElements() does not browse the list. nextElement does...
That's an infinite loop in your code.
Bye
Christophe
-Original Message-
From: Simon Harris [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 10, 2000 9:02 AM
To: Orion-Interest
Subject: Orion JMS locks up
Firstly, where do I find the source for the ATM code. I believe it has
message driven beans??? But more importantly, the following code puts orion
in a spin:
QueueConnection connection = null;
QueueSession session = null;
Queue queue = null;
QueueSender sender = null;
TextMessage message = null;
try {
connection = CatsUtils.getJMSConnection();
connection.start();
session = connection.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
queue = (Queue)CatsUtils.lookup(CatsUtils.EJB_ENVIRONMENT_NAME +
"jms/CatsInQueue", Queue.class);
QueueBrowser browser = session.createBrowser(queue);
int i = 0;
Enumeration e = browser.getEnumeration();
while (e.hasMoreElements())
{
i++;
}
System.out.println("There are currently " + i + " message(s) on the
queue.");
//sender = session.createSender(queue);
//
//message = session.createTextMessage();
//message.setJMSDestination(queue);
//message.setText(xmlString);
//
//sender.send(message);
}
catch (Exception e)
{
e.printStackTrace();
}
finally
{
try
{
if (sender != null)
{
sender.close();
}
if (session != null)
{
session.close();
}
if (connection != null)
{
connection.close();
}
}
catch (Exception e)
{
// Ignore it
}
}
Kawa Enterprise Edition 5.0
Hello: Dose Kawa Enterprise Edition 5.0 support Orion J2EE server ?? Thanks in advance. bubble chen(2000/10/10 PM 05:32:51) [EMAIL PROTECTED] == PC home §K¶O¹q¤l«H½c¡A¥Ó½Ð½Ð¦Ü: http://www.pchome.com.tw PC home Online ºô¸ô®a®x¡@¡@ ·|û²Ä¤@¡A¥xÆW³Ì¤jªº¤J¤fºô¯¸ ==
RE: EJB vs Servlets
Hi Kevin You seem to be missing the big picture here. With using a Servlet engine for handling all your logic you are putting all your eggs the same basket. You may have partitioned your logic up in the servlet container envirionment (MVC) but this is only at class level. EJB gives you distinct partioning at the component level. If you model all your Data and business logic at the EJB level then you create yourself a reuseable component layer. This way you can connect to this EJB layer from any clients, (Java) Servlets, (Java) jsp , (java) desktop client , (java) mobile client, (VB) desktop client, (CORBA) client and many more. At the moment you can only access your model layer through the servlet contain (or at least you can't easily access the same model from servlets and standalone clients, due to classloading etc) When you are accessing DB's from servlets you find yourself reinventing the wheel , for OR mapping, calling frameworks and data caching algorithims all the things that the best (like orion) app servers support :) -Original Message- From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] Sent: Monday, October 09, 2000 6:22 PM To: Orion-Interest Subject: EJB vs Servlets Hey all, I know this is a little off-topic, but seeing as how Orion is about the only fully compliant EJB server, I figured this would be a better place to ask. Lately I have talked to a number of people that have been moving towards EJB and pulled back because they have found it to be more tedious to develop, as well as the end result was slower than just using Servlets. I ask this because it appears to me that the servlet engine (at least with 2.2) being able to be failed over, load-balanced, etc, seems to be quite as capable for scalability and fault-tolerance as the ejb engine used to be. I do realize that the EJB container offers transaction management, but connection pooling is available in the servlet engine at the server level as well. So, if you lose speed in development time and performance, what is the real benefits of moving to EJB? I should say this with caution..I am sure the EJB engine/container offers some things the servlet container doesn't, but I would think its possible to actually put those abilities in the servlet container. Anyways..I'll be interested in hearing any feedback on this. Thanks.
allow/deny host access
Hi, Is possible to do host based access control with orion in a similar way to apache i.e. Deny from all Allow from xxx.xxx. We have a directory on a site which we only want computers from the client's network to have access to ( accounting and admin pages ). Cheers, Mike
SV: Performance
Add more memory to the vm :) Klaus -Opprinnelig melding- Fra: Sarathy Mattaparti [mailto:[EMAIL PROTECTED]] Sendt: 9. oktober 2000 20:00 Til: Orion-Interest Emne: Performance Hi, Previously i used Pentium III 550 MHz and 64 MB RAM and i bought a new computer its Dual Pentium III 800 MHZ and 256 MB RAM. i havent seen the difference. I am using Windows 2000 Server as my OS. I just changed the configuration of access log.. Any suggestions to improve the performance ?? Thanks Sarathy _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.
EJB 2.0: can dependent objects have dependent objects?
Hi!
I have VotingEntity which is an entity bean having a one-to-many
relationship between Question. The Question has a one-to-many relationship
between Choice.
+-+
| entity bean |
|VotingEntity |
+-+
1 |
|
* V
+-+
| dependent class |
| Question |
+-+
1 |
|
* V
+-+
| dependent class |
| Choice|
+-+
The relevant parts of code for each class:
public abstract class VotingEntityBean implements EntityBean {
private EntityContext context;
// cmp-fields
public abstract void setId(Long id);
public abstract Long getId();
// cmr-fields
public abstract void setQuestions(Collection questions);
public abstract Collection getQuestions();
public abstract Question createQuestion(Long id)
throws CreateException;
...
}
public abstract class Question {
// cmp-fields
public abstract void setId(Long id); // primary key
public abstract Long getId(); // primary key
public abstract void setText(String text);
public abstract String getText();
// cmr-fields
public abstract void setChoices(Collection choices);
public abstract Collection getChoices();
public abstract Choice createChoice(Long choiceId);
// Creators
public Long ejbCreateQuestion(Long id) {
this.setId(id);
return null;
}
public void ejbPostCreateQuestion(Long id) {
}
...
...
}
public abstract class Choice {
public abstract void setId(Long id);
public abstract Long getId();
public abstract void setText(String text);
public abstract String getText();
public Long ejbCreateChoice(Long id) {
this.setId(id);
return null;
}
public void ejbPostCreateChoice(Long id) {
}
...
...
}
And I have deployed these in a following way:
enterprise-beans
entity
ejb-nameVoting/ejb-name
homevoting.VotingEntityHome/home
remoteVotingEntity/remote
ejb-classVotingEntityBean/ejb-class
persistence-typeContainer/persistence-type
prim-key-classjava.lang.Long/prim-key-class
reentrantTrue/reentrant
cmp-field
field-namequestions/field-name
/cmp-field
cmp-field
field-nameid/field-name
/cmp-field
primkey-fieldid/primkey-field
/entity
/enterprise-beans
dependents
dependent
dependent-namequestion/dependent-name
dependent-classvoting.Question/dependent-class
cmp-field
field-nameid/field-name
/cmp-field
cmp-field
field-nametext/field-name
/cmp-field
cmp-field
field-namechoices/field-name
/cmp-field
prim-key-classjava.lang.Long/prim-key-class
primkey-fieldid/primkey-field
/dependent
dependent
dependent-namechoice/dependent-name
dependent-classvoting.Choice/dependent-class
cmp-field
field-nameid/field-name
/cmp-field
cmp-field
field-nametext/field-name
/cmp-field
cmp-field
field-nameanswers/field-name
/cmp-field
prim-key-classjava.lang.Long/prim-key-class
primkey-fieldid/primkey-field
/dependent
/dependents
relationships
ejb-relation
ejb-relation-namevoting-question/ejb-relation-name
ejb-relationship-role
ejb-relationship-role-name
voting-has-questions
/ejb-relationship-role-name
multiplicityone/multiplicity
role-source
ejb-nameVoting/ejb-name
/role-source
cmr-field
cmr-field-namequestions/cmr-field-name
cmr-field-typejava.util.Collection/cmr-field-type
/cmr-field
/ejb-relationship-role
ejb-relationship-role
ejb-relationship-role-name
question-belongsto-voting
/ejb-relationship-role-name
multiplicitymany/multiplicity
role-source
dependent-namequestion/dependent-name
/role-source
/ejb-relationship-role
/ejb-relation
ejb-relation
ejb-relation-namequestion-choice/ejb-relation-name
ejb-relationship-role
ejb-relationship-role-name
question-has-choices
/ejb-relationship-role-name
multiplicityone/multiplicity
role-source
dependent-namequestion/dependent-name
/role-source
cmr-field
cmr-field-namechoices/cmr-field-name
cmr-field-typejava.util.Collection/cmr-field-type
/cmr-field
/ejb-relationship-role
ejb-relationship-role
ejb-relationship-role-name
choice-belongsto-question
/ejb-relationship-role-name
multiplicitymany/multiplicity
role-source
dependent-namechoice/dependent-name
/role-source
/ejb-relationship-role
/ejb-relation
/relationships
But at deployment phase the Orion gives an error:
Error compiling file:voting.jar:
RE: Kawa Enterprise Edition 5.0
it is not mentioned in the documentation to support anything beyond WebLogic
and the RI that ships with J2EE.
Please ask Tek-tools directly and keep us informed.
Jeroen T. Wenting
[EMAIL PROTECTED]
Murphy was wrong, things that can't go wrong will anyway
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of 3??E1A
Sent: Tuesday, October 10, 2000 11:34
To: Orion-Interest
Subject: Kawa Enterprise Edition 5.0
Hello:
Dose Kawa Enterprise Edition 5.0 support Orion J2EE server ??
Thanks in advance.
bubble chen(2000/10/10 PM 05:32:51)
[EMAIL PROTECTED]
==
PC home 'K6O9q$l+H=c!A%S=P=P\: http://www.pchome.com.tw
PC home Online :t8t.a.x!@!@ 7|-{2D$@!A%xFW3L$j*:$J$f:t/8
==
RE: EJB vs Servlets
At 10:54 10.10.00 , you wrote: Hi Kevin You seem to be missing the big picture here. With using a Servlet engine for handling all your logic you are putting all your eggs the same basket. You may have partitioned your logic up in the servlet container envirionment (MVC) but this is only at class level. EJB gives you distinct partioning at the component level. If you model all your Data and business logic at the EJB level then you create yourself a reuseable component layer. This way you can connect to this EJB layer from any clients, (Java) Servlets, (Java) jsp , (java) desktop client , (java) mobile client, (VB) desktop client, (CORBA) client and many more. At the moment you can only access your model layer through the servlet contain (or at least you can't easily access the same model from servlets and standalone clients, due to classloading etc) When you are accessing DB's from servlets you find yourself reinventing the wheel , for OR mapping, calling frameworks and data caching algorithims all the things that the best (like orion) app servers support :) generally agree here. the point is that you have to make good modelling decisions WHAT you package as a component because you do pay a price for modelling something as an ejb (overhead due to copy-by-value semantics, maintenance of assembly and deployment information etc. and yes, the development cycle is slower with all ejb server I've uesd including orion) which you have to justify by the value you get back (declarative transactions, flexibility to deploy in different environments, remote usability by non-web-clients). I don't think it's a good question to ask whether to generally use servlets or ejb (provided you have a working J2EE implementation at hand). it's like asking:"what's better? a race car or a jeep". you have to know the trade-offs to make good modelling decisions (HOW to use those technologies is the key) and that requires experience (especially having made bad ones ;-). however, there are many productive applications out there based on proven technologies like the apache jserv combination because they are rock stable, clustering is easy and people have had a few years time to find out the odds and evens of the particular technologies and I would agree that in many transactional web applications you would not lose too much if you did it with servlets, a transaction manager like tirex and some other O/R mapping layer like castor if you have a good architect. the modelling decisions (the tough part) you have to make are not that different. just my 2c, robert -Original Message- From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] Sent: Monday, October 09, 2000 6:22 PM To: Orion-Interest Subject: EJB vs Servlets Hey all, I know this is a little off-topic, but seeing as how Orion is about the only fully compliant EJB server, I figured this would be a better place to ask. Lately I have talked to a number of people that have been moving towards EJB and pulled back because they have found it to be more tedious to develop, as well as the end result was slower than just using Servlets. I ask this because it appears to me that the servlet engine (at least with 2.2) being able to be failed over, load-balanced, etc, seems to be quite as capable for scalability and fault-tolerance as the ejb engine used to be. I do realize that the EJB container offers transaction management, but connection pooling is available in the servlet engine at the server level as well. So, if you lose speed in development time and performance, what is the real benefits of moving to EJB? I should say this with caution..I am sure the EJB engine/container offers some things the servlet container doesn't, but I would think its possible to actually put those abilities in the servlet container. Anyways..I'll be interested in hearing any feedback on this. Thanks. (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
Re: EJB vs Servlets
Hani Suleiman wrote: 1) Connection pooling: This is available everywhere, and everyone can reap the benefits of it while being perfectly EJBless. 2) Transaction support: Stored procedures can take care of this. Stored procedures to do your transactions for you takes away the possibility to easilly 'plug-in' another database, which, imho is one of the greatest benefits of EJB. While trying to learn orion EJB at the same time, I was able to run the app I developed on Orion Interprise App Server against Oracle, DB2, Sybase, Cloudscape MYSQL without any changes to my code (Of course w/o the benefit of transactions in MySql. 3) Caching of database objects: Pretty easy to implement 4) Failover/load-balancing: As Kevin mentioned, works very nicely for servlets. Sure all this can be easilly implemented, but why should you? The guys at Orion, Inprice, IBM etc already did this for us. Which is another nice benefit of EJB, a container that does all this for you, you only have to implement the bussines logic. More tedious sure, it's the stuff mentioned above which is the nice part of programming, calculating priceindexes is not really fun. Having said all that though, I'm still going to try and use EJB's in my current project, and port all the existing 'model' objects to become full fledged EJB's. I'm hoping the advantages will become apparent then! Also, does anyone have any concrete examples of EJB's performance/scalability? Has anyone deployed them in a high volume production environment? Most people seem to be using them for prototyping and small scale projects, that I know of... It's quite a new technology, so there are hardly any big projects running. I know that here in brazil some financial institutions are messing with it (IAS because of Cobra). Sure EJB is slower, it's the java standard for a transactional framework, not the Java implemented in McLaren cars ;-) sven -- == Sven E. van 't Veer http://www.cachoeiro.net Java Developer [EMAIL PROTECTED] ==
Deployment platforms
We're at a planning stage for future deployment of a system which may include Orion (certainly a J2EE environment). I'm looking for information from people out there who have _real_ live deployments (not development code) of orion. 1. What Hardware are you running? 2. Which Operating System? 3. Which JVM? 4. Are you running a cluster? What extra hardware do you use, and what size cluster? 5. What kind of traffic? 6. What has been your experience (stability, performance, managability, etc) - mainly of the underlying platform, not orion. I do not want to start any religious wars here, just experiences of deployed systems. We are currently looking at Solaris and Win2K, maybe others. Our J2EE platform can be different to the rest of our system (call it legacy - talk to it via Corba), but there are then obvious management overheads. Please - talk to me! Thanks, Kev --- Dr. Kevin Palfreyman APAMA Ltd, 17 Millers Yard, Mill Lane Cambridge CB2 1RQ, United Kingdom Email: [EMAIL PROTECTED] Phone: +44 1223 706508 Fax: +44 1223 518859
R: Really basic problem with user authentication
Have you defined roles in application.xml? Luciano -Messaggio originale- Da: Ben Z. Tels [mailto:[EMAIL PROTECTED]] Inviato: lunedì 9 ottobre 2000 21.28 A: Orion-Interest Oggetto: Really basic problem with user authentication L.S. I am having the following problem with principals on the Orion server (version 2.1): I have principals defined in an applicaiton-specific principals.xml file, like so: - principals.xml ?xml version="1.0"? !DOCTYPE principals PUBLIC "//Evermind - Orion Principals//" "http://www.orionserver.com/dtds/principals.dtd" principals groups group name="StoreOwner"/group group name="Customer"/group /groups users user deactivated="false" locked="false" password="KerLach" realname="Ben Tels" username="ben" group-membership group="StoreOwner" / group-membership group="Customer" / /user user deactivated="false" locked="true" password="" realname="" username="anonymous" group-membership group="Customer" / /user /users /principals --- lmx.slapiclap --- Needless to say, my client application gets refused ( Invalid user/password (ben) ). If anybody can help, I'd really appreciate it. Thanks in advance, Ben Z. Tels [EMAIL PROTECTED] http://www.stack.nl/~optimusb/ UIN:2474460 "The Earth is the cradle of the mind, but one cannot stay in the cradle forever." --Tsiolkovsky
RE: EJB vs Servlets
What a fun discussion. There are obviously alot of strong opinions out there, and here's one more. :) I come from a DCE/Encina background and have been playing with EJB 1.1 (Orion) for about 2 months now. For those of you not familiar with Encina, it is a highly distributable RPC environment with very strong security, transaction support, etc. My take on EJB is as follows. The biggest benefit I see from EJB is distribution, transaction management, and security. I still think EJB still has a long way to go, but it's getting there. 2.0 seems to be another strong step in the right direction. As far as ease of development, pure enterprise beans are straight forward. Where I run into complexity is when I start getting a complex object model (lots of one-to-one and one-to-many relationships.) Even on this list, it has been strongly recommended that you don't talk to entity beans directly, but instead, talk via a session bean. This is almost necessary if you want any kind of decent transactional control (unless you mess with user transactions). Where I think this gets nasty is taking you details objects (somtimes called value objects, see details pattern at www.theserverside.com) and syncing them with your entity beans. With one-to-many's this is not a trivial task. As far as the OR mapping features of EJB (even 2.0) they are still weak. There are more sophisticated solutions for OR mapping (Toplink for Java, Cocobase, etc.). Unfortunately, the EJB spec doesn't provide a way for vendors of these tools to write plugins for expanding the functionality of EJB. (Although there is a Weblogic specific version of Toplink that allows for very sophisticated OR mappings) Also, EJBs and servlets are not mutually exclusive. While you don't always need both, as Russ White pointed out, if you need to be distributed, EJBs give you that without worrying about what kind of client you have. For web access to your app, servlets and JSPs can be clients to your EJB app. Lastly, as far as performance goes, I believe you are going to take a performance hit (not necessarily significant) with EJBs versus talking to to your persistence classes directly. This is because you are always going through the client stub when you use the EJB remote interface. In DCE and CORBA, when you call the client stub, it is optimized to do an RPC if the server is on a different machine, an IPC if it's on the same machine, and a simple method call if in the same process. EJB doesn't offer that kind of optimization, therefore, you are always serializing what your are passing to and from the enterprise bean. As far as the question that kicked of this discussion. If you do not need the any of the benefits of EJB then don't use it. However, I would recommend that you separate your data and business layers from your servlets and JSPs. Have them be presentation only. That way you could always grow into EJB without having to rewrite your front end. Bill -Original Message- From: Robert Krueger [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 10, 2000 7:04 AM To: Orion-Interest Subject: RE: EJB vs Servlets At 10:54 10.10.00 , you wrote: Hi Kevin You seem to be missing the big picture here. With using a Servlet engine for handling all your logic you are putting all your eggs the same basket. You may have partitioned your logic up in the servlet container envirionment (MVC) but this is only at class level. EJB gives you distinct partioning at the component level. If you model all your Data and business logic at the EJB level then you create yourself a reuseable component layer. This way you can connect to this EJB layer from any clients, (Java) Servlets, (Java) jsp , (java) desktop client , (java) mobile client, (VB) desktop client, (CORBA) client and many more. At the moment you can only access your model layer through the servlet contain (or at least you can't easily access the same model from servlets and standalone clients, due to classloading etc) When you are accessing DB's from servlets you find yourself reinventing the wheel , for OR mapping, calling frameworks and data caching algorithims all the things that the best (like orion) app servers support :) generally agree here. the point is that you have to make good modelling decisions WHAT you package as a component because you do pay a price for modelling something as an ejb (overhead due to copy-by-value semantics, maintenance of assembly and deployment information etc. and yes, the development cycle is slower with all ejb server I've uesd including orion) which you have to justify by the value you get back (declarative transactions, flexibility to deploy in different environments, remote usability by non-web-clients). I don't think it's a good question to ask whether to generally use servlets or ejb (provided you have a working J2EE implementation at hand). it's like asking:"what's better? a race car or a jeep". you have to know the trade-offs to make good modelling decisions (HOW to
RE: EJB vs Servlets
hello all, since it came up, this is an issue that i and our other programmer have been wrestling with for a while, because like everyone else we feel the pressure to use the cool new stuff..and we wonder if the transactional and distributed advantages will help us out. here is my problem. call me dense, but i just don't see or mapping being as flexible as i need it to be. in all the books the examples tell you that you map your object to the table that holds its data. sounds fine in theory, but we have some very complex objects, and we have a complex relational model, the reason for which is to store our data efficiently, not only for this application, but also for others. so we have objects that need to get their data from different tables, even different databases. these objects contain collections, single entities, indexes into other objects, etc., all of which must be persisted in the db. we have solved the problem by writing our own dblayer, employing reflection and stashing all our queries (as well as caching them and the connections) in a static lookup object. this gives us a level of control over the data that i cannot see us getting from any OR tool, no matter how smart (and remember, the smarter something is, the slower). as to transactional support, we use jts or the db transaction services. no problems.. as to servlets, we use exactly one per application, mereley to take the requests and to control everything--everything else is plain old java classes. it is blazingly fast. i cannot believe that looking up objects through jndi is going to be as quick as looking up my classes in a hashmap. if i want distribution, i simply break my app into multiple apps, run them on separate machines, and use the same object model--thats one benefit of oo, right? i hope someone has the time to refute me completely, because, like kevin, i really do want to understand what ejb will give me that i cannot live without. my greatest concern, as i mentioned above, is OR mapping. i have been a dba and a programmer, and i find it really difficult to believe that some tool is going to produce more efficient and more flexible access to my data than i can, given that i currently have full control from table to view to sp to accessor methods on objects.. bradley mclain --usmoving.com --- "Duffey, Kevin" [EMAIL PROTECTED] wrote: Hi Mike (and all), Actually, while Struts is pretty kewl, there are some things that I wish were modified that won't be for reasons of the general population interest instead of my own. Because of this, while I will continue to use Struts at work, my own projects will use my own solution, similar to Struts but not near as robust in some ways, but a bit better on performance. The one thing I really dislike, but I agree with based on what Craig has told me, is that every single form submission causes the auto-population feature to get called (reflection). I only want it to be called if an update occurs. If the user hits cancel to go back, or what not..I don't much care what they just entered. Only when doing searches or updates/entry on forms should it be called. For that reason I am doing my own reflection population routine that does use nested objects. But overall Struts kicks ass in what it offers for a free package. Did I compare Struts to EJB? I didn't mean to in terms of performance. -Original Message- From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED]] Sent: Monday, October 09, 2000 4:12 PM To: Orion-Interest Subject: RE: EJB vs Servlets I have to laugh when someone compares Struts to EJBs for performance. I've used both and I'd have to say Kevin that if you factored your code away from Struts and used EJBs instead you'd have a very VERY minimal performance impact (if any noticable at all). And looking up EJBs is really very simple two lines of code (or one little JSP tag ejb). Although if you wanted to attach a Swing client to Struts... you'd have much greater problem I fear? ;) Mike PS Struts does have some cool points, I wish they'd break out the i18n stuff into another library, it doesn't seem to fit there. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin Sent: Tuesday, October 10, 2000 5:01 AM To: Orion-Interest Subject: RE: EJB vs Servlets Actually, I know all about it. I have read up on it in those books and others. Infact, we have already separated our code into those tiers but it all runs in the servlet engine. This is what I am talking about. I am using the Struts framework to allow all forms submitted to a single controller servlet, which then calls upong action classes. Those action classes then figure out what "session" class to call upon. These "session" classes are our logic (ejb) code, but its not in the EJB
Re: Performance
Hi, This mail is useful only if you're using entity EJBs. Because EJB is RMI on steroids (is more than that, but let's keep it simple), if you need more that one entity to get the data you need for the presentation layer you end up opening a lot of rmi connections, with the overhead it implies. The solution is simple, yet elegant: Create a Session Bean, collect all the data (raw data, not the remotes) from the Entity Beans and use that for the presentation. That way you use only one rmi connection. Hope this help. -- Best regards, Rafaelmailto:[EMAIL PROTECTED]
Re: Out of memory
Tell the Orion JDK to use more memory on startup. I think the command line jdk startup parms are ms:64M for min memory mx:80M for maximum memory, and -gc for no incremental garbabe collection. Jas Vlad Petric wrote: Stanislav Maximov wrote: Hello, I'm constantly getting "Out of memory error" from Orion. Please shed some light if there are some typical mistakes which may cause it, or maybe debug tips? Great thanks in advance. stas@ JOVOS ?? (JVM, Orion Version, Operating System ?) Have you tried a manually started garbage collection ? When does the problem occur ? when running EJB/JSP code or just like that ? Are you by any chance running Orion with a different heap size ? Vlad Vlad Petric wrote: Stanislav Maximov wrote: Hello, I'm constantly getting "Out of memory error" from Orion. Please shed some light if there are some typical mistakes which may cause it, or maybe debug tips? Great thanks in advance. stas@ JOVOS ?? (JVM, Orion Version, Operating System ?) Have you tried a manually started garbage collection ? When does the problem occur ? when running EJB/JSP code or just like that ? Are you by any chance running Orion with a different heap size ? Vlad
Re: EJB vs Servlets
Hello Reddy, I agree with you in some points. Yes, complex OR mapping is solved in 2.0, but as you said is a draft. I won't risk put it into production right now (we have to finish the project by Octuber 17). About SQL, again I agree with you. I was using BMP EJB until I found out that Orion 1.3.6 generates automatically the findByAll() and findByXXX(). That way I have a better control over the beans I need. There is something I left out from the last mail. Because EJB1.1 complex O-R mapping is impossible (you need a workaround), sometimes I need a BMP Entity because I need a complex query. And for me, the myth was true. The migration from HyperSonic SQL to Oracle was transparent for the application. I just had to redeploy the application, and volia!, all the tables and constraints where there. The mass import was a little more tricky, (we used JDBC and SQL, query one place, insert in the other). Two side notes about independance from tables and databases: If you relay on triggers, multiple-field primary keys, foreign key for consistency, etc..., you have to stick into you RDMBS. And remember: never, ever, use a RDBMS that don't support multiple-field primary keys. They only give you headaches. -- Best regards, Rafaelmailto:[EMAIL PROTECTED]
