RE: EJB Help..
Jim, How could a CMP managed entity bean handle a create for say an Oracle database table that used db specific sql for describing the key using a sequence? Where the sql itself might look like insert into customer (id, name, address) values(cust_sequence.NEXTVAL, "Jim" "12 Willow Street"); Maybe this is trivial. Better yet could I ask you to provide some of the sources of information that you use to help all of us better understand how to do CMP with perhaps complex RDBMS entity relationships? Thanks, Cory At 09:07 PM 10/20/00 -0400, Jim Archer wrote: What types of relationships do you feel EJB 2.0 can't adequately support? I have been studying 2.0 CMP carefully, and it seems to be quite powerfull. There may be holes in it, but it can handle the majority of real works cases. Jim --On Friday, October 20, 2000 12:28 PM -0700 [EMAIL PROTECTED] wrote: If you don't use an object-relational mapping tool you're still in for a lot of hurt with EJB if you have a complex data model. I don't think CMP really addresses the kind of data models large systems have. Nor does the relationship support in EJB 2.0 either. I think you'll end up doing JDBC BMP with your Session and Entity beans. Performance is only an issue when you make everything a stateful session bean or an entity bean. There are rules for when it's appropriate to make things entity beans. There still isn't a whole lot of useful information around on design EJBs yet though with most of it only explaining the basics including the ORA book. On Fri, 20 Oct 2000, Duffey, Kevin wrote: Thanks. I only meant to use the /classes folder because my ejb code is in the same project as the rest of my code (Servlets, javabeans, action classes, etc). Since it all compiles to the same one folder, I assume I will have to "move" the ejb compiled classes every time I compile them. What I was hoping for was a way to not have to do this..instead, just let the whole project compile to the WEB-INF/classes folder (all my code), and then have Orion pick up on the ejb changes from that point. It appears to me from what everyone is saying I will have to use some sort of script every time I make a change to an ejb, which my first thoughts is a pain in the ass. Its very easy to develop servlets, action classes, javabeans, core classes, but ejb not only requires 3 classes per component, but lots of "special" work just to get the thing deployed. Then, every time you make a change, it requires the same process. I would think turn-around time for ejb development is on the order of a couple of minutes for every change you make. That results in a lot slower development cycle than I am currently using. Worse, I have started hearing alot of people turn away from ejb and going back to servlets because of development time, and performance. Supposedly the ejb stuff isn't living up to all the hype. However, I look at what the ejb container does for you (connection pooling, transactions, security, instance pooling, etc) and it seems there is alot of stuff I wont have to do on the side of persistence, transactions and security..so maybe the extra time is worth it? ;) Anyways..I did as one person suggested in this list, I set up in my application.xml like so: module ejb/path/www/WEB-INF/classes//ejb /module and Orion seems to be finding the classes (the ejb). However, I keep seeing an error appear. It says something like: Error compiling class c:/path/www/WEB-INF/classes/ Login.java LoginBean.java LoginHome.java can't find method create()in LoginBean.java Its a very strange message to me. If I change the module path, it tells me it can't find the classes. If I delete the classes, it also tells me it can't find them. So I assume the path is set correctly in the module ejb tag..as it is finding the classes. I am just not sure why the heck its giving me some compiler error..or why its even trying to compile them..they are already compiled. Anyways..I'll keep plugging away. -Original Message- From: Stanislav Maximov [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 19, 2000 6:34 PM To: Orion-Interest Subject: RE: EJB Help.. Kevin, look inside the news-application example bundled with Orion, lots of things will become clear for you after that. www-dir/WEB-INF/classes directory is for servlet classes, not for EJBs. You'll see how to deploy EJBs in that example and in documentation as well. stas@ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin Sent: Friday, October 20, 2000 3:45 AM To: Orion-Interest Subject: RE: EJB Help.. Thanks for the note. One thing..since I compile all of my classes into the www/WEB-INF/classes dir, should I put a META-INF in the /classes dir, and just point the module to the WEB-INF/classes folder? Would that work? Not that I want you to tell me
RE: RE: JSP char code
I found it myself. Just add default-charset="gb2312" to the orion-web.xml file. Hou Yunfeng __ ==ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn ÐÂÀËÍƳö°ÂÔ˶ÌÐÅÏ¢ÊÖ»úµã²¥·þÎñ http://sms.sina.com.cn/
Re: Orion in production - Let's sell support!
Hello Jim, Couldn't agree more on the business plans. We are looking for partners to do support for money, if you're interested and your company has Orion knowledge, we'd be very happy to help you "officially" to get customers. However, you say that you have not bought a license yet and that means you have not yet bought any support from us. If you are serious in choosing Orion I think it can actually save you money to get a license when developing (even if you can get free developer licenses), since it will mean you get better support from us. However, the support you get for $1500 is, needless to say, limited. We can't put 100 hours into giving you support at that price and still have money left to develop the product. So we are going to provide more generous support at a higher price, both ourselves and through partners. We are speaking with multiple possible partners about outsourcing support and selling support packages and if you are interested or know someone who is interested in selling support and make decent money from it, feel free to contact us. Regards, Karl Avedal Jim Archer wrote: Hello all... --On Friday, October 20, 2000 5:35 PM -0300 "Juan Lorandi (Chile)" [EMAIL PROTECTED] wrote: And also, lack of support documentation is becoming now, as most developers are finishing their work and reach deployment time(from what I pick up of many mails in this list), a critical point about orion. Many of us are reaching the point where we have to prove no only that orion's the best, but that it also is a good business choice. This is unfairly hard due to little colaboration from Evermind's team regarding, as said, support documentation, tough it clearly seems to be changing. This is a key issue. There is an old saying that time is money. Not true in software. Time is far more valuable than money. Money can be raised but time can not. Orion is reasonably priced for the product itself. However, if using Orion means a lot of trial and error development and no official support from the vendor, the costs in extra consumption of developers time and oppertunity loss from delayed market entry could easily exceed the price tag of Weblogic. Don't get me wrong, I like Orion. I like it alot. Currently, our intention is to complete development on it and then license it and deploy with it and hopefully sell it with our product. This goal would be one heck of a lot easier to obtain if we had official support from the vendor. Right now, there are people here banging their heads on the wall just trying to guess at what works and what dossen't, whats implemented and whats not. It's tireing. Anybody want to help me start a business selling Orion support on a 900 number? Just charge several dollars a minute, on an incident by incident basis. If the support is competant, it would sell big. Heck, we could make more money then Evermind! Big Grin OK, just kidding, but this is a serious issue. Jim
RE: Orion in production
Biggest problems with Orion, as I see them: lack of US support base and representation (many companies don't like to write foreign purchase orders, and local training is an issue even though Orion supports standards better than its competitors), and documentation, with documentation being a MUCH smaller issue than communication with local support. On Fri, 20 Oct 2000, Juan Lorandi (Chile) wrote: I completly agree with your posts, but I beg I'm allowed to differ in one thing... Big Companies don't make enterprises like Evermind or BEA Systems rich... directly... But these BIG names make for BIG hype... as you're well aware of; That's why your boss thinks Weblogic is the way to go... That's why I have requested data to make the OPS list... And also, lack of support documentation is becoming now, as most developers are finishing their work and reach deployment time(from what I pick up of many mails in this list), a critical point about orion. Many of us are reaching the point where we have to prove no only that orion's the best, but that it also is a good business choice. This is unfairly hard due to little colaboration from Evermind's team regarding, as said, support documentation, tough it clearly seems to be changing. Perhaps its time for a change(and I hope it's a change that will keep my sorry a~s working with Orion ;-) JP -Original Message- From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] Sent: Viernes, 20 de Octubre de 2000 16:27 To: Orion-Interest Subject: RE: Orion in production Importance: High I would like to ammend my previous post. I don't actually know if Orion has marketing/publicity, and I am not in a position to say they are just starting out. I apologize if I spoke with my head up my rear..I believe my intention was to hype up Orion for all the hard work the team has done to give us a great product, not to make it sound like they are a small company. My point being, I had a very difficult time getting my boss to go with Orion over WebLogic, and even so he still wants to use WebLogic, we just don't want to spend the money right now. Alot of companies for some reason feel the name is bigger than the actual work behind it. It sucks..but that appears to be the way alot of business run. When you have a VC give you $72 million as we have received in the past year, its hard to use a product nobody is familiar with, over one that is touted the best, even if the price costs 10 to 20 times more. I of all people have had a hard time trying to understand why our company would want to waste so much money on a proudct that isn't even on par with the standards (as they claim to be) as Orion is. Anyways..Just wanted to clear that up incase I got some people thinking Orion is small. In actuality, they are big, and they will get bigger! -Original Message- From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] Sent: Friday, October 20, 2000 12:05 PM To: Orion-Interest Subject: RE: Orion in production I would say..Orion has almost no publicity other than word of mouth right now. Orion is just starting out compared to WebLogic, IIS, and what not. Give them some time..people are reluctant to turn to a small company with such a cheap price. I hate to say it, and I hope they don't change their price, but believe it or not, if Orion raised its license price to say $10,000 per server (hopefully not cpu), they might actually get more interest. I think there is still a lot of testing and what not to do before they should do that, if they even want to. Quite frankly, I like what they are doing. They offer a kick-ass server for a affordable price..very good for small to medium sized companies to use. There are a LOT more small to medium sized companies than big companies, so even if they are 1/10th the price (or 1/40th if you compare 4 cpu servers), I would be that the Orion team will see a lot of sales in the small/medium market, which could actually give them alot more money in the bank. On top of that, I don't know how many people Orion employs, but I know WebLogic is over 1500 people, large facility, etc. WebLogic spends a hell of a lot more on salaries, travel expenses, marketing, etc. In my opinion..maybe its just me, but I trust Orion or Apache over the big names. Plus..as I said, I can't start up my own company using WebLogic. I can with Orion. Better yet, Orion has thus far beat the hell out of every major (and as far as I can tell..every small) vendor of app servers (J2EE supporters I should say) as far as staying ahead of the ballgame, offering great performance, the best J2EE support, and the easiest to set up. I played around with WebLogic for two weeks (on and off) and still couldn't get my simple JSP page to show up. WebSphere was a nightmare, and while Resin was easy to work with, its not a full J2EE app
RE: Orion in production
At 07:46 21.10.00 , you wrote: I think that Orion far outshines products like EA Server, Web Sphere, etc because of the functionality available - and you are right - the docs are just a little more pretty and their tech support is absurdly costly and much less informative than what is found on this list. snip/ ok, sorry to somehow take the part of mr. bad guy here but I get the feeling someone following this discussion IMHO doesn't really get the right impression. it's a little bit too black and white. first of all, let me say that after about a year of intensively using orion in development and half a year in production, I'm a generally very satisfied customer and I do appreciate the completeness, standards conformance, speed, great logical concept of orion. however, I think it's oversimplifying things to say it's just marketing that makes the big names so expensive (it's a significant factor, though) and it's not a very good assessment to say that orion beat all competitors' asses if it weren't for the lack of good documentation. there are some significant things that are a lot of work and therefore very expensive like QA and rigid testing with many, many hardware, software, db, vm combinations that a company the size of evermind simply cannot deliver (have you looked at the number of platforms you can get websphere for?). anyone who says that write once run anywhere really works 100% probably hasn't been involved in too many real-world projects where certain combinations of VMs and software just crash under certain load conditions. that's why e.g. weblogic is tested and certified for a particular platform. of course, part of this certification stuff is to keep the typical IT manager happy but to say it's all bullshit is off-target and not very professional IMO. when orion became officially stable (1.0) it still contained many very serious bugs and I presume it wouldn't have been 1.0 time if it hadn't been for J1. the flexibility and development speed of the orion team takes it's toll in the number of fundamental bugs in those very features. with a few exceptions I doubt many of those would slip through bea or ibm QA. I sometimes think it feels like an open source project but without the source. a very loyal user community and very short release cycles but still lots of rough edges. don't get me wrong. I'm a great fan of orion and I think for many projects it's an unbeatable tool with no serious competitors especially considering the price and I think magnus and karl are extremely good software architects and true J2EE wizards but I think there are some more things one has to consider before making the kind of statements that have been made in this thread. at my company we share the experiences with a very efficent development environment using orion together with jikes and ant but we also had our share of spending considerable amounts of time working around serious bugs or waiting for fixes for showstoppers. to sum things up, IMO orion is a great deal and it completely meets (and exceeds) the requirements many people have for an appserver but it does have its rough edges (and that's not primarily the documentation IMO). I'm quite sure that those will fade away eventually but evermind still has some work to do in the areas QA, support and documentation. let's just hope they don't get bought out and manage to grow quickly yet in a controlled manner so they can continue developing a kick-ass server. just my 2c robert (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
Re: Orion in production
I have to agree with Robert. (with the same caveat, I think Orion is a great product We even recommended it to some clients who wanted a J2EE solution without the cost of BEA or Netscape) There are some things that right now I don't feel comfortable with in it though. Clustering... Clustering is just downright a pain in Orion :) I would love to see something like IPlanet 6's control panel to control clustering and failover. Deployment... Deployment is not terribly difficult if you know what you are doing, but my last project had us using IPlanet 6 and I had developers who had never deployed J2EE apps able to deploy them easily using their deployment tool. It took minimal training for the front end guys to get them trained to use it, and deploy the application without having to come to me for help. That would be nice and is a step closer with the console now in Orion. Pricing is very nice, but believe it or not we have had clients bow out of Orion based on it being too inexpensive. I know that is terrible, but for some reason some clients seem to equate big bucks with maturity and reliability. You wont find me complaining though, heck where else is there a free for development commercial server? Al - Original Message - From: "Robert Krueger" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Saturday, October 21, 2000 3:19 PM Subject: RE: Orion in production At 07:46 21.10.00 , you wrote: I think that Orion far outshines products like EA Server, Web Sphere, etc because of the functionality available - and you are right - the docs are just a little more pretty and their tech support is absurdly costly and much less informative than what is found on this list. snip/ ok, sorry to somehow take the part of mr. bad guy here but I get the feeling someone following this discussion IMHO doesn't really get the right impression. it's a little bit too black and white. first of all, let me say that after about a year of intensively using orion in development and half a year in production, I'm a generally very satisfied customer and I do appreciate the completeness, standards conformance, speed, great logical concept of orion. however, I think it's oversimplifying things to say it's just marketing that makes the big names so expensive (it's a significant factor, though) and it's not a very good assessment to say that orion beat all competitors' asses if it weren't for the lack of good documentation. there are some significant things that are a lot of work and therefore very expensive like QA and rigid testing with many, many hardware, software, db, vm combinations that a company the size of evermind simply cannot deliver (have you looked at the number of platforms you can get websphere for?). anyone who says that write once run anywhere really works 100% probably hasn't been involved in too many real-world projects where certain combinations of VMs and software just crash under certain load conditions. that's why e.g. weblogic is tested and certified for a particular platform. of course, part of this certification stuff is to keep the typical IT manager happy but to say it's all bullshit is off-target and not very professional IMO. when orion became officially stable (1.0) it still contained many very serious bugs and I presume it wouldn't have been 1.0 time if it hadn't been for J1. the flexibility and development speed of the orion team takes it's toll in the number of fundamental bugs in those very features. with a few exceptions I doubt many of those would slip through bea or ibm QA. I sometimes think it feels like an open source project but without the source. a very loyal user community and very short release cycles but still lots of rough edges. don't get me wrong. I'm a great fan of orion and I think for many projects it's an unbeatable tool with no serious competitors especially considering the price and I think magnus and karl are extremely good software architects and true J2EE wizards but I think there are some more things one has to consider before making the kind of statements that have been made in this thread. at my company we share the experiences with a very efficent development environment using orion together with jikes and ant but we also had our share of spending considerable amounts of time working around serious bugs or waiting for fixes for showstoppers. to sum things up, IMO orion is a great deal and it completely meets (and exceeds) the requirements many people have for an appserver but it does have its rough edges (and that's not primarily the documentation IMO). I'm quite sure that those will fade away eventually but evermind still has some work to do in the areas QA, support and documentation. let's just hope they don't get bought out and manage to grow quickly yet in a controlled manner so they can continue developing a kick-ass server. just my 2c robert (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-)
RE: ANSWER: How to use pooled connections in Orion?
Deepak et al:
I'm confused about how Orion populates the JNDI server with the
DataSource object. Obviously for the code fragment you posted to work,
an object "jdbc/SQLServerDS" has to exist in your directory server. How
does it get there?
I would have guessed that admin.jar -installDataSource was the answer,
but I find no switch there which would tell Orion how to find the
directory server.
Many thanks for your posts, they're very helpful!
--Mark
===
Hi,
The way you access the datasource is dependent on where will you access
the
datasource from. I'm currently accessing the datasource from a servlet
which
is pretty straightforward:
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource)ctx.lookup("jdbc/SQLServerDS");
The above method might not be portable but it works for me so I mention
it.
Note that you don't need any special Orion datasource name. DataSource
is
defined in javax.sql.*
The portable way which require more work is to add the following to your
web.xml if you access the datasource from servlets and/or JSP:
context-param
param-namemyDS/param-name
param-valuejdbc/SQLServerDS/param-value
/context-param
resource-ref
descriptionA data source/description
res-ref-namemyDS/res-ref-name
res-typejavax.sql.DataSource/res-type
res-authCONTAINER/res-auth
/resource-ref
Now, you can access the datasource by:
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource)ctx.lookup("java:comp/env/myDS");
--Deepak
-Original Message-
From: Luis M Bernardo [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 12, 2000 7:39 AM
To: Goel, Deepak
Subject: Re: ANSWER: How to use pooled connections in Orion?
hi. thanks for posting this message, but could you show me how you make
the connection (a code snippet)? Looking at old postings I see some
people
using a DataSource and some others a ConnectionPoolDataSource. Also, you
use a DriverManagerDataSource, some other people use a
ConnectionDataSource.
cheers,
luis
On Sat, 7 Oct 2000, Goel, Deepak wrote:
Hello everyone,
I've seen that many people are confused over how to setup pooled
connections
in Orion (even I was initially). Now since I figured out through
documentation and through some hit and try, I would like to share
these
instructions. Keep in mind that this is only one way of setting it up
and
there are other ways to setup depending on capabilities of the driver.
1. Basically, the first step is to create a non-pooled version of your
data
source. This can be done by adding something like this to your
data-sources.xml:
data-source
class="com.evermind.sql.DriverManagerDataSource"
name="SQLServerNP"
location="jdbc/SQLServerNP"
xa-location="jdbc/xa/SQLServerXANP"
ejb-location="jdbc/SQLServerNP"
connection-driver="com.inet.tds.TdsDriver"
username="user"
password="pwd"
url="jdbc:inetdae:localhost"
inactivity-timeout="30"
schema="database-schemas\ms-sql.xml"
/
The above example is for a SQL Server data source using i-net driver.
Remeber to change the connection-driver, username, password and url.
2. Now, the following step will add the pooled version. Add the
following
lines to data-sources.xml.
data-source
class="com.evermind.sql.OrionPooledDataSource"
name="SQLServer"
location="jdbc/SQLServerDS"
xa-location="jdbc/xa/SQLServerXADS"
ejb-location="jdbc/SQLServerDS"
max-connections="4"
source-location="jdbc/SQLServerNP"
pooled-location="jdbc/SQLServerDS"
inactivity-timeout="30"
connection-driver="com.inet.tds.TdsDriver"
url="jdbc:inetdae:localhost"
/
Note that the source-location should correspond to location in the 1st
step.
"max-connections" can be changed to suit your requirements. I'm not
sure
whether url and connection-driver are required here.
The above steps should work for any JDBC drivers. If your driver
vendor
supplies a data source, step 1 will be little bit different. Also,
some of
the driver vendors directly provide pooled data source implementation
in
which case 2 steps are not needed. I could successfully use i-net OPTA
PooledDataSource with Orion.
--Deepak
RE: Orion in production
Robert, I agree with some of your points, and I have a 'semi' solution that I've told Magnus about before. The autoupdate tool is brilliant, but too addictive. Sometimes I've updated to get fixes for bugs, only to get another version with a different annoying bug. If it had the option to autoupdate to the latest 'stable' version, or the latest 'rough edged' version, it would be perfect. eg java -jar autoupdate.jar -version=stable / development Oh, and to Al who says he can't see Orion because it's too inexpensive? Just tell the client it's $10k, bill 'em $10k and they'll love you for it - oh, and either pocket the $8.5k or donate it to the Orion guys, I'm sure they wouldn't knock you back ;) Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Krueger Sent: Sunday, October 22, 2000 5:19 AM To: Orion-Interest Subject: RE: Orion in production At 07:46 21.10.00 , you wrote: I think that Orion far outshines products like EA Server, Web Sphere, etc because of the functionality available - and you are right - the docs are just a little more pretty and their tech support is absurdly costly and much less informative than what is found on this list. snip/ ok, sorry to somehow take the part of mr. bad guy here but I get the feeling someone following this discussion IMHO doesn't really get the right impression. it's a little bit too black and white. first of all, let me say that after about a year of intensively using orion in development and half a year in production, I'm a generally very satisfied customer and I do appreciate the completeness, standards conformance, speed, great logical concept of orion. however, I think it's oversimplifying things to say it's just marketing that makes the big names so expensive (it's a significant factor, though) and it's not a very good assessment to say that orion beat all competitors' asses if it weren't for the lack of good documentation. there are some significant things that are a lot of work and therefore very expensive like QA and rigid testing with many, many hardware, software, db, vm combinations that a company the size of evermind simply cannot deliver (have you looked at the number of platforms you can get websphere for?). anyone who says that write once run anywhere really works 100% probably hasn't been involved in too many real-world projects where certain combinations of VMs and software just crash under certain load conditions. that's why e.g. weblogic is tested and certified for a particular platform. of course, part of this certification stuff is to keep the typical IT manager happy but to say it's all bullshit is off-target and not very professional IMO. when orion became officially stable (1.0) it still contained many very serious bugs and I presume it wouldn't have been 1.0 time if it hadn't been for J1. the flexibility and development speed of the orion team takes it's toll in the number of fundamental bugs in those very features. with a few exceptions I doubt many of those would slip through bea or ibm QA. I sometimes think it feels like an open source project but without the source. a very loyal user community and very short release cycles but still lots of rough edges. don't get me wrong. I'm a great fan of orion and I think for many projects it's an unbeatable tool with no serious competitors especially considering the price and I think magnus and karl are extremely good software architects and true J2EE wizards but I think there are some more things one has to consider before making the kind of statements that have been made in this thread. at my company we share the experiences with a very efficent development environment using orion together with jikes and ant but we also had our share of spending considerable amounts of time working around serious bugs or waiting for fixes for showstoppers. to sum things up, IMO orion is a great deal and it completely meets (and exceeds) the requirements many people have for an appserver but it does have its rough edges (and that's not primarily the documentation IMO). I'm quite sure that those will fade away eventually but evermind still has some work to do in the areas QA, support and documentation. let's just hope they don't get bought out and manage to grow quickly yet in a controlled manner so they can continue developing a kick-ass server. just my 2c robert (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
Re: Orion in production
lol. What a concept. But we would have to charge 20 or 30 K... of course :) Hey *I* see it, our clients seem to equate inexpensive with "not ready for prime time" Al - Original Message - From: "Mike Cannon-Brookes" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Saturday, October 21, 2000 10:09 PM Subject: RE: Orion in production Robert, I agree with some of your points, and I have a 'semi' solution that I've told Magnus about before. The autoupdate tool is brilliant, but too addictive. Sometimes I've updated to get fixes for bugs, only to get another version with a different annoying bug. If it had the option to autoupdate to the latest 'stable' version, or the latest 'rough edged' version, it would be perfect. eg java -jar autoupdate.jar -version=stable / development Oh, and to Al who says he can't see Orion because it's too inexpensive? Just tell the client it's $10k, bill 'em $10k and they'll love you for it - oh, and either pocket the $8.5k or donate it to the Orion guys, I'm sure they wouldn't knock you back ;) Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Krueger Sent: Sunday, October 22, 2000 5:19 AM To: Orion-Interest Subject: RE: Orion in production At 07:46 21.10.00 , you wrote: I think that Orion far outshines products like EA Server, Web Sphere, etc because of the functionality available - and you are right - the docs are just a little more pretty and their tech support is absurdly costly and much less informative than what is found on this list. snip/ ok, sorry to somehow take the part of mr. bad guy here but I get the feeling someone following this discussion IMHO doesn't really get the right impression. it's a little bit too black and white. first of all, let me say that after about a year of intensively using orion in development and half a year in production, I'm a generally very satisfied customer and I do appreciate the completeness, standards conformance, speed, great logical concept of orion. however, I think it's oversimplifying things to say it's just marketing that makes the big names so expensive (it's a significant factor, though) and it's not a very good assessment to say that orion beat all competitors' asses if it weren't for the lack of good documentation. there are some significant things that are a lot of work and therefore very expensive like QA and rigid testing with many, many hardware, software, db, vm combinations that a company the size of evermind simply cannot deliver (have you looked at the number of platforms you can get websphere for?). anyone who says that write once run anywhere really works 100% probably hasn't been involved in too many real-world projects where certain combinations of VMs and software just crash under certain load conditions. that's why e.g. weblogic is tested and certified for a particular platform. of course, part of this certification stuff is to keep the typical IT manager happy but to say it's all bullshit is off-target and not very professional IMO. when orion became officially stable (1.0) it still contained many very serious bugs and I presume it wouldn't have been 1.0 time if it hadn't been for J1. the flexibility and development speed of the orion team takes it's toll in the number of fundamental bugs in those very features. with a few exceptions I doubt many of those would slip through bea or ibm QA. I sometimes think it feels like an open source project but without the source. a very loyal user community and very short release cycles but still lots of rough edges. don't get me wrong. I'm a great fan of orion and I think for many projects it's an unbeatable tool with no serious competitors especially considering the price and I think magnus and karl are extremely good software architects and true J2EE wizards but I think there are some more things one has to consider before making the kind of statements that have been made in this thread. at my company we share the experiences with a very efficent development environment using orion together with jikes and ant but we also had our share of spending considerable amounts of time working around serious bugs or waiting for fixes for showstoppers. to sum things up, IMO orion is a great deal and it completely meets (and exceeds) the requirements many people have for an appserver but it does have its rough edges (and that's not primarily the documentation IMO). I'm quite sure that those will fade away eventually but evermind still has some work to do in the areas QA, support and documentation. let's just hope they don't get bought out and manage to grow quickly yet in a controlled manner so they can continue developing a kick-ass server. just my 2c robert (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151
Re: ANSWER: How to use pooled connections in Orion?
Orion will bind the Datasource to the JNDI environment for you, you set this
up in the data-sources.xml file. for instance for my Oracle instance the
file is ... defined in data-sources.xml like so
?xml version="1.0"?
!DOCTYPE data-sources PUBLIC "Orion data-sources"
"http://www.orionserver.com/dtds/data-sources.dtd"
data-sources
!--
An example/default DataSource that uses an ordinary
JDBC-driver (in this case hsql) to create the connections.
This tag creates all the needed kinds
of data-sources, transactional, pooled and EJB-aware sources.
The source generally used in application code is the "EJB"
one - it provides transactional safety and connection pooling.
--
data-source
class="com.evermind.sql.DriverManagerDataSource"
name="Oracle"
location="jdbc/RedbookDS"
xa-location="jdbc/xa/RedbookXADS"
ejb-location="jdbc/RedbookDS"
connection-driver="oracle.jdbc.driver.OracleDriver"
username=""
password=""
url="jdbc:oracle:thin:@enterprise:1521:G2K_DEV"
inactivity-timeout="30"
/
/data-sources
this will bind my DataSource to "java:comp/env/jdbc/RedbookDS"
Al
- Original Message -
From: "Mark" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Saturday, October 21, 2000 8:01 PM
Subject: RE: ANSWER: How to use pooled connections in Orion?
Deepak et al:
I'm confused about how Orion populates the JNDI server with the
DataSource object. Obviously for the code fragment you posted to work,
an object "jdbc/SQLServerDS" has to exist in your directory server. How
does it get there?
I would have guessed that admin.jar -installDataSource was the answer,
but I find no switch there which would tell Orion how to find the
directory server.
Many thanks for your posts, they're very helpful!
--Mark
===
Hi,
The way you access the datasource is dependent on where will you access
the
datasource from. I'm currently accessing the datasource from a servlet
which
is pretty straightforward:
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource)ctx.lookup("jdbc/SQLServerDS");
The above method might not be portable but it works for me so I mention
it.
Note that you don't need any special Orion datasource name. DataSource
is
defined in javax.sql.*
The portable way which require more work is to add the following to your
web.xml if you access the datasource from servlets and/or JSP:
context-param
param-namemyDS/param-name
param-valuejdbc/SQLServerDS/param-value
/context-param
resource-ref
descriptionA data source/description
res-ref-namemyDS/res-ref-name
res-typejavax.sql.DataSource/res-type
res-authCONTAINER/res-auth
/resource-ref
Now, you can access the datasource by:
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource)ctx.lookup("java:comp/env/myDS");
--Deepak
-Original Message-
From: Luis M Bernardo [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 12, 2000 7:39 AM
To: Goel, Deepak
Subject: Re: ANSWER: How to use pooled connections in Orion?
hi. thanks for posting this message, but could you show me how you make
the connection (a code snippet)? Looking at old postings I see some
people
using a DataSource and some others a ConnectionPoolDataSource. Also, you
use a DriverManagerDataSource, some other people use a
ConnectionDataSource.
cheers,
luis
On Sat, 7 Oct 2000, Goel, Deepak wrote:
Hello everyone,
I've seen that many people are confused over how to setup pooled
connections
in Orion (even I was initially). Now since I figured out through
documentation and through some hit and try, I would like to share
these
instructions. Keep in mind that this is only one way of setting it up
and
there are other ways to setup depending on capabilities of the driver.
1. Basically, the first step is to create a non-pooled version of your
data
source. This can be done by adding something like this to your
data-sources.xml:
data-source
class="com.evermind.sql.DriverManagerDataSource"
name="SQLServerNP"
location="jdbc/SQLServerNP"
xa-location="jdbc/xa/SQLServerXANP"
ejb-location="jdbc/SQLServerNP"
connection-driver="com.inet.tds.TdsDriver"
username="user"
password="pwd"
url="jdbc:inetdae:localhost"
inactivity-timeout="30"
schema="database-schemas\ms-sql.xml"
/
The above example is for a SQL Server data source using i-net driver.
Remeber to change the connection-driver, username, password and url.
2. Now, the following step will add the pooled version. Add the
following
lines to data-sources.xml.
data-source
class="com.evermind.sql.OrionPooledDataSource"
name="SQLServer"
location="jdbc/SQLServerDS"
xa-location="jdbc/xa/SQLServerXADS"
ejb-location="jdbc/SQLServerDS"
max-connections="4"
source-location="jdbc/SQLServerNP"
RE: Orion in production - autoupdate tool
This sounds fascinating - I'd love to know more about *ix permissions, securing Orion properly etc. You sound like you've got it all down pat, if you wouldn't mind, I'd love to learn more about your setup - as I'm sure other Orion users would. How about writing a quick how to doc about securing Orion on *ix? The OrionSupport team will love you for it ;) Mike -Original Message- From: Jim Archer [mailto:[EMAIL PROTECTED]] Sent: Sunday, October 22, 2000 1:18 PM To: Orion-Interest Cc: Mike Cannon-Brookes Subject: RE: Orion in production - autoupdate tool Actually, I'm not sure the auto-update tool is very usefull at all in production. For security reasons, we don't allow Orion write access to itself. If we configure our operating system to allow Orion to over write its own code files, we create a serious security hole. A hacker may discover an exploit in Orion that gets it to change its files and open a security hole. If Orion can't write to itself, this can't happen. Configuring an app like a web server to not have write access to itself is security measure number 1. Jim --On Sunday, October 22, 2000 12:09 PM +1000 Mike Cannon-Brookes [EMAIL PROTECTED] wrote: Robert, I agree with some of your points, and I have a 'semi' solution that I've told Magnus about before. The autoupdate tool is brilliant, but too addictive. Sometimes I've updated to get fixes for bugs, only to get another version with a different annoying bug. If it had the option to autoupdate to the latest 'stable' version, or the latest 'rough edged' version, it would be perfect. eg java -jar autoupdate.jar -version=stable / development Oh, and to Al who says he can't see Orion because it's too inexpensive? Just tell the client it's $10k, bill 'em $10k and they'll love you for it - oh, and either pocket the $8.5k or donate it to the Orion guys, I'm sure they wouldn't knock you back ;) Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Krueger Sent: Sunday, October 22, 2000 5:19 AM To: Orion-Interest Subject: RE: Orion in production At 07:46 21.10.00 , you wrote: I think that Orion far outshines products like EA Server, Web Sphere, etc because of the functionality available - and you are right - the docs are just a little more pretty and their tech support is absurdly costly and much less informative than what is found on this list. snip/ ok, sorry to somehow take the part of mr. bad guy here but I get the feeling someone following this discussion IMHO doesn't really get the right impression. it's a little bit too black and white. first of all, let me say that after about a year of intensively using orion in development and half a year in production, I'm a generally very satisfied customer and I do appreciate the completeness, standards conformance, speed, great logical concept of orion. however, I think it's oversimplifying things to say it's just marketing that makes the big names so expensive (it's a significant factor, though) and it's not a very good assessment to say that orion beat all competitors' asses if it weren't for the lack of good documentation. there are some significant things that are a lot of work and therefore very expensive like QA and rigid testing with many, many hardware, software, db, vm combinations that a company the size of evermind simply cannot deliver (have you looked at the number of platforms you can get websphere for?). anyone who says that write once run anywhere really works 100% probably hasn't been involved in too many real-world projects where certain combinations of VMs and software just crash under certain load conditions. that's why e.g. weblogic is tested and certified for a particular platform. of course, part of this certification stuff is to keep the typical IT manager happy but to say it's all bullshit is off-target and not very professional IMO. when orion became officially stable (1.0) it still contained many very serious bugs and I presume it wouldn't have been 1.0 time if it hadn't been for J1. the flexibility and development speed of the orion team takes it's toll in the number of fundamental bugs in those very features. with a few exceptions I doubt many of those would slip through bea or ibm QA. I sometimes think it feels like an open source project but without the source. a very loyal user community and very short release cycles but still lots of rough edges. don't get me wrong. I'm a great fan of orion and I think for many projects it's an unbeatable tool with no serious competitors especially considering the price and I think magnus and karl are extremely good software architects and true J2EE wizards but I think there are some more things one has to consider before making the kind of statements that have
EJB 2.0 Dependent Object problem - NPE on deploy
Hi All... After being told that Orion supports the PD1 spec for EJB 2.0 dependent objects I went through the PD1 spec carefully and compared it to the PD2 spec and changed my code accordingly. In fact, I have created a very stripped down example that fails. I also have looked carefully at the LogEntry class in the ATM example and its associated deployment descriptors and AccountEJB class. The best I can get Orion to do is throw a null pointer exception (pasted below) at deployment time. I have been trying a variety of things for many hours so far Friday and this weekend and still just the same, cryptic null pointer error. I have posted the code and deployment descriptors below. I realize the error is mine, since I can successfully deploy the ATM example. If someone could take a look and let me know what I screwed up, I would be greatly appreciative. This whole mess is pretty straightforward. In the PersonEJB class you'll see I used AddrDo for the varible name as in getAddrDo(), but I also tried to use a different name than the type, sich as getAddress(). If I remove the dependent object portions of this code and descriptor it works fine, except of course without the dependent. Also, there is a servlet and web descriptors and application descriptors I didn't post to save bandwidth. If thats needed I'll gladly post it. Thanks to everyone in advance. I'm sorry I'm asking so much, but the side of my head is bashed in from the brick wall. Jim C:\orionjava -jar orion.jar Auto-unpacking C:\Orion-test-apps\Test20CmpDo\rel\Sample20EbDo-ver001a.ear... do ne. Auto-unpacking C:\Orion-test-apps\Test20CmpDo\rel\Sample20EbDo-ver001a\Sample20E bDo-ver001a-web.war... done. Auto-deploying Sample20EbDo (Assembly had been updated)... Auto-deploying Sample20EbDo-ver001a-ejb.jar (ejb-jar.xml had been touched since the previous deployment)... java.lang.NullPointerException at com.evermind.server.ejb.deployment.ContainerManagedField.equals(JAX) at java.util.HashMap.put(Unknown Source) at java.util.HashSet.add(Unknown Source) at java.util.AbstractCollection.addAll(Unknown Source) at java.util.HashSet.init(Unknown Source) at com.evermind.server.ejb.deployment.Dependent.zk(JAX) at com.evermind.server.ejb.compilation.f4.init(JAX) at com.evermind.server.ejb.compilation.f9.ss(JAX) at com.evermind.server.ejb.EJBContainer.by(JAX) at com.evermind.server.Application.by(JAX) at com.evermind.server.Application.ge(JAX) at com.evermind.server.ApplicationServer.rn(JAX) at com.evermind.server.ApplicationServer.apr(JAX) at com.evermind.server.ApplicationServer.ge(JAX) at com.evermind.server.hf.run(JAX) at java.lang.Thread.run(Unknown Source) at com.evermind.util.f.run(JAX) ?xml version="1.0"? !DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_2_0.dtd" ejb-jar descriptionTest Sample EJB 2.0 EB/description display-namePerson/display-name enterprise-beans entity cmp-version2.0/cmp-version descriptionPerson has an address DO/description display-nameTest20CmpDo.eb.Person/display-name ejb-nameTest20CmpDo.eb.Person/ejb-name homeTest20CmpDo.eb.PersonHome/home remoteTest20CmpDo.eb.Person/remote ejb-classTest20CmpDo.eb.PersonEJB/ejb-class persistence-typeContainer/persistence-type prim-key-classjava.lang.String/prim-key-class reentrantTrue/reentrant !-- Same failure with without the next line -- cmp-fieldfield-nameaddrDo/field-name/cmp-field cmp-fieldfield-nameuserId/field-name/cmp-field cmp-fieldfield-namefirstName/field-name/cmp-field cmp-fieldfield-namelastName/field-name/cmp-field primkey-fielduserId/primkey-field /entity /enterprise-beans dependents dependent dependent-nameaddrDo/dependent-name dependent-classTest20CmpDo.eb.AddrDo/dependent-class cmp-fieldstreet/cmp-field cmp-fieldcity/cmp-field cmp-fieldstate/cmp-field cmp-fieldzip/cmp-field /dependent /dependents relationships ejb-relation ejb-relation-nameUser-Address/ejb-relation-name ejb-relationship-role ejb-relationship-role-nameUser-has-Address/ejb-relationship-role-name
RE: Orion in production - autoupdate tool
I would love to take credit, but one of the guys I work with is an expert in this field and he has been working on securing Orion on a Debian Linux server. I'll see if I can get him to write up a little doc on this, but unfortunatly we have not got it working properly yet. When we remove Orion's permission to write to itself, we find thst it is no longer able to make the JSP cache files when a JSP is run for the first time. This is odd, since we moved them and granted Orion permission to write to them, so this should not fail. We sent some questions off to Orion, but have not heard back yet. So for now, we are running it unsecure in test mode. We really can't deploy like that, so it is being worked on. When we figure out what the heck is going on, we'll do as you request, gladly. We have received a lot of help from this list and so we'll be happy to give back. However, I doid post a long note from my friend describing the some problems and solutions, except for that last one. I'll see if I can hunt it down and forward it to you. Jim Jim --On Sunday, October 22, 2000 2:28 PM +1000 Mike Cannon-Brookes [EMAIL PROTECTED] wrote: This sounds fascinating - I'd love to know more about *ix permissions, securing Orion properly etc. You sound like you've got it all down pat, if you wouldn't mind, I'd love to learn more about your setup - as I'm sure other Orion users would. How about writing a quick how to doc about securing Orion on *ix? The OrionSupport team will love you for it ;) Mike -Original Message- From: Jim Archer [mailto:[EMAIL PROTECTED]] Sent: Sunday, October 22, 2000 1:18 PM To: Orion-Interest Cc: Mike Cannon-Brookes Subject: RE: Orion in production - autoupdate tool Actually, I'm not sure the auto-update tool is very usefull at all in production. For security reasons, we don't allow Orion write access to itself. If we configure our operating system to allow Orion to over write its own code files, we create a serious security hole. A hacker may discover an exploit in Orion that gets it to change its files and open a security hole. If Orion can't write to itself, this can't happen. Configuring an app like a web server to not have write access to itself is security measure number 1. Jim --On Sunday, October 22, 2000 12:09 PM +1000 Mike Cannon-Brookes [EMAIL PROTECTED] wrote: Robert, I agree with some of your points, and I have a 'semi' solution that I've told Magnus about before. The autoupdate tool is brilliant, but too addictive. Sometimes I've updated to get fixes for bugs, only to get another version with a different annoying bug. If it had the option to autoupdate to the latest 'stable' version, or the latest 'rough edged' version, it would be perfect. eg java -jar autoupdate.jar -version=stable / development Oh, and to Al who says he can't see Orion because it's too inexpensive? Just tell the client it's $10k, bill 'em $10k and they'll love you for it - oh, and either pocket the $8.5k or donate it to the Orion guys, I'm sure they wouldn't knock you back ;) Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Krueger Sent: Sunday, October 22, 2000 5:19 AM To: Orion-Interest Subject: RE: Orion in production At 07:46 21.10.00 , you wrote: I think that Orion far outshines products like EA Server, Web Sphere, etc because of the functionality available - and you are right - the docs are just a little more pretty and their tech support is absurdly costly and much less informative than what is found on this list. snip/ ok, sorry to somehow take the part of mr. bad guy here but I get the feeling someone following this discussion IMHO doesn't really get the right impression. it's a little bit too black and white. first of all, let me say that after about a year of intensively using orion in development and half a year in production, I'm a generally very satisfied customer and I do appreciate the completeness, standards conformance, speed, great logical concept of orion. however, I think it's oversimplifying things to say it's just marketing that makes the big names so expensive (it's a significant factor, though) and it's not a very good assessment to say that orion beat all competitors' asses if it weren't for the lack of good documentation. there are some significant things that are a lot of work and therefore very expensive like QA and rigid testing with many, many hardware, software, db, vm combinations that a company the size of evermind simply cannot deliver (have you looked at the number of platforms you can get websphere for?). anyone who says that write once run anywhere really works 100% probably hasn't been involved in too many real-world projects where certain combinations of VMs and software just crash under certain load conditions.
RE: EJB Help..
Jim, Thanks for the reply. I have not looked over the 2.0 spec. in detail yet but I will. Are you mapping cmp entity beans to an existing db structure most of the time? Cory At 07:28 PM 10/21/00 -0400, you wrote: Hi Cory... I doubt we'll see anything thats database engine specific supported in CMP. I agree that sequences are extremely usefull and wish that there was a standard way on implementing them on database engines so that JDBC (and therefore J2EE) could take full advantage. PostgreSQL has a sequence and MS SQL Server has an identity field and so on. Unfortunatly, database vendors have no standard for implementing them. You can write code to generate a unique value for a primary key. You could code up a session bean that uses JDBC to create a new record in a table with no fields but the identity field. Of course, this bean would be database specific and it would be used by the non-database specific CMP entity beans. Orion makes a key generator available called counter.jar, which you can read about in the Orion FAQ (although I don't know what its licensing terms are - check this before you rely on it in your app). Setting aside the question of sequence types and primary key generation, I have not yet run into a RDBMS data structure I don't think I could replicate using EJB 2.0 CMP. Even if I did, I could isolate part with BMP or session beans and use CMP for the rest. I expect if I found something so strange 2.0 CMP could not handle it that I would try to redesign it so that it could be handled. I would probably end up with a better and simpler design. With EJB 2.0 CMP, I have a very good chance of getting my J2EE app to run on whatever database on whatever compliant server on whatever operating system. And, all the work it does for me is nice as well. Also, with EJB 2.0, its entirely possible to create a tool that would let you draw a UML diagram and generate almost the entire back end of an app - deployment descripters, code, maybe everything but the QL- automatically and then make changes a snap. There is no such tool now, but give some time. The best source of how to do CMP, unfortunatly, is still the spec. Anyhow, I thought EJB 1.1 was of limited utility. I think 2.0 is much, much better and can probably handle most systems. Just my opinion. Jim --On Saturday, October 21, 2000 3:11 AM -0400 Cory Adams [EMAIL PROTECTED] wrote: Jim, How could a CMP managed entity bean handle a create for say an Oracle database table that used db specific sql for describing the key using a sequence? Where the sql itself might look like insert into customer (id, name, address) values(cust_sequence.NEXTVAL, "Jim" "12 Willow Street"); Maybe this is trivial. Better yet could I ask you to provide some of the sources of information that you use to help all of us better understand how to do CMP with perhaps complex RDBMS entity relationships? Thanks, Cory At 09:07 PM 10/20/00 -0400, Jim Archer wrote: What types of relationships do you feel EJB 2.0 can't adequately support? I have been studying 2.0 CMP carefully, and it seems to be quite powerfull. There may be holes in it, but it can handle the majority of real works cases. Jim --On Friday, October 20, 2000 12:28 PM -0700 [EMAIL PROTECTED] wrote: If you don't use an object-relational mapping tool you're still in for a lot of hurt with EJB if you have a complex data model. I don't think CMP really addresses the kind of data models large systems have. Nor does the relationship support in EJB 2.0 either. I think you'll end up doing JDBC BMP with your Session and Entity beans. Performance is only an issue when you make everything a stateful session bean or an entity bean. There are rules for when it's appropriate to make things entity beans. There still isn't a whole lot of useful information around on design EJBs yet though with most of it only explaining the basics including the ORA book. On Fri, 20 Oct 2000, Duffey, Kevin wrote: Thanks. I only meant to use the /classes folder because my ejb code is in the same project as the rest of my code (Servlets, javabeans, action classes, etc). Since it all compiles to the same one folder, I assume I will have to "move" the ejb compiled classes every time I compile them. What I was hoping for was a way to not have to do this..instead, just let the whole project compile to the WEB-INF/classes folder (all my code), and then have Orion pick up on the ejb changes from that point. It appears to me from what everyone is saying I will have to use some sort of script every time I make a change to an ejb, which my first thoughts is a pain in the ass. Its very easy to develop servlets, action classes, javabeans, core classes, but ejb not only requires 3 classes per component, but lots of "special" work just to get the thing deployed. Then, every time you make a change, it requires the same process. I would think turn-around time for
RE: EJB 2.0 Dependent Object problem - NPE on deploy
I noticed that you're missing the abstract-schema-name element in the entity block. That might not be your problem, though; when I comment mine out I can still successfully deploy my solution. If adding abstract-schema-name does nothing, I'll look again. I haven't been using dependent objects because I couldn't figure out from the spec how to use a compound primary key defined by two CMR fields. The spec (in italics at the bottom of pg 121 of pd2) says this is possible, but I can't quite seem to figure out how it should work. Has anyone done this? Section 9.4.4.1 (at the end of pg 118) is confusing. It says that the primary key must be set by the end of ejbCreate(), but that CMR fields must not be modified until ejbPostCreate(). If a CMR field is the primary key, we seem to have a catch-22 problem... Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: Jim Archer [mailto:[EMAIL PROTECTED]] Sent: Saturday, October 21, 2000 9:14 PM To: Orion-Interest Subject: EJB 2.0 Dependent Object problem - NPE on deploy Hi All... After being told that Orion supports the PD1 spec for EJB 2.0 dependent objects I went through the PD1 spec carefully and compared it to the PD2 spec and changed my code accordingly. In fact, I have created a very stripped down example that fails. I also have looked carefully at the LogEntry class in the ATM example and its associated deployment descriptors and AccountEJB class. The best I can get Orion to do is throw a null pointer exception (pasted below) at deployment time. I have been trying a variety of things for many hours so far Friday and this weekend and still just the same, cryptic null pointer error. I have posted the code and deployment descriptors below. I realize the error is mine, since I can successfully deploy the ATM example. If someone could take a look and let me know what I screwed up, I would be greatly appreciative. This whole mess is pretty straightforward. In the PersonEJB class you'll see I used AddrDo for the varible name as in getAddrDo(), but I also tried to use a different name than the type, sich as getAddress(). If I remove the dependent object portions of this code and descriptor it works fine, except of course without the dependent. Also, there is a servlet and web descriptors and application descriptors I didn't post to save bandwidth. If thats needed I'll gladly post it. Thanks to everyone in advance. I'm sorry I'm asking so much, but the side of my head is bashed in from the brick wall. Jim C:\orionjava -jar orion.jar Auto-unpacking C:\Orion-test-apps\Test20CmpDo\rel\Sample20EbDo-ver001a.ear... do ne. Auto-unpacking C:\Orion-test-apps\Test20CmpDo\rel\Sample20EbDo-ver001a\Sample20E bDo-ver001a-web.war... done. Auto-deploying Sample20EbDo (Assembly had been updated)... Auto-deploying Sample20EbDo-ver001a-ejb.jar (ejb-jar.xml had been touched since the previous deployment)... java.lang.NullPointerException at com.evermind.server.ejb.deployment.ContainerManagedField.equals(JAX) at java.util.HashMap.put(Unknown Source) at java.util.HashSet.add(Unknown Source) at java.util.AbstractCollection.addAll(Unknown Source) at java.util.HashSet.init(Unknown Source) at com.evermind.server.ejb.deployment.Dependent.zk(JAX) at com.evermind.server.ejb.compilation.f4.init(JAX) at com.evermind.server.ejb.compilation.f9.ss(JAX) at com.evermind.server.ejb.EJBContainer.by(JAX) at com.evermind.server.Application.by(JAX) at com.evermind.server.Application.ge(JAX) at com.evermind.server.ApplicationServer.rn(JAX) at com.evermind.server.ApplicationServer.apr(JAX) at com.evermind.server.ApplicationServer.ge(JAX) at com.evermind.server.hf.run(JAX) at java.lang.Thread.run(Unknown Source) at com.evermind.util.f.run(JAX) ?xml version="1.0"? !DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_2_0.dtd" ejb-jar descriptionTest Sample EJB 2.0 EB/description display-namePerson/display-name enterprise-beans entity cmp-version2.0/cmp-version descriptionPerson has an address DO/description display-nameTest20CmpDo.eb.Person/display-name ejb-nameTest20CmpDo.eb.Person/ejb-name homeTest20CmpDo.eb.PersonHome/home remoteTest20CmpDo.eb.Person/remote ejb-classTest20CmpDo.eb.PersonEJB/ejb-class persistence-typeContainer/persistence-type prim-key-classjava.lang.String/prim-key-class reentrantTrue/reentrant !-- Same failure with without the next line --
