RE: Impossible getting the attention of the orion (support) team. Are they still around?
I have given up on Orion (support), completely. When I got to know Orion, I was very excited with the EJB 2.0 preview, very good performance etc. Of course, like most of you I was disappointed with the documentation, but that was no excuse not to try the software. I was generally happy with the server. But when I encountered unexpected behaviour I tried to obtain support. It was never answered. I have entered a bug (229) in Bugzilla a long time ago (Opened: 2000-12-19 23:57). It was never processed (maybe read and dismissed) but it is still (as of now) in the NEW state. To me that shows a level of code maintenance that is IMHO way below minimum. Maybe it wasn't a bug ? Place it in the assigned, won't fix, duplicate, etc. state... whatever! But don't leave it in the NEW state, it sends the signal that they didn't look and/or they don't care. 'As far as I can see', Orion is going down the drain. I really wish they come up with a support plan for the rest of you guys (with Ironflare?) We won't need it as we have completely phased Orion out of our RD project. We have now joined the legions of JBoss developpers/users. The fact we have access to and can contribute to the source code is reason enough. And to those who say EJB 2.0 is reason enough to stay with Orion I say, have a look at www.mvcsoft.com who provides for a mere 28$ a persistence manager for JBoss that supports EJB 2.0, including EJBQL. I wish all of you the best with your respective projects. I'll be seeing many of you on the JBoss' mailing lists I am sure :) Cheers, Daniel -Message d'origine- De : Douma, Ate [mailto:[EMAIL PROTECTED]] Envoy : 19 mars, 2001 05:24 : Orion-Interest Objet : 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/msg09692.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: Customizing CMP deployment
What you want to do is provide your own orion-ejb-jar.xml. place it in your XXX-ejb.jar under orion/orion-ejb-jar.xml It will get copied at deployment time. Orion will fill-in all that is missing but will start with your own copy. You can then specify tables and attributes for your CMP mappings. HTH Daniel -Message d'origine- De : Sergei Batiuk [mailto:[EMAIL PROTECTED]] Envoye : 12 mars, 2001 10:51 A : Orion-Interest Objet : Customizing CMP deployment Is there any way to customize deployment of CMP bean - to indicate the table name in the database to which the entity bean should map its persistence (in case the name of the table is different from the bean name) or the data source to connect to. As far as I know orion-ejb-jar.xml is responsible for these properties, but it has no effect ibefore/i the deployment. Is there an orion-specific (or some other) way to deliver such information to the container?
RE: No influence on CMP 2.0 getter setter methods - a feature or a bug?
I completely understand where you're trying to go. However, keep in mind
Entity beans are not meant to hold business rules. They are an interface
to
your physical storage.
We have solved that problem using a facade pattern that basically works
by
shielding the developper from the actual method being called on the
server.
For example:
Create an Entity bean AccountBean
Create a stateless session bean AccountBusinessRules
Leave the setBalance in the Entity Bean and add a setBalance in the
BusinessRules bean.
Use a reference to the remote interface as the first parameter, like
this :
public class AccountBusinessBean implements SessionBean
...
public setBalance(AccountBean ref, float balance)
{
// put the business code here...
// you can also use
ref.setBalance(balance);
}
... other business methods, not necessarily tied to remotes
The facade has the following generated code (with checks, try catch
etc.):
public class Account extends BusinessObject
public setBalance(float balance)
{
getBusinessBean().setBalance(getRemote(), balance);
}
... the other business methods calls
The client application instantiates the facade object
Account acct = new Account(new Integer(accountNumber)); // for
an existing entity
acct.setBalance(newBalance);
The client application developper does not know (or need to know?) which
method gets called. It's the
job of the developper providing the Bean.
So the trick is generating the facade. We use a java doclet that
generates our facade objects by
combining AccountBean methods with AccountBusinessRules methods. We use
method tags in the Entity
and Business beans to "inform" the doclet about how to process the
methods in the facade.
This allows an easy switch from a "pure" data set (method only in the
Entity Bean) to a business
method being called (both in Entity and BusinessRules) without impacting
existing client applications
in any way.
As a bonus, with stateless session beans, you get pooling of business
methods, which makes more
efficient use of the server's ressources than having the code in
stateful beans or entity beans (BMP).
This works very well for us. If you have better suggestions, let's
discuss them!
Cheers,
Daniel
-Message d'origine-
De : Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
Envoy : 21 fvrier, 2001 11:46
: Orion-Interest
Cc : Jens Peter Grosen; Simon Anker Christiansen; Kim Jrgensen
Objet : No influence on CMP 2.0 getter setter methods - a feature or a
bug?
I have been reading the CMP 2.0 specification and I think it is simply
great! Still, I am a bit surprised that the bean developer has no
control
over what happens when a field is set. Imagine an AccountBean, for
instance:
public abstract class AccountBean extends EntityBean {
//implemented by the persistence manager
public abstract Float getBalance();
//implemented by the persistence manager
public abstract void setBalance(Float balance);
}
What if I wanted to do something useful when the balance was set? Say, I
wanted to add the account to a list of surveilled accounts if a
negative
balance was set... it seems I cannot do that because the container
implements the setBalance() method for me. And I cannot just declare a
setBalance() method myself because I need the container's implementation
or
I will not be able to store the balance. H... it seems this is going
to
leave me with something like
public abstract class AccountBean extends EntityBean {
public abstract Float getBalance();
public abstract void setBalance(Float balance);
public void
setBalanceAndDoWhatHasToBeDoneWhenYouSetBalance(Float balance)
{
//check if balance is negative and take action
...
setBalance(balance);
}
}
Now I have _no_ guarantee that nobody will accidently call the original
setBalance() method, thereby circumventing my little security system,
which
was supposed to check for a negative balance. But, hey, I thought, then
I
will just declare the original setBalance() as protected - unfortunately
that is not allowed by the specification.
I would r e a l l y like to hear from anybody who knows a solution to
this.
Any comments would be most welcomed.
Randahl
RE: Orion-console in 1.4.7 supports DataSource properly... now what!!!
Allen,
You are right... the lookup from within any EJB works flawlessly. I am
trying to get it to work on the client side.
See my other reply for more info...
Thanks for your comment,
Daniel
-Message d'origine-
De : Allen Fogleson [mailto:[EMAIL PROTECTED]]
Envoy : 6 fvrier, 2001 21:30
: Orion-Interest
Objet : RE: Orion-console in 1.4.7 supports DataSource properly... now
what!!!
Daniel;
As far as I can tell the DS lookup works in 1.4.7 I have an app that
does
many lookups and I just ran it unchanged from 1.4.5 to 1.4.7. Now
Granted I
am in orion so I just have to do a...
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("jdbc/myDS");
So maybe it might not work with the initialApplicationContext??
(although
the console belies that)
Al
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Daniel Cardin
Sent: Tuesday, February 06, 2001 4:17 PM
To: Orion-Interest
Subject: Orion-console in 1.4.7 supports DataSource properly... now
what!!!
Hi everyone!
I'm progressing... Orion 1.4.7 has support for DataSources in the
orion-console application.
If you select a DataSource, you will see a new panel allowing you to
enter SQL commands that will
be sent directly to the database through the DataSource + connection.
it WORKS in the console. So this implies that :
1. the concept is valid : you don't need to use a driver instance on the
client side, contrary to what
some of you stated. No JDBC download, nothing... just a proxy
instance implementing the Connection interface
2. the client doesn't need to see the database server on the same
network
3. my datasources are configured PROPERLY on the server side... (I was
always doubting that
but normal DS, pooled DS, EJB DS etc. all work from my client
(actually only XA won't work now))
SO: since I get perfect access through the console, either
a) I can't do a JNDI lookup! (I doubt that)
b) the DataSource lookup is not working (yet) in 1.4.7
c) OrionConsole uses another method than a simple lookup to get the
DataSource object.
Please everyone, realize this is important for performance issues and
let's try to make it work!
Thanks for your help
Daniel
RE: Orion-console in 1.4.7 supports DataSource properly... now what!!!
Jeff, Are you sure that the JDBC driver isn't finding its way into the classpath? Did you try the console remotely from a machine that you know doesn't have the JDBC driver? Honestly, I haven't. But I still fail to see why it would be needed. If the data access was done using the "real" JDBC driver on the client, the connection to the database would have to be opened there... It's not the case. Running tests at home allowed me to prove that the Connection must be proxied through Orion because my client could not see the SQL server. The only conclusion is that Orion opens a connection locally, pools it, and on demand gives a proxy to it allowing all database access to go through the App Server... You may already know this, but just in case: Almost all of the orion tools (including orionconsole.jar) are simply empty jar files with a manifest that sets the Class-Path to include orion.jar and defines the appropriate Main-Class. You're still loading the orion.jar classes, potentially activating whatever classloader loads jars (especially the JDBC driver) out of the lib directory. Did you take this into account in your tests? I know about the way orionconsole works, thanks :) I've actually spent quite some time analysing com.evermind.gui.server and com.evermind.server to figure out exactly what's going on. So far, I believe DataSource access goes through another JNDI bound object the ApplicationAdministrator. I still have to test that avenue fully. We now have four different theories about how application-client JDBC works in app servers: 1) Database-specific JDBC driver gets packaged with the application client and loaded into the client VM. 2) Database-specific JDBC driver gets http-classloaded into the client VM. 3) Serialized classes come from JNDI. Actually, I think this is just another way of saying #2, because java RMI uses http classloading to get the class definitions to a new client. 4) App server provides a JDBC proxy which implements a proprietary wire protocol (or at least RMI "object protocol") to communicate with the server. Note that this is not just simply a matter of remoting the implementation of the Connection interface; you would have to remote the implementations of ResultSet, Statement, and any other interfaces associated with JDBC. And you have to be pretty smart about how you do it, otherwise it's going to perform a lot worse than EJB methods. I tend so far to go for 4, just because it is impossible that my client running from home had access to the server. No direct TCP/IP route from my subnet to the company's 192.168.1.111/24 No way around that limitation :) My understanding... please all feel free to add to this, especially Orion's developpers !!! A DataSource is a mechanism used encapsulate access to JDBC connections. Orion manages Connections with the ConnectionDataSource objects. In "theory", a client uses JNDI to lookup the DataSource object, gets an RMI proxy, and retrieves a Connection object. the way I see it, the DataSource implementation on the server side HAS to return a proxy to the Connection, which only resides on the server. I don't see any other way around that explains why I could use the console from home and still get to the data. Now, I think that the current DataSource lookup does not work as I understand it should. Maybe I'm not proceeding properly. But now that I have seen it work in the console, I will not stop until it works in my client application! :) Does anyone out there *know* what Orion does? Anyone? :) Daniel -----Original Message- From: Daniel Cardin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 1:17 PM To: Orion-Interest Subject: Orion-console in 1.4.7 supports DataSource properly... now what!!! Hi everyone! I'm progressing... Orion 1.4.7 has support for DataSources in the orion-console application. If you select a DataSource, you will see a new panel allowing you to enter SQL commands that will be sent directly to the database through the DataSource + connection. it WORKS in the console. So this implies that : 1. the concept is valid : you don't need to use a driver instance on the client side, contrary to what some of you stated. No JDBC download, nothing... just a proxy instance implementing the Connection interface 2. the client doesn't need to see the database server on the same network 3. my datasources are configured PROPERLY on the server side... (I was always doubting that but normal DS, pooled DS, EJB DS etc. all work from my client (actually only XA won't work now)) SO: since I get perfect access through the console, either a) I can't do a JNDI lookup! (I doubt that) b) the DataSource lookup is not working (yet) in 1.4.7 c) OrionConsole uses another method than a simple lookup to get the DataSource object. Please everyone, realize this is important for performance issues and let's try to make it work! Thanks for your help Daniel
My final notes on DataSources... disappointing!
Ok folks...
Here's what I have found out. Contrary to what I believed, it seems
the Orion console uses another trick than a DataSource to run SQL
commands on the server: the executeSQL method of the
ApplicationAdministrator
class. I have managed to run commands from my client program using this
snippet :
java.util.Properties p = new java.util.Properties();
p.put("java.naming.factory.initial",
"com.evermind.server.ApplicationClientInitialContextFactory");
p.put("java.naming.provider.url", "ormi://server/application");
p.put("java.naming.security.principal", "admin");
p.put("java.naming.security.credentials", "yoursecret");
ctx = new InitialContext(p);
ApplicationAdministrator appAdmin = (ApplicationAdministrator)
context.lookup("java:comp/Administrator");
RowSet rs = appAdmin.executeSQL("jdbc/pooled/MyDS", "SELECT * FROM
TestTable");
This returns a serializable rowset from the server... That's it. Not
portable,
very disappointing. I really hoped DataSources would work from the
client side.
It seems you can only do it through the appadmin. PLEASE CORRECT ME IF
I'M WRONG :)
On another note, this line retrieves the list of all datasources for an
application
List sources = appAdmin.getDataSources();
this is a List of DataSourceConfig objects, NOT DataSource. DSC contain
info about
the various JNDI locations, username, password etc. all the properties
defined
in data-sources.xml
Hope this turns out helpful to some of you!
Cheers,
Daniel
Orion-console in 1.4.7 supports DataSource properly... now what!!!
Hi everyone! I'm progressing... Orion 1.4.7 has support for DataSources in the orion-console application. If you select a DataSource, you will see a new panel allowing you to enter SQL commands that will be sent directly to the database through the DataSource + connection. it WORKS in the console. So this implies that : 1. the concept is valid : you don't need to use a driver instance on the client side, contrary to what some of you stated. No JDBC download, nothing... just a proxy instance implementing the Connection interface 2. the client doesn't need to see the database server on the same network 3. my datasources are configured PROPERLY on the server side... (I was always doubting that but normal DS, pooled DS, EJB DS etc. all work from my client (actually only XA won't work now)) SO: since I get perfect access through the console, either a) I can't do a JNDI lookup! (I doubt that) b) the DataSource lookup is not working (yet) in 1.4.7 c) OrionConsole uses another method than a simple lookup to get the DataSource object. Please everyone, realize this is important for performance issues and let's try to make it work! Thanks for your help Daniel
RE: Re[2]: R: R: frustrated - jdbc: No suitable driver
Have anyone else seen the problem where the getConnection() returns a com.evermind.sql.ak type, but ANY operation on that connection such as getMetaData etc. raises a NullPointerException ? I am desperate to connect to a JDBC datasource _cleanly_ from the client side. Is it possible ? Thanks! Daniel -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Envoy : 5 fvrier, 2001 08:06 : Orion-Interest Objet : SV: Re[2]: R: R: frustrated - jdbc: No suitable driver You shouls check out the getConnection implementation on the datasource. It gets a reference it pass on to the client, so the client need to have the jdbc interfaces to do this, but it dont need the database drivers. It works much like the same way as an entitybean works (datasources)... Have fun. Klaus -Opprinnelig melding- Fra: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sendt: 5. februar 2001 12:17 Til: Orion-Interest Emne: RE: Re[2]: R: R: frustrated - jdbc: No suitable driver I'm fully prepared to believe that my understanding of how this works is wrong, but if so it raises quite a few questions for me. Connection, Statement, ResultSet, etc are just interfaces; something must implement them. Normally they are implemented by the JDBC driver, thus allowing the client to communicate with the database using whatever the database uses asa native wire protocol. We have an application client which we want to communicate with the database using JDBC. If we want to use the database's native wire protocol to communicate from the client box to the database box, the JDBC drivers *must* be loaded into the client's VM and used. Alternatively, the app server could act as an intermediary, providing a proxy JDBC interface to the application client and making JDBC calls into the real JDBC driver within the application server. This would obviate the need for the database's JDBC driver on the client, but it would also require inventing a whole new wire protocol for this middle link... sending partial result sets in chunks, maybe caching query results in the client, etc. So now I'm thinking, that sounds painful, but it's possible. It's not like writing an app server is supposed to be *easy* or anything :-) No, Karl and Magnus are supposed to suffer so that it's easy for *us* to write applications :-) But a casual purusal of the decompiled Orion source code (that can be made out through the obfuscation, which is quite a bit) turns up no evidence of such a proxy. In fact, it looks very much like this is not the case. Getting more curious, I checked the JBoss source tree, and while I can't be sure in such a quick study, it doesn't look like there is any sort of intelligent JDBC proxy in that server either. Am I just missing it, and all app servers implement such a proxy? Or is it just WebLogic - allowing the behavior described in the original post? Or is WebLogic doing http-type classloading to get the JDBC driver into the client (a prospect I am considering less likely the more I think about it)? Ever curious, Jeff -Original Message- From: Allen Fogleson [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 04, 2001 10:46 AM To: Orion-Interest Subject: RE: Re[2]: R: R: frustrated - jdbc: No suitable driver Uhmmm, I agree, I was confused because someone said they still needed the JDBC drivers on the client, and assuming you use the portable method of DataSources, there should be no reason that they would need to have the JDBC drivers, it is all handled container side with the datasource. Al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rafael Alvarez Sent: Sunday, February 04, 2001 10:24 AM To: Orion-Interest Subject: Re[2]: R: R: frustrated - jdbc: No suitable driver Hello Allen, DataSources gives you one advantage on the client side: Security. If you use a direct JDBC connection to a Database, your username, password and URL have to be placed in your class. A Datasource hides all those details, so if some one decompile your class (even JAXed classes are not totally safe) only the JNDI Datasource name will be found. It's up to you to set a security schema for the connection with the app server, but at least is one problem less to solve. -- Best regards, Rafaelmailto:[EMAIL PROTECTED]
RE: Pooled Data Source ADDENDUM! Design question for you :)
I think I have not made myself clear enough. The DataSource access works
in the
context of the appserver running. What I was trying to do is access a
DataSource
from the application client side. Now, this is the fix for my problem,
but maybe
there is a better way to resolve this, so I will explain what I'm trying
to
accomplish on the client side.
I have many requests to the database that return a high number of rows
to be
displayed in the client application. Now, my current framework allows me
to build
portable data object and transmit them accross the wire, but you will
surely
agree with me that building 1 objects and serializing them is NOT
efficient.
I have then tried using the new CachedRowSet object from Sun on the
server side
and returning (serializing) the ResultSet directly to the client app.
But this
process is _still_ very long as the serialization of so many records is
very expensive. (ie about 10 seconds, versus less than one second with a
local
connection object, vs about 500 ms with an ADO.RecordSet)
I thus get very good performance if I open up the ResultSet on the
client side, but
this is something I wanted to avoid. In the very least I figured that if
I could
get a connection from the server connection pool, I could build up the
SQL request
on the server and execute it blindly on the client through a generic
mechanism.
So, I ask you, what should I do to access large number of rows ?
And is it possible to use a DataSource from the application client when
the beans
are deployed as CMP beans ?
Thanks!
Daniel
-Message d'origine-
De : Daniel Cardin
Envoy : 29 janvier, 2001 11:08
: Orion-Interest
Objet : Pooled Data Source
Well... it seems I just can't make it work, even though I have read just
about all the messages on the subject.
datasources :
data-source
class="com.evermind.sql.DriverManagerDataSource"
name="ddsNP"
location="jdbc/ddsNP"
xa-location="jdbc/xa/ddsXANP"
ejb-location="jdbc/ddsNP"
connection-driver="com.inet.tds.TdsDriver"
username="sa"
password=""
url="jdbc:inetdae7:theserver:1433?database=test"
inactivity-timeout="30"
schema="database-schemas\ms-sql.xml"
/
data-source
class="com.evermind.sql.OrionPooledDataSource"
name="dds"
location="jdbc/ddsDS"
xa-location="jdbc/xa/ddsXADS"
ejb-location="jdbc/ddsDS"
max-connections="2"
source-location="jdbc/ddsNP"
pooled-location="jdbc/ddsDS"
username="sa"
password=""
inactivity-timeout="30"
connection-driver="com.inet.tds.TdsDriver"
url="jdbc:inetdae7:theserver:1433?database=test"
/
the code
DataSource ds = (DataSource)ctx.lookup("jdbc/ddsNP"); // have used
jdbc/ddsDS as well...
the lookup returns an OrionCMTDataSource
but the call to getConnection()
DatabaseMetaData dmd = ds.getConnection().getMetaData();
raises :
java.lang.NullPointerException
at com.evermind.sql.OrionPooledDataSource.d8(JAX)
at com.evermind.sql.ak.eo(JAX)
at com.evermind.sql.ak.ep(JAX)
at com.evermind.sql.ap.getMetaData(JAX)
at dds_testclient.Frame1.dsTest(Frame1.java:81)
Hints anyone ?
Thanks!
Daniel
Pooled Data Source
Well... it seems I just can't make it work, even though I have read just
about all the messages on the subject.
datasources :
data-source
class="com.evermind.sql.DriverManagerDataSource"
name="ddsNP"
location="jdbc/ddsNP"
xa-location="jdbc/xa/ddsXANP"
ejb-location="jdbc/ddsNP"
connection-driver="com.inet.tds.TdsDriver"
username="sa"
password=""
url="jdbc:inetdae7:theserver:1433?database=test"
inactivity-timeout="30"
schema="database-schemas\ms-sql.xml"
/
data-source
class="com.evermind.sql.OrionPooledDataSource"
name="dds"
location="jdbc/ddsDS"
xa-location="jdbc/xa/ddsXADS"
ejb-location="jdbc/ddsDS"
max-connections="2"
source-location="jdbc/ddsNP"
pooled-location="jdbc/ddsDS"
username="sa"
password=""
inactivity-timeout="30"
connection-driver="com.inet.tds.TdsDriver"
url="jdbc:inetdae7:theserver:1433?database=test"
/
the code
DataSource ds = (DataSource)ctx.lookup("jdbc/ddsNP"); // have used
jdbc/ddsDS as well...
the lookup returns an OrionCMTDataSource
but the call to getConnection()
DatabaseMetaData dmd = ds.getConnection().getMetaData();
raises :
java.lang.NullPointerException
at com.evermind.sql.OrionPooledDataSource.d8(JAX)
at com.evermind.sql.ak.eo(JAX)
at com.evermind.sql.ak.ep(JAX)
at com.evermind.sql.ap.getMetaData(JAX)
at dds_testclient.Frame1.dsTest(Frame1.java:81)
Hints anyone ?
Thanks!
Daniel
RE: E_Roman e-commerce application(Mastering Java Beans)Wiley
I have unsuccessfully tried to implement CMP using PK classes... Normal implementation, public fields, overriding of the hash value etc. Anyone got EJB 2.0, CMP, composite keys PK classes working ? Thanks, Daniel -Message d'origine- De : Juan Lorandi (Chile) [mailto:[EMAIL PROTECTED]] Envoy : 21 janvier, 2001 13:22 : Orion-Interest Objet : RE: E_Roman e-commerce application(Mastering Java Beans)Wiley I believe your last assertion is false. Any entity bean that has a composed key (that is, its key maps to more than one field in the persistence) must have its own PK class check the specs JP -Original Message- From: Oglinda [mailto:[EMAIL PROTECTED]] Sent: Sbado, 20 de Enero de 2001 22:35 To: Orion-Interest Subject: Re: E_Roman e-commerce application(Mastering Java Beans)Wiley At 01:31 AM 1/20/01 +, faisal wrote: Hi -Has any body tried to install Ed Roman e-commerce examples on Orion?. I am studying the book and I have played with some of the EJBs. There are some problems 1. I assume the code was written with the EJB 1.0 specifications because it is using some deprecated methods. 2. The author was using WebLogic to deploy the beans and there are some major differences in the way you deploy the EJBs. -Another question is it possible to do without creating a seperate class for the primary key such as "customerPK.class" I am not an expert but from what I have noticed: * CMBs do not need a PK class * Bean-Managed persistence requires a PK class. Danut _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
RE: O/R mapping
I'd like to point out that a third table is only needed for a N-M (many-to-many) relationship. In the case of a 1-N relationship, simply have a foreign key to the master table. For example : Customer object refers to a Country object you a Customer will only have one Country object. you do NOT need a third table to map this. Simply add a field in Customer that contains the foreign key to the Country object. The EJB 2.0 mapping is Simple Customer ... public abstract Country getCountry(); public abstract void setCountry(Country aCountry); and in Country public abstract Collection getCustomers(); public abstract void setCustomer(Collection customers); This is fully supported by Orion, which will populate the collection object automatically. Cheers, Daniel -Message d'origine- De : Tony J Brooks [mailto:[EMAIL PROTECTED]] Envoy : 22 janvier, 2001 11:27 : Orion-Interest Objet : RE: O/R mapping Hi Theis, As much as I can remember, there *is* - definitely - a need for an intermediate third table to contain the mapping information. By using this third table, you eliminate data replication/redundancy in the other two tables. To my knowledge this is a common technique. ER tools typically create such an intermediate table for you when you select a relationship to be 'zero/one/many to many'. Whether you see that on your diagram is another matter, but you will definitely see it in your DB ;) Apologies if I have misunderstood your question. Bye for now, Tony. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: 22 January 2001 15:10 To: Orion-Interest Subject: O/R mapping Hi! I have been reading the complex-or example and ploughed through the atm example. In the complex-or example it is stated that collections are mapped to an another table and that the reason for this is normalization. The Atm example is also following this principle. Is this really correct? I have never seen the necessity for mapping anone to many relation to a third table (even though it was a long time ago I read the rules of normalization I'm very doubtful that this is correct). Could someone tell me the rational behind this. If this not true, how does the xml look like (in the orion-ejb-jar.xml) when you only map the relation as a foreign key? Regards /Theis
Composite PK classes
Has anyone managed to build EJB 2.0 applications using Orion, CMP and composite primary keys using a PK class ? I believe I have followed all recommandations but can't seem to make it work. Cheers, Daniel
RE: O/R mapping
I'm a CMP fanatic too :) But keep in mind some of us have to deal with existing models that have been created in the "traditionnal" RDBMS fashion. It's good to have control on the way CMP will work with Orion. We have solved the O-R mapping problem by having a code generator generate first-cut beans from the database. Then we use a heavily modified version of Rickard berg's java doclet to generate the home interface, the remote interface a data structure for quick access to data, the ejb-jar.xml AND orion-ejb-jar.xml which allows fine-grained control on the tables and attributes used for the mapping through the use of javadoc tags. For example, all CMP fields are marked with the tag @cmp-field. a @cmp-table tag will indicate (through the orion-ejb-jar.xml file) what underlying table is needed for the bean. Similarly @cmp-attribute indicates the doclet what underlying attribute we are mapping to. 1-N and N-M relationships are also supported through doclet tags. This allows a quick regeneration of all source files from one master bean source file. It also enables, through modifications to the doclet, generating other vendor specific files like jboss.xml, inprise-ejb.xml etc. As a bonus, the doclet generates a faade object that allows a connected (via remote methods) or disconnected (via the data object) view of an entity's data. This was a little off-topic, but the point I'm trying to make is that when existing schemas are used, some knowledge on the mapping process can help. Cheers -Message d'origine- De : Magnus Rydin [mailto:[EMAIL PROTECTED]] Envoy : 23 janvier, 2001 08:51 : Orion-Interest Objet : SV: O/R mapping One of the things I like best with EJB is that I dont have to care about how my objects are stored (Yes, im a CMP fanatic). So my personal contribution to the subject must be: who cares how many tables are used 'back there' ? :) -Ursprungligt meddelande----- Frn: Daniel Cardin [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Skickat: den 23 januari 2001 05:01 Till: Orion-Interest mne: RE: O/R mapping I'd like to point out that a third table is only needed for a N-M (many-to-many) relationship. In the case of a 1-N relationship, simply have a foreign key to the master table. For example : Customer object refers to a Country object you a Customer will only have one Country object. you do NOT need a third table to map this. Simply add a field in Customer that contains the foreign key to the Country object. The EJB 2.0 mapping is Simple Customer ... public abstract Country getCountry(); public abstract void setCountry(Country aCountry); and in Country public abstract Collection getCustomers(); public abstract void setCustomer(Collection customers); This is fully supported by Orion, which will populate the collection object automatically. Cheers, Daniel -Message d'origine- De : Tony J Brooks [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Envoy : 22 janvier, 2001 11:27 : Orion-Interest Objet : RE: O/R mapping Hi Theis, As much as I can remember, there *is* - definitely - a need for an intermediate third table to contain the mapping information. By using this third table, you eliminate data replication/redundancy in the other two tables. To my knowledge this is a common technique. ER tools typically create such an intermediate table for you when you select a relationship to be 'zero/one/many to many'. Whether you see that on your diagram is another matter, but you will definitely see it in your DB ;) Apologies if I have misunderstood your question. Bye for now, Tony. -Original Message- From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ]On Behalf Of [EMAIL PROTECTED] Sent: 22 January 2001 15:10 To: Orion-Interest Subject: O/R mapping Hi! I have been reading the complex-or example and ploughed through the atm example. In the complex-or example it is stated that collections are mapped to an another table and that the reason for this is normalization. The Atm example is also following this principle. Is this really correct? I have never seen the necessity for mapping anone to many relation to a third table (even though it was a long time ago I read the rules of normalization I'm very doubtful that this is correct). Could someone tell me the rational behind this. If this not true, how does the xml look like (in the orion-ejb-jar.xml) when you only map the relation as a foreign key? Regards /Theis
