SV: need help getting started

[Magnus Rydin]

Title: SV: need help getting started





IMHO,
Orion is a better choice than Tomcat at this moment, even if just using JSP/Servlets.
Im still waiting for some benchmarks to show me that Tomcat has matured and can be compared to the other application servers.

As far as being the Reference Implementation, it has a history of not following the specification. Although this is hopefully not the case today.

Again, this is my opinion, it doesnt have to be anyone elses :)


WR




> -Ursprungligt meddelande-
> Från: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
> Skickat: den 1 mars 2001 14:10
> Till: Orion-Interest
> Ämne: RE: need help getting started
> 
> 
> I would definately *NOT* recommend moving away from Tomcat if 
> you only use
> JSP and servlets. Tomcat is the reference implementation, it 
> is free, and
> unless you need a product with a lot of additional features 
> (GUI helper
> tools, EJBs, remote debugging, etc.) there is no reason to 
> open up a can of
> worms.
> I really like the Orion server but that is for its EJB 
> capabilities. I think
> the Orion team strives for making it a great EJB server. - 
> The aim is not
> specifically to make it the best JSP/Servlet platform 
> available, so I would
> not expect it to be ahead of Tomcat in that sence.
> Orion is a great product, but also a more complicated 
> product, so if you can
> use a less complex system and still fulfill your needs, then I sure
> recommend you do so.
> 
> However, should you get to the point where you simply don't 
> think using just
> a relational database and several truck loads of SQL really 
> makes your day,
> THEN JOIN THE CLUB - that is why many of use Orion Server and 
> Enterprise
> Java Beans.
> 
> Yours Sincerely
> 
> Randahl
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of John de la
> Garza
> Sent: 1. marts 2001 19:01
> To: Orion-Interest
> Subject: need help getting started
> 
> 
> I have been using tomcat for some time now and am having 
> issues with it...
> 
> 
> I am thinking about using Orion.  I don't do any ejb stuff 
> and only need a
> servlet container and web server.
> 
> I am having trouble using formbased security.  I couldn't get 
> it to work
> with the users set up in the principals file.  When I would go to a
> protected area I would just get a message saying 'not allowed here' or
> something like that but I would not get prompted for a pw username.
> 
> 
> I actually don't want to use the principals file but have the 
> usernames and
> passwds in a data base.
> 
> Can anyone here refer me to some documentation on this?
> 
> 

JAAS Support?

[Phan Anh Tran]

Does Orion support JAAS?
 
Anh
 

Re: need help getting started

[johnd]

my main reason for switching was that orion is much faster than tomcat.
Isn't that so?

But, you are right, I had the feeling that it was way over kill...I am also
looking into resin, I guess that is over kill, too for functionality, but
like I said I was looking for speed gains.

- Original Message -
From: "Randahl Fink Isaksen" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Thursday, March 01, 2001 2:10 PM
Subject: RE: need help getting started


> I would definately *NOT* recommend moving away from Tomcat if you only use
> JSP and servlets. Tomcat is the reference implementation, it is free, and
> unless you need a product with a lot of additional features (GUI helper
> tools, EJBs, remote debugging, etc.) there is no reason to open up a can
of
> worms.
> I really like the Orion server but that is for its EJB capabilities. I
think
> the Orion team strives for making it a great EJB server. - The aim is not
> specifically to make it the best JSP/Servlet platform available, so I
would
> not expect it to be ahead of Tomcat in that sence.
> Orion is a great product, but also a more complicated product, so if you
can
> use a less complex system and still fulfill your needs, then I sure
> recommend you do so.
>
> However, should you get to the point where you simply don't think using
just
> a relational database and several truck loads of SQL really makes your
day,
> THEN JOIN THE CLUB - that is why many of use Orion Server and Enterprise
> Java Beans.
>
> Yours Sincerely
>
> Randahl
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of John de la
> Garza
> Sent: 1. marts 2001 19:01
> To: Orion-Interest
> Subject: need help getting started
>
>
> I have been using tomcat for some time now and am having issues with it...
>
>
> I am thinking about using Orion.  I don't do any ejb stuff and only need a
> servlet container and web server.
>
> I am having trouble using formbased security.  I couldn't get it to work
> with the users set up in the principals file.  When I would go to a
> protected area I would just get a message saying 'not allowed here' or
> something like that but I would not get prompted for a pw username.
>
>
> I actually don't want to use the principals file but have the usernames
and
> passwds in a data base.
>
> Can anyone here refer me to some documentation on this?
>
>
>

JUGerNaut Upcoming Courses in Maryland USA

[Michael Van]

We are proud to announce that we'll be holding another
peer-based-instruction group for programmers in the state of Maryland, USA.
If you're interested in joining our organization, please e-mail me.  This
term we'll be focusing on Servlets, JSP's and XSLT's using Cocoon.

If you'd like to start a JUGerNaut group and are not in Maryland, please
contact me for the Syllabus and requirements for being a JUGerNaut group.

Michael Van
CEO, JUGerNaut

PS. Mr. Birchfield, thanks for the database connection pooling bean. I hope
you're doing well.

configuring an application

[G.L. Grobe]

 After 
running 'java -jar orion.jar', I get the following output:Error 
initializing site C.A.I.S: No application named 'cais' found in 
theserverOrion/1.4.5 initializedI can't seem to get the 
application setup correctly. I've included thefollowing 
files:server.xmlapplicaton.xmlcais-web-site.xmlOrion is 
installed under /u/public/orion on linux.My application is installed as 
follows-- my directory structure 
/u/build   |+ META-INF (ejb's 
etc...)   |- build.xml (and build)   |+ cais-web 
(web app)   |   |+ 
WEB-INF   |   
|  |+ classes   
|   |  |+ 
lib   |   
|  |+ src   
|   
|   |+ com 
...   |   |   
|   |+ web   
|   
|- *.html, *.jsp, etc...   |-config/server.xml 
-"http://www.orionserver.com/dtds/application-server.dtd">   
application-directory="../applications"   
deployment-directory="../application-deployments" >   
            
           
            -config/application.xml 
-runtime 1.2//EN" 
"http://www.orionserver.com/dtds/orion-application.dtd">      
   
          
    
   
      
  
 
    
   
    
 
  
  
 
    
   
    
 
  
   
-config/cais-web-site.xml 
-"http://www.orionserver.com/dtds/web-site.dtd">         

configuring an application

[G.L. Grobe]

After running 'java -jar orion.jar', I get the following output:

Error initializing site C.A.I.S: No application named 'cais' found in the
server
Orion/1.4.5 initialized

I can't seem to get the application setup correctly. I've included the
following files:
server.xml
applicaton.xml
cais-web-site.xml

Orion is installed under /u/public/orion on linux.
My application is installed as follows

-- my directory structure 
/u/build
   |+ META-INF (ejb's etc...)
   |- build.xml (and build)
   |+ cais-web (web app)
   |   |+ WEB-INF
   |   |  |+ classes
   |   |  |+ lib
   |   |  |+ src
   |   |   |+ com ...
   |   |
   |   |+ web
   |   |- *.html, *.jsp, etc...
   |
-config/server.xml -

http://www.orionserver.com/dtds/application-server.dtd">



   
   
   
   
   
  
   

   

   

   
   

   
   



-config/application.xml -

http://www.orionserver.com/dtds/orion-application.dtd">



   
   

   


   

   
  
  
   

   

   
  
 

   

 
  
  
 

   

 
  
   


-config/cais-web-site.xml -

http://www.orionserver.com/dtds/web-site.dtd">


   
   
   

RE: need help getting started

[Jeff Schnitzer]

Tomcat, unfortunately, is one of the slower servlet runners available.
Orion is one of the fastest, and it allows an upgrade path to EJBs if he
wants to evolve his architecture that way.

But you're right, Orion (or any EJB container) adds a lot of complexity
and expense.  Caucho's Resin is a good, fast, and cheap servlet runner
http://www.caucho.com.  I used it for a bit before I "upgraded" my
architecture to EJBs and adopted Orion.  Resin is a very nice product
for what it does, much nicer than Tomcat.

Jeff

>-Original Message-
>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 01, 2001 2:10 PM
>To: Orion-Interest
>Subject: RE: need help getting started
>
>
>I would definately *NOT* recommend moving away from Tomcat if 
>you only use
>JSP and servlets. Tomcat is the reference implementation, it 
>is free, and
>unless you need a product with a lot of additional features (GUI helper
>tools, EJBs, remote debugging, etc.) there is no reason to 
>open up a can of
>worms.
>I really like the Orion server but that is for its EJB 
>capabilities. I think
>the Orion team strives for making it a great EJB server. - The 
>aim is not
>specifically to make it the best JSP/Servlet platform 
>available, so I would
>not expect it to be ahead of Tomcat in that sence.
>Orion is a great product, but also a more complicated product, 
>so if you can
>use a less complex system and still fulfill your needs, then I sure
>recommend you do so.
>
>However, should you get to the point where you simply don't 
>think using just
>a relational database and several truck loads of SQL really 
>makes your day,
>THEN JOIN THE CLUB - that is why many of use Orion Server and 
>Enterprise
>Java Beans.
>
>Yours Sincerely
>
>Randahl
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of John de la
>Garza
>Sent: 1. marts 2001 19:01
>To: Orion-Interest
>Subject: need help getting started
>
>
>I have been using tomcat for some time now and am having 
>issues with it...
>
>
>I am thinking about using Orion.  I don't do any ejb stuff and 
>only need a
>servlet container and web server.
>
>I am having trouble using formbased security.  I couldn't get 
>it to work
>with the users set up in the principals file.  When I would go to a
>protected area I would just get a message saying 'not allowed here' or
>something like that but I would not get prompted for a pw username.
>
>
>I actually don't want to use the principals file but have the 
>usernames and
>passwds in a data base.
>
>Can anyone here refer me to some documentation on this?
>
>
>

Re: Orion Tutorial, Parts 1 and 2

[Ernst de Haan]

Although I've written my own Orion tutorials for starters, I heartily welcome
your contributions! If you like I can give you my XML tutorial format plus an
XSLT stylesheet that will convert it to a format similar to the Orion Primer:

   * http://jollem.com/orion-primer/

Ofcourse I'd welcome new stylesheets as well, I already `uniquely' identified
my stylesheet as `Classic' ;)

I'd also be happy to host your tutorials at http://jollem.com/. In that case
you can have a shell account and CVS access (to the other Orion tutorials
too).

If you want www.orionsupport.com to host your tutorials, they probably have
their own XML format for documents posted there.

Thanks again for your contribution!

--
Ernst


James Halloran wrote:
> Hello Orion community,
> 
> I cleaned up the tutorial I posted here a few days ago, and I added a Part 2 
> that explains connecting to Oracle.  The only tools you need to use are 
> javac, jar, and deploytool.  You won't need to write any XML files either, 
> aside from adding lines the Orion config files.  I hope these guides will be 
> useful for newcomers to Orion, or even J2EE.
> 
> http://www.4degreez.com/intro_part_1.html
> http://www.4degreez.com/intro_part_2.html
> 
> I think everything will work properly, but it's possible that there is a 
> mistake or two in there so let me know if you find any.  If someone is able 
> to follow through it and get it to work, I'd love to hear about it.
> 
> In a few days, I'll see about getting it posted at orionsupport.
> _
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> 
> 

RE: Capturing the output of a JSP page as HTML

[Alex 'Kazuma' Garbagnati]

>Can anyone tell me if this is possible.  I have a JSP page that contains
>information about an order that was just entered (Essentially a
>confirmation page).  What I want to do is somehow intercept the output
>stream inside the JSP page and write it to a file, as plain html, which I
>will later attach to an email and send to someone.

There area couple of solutions...
The best one is using (if you can) Filtering of servlet 2.3

If this is not possible (you cannot use servlet 2.3 but only 2.2) the best 
way is building a simple JSP Tag that will include your page. The tag will 
do whatever you need before sending out the bodyContent.

I've done this for an environment where installing 2.3 was out of the 
question and it works fine.
If you need the code, email me directly.

 Best Regards,
 Kazuma


Cos'e' il genio. E' fantasia intuizione, colpo d'occhio e velocita' 
d'esecuzione. (Amici Miei)

---
Alessandro A. 'Kazuma' Garbagnati
http://www.kazuma.net/   ICQ UIN: 1600386
Mountain View, CA, 94043 - USA

RE: Capturing the output of a JSP page as HTML

[Matt Krevs]

http://www.orionserver.com/tutorials/filters/

  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]]On Behalf Of 
  [EMAIL PROTECTED]Sent: Friday, 2 March 2001 6:06 
  AMTo: Orion-InterestSubject: RE: Capturing the output of 
  a JSP page as HTML
   Hi, Thanks for the reply to my question.  I am not familiar with 
  filters.  How would I do this?"elephantwalker" 
  <[EMAIL PROTECTED]>Sent by: 
  [EMAIL PROTECTED]03/01/2001 09:42 
  AM PSTPlease respond to 
  Orion-InterestTo: Orion-Interest <[EMAIL PROTECTED]>cc: bcc: Subject: RE: Capturing the output of a JSP page as 
  HTML
  I think you can use a Filter to do 
  that.-Original 
  Message-From: 
  [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]]On 
  Behalf Of[EMAIL PROTECTED]Sent: Thursday, March 01, 2001 8:32 
  AMTo: Orion-InterestSubject: Capturing the output of a JSP page as 
  HTMLCan anyone tell me if this 
  is possible.  I have a JSP page that containsinformation about an 
  order that was just entered (Essentially aconfirmation page).  What I 
  want to do is somehow intercept the outputstream inside the JSP page and 
  write it to a file, as plain html, which Iwill later attach to an email 
  and send to someone.Thanks,Andy

RE: Orion Tutorial, Parts 1 and 2

[Kemp Randy-W18971]

 These tutorials are great and a wonderful aid for J2EE and Orion
deployment.

-Original Message-
From: James Halloran
To: Orion-Interest
Sent: 3/1/01 12:56 PM
Subject: Orion Tutorial, Parts 1 and 2

Hello Orion community,

I cleaned up the tutorial I posted here a few days ago, and I added a
Part 2 
that explains connecting to Oracle.  The only tools you need to use are 
javac, jar, and deploytool.  You won't need to write any XML files
either, 
aside from adding lines the Orion config files.  I hope these guides
will be 
useful for newcomers to Orion, or even J2EE.

http://www.4degreez.com/intro_part_1.html
http://www.4degreez.com/intro_part_2.html

I think everything will work properly, but it's possible that there is a

mistake or two in there so let me know if you find any.  If someone is
able 
to follow through it and get it to work, I'd love to hear about it.

In a few days, I'll see about getting it posted at orionsupport.
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: In Orion, are tag handler instances reused or reinstantiated?

[Huibert Aalbers Indaberea]

Hi Bart,

It seems that the tags are re-used only when called multiple times inside
the same page. At least that is my experience with versions up to 1.4.5

Huibert

on 3/1/01 2:25 PM, Trevor Squires at [EMAIL PROTECTED] wrote:

> 
> Funny, I never managed to get it to *not* re-use tags (haven't rev'd up to
> latest release tho) regardless of the jsp.reuse.tags setting...
> 
> Trevor
> 
> On Thu, 1 Mar 2001, Jonathan James wrote:
> 
>> Actually it's configurable. Just add "-Djsp.reuse.tags=[false|true]" to your
>> command line when you launch the server.
>> 
>> Jonathan
>> - Original Message -
>> From: "Randahl Fink Isaksen" <[EMAIL PROTECTED]>
>> To: "Orion-Interest" <[EMAIL PROTECTED]>
>> Sent: Thursday, March 01, 2001 2:47 AM
>> Subject: RE: In Orion, are tag handler instances reused or reinstantiated?
>> 
>> 
>>> Experience tells me they are reused in Orion. If I have an optional tag
>>> attribute on a tag and the tag is used multiple times on a page I have
>> found
>>> out that I need to make sure that any contents set in the optional
>> attribute
>>> must be cleared manually by me, or I will get whatever contents was set by
>> a
>>> previous invokation of the tag.
>>> 
>>> 
>>> Yours
>>> Randahl
>>> 
>>> -Original Message-
>>> From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED]]On Behalf Of Blacha, Bart
>>> Sent: 28. februar 2001 19:27
>>> To: Orion-Interest
>>> Subject: In Orion, are tag handler instances reused or reinstantiated?
>>> 
>>> 
>>> We are trying to figure out if tag handler objects are re-used, or
>>> instantiated-and-destroyed at every request.  This is obviously important
>>> for performance reasons.
>>> 
>>> There is conflicting information in JSP spec and on JGuru (see references
>>> below).  So maybe it's an implementation-specific issue.   Which brings me
>>> to the question:
>>> 
>>> What does Orion do with tag handler instances?  Reuse or reinstantiate
>> them?
>>> 
>>> 
>>> 
>>> 
>>> JSP spec 1.1, paragraph 5.4.7:
>>> 
>>> At execution time the implementation of a JSP page will use an available
>> Tag
>>> instance with
>>> the appropriate prefix and name that is not being used, initialize it, and
>>> then follow the
>>> protocol described below. Afterwards, it will release the instance and
>> make
>>> it available for
>>> further use. This approach reduces the number of instances that are needed
>>> at a time.
>>> 
>>> 
>>> http://www.jguru.com/jguru/faq/view.jsp?EID=337618
>>> 
>>> Question  We want to make sure that our JSP development efforts are
>>> thread-safe. Is it possible that two threads will access one instance of a
>>> JSP custom tag handler concurrently?
>>> 
>>> No it is not possible. There is a defined lifecycle of a custom tag, and
>>> during this lifecycle, that instance of the tag will only get called once.
>>> Hopefully in newer implementations of JSP engines, the actual tag object
>>> will not get reinstantiated each time (as this negatively affects
>>> performance), but at least during it's use, it will be thread safe.
>>> 
>>> 
>>> --
>>> Bart Blacha, Software Developer
>>> NetPerceptions Inc.
>>> (512) 349-5622
>>> [EMAIL PROTECTED]
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 

Sending Serializable obj from ejb to servlet

[John Hogan]

All,

I'm attempting to send a serializable object from an entity bean to a 
servlet, and am seeing the error below.  Seems like it may be a 
deployment thing, perhaps with helper class PaidTransaction.  If 
someone could point me at a summary for deployment requirements for 
helper classes needed by a servlet, that would be much appreciated.  
TIA.

John Hogan


javax.ejb.EJBException
at PaidTransaction_ORList4.getObjects
(PaidTransaction_ORList4.java:75)
at com.evermind.server.ejb.ORList.size(JAX)
at java.util.ArrayList.(Unknown Source)
at com.evermind.server.ejb.ORList.getReplacement(JAX)
at com.evermind.server.ejb.gv.ajn(JAX)
at com.evermind.server.ejb.gv.replaceObject(JAX)
at java.io.ObjectOutputStream.writeObject(Unknown Source)
at java.io.ObjectOutputStream.outputClassFields(Unknown 
Source)
at java.io.ObjectOutputStream.defaultWriteObject(Unknown 
Source)
at java.io.ObjectOutputStream.outputObject(Unknown Source)
at java.io.ObjectOutputStream.writeObject(Unknown Source)
at com.evermind.server.ejb.EJBUtils.cloneObject(JAX)
at PolicyWrapper_EntityBeanWrapper1.getPolicyProxy
(PolicyWrapper_EntityBeanWrapper1.java:278)
at com.sc.web.paid.RecentPolicyActivityServlet.doGet
(RecentPolicyActivityServlet.java:57)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:190)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:302)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:329)
at com.evermind.server.http.d4.s3(JAX)
at com.evermind.server.http.d4.s1(JAX)
at com.evermind.server.http.eg.s9(JAX)
at com.evermind.server.http.eg.dr(JAX)
at com.evermind.util.f.run(JAX)



_

Get your free E-mail at http://www.ireland.com

RE: EJB values into xml attributes (a little off topic, I know)

[Randahl Fink Isaksen]

Falk wrote:

(...)
We do have the same problem and solve it by transforming all strings by our
class XMLEscaper (...) I would be surprised if there existed some magic
avoiding this step.
(...)

You are probably right. Still, I would very much like to hear from anybody
who could prove you wrong. Having to use something like
XMLEscaper.escape(Book.getPreface()) for all the output you take from your
beans and use to generate XML really sounds like a mess to me.

While we are at it: If you just *have* to do this conversion, why not do it
when you put information into the beans rather than when you take it back
out again... many systems on the web certainly have more content browsing
than updates of content.


Still, I sure hope this EJB/XML hindrance is just a rumour - somebody tell
me there is a solution to this (!)


Randahl

RE: need help getting started

[Randahl Fink Isaksen]

I would definately *NOT* recommend moving away from Tomcat if you only use
JSP and servlets. Tomcat is the reference implementation, it is free, and
unless you need a product with a lot of additional features (GUI helper
tools, EJBs, remote debugging, etc.) there is no reason to open up a can of
worms.
I really like the Orion server but that is for its EJB capabilities. I think
the Orion team strives for making it a great EJB server. - The aim is not
specifically to make it the best JSP/Servlet platform available, so I would
not expect it to be ahead of Tomcat in that sence.
Orion is a great product, but also a more complicated product, so if you can
use a less complex system and still fulfill your needs, then I sure
recommend you do so.

However, should you get to the point where you simply don't think using just
a relational database and several truck loads of SQL really makes your day,
THEN JOIN THE CLUB - that is why many of use Orion Server and Enterprise
Java Beans.

Yours Sincerely

Randahl
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of John de la
Garza
Sent: 1. marts 2001 19:01
To: Orion-Interest
Subject: need help getting started


I have been using tomcat for some time now and am having issues with it...


I am thinking about using Orion.  I don't do any ejb stuff and only need a
servlet container and web server.

I am having trouble using formbased security.  I couldn't get it to work
with the users set up in the principals file.  When I would go to a
protected area I would just get a message saying 'not allowed here' or
something like that but I would not get prompted for a pw username.


I actually don't want to use the principals file but have the usernames and
passwds in a data base.

Can anyone here refer me to some documentation on this?

RE: Database schema type mappings

[Randahl Fink Isaksen]

The fact that you have found that quote in the book (even in the 2nd
edition) definately indicates that at least at some point in time it has not
been allowed to use primitive types as primary keys. Still, the
specification is under constant development, and it seems to me the subject
is deliberately ignored in the specification - in fact I did a search on
java.lang.Integer and java.lang.Long and there is _no_ example what so ever
which includes a primary key of neither the wrapper class nor the primitive
type - odd... Perhaps it is avoided in the specification because it is
subject to change.
Personally I would like to here it from "the horse's own mouth" aswell - to
be absolutely sure. We are definately not the only people who bumped into
this issue.

I am not sure your argument about EntityContext.getPrimaryKey() returning an
object can be used here, though. Since EntityContext is an interface which
is implemented by some proprietary class it is _possible_ that a container
could construct the Integer object for you no matter what kind of Integer
you are using. Please note the earlier post in this thread by Michael Third,
too. He states they are using long's - so it works. And why not? - You can
use any primitive type which is valid in RMI-IIOP, which for what I know
includes primitive types aswell.

Which brings me to my conclusion: Since this issue is unclear in the
specification there is no guarantee that using int or long will work on any
EJB Server. Therefore I will continue to use Integer to make sure my beans
are platform independent. I personally go for a container independant
system.


Randahl


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer
Sent: 1. marts 2001 12:12
To: Orion-Interest
Subject: RE: Database schema type mappings


It's at the bottom of page 159 of Richard Monson-Haefel's _Enterprise
Java Beans, 2nd Ed_:  "Although primary keys can be primitive wrappers
(Integer, Double, Long, etc.), primary keys cannot be primitive types
(int, double, long, etc.)"

I wasn't able to locate an explicit statement in the spec in my quick
scan, but the spec always refers to the primary key as the "primary key
class" and the deployment descriptor element is "prim-key-class".  This
is further reinforced by the comments in the DTD.

It makes sense, because EntityContext.getPrimaryKey() returns an Object.
Thus all PKs *must* be Objects.

About question #1:  I doubt there is any explicit requirement in the
spec that Integers be converted to ints in the database.  In fact, the
spec doesn't require a relational database; that's simply an
implementation detail.  Still, I doubt you will find *any* appservers
which serialize Integer keys as blobs - although it would work, the
performance penalty would be severe.

Jeff

>-Original Message-
>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 01, 2001 1:22 AM
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>Thanks for the reply Jeff. Know I have two replies: One saying
>primary keys
>can be primitive types and one that says they can't.
>I am really looking forward to hearing your arguments, gentlemen ;-)
>
>BTW, Jeff: Your answer to question number 1 - do you have that from the
>specification, or...
>
>Randahl
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff
>Schnitzer
>Sent: 1. marts 2001 02:52
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>>
>>1. Why is Integers automatically converted to int by Orion -
>>and is this a
>>standard EJB convention?
>
>Yes.  All the class representations of the primitive types should work
>that way.
>
>>2. Would it be legal to have a primary key of the primitive type "int"
>>instead of Integer?
>
>No.  Primary keys must be Objects.  This makes sense because
>EntityContext.getPrimaryKey() returns an Object.
>
>Jeff
>
>
>

RE: CMP 2.0

[Randahl Fink Isaksen]

God point - I'll report it as a bug in Bugzilla.


Randahl

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer
Sent: 1. marts 2001 12:16
To: Orion-Interest
Subject: RE: CMP 2.0


I've heard comments on this list in the past from Karl & Magnus that
bad, misleading, or missing error messages should be logged in Bugzilla
as bugs.

http://www.orionserver.com/bugzilla

:-)

Jeff

>-Original Message-
>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 01, 2001 1:19 AM
>To: Orion-Interest
>Subject: RE: CMP 2.0
>
>
>As I just posted, Jeff. The error was due to the fact that I 
>had declared my
>primary keys as Integer but I returned the primitive type int from my
>ejbCreate methods. As soon as I changed this, everything 
>worked fine. I am
>(to put it mildly) very surprised that Orion did _not_ give me 
>a compile
>time error when I deployed - it just crashed instead or ran 
>without working
>correctly.
>Yes I know who introduced the bug, but since I think Orion is 
>a magnificent
>piece of software I would never had expected it to NOT report 
>this compile
>time error.
>
>
>Randahl
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff 
>Schnitzer
>Sent: 1. marts 2001 02:42
>To: Orion-Interest
>Subject: RE: CMP 2.0
>
>
>?
>
>I have all my transactional behavior defined as NotSupported and I use
>EJB 2.0 container managed relationships without issue.  I don't
>currently need transactions for what I'm doing.
>
>Randahl, have you examined the contents of the database tables and the
>orion-ejb-jar.xml closely?
>
>Jeff
>
>-Original Message-
>From: Tim Drury [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, February 28, 2001 8:34 AM
>To: Orion-Interest
>Subject: RE: CMP 2.0
>
>
>
>
>I've been out for a few days, so it this has been answered,
>sorry for the repost.
>
>This sounds like you didn't set the transactional behavior
>in ejb-jar.xml as "required".  There is no default behavior
>in the spec so it is up to the container to decide what
>the default behavior is.  I know in Weblogic, transactions
>default to "supports" (I think).  In any event, the entities
>are not stored in the database unless you mark them
>as "required".  Orion may be doing the same thing.
>
>-tim
>
>
>> -Original Message-
>> From: Randahl Fink Isaksen [ mailto:[EMAIL PROTECTED]
> ]
>> Sent: Monday, February 26, 2001 5:29 AM
>> To: Orion-Interest
>> Subject: CMP 2.0
>>
>>
>> Would somebody please confirm that they have been able to use CMP 2.0
>> relationships on Orion, that they have seen them get stored
>> in the database
>> AND brought back into main memory correctly after a restart
>> of the server.
>>
>> When I create a relationship it works fine until I restart -
>> I simply can't
>> make Orion restore my relationships from the keys it stores
>> in the database.
>> If I try the getX() / method of a cmr property it works - but after a
>> restart it returns null.
>>
>>
>> R.
>>
>>
>>
>
>
>

RE: Database schema type mappings

[Randahl Fink Isaksen]

Thanks for your input. An additional argument here might be that if you are
not the only developer working on your EJB system, and if the system is to
be maintained and expanded over time by many different software developers
in a large organisation, it would probably be best to use only a single type
of key for the same EJB (both in the bean class files and in the xml
files) - and that would have to be the wrapper class, of course.
- All these mails confirm that using different kinds of keys cause
confusion, and I see no reason to confuse future developers of a system.
But that is my personal view of course - and from the systems I have met so
far in my career I sure know that not all developers think this way.

Randahl

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Michael A
Third
Sent: 1. marts 2001 17:46
To: Orion-Interest
Subject: RE: Database schema type mappings


I went digging through the EJB 1.1 specification, and it doesn't
specifically say you can't use primitive types, but it does say they primary
key class needs to be serializable.

I have created a number of EJB's using the primitive long as the primary key
and have had no problems using them.  So I went back and looked at the
deployment descriptor (it was originally generated by EJBMaker) and noticed
that they  was "java.lang.Long".  All of the EJB class files
are using the primitive type.  It appears that at least Orion maps them
intelligently(if not according to spec).

On closer examination of the EJB 2.0 spec, I found these statements.

* The primary key type must be a legal Value Type in RMI-IIOP. (this
includes long)
* The container must be able to manipulate the primary key type of an entity
bean.
* Primary key (must be a class or type?) that maps to a single field in the
entity bean class.
* The (create) method must declare the primary key class as the method
argument.

According to this statements, the primary key class and the primary key type
don't necessarily have to be the same.  Orion does allow the create method
to accept the primary key type as opposed to the class, which isn't
according to spec.

Thanks,

Michael

PS - After my response on Java primitive data-types, I should probably keep
my mouth shut for a while :)


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer
Sent: Thursday, March 01, 2001 6:12 AM
To: Orion-Interest
Subject: RE: Database schema type mappings


It's at the bottom of page 159 of Richard Monson-Haefel's _Enterprise
Java Beans, 2nd Ed_:  "Although primary keys can be primitive wrappers
(Integer, Double, Long, etc.), primary keys cannot be primitive types
(int, double, long, etc.)"

I wasn't able to locate an explicit statement in the spec in my quick
scan, but the spec always refers to the primary key as the "primary key
class" and the deployment descriptor element is "prim-key-class".  This
is further reinforced by the comments in the DTD.

It makes sense, because EntityContext.getPrimaryKey() returns an Object.
Thus all PKs *must* be Objects.

About question #1:  I doubt there is any explicit requirement in the
spec that Integers be converted to ints in the database.  In fact, the
spec doesn't require a relational database; that's simply an
implementation detail.  Still, I doubt you will find *any* appservers
which serialize Integer keys as blobs - although it would work, the
performance penalty would be severe.

Jeff

>-Original Message-
>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 01, 2001 1:22 AM
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>Thanks for the reply Jeff. Know I have two replies: One saying
>primary keys
>can be primitive types and one that says they can't.
>I am really looking forward to hearing your arguments, gentlemen ;-)
>
>BTW, Jeff: Your answer to question number 1 - do you have that from the
>specification, or...
>
>Randahl
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff
>Schnitzer
>Sent: 1. marts 2001 02:52
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>>
>>1. Why is Integers automatically converted to int by Orion -
>>and is this a
>>standard EJB convention?
>
>Yes.  All the class representations of the primitive types should work
>that way.
>
>>2. Would it be legal to have a primary key of the primitive type "int"
>>instead of Integer?
>
>No.  Primary keys must be Objects.  This makes sense because
>EntityContext.getPrimaryKey() returns an Object.
>
>Jeff
>
>
>

RE: java.lang.NullPointerException in JMS

[Heikkinen, Jarno]

Hi,

I had the same problem, but with queue-connection-factory.  It works for the
very first time, but if you stop Orion and restart, the connection.start()
gives NullPointerException.  To me, it looks like Orion has problems
rebinding the configured factories, if the factory exists already, the NPE
is thrown when client tries to start the connection.  

Now, if I remove the queue-connection-factory tag from jms.xml and restart -
the JMS access client starts work perfectly (yes, it's no longer configured
into jms.xml, but it works anyway).  I am not that familiar with Orion, I
don't know where orion actually stores the binding for JMS factory class,
but it really looks like there is something odd there.

As Orion doesn't produce any kind of debug log (or is there a hidden
option?), tracking down things like this is really difficult.  Especially in
this case, where it looks like the connection factory lookup() is OK, it
just fails when starting it.

Jarno

-Original Message-
From: Matt Simmerson [mailto:[EMAIL PROTECTED]]
Sent: 1. maaliskuuta 2001 16:19
To: Orion-Interest
Subject: java.lang.NullPointerException in JMS


Hi 
I've created my own topic-connection-factory and own topic in jms.xml 
 
 
  JMS Logger 
 
I have referenced these in my application-client.xml as 
  
App Logger 
 
 
jms/LoggerTopicConnectionFactory 
javax.jms.TopicConnectionFactory 
Container 
 
 
jms/ApplicationLoggerTopic 
javax.jms.Topic 
Container 
 
  
I reference these in my code, and print out the topic name which display
"Demo Topic" !!! 
TopicConnectionFactory connFactory = (TopicConnectionFactory)new
InitialContext().lookup("java:comp/env/jms/LoggerTopicConnectionFactory");
this.connection = connFactory.createTopicConnection(); 
this.loggerTopic = (Topic)new
InitialContext().lookup("java:comp/env/jms/ApplicationLoggerTopic"); 
When the code executes connection.start() I get the following error. 
java.lang.NullPointerException 
at java.io.DataOutputStream.writeUTF(DataOutputStream.java:329) 
at java.io.DataOutputStream.writeUTF(DataOutputStream.java:306) 
at com.evermind.server.jms.cj.(JAX) 
at com.evermind.server.jms.b8.start(JAX) 
at
AppLogger.LoggerListeners.JMSLoggerSubscriber.initSubscriber(JMSLogge 
rSubscriber.java:116) 
at
AppLogger.LoggerListeners.JMSLoggerSubscriber.(JMSLoggerSubscri 
ber.java:76) 
at
AppLogger.LoggerListeners.JMSLoggerSubscriber.main(JMSLoggerSubscribe 
r.java:33) 
Has anyone any idea what I've missed, or know how to resolve this. 
Cheers 
Matt 
Matt Simmerson 
IT Consultant 
smart421 - Smart solutions for the 21st century 
  
http://www.smart421.com 
Wap Site: wap.smart421.com 
Tel:   01473 408720 
Fax:  01473 408753 
Mob: 07759 258083 
email: [EMAIL PROTECTED] 
Information contained in this e-mail and any attachments is confidential 
and intended for the use of the addressee only.  Dissemination, 
distribution, copying or use of this communication without prior permission 
of the addressee is strictly prohibited. If you have received this 
transmission in error, please advise the originator by reply e-mail and 
delete it. Thank you. 

RE: Database schema type mappings

[Jeff Schnitzer]

>From: Chad Stansbury [mailto:[EMAIL PROTECTED]]
>
>Actually, a more proper way is to indicate to the compiler 
>that you want
>long arithmetic by writing:
>
>long millisInMonth = 1000L * 60L * 60L * 24L * 30L

I'm sure it all gets optimized out to the same thing in the end :-)  But
yes, you're right.

I can imagine what engineers 10 years from now are going to be saying
when they write Java code - damn thing only uses 32 bit math by default!
How silly on our (32 * whatever) bit chips!  :-)  It certainly beats
erratic machine-specific behavior though.

>Oh, and by the way, this is not really correct since you're 
>assuming 30 days
>in a month.  You should use the Calendar to figure out how 
>many millis a
>given month actually has since this varies by month and year.

The problem is not that particular.  It's just a "what happened in the
last 30 days" search bound.

Jeff

Re: In Orion, are tag handler instances reused or reinstantiated?

[Trevor Squires]

Funny, I never managed to get it to *not* re-use tags (haven't rev'd up to
latest release tho) regardless of the jsp.reuse.tags setting...

Trevor

On Thu, 1 Mar 2001, Jonathan James wrote:

> Actually it's configurable. Just add "-Djsp.reuse.tags=[false|true]" to your
> command line when you launch the server.
> 
> Jonathan
> - Original Message -
> From: "Randahl Fink Isaksen" <[EMAIL PROTECTED]>
> To: "Orion-Interest" <[EMAIL PROTECTED]>
> Sent: Thursday, March 01, 2001 2:47 AM
> Subject: RE: In Orion, are tag handler instances reused or reinstantiated?
> 
> 
> > Experience tells me they are reused in Orion. If I have an optional tag
> > attribute on a tag and the tag is used multiple times on a page I have
> found
> > out that I need to make sure that any contents set in the optional
> attribute
> > must be cleared manually by me, or I will get whatever contents was set by
> a
> > previous invokation of the tag.
> >
> >
> > Yours
> > Randahl
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Blacha, Bart
> > Sent: 28. februar 2001 19:27
> > To: Orion-Interest
> > Subject: In Orion, are tag handler instances reused or reinstantiated?
> >
> >
> > We are trying to figure out if tag handler objects are re-used, or
> > instantiated-and-destroyed at every request.  This is obviously important
> > for performance reasons.
> >
> > There is conflicting information in JSP spec and on JGuru (see references
> > below).  So maybe it's an implementation-specific issue.   Which brings me
> > to the question:
> >
> > What does Orion do with tag handler instances?  Reuse or reinstantiate
> them?
> >
> >
> >
> >
> > JSP spec 1.1, paragraph 5.4.7:
> >
> > At execution time the implementation of a JSP page will use an available
> Tag
> > instance with
> > the appropriate prefix and name that is not being used, initialize it, and
> > then follow the
> > protocol described below. Afterwards, it will release the instance and
> make
> > it available for
> > further use. This approach reduces the number of instances that are needed
> > at a time.
> >
> >
> > http://www.jguru.com/jguru/faq/view.jsp?EID=337618
> >
> > Question  We want to make sure that our JSP development efforts are
> > thread-safe. Is it possible that two threads will access one instance of a
> > JSP custom tag handler concurrently?
> >
> > No it is not possible. There is a defined lifecycle of a custom tag, and
> > during this lifecycle, that instance of the tag will only get called once.
> > Hopefully in newer implementations of JSP engines, the actual tag object
> > will not get reinstantiated each time (as this negatively affects
> > performance), but at least during it's use, it will be thread safe.
> >
> >
> > --
> > Bart Blacha, Software Developer
> > NetPerceptions Inc.
> > (512) 349-5622
> > [EMAIL PROTECTED]
> >
> >
> >
> >
> >
> 
> 

Re: login security include file

[Geoff Marshall]

According to all the books, as soon and you do a  there are
3 things you can't do:

1) redirect
2) mess with your response headers
3) mess with cookies

So all such code must reside before your first  in a static
file...

-- 

-Geoff Marshall, Director of Development

...
t e r r a s c o p e  (415) 951-4944
54 Mint Street, Suite 110 direct (415) 625-0349
San Francisco, CA  94103 fax (415) 625-0306
...

> From: "Vaskin Kissoyan" <[EMAIL PROTECTED]>
> Organization: Lokion
> Reply-To: Orion-Interest <[EMAIL PROTECTED]>
> Date: Wed, 28 Feb 2001 16:35:44 -0500
> To: Orion-Interest <[EMAIL PROTECTED]>
> Subject: login security include file
> 
> I'm trying to do a response.sendRedirect() from an include file 
> and wanted to avoid doing a directive.include (preparser),
> 
> I keep getting "Response has already been committed, be sure not to write to
> the OutputStream or to trigger a commit due to any other action before calling
> this method."
> 
> I have been very careful as to put this include at the very top of the file,
> and to specify autoFlush=false and flush=false on the include tag.
> 
> Again, the intention of this include file would be to be place at the top of
> the jsp file to secure it by redirecting to a login page if credentials in a
> session based UserBean do not allow access to the page for some reason.
> 
> -Vaskin
> 

RE: Struts (was: I switch from X to Orion because: )

[Jeff Schnitzer]

Why on earth would you want to store a MessageResources/ResourceBundle
in an application or session context?

The static method ResourceBundle.getBundle(...) returns a fast hash
lookup for the bundle from a table the framework maintains.  It has the
added bonus that if you pass in the appserver's classloader, properties
files are automagically reloaded just like everything else - no need for
special administrative Reload actions.

All that should be needed is:

String blah = ResourceBundle.getBundle(name, locale,
classLoader).getString(key);

Why does Struts put MessageResources in a servlet context?

Jeff

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 01, 2001 9:51 AM
>To: Orion-Interest
>Cc: [EMAIL PROTECTED]; 
>[EMAIL PROTECTED]
>Subject: Re: Struts (was: I switch from X to Orion because: )
>
>
>
>The reason for reimplementing ResourceBundle as 
>MessageResources is that
>ResourceBundle is not Serializable.  Some containers, notable 
>WebLogic 6, have
>issues with non-serializable objects being stored in things 
>like the application
>and session context.  Its also very important that you only 
>throw Serializable
>things in there espacially if you plan on using the 
> tag in
>your web.xml.
>
>mark
>
>Mark R Mascolino
>The Procter & Gamble Co.
>[EMAIL PROTECTED]
>
>
>
> Internet Mail Message  
> Received from host:
>
>
>
>   
>   
>  "Jeff Schnitzer" 
>   
> <[EMAIL PROTECTED]>
>To:  Orion-Interest 
>  Sent by:
><[EMAIL PROTECTED]>
>  [EMAIL PROTECTED]cc: 
>(bcc: Mark Mascolino-MR/PGI)
>  Subject: 
>Struts (was: I switch from X to
> 02/28/01 08:25 PMOrion 
>because: )
>  Please respond to Orion-Interest 
>   
>   
>   
>   
>   
>
>
>
>
>This subject is especially timely for me because I just finished
>evaluating both WebWork and Struts.  I decided to go with WebWork.  It
>wasn't so much that I was drawn to WebWork's technological coolness -
>there are some neat ideas there, but I think most could be adapted into
>Struts with a little effort.  The problem was that when I looked deeply
>into Struts, I didn't like what I saw.
>
>I spent a *lot* of time wavering; on one hand, Struts has a solid user
>community and good javadocs, on the other hand, WebWork is simpler and
>easier to teach future members of the team.  I kept switching my favor
>back and forth when I discovered something new I did or didn't like.
>What finally pushed me over the edge was my experience hunting down the
>problem preventing Struts from working with Orion out of the box.
>Here's the story:
>
>If you've ever tried loading the Struts 1.0 example app, you are
>immediately confounded by missing resource errors.  There is a lot of
>complaint in the Orion and Struts archives about this, but the closest
>anyone has come to nailing it down is this message:
>
>http://www.mail-archive.com/struts-user@jakarta.apache.org/msg0
>0582.html
>
>in which the principal author of Struts, Craig, implies that Orion's
>classloader has a problem preventing it from working with the standard
>JDK ResourceBundle.  I knew there was something wrong with this because
>WebWork uses ResourceBundle without issue.
>
>So I looked through Struts' source to see how it might be using
>ResourceBundle differently, and what I discovered is that 
>Struts doesn't
>use ResourceBundle at all!  In fact, Struts has a whole homebrewed
>framework for handling properties which mirrors the ResourceBundle API
>but doesn't use any of its classes or interfaces.  There are javadoc
>comments to the effect that the Struts code should be faster than
>ResourceBundles, but looking at the JDK 1.3 source code, both 
>frameworks
>seem to be doing pretty much the same thing.
>
>For those curious, the actual problem with Orion is that Struts uses
>ClassLoader.getResourceAsStream() to build the Properties 
>object, and (I
>checked the decompiled code) the Orion classloader does not implement
>getResourceAsStream().  Orion's fault, and logged as bug #340.
>
>But why re-invent the wheel?!?  The JDK provides resource 
>management for
>

RE: Capturing the output of a JSP page as HTML

[APapada]

 Hi, Thanks for the reply to my question.  I am not familiar with filters.  How would I do this?"elephantwalker" <[EMAIL PROTECTED]>Sent by: [EMAIL PROTECTED]03/01/2001 09:42 AM PSTPlease respond to Orion-Interest To: Orion-Interest <[EMAIL PROTECTED]> cc:  bcc:  Subject: RE: Capturing the output of a JSP page as HTML I think you can use a Filter to do that.-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]]On Behalf Of[EMAIL PROTECTED]Sent: Thursday, March 01, 2001 8:32 AMTo: Orion-InterestSubject: Capturing the output of a JSP page as HTMLCan anyone tell me if this is possible.  I have a JSP page that containsinformation about an order that was just entered (Essentially aconfirmation page).  What I want to do is somehow intercept the outputstream inside the JSP page and write it to a file, as plain html, which Iwill later attach to an email and send to someone.Thanks,Andy

Orion and Cocoon anyone?

[Robert_Lasch]

Hi!

I'm trying to use Cocoon 1.82 with Orion 1.45.  I've followed the example on
the orionsupport.com site, but I'm still getting an error.  Here's the error
message.

Publishing Engine could not be initialized.
java.lang.RuntimeException: Error while initializing XSP engine:
org.xml.sax.SAXNotRecognizedException:
http://apache.org/xml/features/validation/schema
at
org.apache.xerces.framework.XMLParser.setFeature(XMLParser.java:1515)
at
org.apache.xerces.parsers.DOMParser.setFeature(DOMParser.java:659)
at
org.apache.cocoon.parser.XercesParser.parse(XercesParser.java:78)
at
org.apache.cocoon.parser.AbstractParser.parse(AbstractParser.java:83)
at
org.apache.cocoon.processor.xsp.XSPProcessor.init(XSPProcessor.java,
Compiled Code)
at
org.apache.cocoon.framework.Manager.create(Manager.java:109)
at org.apache.cocoon.framework.Router.init(Router.java,
Compiled Code)
at
org.apache.cocoon.framework.Manager.create(Manager.java:109)
at org.apache.cocoon.Engine.(Engine.java:179)
at org.apache.cocoon.Engine.getInstance(Engine.java:232)
at org.apache.cocoon.Cocoon.init(Cocoon.java, Compiled Code)
at
com.orionsupport.cocoon.CocoonServlet.init(CocoonServlet.java:52)
at com.evermind.server.http.HttpApplication.w1(JAX)
at com.evermind.server.http.HttpApplication.wj(JAX)
at com.evermind.server.http.HttpApplication.w6(JAX)
at
com.evermind.server.http.HttpApplication.getNamedDispatcher(JAX)
at
com.orionsupport.cocoon.CocoonFilter.cocoonDispatcher(CocoonFilter.java:99)
at
com.orionsupport.cocoon.CocoonFilter.doFilter(CocoonFilter.java:72)
at com.evermind.server.http.ey.xv(JAX, Compiled Code)
at com.evermind.server.http.ey.su(JAX)
at com.evermind.server.http.ef.s1(JAX, Compiled Code)
at com.evermind.server.http.ef.do(JAX, Compiled Code)
at com.evermind.util.f.run(JAX, Compiled Code)

at
org.apache.cocoon.processor.xsp.XSPProcessor.init(XSPProcessor.java,
Compiled Code)
at
org.apache.cocoon.framework.Manager.create(Manager.java:109)
at org.apache.cocoon.framework.Router.init(Router.java,
Compiled Code)
at
org.apache.cocoon.framework.Manager.create(Manager.java:109)
at org.apache.cocoon.Engine.(Engine.java:179)
at org.apache.cocoon.Engine.getInstance(Engine.java:232)
at org.apache.cocoon.Cocoon.init(Cocoon.java, Compiled Code)
at
com.orionsupport.cocoon.CocoonServlet.init(CocoonServlet.java:52)
at com.evermind.server.http.HttpApplication.w1(JAX)
at com.evermind.server.http.HttpApplication.wj(JAX)
at com.evermind.server.http.HttpApplication.w6(JAX)
at
com.evermind.server.http.HttpApplication.getNamedDispatcher(JAX)
at
com.orionsupport.cocoon.CocoonFilter.cocoonDispatcher(CocoonFilter.java:99)
at
com.orionsupport.cocoon.CocoonFilter.doFilter(CocoonFilter.java:72)
at com.evermind.server.http.ey.xv(JAX, Compiled Code)
at com.evermind.server.http.ey.su(JAX)
at com.evermind.server.http.ef.s1(JAX, Compiled Code)
at com.evermind.server.http.ef.do(JAX, Compiled Code)
at com.evermind.util.f.run(JAX, Compiled Code)


Has anyone found a way to solve this?  Any hints?  I'm on the verge of
trying a different app server to get this to fly, but I really don't want to
switch away from Orion.

Thanks in advance,
- Bob
Web Developer
VisionTek

Re: Intro to Orion Tutorial

[Geoff Marshall]

Awesome, now if someone can translate it into Linux...
-- 

-Geoff Marshall, Director of Development

...
t e r r a s c o p e  (415) 951-4944
54 Mint Street, Suite 110 direct (415) 625-0349
San Francisco, CA  94103 fax (415) 625-0306
...

Orion Tutorial, Parts 1 and 2

[James Halloran]

Hello Orion community,

I cleaned up the tutorial I posted here a few days ago, and I added a Part 2 
that explains connecting to Oracle.  The only tools you need to use are 
javac, jar, and deploytool.  You won't need to write any XML files either, 
aside from adding lines the Orion config files.  I hope these guides will be 
useful for newcomers to Orion, or even J2EE.

http://www.4degreez.com/intro_part_1.html
http://www.4degreez.com/intro_part_2.html

I think everything will work properly, but it's possible that there is a 
mistake or two in there so let me know if you find any.  If someone is able 
to follow through it and get it to work, I'd love to hear about it.

In a few days, I'll see about getting it posted at orionsupport.
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: Database schema type mappings

[Chad Stansbury]

Actually, a more proper way is to indicate to the compiler that you want
long arithmetic by writing:

long millisInMonth = 1000L * 60L * 60L * 24L * 30L

Oh, and by the way, this is not really correct since you're assuming 30 days
in a month.  You should use the Calendar to figure out how many millis a
given month actually has since this varies by month and year.

- Original Message -
From: Jeff Schnitzer <[EMAIL PROTECTED]>
To: Orion-Interest <[EMAIL PROTECTED]>
Sent: Thursday, March 01, 2001 3:50 AM
Subject: RE: Database schema type mappings


> Yes, it fits into a long, but by default constants like
>
> 1000 * 60 * 60 * 24 * 30
>
> are ints, so the arithmetic is done using int math.  Inconveniently, the
> value of that expression is (slightly) greater than Integer.MAX_VALUE so
> overflow occurs.  Thus the negative value which gets assigned to
> millisInMonth.
>
> The fix is to force long math:
>
> long millisInMonth = (long)1000 * 60 * 60 * 24 * 30;
>
> This should probably go in some sort of Java-puzzle magazine article.
> :-)
>
> Jeff
>
> >-Original Message-
> >From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
> >Sent: Thursday, March 01, 2001 1:09 AM
> >To: Orion-Interest
> >Subject: RE: Database schema type mappings
> >
> >
> >Jeff, about the bug you mention... that sounds very strange to
> >me and it
> >sure should not have anything to do with byte size, I think. The value
> >millisInMonth easily fits into a long... So if you have a long
> >representing
> >the current time milliseconds and subtract one month of
> >milliseconds, yes,
> >that should definately produce a time last month.
> >
> >I would like to know if I am wrong in this assumption or what
> >the bug REALLY
> >was about (?)
> >
> >R.
> >
> >-Original Message-
> >From: [EMAIL PROTECTED]
> >[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff
> >Schnitzer
> >Sent: 1. marts 2001 02:38
> >To: Orion-Interest
> >Subject: RE: Database schema type mappings
> >
> >
> >You're thinking C++.
> >
> >In Java:
> >
> >A long is 8 bytes, always.
> >An int is 4 bytes, always.
> >
> >The byte-orders are fixed independent of the hardware, too.
> >
> >Speaking of byte size, here's something I found amusing (and annoying):
> >
> > long millisInMonth = 1000 * 60 * 60 * 24 * 30;
> > Date thirtyDaysAgo = new Date();
> > thirtyDaysAgo.setTime(thirtyDaysAgo.getTime() - millisInMonth);
> >
> >This actually produces a date in the FUTURE!
> >
> >It took me a while to hunt down this bug because it had really wierd
> >effects on my application.
> >
> >Jeff
> >
> >>-Original Message-
> >>From: Michael A Third [mailto:[EMAIL PROTECTED]]
> >>Sent: Wednesday, February 28, 2001 11:02 AM
> >>To: Orion-Interest
> >>Subject: RE: Database schema type mappings
> >>
> >>
> >>Randahl,
> >>
> >>We use the primitive long for all of our primary keys for a couple of
> >>reasons:
> >>* primary keys can't be null so there isn't a need for Long
> >>(or Integer)
> >>* long's are always 4 bytes no matter what the CPU (32bit vs
> >>64bit), which
> >>is currently not a problem but could be when Itanium platforms
> >>come out.
> >>int's depend on the CPU's native integer type which happens to
> >>be 32bits on
> >>ix86 architectures.
> >>
> >>Michael Third
> >>Chief Software Architect
> >>parts.com
> >>
> >>
> >>-Original Message-
> >>From: [EMAIL PROTECTED]
> >>[mailto:[EMAIL PROTECTED]]On Behalf Of Randahl Fink
> >>Isaksen
> >>Sent: Wednesday, February 28, 2001 10:02 AM
> >>To: Orion-Interest
> >>Subject: Database schema type mappings
> >>
> >>
> >>If you look at the database schema in
> >>"orion/config/database-schemas/hypersonic.xml" it looks as if
> >>it is mapping
> >>between the primitive java type "int" and the corresponding
> >>database type
> >>"int":
> >>.
> >>
> >>In my EJBs my primary keys and other attributes are of type
> >>Integer. Since
> >>there is no mapping for class Integer one could think that
> >>Integers would be
> >>mapped to VARBINARY. Luckily my integers are mapped to the
> >>database type
> >>"int", but this makes me ask two questions:
> >>
> >>1. Why is Integers automatically converted to int by Orion -
> >>and is this a
> >>standard EJB convention?
> >>2. Would it be legal to have a primary key of the primitive type "int"
> >>instead of Integer?
> >>
> >>
> >>Yours
> >>
> >>Randahl
> >>
> >>
> >>
> >
> >
> >
>
>

RE: java.lang.NullPointerException in JMS

[Edoardo Comar]

Title: java.lang.NullPointerException in JMS



I got the same problem. 
connection.start() throws an NPE
Search for JMS in this 
list and you'll find something.
 
I couldn't solve it - I 
logged the fact as blocking in bugzilla and 
had to switch to weblogic for the time being.
 
Edo
 

  -Original 
  Message-From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]]On Behalf Of Matt 
  SimmersonSent: 01 March 2001 14:19To: 
  Orion-InterestSubject: java.lang.NullPointerException in 
  JMS
  Hi 
  I've created my own topic-connection-factory and own topic in 
  jms.xml  
     
  JMS Logger  
  I have referenced these in my application-client.xml as 
  
        App 
  Logger      
      
      
  jms/LoggerTopicConnectionFactory 
      
      
  javax.jms.TopicConnectionFactory 
      
      
  Container      
      
       
      
  jms/ApplicationLoggerTopic 
      
      
  javax.jms.Topic     
      
  Container      
    
  I reference these in my code, and print out the topic name 
  which display "Demo Topic" !!! 
  TopicConnectionFactory connFactory = 
  (TopicConnectionFactory)new 
  InitialContext().lookup("java:comp/env/jms/LoggerTopicConnectionFactory");
  this.connection = connFactory.createTopicConnection(); 
  this.loggerTopic = (Topic)new 
  InitialContext().lookup("java:comp/env/jms/ApplicationLoggerTopic"); 
  
  When the code executes connection.start() I get the following 
  error. java.lang.NullPointerException     at 
  java.io.DataOutputStream.writeUTF(DataOutputStream.java:329)     at 
  java.io.DataOutputStream.writeUTF(DataOutputStream.java:306)     at 
  com.evermind.server.jms.cj.(JAX)     at 
  com.evermind.server.jms.b8.start(JAX)     at 
  AppLogger.LoggerListeners.JMSLoggerSubscriber.initSubscriber(JMSLogge 
  rSubscriber.java:116)     at 
  AppLogger.LoggerListeners.JMSLoggerSubscriber.(JMSLoggerSubscri 
  ber.java:76)     at 
  AppLogger.LoggerListeners.JMSLoggerSubscriber.main(JMSLoggerSubscribe 
  r.java:33) 
  Has anyone any idea what I've missed, or know how to resolve 
  this. 
  Cheers 
  Matt 
  Matt Simmerson IT Consultant 
  smart421 - Smart solutions for the 21st century 
    http://www.smart421.com Wap Site: wap.smart421.com Tel:   
  01473 408720 Fax:  01473 408753 Mob: 07759 258083 email: 
  [EMAIL PROTECTED] 
  Information contained in this e-mail and any attachments is 
  confidential and intended for the use of the addressee 
  only.  Dissemination, distribution, copying or 
  use of this communication without prior permission of 
  the addressee is strictly prohibited. If you have received this 
  transmission in error, please advise the originator by reply 
  e-mail and delete it. Thank you. 

RE: CMP 2.0

[Randahl Fink Isaksen]

Title: RE: CMP 2.0



You 
are right, Matt, but I am afraid I consider that irrellevant. When the 
developer deploys his application on Orion, he should not worry 
about how Orion builds the beans and whether it uses the JDK or 
anything else in the process of doing so - he should just expect it to do its 
work and should an error occur along the way he should *certainly* expect 
it to report back to him. Anything else is a serious bug which makes it _very_ 
hard to develop bug free applications.
 
Yours
 
Randahl

  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]]On Behalf Of Matt 
  SimmersonSent: 1. marts 2001 14:54To: 
  Orion-InterestSubject: RE: CMP 2.0
  But its java that compiles, not Orion. 
  -Original Message- From: 
  Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 01, 2001 9:19 AM To: 
  Orion-Interest Subject: RE: CMP 2.0 
  As I just posted, Jeff. The error was due to the fact that I 
  had declared my primary keys as Integer but I returned 
  the primitive type int from my ejbCreate methods. As 
  soon as I changed this, everything worked fine. I am (to put it mildly) very surprised that Orion did _not_ give me a 
  compile time error when I deployed - it just crashed 
  instead or ran without working correctly. 
  Yes I know who introduced the bug, but since I think Orion is 
  a magnificent piece of software I would never had 
  expected it to NOT report this compile time 
  error. 
  Randahl 
  -Original Message- From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On 
  Behalf Of Jeff Schnitzer Sent: 1. marts 2001 
  02:42 To: Orion-Interest Subject: RE: CMP 2.0 
  ? 
  I have all my transactional behavior defined as NotSupported 
  and I use EJB 2.0 container managed relationships 
  without issue.  I don't currently need 
  transactions for what I'm doing. 
  Randahl, have you examined the contents of the database tables 
  and the orion-ejb-jar.xml closely? 
  Jeff 
  -Original Message- From: Tim 
  Drury [mailto:[EMAIL PROTECTED]] 
  Sent: Wednesday, February 28, 2001 8:34 AM To: Orion-Interest Subject: RE: CMP 2.0 
  
  I've been out for a few days, so it this has been 
  answered, sorry for the repost. 
  This sounds like you didn't set the transactional 
  behavior in ejb-jar.xml as "required".  There is 
  no default behavior in the spec so it is up to the 
  container to decide what the default behavior 
  is.  I know in Weblogic, transactions default to 
  "supports" (I think).  In any event, the entities are not stored in the database unless you mark them as "required".  Orion may be doing the same thing. 
  -tim 
  > -Original Message- > 
  From: Randahl Fink Isaksen [ mailto:[EMAIL PROTECTED]  
  ] > Sent: Monday, February 26, 2001 5:29 AM 
  > To: Orion-Interest > Subject: 
  CMP 2.0 > > 
  > Would somebody please confirm that they have been able 
  to use CMP 2.0 > relationships on Orion, that they 
  have seen them get stored > in the database 
  > AND brought back into main memory correctly after a 
  restart > of the server. > > When I create a relationship it works 
  fine until I restart - > I simply can't 
  > make Orion restore my relationships from the keys it 
  stores > in the database. > If I try the getX() / method of a cmr property it works - but 
  after a > restart it returns null. > > > 
  R. > > > 

RE: Starting threads not permitted in servlet?

[Andre Vanha]

As far as I know, the EJB spec specifically forbids creating threads Sec
18.1.2.  The servlet spec 2.2 Sec 1.2 says:
"For example, high end application servers may limit certain action, such as
the creation of
a Thread object, to insure that other components of the container are not
negatively impacted."

Andre

-Original Message-
From: Falk Langhammer [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 01, 2001 6:38 AM
To: Orion-Interest
Subject: Re: Starting threads not permitted in servlet?


> Somebody on this list said that you're not allowed to start threads inside
a
> servlet container. Is this really in the spec (this was claimed), or is it
> implementation-dependent?

I am not sure for the web container. But the situation is even fuzzy for an
EJB container. I believe that in Orion, there isn't much difference between
the two (except for the RMI and wrapper subclasses).

Here is what the Borland BAS4.5 spec says about the EJB programming
restrictions:

--->8---
Verifies in accordance with pedantic EJB 1.1 rules. There are four warnings
that have been classified as pedantic:
-- Throwing java.rmi.RemoteException from a bean method is deprecated.
-- Static fields in the bean class must be final. (This is actually a useful
rule, which is violated by the Java compiler.)
-- The primary key type must define the equals(Object) method.
-- The primary key type must define the hashCode() method.
The behavior of the verifier is that, by default, these rules are ignored.
Choosing the Pedantic option causes violations of these rules to issue
warnings. For deployment purposes, warnings are ignored, meaning that you
can go ahead and deploy beans which have warnings. However, you cannot
deploy beans which have errors.
Keep in mind the following about pedantic verification:
1) Not actually required by our runtime, meaning that your code will work as
is.
2) Questionable altogether, and may well be eliminated from the EJB
specification when people realize how annoying they are.
3) Violated in almost every EJB program ever written, both in our product
and in all the various books ever written about EJB.
--->8---

>>> Especially, note point 3)  :-))

-
Below is a list of programming restrictions defined in the EJB 1.1
specification.

An enterprise bean is not allowed to manage threads and thread groups. It
should not start new threads or resume suspended threads, nor should it
terminate or suspend the running thread. In addition, an enterprise bean
should not change a thread's priority or its name.
An enterprise bean is not allowed to use read/write static fields. Using
read-only static fields is allowed. Therefore, all static fields must be
declared as final.
An enterprise bean is not allowed to use thread synchronization primitives
to synchronize the execution of multiple instances.
An enterprise bean must not use the Java AWT functionality to output
information to a display or to accept information from a keyboard.
An enterprise bean should not use the java.io package to access files and
directories in the file system.
An enterprise bean should refrain from using sockets; in particularly, the
bean should not listen on a socket, accept connections on a socket, or use a
socket for multicast. In addition, it should not set the socket factory used
by ServerSocket, Socket, or the stream handler factory used by URL.
An enterprise bean must not access classes or packages, or attempt to obtain
information about classes, in a manner normally disallowed by the Java
programming language or if the classes are normally unavailable to the
enterprise bean.
An enterprise bean must not access the runtime environment functions
normally handled by the container--create a class loader or access or change
its context, set or create a security manager, stop the JVM, change input,
output, or error streams.
An enterprise bean must not obtain security policy information for a
particular code source as this would compromise security.
An enterprise bean must not load a native library.
An enterprise bean must not define a class in a package, as this is a
function reserved for the container for security reasons.
An enterprise bean must not use the subclass and object substitution
features of the Java Serialization Protocol.
An enterprise bean should be careful if passing this as an argument or
method result. It is safer for the bean to pass the result of
SessionContext.getEJBObject() or EntityContext.getEJBObject().
An enterprise bean is not allowed to access or modify security configuration
objects. For example, it is not allowed to change its
java.security.Identity. Any such attempt will result in the
java.security.SecurityException being thrown.

RE: referring to a jar from an ejb-jar file/directory?

[Andre Vanha]

Gary,
you can also add a library entry to your orion-application.xml.


I use this in my app to get access to third party libraries.

I'm glad to hear the manifest method works.  I've tried it before, but was
never able to get it working.  However, I have a question concerning WAR
files.  The spec says that the manifest classpath is only used by JAR files.
If you use the separately JARed classes from servlets or JSP can the class
loader still find them?  Or more generally, If I have an J2EE application
that contains one EJB module and one WAR module, does the web-app class
loader automatically include the ejb-module in it's classpath?

Since the spec is somewhat vague in this area, a little documentation about
Orion's class loader/class path structure would really help.

Andre


-Original Message-
From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 28, 2001 11:27 PM
To: Orion-Interest
Subject: RE: referring to a jar from an ejb-jar file/directory?


Running it out of a directory I'm not sure the MANIFEST Class-Path: will
work.

I know if you use a JAR, it will work that way. It's the way the OSCore
library works, http://www.opensymphony.com/oscore

-mike

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Gary Shea
> Sent: Thursday, March 01, 2001 4:35 PM
> To: Orion-Interest
> Subject: referring to a jar from an ejb-jar file/directory?
>
>
> I have an ejb application running under orion.  I want to restructure
> the code so that some common code is put into a jar.  The problem is
> that I can't figure out a way, short of putting the jar in the orion/lib
> directory, to make the contents of the jar available to the ejb side of
> the application.  The EJB-2.0-pfd spec says:
>
> The ejb-jar file must also contain, either by inclusion or
> by reference, the class files for all the classes and interfaces
> that each enterprise bean class and the remote and home interfaces
> depend on, except J2EE and J2SE classes. (page 486)
>
> Well, what does 'reference' mean?  The only hint I have found is:
>
> An ejb-jar file does not have to physically include the class files
> if the classes are defined in another jar file that is named in the
> Class-Path attribute in the Manifest file of the referencing ejb-jar
> file or in the transitive closure of such Class-Path references.
> (page 487)
>
> Well, I'm going to try creating a manifest file with a Class-Path in it,
> but since I'm running out of a directory, not an actual ejb-jar file,
> I really doubt this is going to work!
>
> Any hints would be greatly appreciated...
>
>   Gary
>
>
>

need help getting started

[John de la Garza]

I have been using tomcat for some time now and am having issues with it...


I am thinking about using Orion.  I don't do any ejb stuff and only need a
servlet container and web server.

I am having trouble using formbased security.  I couldn't get it to work
with the users set up in the principals file.  When I would go to a
protected area I would just get a message saying 'not allowed here' or
something like that but I would not get prompted for a pw username.


I actually don't want to use the principals file but have the usernames and
passwds in a data base.

Can anyone here refer me to some documentation on this?

RE: Orion with tomcat!!!

[John de la Garza]

Why would you use tomcat/apache and Orion?  Can't Orion alone handle that?

I'm just trying to understand Orion at this point.  I'm looking to move from
tomcat to another servlet container.



> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Alex 'Kazuma'
> Garbagnati
> Sent: Wednesday, February 28, 2001 5:16 PM
> To: Orion-Interest
> Subject: Re: Orion with tomcat!!!
>
>
>
> >I know it has been mentioned in serveral times.
> >However, I could not make Orion as EJB server work with
> Apache & Tomcat.
> >A servlet is placed to access ejb at tomcat's
> WEB-INF/classes directory,
> >along with application-client.xml under META-INF directory.
>
> That's strange. I've built two different applications, both
> using Orion as
> an app server and Tomcat and Resin as servlet containers,
> both with Apache
> as a web server.
> In both application i had no ejb references in the web.xml and i have
> absolutely no application-client.xml.
>
> I've just built war files with the required lib, classes, jsps and
> servlets... few parameters into the web.xml and that's it.
>
>
> It looks from your stack trace that the problem is that the
> application
> cannot connect to the application server at all...
> I'm afraid that you're using the wrong port this unless you have
> changed the port number in the rmi.xml file from the default
> (23791) to the
> one you've set in the environment for the intial context (800).
>
>  Best Regards,
>  Kazuma
>
>
> Cos'e' il genio. E' fantasia intuizione, colpo d'occhio e velocita'
> d'esecuzione. (Amici Miei)
>
> ---
> Alessandro A. 'Kazuma' Garbagnati
> http://www.kazuma.net/   ICQ UIN: 1600386
> Mountain View, CA, 94043 - USA
>
>
>

Re: Struts (was: I switch from X to Orion because: )

[mascolino . mr]

The reason for reimplementing ResourceBundle as MessageResources is that
ResourceBundle is not Serializable.  Some containers, notable WebLogic 6, have
issues with non-serializable objects being stored in things like the application
and session context.  Its also very important that you only throw Serializable
things in there espacially if you plan on using the  tag in
your web.xml.

mark

Mark R Mascolino
The Procter & Gamble Co.
[EMAIL PROTECTED]



 Internet Mail Message  
 Received from host:



   
   
  "Jeff Schnitzer" 
   
 <[EMAIL PROTECTED]>To:  Orion-Interest  
   
  Sent by:<[EMAIL PROTECTED]> 
   
  [EMAIL PROTECTED]cc: (bcc: Mark 
Mascolino-MR/PGI)
  Subject: Struts (was: I 
switch from X to
 02/28/01 08:25 PMOrion because: ) 
   
  Please respond to Orion-Interest 
   
   
   
   
   




This subject is especially timely for me because I just finished
evaluating both WebWork and Struts.  I decided to go with WebWork.  It
wasn't so much that I was drawn to WebWork's technological coolness -
there are some neat ideas there, but I think most could be adapted into
Struts with a little effort.  The problem was that when I looked deeply
into Struts, I didn't like what I saw.

I spent a *lot* of time wavering; on one hand, Struts has a solid user
community and good javadocs, on the other hand, WebWork is simpler and
easier to teach future members of the team.  I kept switching my favor
back and forth when I discovered something new I did or didn't like.
What finally pushed me over the edge was my experience hunting down the
problem preventing Struts from working with Orion out of the box.
Here's the story:

If you've ever tried loading the Struts 1.0 example app, you are
immediately confounded by missing resource errors.  There is a lot of
complaint in the Orion and Struts archives about this, but the closest
anyone has come to nailing it down is this message:

http://www.mail-archive.com/struts-user@jakarta.apache.org/msg00582.html

in which the principal author of Struts, Craig, implies that Orion's
classloader has a problem preventing it from working with the standard
JDK ResourceBundle.  I knew there was something wrong with this because
WebWork uses ResourceBundle without issue.

So I looked through Struts' source to see how it might be using
ResourceBundle differently, and what I discovered is that Struts doesn't
use ResourceBundle at all!  In fact, Struts has a whole homebrewed
framework for handling properties which mirrors the ResourceBundle API
but doesn't use any of its classes or interfaces.  There are javadoc
comments to the effect that the Struts code should be faster than
ResourceBundles, but looking at the JDK 1.3 source code, both frameworks
seem to be doing pretty much the same thing.

For those curious, the actual problem with Orion is that Struts uses
ClassLoader.getResourceAsStream() to build the Properties object, and (I
checked the decompiled code) the Orion classloader does not implement
getResourceAsStream().  Orion's fault, and logged as bug #340.

But why re-invent the wheel?!?  The JDK provides resource management for
us!  Even if the Struts code was slightly faster (which I doubt), any
performance gain is going to be negligable compared to the amount of
time spent processing taglibs, etc.  I can't believe that whoever wrote
the Struts MessageResources classes ever bothered to run the code
through a profiler to find out where the real bottlenecks are.  All this
extra code and duplicated infrastructure is nothing but an opportunity
for more bugs, IMHO.

At this point I decided to go with WebWork.  It is certainly not without
issues as well, but I'm very happy with the results.  And I am finding
that in a framework this simple, fundamental changes are easy to make.

I could elaborate on the differences between WebWork and Struts if
anyone is really interested.  If you're still writing JSP-centric
applications, you *really* should look into an MVC framework.

Jeff

>-Original Message-
>From: Arved Sandstrom [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, February 28, 2001

RE: Capturing the output of a JSP page as HTML

[elephantwalker]

I think you can use a Filter to do that. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, March 01, 2001 8:32 AM
To: Orion-Interest
Subject: Capturing the output of a JSP page as HTML


Can anyone tell me if this is possible.  I have a JSP page that contains
information about an order that was just entered (Essentially a
confirmation page).  What I want to do is somehow intercept the output
stream inside the JSP page and write it to a file, as plain html, which I
will later attach to an email and send to someone.

Thanks,
Andy

ejbload

[Peng Yong]

I have a BMP called UserEJB.

when a client call the EJB by findByPrimaryKey, the EJB only call
ejbload at the first time. then it is not synchronized with the DB.

the EJB specification said BMP should called ejbload every time when
a transaction begin.

How can i ensure ejbload called every time?

--
Peng Yong Email: [EMAIL PROTECTED]
Bentium Ltd.  URL: http://www.cn99.com

RE: signoff EJB-INTEREST

[Juan Lorandi (Chile)]

should you use the form in http://archives.java.sun.com ???
if you wnat to unsubscribe from EJB-INTEREST, that is

> -Original Message-
> From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 01, 2001 5:53 AM
> To: Orion-Interest
> Subject: RE: signoff EJB-INTEREST
> 
> 
> Please use the form at www.orionserver.com
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Lu, Michael
> Sent: 28. februar 2001 20:47
> To: Orion-Interest
> Subject: signoff EJB-INTEREST
> 
> 
> signoff EJB-INTEREST
> 
> 

RE: login security include file

[Juan Lorandi (Chile)]

and  closes the outputstream 
too

  -Original Message-From: Manne Fagerlind 
  [mailto:[EMAIL PROTECTED]]Sent: Thursday, March 01, 
  2001 6:20 AMTo: Orion-InterestSubject: RE: login 
  security include file
  Strangely enough,  always flushes 
  the writer - i.e. the flush="false" is ignored. This is in the JSP 1.1 spec. 
  Don't ask me why...
   
  /Manne
  
-Original Message-From: Vaskin Kissoyan 
[mailto:[EMAIL PROTECTED]]Sent: 28 February 2001 
22:36To: Orion-InterestSubject: login security include 
file
I'm trying to do a 
response.sendRedirect() from an include file 
 and wanted to avoid doing a directive.include 
(preparser), 
 
I keep getting "Response has already been 
committed, be sure not to write to the OutputStream or to trigger a commit 
due to any other action before calling this method."
 
I have been very careful as to put this include 
at the very top of the file, and to specify autoFlush=false and flush=false 
on the include tag.
 
Again, the intention of this include file would 
be to be place at the top of the jsp file to secure it by redirecting to a 
login page if credentials in a session based UserBean do not allow access to 
the page for some reason.
 
-Vaskin

RE: Database schema type mappings

[Michael A Third]

Correction:
The last bullet should be:
* The home interface must always include the findByPrimaryKey method, which
is always a single-object finder. The method must declare the primary key
class as the method argument.

Michael
-Original Message-
From: Michael A Third [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 01, 2001 11:46 AM
To: Orion-Interest
Subject: RE: Database schema type mappings


I went digging through the EJB 1.1 specification, and it doesn't
specifically say you can't use primitive types, but it does say they primary
key class needs to be serializable.

I have created a number of EJB's using the primitive long as the primary key
and have had no problems using them.  So I went back and looked at the
deployment descriptor (it was originally generated by EJBMaker) and noticed
that they  was "java.lang.Long".  All of the EJB class files
are using the primitive type.  It appears that at least Orion maps them
intelligently(if not according to spec).

On closer examination of the EJB 2.0 spec, I found these statements.

* The primary key type must be a legal Value Type in RMI-IIOP. (this
includes long)
* The container must be able to manipulate the primary key type of an entity
bean.
* Primary key (must be a class or type?) that maps to a single field in the
entity bean class.
* The (create) method must declare the primary key class as the method
argument.

According to this statements, the primary key class and the primary key type
don't necessarily have to be the same.  Orion does allow the create method
to accept the primary key type as opposed to the class, which isn't
according to spec.

Thanks,

Michael

PS - After my response on Java primitive data-types, I should probably keep
my mouth shut for a while :)


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer
Sent: Thursday, March 01, 2001 6:12 AM
To: Orion-Interest
Subject: RE: Database schema type mappings


It's at the bottom of page 159 of Richard Monson-Haefel's _Enterprise
Java Beans, 2nd Ed_:  "Although primary keys can be primitive wrappers
(Integer, Double, Long, etc.), primary keys cannot be primitive types
(int, double, long, etc.)"

I wasn't able to locate an explicit statement in the spec in my quick
scan, but the spec always refers to the primary key as the "primary key
class" and the deployment descriptor element is "prim-key-class".  This
is further reinforced by the comments in the DTD.

It makes sense, because EntityContext.getPrimaryKey() returns an Object.
Thus all PKs *must* be Objects.

About question #1:  I doubt there is any explicit requirement in the
spec that Integers be converted to ints in the database.  In fact, the
spec doesn't require a relational database; that's simply an
implementation detail.  Still, I doubt you will find *any* appservers
which serialize Integer keys as blobs - although it would work, the
performance penalty would be severe.

Jeff

>-Original Message-
>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 01, 2001 1:22 AM
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>Thanks for the reply Jeff. Know I have two replies: One saying
>primary keys
>can be primitive types and one that says they can't.
>I am really looking forward to hearing your arguments, gentlemen ;-)
>
>BTW, Jeff: Your answer to question number 1 - do you have that from the
>specification, or...
>
>Randahl
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff
>Schnitzer
>Sent: 1. marts 2001 02:52
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>>
>>1. Why is Integers automatically converted to int by Orion -
>>and is this a
>>standard EJB convention?
>
>Yes.  All the class representations of the primitive types should work
>that way.
>
>>2. Would it be legal to have a primary key of the primitive type "int"
>>instead of Integer?
>
>No.  Primary keys must be Objects.  This makes sense because
>EntityContext.getPrimaryKey() returns an Object.
>
>Jeff
>
>
>

RE: Database schema type mappings

[Michael A Third]

I went digging through the EJB 1.1 specification, and it doesn't
specifically say you can't use primitive types, but it does say they primary
key class needs to be serializable.

I have created a number of EJB's using the primitive long as the primary key
and have had no problems using them.  So I went back and looked at the
deployment descriptor (it was originally generated by EJBMaker) and noticed
that they  was "java.lang.Long".  All of the EJB class files
are using the primitive type.  It appears that at least Orion maps them
intelligently(if not according to spec).

On closer examination of the EJB 2.0 spec, I found these statements.

* The primary key type must be a legal Value Type in RMI-IIOP. (this
includes long)
* The container must be able to manipulate the primary key type of an entity
bean.
* Primary key (must be a class or type?) that maps to a single field in the
entity bean class.
* The (create) method must declare the primary key class as the method
argument.

According to this statements, the primary key class and the primary key type
don't necessarily have to be the same.  Orion does allow the create method
to accept the primary key type as opposed to the class, which isn't
according to spec.

Thanks,

Michael

PS - After my response on Java primitive data-types, I should probably keep
my mouth shut for a while :)


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer
Sent: Thursday, March 01, 2001 6:12 AM
To: Orion-Interest
Subject: RE: Database schema type mappings


It's at the bottom of page 159 of Richard Monson-Haefel's _Enterprise
Java Beans, 2nd Ed_:  "Although primary keys can be primitive wrappers
(Integer, Double, Long, etc.), primary keys cannot be primitive types
(int, double, long, etc.)"

I wasn't able to locate an explicit statement in the spec in my quick
scan, but the spec always refers to the primary key as the "primary key
class" and the deployment descriptor element is "prim-key-class".  This
is further reinforced by the comments in the DTD.

It makes sense, because EntityContext.getPrimaryKey() returns an Object.
Thus all PKs *must* be Objects.

About question #1:  I doubt there is any explicit requirement in the
spec that Integers be converted to ints in the database.  In fact, the
spec doesn't require a relational database; that's simply an
implementation detail.  Still, I doubt you will find *any* appservers
which serialize Integer keys as blobs - although it would work, the
performance penalty would be severe.

Jeff

>-Original Message-
>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 01, 2001 1:22 AM
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>Thanks for the reply Jeff. Know I have two replies: One saying
>primary keys
>can be primitive types and one that says they can't.
>I am really looking forward to hearing your arguments, gentlemen ;-)
>
>BTW, Jeff: Your answer to question number 1 - do you have that from the
>specification, or...
>
>Randahl
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff
>Schnitzer
>Sent: 1. marts 2001 02:52
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>>
>>1. Why is Integers automatically converted to int by Orion -
>>and is this a
>>standard EJB convention?
>
>Yes.  All the class representations of the primitive types should work
>that way.
>
>>2. Would it be legal to have a primary key of the primitive type "int"
>>instead of Integer?
>
>No.  Primary keys must be Objects.  This makes sense because
>EntityContext.getPrimaryKey() returns an Object.
>
>Jeff
>
>
>

Capturing the output of a JSP page as HTML

[APapada]

Can anyone tell me if this is possible.  I have a JSP page that contains
information about an order that was just entered (Essentially a
confirmation page).  What I want to do is somehow intercept the output
stream inside the JSP page and write it to a file, as plain html, which I
will later attach to an email and send to someone.

Thanks,
Andy

RE: Database schema type mappings

[Randahl Fink Isaksen]

Jeff wrote:
> This should probably go in some sort of Java-puzzle magazine article. :-)

ROFL ! - I am glad you shared that top-secret-hard-to-find-under-cover-bug
experience with us; I too might have used a lot of time finding out... in
fact I think most developers would.

Randahl


>-Original Message-
>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 01, 2001 1:09 AM
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>Jeff, about the bug you mention... that sounds very strange to
>me and it
>sure should not have anything to do with byte size, I think. The value
>millisInMonth easily fits into a long... So if you have a long
>representing
>the current time milliseconds and subtract one month of
>milliseconds, yes,
>that should definately produce a time last month.
>
>I would like to know if I am wrong in this assumption or what
>the bug REALLY
>was about (?)
>
>R.
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff
>Schnitzer
>Sent: 1. marts 2001 02:38
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>You're thinking C++.
>
>In Java:
>
>A long is 8 bytes, always.
>An int is 4 bytes, always.
>
>The byte-orders are fixed independent of the hardware, too.
>
>Speaking of byte size, here's something I found amusing (and annoying):
>
>   long millisInMonth = 1000 * 60 * 60 * 24 * 30;
>   Date thirtyDaysAgo = new Date();
>   thirtyDaysAgo.setTime(thirtyDaysAgo.getTime() - millisInMonth);
>
>This actually produces a date in the FUTURE!
>
>It took me a while to hunt down this bug because it had really wierd
>effects on my application.
>
>Jeff
>
>>-Original Message-
>>From: Michael A Third [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, February 28, 2001 11:02 AM
>>To: Orion-Interest
>>Subject: RE: Database schema type mappings
>>
>>
>>Randahl,
>>
>>We use the primitive long for all of our primary keys for a couple of
>>reasons:
>>* primary keys can't be null so there isn't a need for Long
>>(or Integer)
>>* long's are always 4 bytes no matter what the CPU (32bit vs
>>64bit), which
>>is currently not a problem but could be when Itanium platforms
>>come out.
>>int's depend on the CPU's native integer type which happens to
>>be 32bits on
>>ix86 architectures.
>>
>>Michael Third
>>Chief Software Architect
>>parts.com
>>
>>
>>-Original Message-
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED]]On Behalf Of Randahl Fink
>>Isaksen
>>Sent: Wednesday, February 28, 2001 10:02 AM
>>To: Orion-Interest
>>Subject: Database schema type mappings
>>
>>
>>If you look at the database schema in
>>"orion/config/database-schemas/hypersonic.xml" it looks as if
>>it is mapping
>>between the primitive java type "int" and the corresponding
>>database type
>>"int":
>>.
>>
>>In my EJBs my primary keys and other attributes are of type
>>Integer. Since
>>there is no mapping for class Integer one could think that
>>Integers would be
>>mapped to VARBINARY. Luckily my integers are mapped to the
>>database type
>>"int", but this makes me ask two questions:
>>
>>1. Why is Integers automatically converted to int by Orion -
>>and is this a
>>standard EJB convention?
>>2. Would it be legal to have a primary key of the primitive type "int"
>>instead of Integer?
>>
>>
>>Yours
>>
>>Randahl
>>
>>
>>
>
>
>

java.lang.NullPointerException in JMS

[Matt Simmerson]

Title: java.lang.NullPointerException in JMS





Hi


I've created my own topic-connection-factory and own topic in jms.xml 




  JMS Logger



I have referenced these in my application-client.xml as 


 
    App Logger
    
        jms/LoggerTopicConnectionFactory
        javax.jms.TopicConnectionFactory
        Container
    
    
        jms/ApplicationLoggerTopic
        javax.jms.Topic
        Container
    
  


I reference these in my code, and print out the topic name which display "Demo Topic" !!! 


TopicConnectionFactory connFactory = (TopicConnectionFactory)new InitialContext().lookup("java:comp/env/jms/LoggerTopicConnectionFactory");

this.connection = connFactory.createTopicConnection();
this.loggerTopic = (Topic)new InitialContext().lookup("java:comp/env/jms/ApplicationLoggerTopic");


When the code executes connection.start() I get the following error.
java.lang.NullPointerException
    at java.io.DataOutputStream.writeUTF(DataOutputStream.java:329)
    at java.io.DataOutputStream.writeUTF(DataOutputStream.java:306)
    at com.evermind.server.jms.cj.(JAX)
    at com.evermind.server.jms.b8.start(JAX)
    at AppLogger.LoggerListeners.JMSLoggerSubscriber.initSubscriber(JMSLogge
rSubscriber.java:116)
    at AppLogger.LoggerListeners.JMSLoggerSubscriber.(JMSLoggerSubscri
ber.java:76)
    at AppLogger.LoggerListeners.JMSLoggerSubscriber.main(JMSLoggerSubscribe
r.java:33)


Has anyone any idea what I've missed, or know how to resolve this.


Cheers


Matt


Matt Simmerson
IT Consultant
smart421 - Smart solutions for the 21st century
 
http://www.smart421.com
Wap Site: wap.smart421.com
Tel:   01473 408720
Fax:  01473 408753
Mob: 07759 258083
email: [EMAIL PROTECTED]


Information contained in this e-mail and any attachments is confidential
and intended for the use of the addressee only.  Dissemination,
distribution, copying or use of this communication without prior permission
of the addressee is strictly prohibited. If you have received this
transmission in error, please advise the originator by reply e-mail and
delete it. Thank you.

RE: CMP 2.0

[Matt Simmerson]

Title: RE: CMP 2.0





But its java that compiles, not Orion.


-Original Message-
From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 01, 2001 9:19 AM
To: Orion-Interest
Subject: RE: CMP 2.0



As I just posted, Jeff. The error was due to the fact that I had declared my
primary keys as Integer but I returned the primitive type int from my
ejbCreate methods. As soon as I changed this, everything worked fine. I am
(to put it mildly) very surprised that Orion did _not_ give me a compile
time error when I deployed - it just crashed instead or ran without working
correctly.
Yes I know who introduced the bug, but since I think Orion is a magnificent
piece of software I would never had expected it to NOT report this compile
time error.



Randahl


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer
Sent: 1. marts 2001 02:42
To: Orion-Interest
Subject: RE: CMP 2.0



?


I have all my transactional behavior defined as NotSupported and I use
EJB 2.0 container managed relationships without issue.  I don't
currently need transactions for what I'm doing.


Randahl, have you examined the contents of the database tables and the
orion-ejb-jar.xml closely?


Jeff


-Original Message-
From: Tim Drury [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 28, 2001 8:34 AM
To: Orion-Interest
Subject: RE: CMP 2.0





I've been out for a few days, so it this has been answered,
sorry for the repost.


This sounds like you didn't set the transactional behavior
in ejb-jar.xml as "required".  There is no default behavior
in the spec so it is up to the container to decide what
the default behavior is.  I know in Weblogic, transactions
default to "supports" (I think).  In any event, the entities
are not stored in the database unless you mark them
as "required".  Orion may be doing the same thing.


-tim



> -Original Message-
> From: Randahl Fink Isaksen [ mailto:[EMAIL PROTECTED]
 ]
> Sent: Monday, February 26, 2001 5:29 AM
> To: Orion-Interest
> Subject: CMP 2.0
>
>
> Would somebody please confirm that they have been able to use CMP 2.0
> relationships on Orion, that they have seen them get stored
> in the database
> AND brought back into main memory correctly after a restart
> of the server.
>
> When I create a relationship it works fine until I restart -
> I simply can't
> make Orion restore my relationships from the keys it stores
> in the database.
> If I try the getX() / method of a cmr property it works - but after a
> restart it returns null.
>
>
> R.
>
>
>

RE: I switch from X to Orion because:

[Arved Sandstrom]

Hi, Mike

Any or all of the Apache products are open to criticism, just as any
software should be.

I guess my reaction to points like yours below would be:

(1) severe bloat: by what definition? The core JAR size? The distribution
size? The API size? For that matter, if we're talking APIs, the normal
developer using Xerces, for example, should be concerned with public APIs
like SAX and DOM. Exactly how are these different from anyone else's SAX or
DOM interfaces?;
(2) old JDKs: not sure I understand this one. Support for old JDKs? Well,
like I said before, not every real world developer has access to a 1.2+ JDK.
And the mission of Apache is not to support J2EE specifically;
(3) Bad spec conformance: on what basis? Not keeping up with the latest
specs as fast as you might like? Or declaring that they conform to spec
A12.3, and not in fact doing so? There's a difference;
(4) Appalling speed: you can always find a stripped down little product that
blazes through problem X. I use nanoxml from time to time for specific
problems, and it's fast as hell - does that mean that Xerces is then bad
because it's slower on the same problem? And a number of Apache products are
acknowledged as being the fastest. If I know that you had a hate-on for
Tomcat it would help clarify the discussion; blanket statements are
exceedingly unhelpful;
(5) Some sort of strange developer arrogance: OK, this could use some
clarification. But I sure as hell haven't seen it.

There have been real problems associated with the donation of code and
people to Apache projects by big companies. Those problems doubtless led to
perceptions that I have heard here. Many of those perceptions are not
entirely wrong. These problems are being addressed.

There are a number of ways of productively influencing Apache software. All
of them entail becoming involved to some degree.

As for the list of stuff you mention, I've used some of them, too, and as
you know I'm interested in OpenSymphony. That list is a bit misleading -
Apache doesn't have a J2EE server project that I'm aware of, one of the JDOM
authors is in fact an ASF member, OpenSymphony doesn't have an Apache
counterpart, can't speak for the tags thing, and Saxon...well, hell, I like
Saxon better myself, but it's not free of bugs either. :-) Not sure I
understand the license reference, though.

Regards,
Arved Sandstrom

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Mike
Cannon-Brookes
Sent: Wednesday, February 28, 2001 8:52 PM
To: Orion-Interest
Subject: RE: I switch from X to Orion because:

On another note (am I imagining things?) or isn't JDK2 _REQUIRED_ for J2EE ?

(Apache-folk: note the 2 in J2EE)

That tells me that Tomcat can never effectively be part of a true J2EE
server.

Other than that I agree with all that Victor has said.

Apache products suffer from
- severe bloat,
- old JDKs,
- bad spec conformance,
- appalling speed and
- some sort of strange developer arrogance

Why does everyone on the Apache project seem to think their products are
'the best' and cannot be beaten?! Sadly, 'tis not even close to true.

-mike (who uses Orion, Saxon, Jdom, Epesh.com tags and OpenSymphony - not
one released under the ASL and all rock)

Re: Starting threads not permitted in servlet?

[Falk Langhammer]

> Somebody on this list said that you're not allowed to start threads inside
a
> servlet container. Is this really in the spec (this was claimed), or is it
> implementation-dependent?

I am not sure for the web container. But the situation is even fuzzy for an
EJB container. I believe that in Orion, there isn't much difference between
the two (except for the RMI and wrapper subclasses).

Here is what the Borland BAS4.5 spec says about the EJB programming
restrictions:

--->8---
Verifies in accordance with pedantic EJB 1.1 rules. There are four warnings
that have been classified as pedantic:
-- Throwing java.rmi.RemoteException from a bean method is deprecated.
-- Static fields in the bean class must be final. (This is actually a useful
rule, which is violated by the Java compiler.)
-- The primary key type must define the equals(Object) method.
-- The primary key type must define the hashCode() method.
The behavior of the verifier is that, by default, these rules are ignored.
Choosing the Pedantic option causes violations of these rules to issue
warnings. For deployment purposes, warnings are ignored, meaning that you
can go ahead and deploy beans which have warnings. However, you cannot
deploy beans which have errors.
Keep in mind the following about pedantic verification:
1) Not actually required by our runtime, meaning that your code will work as
is.
2) Questionable altogether, and may well be eliminated from the EJB
specification when people realize how annoying they are.
3) Violated in almost every EJB program ever written, both in our product
and in all the various books ever written about EJB.
--->8---

>>> Especially, note point 3)  :-))

-
Below is a list of programming restrictions defined in the EJB 1.1
specification.

An enterprise bean is not allowed to manage threads and thread groups. It
should not start new threads or resume suspended threads, nor should it
terminate or suspend the running thread. In addition, an enterprise bean
should not change a thread's priority or its name.
An enterprise bean is not allowed to use read/write static fields. Using
read-only static fields is allowed. Therefore, all static fields must be
declared as final.
An enterprise bean is not allowed to use thread synchronization primitives
to synchronize the execution of multiple instances.
An enterprise bean must not use the Java AWT functionality to output
information to a display or to accept information from a keyboard.
An enterprise bean should not use the java.io package to access files and
directories in the file system.
An enterprise bean should refrain from using sockets; in particularly, the
bean should not listen on a socket, accept connections on a socket, or use a
socket for multicast. In addition, it should not set the socket factory used
by ServerSocket, Socket, or the stream handler factory used by URL.
An enterprise bean must not access classes or packages, or attempt to obtain
information about classes, in a manner normally disallowed by the Java
programming language or if the classes are normally unavailable to the
enterprise bean.
An enterprise bean must not access the runtime environment functions
normally handled by the container--create a class loader or access or change
its context, set or create a security manager, stop the JVM, change input,
output, or error streams.
An enterprise bean must not obtain security policy information for a
particular code source as this would compromise security.
An enterprise bean must not load a native library.
An enterprise bean must not define a class in a package, as this is a
function reserved for the container for security reasons.
An enterprise bean must not use the subclass and object substitution
features of the Java Serialization Protocol.
An enterprise bean should be careful if passing this as an argument or
method result. It is safer for the bean to pass the result of
SessionContext.getEJBObject() or EntityContext.getEJBObject().
An enterprise bean is not allowed to access or modify security configuration
objects. For example, it is not allowed to change its
java.security.Identity. Any such attempt will result in the
java.security.SecurityException being thrown.

Re: In Orion, are tag handler instances reused or reinstantiated?

[Jonathan James]

Actually it's configurable. Just add "-Djsp.reuse.tags=[false|true]" to your
command line when you launch the server.

Jonathan
- Original Message -
From: "Randahl Fink Isaksen" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Thursday, March 01, 2001 2:47 AM
Subject: RE: In Orion, are tag handler instances reused or reinstantiated?


> Experience tells me they are reused in Orion. If I have an optional tag
> attribute on a tag and the tag is used multiple times on a page I have
found
> out that I need to make sure that any contents set in the optional
attribute
> must be cleared manually by me, or I will get whatever contents was set by
a
> previous invokation of the tag.
>
>
> Yours
> Randahl
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Blacha, Bart
> Sent: 28. februar 2001 19:27
> To: Orion-Interest
> Subject: In Orion, are tag handler instances reused or reinstantiated?
>
>
> We are trying to figure out if tag handler objects are re-used, or
> instantiated-and-destroyed at every request.  This is obviously important
> for performance reasons.
>
> There is conflicting information in JSP spec and on JGuru (see references
> below).  So maybe it's an implementation-specific issue.   Which brings me
> to the question:
>
> What does Orion do with tag handler instances?  Reuse or reinstantiate
them?
>
>
>
>
> JSP spec 1.1, paragraph 5.4.7:
>
> At execution time the implementation of a JSP page will use an available
Tag
> instance with
> the appropriate prefix and name that is not being used, initialize it, and
> then follow the
> protocol described below. Afterwards, it will release the instance and
make
> it available for
> further use. This approach reduces the number of instances that are needed
> at a time.
>
>
> http://www.jguru.com/jguru/faq/view.jsp?EID=337618
>
> Question  We want to make sure that our JSP development efforts are
> thread-safe. Is it possible that two threads will access one instance of a
> JSP custom tag handler concurrently?
>
> No it is not possible. There is a defined lifecycle of a custom tag, and
> during this lifecycle, that instance of the tag will only get called once.
> Hopefully in newer implementations of JSP engines, the actual tag object
> will not get reinstantiated each time (as this negatively affects
> performance), but at least during it's use, it will be thread safe.
>
>
> --
> Bart Blacha, Software Developer
> NetPerceptions Inc.
> (512) 349-5622
> [EMAIL PROTECTED]
>
>
>
>
>

Re: Database schema type mappings

[Falk Langhammer]

- Original Message -
> long millisInMonth = (long)1000 * 60 * 60 * 24 * 30;
> This should probably go in some sort of Java-puzzle magazine article.
> :-)

I think this is a standard situation in Java and C. Most programmers would
probably write it as

long millisInMonth = 1000L * 60L * 60L * 24L * 30L;

only casting "(long)1000..." is safe only as long as the remainder of the
expression fits an int.

Use non-captital "l" rather than "L" as in

long millisInMonth = 1000 * 60 * 60 * 24l * 30; // right
long millisInMonth = 1000 * 60 * 60 * 241 * 30; // wrong

for Your Java puzzle. Depending on the font used it may be impossible to
spot the error ;-))

Re: Form based authentication problem

[Jonathan James]

I get a 405 error. "The method POST is not 
supported by this URL"
 
Jonathan

  - Original Message - 
  From: 
  cybermaster 
  To: Orion-Interest 
  Sent: Wednesday, February 28, 2001 10:22 
  AM
  Subject: RE: Form based authentication 
  problem
  
  
  Post 
  works for me in my test code – what error do you get?  
  --peter
   
  -Original 
  Message-From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan JamesSent: Tuesday, February 27, 2001 9:50 
  AMTo: 
  Orion-InterestSubject: Form 
  based authentication problem
   
  I'm trying to get 
  the Java Petstore 1.1.1 (the new one) working with Orion. I've read some 
  previous posts and the docs and everything is working except that on my 
  login.jsp I have to use  
  instead of  as it is 
  supposed to be. This ends up putting the password in the URL. Why doesn't POST 
  work with with j_security_check?
   
  Thanks
   
  Jonathan

Re: EJB values into xml attributes (a little off topic, I know)

[Falk Langhammer]

]>

I do not think this is legal.
(1) Recursive entitity declaration
(2) & is predefined, & is reserved as entity prefix.

I do not think that You can redefine the XML grammar by defining "&" or "<"
as entities. In summary, You do not need the DOCTYPE at all. (I haven't read
the spec recently, I may be wrong).

Then, to my understanding,

& should be & because doc: is a namespace prefix, not
a DOCTYPE prefix.
& should be & (cf. above)

Therefore, You have the same problem for elements and attributes.

We do have the same problem and solve it by transforming all strings by our
class XMLEscaper or (where elements may use CDATA when it must preserve
whitespace and linefeeds) before generating XML. I would be surprised if
there existed some magic avoiding this step. [EMAIL PROTECTED] has proposed
this magic to the JDOM list such that Java strings can be passed in and out
of elements and attributes without worry. Dunno what happened to this
proposition. JDOM *is* the place where this problem should be fixed.

Bye,
Falk

RE: CMP 2.0

[Jeff Schnitzer]

I've heard comments on this list in the past from Karl & Magnus that
bad, misleading, or missing error messages should be logged in Bugzilla
as bugs.

http://www.orionserver.com/bugzilla

:-)

Jeff

>-Original Message-
>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 01, 2001 1:19 AM
>To: Orion-Interest
>Subject: RE: CMP 2.0
>
>
>As I just posted, Jeff. The error was due to the fact that I 
>had declared my
>primary keys as Integer but I returned the primitive type int from my
>ejbCreate methods. As soon as I changed this, everything 
>worked fine. I am
>(to put it mildly) very surprised that Orion did _not_ give me 
>a compile
>time error when I deployed - it just crashed instead or ran 
>without working
>correctly.
>Yes I know who introduced the bug, but since I think Orion is 
>a magnificent
>piece of software I would never had expected it to NOT report 
>this compile
>time error.
>
>
>Randahl
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff 
>Schnitzer
>Sent: 1. marts 2001 02:42
>To: Orion-Interest
>Subject: RE: CMP 2.0
>
>
>?
>
>I have all my transactional behavior defined as NotSupported and I use
>EJB 2.0 container managed relationships without issue.  I don't
>currently need transactions for what I'm doing.
>
>Randahl, have you examined the contents of the database tables and the
>orion-ejb-jar.xml closely?
>
>Jeff
>
>-Original Message-
>From: Tim Drury [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, February 28, 2001 8:34 AM
>To: Orion-Interest
>Subject: RE: CMP 2.0
>
>
>
>
>I've been out for a few days, so it this has been answered,
>sorry for the repost.
>
>This sounds like you didn't set the transactional behavior
>in ejb-jar.xml as "required".  There is no default behavior
>in the spec so it is up to the container to decide what
>the default behavior is.  I know in Weblogic, transactions
>default to "supports" (I think).  In any event, the entities
>are not stored in the database unless you mark them
>as "required".  Orion may be doing the same thing.
>
>-tim
>
>
>> -Original Message-
>> From: Randahl Fink Isaksen [ mailto:[EMAIL PROTECTED]
> ]
>> Sent: Monday, February 26, 2001 5:29 AM
>> To: Orion-Interest
>> Subject: CMP 2.0
>>
>>
>> Would somebody please confirm that they have been able to use CMP 2.0
>> relationships on Orion, that they have seen them get stored
>> in the database
>> AND brought back into main memory correctly after a restart
>> of the server.
>>
>> When I create a relationship it works fine until I restart -
>> I simply can't
>> make Orion restore my relationships from the keys it stores
>> in the database.
>> If I try the getX() / method of a cmr property it works - but after a
>> restart it returns null.
>>
>>
>> R.
>>
>>
>>
>
>
>

Starting threads not permitted in servlet?

[Manne Fagerlind]

Somebody on this list said that you're not allowed to start threads inside a
servlet container. Is this really in the spec (this was claimed), or is it
implementation-dependent?

/Manne

RE: Database schema type mappings

[Jeff Schnitzer]

It's at the bottom of page 159 of Richard Monson-Haefel's _Enterprise
Java Beans, 2nd Ed_:  "Although primary keys can be primitive wrappers
(Integer, Double, Long, etc.), primary keys cannot be primitive types
(int, double, long, etc.)"

I wasn't able to locate an explicit statement in the spec in my quick
scan, but the spec always refers to the primary key as the "primary key
class" and the deployment descriptor element is "prim-key-class".  This
is further reinforced by the comments in the DTD.

It makes sense, because EntityContext.getPrimaryKey() returns an Object.
Thus all PKs *must* be Objects.

About question #1:  I doubt there is any explicit requirement in the
spec that Integers be converted to ints in the database.  In fact, the
spec doesn't require a relational database; that's simply an
implementation detail.  Still, I doubt you will find *any* appservers
which serialize Integer keys as blobs - although it would work, the
performance penalty would be severe.

Jeff

>-Original Message-
>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 01, 2001 1:22 AM
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>Thanks for the reply Jeff. Know I have two replies: One saying 
>primary keys
>can be primitive types and one that says they can't.
>I am really looking forward to hearing your arguments, gentlemen ;-)
>
>BTW, Jeff: Your answer to question number 1 - do you have that from the
>specification, or...
>
>Randahl
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff 
>Schnitzer
>Sent: 1. marts 2001 02:52
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>>
>>1. Why is Integers automatically converted to int by Orion -
>>and is this a
>>standard EJB convention?
>
>Yes.  All the class representations of the primitive types should work
>that way.
>
>>2. Would it be legal to have a primary key of the primitive type "int"
>>instead of Integer?
>
>No.  Primary keys must be Objects.  This makes sense because
>EntityContext.getPrimaryKey() returns an Object.
>
>Jeff
>
>
>

Re: Orion with tomcat!!!

[Joe Walnes]

At 16:54 28/02/2001 -0500, JangHo Ki wrote:
>Hello.
>
>I know it has been mentioned in serveral times.
>However, I could not make Orion as EJB server work with Apache & Tomcat.
>A servlet is placed to access ejb at tomcat's WEB-INF/classes directory,
>along with application-client.xml under META-INF directory.
>
>The servlet looks as follows:

*snip*

> Hashtable env = new Hashtable();
> env.put("java.naming.factory.initial",
>"com.evermind.server.ApplicationClientInitialContextFactory");
> env.put("java.naming.provider.url",
>"ormi://localhost:800/hello-planet");
> env.put("java.naming.security.principal", "admin");
> env.put("java.naming.security.credentials", "admin");

You should set the java.naming.factory.initial property to 
'com.evermind.server.rmi.RMIInitialContextFactory', otherwise the web-app 
behaves like a J2EE client (which requires application-client.xml).

-Joe Walnes

RE: Database schema type mappings

[Jeff Schnitzer]

Yes, it fits into a long, but by default constants like 

1000 * 60 * 60 * 24 * 30

are ints, so the arithmetic is done using int math.  Inconveniently, the
value of that expression is (slightly) greater than Integer.MAX_VALUE so
overflow occurs.  Thus the negative value which gets assigned to
millisInMonth.

The fix is to force long math:

long millisInMonth = (long)1000 * 60 * 60 * 24 * 30;

This should probably go in some sort of Java-puzzle magazine article.
:-)

Jeff

>-Original Message-
>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 01, 2001 1:09 AM
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>Jeff, about the bug you mention... that sounds very strange to 
>me and it
>sure should not have anything to do with byte size, I think. The value
>millisInMonth easily fits into a long... So if you have a long 
>representing
>the current time milliseconds and subtract one month of 
>milliseconds, yes,
>that should definately produce a time last month.
>
>I would like to know if I am wrong in this assumption or what 
>the bug REALLY
>was about (?)
>
>R.
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff 
>Schnitzer
>Sent: 1. marts 2001 02:38
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>You're thinking C++.
>
>In Java:
>
>A long is 8 bytes, always.
>An int is 4 bytes, always.
>
>The byte-orders are fixed independent of the hardware, too.
>
>Speaking of byte size, here's something I found amusing (and annoying):
>
>   long millisInMonth = 1000 * 60 * 60 * 24 * 30;
>   Date thirtyDaysAgo = new Date();
>   thirtyDaysAgo.setTime(thirtyDaysAgo.getTime() - millisInMonth);
>
>This actually produces a date in the FUTURE!
>
>It took me a while to hunt down this bug because it had really wierd
>effects on my application.
>
>Jeff
>
>>-Original Message-
>>From: Michael A Third [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, February 28, 2001 11:02 AM
>>To: Orion-Interest
>>Subject: RE: Database schema type mappings
>>
>>
>>Randahl,
>>
>>We use the primitive long for all of our primary keys for a couple of
>>reasons:
>>* primary keys can't be null so there isn't a need for Long
>>(or Integer)
>>* long's are always 4 bytes no matter what the CPU (32bit vs
>>64bit), which
>>is currently not a problem but could be when Itanium platforms
>>come out.
>>int's depend on the CPU's native integer type which happens to
>>be 32bits on
>>ix86 architectures.
>>
>>Michael Third
>>Chief Software Architect
>>parts.com
>>
>>
>>-Original Message-
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED]]On Behalf Of Randahl Fink
>>Isaksen
>>Sent: Wednesday, February 28, 2001 10:02 AM
>>To: Orion-Interest
>>Subject: Database schema type mappings
>>
>>
>>If you look at the database schema in
>>"orion/config/database-schemas/hypersonic.xml" it looks as if
>>it is mapping
>>between the primitive java type "int" and the corresponding
>>database type
>>"int":
>>.
>>
>>In my EJBs my primary keys and other attributes are of type
>>Integer. Since
>>there is no mapping for class Integer one could think that
>>Integers would be
>>mapped to VARBINARY. Luckily my integers are mapped to the
>>database type
>>"int", but this makes me ask two questions:
>>
>>1. Why is Integers automatically converted to int by Orion -
>>and is this a
>>standard EJB convention?
>>2. Would it be legal to have a primary key of the primitive type "int"
>>instead of Integer?
>>
>>
>>Yours
>>
>>Randahl
>>
>>
>>
>
>
>

RE: EJB values into xml attributes (a little off topic, I know)

[Randahl Fink Isaksen]

I will rephrase my question then (still, a little off topic):

On Orion at least, it seems transformation only works for element values NOT
for attribute values. If I have


]>

Then & will get transformed to &

But  will just get transformed into  because the '&'
is inside an attribute.

How can one accomplish transformation of such attributes?


Yours
Randahl

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of orionEJB
Sent: 28. februar 2001 15:37
To: Orion-Interest
Subject: Re: EJB values into xml attributes (a little off topic, I know)


You can use title as element not as attribut in your XML document.
Then you can to use CDATA. Everything inside a CDATA section is ignored
by the parser.

 


 


BaV

RFI> PROBLEM

RFI> I have a question regarding taking properties from an EJB and
generating XML
RFI> output. To explain, here is an example of my problem:

RFI><%= myPoem.getContents() %>
RFI> 

RFI> Because title is an XML attribute I think special characters like '&'
needs
RFI> to be escaped with & and the like. How does one handle this in a
nice
RFI> way?


---R--E--K--L--A--M--A-
Szukasz wiedzy? 85 tysiecy uaktualnianych ciagle hasel.
Encyklopedia Internautica: http://encyklopedia.interia.pl/

JSP set-property bug

[Falk Langhammer]

Hi list,

I believe that there is a bug in Orion's JSP engine (1.4.5).



About 6 out of 53 properties are not set. When I set those explicitely as in



everything is ok. Because 12 properties are structurally identical (just
different names) I guess that there is a hard number in the # of properties
which Orion can handle via reflection (the "*"-tag). The JSP works ok under
Tomcat.

Anyone who can confirm this is a bug? Is it in bugzilla? I tend to enter it
as a bug there but wanted to ask the list first.

Bye,
Falk

RE: login security include file

[Manne Fagerlind]

Strangely enough,  always flushes 
the writer - i.e. the flush="false" is ignored. This is in the JSP 1.1 spec. 
Don't ask me why...
 
/Manne

  -Original Message-From: Vaskin Kissoyan 
  [mailto:[EMAIL PROTECTED]]Sent: 28 February 2001 
  22:36To: Orion-InterestSubject: login security include 
  file
  I'm trying to do a 
  response.sendRedirect() from an include file 
   and wanted to avoid doing a directive.include (preparser), 
  
   
  I keep getting "Response has already been 
  committed, be sure not to write to the OutputStream or to trigger a commit due 
  to any other action before calling this method."
   
  I have been very careful as to put this include 
  at the very top of the file, and to specify autoFlush=false and flush=false on 
  the include tag.
   
  Again, the intention of this include file would 
  be to be place at the top of the jsp file to secure it by redirecting to a 
  login page if credentials in a session based UserBean do not allow access to 
  the page for some reason.
   
  -Vaskin

RE: Database schema type mappings

[Randahl Fink Isaksen]

Thanks for the reply Jeff. Know I have two replies: One saying primary keys
can be primitive types and one that says they can't.
I am really looking forward to hearing your arguments, gentlemen ;-)

BTW, Jeff: Your answer to question number 1 - do you have that from the
specification, or...

Randahl

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer
Sent: 1. marts 2001 02:52
To: Orion-Interest
Subject: RE: Database schema type mappings


>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>
>1. Why is Integers automatically converted to int by Orion -
>and is this a
>standard EJB convention?

Yes.  All the class representations of the primitive types should work
that way.

>2. Would it be legal to have a primary key of the primitive type "int"
>instead of Integer?

No.  Primary keys must be Objects.  This makes sense because
EntityContext.getPrimaryKey() returns an Object.

Jeff

RE: CMP 2.0

[Randahl Fink Isaksen]

As I just posted, Jeff. The error was due to the fact that I had declared my
primary keys as Integer but I returned the primitive type int from my
ejbCreate methods. As soon as I changed this, everything worked fine. I am
(to put it mildly) very surprised that Orion did _not_ give me a compile
time error when I deployed - it just crashed instead or ran without working
correctly.
Yes I know who introduced the bug, but since I think Orion is a magnificent
piece of software I would never had expected it to NOT report this compile
time error.


Randahl

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer
Sent: 1. marts 2001 02:42
To: Orion-Interest
Subject: RE: CMP 2.0


?

I have all my transactional behavior defined as NotSupported and I use
EJB 2.0 container managed relationships without issue.  I don't
currently need transactions for what I'm doing.

Randahl, have you examined the contents of the database tables and the
orion-ejb-jar.xml closely?

Jeff

-Original Message-
From: Tim Drury [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 28, 2001 8:34 AM
To: Orion-Interest
Subject: RE: CMP 2.0




I've been out for a few days, so it this has been answered,
sorry for the repost.

This sounds like you didn't set the transactional behavior
in ejb-jar.xml as "required".  There is no default behavior
in the spec so it is up to the container to decide what
the default behavior is.  I know in Weblogic, transactions
default to "supports" (I think).  In any event, the entities
are not stored in the database unless you mark them
as "required".  Orion may be doing the same thing.

-tim


> -Original Message-
> From: Randahl Fink Isaksen [ mailto:[EMAIL PROTECTED]
 ]
> Sent: Monday, February 26, 2001 5:29 AM
> To: Orion-Interest
> Subject: CMP 2.0
>
>
> Would somebody please confirm that they have been able to use CMP 2.0
> relationships on Orion, that they have seen them get stored
> in the database
> AND brought back into main memory correctly after a restart
> of the server.
>
> When I create a relationship it works fine until I restart -
> I simply can't
> make Orion restore my relationships from the keys it stores
> in the database.
> If I try the getX() / method of a cmr property it works - but after a
> restart it returns null.
>
>
> R.
>
>
>

RE: Database schema type mappings

[Randahl Fink Isaksen]

Jeff, about the bug you mention... that sounds very strange to me and it
sure should not have anything to do with byte size, I think. The value
millisInMonth easily fits into a long... So if you have a long representing
the current time milliseconds and subtract one month of milliseconds, yes,
that should definately produce a time last month.

I would like to know if I am wrong in this assumption or what the bug REALLY
was about (?)

R.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer
Sent: 1. marts 2001 02:38
To: Orion-Interest
Subject: RE: Database schema type mappings


You're thinking C++.

In Java:

A long is 8 bytes, always.
An int is 4 bytes, always.

The byte-orders are fixed independent of the hardware, too.

Speaking of byte size, here's something I found amusing (and annoying):

long millisInMonth = 1000 * 60 * 60 * 24 * 30;
Date thirtyDaysAgo = new Date();
thirtyDaysAgo.setTime(thirtyDaysAgo.getTime() - millisInMonth);

This actually produces a date in the FUTURE!

It took me a while to hunt down this bug because it had really wierd
effects on my application.

Jeff

>-Original Message-
>From: Michael A Third [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, February 28, 2001 11:02 AM
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>Randahl,
>
>We use the primitive long for all of our primary keys for a couple of
>reasons:
>* primary keys can't be null so there isn't a need for Long
>(or Integer)
>* long's are always 4 bytes no matter what the CPU (32bit vs
>64bit), which
>is currently not a problem but could be when Itanium platforms
>come out.
>int's depend on the CPU's native integer type which happens to
>be 32bits on
>ix86 architectures.
>
>Michael Third
>Chief Software Architect
>parts.com
>
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Randahl Fink
>Isaksen
>Sent: Wednesday, February 28, 2001 10:02 AM
>To: Orion-Interest
>Subject: Database schema type mappings
>
>
>If you look at the database schema in
>"orion/config/database-schemas/hypersonic.xml" it looks as if
>it is mapping
>between the primitive java type "int" and the corresponding
>database type
>"int":
>.
>
>In my EJBs my primary keys and other attributes are of type
>Integer. Since
>there is no mapping for class Integer one could think that
>Integers would be
>mapped to VARBINARY. Luckily my integers are mapped to the
>database type
>"int", but this makes me ask two questions:
>
>1. Why is Integers automatically converted to int by Orion -
>and is this a
>standard EJB convention?
>2. Would it be legal to have a primary key of the primitive type "int"
>instead of Integer?
>
>
>Yours
>
>Randahl
>
>
>

RE: Database schema type mappings

[Randahl Fink Isaksen]

Thanks Michael - that answered question number 2... anyone up for question
number 1 (see below).

Randahl

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Michael A
Third
Sent: 28. februar 2001 20:02
To: Orion-Interest
Subject: RE: Database schema type mappings


Randahl,

We use the primitive long for all of our primary keys for a couple of
reasons:
* primary keys can't be null so there isn't a need for Long (or Integer)
* long's are always 4 bytes no matter what the CPU (32bit vs 64bit), which
is currently not a problem but could be when Itanium platforms come out.
int's depend on the CPU's native integer type which happens to be 32bits on
ix86 architectures.

Michael Third
Chief Software Architect
parts.com


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Randahl Fink
Isaksen
Sent: Wednesday, February 28, 2001 10:02 AM
To: Orion-Interest
Subject: Database schema type mappings


If you look at the database schema in
"orion/config/database-schemas/hypersonic.xml" it looks as if it is mapping
between the primitive java type "int" and the corresponding database type
"int":
.

In my EJBs my primary keys and other attributes are of type Integer. Since
there is no mapping for class Integer one could think that Integers would be
mapped to VARBINARY. Luckily my integers are mapped to the database type
"int", but this makes me ask two questions:

1. Why is Integers automatically converted to int by Orion - and is this a
standard EJB convention?
2. Would it be legal to have a primary key of the primitive type "int"
instead of Integer?


Yours

Randahl

RE: signoff EJB-INTEREST

[Randahl Fink Isaksen]

Please use the form at www.orionserver.com

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Lu, Michael
Sent: 28. februar 2001 20:47
To: Orion-Interest
Subject: signoff EJB-INTEREST


signoff EJB-INTEREST

RE: recreate tables for a cmp

[Randahl Fink Isaksen]

In fact if you just save your ejb-jar.xml and thereby change its time stamp
that will make Orion recreate tables. I am not sure, but I think you can
invoke orion.jar with a parameter to get it done (check out the docs), if
you are looking for a nicer way...

Yours
Randahl

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of John Hogan
Sent: 28. februar 2001 19:47
To: Orion-Interest
Subject: recreate tables for a cmp


All,

I have a cmp that has been deployed and has created tables for itself.

Now, I'd like to migrate to a different schema/db.  Changing the
schema connect string info in data-sources.xml to point at a
different db, and restarting orion does not by itself trigger
recreation of the entitybean tables.  Any use of the bean causes the
following error:

javax.ejb.CreateException: Error creating EntityBean: ORA-00942:
table or view does not exist

It seems that if you change some of the info in orion-ejb-jar.xml (a
cmp-field-mapping-name), the tables will be recreated the next time
orion is started.  I was wondering if anyone knows of a easier way to
signal orion to recreate db tables for an cmp bean?  TIA.

John Hogan


_

Get your free E-mail at http://www.ireland.com

RE: In Orion, are tag handler instances reused or reinstantiated?

[Randahl Fink Isaksen]

Experience tells me they are reused in Orion. If I have an optional tag
attribute on a tag and the tag is used multiple times on a page I have found
out that I need to make sure that any contents set in the optional attribute
must be cleared manually by me, or I will get whatever contents was set by a
previous invokation of the tag.


Yours
Randahl

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Blacha, Bart
Sent: 28. februar 2001 19:27
To: Orion-Interest
Subject: In Orion, are tag handler instances reused or reinstantiated?


We are trying to figure out if tag handler objects are re-used, or
instantiated-and-destroyed at every request.  This is obviously important
for performance reasons.

There is conflicting information in JSP spec and on JGuru (see references
below).  So maybe it's an implementation-specific issue.   Which brings me
to the question:

What does Orion do with tag handler instances?  Reuse or reinstantiate them?




JSP spec 1.1, paragraph 5.4.7:

At execution time the implementation of a JSP page will use an available Tag
instance with
the appropriate prefix and name that is not being used, initialize it, and
then follow the
protocol described below. Afterwards, it will release the instance and make
it available for
further use. This approach reduces the number of instances that are needed
at a time.


http://www.jguru.com/jguru/faq/view.jsp?EID=337618

Question  We want to make sure that our JSP development efforts are
thread-safe. Is it possible that two threads will access one instance of a
JSP custom tag handler concurrently?

No it is not possible. There is a defined lifecycle of a custom tag, and
during this lifecycle, that instance of the tag will only get called once.
Hopefully in newer implementations of JSP engines, the actual tag object
will not get reinstantiated each time (as this negatively affects
performance), but at least during it's use, it will be thread safe.


--
Bart Blacha, Software Developer
NetPerceptions Inc.
(512) 349-5622
[EMAIL PROTECTED]

RE: CMP 2.0

[Randahl Fink Isaksen]

Title: RE: CMP 2.0



Thanks, Tim
 
I just 
dived into chapter 16 (Transactions) and it is clear that there is definately 
important stuff there which needs to be taken into consideration to avoid 
errors. However, it turned out that the reason for the problem I described was 
the fact that I had declared my primary key classes as "Integer" and in the 
create methods returned "int" - as soon as that was corrected, everything work 
fine.
I must 
say that I am a bit surprised this fault was not discovered by Orion on compile 
time !!???!!?
 
Thanks 
again
Randahl
 
 -Original Message-From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim 
DrurySent: 28. februar 2001 17:34To: 
Orion-InterestSubject: RE: CMP 2.0

  I've been out for a few days, so it this has been 
  answered, sorry for the repost. 
  This sounds like you didn't set the transactional 
  behavior in ejb-jar.xml as "required".  There is 
  no default behavior in the spec so it is up to the 
  container to decide what the default behavior 
  is.  I know in Weblogic, transactions default to 
  "supports" (I think).  In any event, the entities are not stored in the database unless you mark them as "required".  Orion may be doing the same thing. 
  -tim 
  > -Original Message- > 
  From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 26, 2001 5:29 AM > To: Orion-Interest > Subject: CMP 
  2.0 > > > Would somebody please confirm that they have been able to use CMP 
  2.0 > relationships on Orion, that they have seen 
  them get stored > in the database > AND brought back into main memory correctly after a restart 
  > of the server. > 
  > When I create a relationship it works fine until 
  I restart - > I simply can't > make Orion restore my relationships from the keys it stores 
  > in the database. > If 
  I try the getX() / method of a cmr property it works - but after a 
  > restart it returns null. > 
  > > R. > > > 
  

RE: Servlet Filters

[Manne Fagerlind]

If that doesn't work, you could try using the
HttpServletRequest.getRequestURI() method to spot requests for /test/* and
forward these requests to the right servlet or JSP.

/Manne

-Original Message-
From: Trond Nilsen [mailto:[EMAIL PROTECTED]]
Sent: 28 February 2001 22:51
To: Orion-Interest
Subject: RE: Servlet Filters


> We want to use a servlet filter to intercept *all* requests that come into
> the web server.  Is this possible?  It seems to work for all files when I
> put the URL filter as "/" or "/*".  But we're also looking to be notified
> when a directory resource is requested.  An example of this might be a url
> that looks like so:  "http://www.somecompany.com/test".  Test is not a
> virtual directory nor is it a directory under our site root.  We forward
> these directory requests to a JSP that then produces the appropriate
output
> for this directory on the fly.
>
> Has anyone tried this?  Or is there another way to filter HTTP requests in
> the Orion web server?

Given that you seem to have worked out how to intercept /*, intercepting
/test/* is a simple extension of that.
Presumably you have something like this in your web.xml


WhereStuffGoesByDefault
/*


So for /test/* you'd have


TestServlet
/test/*


The problem is working out which order they're considered. I imagine it's
probably the order they're specified, so you'd want the test one listed
first
in your web.xml. I'm assuming that by intercepting all requests you want
everything (except test/*) to go to a particular servlet. If you just mean
intercept and feed back whatever resource they asked for, then all you need
is
the second code snippet in your web.xml

Trond.