Re: Orion in production

2000-10-21 Thread Al Fogleson

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: Orion in production

2000-10-21 Thread Al Fogleson

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?

2000-10-21 Thread Al Fogleson

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: Help with getting Orion to talke to Oracle.

2000-10-19 Thread Al Fogleson

You need to copy the oracle drivers into your orion/lib directory I actually
unzipped the classes111.zip there myself.

Al

- Original Message -
From: "J Davis" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Thursday, October 19, 2000 1:43 PM
Subject: Help with getting Orion to talke to Oracle.


 I have been pulling my hair out trying to get oracle and orion to talk to
 each other.  I am sure it is a simple error, but I can't seem to find it.
 Here is my problem:

 I have installed orion 1.3.8 on a Windows 2000 server with jdk1.2.2,
 j2ee1.2.1, jre1.2.2 and oracle8idrivers12_01.zip.

 I copied the tools.jar from the jdk into the c:\orion dir.

 I have taken the time to set the following ENV variables based off some
 earlier messages:

 J2EE_CLASSPATH=c:\orion\lib\oracle8idrivers12_01.zip
 J2EE_HOME=c:\j2ee
 JAVA_HOME=c:\jdk
 PATH=(Original path);c:\jdk

 I tried exploding the oracle drivers in the orion/lib dir as well as the
 jre/lib/ext dir.

 I tried adding the oracle zip file to the library tag in the
application.xml
 like so:

 library path="../lib/oracle8idrivers12_01.zip;../lib" /

 I setup the data-source file like so:

 data-source
 class="com.evermind.sql.ConnectionDataSource"
 name="Oracle VND Driver"
 location="jdbc/vndCoreDS"
 pooled-location="jdbc/vndPooledDS"
 xa-location="jdbc/xa/vndXADS"
 ejb-location="jdbc/vndDS"
 connection-driver="oracle.jdbc.driver.OracleDriver"
 username="login"
 password="pass"
 schema="./database-schemas/oracle.xml"
 url="jdbc:oracle:thin:@machine:1521:sid"
 inactivity-timeout="120"
 /

 I built a simple class that looks like this to run from a remote machine:

 import java.sql.*;
 import javax.ejb.*;
 import javax.sql.DataSource;
 import javax.naming.*;
 import com.micronpc.db.*;

 public class TestConn
 {
   Context jndiContext;

   public TestConn()
   {
 try
 {
   jndiContext = new InitialContext();
   DataSource ds = (DataSource)jndiContext.lookup("jdbc/vndPooledDS");
   Connection conn = ds.getConnection();
   Statement s = conn.createStatement();
   String sql = "SELECT * from adv_sub_family_type";
   ResultSet rs = s.executeQuery(sql);
   while(rs != null  rs.next())
   {
 System.out.println("Record:" + rs.getString(1));
   }
 }
 catch(Exception e)
 {
   System.out.println("Got this exception:" + e.getMessage());
   e.printStackTrace();
 }
   }

   public static void main(String[] args)
   {
 TestConn testConn1 = new TestConn();
   }
 }

 My application-client.xml in the META-INF looks like this(although I am
not
 trying to use any of these objects yet.):

 ?xml version="1.0"?
 !DOCTYPE application-client PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE
 Application Client 1.2//EN"
 "http://java.sun.com/j2ee/dtds/application-client_1_2.dtd"
 application-client
 ejb-ref
 ejb-ref-nameQuoteEntity/ejb-ref-name
 ejb-ref-typeEntity/ejb-ref-type
 homecom.micronpc.api.configurator.QuoteEntityHome/home

 remotecom.micronpc.api.configurator.QuoteEntityRemote/remote
 /ejb-ref
 ejb-ref
 ejb-ref-nameModelQuoteEntity/ejb-ref-name
 ejb-ref-typeEntity/ejb-ref-type

 homecom.micronpc.api.configurator.ModelQuoteEntityHome/home

 remotecom.micronpc.api.configurator.ModelQuoteEntityRemote/remote
 /ejb-ref
 ejb-ref
 ejb-ref-nameProfileEntity/ejb-ref-name
 ejb-ref-typeEntity/ejb-ref-type
 homecom.micronpc.api.configurator.ProfileEntityHome/home

 remotecom.micronpc.api.configurator.ProfileEntityRemote/remote
 /ejb-ref
 /application-client

 my jndi.properties looks like this:


java.naming.factory.initial=com.evermind.server.ApplicationClientInitialCont
 extFactory
 java.naming.provider.url=ormi://ejbtestbox/micron
 java.naming.security.principal=admin
 java.naming.security.credentials=123

 my principales file looke like this:

 ?xml version="1.0"?
 !DOCTYPE principals PUBLIC "//Evermind - Orion Principals//"
 "http://www.orionserver.com/dtds/principals.dtd"

 principals
 groups
 group name="administrators"
 descriptionadministrators/description
 permission name="administration" /
 permission
 name="com.evermind.server.AdministrationPermission" /
 /group
 group name="guests"
 descriptionguests/description
 /group
 group name="users"
 descriptionusers/description
 permission name="rmi:login" /
 permission
 name="com.evermind.server.rmi.RMIPermission" /
 /group
 /groups
 users
 user username="admin" password="123"
 descriptionThe default administrator/description
 group-membership group="administrators" /
 group-membership group="guests" /
 group-membership group="users" /
 /user
 user username="user" password="456"
 descriptionThe default user/description
 group-membership group="guests" /
 group-membership group="users" /
 /user
 user username="anonymous" password=""
 descriptionThe default guest/anonyomous
 user/description
 group-membership group="guests" /
 /user
 /users
 /principals

 if I try to make a connection with a standalone app on the machine it
works
 fine.  If I 

Re: Orion can't find my jar file for my servlet....!

2000-10-19 Thread Al Fogleson

This is not a servlet error really, this is an xwindows error. try being
root and typing xhost + (a temporary fix this will open up your x server to
the world..) if that works you can man xhost to see how to open specific
IP's to connect to the Xserver. If this is not your box but a company box
(highly likely coming from a .gov domain) someone reconfigured the Xserver
to lock it down. Sysadmins do that when unknown users start hitting Xservers
hehe.

Al


- Original Message -
From: "Keith Kwiatek" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Thursday, October 19, 2000 2:57 PM
Subject: Orion can't find my jar file for my servlet!


 Hello,

 I loaded a new servlet of mine into the "classes" directory this new
 servlet needed a jar file, which I put into the ./orion/lib directory  (as
 well in the ./orion  and ./classes) ... all seemed to be fine. The servlet
 worked great for a long time. BUT I then I started to get the errors
below.
 I am pretty sure I didn't touch a thing configuration wise. All I had been
 doing was recompiling my servlet code. Now it seems it can' t find the jar
 file??!!! The other example servlets still run fine. Any ideas?


 500 Internal Server Error
 java.lang.InternalError: Can't connect to X11 window server using ':0.0'
as
 the value of the DISPLAY variable. at
 sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) at
 sun.awt.X11GraphicsEnvironment.clinit(X11GraphicsEnvironment.java:61) at
 java.lang.Class.forName0(Native Method) at
 java.lang.Class.forName(Class.java, Compiled Code) at

java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment
 .java, Compiled Code) at java.awt.Font.initializeFont(Font.java, Compiled
 Code) at java.awt.Font.init(Font.java, Compiled Code) at
 javachart.chart.Gc.clinit(Gc.java:74) at
 javachart.chart.Plotarea.init(Plotarea.java, Compiled Code) at
 javachart.chart.BarChart.initChart(BarChart.java, Compiled Code) at
 javachart.chart.Chart.init(Chart.java, Compiled Code) at
 javachart.chart.BarChart.init(BarChart.java, Compiled Code) at
 javachart.servlet.columnApp.localInit(columnApp.java, Compiled Code) at
 javachart.servlet.Bean.buildChart(Bean.java, Compiled Code) at
 javachart.servlet.Bean.generate(Bean.java, Compiled Code) at
 javachart.servlet.Bean.getFileName(Bean.java, Compiled Code) at
 MagicServlet.doGet(MagicServlet.java, Compiled Code) at
 javax.servlet.http.HttpServlet.service(HttpServlet.java, Compiled Code) at
 javax.servlet.http.HttpServlet.service(HttpServlet.java, Compiled Code) at
 javax.servlet.http.HttpServlet.service(HttpServlet.java, Compiled Code) at
 com.evermind.server.http.d1.si(JAX, Compiled Code) at
 com.evermind.server.http.d1.forward(JAX, Compiled Code) at
 com.evermind.server.http.ed.sp(JAX, Compiled Code) at
 com.evermind.server.http.ed.so(JAX, Compiled Code) at
 com.evermind.util.f.run(JAX, Compiled Code

 ON THE SUBSEQUENT REQUEST TO THE SERVLET I GET:

 500 Internal Server Error
 java.lang.NoClassDefFoundError: javachart/chart/Gc at
 javachart.chart.PieChart.initChart(PieChart.java, Compiled Code) at
 javachart.chart.Chart.init(Chart.java, Compiled Code) at
 javachart.chart.PieChart.init(PieChart.java, Compiled Code) at
 javachart.servlet.pieApp.localInit(pieApp.java, Compiled Code) at
 javachart.servlet.Bean.buildChart(Bean.java, Compiled Code) at
 javachart.servlet.Bean.generate(Bean.java, Compiled Code) at
 javachart.servlet.Bean.getFileName(Bean.java, Compiled Code) at
 m.doGet(m.java, Compiled Code) at
 javax.servlet.http.HttpServlet.service(HttpServlet.java, Compiled Code) at
 javax.servlet.http.HttpServlet.service(HttpServlet.java, Compiled Code) at
 javax.servlet.http.HttpServlet.service(HttpServlet.java, Compiled Code) at
 com.evermind.server.http.d1.si(JAX, Compiled Code) at
 com.evermind.server.http.d1.forward(JAX, Compiled Code) at
 com.evermind.server.http.ed.sp(JAX, Compiled Code) at
 com.evermind.server.http.ed.so(JAX, Compiled Code) at
 com.evermind.util.f.run(JAX, Compiled Code)









Re: Orion under Solaris

2000-10-17 Thread Al Fogleson

But that is just a matter of changing the configuration to a port above
1024. .

Al

- Original Message -
From: "Chris Woods" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Tuesday, October 17, 2000 10:11 PM
Subject: RE: Orion under Solaris


 This does not permit it to run on any port  1024 on unix, though,
 and the default for orion is 80, if I'm not mistaken.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Rick Bos
 Sent: Tuesday, 17 October, 2000 18:20
 To: Orion-Interest
 Subject: RE: Orion under Solaris


 We run orion under a user account where it was installed.

 We unzipped the orion.zip as the user, then run it using
 java -jar orion.jar.



 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Kemp
 Randy-W18971
 Sent: Tuesday, October 17, 2000 4:43 PM
 To: Orion-Interest
 Subject: Orion under Solaris


 Can the Orion server processes be run as someone other then root (under
 Solaris) and how?









Re: getting EJB home from JSP

2000-10-09 Thread Al Fogleson
Title: 



hmmm interensting. of course i assume that is just 
a typo where you have the semicolon and comma after the proable remote 
object.narrow as it would not compile that way. 

I remember getting these wrapper classes returned, 
but I am sure when I was doing it I was not casting correctly. I assume you are 
getting an exception on execution?

Al

  - Original Message - 
  From: 
  Reddy Krishnan 
  To: Orion-Interest 
  Sent: Monday, October 09, 2000 2:14 
  PM
  Subject: RE: getting EJB home from 
  JSP
  
  Hi,
  
  I am 
  casting the narrowed object properly my code is 
  
  CategoryHome catHome = 
  (CategoryManagerHome)PortableRemoteObject.narrow( 
  ctx.lookup("java:comp/env/CategoryManager");, 
  CategoryManagerHome.class);
  
  but 
  this throws up a wrong ( maybe intermediate class) .(CategoryManagerHome_StatelessSessionHomeWrapper3).
  
  I am using Resin as 
  the servlet/ web server now and it works fine ( as resin acts like any other 
  java client would do).
  I would rather use 
  orion for the full setup if i can get over with this 
  problem.
  
  Thanks
  Krishnan
  
  
-Original Message-----From: Al Fogleson 
[mailto:[EMAIL PROTECTED]]Sent: Sunday, October 08, 1995 
7:57 AMTo: Orion-InterestSubject: Re: getting EJB home 
from JSP
The only time I have ever seen this is when I 
forgot to cast my PortableRemoteObject.narrow() call it should be 
something like...

CategoryManagerHomehome;

home = (CategoryManagerHome) 
PortableRemoteObject.narrow(ctx.lookup("myhome"), 
CategoryManagerHome.class);



you still have to cast it to a thisHome object 
even using a portableRemoteObject.narrow()

Al


  - Original Message - 
  From: 
  Jitendra 
  Kothari 
  To: Orion-Interest 
  Sent: Saturday, October 07, 2000 
  10:59 PM
  Subject: getting EJB home from 
  JSP
  
  Hi,
  I am deploying ejbs, and jsps using a source-directory 
  method with development set to "true"( instead of packages classes into 
  ears or wars). When i try to get a handle from JNDI for EJB home class 
  within my jsp i am getting following error:
  java.lang.ClassCastExceptionat 
  com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:296)at 
  javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:137)
  This isbecause Orionis returning some wrapper 
  class instead of 
  thehome.(CategoryManagerHome_StatelessSessionHomeWrapper3).
  The same code works fine if i call from a standalone java 
  test client, in which case Orion returns some _proxy3 
  class which gets casted to the proper class.
  Would appreciate any help and insights on this 
  problem.
  Thanks Much,
  Krishnan 
  


Re: getting EJB home from JSP

2000-10-08 Thread Al Fogleson
Title: 



The only time I have ever seen this is when I 
forgot to cast my PortableRemoteObject.narrow() call it should be something 
like...

CategoryManagerHomehome;

home = (CategoryManagerHome) 
PortableRemoteObject.narrow(ctx.lookup("myhome"), 
CategoryManagerHome.class);



you still have to cast it to a thisHome object even 
using a portableRemoteObject.narrow()

Al


  - Original Message - 
  From: 
  Jitendra 
  Kothari 
  To: Orion-Interest 
  Sent: Saturday, October 07, 2000 10:59 
  PM
  Subject: getting EJB home from JSP
  
  Hi,
  I am deploying ejbs, and jsps using a source-directory method 
  with development set to "true"( instead of packages classes into ears or 
  wars). When i try to get a handle from JNDI for EJB home class within my jsp i 
  am getting following error:
  java.lang.ClassCastExceptionat 
  com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:296)at 
  javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:137)
  This isbecause Orionis returning some wrapper 
  class instead of thehome.(CategoryManagerHome_StatelessSessionHomeWrapper3).
  The same code works fine if i call from a standalone java test 
  client, in which case Orion returns some _proxy3 class which 
  gets casted to the proper class.
  Would appreciate any help and insights on this 
  problem.
  Thanks Much,
  Krishnan 
  


Re: How does orionconsole do it?? (remote EJBs)

2000-10-08 Thread Al Fogleson

interesting, I connect to a remote server all the time using my clients. I
just set up a jndi.properties file, but it would be similar to your setup.
About the only thing I see is the /stamp after your remoteserver. I have
never had anything after the ormi://remoteserver, Doing all the lookup in
the jndi context. (I assume stamp is a subcontext you are looking in)

thus if I had a bean (thisHome) that i bound to context stamp/myHomeObject I
would go about it this way (using your env.

env.put(Context.INITIAL_CONTEXT_FACTORY,"com.evermind.server.rmi.RMIInitialC
ontextFactory");
env.put(Context.PROVIDER_URL,"ormi://remoteserver");
env.put(Context.SECURITY_PRINCIPAL,"admin");
env.put(Context.SECURITY_CREDENTIALS,"123");
context = new InitialContext(env);

thisHome home;

home = (thisHome)
PortableRemoteObject.narrow(context.lookup("stamp/myHomeObject"),
thisHome.class);

and so on... maybe I am totally missing what you want to do though. :)



Al


- Original Message -
From: "James Ho" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Sunday, October 08, 2000 3:10 AM
Subject: How does orionconsole do it?? (remote EJBs)


 Hi everyone,

 I am currently trying to access an remote EJB from a servlet.  I had
 this, in my code..



env.put(Context.INITIAL_CONTEXT_FACTORY,"com.evermind.server.rmi.RMIInitialC
ontextFactory");
 env.put(Context.PROVIDER_URL,"orim://remoteserver/stamp");
 env.put(Context.SECURITY_PRINCIPAL,"admin");
 env.put(Context.SECURITY_CREDENTIALS,"123");
 context = new InitialContext(env);

 When I tried to lookup the EJB, it kept on saying 'domain was null'.
 WHat happened was that it actually tried to look for 'stamp' in the
 local orion server (and of course failed).

 What I wanted to do, is basically like orionconsole.jar, let u add a
 server in, and then search the EJBs on the server, and mine is
 web-based.  How does orionconsole do it?  How come the orion console
 doesn't need the remote EJBs' home/remote interface??  I have been
 having a lot of problem with servlets accessing remote EJBs.. :(

 Any help much appreciated.

 Thanks heaps...

 Regards, James.






Re: OrionServer newbie question

2000-09-13 Thread Al Fogleson

I dont know as orion is any worse than anything else for jsp's. We use
netscape at work on this job (my current one) and it doesnt do any decent
logging when something goes wrong either. In a JSP it either works, or it
doesnt. :)

Al

- Original Message -
From: "Bill Girten" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Wednesday, September 13, 2000 9:02 PM
Subject: OrionServer newbie question


 It appears that the logs don't offer much for reporting exceptions when
 a jsp is launched.  Is there an area that helps pinpoint where things
 (jars, etc.) go wrong?

 Thanks in advance.

 - Bill Girten / TechSurfers, Inc.







Clustering

2000-06-19 Thread Al Fogleson

OK, We are specing out a project at work that is going to require clustering
our EJB servers... has anyone gotten orion to cluster EJB's? Maybe a quick
short tutorial? I would love to recommend Orion, but without the docs on how
to do that... it becomes harder.

Al






Re: How are database JOINS achieved with EJBs?

2000-05-28 Thread Al Fogleson

Karl;

Most of the EJB containers I have tried out have multiple instances of a JVM
running, thats an awful lot of overhead. We are also running applications
where there are up to (and sometimes more) than 100 simultaneous accesses on
a bean. Even using clustering there is still an awful load on our cpu's at
that rate.

unless there is some way to access the bean other than through the
home/remote interface I cant think of any instance where a EJB is not
accessed remotely. Whether that RMI call is made locally or from a turly
remote client (application, applet, what have you) its still an RMI call. i
will grant that it will be faster on a local call than on a network call,
but it is still an RMI call. (I'll even grant that RMI is faster than Corba
IIOP, but I wonder, since the last tests I saw were using straight RMI if
that is even true now.)

I disagree on the changing databases using BMP. Enterprise level databases
all are pretty much standardized on SQl, and as long as you dont use some
database specific code to do your stuff in (whether that be calling stored
procedures or whatever) you should be able to be portable accross databses
using JNDI to get a datasource. I do agree there are not that many cases
where BMP is truly necessary however. :)

Al

- Original Message -
From: "Karl Avedal" [EMAIL PROTECTED]
To: "Al Fogleson" [EMAIL PROTECTED]
Cc: "Orion-Interest" [EMAIL PROTECTED]
Sent: Sunday, May 28, 2000 5:01 AM
Subject: Re: How are database JOINS achieved with EJBs?


 Hello Al,

 Al Fogleson wrote:

  Yes and no. There is a terribly large amount of overhead involved in
 EJB to begin with

 Which overhead are you referreing to by this? The overhead involved
 should be low compared to the optimizations that are done to speed up
 data access.

  then you start adding all the RMI calls over the network and that adds
 some load too

 Well, EJBs will not always be called remotely to start with. A very
 common scenario is that you write Servlets/JSPs that communicate with
 EJBs. Usually you will run your Web components and EJBs on the same
 servr and no RMI calls will be made. Of course though, if you need the
 remote access it will be used. But that is an overhead you need no
 matter what technology. Orion's RMI-transport protocol is very
 optimized.
  There are some situations, especially when doing the kinds of things
 you are talking
 about where BMP is the only way to go. Because of complex joins or the
 need for a
 complex primary key. it does put more work on the bean developer but in
 some cases
 it may be the only way to go.

 Yes, in a few very rare cases you need BMP because of the full control,
 but whenever you do, stop and think about wether you really need it. In
 most cases when BMP is used it's not really necesseary. And with BMP, as
 always, you won't get the performance of CMP and it won't be as simple
 to change database.

 Regards,
 Karl Avedal






Re: Does Orion eliminate RMI? Was: How are database JOINS achieved with EJBs?

2000-05-28 Thread Al Fogleson

that would be the only case where I can see that you could bypass RMI. How
it would be done and maintain within spec would be beyond me. since the
client is not run in the container... certainly in the case of a session
bean calling Entities yes, but in the case of a web client (servlet or
whatever) calling the session bean you are still going to have the RMI
overhead. That was my contention. I assumed Karl was speaking of the
inter-container calls between Session and Entity beans when he referred to
them not being called remotely after I thought about it :)

Al

- Original Message -
From: "Steven Punte" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Sunday, May 28, 2000 7:33 PM
Subject: Does Orion eliminate RMI? Was: How are database JOINS achieved with
EJBs?



  Al Fogleson wrote:
   then you start adding all the RMI calls over the network and that adds
  some load too
 
  Well, EJBs will not always be called remotely to start with. A very
  common scenario is that you write Servlets/JSPs that communicate with
  EJBs. Usually you will run your Web components and EJBs on the same
  servr and no RMI calls will be made. Of course though, if you need the
  remote access it will be used. But that is an overhead you need no
  matter what technology. Orion's RMI-transport protocol is very
  optimized.

 I agree with Karl that RMI, even on the same machine, is a significant
 overhead.  Think of CPU consumption to serialized and de-serialize
 member function arguments and return value.

 When ones' client and EJB container are both on the same machine
 and in the same process, CAN Orion bypass the RMI protocol
 here and achieve near optimum performance?

 It would be like having your cake and eating it too, to have both
 the Enterprise architecture and near optimum performance
 in this single server scenario.  :-)

 STeve










Re: EJB Question(s)

2000-04-03 Thread Al Fogleson

This is true. I think a lot of us just worry about the cost of RMI too much.
Is it noticeable to the user? No, probably not. Right now we sit at about
300 concurrent sessions though and the cost of RMI then becomes pretty high.
(actually I think you can actually go higher than 50 concurrent users. there
will be an initial hit as they access the site, but then there will be some
down time as they view and decide what to do next)

Scalability is good with EJB, and it is HOT technology, one just needs to be
aware of the costs involved in that. On  the clustering side that is exactly
why we are using EJB. You start to become overloaded in resources you just
through another server onto the network. So yes, what you say about that is
absolutely true.

Actually a lot of my concerns about RMI costs and such are coming from a
recent interview I had which made me think of some things. Some I have
rethought and have come to the conclusion they were not exactly correct. But
then EJB is so new to both me (I've only been using the technology a few
months and just moved to the 1.1 spec) and the place I interviewed at that I
had to do some tests to see if the theorys were true or false. :) The cost
in network traffic using RMI is not going to go away, the question becomes
is that cost higher than we can affford or is the scalability important
enough to warrant that higher cost. Personally I don't think that the cost
is any worse than using JSP's or servlets. But I have not actually done any
timing or performance tests. The advantage in my mind at least is the
database pooling Which is also why I am such a fan of Stateless session
beans. Pooling is much easier and less costly with them than with stateful.

Anyway I babble. Yes, everything you say is correct. Some of us just try to
get every ounce of power possible from what we have. :) Sometimes that tends
to make us worry worts. Jens probably has some figures on the costs and
such, he has done much testing lately with these things.

Al
- Original Message -
From: Kevin Duffey [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Sunday, April 02, 2000 6:43 PM
Subject: RE: EJB Question(s)


 Ok..you've got me concerned here. I thought EJB was all the rage right
now,
 which is the big reason everyone is going to it. But, you and some others
 have been saying lately that its slow compared to other solutions.

 The question is, is it slow only because of network traffic? I mean, we
have
 a T1 line, which is 1.5Mbps, but our network is 100Mbps, so if everyone is
 using 56K modems hitting our site, thus, about 50 people can use our site
 via T1 at the exact same moment, how is it being such a bottleneck to the
 100Mbps network behind the scenes?

 Plus, from what I read, the reason to go to EJB is so you can scale the
 hardware and the app server on each machine works together to keep the
same
 session from the client-side going to the right machine on the EJB tier,
and
 thus as you scale and add more machines, you can handle more. Is this not
 the case now?

 Another question arises here. Doesn't the EJB server handle scalability
 automatically? Meaning, if I add another machine, is it alot of work to
get
 a new app server installed and working with an existing one, so that the
 requests are divided between the two app servers now?

 Thanks.