RE: OffTopic: Entity-Beans and relational structure

2002-04-25 Thread Jeff Schnitzer

You don't need BMP to do this, CMP works just fine.  Create separate
entity beans for Movie, Actor, etc and establish many-to-many
relationships between them.

However, I will provide this warning:  If you don't already know how to
do this, that is, if you haven't already climbed the EJB learning curve,
you will be a *lot* happier if you choose some other O/R mapping tool.
Torque, Castor, Hibernate, JDO, or even just straight JDBC; with any of
these solutions, your project will be up and running long before an
entity bean solution, and it will perform a lot better too.
Relationships in particular are hopelessly immature in Orion, and
they're even painful in WebLogic.

Jeff Schnitzer
[EMAIL PROTECTED]

 -Original Message-
 From: Chris Nias [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, April 24, 2002 7:49 AM
 To: Orion-Interest
 Subject: RE: OffTopic: Entity-Beans and relational structure
 
 If you get the Java 2 Enterprise Edition Developers Guide (I have v
 1.2.1 pdf) from www.java.sun.com
 Then it is on page 135 - Mapping Table Relationships to Entity beans
 It goes on to describe when you should use entity beans, and when to
use
 helper classes (hint: that is what you need!)
 It also gives a good example with source code.
 Be warned though; you will have to use BMP!
 
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]] On Behalf Of Maximilian
 Eberl
 Sent: 24 April 2002 13:13
 To: Orion-Interest
 Subject: OffTopic: Entity-Beans and relational structure
 
 Excuse me for asking off topic (and stupid), I am just learning to use
 Entity Beans on Orion.
 
 In most tutorials entity beans only represent ONE ROW from ONE TABLE,
 but
 relational databases go far beyond that.
 
 I have a relational database for movies, actors, directors  writers.
 
 So I have a table tblMovies
 INT id, VARCHAR title, INT year, VARCHAR description
 e.g.:
 1, 'Casablanca',1942,'the classical movie'
 2, 'The Maltese Falcon',1946,'begin of the dark series'
 3, 'The Seawulf',1947,'after the novel from Jack London'
 ...
 
 I have a tblActors (INT id, VARCHAR name)
 1,'Humphrey Bogart'
 2,'Ingrid Bergman'
 3,'Edward G. Robinson'
 ...
 
 and in the same manner tblDirectors, tblWriters
 
 And I have tables for the relations, e.g.
 
 tblRoles (INT filmid, INT actorid)
 1,1
 2,1
 1,2
 3,3
 ..
 and also tblMisEnScene, tblScreenplay
 
 meaning: Humphrey Bogart (actorid: 1) appeared in 'Casablanca'
(filmid:
 1)
 and 'The Maltese Falcon' (filmid: 2), Ingrid Bergman (actorid: 2)
 appeared
 in 'Casablanca' (filmid: 1), Edward G. Robinson (actorid: 3) appeared
in
 'The Seawulf' (filmid: 3) . So this relational structure allows that
one
 film can have multiple actors, writers, directors and one actor can
 appear
 in multiple films. Relational basework, of course.
 
 If I want to extract those films in which Humphrey Bogart appeared I
can
 do
 this easily in SQL (used by a Servlet) with:
 
 SELECT title FROM tblFilms WHERE id IN (SELECT filmid FROM tblRoles
 WHERE
 actorid=(SELECT id FROM tblActors WHERE name='Humphrey Bogart'))
 
 (or as in my case with JOINS from MySQL)
 
 When I do want to write an EJB-Application using this database, how do
I
 do
 this ? How do I represent the relational data ?
 
 Do I have to keep Entity Beans for EVERY row of ANY table ? Do I have
to
 create temporary tables with all information merged ? This creates a
 problem
 because one film can have one or more writers (Casablanca had three)
and
 (in
 most cases) more than one actor.
 
 This way  ?
 
 public class MovieBean implements javax.ejb.EntityBean
 {
 String Title;
 String[] Actors;
 ...
 public String getTitle() throws RemoteException;
 {...
 }
 public String[] getActors() throws RemoteException;
 {
 return Actors[];
 }
 }
 
 using Arrays filled from the database with all actors, directors,
 writers ?
 
 Please give me a hint ! (Well, I know I am stupid. But it is a good
work
 to
 help stupid persons)
 
 
 Maximilian Eberl
 http://www.derdickemax.de
 mailto:[EMAIL PROTECTED]
 
 
 
 





RE: is Orion dead?

2002-04-12 Thread Jeff Schnitzer

You know, this exact conversation has been surfacing every 4 months or
so for the last year and a half.  In particular, the internal
refactoring was what occupied the 6 months before the 1.5.4 release...
and now it looks like it's going on again.  Every time, a handful of
people (who apparently have some mysterious source of knowledge they
don't care to explain) say have patience, it's about to get a lot
better!

My patience ran out a couple weeks ago.  The 1.5.4 release has a
show-stopper (for me) broken version of HttpServletResponseWrapper, and
when I try to deploy my application I get a NullPointerException with a
stack trace obfuscated all the way up to Thread.run().  And this isn't
the first time I've had to hunt down problems with only a meaningless
exception as guide.

I have just fought my last obfuscated stack trace.  I'm tired of waiting
with no feedback.  I'm in the process of porting my applications to
JBoss 3.0, and so far I'm enormously pleased.  The pace of development
there is dizzying, and they are already ahead of Orion in terms of spec
compliance.  CVS commits and changes to the bug database are
automatically posted to the dev list so I can see the progress daily.

...and their mailing list software actually works.

Jeff Schnitzer
[EMAIL PROTECTED]
[I don't want to sound like I'm disparaging an obviously extraordinarily
bright software development team - but it looks to me like this project
has grown far beyond the reasonable scope of two or three developers.]

 -Original Message-
 From: Joseph Ottinger [mailto:[EMAIL PROTECTED]]
 Sent: Friday, April 12, 2002 1:05 AM
 To: Orion-Interest
 Subject: Re: is Orion dead?
 
 ...except the wait is due to an internal refactoring that should yield
 significant benefits. Yourconclusion was predicted by the list in
general,
 but I disagree; the team's still working on Orion, and I figure that
 people will be more happy once the new versions come out. You'd hope
it
 would be incremental changes as it was in the past (anyone remember
the
 three-versions-a-day times?) but that's simply not realistic
considering
 the changes being put into place. Patience. Enjoy.
 
 -
 Joseph B. Ottinger [EMAIL PROTECTED]
 http://enigmastation.comIT Consultant
 
 On Thu, 11 Apr 2002, Jarrod Roberson wrote:
 
  At 03:41 PM 4/11/2002, you wrote:
  Whats the current state of Ironflare and Orion?
  
  Nothing has changed in the 'stable release' of Orion for almost a
year,
 even
  though there are glaring bugs in http session clustering (not even
 fixed in
  1.5.4) and some significantly lacking components.   Ironflare was
 supposed
  to be in the pavillion at JavaONE, but oddly they had no write up
  (apparently they didn't submit one), and didn't actually show up
(so
 their
  booth was empty).  There also seems to be a conspicuous infrequency
to
 their
  responses here.
  
  I know that Oracle 9iAS is evolving and expanding, and I believe
that
  IronFlare is doing a significant amount of work on the 9iAS code
base
 (as
  consultants?).  But whats to become of Orion?  It almost appears
that
 Oracel
  has consumed Orion completely and no development will happen on the
old
  Orion.
 
  looks like someone finally figured it out!
 
  this is what happens when you get one big customer with a
guaranteed
  revenue stream, can't much blame them myself.
 
 
 
 
 





RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence

2002-04-09 Thread Jeff Schnitzer

 From: Simon Stewart [mailto:[EMAIL PROTECTED]]
 
 Forgive me, but what about the case where you just set the
 prim-key-class to be java.lang.Object and don't specify a managed
 primary key field in your ejb-jar.xml file? While that's not the
 world's most advanced method for automatically generating primary
 keys, it's there, and it does work
 
 Of course, I have no idea how to refer to this autogenerated primary
 key using EJB-QL, but that's beside the point ;)

Does that really work?  Can you get access to the value of the key
later?  I've combed over that part of the spec, but it's terribly vague
about how deferred keys are supposed to work.  I've never seen a
container that documented them, I have never seen an example of them
being used, and (until now) I have never known anyone to have tried
them.

Jeff Schnitzer
[EMAIL PROTECTED]




RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence

2002-04-09 Thread Jeff Schnitzer

I probably should have phrased my question a little differently:  Is
this guaranteed to work on any J2EE-compliant appserver?
 
Jeff
 
 
-Original Message-
From: Ray Harrison [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, April 09, 2002 4:30 AM
To: Orion-Interest
Subject: RE: [orion-interest]CMP/BMP and standard JDBC, speed is of
essence
 
Jeff - 
 Yes, it really works. You can get access to the key value later by
using getPrimaryKey on the instance. 
Cheers 
Ray 
  Jeff Schnitzer [EMAIL PROTECTED] wrote: 
 From: Simon Stewart [mailto:[EMAIL PROTECTED]]
 
 Forgive me, but what about the case where you just set the
 prim-key-class to be java.lang.Object and don't specify a managed
 primary key field in your ejb-jar.xml file? While that's not the
 world's most advanced method for automatically generating primary
 keys, it's there, and it does work
 
 Of course, I have no idea how to refer to this autogenerated primary
 key using EJB-QL, but that's beside the point ;)

Does that really work? Can you get access to the value of the key
later? I've combed over that part of the spec, but it's terribly vague
about how deferred keys are supposed to work. I've never seen a
container that documented them, I have never seen an example of them
being used, and (until now) I have never known anyone to have tried
them! .

Jeff Schnitzer
[EMAIL PROTECTED]
 
  _  

Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax




RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence

2002-04-07 Thread Jeff Schnitzer

 From: The elephantwalker [mailto:[EMAIL PROTECTED]]
 
 You will find that if you want the _enterprise_ features offered by
cmp
 with
 straight jdbc calls, your classes for jdbc calls will be slower than
cmp,
 and _much more_ difficult to develop.
 
 I am not a smarter developer than Karl or Magnus. Their algorithms for
 caching, transaction management, pooling (connection, threads,
objects,
 you
 name it), are among the best in the business. If I were to _attempt_
to
 reproduce these features, I would certainly _fail_ to reproduce these
 features in a reasonable time.

Eh?

Connection pooling and transaction management are provided to session
beans through the data source.  No CMP or entity beans necessary.
Furthermore, if you want sane transaction demarcation, you already have
to wrap all your entity bean access in session bean methods.

Entity bean caching I have found to be remarkably useless.  First of
all, it depends on a pessimistic locking strategy, which is both hard to
use (gotta love those deadlock exceptions!) and not applicable to a
clustered environment or any environment in which the database table can
be modified from an external source.  Furthermore, finder methods are
not cached - and with an eager loading strategy, I really have to wonder
what the great advantage of the caching is... bringing all the bean data
back usually isn't that much more expensive than bringing just the PK
data back, and if it is (because of large data fields) then your cache
is going to have size problems anyways.

Irrespective of who may be a smarter developer, I can guarantee you that
I know a *lot* more about *my* specific business logic than Karl or
Magnus.  Furthermore, Karl and Magnus are for the most part just
implementing a specification produced by a committee of labcoats
dedicated to a lowest-common-denominator set of features that IBM, BEA,
Borland, Sybase,  the rest of the implementers can agree to.  The
absence of ORDER BY in EJB-QL and the lack of a standard PK generation
mechanism make me seriously wonder if any of the people writing the EJB
spec have ever used it to implement a real-world application.

 There will always be a place for jdbc in an enterprise application.
But in
 an enterprise application where the transaction is as important as the
 data,
 and the data structure itself may change from time to time, cmp ejbs
are
 the
 way to go.

Entity beans can be useful for modeling your data.  For some business
cases, they might actually be all you need.  I, however, have yet to see
one of those cases in the real world.  I will reiterate the three
failings I mentioned before:  you cannot model relationship attributes,
you cannot perform aggregation queries, and you cannot query for data
that spans multiple objects.  I'll add that if you're restricting
yourself to EJB-QL, you're going to have even bigger problems, like the
inability to order the result set without sorting yourself in Java.

Relational databases have evolved over the last thirty years to provide
us with a very refined solution for storing and accessing enterprise
data.  Entity beans are a big square peg that can only be brutally
forced into the multifaceted hole that is our problem space.
 
 A resultset relies on datastructure strings, and are closely coupled
with
 the underlying database structure. All my experience indicates that
the
 datastructure will change many times during a project, after the
project
 is
 finished, and before the application is retired.
 
 jdbc is tightly linked with the datastructure. This link goes to a low
 level, as many text strings need to be modified when the datastructure
 changes. Argh! Don't get caught in the performance trap where you
 application performance increases by 2%, but its almost impossible to
 change
 your application without competely rewriting it.

If the primary argument for using entity beans is that they offer a
layer of indirection so that you can rename columns, there are plenty of
alternative approaches which are *much* simpler.

I'm not saying don't use entity beans (although I would *definitely*
recommend that a team which does not already have a lot of EJB expertise
should avoid them), but I am saying that it is a huge mistake to
consider entity beans your only means of data access.  To use the square
peg analogy again, reduce the size of the square to something that fits
smoothly through the hole, and fill in around the edges with other
mechanisms (like JDBC).
 
Jeff Schnitzer
[EMAIL PROTECTED]
Consulting  Contracting - J2EE, WebLogic, Orion/OC4J




RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence

2002-04-06 Thread Jeff Schnitzer

 From: Hani Suleiman [mailto:[EMAIL PROTECTED]]
 Sent: Saturday, April 06, 2002 6:20 PM
 To: Orion-Interest
 Subject: Re: [orion-interest]CMP/BMP and standard JDBC, speed is of
 essence
 
 CMP will load in all the entities in one go (in orion at least).
 
 There will be a performance difference between straight JDBC and EJB,
 since
 there's more involved with an EJB query. Transactions, constructing
 entities
 and so on are extra overhead that just getting a resultset back will
not
 have.

If you use JDBC from a connection obtained from a DataSource in a
Session bean, all queries should have the transaction attributed defined
for the Session bean method.  You do not need entity beans to have
transactions.

 So if done right, CMP will be close in speed to straight JDBC, plus
you
 have
 the potential for more goodies like container caching of finders and
 entities and so on, that you'd get for 'free' in some new version of
your
 favourite container, if it doesn't do so already!

There's that if done right problem.

If Orion (or any other app server) backed the Collection returned by a
finder with the ResultSet itself (instead of producing ArrayLists), then
it seems like performance wouldn't be too much different from JDBC.  Of
course, you're going to have all the overhead of constructing entity
bean objects and loading them with all the data (ok, maybe part of the
data if you're using WebLogic or other container with field groups), but
it shouldn't be too dramatic compared to the remote database call.

I don't know if there is a technical problem with doing this or if other
containers do this, but Orion doesn't seem to be that smart.  So yeah,
entities are going to be slower, especially if you're listing 1000's of
them.

EJB-QL, even if Orion supported it, is only going to make things worse.
It's an abstraction above SQL.  All the hints and other
database-specific goodies that you can normally encode in a SQL
statement cannot be used.  And you can't order the result set with EJB
QL, so sorting has to be done outside the database (yeah, right!).

I have found that a good approach to data access is to model your data
using CMP entity beans, use them for write access, and code in JDBC
whenever you need listing behavior that CMP is too slow or too
inflexible to support.

By far the biggest problem is that too inflexible part, IMHO...
modeling relationship attributes, performing aggregation queries, or
querying for data that spans multiple objects simply does not fit into
the world of entity beans.  This criticism seems to apply to just about
any O/R mapping scheme... which is why I think they are useful, but
should not be taken too seriously.

A good example of this hybrid approach is the Punk Image Gallery
sample application for the Maverick MVC framework:
http://mav.sourceforge.net/pig.  It is a comprehensive sample J2EE
application which runs on Orion.  It's not a trivial sample; my friends
and I actually use a live instance to archive (and annotate, wiki-like)
our images.  There is *no* way it could perform reasonably with pure
entity beans.

Jeff Schnitzer
[EMAIL PROTECTED]
Consulting  Contracting - J2EE, WebLogic, Orion/OC4J

 On 6/4/02 7:15 pm, Duffey, Kevin [EMAIL PROTECTED] wrote:
 
  Hi all,
 
  Kinda curious about one thing. We use BMP, and tried CMP. Both seem
to
 load
  one record at a time. With straight JDBC, you can query and get a
large
  result set back in one time. When comparing our searching using CMP
and
 BMP,
  it is over 100 times slower than a straight JDBC query when getting
 several
  1000 records. Maybe we are doing something wrong, but can anyone
tell me
 if
  this makes sense? Should CMP with EJB 2.0 (and lets use all aspects,
 such as
  the EJB QL language if necessary to do a query) be as fast as a
straight
  JDBC call? Or is it in fact that doing a query with JDBC and getting
the
  ResultSet back is much faster than a container that implements CMP?
Id
  really like to use EJB 2.0 and CMP, but if the results are anything
like
  what we are seeing, it seems to be way too slow for big tasks. We
are
  re-evaluating if we should use EJB for our tasks or not.
 
  Thanks.
 
 





RE: CMP 2.0 vs BMP - Which performes better?

2002-04-04 Thread Jeff Schnitzer

 From: Curt Smith [mailto:[EMAIL PROTECTED]]
 
  There are several constraints to BMP beans which make them almost
always
  perform slower than CMP beans.  In particular, the inability to bulk
  load beans from finder methods is a nearly fatal defect.
 
 I'd like to know more of the details?
 
 How does the container deal with the following finder in CMP
 differently than BMP?
 
 Collection remoteRefs = home.findSalaryGreaterThan ( 50,000);

Lets assume this produces 1000 results which you then iterate through.

With BMP beans, this will require 1001 database queries.  First the
finder, then 1000 selects to load each bean.

With CMP, it's actually rather ambiguous what will happen.  Last time I
checked, Orion will load all the beans into an ArrayList.  Yes, lots of
memory consumed, but a *lot* better than 1001 database hits.  Admittedly
a bigger problem with orders of magnitude more objects, but even with
BMP you're going to choke if the finder query returns a billion rows of
primary key data.

Some containers (not Orion, I don't think) allow you to specify that
finders should lazy-load beans.  But this brings you back to BMP
performance.  Some containers allow you to define field groups to
minimize the amount of data brought back (especially useful if you store
blobs), but not Orion.

Personally, I don't understand why containers don't implement
Collections backed by the ResultSet directly.  98% of the time, the
client just creates an iterator and walks the results.  If the client
does something that the ResultSet can't support, build the full
Collection.

Jeff Schnitzer
[EMAIL PROTECTED]




RE: CMP 2.0 vs BMP - Which performes better?

2002-04-03 Thread Jeff Schnitzer

Huh?

There are several constraints to BMP beans which make them almost always
perform slower than CMP beans.  In particular, the inability to bulk
load beans from finder methods is a nearly fatal defect.

In general, I recommend a combination of CMP entities and raw JDBC in
session beans for queries that are not efficient or possible in a CMP
environment.

Just watch out for relationships in Orion.  They are horribly broken,
have been for years, and don't show any sign of getting better.

Jeff Schnitzer
[EMAIL PROTECTED]

 -Original Message-
 From: Andrew Chau [mailto:[EMAIL PROTECTED]]
 Sent: Friday, March 29, 2002 6:11 PM
 To: Orion-Interest
 Subject: RE: CMP 2.0 vs BMP - Which performes better?
 
 If performance is the only factor, BMP performs a million times faster
 than CMP. Well, may be not that much faster, but you get the point.
 
 CMP is for ease of development, basically the container does all the
 work for you, but it is not as flexible and you cannot fine tune the
 query like you can do in BMP.
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]] On Behalf Of Orion
 Newsgroup
 Sent: Thursday, March 28, 2002 2:40 PM
 To: Orion-Interest
 Subject: CMP 2.0 vs BMP - Which performes better?
 
 Subject: CMP 2.0 vs BMP - Which performes better?
 From: alt.cybercafes [EMAIL PROTECTED]
  ===
 I am in the process of building a database intensive app and wanted to
 know
 whether to use container manage persistance versus bean manage
 persistence
 for this database instensive application. What are the pros and cons
of
 CMP
 and BMP.?
 
 thanks
 
 
 
 
 





RE: Username and Password

2002-02-06 Thread Jeff Schnitzer

HttpServletRequest.getUserPrincipal().getName() should do the trick.

Jeff Schnitzer
[EMAIL PROTECTED]

 -Original Message-
 From: Christian, Joanne [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, February 06, 2002 9:30 AM
 To: Orion-Interest
 Subject: Username and Password
 
 HI All,
 
 I'm new to J2EE and Orion. I have set up form-based authorization
using
 DataSourceUserManager. Super!
 
 From my initial jsp and/or servlet (not the login page), I would like
to
 access the username of the person who just logged in.
 
 How can I do this?  I have tried to get attributes from the
ServletContext
 an the session. I have also tried various other things I'd rather not
 mention . . .
 
 So:
 How can I access the values of j_username and j_password once the user
has
 been logged in?
 
 Also, where and what is j_security_check?
 
 
 Thanks,
 
 Joanne





RE: automatic invocation of servlet as the root-service

2002-01-31 Thread Jeff Schnitzer

Create a default.jsp with either:

jsp:forward page=your/servlet/path/

or

% response.sendRedirect(your/servlet/path); %

depending on which fits your preference best.  I find that the redirect
is a bit better for debugging because jsp:forward munges any errors.

I never managed to configure Orion to use a servlet as the context root.
Nothing in the Servlet specification seems to require this be possible,
either.

Jeff Schnitzer
[EMAIL PROTECTED]

 -Original Message-
 From: Robert Virkus [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, January 31, 2002 12:27 PM
 To: Orion-Interest
 Cc: Orion-Interest
 Subject: Re: automatic invocation of servlet as the root-service
 
 Hello Igor  everyone out there,
 
 thanks for your help,
 I set the servlet-webdir to  in the orion-web.xml and set the
 welcome file in the WEB-INF/web.xml to my desired servlet
 (welcome-file-list
welcome-filecom.scaraboo.servlet.Loadbalancer/welcome-file
 /welcome-file-list)
 but if I surf to the root (eg. http://127.0.0.1), I just get a 403
 Forbidden
 Directory browsing not allowed-Message. If I browse
 http://127.0.0.1/com.scaraboo.servlet.Loadbalancer instead, my servlet
 is invoked as expected...
 
 As you know I'd like to have my serlvet invoked each time I enter the
 root of the server (like in http://127.0.0.1).
 
 any further ideas?
 
 thanks a lot!
- Robert
 
 
 
 
 Friday, February 01, 2002, 12:09:41 AM, you wrote:
 
 
 IC Hello, Robert .
 
 IC I sent to you the same message throw orion-interest e-mail(just
reply
 on your message), but I am not sure you received it or not.
 IC Try next:
 
 IC Go to \orion\application-deployments\YourApplication... directory
 created
 IC
 YourSubApplication...
 IC folder with
 IC  orion-web.xml
 where we
 IC can init
 
 IC servlet-webdir=/NameWebDir/
 IC Default is /servlet/
 IC You also can use: servlet-webdir=
 
 IC I hope it's help.
 
 IC Igor.
 
 IC Hello everybody!
 IC
 IC I hope someone can give me a hint for my problem:
 IC I want to try to use a servlet as the root of my web-application,
so
 I
 IC want the servlet/com.company.mystuff.MyServlet  - servlet called,
 when
 IC I do not specify any file in my http-request.
 IC
 IC So I want to map my servlet to the root of the web-application;
if I
 IC call www.mycompany.com I want to get to my servlet, rather than
 IC receiving default.jsp or index.html (or a directory-browsing not
 IC allowed - message).
 IC
 IC Thanks in advance for your help!!!
 
 --
 Robert Virkus
 scaraboo GmbH
 mobile Entertainment
 Georg-Wulf-Str.4-6
 28199 Bremen
 Germany
 phone  +49 - (0)421 - 59 67 549
 fax+49 - (0)421 - 59 67 567
 mobile +49 - (0)171 - 35 31 635
 [EMAIL PROTECTED]
 www.scaraboo.de
 wap.scaraboo.de
 
 
 Aus Rechts- und Sicherheitsgruenden ist die in dieser E-Mail gegebene
 Information nicht rechtsverbindlich. Eine rechtsverbindliche
Bestaetigung
 reichen wir Ihnen gerne auf Anforderung in schriftlicher Form nach.
 Beachten
 Sie bitte, dass jede Form der unautorisierten Nutzung,
Veroeffentlichung,
 Vervielfaeltigung oder Weitergabe des Inhalts dieser E-Mail nicht
 gestattet
 ist. Diese Nachricht ist ausschliesslich fuer den bezeichneten
Adressaten
 oder dessen Vertreter bestimmt. Sollten Sie nicht der vorgesehene
Adressat
 dieser E-Mail oder dessen Vertreter sein, so bitten wir Sie, sich mit
dem
 Absender der E-Mail in Verbindung zu setzen.
 
 For legal and security reasons the information provided in this e-mail
is
 not legally binding. Upon request we would be pleased to provide you
with
 a
 legally binding confirmation in written form. Any form of unauthorised
 use,
 publication, reproduction, copying or disclosure of the content of
this
 e-mail is not permitted. This message is exclusively for the person
 addressed or their representative. If you are not the intended
recipient
 of
 this message and its contents, please notify the sender immediately.
 





RE: Integrating LOG4J into Orion...

2002-01-19 Thread Jeff Schnitzer

I put the log4j.jar in orion's lib directory, and use
-Dlog4j.configuration=file:path/to/log4j.properties
to initialize log4j.  I'm pretty happy with this approach.  I control
logging on a server-wide basis, so I can use the same ear file for both
testing and deployment.

Jeff Schnitzer
[EMAIL PROTECTED]

 -Original Message-
 From: Alex Paransky [mailto:[EMAIL PROTECTED]]
 Sent: Friday, January 18, 2002 5:35 PM
 To: Orion-Interest
 Subject: FW: Integrating LOG4J into Orion...
 
 One more time, the last one did not show up
 
 -Original Message-
 From: Alex Paransky [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, January 17, 2002 11:09 AM
 To: Orion-Interest
 Subject: Integrating LOG4J into Orion...
 
 
 I have a full EJB/JSP application running with Orion.  Is there a
 preferred
 method of initializing LOG4J in this situation?
 
 Looking at the LOG4J documentation, they mention using a startup
servlet
 to
 do the initialization.  I am concerned as to how this would work with
the
 CLASSLOADER hierarchy.  If I initialize my LOG4J at the servlet (WEB)
 layer,
 will the EJB's be able to see the initialized LOG4J or will they
attempt
 to
 re-initialize due to the different classloader?
 
 Thanks.
 -AP_
 





List errors

2001-10-23 Thread Jeff Schnitzer

Does anyone else get You do not have permission to send to this
recipient. When attempting to send mail to this list?

Of course, if you're reading this, then it's allowing me to send *some*
traffic...

Jeff




RE: Problem implementing Custom User Management using SimpleUserManager

2001-10-02 Thread Jeff Schnitzer

I am also experiencing this - no matter what I try (and I'm pretty sure
I've tried everything), I cannot get an application client user to log
in using a custom user manager (either SimpleUserManager-derived or
DataSourceUserManager).

Note that the application client logs in just fine using admin or any
of the principals.xml users.  But I get the Invalid username/password
exception when trying users produced by the custom user manager.

This is with Orion 1.5.2.  Does anyone have application clients working
with a custom user manager?

Jeff

 -Original Message-
 From: Adam Maliborski [mailto:[EMAIL PROTECTED]]
 Sent: Saturday, September 29, 2001 7:09 AM
 To: Orion-Interest
 Subject: Problem implementing Custom User Management using
 SimpleUserManager
 
 Hi,
 
 I am trying to validate users of my ejb server via a database using
the
 SimpleUserManager.
 
 I have extended SimpleUserManager and overridden the three methods and
 confirmed that they are being called and returning true.
 
 I have made the following changes to the descriptors.
 
 ORION-APPLICATION.XML
 orion-application deployment-version=1.5.2
 
ejb-module remote=false path=ejb.jar /
web-module id=web path=web.war /
 
security-role-mapping name=administration
   group name=administration /
/security-role-mapping
security-role-mapping name=productbuilder
   group name=productbuilder /
/security-role-mapping
security-role-mapping name=enduser
   group name=enduser /
/security-role-mapping
persistence path=persistence /
library path=c:\test\ejb.jar /
principals path=principals.xml /
user-manager class=com.test.rms.user.orion.UCIServerUserManager
/
log
   file path=application.log /
/log
 
namespace-access
   read-access
  namespace-resource root=
 security-role-mapping name=lt;jndi-user-rolegt;
  group name=administration /
  group name=productbuilder /
  group name=enduser /
 /security-role-mapping
  /namespace-resource
   /read-access
   write-access
  namespace-resource root=
 security-role-mapping name=lt;jndi-user-rolegt;
  group name=administration /
  group name=productbuilder /
  group name=enduser /
 /security-role-mapping
  /namespace-resource
   /write-access
/namespace-access
 /orion-application
 
 PRINCIPALS.XML
 principals
groups
   group name=administration
  permission name=administration /
permission name=rmi:login /
  permission name=com.evermind.server.rmi.RMIPermission /
   /group
   group name=productbuilder
  permission name=rmi:login /
  permission name=com.evermind.server.rmi.RMIPermission /
   /group
   group name=enduser
permission name=rmi:login /
  permission name=com.evermind.server.rmi.RMIPermission /
   /group
/groups
users
/users
 /principals
 
 ORION-EJB-JAR.XML
 orion-ejb-jar deployment-version=1.5.2
deployment-time=e93e1950d0
enterprise-beans
   ..
   .. (EJB DECLARATION)
   ..
   assembly-descriptor
  security-role-mapping name=administration
  /security-role-mapping
  security-role-mapping name=productbuilder
  /security-role-mapping
  security-role-mapping name=enduser
  /security-role-mapping
  default-method-access
 security-role-mapping name=lt;default-ejb-caller-
 rolegt; impliesAll=true /
  /default-method-access
   /assembly-descriptor
 /orion-ejb-jar
 
 When I try to access the ejb server through an external java client
 using the following code :
 
 Properties prop = new Properties();
 prop.put
 (java.naming.factory.initial,
com.evermind.server.ApplicationClientIn
 itialContextFactory);
 
 prop.put(java.naming.provider.url, ormi://localhost/UCIServer);
 prop.put(java.naming.security.principal, adammal);
 prop.put(java.naming.security.credentials, adammal);
 
 Context initial = new InitialContext(prop);
 
 I get the following error :
 
 java.lang.SecurityException: Invalid username/password for UCIServer
 (adammal)
 at com.evermind._cd._mu(Unknown Source)
 at com.evermind._cd._mu(Unknown Source)
 at com.evermind._cd._np(Unknown Source)
 at com.evermind._ce._np(Unknown Source)
 at com.evermind.server.rmi.RMIContext.lookup(Unknown Source)
 at com.evermind.server.administration.LazyResourceFinder._np
 (Unknown Source)
 at
 com.evermind.server.administration.LazyResourceFinder.getEJBHome
 (Unknown Source)
 at com.evermind._ck._ho(Unknown Source)
 at

com.evermind.server.ApplicationClientInitialContextFactory.getInitialCon
 text(Unknown Source)
 at javax.naming.spi.NamingManager.getInitialContext
 (NamingManager.java:668)
 at javax.naming.InitialContext.getDefaultInitCtx
 

RE: Does orion support XSLT

2001-08-31 Thread Jeff Schnitzer

There is an XSLT filter in place by default that automatically processes
XML documents that reference a stylesheet in the header like this:

?xml-stylesheet href=doc.xsl type=text/xsl?

See the directory default-web-app/examples/xsl for some simple examples.

However, this is pretty primitive.  If you want to be able to configure
a pipeline of transformations, or work with dynamic content, I suggest
looking at the Maverick MVC framework:  http://mav.sourceforge.net.

Jeff Schnitzer
[EMAIL PROTECTED]

 -Original Message-
 From: Shah, Ritesh [mailto:[EMAIL PROTECTED]]
 Sent: Friday, August 31, 2001 11:52 AM
 To: Orion-Interest
 Subject: Does orion support XSLT
 Importance: High
 
 Hi,
 I was trying to find any help on XSL for orion application server.
On
 the site www.orionserver.com it does say they have
 Lots of additional features
 XML/XSLT processing
 
 but when I try to go through there documentation I didn't find any
link
 related to XSLT/XML.
 Now I feel does it support XSLT/XML. If yes then where can I find all
 documentation regarding configuration and implementation of XSLT/XML
for
 orion server
 Please help me out.
 
 Thanks
 -Ritesh
 
 
 





RE: 2 parameter finder finding wrong thing

2001-07-09 Thread Jeff Schnitzer

EJB-QL is not yet implemented in Orion.  Try this:

http://www.c2.com/cgi/wiki?OrionServerSpecSupport

Note that Orion will automatically create finders with a single
parameter that corresponds to the name of a cmp field.  Otherwise you
have to write them yourself.

Jeff Schnitzer
[EMAIL PROTECTED]

 -Original Message-
 From: Kit Cragin [mailto:[EMAIL PROTECTED]]
 Sent: Sunday, July 08, 2001 10:30 AM
 To: Orion-Interest
 Subject: 2 parameter finder finding wrong thing
 
 I am using EJB 2.0 and have a finder method that takes 2 parameters
(e.g.
 the WHERE clause looks something like WHERE columnOne = ?1 AND
columnTwo
 =
 ?2).
 
 No matter what I do, it does not return the right entity. I have tried
 single-object return, Collection return, narrowing, not narrowing,
 checking
 parameters, etc.
 
 I am running Orion 1.4.7 on HypersonicSQL for my testbed. Any ideas?
 
 Kit Cragin
 VP of Product Development
 Mongoose Technology, Inc.
 www.mongoosetech.com
 





RE: Features of CMP

2001-06-24 Thread Jeff Schnitzer

Try this:

http://www.c2.com/cgi/wiki?OrionServerSpecSupport

Please update it as well.

Jeff

 -Original Message-
 From: Stefan Marx [mailto:[EMAIL PROTECTED]]
 Sent: Friday, June 22, 2001 4:47 AM
 To: Orion-Interest
 Subject: Features of CMP
 
 
 Hi,
 
 Is there any List available which features ar implemented in 
 Orion 1.5.2.
 
 I have some special interest in the implementation of the EJB 
 QL (Chapter 11
 in the EJB2.0 Spec).
 
 Thanks Stefan
 
 
 




RE: Collection or list as return ??

2001-06-15 Thread Jeff Schnitzer

You're right, there is no guarantee from the spec that other app servers
will return data in order or even allow you to specify the ORDER BY
clause in the finder sql.  For that matter, there is no guarantee that
the database has a sql interface.

It gets even worse.  The current spec for EJB-QL has no support for
ordering.  The *only* way to write a 100% spec-compliant app which does
ordering is to implement the sorting yourself, in application code, in
Java.

It's pretty obvious to me at least that the people developing the EJB
specification have never actually used their ideas to develop a real
world application.  Fortunately for us, container vendors are less
insulated from the eventual customers; it's a pretty safe bet that most
servers will let you configure the ordering in the database query
somehow.  I wouldn't worry about it, but no, it's not standard.

Jeff Schnitzer

 -Original Message-
 From: Eddie Post [mailto:[EMAIL PROTECTED]]
 Sent: Friday, June 15, 2001 3:48 PM
 To: Orion-Interest
 Subject: Re: Collection or list as return ??
 
 
 Thanks Scott,
 
 Thanks for the test (stupid that I didn't thought about that 
 ;) ). So, yes 
 the returned Collection (read: ArrayList) is a sorted one.
 But how general is this, as I can't find anything in the J2EE 
 spec about 
 this and is it possible that Orion will change this such that 
 it isn't 
 sorted anymore ?
 
 
 What do you think ? Let the DB do the order by or just let 
 the sort method 
 of Collections do the trick ? I have noticed that the sort 
 method is very 
 fast.
 
 
 Eddie
 
 
 
 From: Scot Weber [EMAIL PROTECTED]
 Reply-To: Orion-Interest [EMAIL PROTECTED]
 To: Orion-Interest [EMAIL PROTECTED]
 Subject: Re: Collection or list as return ??
 Date: Fri, 15 Jun 2001 12:15:46 -0700
 
 Eddie,
 
I just tested it . . .
 
 MyTestHome.java __
 
public interface MyTestHome {
 
  
  public Collection findAll () ...
 
}
 
 mytest.jsp__
 

 
%= myTestHome.findall ().getClass () %
 
 output_
 
java.util.ArrayList
 
 peace - scot
 
   Eddie wrote:
  
   Hellu there,
  
   Some time ago someone made a remark that it make no sense 
 putting a
   ORDER
   BY in the where clause in the orion-ejb-jar.xml, as the finder
   methods of
   the home interface do return a Collection, which are not sorted by
   definition.
  
   Hmmm makes sence, but if I play around with it and put a 
 ORDER BY id
   ASC
   or ORDER BY id DESC in the where clause in the 
 orion-ejb-jar.xml, to
   fine
   tune some queries, it does  return sorted collections 
  
   Howcome ?? Does the finder methods return a  sorted List as a J2EE
   feature,
   that is a subClass of a Collection, or is this just Orion. ??
  
   The thing is that I like to optimize my queries, but if 
 this feature
   isn't
   J2EE for example I will have a problem with the following 
 upgrades if
   it's
   left out for some reason !!
  
   BTW: in the J2EE spec, in section 10.5.6 they only talk about the
   Collection
   data type.!!
  
   Some advise please ??
   Eddie
 
 --
 
scot weber - [EMAIL PROTECTED]
-
Given a choice between a folly and a sacrament, one should
always choose the folly -- because we know a sacrament
will not bring us closer to God and there's always a chance
that a folly will. - Erasmus
 
The only man who never makes a mistake is the man who
never does anything. - Theodore Roosevelt.
 
 
 __
 ___
 Get Your Private, Free E-mail from MSN Hotmail at 
http://www.hotmail.com.






RE: Counting CMP entities

2001-06-14 Thread Jeff Schnitzer

It's not necessarily true that findAll().size() would be expensive.  A
slick container implementation would delay the actual query until the
first method call on the Collection.  If size() is the first method
called, the container could easily perform the proper select count(*).
 
The question then becomes, how slick is Orion's implementation of CMP
finders?
 
I just ran a test and discovered that Orion doesn't do this.  Oh well.
Maybe it should be logged in bugzilla as an enhancement.
 
Jeff
 

-Original Message-
From: Russ White [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 14, 2001 6:00 AM
To: Orion-Interest
Subject: Re: Counting CMP entities


That would work fine but would be very expensive.
 
I would create a getCount() method and have that method do a simple JDBC
call and return the count. This way the container does not have the
added overhead of creating/marshalling the collection.
 

- Original Message - 
From: elephantwalker mailto:[EMAIL PROTECTED]  
To: Orion-Interest mailto:[EMAIL PROTECTED]  
Sent: Wednesday, June 13, 2001 6:56 PM
Subject: RE: Counting CMP entities

Sergei,
 
Do a findAll() ,you get a collection. Then do a result.size(), that
should do it.
 
Regards,
 
the elephantwalker
 

-Original Message-
From: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Sergei Batiuk
Sent: Tuesday, June 13, 2000 3:25 PM
To: Orion-Interest
Subject: Counting CMP entities


Is it possible to count the number of records in a table with a CMP?
 
WBR,
Sergei





RE: Oracle deal gag

2001-06-12 Thread Jeff Schnitzer

 From: Jay Armstrong [mailto:[EMAIL PROTECTED]]
 
 Seriously, smartass, I'd like a 'yes' or 'no' answer from you: do you
 really think the CIA doesn't monitor the web?

I'm not a smartass.  I'm just out to get you :-)

From Catch-22:

They're trying to kill me, Yossarian told him calmly.
No one's trying to kill you, Clevinger cried.
Then why are they shooting at me? Yossarian asked.
They're shooting at *everyone*, Clevinger answered.  They're
trying to kill everyone.
And what difference does that make?

The difference between cynicism and paranoia is the difference between:

The CIA is monitoring email on the internet.
The CIA is monitoring *my* email on the internet.


I can, with almost complete confidence, assure you that nobody at
Ironflare is censoring your email.  From longtime observation of this
list, I have discovered that the mailing list software Sucks Bigtime.
I'm sorry to say this, because someone at Ironflare probably put a
significant amount of time into it in a noble but misguided attempt to
show off the Orion server.  Unfortunately natural brilliance and a
thorough understanding of J2EE do not automatically translate into
detailed knowledge of ESMTP and the specific manner in which the
hundreds of mail agents out there butcher it.  The consequence is that
with *frequent* occurance mail is lost, mail is delivered out of order,
the list blacks out for weekends at a time, vacation messages get sent
to everyone, mail senders get back dozens of bounce messages, etc.  I
started that thread you mentioned (Orion Team Needs New List
Software), and it's still very much true.  I suspect that vanity
prevents Ironflare from converting to Mailman or some other mature
package.

As to why Karl never responded to your message about licensing
violation, hey, maybe he's too busy working on the broken list software.
Or more likely, Orion.  Think about it.  What's a two-person company in
Sweden going to do about somebody 10,000 miles away abusing a $1500
license?  The practical limitations of enforcement pretty much mean that
anyone that wants to can steal the software.  For a small company and a
relatively inexpensive product you just have to hope that there are
enough honest customers out there to pay your bills.  Fortunately it
looks like there are.


I don't understand why you think the Oracle deal is anything but a
fanstastic coup for both us (the Orion community) and Ironflare.  It
validates the product, puts a significant amount of $$$ in the pockets
of Karl  Magnus, makes it a lot easier for us to sell Orion to
clients, and *radically* increases our market value as experts with The
Oracle J2EE Solution as well as the obscure Swedish app server we know
and love.  Larry and Karl make a deal, and suddenly my resume gets a
steroid injection!  I couldn't be happier!

Will Oracle draw from this community?  Send them a resume and find out!
What kind of validation are you looking for?  Sure we (the users) spend
a lot of time debugging the app server - but hey, nobody is forcing us
to run the autoupdater.  And a lot of people, myself included, consider
this just the least we can offer to Ironflare for providing us with a
free server.  Free for noncommercial use has bought them a lot more
than $1500 worth of my time, and I'm quite content about it.


Jeff Schnitzer
[EMAIL PROTECTED]




RE: Oracle deal gag

2001-06-10 Thread Jeff Schnitzer

 From: Jay Armstrong [mailto:[EMAIL PROTECTED]]

 [...paranoia...]
 

Have you ever considered that maybe your communications are being
intercepted and preprocessed by a CIA computer?  Do you hear clicking
noises every time you pick up the phone?

You have accidentally sumbled across The Swedish Conspiracy.  Ironflare
is actually a front company for arms smuggling:  It is a little known
fact that Larry Ellison converted to a radical reactionary Islamic sect
recently.  Oracle purchases app servers from Ironflare, Ironflare uses
the money to purchase Kalishnakov rifles from nearby Russia, and a
renegade CIA group smuggles them into Afghanistan to support the
Taliban.  Magnus and Karl are ficticious identities; in fact their names
are acronyms for Make Arms Gifts Neglecting Upgrading Software and
Keep Armstrong's Replies Limited.

Now that you have now exposed yourself and your knowledge, the Men In
Black will be coming for you soon.  Good luck!


Jeff Schnitzer




RE: 1.5.1 vs 1.4.7 RequestDispatcher

2001-05-30 Thread Jeff Schnitzer

I am definitely experiencing something very similar.  I haven't tried it
with a version of Orion prior to 1.4.8, but I find that using
RequestDispatcher.forward() produces erratic results, usually without
sending any output.  I find that calling include() works as advertised.

The exact same code with forward() works fine with Tomcat4.  I logged
bug #482 about this.  It would probably help if you added more
information:
http://bugzilla.orionserver.com/bugzilla/show_bug.cgi?id=482

I will try 1.4.7 and see if it works.  BTW, I'm using an
HttpServletResponseWrapper subclass; I haven't tried without a wrapper
to see if it works.

Jeff

 -Original Message-
 From: Kit Cragin [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, May 30, 2001 11:49 AM
 To: Orion-Interest
 Subject: 1.5.1 vs 1.4.7 RequestDispatcher
 
 
 Is there something that changed between 1.5.1 and 1.4.7 that broke my
 forward() requests?
 
 I have a servlet mapped to /start and protected by a role, user, in
 web.xml. The servlet obtains a RequestDispatcher to 
 /roles/user/index.jsp.
 This JSP has an iframe that loads /roles/user/content.html.
 
 Under 1.4.7 when I do http://localhost/webapp/start I got a 
 login prompt as
 expected and everything shows up correctly. Under 1.5.1, the 
 same URL causes
 3 login prompts. On the last one, I get a 401 unauthorized on 
 content.html.
 Anyone know why this could be occuring?
 
 Thanks,
 
 Kit Cragin
 VP of Product Development
 Mongoose Technology, Inc.
 www.mongoosetech.com
 
 
 




RE: Tracing SQL

2001-05-29 Thread Jeff Schnitzer

I don't believe there is any way to force Orion to spit out that
information.  However, when running against Hypersonic in server mode,
you see all the SQL on the database console.  I find this to be an
excellent arrangement for development.

If you wanted to, you could fairly easily write a JDBC wrapper that
prints the SQL.  I wouldn't be surprised if someone has already written
such a creature.

Jeff

 -Original Message-
 From: Koster, K.J. [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, May 29, 2001 1:03 PM
 To: Orion-Interest
 Subject: Tracing SQL
 
 
 Dear All,
 
 I'm having some trouble finding what Orion is doing in my 
 databases. I get
 truncated data without any error messages.
 
 How can I see what SQL statements Orion executes? (MySQL, 
 with the mm-mysql
 driver, if that matters).
 
 When I have a Java long datatype for a CMP property on an 
 enity bean. It's
 mapped to int(11) in the database. How come the values are 
 truncated? Who is
 clipping my longs?
 
 Kees Jan
 
 
  You are only young once,
but you can stay immature all your life.
 
 
 




RE: Struts help?

2001-05-24 Thread Jeff Schnitzer

Struts doesn't work out of the box with Orion versions prior to 1.4.8.
The message resources problem is that when re-implementing the
ResouceBundle (for reasons nobody on the struts list could tell me),
Struts used a method on the Orion classloader that was not implemented
(getResourceAsStream).

Run the autoupdate and Struts will work fine.  You might have other
problems, though (autoupdate versions are experimental).

Or you might want to use the Maverick framework, which works well with
JSP and is a lot simpler than Struts:  http://mav.sourceforge.net

Good luck,
Jeff

-Original Message-
From: Chad Stansbury [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 24, 2001 6:43 AM
To: Orion-Interest
Subject: Re: Struts help?


Sorry, it was rushed when I sent the original message and forgot to
include this information...  

Anyway, I'm using Orion 1.4.5 'out of the box' and struts 1.0-b2, also
'out of the box'.  

I'm getting two distinct error messages - one is that the jndi protocol
is not recognized (due to struts looking for the struts DTD using a
jndi://-based URL), and the second is that it 'Cannot find message
resources under key org.apache.struts.action.MESSAGE'.

Any help would be appreciated.

Chad Stansbury
- Original Message - 
From: Grama Bogdan 
To: '[EMAIL PROTECTED]' 
Sent: Thursday, May 24, 2001 12:32 AM
Subject: RE: Struts help?


What version of orion do you have?
Bigdan.
-Original Message-
From: Chad Stansbury [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 24, 2001 3:04 AM
To: Orion-Interest
Subject: Struts help?


Hello -

I'm having a little trouble getting the struts-example application
working... and before I spend a lot of time trying to do so, I'd like to
know if anyone else has already expended the effort.  Has anyone got
some experience with Struts  Orion?

Thanks in Advance,

Chad Stansbury




RE: Deployment to multiple instances...?

2001-05-17 Thread Jeff Schnitzer

Furthermore, rather than having multiple web.xml files, you can use
Ant's style task to apply transforms to the base web.xml.  Then all
you need are xsl files which contain the different context parameters.
With a little XSLT knowledge, it's really easy to do.

A simpler approach, though, would be to define propeties with the -D
option to the JVM.

Jeff

 -Original Message-
 From: Reid Hartenbower [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, May 17, 2001 1:19 PM
 To: Orion-Interest
 Subject: Re: Deployment to multiple instances...?
 
 
 This might not be the solution you're looking for, but you 
 could use ant and
 specifiy your different deployments as different targets.  
 This would at
 least give you a central place to build from, and because ant 
 knows about
 .war packaging and supports FTP, theoretically (because I 
 have not done this
 myself) you can do all you're looking for with build scripts.
 
 - Original Message -
 From: Attila Bodis [EMAIL PROTECTED]
 To: Orion-Interest [EMAIL PROTECTED]
 Sent: Thursday, May 17, 2001 10:57 AM
 Subject: Deployment to multiple instances...?
 
 
  Hi,
 
  This is a newbie question, I guess...  Here is the situation:
 
  I have a web application (a bunch of servlets, JSPs, and supporting
 classes)
  I want to deploy to multiple Orion instances.  Some of 
 these instances are
  for QA, some are inside the firewall, and some are outside 
 the firewall.
 My
  application has external dependencies on databases and files in the
  filesystem that are not part of the application itself.  Rather than
  hard-code these values, I include them as context-params in
  WEB-INF/web.xml.
 
  Ideally, I'd like to be able to build my web application on 
 my development
  machine, package it as a WAR file, and deploy it by just 
 FTPing the WAR
 into
  the appropriate directory on my various Orion instances.  
 The problem is,
 my
  configuration parameters are in WEB-INF/web.xml, which is 
 inside the WAR
  file.  These configuration parameters have to be different for my
 different
  instances (e.g. different directory structure, different database
 connection
  parameters, etc.).  But the web.xml file inside the WAR file always
  overwrites the one already deployed, which means each time 
 I distribute my
  WAR file to my different instances, I have to 1) wait for Orion to
  auto-unpack the archive, then 2) manually change the settings in
  WEB-INF/web.xml on each instance.
 
  Of course if I avoid putting container-specific (i.e. deployment
  environment-specific) parameters in WEB-INF/web.xml, then 
 the same web.xml
  will work on all of my various instances.  But then where 
 do I put config
  parameters such as log level, log file directory, and path to
  my-secret-files, etc., which are used by the application 
 but are specific
  to the particular deployment environment?
 
  Does Orion provide a way to specify config parameters for 
 an application
 on
  a per-container basis?
 
  Thanks,
 
  Attila
 
 
 
 
 




RE: Standar Template

2001-05-17 Thread Jeff Schnitzer

We finally released our framework, so I have some breathing time now :-)
I'd love to take a look to see if we can find synergy.  The only caveat
is that I would like to avoid GPL; code would need an MIT/BSD/Apache (or
equivalent) license.

If you're interested, take a look at Maverick:

http://mav.sourceforge.net

Later!

Jeff

 -Original Message-
 From: Daniel Lopez [mailto:[EMAIL PROTECTED]]
 Sent: Friday, May 11, 2001 12:27 AM
 To: Orion-Interest
 Subject: Re: Standar Template
 
 
 Hi,
 I haven't looked much into SiteMesh, but, just looking at the 
 overview,
 it seems to me that you still have to generate the content of the
 different sites that you want to mesh, and if they look totally
 different then you are out of luck.
 We are using the same approach that Jeff is talking about and we don't
 consider XML/XSL to be that slow, as using precompiled stylesheets we
 boosted aour performance by a factor of three and the heaviest
 operation is accesing the database. As XSLT implementations 
 improve day
 by day, I hope this will be less of a problem in the future. And using
 XML as the common ground is, IMHO, a very good approach to integrating
 different applications as you can use common stylesheets to integrate
 the different sources.
 But I won't pretend it is a perfect solution or that everybody should
 use it. That's what we use because it fits well into our team and
 requirements. And, Jeff, we also created our own framework to 
 basically
 allow us to get the XLM content from various sources, 
 including directly
 from PLSQL, so if you want we could talk about it privately. 
 We GPLd our
 framework but we haven't publicized it as we don't have much 
 time to do
 so.
 Just my 2c,
 Dan
 
 
 
 Mike Cannon-Brookes wrote:
  
  Noo - XML/XSL is too slow / fugly to actually use day 
 to day (IMHO)
  
  I'd advise you to check out SiteMesh - it's built for this 
 exact purpose!
  
  http://www.opensymphony.com/sitemesh
  
  Quite simply you provide JSP based decorators which are 
 mapped to URIs.
  
  Download and install the sample app, it's the only way to 
 learn about it.
  
  $10 says you're using it within a week ;)
  
  -mike
  
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED]]On Behalf Of 
 Jeff Schnitzer
   Sent: Friday, May 11, 2001 7:12 AM
   To: Orion-Interest
   Subject: RE: Standar Template
  
  
   I've iterated through several solutions to this problem 
 and can offer
   some advice:
  
   I started out using option 1 as you describe.  I quickly 
 noticed that
   *every* page contains the definition of the layout and look of the
   website.  What if I wanted to put the navigation bar on the right
   instead of the left?  I would have to modify *every 
 single page* in my
   website.  Yuck.
  
  
   My next step was to put the container code in separate 
 head/foot JSP
   files and @include them like this:
  
   %@ include file=head_stuff.jsp %
   p
 My content
   /p
   %@ include file=foot_stuff.jsp %
  
   Which at least puts all the look and feel stuff in a 
 handful of places.
   But my site has different templates for the logged in 
 user vs the
   welcome/signup screens and a few other special cases as well.  It
   quickly became a pain to keep track of all the different 
 headers and
   footers, and in any case opening tags in one file and 
 closing them in
   another really sucks.  Yuck.
  
  
   Next step was option 2 as you describe.  I created
   template_inside.jsp, template_outside.jsp, etc which 
 contain all the
   layout structure and then include the appropriate content 
 file based on
   a parameter.  Since I'm using an MVC framework, this is 
 pretty easy to
   do.
  
   This is the best option I've described so far, and it 
 works.  But it's
   not very sophisticated, and it doesn't make having 
 multiple layers very
   easy.  Fortunately I'm working on my own time, so now I'm 
 moving on to
   the fourth generation of my website content:
  
  
   This sort of templating is where XSLT really shines.  Rather than
   creating templating layers from the top down, XSLT allows 
 you to start
   at the bottom and build up, successively transforming the input.
   Wrapping (in a layout template) is just one kind of 
 transformation.
   Each step has no need to know anything specific about the 
 previous step;
   it's all just based on transformation rules.
  
   I'm still near the bottom of the XSLT learning curve, but 
 I'm already
   amazed at how powerful it is.  It's also a lot easier to 
 pick up than I
   had expected from first looking at a sample.
  
   The only problem with using XSLT in a web application is 
 the lack of
   framework support.  Cocoon did not make a favorable 
 impression on me (to
   say the least).  I wanted something that provides a 
 simple MVC paradigm
   like WebWork or (not-so-simple) Struts but uses XSLT for the view
   templating.  So I (and a friend) sat down and wrote it.  
 Tomorrow

ANN: Maverick MVC framework (w/XSLT support) released!

2001-05-17 Thread Jeff Schnitzer

http://mav.sourceforge.net

The MVC framework that a friend and I have been working on is finally
ready for public consumption.  What's cool about Maverick can pretty
much be summed up by this snippet from a hypothetical config file:

  command id=statistics
controller type=org.infohazard.foo.controller.Stats /

view id=error
  source-documentunavailable.xml/source-document
  pipeline
transform src=lookAndFeel.xsl /
  /pipeline
/view

view id=success
  source-model node=stats/
  pipeline
transform src=statistics.xsl /
transform src=lookAndFeel.xsl /
  /pipeline
/view
  /command

This shows a command that uses a controller to perform some processing
(bean properties on the controller are automatically populated from the
request parameters) and that can return one of two defined views.  The
success view wraps the JavaBeans model obtained from the controller in
an adapter pattern which provides a DOM facade to the XSLT engine.

Key points:

. No need for intermediate templating languages like JSP or XSP to
generate XML prior to transformation.  An adapter provides a DOM
representation of an arbitrary graph of JavaBeans through reflection.

. You can define as many transformations per view as you like.

. You can stop the transformation at any point (including prior to any
transformation) and obtain the XML representation.  XSLT designers can
then work with offline content.

. You can still use traditional JSP pages just like you can with Struts,
with the model being placed in an attribute collection for use by
jsp:useBean.  If they generate XML, the pipeline facility is
available.

. Extensively tested with Orion :-)

This is version 0.8, the first public release.  Feedback is appreciated!

http://mav.sourceforge.net

Enjoy :-)

Jeff Schnitzer
[EMAIL PROTECTED]
Scott Hernandez
[EMAIL PROTECTED]




RE: Standar Template

2001-05-17 Thread Jeff Schnitzer

Oops.  Sorry everyone, that was not supposed to be posted to the list.

Jeff

 -Original Message-
 From: Jeff Schnitzer 
 Sent: Thursday, May 17, 2001 8:47 PM
 To: Orion-Interest
 Subject: RE: Standar Template
 
 
 We finally released our framework, so I have some breathing 
 time now :-)
 I'd love to take a look to see if we can find synergy.  The 
 only caveat
 is that I would like to avoid GPL; code would need an 
 MIT/BSD/Apache (or
 equivalent) license.
 
 If you're interested, take a look at Maverick:
 
 http://mav.sourceforge.net
 
 Later!
 
 Jeff
 
  -Original Message-
  From: Daniel Lopez [mailto:[EMAIL PROTECTED]]
  Sent: Friday, May 11, 2001 12:27 AM
  To: Orion-Interest
  Subject: Re: Standar Template
  
  
  Hi,
  I haven't looked much into SiteMesh, but, just looking at the 
  overview,
  it seems to me that you still have to generate the content of the
  different sites that you want to mesh, and if they look totally
  different then you are out of luck.
  We are using the same approach that Jeff is talking about 
 and we don't
  consider XML/XSL to be that slow, as using precompiled 
 stylesheets we
  boosted aour performance by a factor of three and the heaviest
  operation is accesing the database. As XSLT implementations 
  improve day
  by day, I hope this will be less of a problem in the 
 future. And using
  XML as the common ground is, IMHO, a very good approach to 
 integrating
  different applications as you can use common stylesheets to 
 integrate
  the different sources.
  But I won't pretend it is a perfect solution or that 
 everybody should
  use it. That's what we use because it fits well into our team and
  requirements. And, Jeff, we also created our own framework to 
  basically
  allow us to get the XLM content from various sources, 
  including directly
  from PLSQL, so if you want we could talk about it privately. 
  We GPLd our
  framework but we haven't publicized it as we don't have much 
  time to do
  so.
  Just my 2c,
  Dan
  
  
  
  Mike Cannon-Brookes wrote:
   
   Noo - XML/XSL is too slow / fugly to actually use day 
  to day (IMHO)
   
   I'd advise you to check out SiteMesh - it's built for this 
  exact purpose!
   
   http://www.opensymphony.com/sitemesh
   
   Quite simply you provide JSP based decorators which are 
  mapped to URIs.
   
   Download and install the sample app, it's the only way to 
  learn about it.
   
   $10 says you're using it within a week ;)
   
   -mike
   
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of 
  Jeff Schnitzer
Sent: Friday, May 11, 2001 7:12 AM
To: Orion-Interest
Subject: RE: Standar Template
   
   
I've iterated through several solutions to this problem 
  and can offer
some advice:
   
I started out using option 1 as you describe.  I quickly 
  noticed that
*every* page contains the definition of the layout and 
 look of the
website.  What if I wanted to put the navigation bar on 
 the right
instead of the left?  I would have to modify *every 
  single page* in my
website.  Yuck.
   
   
My next step was to put the container code in separate 
  head/foot JSP
files and @include them like this:
   
%@ include file=head_stuff.jsp %
p
  My content
/p
%@ include file=foot_stuff.jsp %
   
Which at least puts all the look and feel stuff in a 
  handful of places.
But my site has different templates for the logged in 
  user vs the
welcome/signup screens and a few other special cases as 
 well.  It
quickly became a pain to keep track of all the different 
  headers and
footers, and in any case opening tags in one file and 
  closing them in
another really sucks.  Yuck.
   
   
Next step was option 2 as you describe.  I created
template_inside.jsp, template_outside.jsp, etc which 
  contain all the
layout structure and then include the appropriate content 
  file based on
a parameter.  Since I'm using an MVC framework, this is 
  pretty easy to
do.
   
This is the best option I've described so far, and it 
  works.  But it's
not very sophisticated, and it doesn't make having 
  multiple layers very
easy.  Fortunately I'm working on my own time, so now I'm 
  moving on to
the fourth generation of my website content:
   
   
This sort of templating is where XSLT really shines.  
 Rather than
creating templating layers from the top down, XSLT allows 
  you to start
at the bottom and build up, successively transforming the input.
Wrapping (in a layout template) is just one kind of 
  transformation.
Each step has no need to know anything specific about the 
  previous step;
it's all just based on transformation rules.
   
I'm still near the bottom of the XSLT learning curve, but 
  I'm already
amazed at how powerful it is.  It's also a lot easier to 
  pick up than I
had expected from

RE: Caching XLS style sheets

2001-05-15 Thread Jeff Schnitzer

It's *almost* ready for release... the framework has reached a pretty
stable state, but the example application (a simple contact-list book)
keeps getting more sophisticated :-)

Jeff

 -Original Message-
 From: Arthur Copeland (Saphari.com - www.saphari.com)
 [mailto:[EMAIL PROTECTED]]
 Sent: Monday, May 14, 2001 1:12 PM
 To: Orion-Interest
 Cc: Jeff Schnitzer
 Subject: RE: Caching XLS style sheets
 
 
 i am VERY interested..
 
 
 artie
 
 Quoting Jeff Schnitzer [EMAIL PROTECTED]:
 
  Excel stylesheets?  Perhaps you mean XSL :-)
 
  If you use the JAXP 1.1 transforms api, creating a 
 Templates object
  should produce a precompiled version of an XSLT.  
 Although this will
  be completely dependent on implementation, I don't 
 believe any
  implementations actually compile to bytecode - really 
 precompiled
  means preparsed and maybe stored in a format for 
 efficient processing.
 
  On a related note:
 
  A friend and I are nearly finished constructing a 
 simple MVC framework
  with sophisticated XSLT support.  We will be 
 publishing it with an
  Apache-style license in about a week.  Cool things 
 this framework does:
 
  . Output from a view can be run through a 
 config-defined sequence of
  iterative XSLT transformations.
 
  . The JavaBeans model returned from a command can be 
 automagically
  adapted to a DOM for XSLT transformation without JSP, 
 XSP, or any other
  templating language.  Efficiently go directly from 
 java beans to XSLT.
 
  . The transformation process can be halted at any 
 step, allowing the
  XSLT creators/designers to work from static XML 
 generated from the
  previous step(s).
 
  . Other templating systems can be used to feed input 
 to the
  transformation process, including JSP and Velocity.  
 Plain XML inputs
  can be used as well.
 
  . XSLT transformations are not required.  It's still 
 an elegant MVC
  framework for simple JSP/Velocity/? - HTML 
 processing.
 
  I've attached an example configuration file so you can 
 see the kinds of
  things you can do with the framework.
 
 
  Is anyone interested?
 
  Jeff Schnitzer
  [EMAIL PROTECTED]
  http://www.similarity.com
  http://www.infohazard.org/junitee
 
  -Original Message-
  From: Vic Cekvenich [mailto:[EMAIL PROTECTED]]
  Sent: Sunday, May 06, 2001 5:55 PM
  To: Orion-Interest
  Subject: Caching XLS style sheets
 
 
  I asked a question on an MVC application architecture 
 using XLS, and got
  advice to cache XLS / XSLT style sheets, and pre 
 compile them.
 
  Can someone give me some more background on this.
  How?
  What if the content is dynamic? (2 million items and 
 100,000  of styles
  + with any combination)
 
  Thanks in advance,  
  Vic
  
 




RE: Database column creation order when using compound keys

2001-05-14 Thread Jeff Schnitzer

The order should be determined by the elements in the orion-ejb-jar.xml
deployment descriptor.

Unfortunately there is a bug in 1.4.5 which causes the order of compound
PK fields to switch on every deployment.  It was fixed in 1.4.6.  See
bug #242.

There is another similar problem in 1.4.8 which my test project
discovered, but my normal application works fine, so I haven't spent a
lot of time worrying about it :-)  Take a look at bug #413.

Jeff

 -Original Message-
 From: Erwin Teseling [mailto:[EMAIL PROTECTED]]
 Sent: Monday, May 14, 2001 8:41 AM
 To: Orion-Interest
 Subject: Database column creation order when using compound keys
 
 
 Hello everybody,
 
 I am having some problems regarding the order in which Orion 
 creates the 
 database columns for compound keys for an entity bean when using CMP. 
 
 I have an entity bean that models a many-to-many 
 relationship, which has 
 a compound key (subscriptionID  userID). Now when creating 
 the database 
 tables Orion seems to be inconsistent on the order in which 
 these two are 
 mapped on the database table. On one machine subscriptionID 
 is mapped on 
 the first column and on another machine (or at another time) 
 userID is 
 mapped on the first column (and subscriptionID on the second). 
 
 Now when I fill my database with a very simple SQL script 
 sometimes my 
 data gets mixed up because it fills the wrong column with the 
 wrong data. 
 Offcourse I can fixs this in the script, but is there a way 
 to tell Orion 
 which field should mapp to which column in the columns to be 
 created in 
 the database??
 
 Thanks!
 
 Regards,
 Erwin Teseling
 
 




RE: Generating primary keys

2001-05-14 Thread Jeff Schnitzer

If you're required to use triggers (or some other database-specific
mechanism) to generate primary keys, someone posted a clever solution to
this list a long time back:  use a finder method.  Since you control the
SQL issued for a finder method, just add a
 
Thingie findNew(Type param, Type param);
 
method and have it create the appropriate row in the SQL before
selecting it out.
 
 
BTW, the counter.jar is *not* portable.  It relies on pessimistic
concurrency behavior, and as far as I know the only other appserver
which supports this model is WebLogic when not clustered.  Even in WL 6,
the default behavior is now optimistic concurrency.
 
 
Here's a direct link to Brett's article about sequences (the original
link has moved on to other topics):
http://www.flashline.com/content/mclaughlin/bm050701.jsp?sid=98987171807
8-1066877012-153
http://www.flashline.com/content/mclaughlin/bm050701.jsp?sid=9898717180
78-1066877012-153 
 
This is, I believe, the *only* portable way of generating sequence-type
keys in EJBland.  It astounds me that this is the case given that a)
nearly every database offers some sort of facility for generating keys
and b) the EJB container could fake it for the ones that don't.
Considering how common the need to generate primary keys is, I consider
this an grossly unacceptable deficiency in the spec.  I'm not normally
prone to believing conspiracy theories, but I have to wonder if the big
RDBMS vendors sitting on the EJB committee (read: Oracle and IBM) are
deliberately trying to keep CMP from becoming too popular.  This is just
too wierd.
 
Jeff Schnitzer
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 
http://www.similarity.com
 

-Original Message-
From: elephantwalker [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 14, 2001 8:38 AM
To: Orion-Interest
Subject: RE: Generating primary keys


two ways of doing this...
 
1. map your ejb pk to another ejb. The counter.jar does this. It creates
a long for every beantype. See the faq at www.orionserver.com
http://www.orionserver.com . I think there is something under
http://www.orionsupport.com/articles/ejbuniquecounter.html
http://www.orionsupport.com/articles/ejbuniquecounter.html
http://www.orionsupport.com , also. In your ejbCreate(), get a
reference to the counter.jar, and then ask for the new pk :
 
  long id =
com.evermind.ejb.CounterUtils.getNextID(java:comp/env/ejb/Counter,
mybeanname);
 
2. See the chain of articles by Brett McGlaughlin at
http://www.flashline.com/content/community.jsp?sid=989854104625-10905805
43-153#brett
http://www.flashline.com/content/community.jsp?sid=989854104625-1090580
543-153#brett   http://www.flashline.com . Instead of using an ejb to
generate your pk references, use jdbc and a stateless session bean. In
the end you do the same thing in your ejbCreate():
 
 long id = slsbRemote.getNextID(mybeanname);
 
And whatever you do, stay away from triggers. 
 
Regards,
 
the elephantwalker

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Sergei Batiuk
Sent: Monday, May 14, 2001 10:08 AM
To: Orion-Interest
Subject: Generating primary keys


Hi mailing list,
 
I have the following problem: the primary key for my EJB is generated at
the database level ( a trigger ), so I don't want to generate it in the
ejbCreate() method. However, EJB specification says, that the use of the
primary key is a MUST. Does anyone have the solution for this problem?
 
Any help is greatly appreciated.
 
Sergei.





RE: Struts and Orion - the example app [EXPIRED TRIAL LICENCE]

2001-05-14 Thread Jeff Schnitzer

Upgrade to Orion 1.4.8.  Version 1.4.7 and prior are missing some
classloader features that Struts uses (for no good reason, as far as I
can tell).

Jeff

 -Original Message-
 From: Sam [mailto:[EMAIL PROTECTED]]
 Sent: Monday, May 14, 2001 7:16 PM
 To: Orion-Interest
 Subject: Struts and Orion - the example app [EXPIRED TRIAL LICENCE]
 
 
 I installed struts and tried to run the example app and
 received the following error:
 
 500 Internal Server Error
 javax.servlet.jsp.JspException: Cannot find message resources 
 under key
 org.apache.struts.action.MESSAGE
  at org.apache.struts.util.RequestUtils.message(RequestUtils.java:285)
  at
 org.apache.struts.taglib.bean.MessageTag.doStartTag(MessageTag
 .java:239)
 
  at /index.jsp._jspService(/index.jsp.java:55) (JSP page line 8)
  at com.orionserver.http.OrionHttpJspPage.service(JAX)
  at com.evermind.server.http.HttpApplication.xj(JAX)
  at com.evermind.server.http.JSPServlet.service(JAX)
  at com.evermind.server.http.d3.sw(JAX)
  at com.evermind.server.http.d3.su(JAX)
  at com.evermind.server.http.ef.s1(JAX)
  at com.evermind.server.http.ef.do(JAX)
  at com.evermind.util.f.run(JAX)
 
 I followed the instruction to correct this and the error still
 appeared.
 
 Has anyone crossed this bridge successfully???
 
 
 
 
 
 
 
 




RE: Session Invalidate Exception

2001-05-13 Thread Jeff Schnitzer

 From: Noah Nordrum [mailto:[EMAIL PROTECTED]]
 
 So have the page where the user enters their credentials wax 
 their session,
 then the validation of the credentials page will create a new session.

That was the solution I mentioned.  It is undesirable for three reasons
I can think of; one, it requires a fix in the multiple locations where
there is a login page; two, not every page with login credentials should
cause this behavior (such as a hypothetical log in as someone else
page); three, it requires access to the session in the view.

The last one is the biggest problem, IMHO, because it violates the MVC
paradigm.  Views shouldn't have code.

 why do you have to invalidate the session? why can't you just do:
 ===
 HttpSession session = request.getSession();
 Enumeration attributes = session.getAttributeNames();
 while (attributes.hasMoreElements()) {
   session.removeAttribute((String)attributes.nextElement());
 }
 ===
 Then you'll basically have a fresh session (except for a few 
 exceptions).

I hadn't thought of that.  I heard mention on this list some time ago
that Orion stores its security credentials in the user session.  The
only problem is, I don't think there is any guarantee that J2EE app
servers store credentials in the session.  That code isn't necessarily
going to work everywhere.

Of course, the RoleManager code isn't portable either, so it doesn't
really matter :-)

Thanks,
Jeff




RE: Session Invalidate Exception

2001-05-12 Thread Jeff Schnitzer

I don't think that excludes the desired behavior, which is that you
should be able to invalidate a session and then create a new one.

It appears that session invalidate() is setting a flag in the session
object causing it to be cleaned up sometime later.  Since the only way
to logout a user is to call invalidate(), this causes some headaches.

Ideally I would like my login submit page to a) discard existing
credentials and b) try new credentials.  This way if a user was already
logged in, the net result of a new login attempt will be the
unauthenticated state.  Unfortunately I can't call

getSession().invalidate();
session = getSession();

because what I get is the old session, which is going to disappear at
the end of the method, the call to RoleManager.login() notwithstanding.
Furthermore, a failed call to RoleManager.login() does *not* discard
existing credentials.  The only way to accomplish the original goal is
to put the invalidate() on every page with a login form.

Ok, this isn't super critical, but it's annoying nevertheless.

Jeff

 -Original Message-
 From: Noah Nordrum [mailto:[EMAIL PROTECTED]]
 Sent: Friday, May 11, 2001 7:09 PM
 To: Orion-Interest
 Subject: Re: Session Invalidate Exception
 
 
 Session Invalidate ExceptionServlet Spec
 ==
 7.2 Creating a Session
 Because HTTP is a request-response based protocol, a session 
 is considered
 to be new until a client joins it. A client joins a session 
 when session
 tracking information has been successfully returned to the 
 server indicating
 that a session has been established. Until the client joins a 
 session, it
 cannot be assumed that the next request from the client will 
 be recognized
 as part of the session.
 
 The session is considered to be new if either of the 
 following is true:
 . The client does not yet know about the session
 . The client chooses not to join a session. This implies that 
 the servlet
 container has no mechanism by which to associate a request 
 with a previous
 request.
 
 A Servlet Developer must design their application to handle a 
 situation
 where a client has not, can not, or will not join a session.
 ==
 
 That last line is what specifically applies to your situation, only
 backwards. In this case you are invalidating the HttpSession, 
 but the client
 doesn't yet know about the pending invalidation, hense the
 IllegalStateException.
 
 Noah
 
 - Original Message -
 From: Kesav Kumar
 To: Orion-Interest
 Sent: Friday, May 11, 2001 7:23 PM
 Subject: RE: Session Invalidate Exception
 
 
 If there is no valid session getSession(false) should return 
 null is in't
 it?
 
 Kesav Kumar
 Software Engineer
 Voquette, Inc.
 650 356 3740
 mailto:[EMAIL PROTECTED]
 http://www.voquette.com
 Voquette...Delivering Sound Information
 -Original Message-
 From: Jason Coward [mailto:[EMAIL PROTECTED]]
 Sent: Friday, May 11, 2001 2:55 PM
 To: Orion-Interest
 Subject: RE: Session Invalidate Exception
 
 
 Kesav:
 
 I believe that when you call request.getSession(false), it 
 will not create a
 new session if a valid one does not already exist.  If you 
 want to create a
 new one, right after invalidation of a previous session, call
 request.getSession() or request.getSession(true).  Obviously, 
 you will need
 to reset your attribute after the new session is created.
 
 Jason
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Kesav Kumar
 Sent: Friday, May 11, 2001 4:17 PM
 To: Orion-Interest
 Subject: Session Invalidate Exception
 
 
 When we call invalidate() method on the session what happens?
 I was doing the following and I am getting a strange error.  
 This is just a
 testcondition I am giving to reproduce my error.  The reality is much
 complex.
 session.setAttribute(kesav, I am nice);
 session.invalidate();
 HttpSession sess = request.getSession(false);
 if(sess == null)
 System.out.println(Session is null);
 Object obj = sess.getAttribute(kesav);
 After the invalidate I was thinking that I won't get session 
 object thats
 the reason I had a condition for null.  What happening is I 
 am getting a
 session object and when I try to access any attribute I am getting
 java.lang.IllegalStateException: Session was invalidated
 at com.evermind[Orion/1.4.8 (build
 10374)].server.http.EvermindHttpSession.getAttribute(Unknown Source)
 at /Test.jsp._jspService(/Test.jsp.java:30) (JSP page line 7)
 at com.orionserver[Orion/1.4.8 (build
 10374)].http.OrionHttpJspPage.service(Unknown Source)
 at com.evermind[Orion/1.4.8 (build 
 10374)]._aj._nxd(Unknown Source)
 at com.evermind[Orion/1.4.8 (build
 10374)].server.http.JSPServlet.service(Unknown Source)
 at com.evermind[Orion/1.4.8 (build 
 10374)]._iib._vfd(Unknown Source)
 at com.evermind[Orion/1.4.8 (build 
 

RE: Standar Template

2001-05-10 Thread Jeff Schnitzer

I've iterated through several solutions to this problem and can offer
some advice:

I started out using option 1 as you describe.  I quickly noticed that
*every* page contains the definition of the layout and look of the
website.  What if I wanted to put the navigation bar on the right
instead of the left?  I would have to modify *every single page* in my
website.  Yuck.


My next step was to put the container code in separate head/foot JSP
files and @include them like this:

%@ include file=head_stuff.jsp %
p
My content
/p
%@ include file=foot_stuff.jsp %

Which at least puts all the look and feel stuff in a handful of places.
But my site has different templates for the logged in user vs the
welcome/signup screens and a few other special cases as well.  It
quickly became a pain to keep track of all the different headers and
footers, and in any case opening tags in one file and closing them in
another really sucks.  Yuck.


Next step was option 2 as you describe.  I created
template_inside.jsp, template_outside.jsp, etc which contain all the
layout structure and then include the appropriate content file based on
a parameter.  Since I'm using an MVC framework, this is pretty easy to
do.

This is the best option I've described so far, and it works.  But it's
not very sophisticated, and it doesn't make having multiple layers very
easy.  Fortunately I'm working on my own time, so now I'm moving on to
the fourth generation of my website content:


This sort of templating is where XSLT really shines.  Rather than
creating templating layers from the top down, XSLT allows you to start
at the bottom and build up, successively transforming the input.
Wrapping (in a layout template) is just one kind of transformation.
Each step has no need to know anything specific about the previous step;
it's all just based on transformation rules.

I'm still near the bottom of the XSLT learning curve, but I'm already
amazed at how powerful it is.  It's also a lot easier to pick up than I
had expected from first looking at a sample.

The only problem with using XSLT in a web application is the lack of
framework support.  Cocoon did not make a favorable impression on me (to
say the least).  I wanted something that provides a simple MVC paradigm
like WebWork or (not-so-simple) Struts but uses XSLT for the view
templating.  So I (and a friend) sat down and wrote it.  Tomorrow we'll
send out a link to the sourceforge site; we're still working on the
documentation and examples.


In summary:  For a simple approach, Option 2 as you describe isn't bad.
For (IMNSHO) a more elegant and powerful approach, it's worth looking
into XSLT.

Jeff Schnitzer
[EMAIL PROTECTED]
http://www.similarity.com (still using WebWork, but not for long :-)


 -Original Message-
 From: Dave Ford [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, May 10, 2001 12:17 PM
 To: Orion-Interest
 Cc: Dan Tharp
 Subject: Standar Template
 
 
 I want to create a web app in which every page on the site 
 has a standard
 header along the top and a standard menu along the left edge (a pretty
 standard thing).
 
 I came up with 2 ways of doing this:
 
 1. Use a table tag and jsp:include tags on EVERY page:
 
 table
   tr
 tdjsp:include page=standardHeader.jsp//td
   /tr
   tr
 td colspan=2
 table
   tr
 td valign=topjsp:include page=/menu.jsp //td
 td valign=top
  THIS IS WHERE THE PAGE-SPECIFIC CONTENT (i.e. the body)*
 /td
   /tr
 /table
 /td
   /tr
 /table
 
 2. Invert the above solution to create one master template 
 (or controller)
 and have the content page name passed in as a parameter. Here 
 would be the
 master template-controller page:
 
 table
   tr
 tdjsp:include page=standardHeader.jsp//td
   /tr
   tr
 td colspan=2
 table
   tr
 td valign=topjsp:include page=/menu.jsp //td
 td valign=top
  jsp:include 
 page=%=request.getParameter(contentPage)% /*
 /td
   /tr
 /table
 /td
   /tr
 /table
 
 The key difference between these two architectures are best 
 understood by
 looking at the 2 lines with the * at the end. Also, in option 
 2, there is
 only one copy of the above code. In option 1, there is one 
 copy per content
 page
 
 Q1: Does anyone have any preference between options 1 and 2?
 Q2: Is there a better way of achieving this result?
 Q3: Do either have any negetive drawback I need to consider? 
 (I will be
 converting an entire site)
 
 By the way, I'm currently achieving this effect VERY easily 
 using good old
 client-side html frames. But due to popular demand, framse must go.
 
 Dave Ford
 Smart Soft - The Java Training Company
 http://www.smart-soft.com
 
 
 




RE: Pure Corba client and Orion

2001-05-09 Thread Jeff Schnitzer

Orion is not an IIOP-based server.  It uses client stubs to communicate
using the Orion RMI Protocol (ormi).

If you need to access EJBs from a pure CORBA client, you have three
options I can think of:

Write your own RMI proxy
Use some sort of HTTP-based RPC mechanism
Use an app server which speaks IIOP natively

There seems to be something of a religious war over the issue of
stubs/proxies vs. IIOP.  There is a lot of interesting discussion in the
EJB-INTEREST archives about this.

Jeff

 -Original Message-
 From: Bogdan Calmac [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, May 08, 2001 12:07 PM
 To: Orion-Interest
 Cc: [EMAIL PROTECTED]
 Subject: Pure Corba client and Orion
 
 
 I am evalating Orion as a potential application server for 
 our product and I
 want to use a pure Corba client with Orion. The question I have are:
 
 1) Does Orion provide a tool to generate idl from the remote 
 interfaces
 (similar to rmic from the jdk)?
 2) If not, is the idl generated by rmic compatible with Orion server?
 3) What is the default port of the naming service and how can it be
 configured?
 
 Thanks a lot,
 
 Bogdan Calmac,
 CISCO Systems.
 
 
 




RE: Caching XLS style sheets

2001-05-09 Thread Jeff Schnitzer

Excel stylesheets?  Perhaps you mean XSL :-)

If you use the JAXP 1.1 transforms api, creating a Templates object
should produce a precompiled version of an XSLT.  Although this will
be completely dependent on implementation, I don't believe any
implementations actually compile to bytecode - really precompiled
means preparsed and maybe stored in a format for efficient processing.

On a related note:

A friend and I are nearly finished constructing a simple MVC framework
with sophisticated XSLT support.  We will be publishing it with an
Apache-style license in about a week.  Cool things this framework does:

. Output from a view can be run through a config-defined sequence of
iterative XSLT transformations.

. The JavaBeans model returned from a command can be automagically
adapted to a DOM for XSLT transformation without JSP, XSP, or any other
templating language.  Efficiently go directly from java beans to XSLT.

. The transformation process can be halted at any step, allowing the
XSLT creators/designers to work from static XML generated from the
previous step(s).

. Other templating systems can be used to feed input to the
transformation process, including JSP and Velocity.  Plain XML inputs
can be used as well.

. XSLT transformations are not required.  It's still an elegant MVC
framework for simple JSP/Velocity/? - HTML processing.

I've attached an example configuration file so you can see the kinds of
things you can do with the framework.


Is anyone interested?

Jeff Schnitzer
[EMAIL PROTECTED]
http://www.similarity.com
http://www.infohazard.org/junitee

-Original Message-
From: Vic Cekvenich [mailto:[EMAIL PROTECTED]]
Sent: Sunday, May 06, 2001 5:55 PM
To: Orion-Interest
Subject: Caching XLS style sheets


I asked a question on an MVC application architecture using XLS, and got
advice to cache XLS / XSLT style sheets, and pre compile them.

Can someone give me some more background on this.
How?
What if the content is dynamic? (2 million items and 100,000  of styles
+ with any combination)

Thanks in advance,  
Vic



maverick

	!-- == Global Views == --
	
	view id=goHome
		redirecthome.do/redirect
	/view
	
	!-- == Commands == --
	
	command id=signup
		controller type=org.infohazard.controller.Signup /
		
		view id=success
			source-model root=foo /
			pipeline
transform src=templates/file1.xsl /
transform src=templates/file2.xsl /
			/pipeline
		/view

		view id=something
			source-documentfoo.xml/source-document
			pipeline
transform src=templates/file1.xsl /
transform src=templates/file2.xsl /
			/pipeline
		/view

		view id=another
			source-jsp bean=foo scope=requestjsps/blah.jsp/source-jsp
			pipeline
transform src=templates/file1.xsl /
transform src=templates/file2.xsl /
transform src=templates/file3.xsl /
			/pipeline
		/view
	/command

	command id=about
		!-- No controller, the source document is always loaded --
		source-documentabout.xml/source-document
		pipeline
			transform src=templates/file1.xsl /
		/pipeline
		!-- /view --
	/command

	command id=home
		controller type=org.infohazard.action.Home /
		!-- Unnamed view, so this is always used no matter what perform() returns --
		source-model name=data /
		pipeline
			transform src=templates/file1.xsl /
			transform src=templates/file2.xsl /
		/pipeline
	/command
	
	command id=plain
		source-documentboring.html/source-document
	/command

/maverick


RE: Fun with compound primary keys

2001-05-09 Thread Jeff Schnitzer

There have been official comments on this list to the effect that
unintuitive error messages should be considered bugs.  You should file
a bugzilla report :-)

Jeff

 -Original Message-
 From: Michael Jara [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, May 09, 2001 9:36 AM
 To: Orion-Interest
 Subject: Re: Fun with compound primary keys
 
 
 Unfortunately, it wasn't quite that simple.  Since I was using CMP, my
 ejbCreate was returning 'null' anyway.  If Orion, internally 
 somewhere, was
 trying to serialize the primary key class, you would expect 
 that it would
 throw an exception or at least kill the entity bean on which it was
 performing operations.  In my case, it was killing all 
 references to the
 entity beans passed in as parameters!  And it was doing so 
 only after the
 first creation of the faulty entity bean (e.g. one was 
 successfully created,
 the next one had problems.)
 
 This is, of course, not a bug in Orion.  It's just counter-intuitive
 behavior which occurs when the bean developer (me) does 
 something stupid. :)
 
 Mike
 
 - Original Message -
 From: Frank Eggink [EMAIL PROTECTED]
 To: Orion-Interest [EMAIL PROTECTED]
 Sent: Tuesday, May 08, 2001 2:20 PM
 Subject: RE: Fun with compound primary keys
 
 
  Yep, if you don't make things serializable you get null 
 as a 'value'.
  That applies to return values crossing the wire as well :-).
 
  Note that, to prevent yourself from having more fun!
 
  FE
 
  On Tuesday, May 08, 2001 2:43 AM, Michael Jara
  [SMTP:[EMAIL PROTECTED]] wrote:
   It took me a while to figure this out, so I thought I'd post it.
  
   If you are using a compound primary key class in your CMP 
 entity bean,
  and you forget to make it implement java.io.Serializable, 
 Orion may do
 some
  really strange things.
  
   In my case, I have an entity bean which represents a many to many
 mapping
  of other entity beans, called TypeDescriptionPair.  This 
 entity bean's
  create method took two other entity beans as parameters, 
 EventType and
  EventDescription.  The create method would simply extract 
 the primary
 key
  from each of these and store it.  So, I was doing something 
 like this to
  test the implementation:
  
   ...
   eventTypes[0] = eventTypeHome.create(0, eventType0);
   eventTypes[1] = eventTypeHome.create(1, eventType1);
   ...
   eventDescription[0] = eventTypeHome.create(0, 
 eventDescription0);
   eventDescription[1] = eventTypeHome.create(1, 
 eventDescription1);
   ...
   typeDescriptionPairHome.create(eventTypes[0], 
 eventDescription[0]);
   typeDescriptionPairHome.create(eventTypes[1], 
 eventDescription[1]);
  
   The very last statement would throw a CreateException, because all
  EventType and EventDescription remote objects had mysteriously been
  nullified!  After hours of debugging, I realized that
  TypeDescriptionPairs primary key class did not implement
  java.io.Serializable.  As soon as I added implements 
 java.io.Serailzable
  to the primary key class, everything was magically fixed.
  
   Mike
 File: ATT3.html 
 
 
 
 




RE: remote shutdown of orion 1.4.8

2001-05-05 Thread Jeff Schnitzer

 From: Eduardo Estefano [mailto:[EMAIL PROTECTED]]
 
 The same is happening to me. Using 1.4.7 everything was fine.
 
 I already posted a message before but here it is again:
 
 - java -jar admin.jar ormi://localhost admin 123 -shutdown
   Works as long as no EJB/Database is called.
   Gives the shutting down... for ever message if ejb/jdbc is
 accessed

This has been happening to me since I started using Orion (1.3.8).
There was some discussion of this problem on the list a long time ago,
and I believe the conclusion was that there is some sort of JVM problem.
You might want to search the list for shutdown.

I'm using Win2K with JDK 1.3  1.3_02.

Jeff




RE: custom finder in CMPs

2001-05-04 Thread Jeff Schnitzer

This is a perfect application for an EJB 2.0 home method.  Call the
finder from within the home method and filter the results.

Basically, you put in your Home interface:

public Collection thisIsAHomeMethod() throws RemoteException;

and you put in your implementation class:

public Collection ejbHomeThisIsAHomeMethod()
{
...
}

No need to add anything to the deployment descriptor.  If you want to
secure access, you can require different security roles for the finder
vs. the home method.

Jeff Schnitzer

 -Original Message-
 From: Armin Michel [mailto:[EMAIL PROTECTED]]
 Sent: Friday, May 04, 2001 7:50 AM
 To: Orion-Interest
 Subject: Re: custom finder in CMPs
 
 
 On Friday 04 May 2001 14:44, you wrote:
  Commonly, developers build a Stateless Session EJB facade 
 through which
  all access to Entity EJBs is accomplished. If you were to 
 employ such a
  pattern, the method of this facade that invokes the CMP finder in
  question would be an appropriate place to manipulate the 
 results before
  returning them to the client. Have a look around 
www.theserverside.com for
 lots of information and discussions of EJB module design.

The facade-approach is no option, because someone could bypass that
facade 
and use the home interface directly. (Everybody must be able to access
my 
JNDI - thus everybody has access to the Home-Interfaces too).

It would be cool, if I could hook the cmp-finder-Method in some way. Is
that 
possible? Such a callback-solution would solve my problem.

Armin Michel

PS: Meanwhile I will have a look at theserverside.com





RE: Interests sake

2001-05-03 Thread Jeff Schnitzer

For production, Win2K/Orion 1.4.7/PostgreSQL.  For development,
Win2K/Orion 1.4.8/hsql.  I'll probably move the production box to 1.4.8
soon since it seems to work well enough with my code.  I have test
systems running Linux/PostgreSQL too.

The only problem with Win2K is that it's a pain to get everything set up
as a service.  RunExeSvc doesn't work with Win2K, and I haven't yet
spent the time needed to get any of the various JNI service adapters
working.  So I'm still starting my sytem by hand from a terminal
services window (which means the app server, an rmi server, and
tnameserv).  Yes, I'm playing fast and loose with my site
availability... but in the year or so I've had the machine, it has never
crashed or involuntarily rebooted :-)

With Linux it's much easier to configure Java apps as daemons, but I
can't render my dynamic images with any reasonable quality - XWindows
renders fonts like a three-year-old with a half-eaten crayon :-)

Jeff Schnitzer
http://www.similarity.com
http://www.infohazard.org/junitee


 -Original Message-
 From: Adam Cassar [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, May 02, 2001 10:53 PM
 To: Orion-Interest
 Subject: Interests sake
 
 
 
 Hi all,
 
 For interests sake, what OS is everyone on the list running orion on?
 
 Windows 2000?
 WinNT
 Linux?
 
 I would of thought that most people would be using Linux but I think
 from postings on this list
 that I might be mistaken
 
 -- 
 
 Adam Cassar
 Technical Development Manager
 ___  
 NetRegistry http://www.netregistry.au.com
 Tel: +61 2 9641 8609 | Fax: +61 2 9699 6088
 PO Box 270 Broadway NSW 2007 Australia
 
 
 




RE: Interests sake

2001-05-03 Thread Jeff Schnitzer

 From: Alex 'Kazuma' Garbagnati [mailto:[EMAIL PROTECTED]]
 
 With Linux it's much easier to configure Java apps as daemons, but I
 can't render my dynamic images with any reasonable quality - XWindows
 renders fonts like a three-year-old with a half-eaten crayon :-)
 
 You should try pja. It does not require any XWindow server 
 running and I 
 use the same fonts available on win...

I tried it.  Didn't produce fonts much (if at all) better than XWindows.
Also tried the xvfb, which was by far the worst option.

One thing you can say about MS Windows is that it does an excellent job
of rendering text :-)  What Linux needs is a ground-up replacement for
XWindows, IMHO.

Jeff





RE: MVC/XML Framework Comments please

2001-04-27 Thread Jeff Schnitzer

Doh!  Sorry, that wasn't supposed to go to the list.

But to keep this topic going (because I'm still undecided about what
direction to go):

Is anyone here besides Tim using XSLT in their web application?  How do
you like it?  Is it easy to get designers up and running with it?  How
do you interface between Java and XML (jsp? building dom nodes in java?
something else?) ?

Thanks,
Jeff


 -Original Message-
 From: Jeff Schnitzer 
 Sent: Friday, April 27, 2001 3:38 PM
 To: Orion-Interest
 Subject: RE: MVC/XML Framework Comments please
 
 
 I'm definitely interested in your framework; may I have a copy?
  
 Thanks,
 Jeff
 
 -Original Message-
 From: Duffey, Kevin [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, April 26, 2001 2:39 PM
 To: Orion-Interest
 Subject: RE: MVC/XML Framework Comments please
 
 
 I use my own framework for a couple of sites, and have gotten feedback
 from others using it as well. Its only 15K in size, full source, its
 free to use, modify, etc. If your interested in it, send me 
 an email. It
 supports xsl transformations, and is very similar to Struts 
 only that I
 found struts too much for my needs, and some features it 
 didn't do that
 I needed, so I went that direction.
  
 
 -Original Message-
 From: Vic Cekvenich [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, April 26, 2001 11:53 AM
 To: Orion-Interest
 Subject: MVC/XML Framework Comments please
 
 
 
 We are bout to pick a a framework, and I am looking for are 
 comments or 
 recommendation on a frameworks, other than Struts. (Don't want to be 
 HTML/JSP centric) Any feedback on your experience with a framework, or
 do 
 you know of web sites in production that are using a certain 
 frame work,
 or 
 do you know of friend or someone who has used one. 
 
 I would like it to be XML centric, and MVC. For example, the V should
 apply 
 the XSL to XML, to make it HTML. It should do standard 
 session tracking.
 It 
 should do standard data manager, so that Java Beans do the 
 SQL (the M).
 A 
 minor plus is form entry management and a bit of image/content
 management. 
 It should be a single rich framework. Here are a few we are 
 considering:
 
 
 http://www.jcorporate.com/html/products/productsfm.html
 http://www.jcorporate.com/html/products/productsfm.html  
 
 http://jakarta.apache.org/jetspeed/site/index.html
 http://jakarta.apache.org/jetspeed/site/index.html  
 
 and all the ones under Jakarta. 
 
 We need to pick one soon. Any comments and feedback welcome on 
 frameworks/class libraries. 
 
 Thanks, [EMAIL PROTECTED] 
 
 
 




RE: Update to 1.4.8 gives strange table names after deployment ???

2001-04-26 Thread Jeff Schnitzer

This line is in changes.txt:

Moved orion-ejb-jar.xml's inclusion path in an ejb-jar to the META-INF/
directory from the orion/ directory for consistency.

BTW, Struts now works out of the box with 1.4.8.

Jeff

 -Original Message-
 From: KirkYarina [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, April 25, 2001 7:12 AM
 To: Orion-Interest
 Subject: Re: Update to 1.4.8 gives strange table names after 
 deployment
 ???
 
 
 Move (or link or copy) your orion-ejb-jar.xml under META-INF, 
 instead of 
 the orion directory.  This was mentioned on the list a while 
 back, but 
 didn't seem to make it into changes.txt.
 
 It bit me, too
 
 Kirk Yarina
 
 At 01:12 PM 4/25/01 +0200, you wrote:
 Great to see there is a new version of Orion, my compliments.
 
 I performed the upgrade through autoupdate.jar and redpoyed 
 my applications,
 whereby I first removed the applications from the 
 application deployment
 dir.
 
 The orion-ejb-jar-xml that Orion generates contains 
 incorrect table names
 which were correct in 1.4.7, see below for the first part of the
 orion-ejb-jar.xml file. It transforms table=sgsusr to
 :table=nl_unwired_sgs_um_User  which isn't correct I suppose.
 Can someone please tell me what goes wrong, as I can't 
 access my database
 like this ??
 BTW: The orion-application contains: autocreate-tables=false.
 
 Eddie
 
 my orion-ejb.jar.xml:
 ?xml version=1.0?
 ?xml version=1.0?
 !DOCTYPE orion-ejb-jar PUBLIC -//Evermind//DTD Enterprise 
 JavaBeans 1.1
 runtime//EN http://www.orionserver.com/dtds/orion-ejb-jar.dtd;
 
 orion-ejb-jar deployment-version=1.4.8 
 deployment-time=e4a8a4f467
   enterprise-beans
entity-deployment table=sgsusr name=nl.unwired.sgs.um.User
 location=nl.unwired.sgs.um.User data-source=jdbc/postgresEJBDS
 exclusive-write-access=false
 
 
 
 --- The above is transformed to:
 
 !DOCTYPE orion-ejb-jar PUBLIC -//Evermind//DTD Enterprise 
 JavaBeans 1.1
 runtime//EN http://www.orionserver.com/dtds/orion-ejb-jar.dtd;
 
 orion-ejb-jar deployment-version=1.4.8 
 deployment-time=e614c0c4f1
   enterprise-beans
entity-deployment name=nl.unwired.sgs.um.User
 location=nl.unwired.sgs.um.User 
 wrapper=UserHome_EntityHomeWrapper8
 table=nl_unwired_sgs_um_User data-source=jdbc/postgresEJBDS
 
 
 




RE: MVC/XML Framework Comments please

2001-04-26 Thread Jeff Schnitzer
 beacuse it's so lightweight and noninvasive compared to Struts;
no worries that Struts might not install on platform X (such as Orion 
1.4.8 :-( ).
 
Good luck,
Jeff Schnitzer
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 
http://www.similarity.com http://www.similarity.com 

-Original Message-
From: Vic Cekvenich [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 26, 2001 11:53 AM
To: Orion-Interest
Subject: MVC/XML Framework Comments please



We are bout to pick a a framework, and I am looking for are comments or 
recommendation on a frameworks, other than Struts. (Don't want to be 
HTML/JSP centric) Any feedback on your experience with a framework, or
do 
you know of web sites in production that are using a certain frame work,
or 
do you know of friend or someone who has used one. 

I would like it to be XML centric, and MVC. For example, the V should
apply 
the XSL to XML, to make it HTML. It should do standard session tracking.
It 
should do standard data manager, so that Java Beans do the SQL (the M).
A 
minor plus is form entry management and a bit of image/content
management. 
It should be a single rich framework. Here are a few we are considering:


http://www.jcorporate.com/html/products/productsfm.html
http://www.jcorporate.com/html/products/productsfm.html  

http://jakarta.apache.org/jetspeed/site/index.html
http://jakarta.apache.org/jetspeed/site/index.html  

and all the ones under Jakarta. 

We need to pick one soon. Any comments and feedback welcome on 
frameworks/class libraries. 

Thanks, [EMAIL PROTECTED] 





RE: MVC/XML Framework Comments please

2001-04-26 Thread Jeff Schnitzer

How do you integratecopy with dynamic content?  Two layers of XSL
transformation (one to mix in copy, one to mix in markup)?  Or do you
use JSP-type templating to build the Content XML before it is sent off
to XSLT?
 
Thanks,
Jeff

-Original Message- 
From: Tim Endres 
Sent: Thu 4/26/2001 5:30 PM 
To: Orion-Interest 
Cc: 
Subject: RE: MVC/XML Framework Comments please



 It sounds like Tim has a homebrew system for going directly
from Logic
 to Presentation.  My team has been thinking of eventually
writing a
 wrapper to expose JavaBeans (the model) as a DOM using
reflection so you
 could still have a pull-based system rather than having to
build the
 full tree ahead of time.  I'm not sure it's ultimately
desirable to skip
 the Logic-Content step, although it would improve
performance.

Not quite.

We use Logic (Session Beans/Commands) -- Content (XML) --
Presentation (XSL).
We simply apply the XSLT transform ourselves, as opposed to
having Orion do
it, so we can precompile and cache appropriately.

I personally think that skipping the Content step is
shortsighted. For instance,
our web page designers never need a live system to connect to.
We simply provide
them with XML files and they write the XSL against the static
XML files. When the
XSL is dropped into the live system, it simply operates on live
XML coming from
the Logic layer. I think this abstraction is important.

tim.





 winmail.dat


RE: Strange error after upgrade to 1.4.8 ?

2001-04-26 Thread Jeff Schnitzer

I have the same problem and have logged bug #414 against it.

I find that the problem goes away if you set your transaction attributes
to NotSupported.  That may or may not be an option for you :-)

It might help Magnus debug it if you attached your orion-ejb-jar.xml to
the bug report too.

Jeff

 -Original Message-
 From: Eddie [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, April 26, 2001 7:45 AM
 To: Orion-Interest
 Subject: Strange error after upgrade to 1.4.8 ?
 
 
 Hmm, somethings are still not working well after the update 
 from 1.4.7 to
 1.4.8.
 
 After the upgrade I get the following error after using a 
 finder method with
 CMP (ofcourse it worked before):
 
 java.lang.InternalError: Was not in used mode
 at 
 com.evermind.server.ejb.DataSourceConnection.release(Unknown
 Source)
 
 
 The stange thing is the some parts of the application are 
 working properly
 (parts that include database interaction). Neither do I 
 receive database
 errors in my db log.
 
 Can someone explain me what the error mean and how to solve it ?
 BTW: below is my datasourse is listed below, just as the 
 complete error:
 
 Eddie
 
 ---
 data-sources
 data-source
 class=com.evermind.sql.ConnectionDataSource
 name=Postgres datasource
 location=jdbc/postgresDS
 pooled-location=jdbc/postgresPooledDS
 xa-location=jdbc/xa/postgresXADS
 ejb-location=jdbc/postgresEJBDS
 schema=database-schemas/postgresql.xml
 url=jdbc:postgresql://localhost/wwwunweb5
 connection-driver=org.postgresql.Driver
 username=login
 password=password
 inactivity-timeout=30
 /
 
 com.evermind.server.rmi.OrionRemoteException: Transaction was 
 rolled back:
 java.lang.InternalError: Was not in used mode
 at
 UserManager_StatelessSessionBeanWrapper5.getMembersFromAccount
 OrderedBy(User
 Manager_StatelessSessionBeanWrapper5.java:6291)
 at 
 nl.unwired.sgs.web.smsmessage.doRequest(smsmessage.java:278)
 at
 nl.unwired.servlet.VelocityHttpServlet.doGet(VelocityHttpServl
 et.java:129)
 at 
 javax.servlet.http.HttpServlet.service(HttpServlet.java:195)
 at 
 javax.servlet.http.HttpServlet.service(HttpServlet.java:309)
 at 
 javax.servlet.http.HttpServlet.service(HttpServlet.java:336)
 at com.evermind._iib._vfd(Unknown Source)
 at com.evermind._iib._qjc(Unknown Source)
 at com.evermind._kj._qbc(Unknown Source)
 at com.evermind._kj._oa(Unknown Source)
 at com.evermind._jw.run(Unknown Source)
 
 
 
 
 - Original Message -
 From: KirkYarina [EMAIL PROTECTED]
 To: Orion-Interest [EMAIL PROTECTED]
 Sent: Wednesday, April 25, 2001 4:12 PM
 Subject: Re: Update to 1.4.8 gives strange table names after 
 deployment ???
 
 
  Move (or link or copy) your orion-ejb-jar.xml under 
 META-INF, instead of
  the orion directory.  This was mentioned on the list a 
 while back, but
  didn't seem to make it into changes.txt.
 
  It bit me, too
 
  Kirk Yarina
 
  At 01:12 PM 4/25/01 +0200, you wrote:
  Great to see there is a new version of Orion, my compliments.
  
  I performed the upgrade through autoupdate.jar and redpoyed my
 applications,
  whereby I first removed the applications from the 
 application deployment
  dir.
  
  The orion-ejb-jar-xml that Orion generates contains 
 incorrect table names
  which were correct in 1.4.7, see below for the first part of the
  orion-ejb-jar.xml file. It transforms table=sgsusr to
  :table=nl_unwired_sgs_um_User  which isn't correct I suppose.
  Can someone please tell me what goes wrong, as I can't 
 access my database
  like this ??
  BTW: The orion-application contains: autocreate-tables=false.
  
  Eddie
  
  my orion-ejb.jar.xml:
  ?xml version=1.0?
  ?xml version=1.0?
  !DOCTYPE orion-ejb-jar PUBLIC -//Evermind//DTD 
 Enterprise JavaBeans 1.1
  runtime//EN http://www.orionserver.com/dtds/orion-ejb-jar.dtd;
  
  orion-ejb-jar deployment-version=1.4.8 
 deployment-time=e4a8a4f467
enterprise-beans
 entity-deployment table=sgsusr name=nl.unwired.sgs.um.User
  location=nl.unwired.sgs.um.User data-source=jdbc/postgresEJBDS
  exclusive-write-access=false
  
  
  
  --- The above is transformed to:
  
  !DOCTYPE orion-ejb-jar PUBLIC -//Evermind//DTD 
 Enterprise JavaBeans 1.1
  runtime//EN http://www.orionserver.com/dtds/orion-ejb-jar.dtd;
  
  orion-ejb-jar deployment-version=1.4.8 
 deployment-time=e614c0c4f1
enterprise-beans
 entity-deployment name=nl.unwired.sgs.um.User
  location=nl.unwired.sgs.um.User 
 wrapper=UserHome_EntityHomeWrapper8
  table=nl_unwired_sgs_um_User data-source=jdbc/postgresEJBDS
 
 
 
 
 




RE: Is this the Orion Team?

2001-04-17 Thread Jeff Schnitzer

Nope.  I know Satan, and she's not that cute :-)

Jeff

-Original Message-
From: Hani Suleiman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 17, 2001 7:18 AM
To: Orion-Interest
Subject: RE: Is this the Orion Team?


And what a lovely picture it is.

PS Anyone notice how one of them looks likeSatan?

On Tue, 17 Apr 2001, Kemp Randy-W18971 wrote:

 If you go to the Swedish newspaper site, there is a picture of the
 developers. 
 
 -Original Message-
 From: Johan Fredriksson [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, April 17, 2001 3:09 AM
 To: Orion-Interest
 Subject: Re: Is this the Orion Team?
 
 
 Yes
 
 - Original Message -
 From: "Kemp Randy" [EMAIL PROTECTED]
 To: "Orion-Interest" [EMAIL PROTECTED]
 Sent: Tuesday, April 17, 2001 2:32 AM
 Subject: Is this the Orion Team?
 
 
  Some digging though the.serverside.com, at the link
  http://www2.theserverside.com/reviews/thread.jsp?thread_id=165,
  uncovered this.
 
  Posted By: Per Norrman on November 3, 2000
 
  in response to this message.
 
 
  A couple of weeks ago, the Orion team
  was featured in Dagens Nyheter,
  the largest swedish newspaper.
  Learn swedish, then read this article:
 
 
http://www.dn.se/DNet/dyn/Crosslink.dyn?d=408a=135807f=huvudt
ext.htmlt=2
 v=0
  In short, the Orion team consists of two guys,
  22 and 24 years old, working from an apartment in
  Eskilstuna, Sweden.
  The article mentiones that they spent about two years
  and approx 14 000 programming hours before their first
  order. However, that implies constantly working more
  than
  19 hours a day for two years 
  Also, they have refused venture capital and and other
  offers, on the grounds that it would limit their
  freedom
  of doing things their own way.
 
  __
  Do You Yahoo!?
  Get email at your own domain with Yahoo! Mail.
  http://personal.mail.yahoo.com/
 
 
 






RE: findBy referencing another entity reference

2001-04-16 Thread Jeff Schnitzer

This is the right idea; you want to do a join in the finder.  Relational
databases were designed to do exactly this sort of thing.  Putting extra
information in the EJBs would just lead to consistency problems, IMHO.  

The EJB 2.0 specification defines EJB QL, which is a
database-independent query language reminiscent of SQL and the preferred
solution to your problem.  Unfortunately Orion does not yet support EJB
QL, so you need to manually specify the join in SQL in the
orion-ejb-jar.xml finder definition.

You will need to use a partial="false" finder to do a join, which means
you need to be very careful about how you specify the select.  Select
table.* should work if you allowed Orion to create the table in the
first place.  Otherwise you'll need to make sure that the columns are
specified in the same order as the fields in ejb-jar.xml.

You will probably want to put this new finder definition in an
orion-ejb-jar.xml fragment included in your ejb jar file so that
deploying your j2ee app on a new server will automatically include the
changes.  There is much discussion in the archives about how to do this.

Good luck!

Jeff

-Original Message-
From: Adam Cassar [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 16, 2001 6:41 PM
To: Orion-Interest
Subject: Re: findBy referencing another entity reference



I found this reply to an earlier posting quite usefull.

http://www.mail-archive.com/orion-interest@orionserver.com/msg1
2085.html





RE: How to enable UserManager support for arbitrary user...

2001-04-16 Thread Jeff Schnitzer
r account.  A Visual Basic client, then 
uses these
  "command" URLs and resulting XML to present a user interface.
 
  Given the above scenario, what would be your recommendation for
  authenticating the user starting right after I accept the
  user/password from
  the VB form (I don't much care for VB specifics, just the
  part which deals
  with EJB/JSP/J2EE security).
 
  After accepting user authentication information from a VB 
dialog, what
  should I do next.  How do I get this information "registered"
  with Orion or
  any j2ee application server so that the deployment descriptor
  information
  works correctly.
 
  Is this the way J2EE security was meant to be used.  A non 
super-user
  account, cannot execute a setSuperuser(boolean) function on
  the User bean.
  Is this how I should be controlling this?  Is this the proper
  method?  I was
  reading the J2EE EJB spec which states that coding security
  should be the
  last resort.
 
  I am not clear on how to execute the above scenario.
 
  Thanks to all the people who have already posted in regards
  to this issue.
 
  -AP_
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On Behalf Of
  Jeff Schnitzer
  Sent: Friday, April 13, 2001 10:09 PM
  To: Orion-Interest
  Subject: RE: How to enable UserManager support for 
arbitrary user...
 
 
  I suggest using an MVC (aka "Model 2") approach, 
separating your view
  from your controller.  One of the controller's 
responsibilities can be
  to check for authentication and provide to the user either
  the requested
  page or the login page.
 
  If you use a dispatcher-servlet-action framework for your 
controller,
  you typically will only need to put the authentication
  checking code in
  a base action class from which all protected action classes
  derive.  If
  you use JSPs as controllers you'll need some sort of code 
in every one
  (you can use @include for this).
 
  You will be much happer if you use an MVC appraoch, trust me.
   The J2EE
  automatic form-based authentication is very crude and fails to
  accomodate simple use cases like automatically logging in 
new users.
 
  You might want to look at WebWork:
  http://www.sourceforge.net/projects/webwork.
 
  BTW, if you use the Orion UserManager (and RoleManager), you
  should not
  do your own database lookup.  Calling RoleManager.login()
  causes methods
  to be called on the UserManager, which can either be your 
class or one
  of the UserManagers that ship with Orion.  
DataSourceUserManager looks
  up password and group information in a table.
 
  Jeff
 
  -Original Message-
  From: Alex Paransky [mailto:[EMAIL PROTECTED]]
  Sent: Friday, April 13, 2001 3:20 PM
  To: Orion-Interest
  Subject: RE: How to enable UserManager support for 
arbitrary user...
  
  
  Tim, this IS what I am looking for, but does it mean that I
  need to put this
  into every .JSP page that I have?  Then, somehow (according to
  J2EE spec)
  Orion will forward this information to all EJB calls and
  properly make use
  of the deployment descriptor stuff?  So every .JSP page will
  check the
  session, find the User object which I stored in there, and
  execute this call
  with the user.login and user.password?
  
  Thanks.
  -AP_
  
  -Original Message-
  From: Tim Endres [mailto:[EMAIL PROTECTED]]
  Sent: Friday, April 13, 2001 3:04 PM
  To: Orion-Interest
  Cc: Alex Paransky
  Subject: Re: How to enable UserManager support for 
arbitrary user...
  
  
  Is this what you are looking for?
  
 RoleManager roleMgr = (RoleManager)
(new InitialContext()).lookup( "java:comp/RoleManager" );
 roleMgr.login( "user", "pass" );
  
  Unfortunately, I think that can only run in the container. To
  accomodate
  multiple logins under a servlet, we used to use a new
  InitialContext on
  every servlet request and set the appropriate JNDI
  properties for each
  InitialContext construction.
  
  tim.
  
   We have developed a web application with our own 
user/group schema.
   Creating a UserManager to map our schema seems pretty
  trivial.  What we
  are
   NOT clear on is how to tell Orion that a particular user has
  logged in.
  
   For example, we start our application with a LOGIN.JSP page,
  which accepts
   user name/password, and proceeds to find the user in the
  database.  After
   the user is found/authenticated, we create an HTTP session,
  and store a
   certain User object in the session to tell us who the user
  is on the next
   http request.
  
   How do we introduce J2EE security into this picture.  In
  other words, how
  do
   we tell Orion which user is logged on so that it starts
  using the security
   attributes/group/rights of the deployment descriptors?  Do
  we need to put
  a
   special attribute into the HTTPSession so that Orion knows
  on behalf of
  what
   user the request is running?
  
   Thanks.
   -AP_
  
  
  
  
  
 
 
 
 
 







RE: How to enable UserManager support for arbitrary user...

2001-04-15 Thread Jeff Schnitzer

Out of curiosity, why aren't you using SOAP?  Seems like that is
designed to do exactly what you want, and I'm sure there is terrific VB
support for it.

You can use J2EE security, but the usual paradigms for J2EE
authentication aren't going to do you much good.

You probably just want a login.jsp?name=xxxpassword=xxx url and from
within that call RoleManager.login().  Since you have a fat client, you
don't need to worry about the user trying to access a protected page
without logging in; the client can be smart about what users are allowed
to do.

Make sure you're properly handling the http cookie returned by the
server otherwise your login isn't going to "stick"... security is
associated with the session, of course.

IMHO, support for HTTP-based RPC in J2EE is very poor, and MS is way
ahead of the game here.

Jeff

-Original Message-
From: Alex Paransky [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 14, 2001 10:03 PM
To: Orion-Interest
Subject: RE: How to enable UserManager support for arbitrary user...


Here is the problem that I am not sure how to really fix.

Our EJB application is wrapped with a number of "command" 
URL's which return
XML results.  For example:
http://localhost/getAccountInformation.jsp?account=2234 would 
return an XML
representation of an account.  An
http://localhost/addUserToAccount?account=2234userName=test...
 would add a
user to a particular account.  A Visual Basic client, then uses these
"command" URLs and resulting XML to present a user interface.

Given the above scenario, what would be your recommendation for
authenticating the user starting right after I accept the 
user/password from
the VB form (I don't much care for VB specifics, just the part 
which deals
with EJB/JSP/J2EE security).

After accepting user authentication information from a VB dialog, what
should I do next.  How do I get this information "registered" 
with Orion or
any j2ee application server so that the deployment descriptor 
information
works correctly.

Is this the way J2EE security was meant to be used.  A non super-user
account, cannot execute a setSuperuser(boolean) function on 
the User bean.
Is this how I should be controlling this?  Is this the proper 
method?  I was
reading the J2EE EJB spec which states that coding security 
should be the
last resort.

I am not clear on how to execute the above scenario.

Thanks to all the people who have already posted in regards to 
this issue.

-AP_

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff 
Schnitzer
Sent: Friday, April 13, 2001 10:09 PM
To: Orion-Interest
Subject: RE: How to enable UserManager support for arbitrary user...


I suggest using an MVC (aka "Model 2") approach, separating your view
from your controller.  One of the controller's responsibilities can be
to check for authentication and provide to the user either the 
requested
page or the login page.

If you use a dispatcher-servlet-action framework for your controller,
you typically will only need to put the authentication checking code in
a base action class from which all protected action classes derive.  If
you use JSPs as controllers you'll need some sort of code in every one
(you can use @include for this).

You will be much happer if you use an MVC appraoch, trust me.  The J2EE
automatic form-based authentication is very crude and fails to
accomodate simple use cases like automatically logging in new users.

You might want to look at WebWork:
http://www.sourceforge.net/projects/webwork.

BTW, if you use the Orion UserManager (and RoleManager), you should not
do your own database lookup.  Calling RoleManager.login() 
causes methods
to be called on the UserManager, which can either be your class or one
of the UserManagers that ship with Orion.  DataSourceUserManager looks
up password and group information in a table.

Jeff

-Original Message-
From: Alex Paransky [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 13, 2001 3:20 PM
To: Orion-Interest
Subject: RE: How to enable UserManager support for arbitrary user...


Tim, this IS what I am looking for, but does it mean that I
need to put this
into every .JSP page that I have?  Then, somehow (according to
J2EE spec)
Orion will forward this information to all EJB calls and
properly make use
of the deployment descriptor stuff?  So every .JSP page will check the
session, find the User object which I stored in there, and
execute this call
with the user.login and user.password?

Thanks.
-AP_

-Original Message-
From: Tim Endres [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 13, 2001 3:04 PM
To: Orion-Interest
Cc: Alex Paransky
Subject: Re: How to enable UserManager support for arbitrary user...


Is this what you are looking for?

   RoleManager roleMgr = (RoleManager)
  (new InitialContext()).lookup( "java:comp/RoleManager" );
   roleMgr.login( "user", "pass" );

Unfortunately,

RE: productive comment.

2001-04-13 Thread Jeff Schnitzer

I just wanted to point out that despite the Orion team's silence on this
list, over the last couple months there has been a lot of bugzilla
activity.  Development is clearly moving forward, so it's not time to
jump ship yet :-)

While a weekly "hey, here's what's up at Ironflare" letter to this list
would be nice, I think just simply echoing all bugzilla update mail to
this list would go a long ways towards giving us the feeling that
development has not stalled.  Especially if this trend towards less
frequent, bigger updates continues.

Anxiously awaiting 1.4.8,
Jeff




RE: productive comment.

2001-04-13 Thread Jeff Schnitzer

I was under the impression that the domain has always been owned by the
Orion organization.  They just pointed it at whoever was willing to
maintain the community site.

I have a suggestion.  Lets take a slice of a Wiki system, say the
Portland Pattern Repository at http://www.c2.com.  I think the Wiki
nature will lend itself well to a community group like this.  It will
also act as a FAQ-O-MATIC.

The natural starting point is:
http://www.c2.com/cgi/wiki?OrionServer

Jeff

-Original Message-
From: Michael J. Cannon [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 13, 2001 6:07 PM
To: Orion-Interest
Subject: RE: productive comment.
Importance: High


Another bit of info:

From NSI WHOIS:

http://www.networksolutions.com/cgi-bin/whois/whois?STRING=orio
nsupport.com
STRING=Search

Magnus owns it now.

NOW WHAT?

Michael J. Cannon

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Stan Ng
 Sent: Friday, April 13, 2001 5:37 PM
 To: Orion-Interest
 Subject: Re: productive comment.


 I'm all for this idea.  Orionsupport is a community support
 effort run on a
 volunteer basis and I believe that it is hosted on Joseph's 
development
 machine using Orion. :) : ) :)  I'd be willing to help shoulder
 some of the
 costs in moving everything over to an ISP host.

 There's no need for a new domain, imho... orionsupport has 
been very open
 and supportive (no pun intended).  I say that we just give those
 good folks
 a nice place to put everything without tying up their resources.

 Community support for Orion has been excellent.  The thing I'm
 worried about
 is how the Orion developers are doing... is there anything we can
 do to help
 out the guys at orionserver/ironflare?



 - Original Message -
 From: "Michael J. Cannon" [EMAIL PROTECTED]
 To: "Orion-Interest" [EMAIL PROTECTED]
 Sent: Thursday, April 12, 2001 10:47 PM
 Subject: RE: productive comment.


  RE: How do we take the next step?
 
  A sig is, classically a _S_pecial _I_nterest _G_roup, in 
the computer
  culture.
 
  orionsig.net, orionsig.org and orionsig.com are available. 
 Pick 'em.
 Don't
  need a license from anyone to be a 'general purpose 
special interest
 group,'
  as long as you don't purport to be in any 'special' 
circumstance or make
  unfounded claims or use words that have obvious legal meaning.
 
  I've got a fixed IP, but it's on a slow and restricted
 connection.  I know
  an ISP that is easy to work with, charges $39/mo, knows how to run
 services
  for Java, and is relatively small and responsive, and 
accesses through a
  multiple T3 (second-tier backbone access, they're actually a
 small CLEC).
  They also are an accredited registrar for all the above TLD's
 (turn-around
  is typically about 24 hours to propagate through BIND/DNS and the
 internic).
  I'd be willing to donate the first six months worth of 
host costs, and,
  after 30 days, pay for the Orion license myself (gotta run 
the site on
  Orion, don't we?) with these guys or anyone better.
 
  Let's just DO IT.  Anyone else want to help?
 
  Michael Cannon
  mailto:  [EMAIL PROTECTED]










RE: How to enable UserManager support for arbitrary user...

2001-04-13 Thread Jeff Schnitzer

I suggest using an MVC (aka "Model 2") approach, separating your view
from your controller.  One of the controller's responsibilities can be
to check for authentication and provide to the user either the requested
page or the login page.

If you use a dispatcher-servlet-action framework for your controller,
you typically will only need to put the authentication checking code in
a base action class from which all protected action classes derive.  If
you use JSPs as controllers you'll need some sort of code in every one
(you can use @include for this).

You will be much happer if you use an MVC appraoch, trust me.  The J2EE
automatic form-based authentication is very crude and fails to
accomodate simple use cases like automatically logging in new users.

You might want to look at WebWork:
http://www.sourceforge.net/projects/webwork.

BTW, if you use the Orion UserManager (and RoleManager), you should not
do your own database lookup.  Calling RoleManager.login() causes methods
to be called on the UserManager, which can either be your class or one
of the UserManagers that ship with Orion.  DataSourceUserManager looks
up password and group information in a table.

Jeff

-Original Message-
From: Alex Paransky [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 13, 2001 3:20 PM
To: Orion-Interest
Subject: RE: How to enable UserManager support for arbitrary user...


Tim, this IS what I am looking for, but does it mean that I 
need to put this
into every .JSP page that I have?  Then, somehow (according to 
J2EE spec)
Orion will forward this information to all EJB calls and 
properly make use
of the deployment descriptor stuff?  So every .JSP page will check the
session, find the User object which I stored in there, and 
execute this call
with the user.login and user.password?

Thanks.
-AP_

-Original Message-
From: Tim Endres [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 13, 2001 3:04 PM
To: Orion-Interest
Cc: Alex Paransky
Subject: Re: How to enable UserManager support for arbitrary user...


Is this what you are looking for?

   RoleManager roleMgr = (RoleManager)
  (new InitialContext()).lookup( "java:comp/RoleManager" );
   roleMgr.login( "user", "pass" );

Unfortunately, I think that can only run in the container. To 
accomodate
multiple logins under a servlet, we used to use a new InitialContext on
every servlet request and set the appropriate JNDI properties for each
InitialContext construction.

tim.

 We have developed a web application with our own user/group schema.
 Creating a UserManager to map our schema seems pretty 
trivial.  What we
are
 NOT clear on is how to tell Orion that a particular user has 
logged in.

 For example, we start our application with a LOGIN.JSP page, 
which accepts
 user name/password, and proceeds to find the user in the 
database.  After
 the user is found/authenticated, we create an HTTP session, 
and store a
 certain User object in the session to tell us who the user 
is on the next
 http request.

 How do we introduce J2EE security into this picture.  In 
other words, how
do
 we tell Orion which user is logged on so that it starts 
using the security
 attributes/group/rights of the deployment descriptors?  Do 
we need to put
a
 special attribute into the HTTPSession so that Orion knows 
on behalf of
what
 user the request is running?

 Thanks.
 -AP_









RE: Usage of the Service console...

2001-04-13 Thread Jeff Schnitzer

My advice is to ignore all the GUI tools that come with Orion and stick
to Ant as a build-and-deploy tool.

It is my strong suspicion that nobody is using, testing, or actively
developing the GUI tools.  It is my personal opinion (probably shared by
many on this list) that this is a good thing.  I would rather see the
Orion team's limited resources focused on the server core.

Not that I think pretty GUI tools don't have a place, but there really
is no limit to the amount of time one can sink into getting a GUI app
working properly.  Ant works just fine.

Jeff

-Original Message-
From: Chaya Ramanujam [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 12, 2001 12:10 PM
To: Orion-Interest
Subject: Usage of the Service console...


I've been playing with the Service console.  It took me way longer to 
create, install and deploy a J2ee app using the console than 
it did when I 
did everything myself on the command line (creating the directory 
structures, creating very simple deployment descriptors, 
creating the jar 
and war files and finally editing the server.xml and 
default-web-site.xml 
files).

I know the console is said to be "alpha" quality - but was 
just curious - is 
any one out there using the console on a regular basis?  Do 
you find it 
really useful?  In what scenarios do you find this more useful - while 
creating and deploying apps or for monitoring or for redeploying apps?

There seems to be a great deal of functionality in the 
console, however the 
lack of documentation/help is a big drawback.

--Chaya.
_
Get your FREE download of MSN Explorer at http://explorer.msn.com







RE: Creating new CMP records

2001-04-09 Thread Jeff Schnitzer

If you want a CMP field that can be null, use java.lang.Integer instead
of int.

Jeff

-Original Message-
From:   Eduardo Estefano
Sent:   Mon 4/9/2001 12:10 PM
To: Orion-Interest
Cc: 
Subject:Creating new CMP records

I have a CMP EJB that has a foreign key field in it (DepartmentID). This
field can be null (removed other fields for simplicity):

CREATE TABLE ACTIVITY ( 
  ACTIVITYID   NUMBERNOT NULL, 
  DEPARTMENTID NUMBER
)

The ActivityID and DepartmentID are class variables of the EJB.

I'm trying to create a record with no DepartmentID. But the value of the
DepartmentID is always 0 (zero) because ints default to 0. The end
result is
a constraint error because there is no department with ID=0.

My question: How can I tell orion to create the new record with a null
value
for DepartmentID instead of 0.

-
Eduardo Estefano
Integrated Information Systems







 winmail.dat


RE: How to set the X-Window DISPLAY on Orion

2001-04-06 Thread Jeff Schnitzer

You just need to configure the DISPLAY variable for the environment that
Orion runs in.  Are you running Orion from a script?  Set the DISPLAY
variable in the script.
 
I gotta warn you though, the xvfb renders some pretty awful output.  The
full X server doesn't do a whole lot better, at least not when fonts are
concerned.  Unfortunately I have to run my server on MS to get
good-looking generated images.
 
IMHO, 75% of what's wrong with Linux is X-Windows.
 
Jeff

-Original Message- 
From: [EMAIL PROTECTED] 
Sent: Thu 4/5/2001 6:34 AM 
To: Orion-Interest 
Cc: 
Subject: How to set the X-Window DISPLAY on Orion




Hi,

We're using Oracle Reports Server on UNIX with Orion. Oracle
Reports
requires an X-Windows session on UNIX platforms. Basic inquiries
such as
font availability and font metrics are resolved through
X-Windows, not just
rasterization of graphic images. Reports is a bitmapped product
and needs a
window runtime environment. So I've set up a Virtual Frame
Buffer using
Xvfb I did some testing and when I set the DISPLAY=:1.0 and run
xclock the
virtual frame buffer works just fine.

But whenever we attempt to use Reports without an Xterm running
we get
"can't  open display".  So I believe the issue is actually with
the
Application Server not knowing where to look for the DISPLAY. My
understanding is that with Apache's JServer you can tell it to
use the Xvfb
instead of the the normal X server by making an entry in the
jserv.properties file. How can I do this with Orion?

Thanks!

Rob Lent
Lead Database Analyst
AXA Client Services







 winmail.dat


RE: Bi-directional relations (my kludge)

2001-04-06 Thread Jeff Schnitzer

M-N relationships do work in Orion, although not bidirectionally.
WebLogic has good support for most of the EJB2.0 spec, and there is a
product that runs on top of JBoss that allows you to deploy EJB2.0
packages (it converts everything to the 1.1 format for JBoss to
consume).  I don't remember the name of it offhand, but I'm sure you'll
find it if you look through the JBoss lists.
 
Reid:
 
I've got to agree with Hani; complaining with such bitterness about the
incompleteness of Orion's EJB2.0 support is ludicrous, especially when
you consider that Orion is one of ONLY TWO servers on the market to
publicly offer *any* native EJB2.0 support.
 
Incidentally, rather than putting that code of yours in a separate
session bean, you can put it in the entities themselves, completely
preserving the EJB2.0 relationship method illusion.  Or better yet (I
have found), you can simply hide a call to a finder within the
getEntityCollection() business methods... this allows you to leave the
relationship unidirectional in implementation.
 
Jeff

-Original Message- 
From: Ray Harrison 
Sent: Thu 4/5/2001 6:47 PM 
To: Orion-Interest 
Cc: 
Subject: Re: Bi-directional relations (my kludge)



Hi Reid -
What App Servers currently offer m-n relationships - I'm
interested in exploring how some of them
operate.

Cheers
Ray
--- Reid Hartenbower [EMAIL PROTECTED] wrote:
 I have found the lack of bi-directional support very
frustrating, and think
 that it so impedes CMP functionality that it should be
qualified as a bug,
 and not a pending feature.

 I also don't see what the big technical challenge in
implementing it would
 be.
 If Orion is going to be this sluggish with support and new
features, I would
 ask them to consider going open source.  Let me fix it if you
won't--do you
 hear me Orion guys?

 My workaround is to manage the relations with a
'RelationManager' session
 bean.  For n-m relations, I create my join tables with
composite primary
 keys, as in (for hsql):

 CREATE TABLE User_Order (
 userId  CHAR(37)NOT NULL,
 orderIdCHAR(37)NOT NULL,
 PRIMARY KEY (userId, orderId));


 Then in the session bean, I explicitly create both sides of
the relationship
 (eg. user.addOrder(order) and order.addUser(user) ) and catch
the duplicate
 key exception, as in:

 user.addOrder(order);
 if(NON_DIRECTIONAL_BUG) {
   try {
 order.addUser(user);
   }
   catch(EJBException e) {
 // for Orion 1.4.7 bidirectional bug;
   }
 }

 When (if) Orion fixes this bug, the modifications to my code
will be slight.

 - Original Message -
 From: "Ray Harrison" [EMAIL PROTECTED]
 To: "Orion-Interest" [EMAIL PROTECTED]
 Sent: Thursday, April 05, 2001 10:50 AM
 Subject: Re: Bi-directional relations


  Nope.
  --- Patrik Andersson [EMAIL PROTECTED] wrote:
   Does bi-directional relations work yet? I'm pretty sure it
did not work
 the
   last time I tried, but that was a fix fix versions ago.
  
   Any news on this issue?
  
   regards,
   Patrik Andersson
  
 
 
  __
  Do You Yahoo!?
  Get email at your own domain with Yahoo! Mail.
  http://personal.mail.yahoo.com/
 
 





__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/




 winmail.dat


RE: findByXXX() with an ORDER BY parameter for Container-managed bean ?

2001-04-03 Thread Jeff Schnitzer

From: Markus Holmberg [mailto:[EMAIL PROTECTED]]

You are relying on an implementation detail of your container.

The reason it has worked for you so far is because your container has
used an instance of java.util.ArrayList/LinkedList, which indeed does
guarantee order. But CMP Entity EJB's finder methods do not return
java.util.List's! They return java.util.Collection. Your functionality
will break when the container changes it's implementation.


I'll bet a case of beer that you can't find a J2EE server that uses an
unordered implementation for the Collection :-)

I would guess that Orion actually walks the RowSet from the Iterator
rather than trying to shove everything into core first.  Otherwise
finders are going to choke on big queries.

I think assuming this behavior is reasonably portable.  My only worry is
whether or not other app servers let you customize the finder sql so
easily.

Jeff




RE: Servlet blues

2001-04-03 Thread Jeff Schnitzer

By default, a single instance of your servlet will be created by the
container to service all requests.  The doGet() is not synchronized so
it must be written thread-safe.

Alternatively, you can have your servlet implement the SingleThreadModel
interface.  This instructs the container to create a pool of servlets
and synchronize access to them.

I do a lot of image generation from servlets, but since I have a
reasonably finite quantity of images I don't bother with
SingleThreadModel and just cache them in a synchronized HashMap.  The
overhead of creating the ImageBuffer, etc for the first instances is
small.

BTW, you might want to use the free Acme GIFEncoder
(http://www.acme.com) instead of Sun's jpeg encoder.  I believe the jpeg
encoder is only available in the Sun JVM and jpeg encoding is pretty
lousy for flat expanses of color anyways.

Jeff

-Original Message-
From: Huibert Aalbers Indaberea [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 30, 2001 9:53 AM
To: Orion-Interest
Subject: Servlet blues


Hi everyone,

I have written a servlet that dynamically generates an image 
using Orion.
Everything works fine under light load. However, under heavy load, when
multiple users are using it simultaneously, it fails, 
presenting erroneous
data.

Does every request instantiate a new servlet class or is the same one
shared? Is the doGet method synchronized? Is this behaviour specific to
Orion?

In a related question, sometimes, under heavy load i get the following
exception:

java.io.IOException: reading encoded JPEG stream
at sun.awt.image.codec.JPEGImageEncoderImpl.writeJPEGStream(Native
Method)

Has anyone seen this problem before?

Thanks a lot for your help.

Huibert







RE: RMI/IIOP support in orion...

2001-04-03 Thread Jeff Schnitzer

You want an appserver that uses RMI-IIOP natively.  Orion isn't one of
these.  You would have to write an intermediate server that translates
all CORBA/IIOP calls into EJB/ORMI calls.  You will more than save on
development costs by just spending the money up front for an IIOP-based
server like BEA or Borland.  If you have CORBA clients, Orion is
probably not the right tool for you.

Jeff

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 03, 2001 2:40 PM
To: Orion-Interest
Subject: RMI/IIOP support in orion...


Hi,

I am relatively new to appserver...

We are thinking of hosting a telecom app on an 
appserverThe inetrface
is to the eventual users
of this application(s) has to be CORBA... so, please advice me 
on options
available to us :

Assuming that we would have a set of EJBs , how would a client 
that uses
CORBA bind to these?


Thanks in advance...


Jobin Thomas

[EMAIL PROTECTED]







RE: Concurrent modification

2001-04-03 Thread Jeff Schnitzer

ConcurrentModificationException is the result of a fail-fast iterator in
the JDK 1.2+ collections framework.  If one thread is iterating a
collection and another thread modifies the collection, the next call to
the iterator will immediately throw this exception.  In the ugly old
days of Hashtable and Vector, the results of concurrent modification
were undefined.
 
You need to rethink your synchronization strategy for whatever shared
data you are initializing in initsequence.jsp.
 
Jeff

-Original Message-
From: Ing. Nicola Folino [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 30, 2001 12:36 AM
To: Orion-Interest
Subject: Concurrent modification


I have a web application with some jsp pages. If I click twice on a link
to another jsp page, I get the exception:
 
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.next(Unknown Source)
at java.util.Collections$6.nextElement(Unknown Source)
at
__jspPage21_initsequence_jsp._jspService(__jspPage21_initsequence_jsp
.java:38)
at com.orionserver.http.OrionHttpJspPage.service(JAX)
at com.evermind.server.http.HttpApplication.xj(JAX)
at com.evermind.server.http.JSPServlet.service(JAX)
at com.evermind.server.http.d3.sw(JAX)
at com.evermind.server.http.d3.su(JAX)
at com.evermind.server.http.ef.s1(JAX)
at com.evermind.server.http.ef.do(JAX)
at com.evermind.util.f.run(JAX)
Keep in mind that go to the other link through an intermediate page
which uses the directive jsp:forward page="somePage". The same
application runs perfectly on JRun, but I saw that Allaire J2EE Server
moves from standard, so I'd like to develope on Orion...
Thanks





RE: Implementation inheritance with ejb...

2001-04-03 Thread Jeff Schnitzer

I don't think you can have an inheritance structure like this.  When you
define the parent relationship, the EJB container wants a method
'abstract Category getParent()' which does not exist.

I have a similar tree structure without the inheritance (also called
'Category'), and it works with some caveats.  Watch out for the lack of
support for bidirectional relationships; I only store the parent
relationship and implement the getCategoryChildren() business method
with a call to ((CategoryHome)getEJBHome()).findByParent().  There are
other ways but I found this to be the most pleasant.

Inheritance wasn't really designed into the EJB specification.  You can
use interface inheritance, but otherwise you're asking for pain.

Jeff


-Original Message-
From: Alex Paransky [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 29, 2001 7:32 PM
To: Orion-Interest
Subject: Implementation inheritance with ejb...


I have a general concept of a TreeNode which could contain a 
parent (another
TreeNode) and some children, a Collection of TreeNodes.  So I 
have defined a
basic TreeNode such as:

public class TreeNode ... {
  public void setParent(TreeNode parent) throws RemoteException;
  public TreeNode getParent() throws RemoteException;

  public void setChildren(Collection children) throws RemoteException;
  public Collection getChildren() throws RemoteException;
}

My TreeNodeBean, has the appropriate abstract functions.

Now, I have something called Category, which has a parent/children
relationship with other categories.  So, when creating a 
Category, I defined
it like this:

public interface Category extends TreeNode {
  public String getName() throws RemoteException;
  public void setName(String string) throws RemoteException
}

similary, I defined a CategoryBean as an abstract class which 
is based on
TreeNodeBean, with the additional abstract functions to 
get/set name.  I
have created a one-to-many relationship between Categories, 
using parent to
specify the parent for particular category, and children to 
indicate the
children Collection.

When I try to deploy the Category bean, I get the following 
exception from
Orion during deployment:

Auto-deploying model (ejb-jar.xml had been touched since the previous
deployment)... java.lang.NullPointerException
at 
com.evermind.server.ejb.deployment.ContainerManagedField.aep(JAX)
at com.evermind.server.ejb.database.fj.afk(JAX)
at com.evermind.server.ejb.compilation.gf.ah9(JAX)
at com.evermind.server.ejb.compilation.f9.ah9(JAX)
at com.evermind.server.ejb.compilation.f9.s7(JAX)
at com.evermind.server.ejb.compilation.gf.s7(JAX)
at com.evermind.server.ejb.EJBContainer.b_(JAX)
at com.evermind.server.Application.b_(JAX)
at com.evermind.server.Application.gj(JAX)
at com.evermind.server.ApplicationServer.r2(JAX)
at com.evermind.server.ApplicationServer.aq0(JAX)
at com.evermind.server.ApplicationServer.gj(JAX)
at com.evermind.server.hk.run(JAX)
at java.lang.Thread.run(Thread.java:484)
at com.evermind.util.f.run(JAX)

Is this normal? What does this exception mean?

Thanks.
-AP_







RE: Collection Finders With Entity Argument Always Return Empty Collection

2001-04-03 Thread Jeff Schnitzer

Try reversing the order of the fields in the primkey-mapping block for
the bean in the orion-ejb-jar.xml.  Might also work just to change the
order in the ejb-jar.xml, especially if you deploy from scratch.

Jeff

-Original Message-
From: Peter Pontbriand [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 28, 2001 7:51 AM
To: Orion-Interest
Subject: Re: Collection Finders With Entity Argument Always 
Return Empty
Collection 


Hmm. it seems a good under-desk gibbering session is helps 
focus the brain.
Once that was over with, I copied the generated finder code 
(below) into an
EJB of my own and executed it, getting the same results - not 
rows in the
ResultSet. I then wasted a whack of time trying to lay my 
eyeballs on the
actual final SQL statement being tossed at the database. No 
luck there, no
amount of downcasting to assorted Oracle JDBC Driver Statement 
classes would
produce a way to get a human readable parameterized SQL statement. No
matter, though, since by chance I spotted the problem in the 
generated code:

THE ORION-GENERATED CODE REVERSES THE ORDER OF THE STATEMENT 
PARAMETERS!!!

Notice the criteria in the where clause: first is
CatalogEntryEJB.catalogIdentity, second is 
CatalogEntryEJB.catalogLocale.
These are the two fields of the composite primary key of CatalogEJB, a
String and a Locale respectively.

Now look at the code that inserts the values for these parameters:

First is: statement.setString(1,
com.evermind.util.ObjectUtils.toString(primaryKey398.locale));
And second is: statement.setString(2, primaryKey398.identity);

The locale is being inserted where the identity should be, and 
vice-versa.

Bugzilla Bug #379 has been posted. Anybody got a 
non-stomach-churningly-ugly
workaround idea?

P. Pontbriand
Canlink Interactive Technologies, Inc.


- Original Message -
From: "Peter Pontbriand" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Tuesday, March 27, 2001 12:27 PM
Subject: Collection Finders With Entity Argument Always Return Empty
Collection


 
 java.sql.PreparedStatement statement =
connection.getCustomStatement("select
 CatalogEntryEJB.identity, CatalogEntryEJB.catalogIdentity,
 CatalogEntryEJB.catalogLocale, CatalogEntryEJB.label,
 CatalogEntryEJB.targetRoleIdentity, 
CatalogEntryEJB.referenceidentity,
 CatalogEntryEJB.price, CatalogEntryEJB.discountRate,
 CatalogEntryEJB.parentreferenceidentity, 
CatalogEntryEJB.referenceTypeInt,
 CatalogEntryEJB.productCode, CatalogEntryEJB.description,
 CatalogEntryEJB.extendedDescription, CatalogEntryEJB.listIndex,
 CatalogEntryEJB.created, CatalogEntryEJB.creator,
CatalogEntryEJB.modified,
 CatalogEntryEJB.modifier from CatalogEntryEJB where
 CatalogEntryEJB.catalogIdentity = ? and 
CatalogEntryEJB.catalogLocale =
?");
 try {
 com.canlink.components.base.LocalizedEntityPK primaryKey398 =
 argument0 == null ? null :
 ((com.canlink.components.base.LocalizedEntityPK)
 argument0.getPrimaryKey());
 {
 if (primaryKey398 == null) {
 if (((java.util.Locale) null) == null) 
statement.setNull(1,
 java.sql.Types.VARCHAR);
 else
 statement.setString(1,

 com.evermind.util.ObjectUtils.toString(((java.util.Locale) null)));
 if (((java.lang.String) null) == null) 
statement.setNull(2,
 java.sql.Types.VARCHAR);
 else
 statement.setString(2, ((java.lang.String) null));
 }
 else {
 if (primaryKey398.locale == null) statement.setNull(1,
 java.sql.Types.VARCHAR);
 else
 statement.setString(1,

 com.evermind.util.ObjectUtils.toString(primaryKey398.locale));
 if (primaryKey398.identity == null) statement.setNull(2,
 java.sql.Types.VARCHAR);
 else
 statement.setString(2, primaryKey398.identity);
 }
 }
 }
 finally {
 }
 java.sql.ResultSet set = statement.executeQuery();
 while (set.next()) {
 
 }
 








RE: What versions of Postgres are people using?

2001-03-21 Thread Jeff Schnitzer

I'm using Postgresql 7.0.3 on RH7 with pleasant results (except the JDBC
driver's timstamp issue).

I don't serialize any objects as BLOBs though.  Why do you want to do
this?

Jeff

-Original Message-
From: Julian Richardson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 21, 2001 7:28 AM
To: Orion-Interest
Subject: What versions of Postgres are people using?


Hi,

Following on from my earlier questions about alternatives to 
Hypersonic, a
few people recommended Postgres.

Well, I'd been meaning to try Postgres generally for a long 
time anyway, so
downloaded the latest version from the site (703) and installed it.

Orion wouldn't run with it, complaining about lack of binary 
object support
(fair enough given that looking inthe JDBC source reveals that it's not
implemented in 703!). Thing is, I was talking to the guy who wrote the
Postgres drivers and it sounds like there was no stream support in 6.5
either; this is new in 7.1 (which isn't released yet). But Orion must
require the use of somthing like this to store serialized data, surely?

So what are the people on the list who use Postgres actually 
using? Have you
patched the JDBC drivers to work, or did someone release 
patched 6.5 drivers
for Postgres which everyone's installed? Or have you modified Orion to
serialize data using some other mechanism to the default? I 
imagine most
people on the list are using 6.5 rather than 7.0.3? Confusing, 
to say the
least...

cheers

Jules






RE: bad timestamp confusion

2001-03-21 Thread Jeff Schnitzer

Take a look at this message I posted in January:

http://www.mail-archive.com/orion-interest@orionserver.com/msg08677.html

If you patch the JDBC driver to read whatever format your dates are
coming back as (you should see the actual formatted date string in the
exception message), you should be ok.

You might first check the CVS copy of the JDBC driver to see if it
works; with any luck patches have already been made.

Storing dates as strings just seems like a bad idea.  It's nice to be
able to do date math in SQL queries when you want to analyze your data.

Jeff

-Original Message-
From: Eddie [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 21, 2001 4:55 AM
To: Orion-Interest
Subject: bad timestamp confusion


Just like other people in the newsgroup, I am receiving a bad timestamp
error once in a while with Postgres 7.0.

I looked in the newsgroup and saw some possible solutions, but 
I am a bit
confused.
How can I solve this problem for ever in case of a DateTime field ???
Someone talked about using java.sql.Date instead of java.util.Date, the
other about getting the last postgres jdbc driver
I got the last postgres driver from the postgres site, so what 
should I do
??

I was thinking about just using Strings to store Date format info. What
about this ?

And what should I do when I get such an error. Filling the 
database all over
again helps. But what, when I have everyting ready online ??

Regards,
Eddie






RE: bad timestamp confusion

2001-03-21 Thread Jeff Schnitzer

There are instructions for obtaining the latest source tree via
anonymous CVS here:
http://www.postgresql.org/devel-corner/docs/postgres/cvs.html

Just get the whole thing :-)  There are instructions for building the
JDBC driver in the README file in the directory you found.

Good luck,
Jeff

-Original Message-
From: Eddie [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 21, 2001 1:56 PM
To: Orion-Interest
Subject: Re: bad timestamp confusion


Thanks Jeff,

H, I am a bit confused, again.
I went searching for the correct postgres jdbc driver, and don't know
exactly where to get the last version and source (I thought I did).
I seached on http://jdbc.postgresql.org/download/ but is that 
the correct
site ? and where can I get the source as I can't find it.
I searched on
http://www.postgresql.org/cgi/cvsweb.cgi/pgsql/src/interfaces/j
dbc/, but
there I only have a complete three and don't realy know what 
to download.

Regards,
Ed Bras

- Original Message -
From: Jeff Schnitzer [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Wednesday, March 21, 2001 8:08 PM
Subject: RE: bad timestamp confusion


 Take a look at this message I posted in January:

 
http://www.mail-archive.com/orion-interest@orionserver.com/msg0
8677.html

 If you patch the JDBC driver to read whatever format your dates are
 coming back as (you should see the actual formatted date 
string in the
 exception message), you should be ok.

 You might first check the CVS copy of the JDBC driver to see if it
 works; with any luck patches have already been made.

 Storing dates as strings just seems like a bad idea.  It's nice to be
 able to do date math in SQL queries when you want to analyze 
your data.

 Jeff

 -Original Message-
 From: Eddie [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, March 21, 2001 4:55 AM
 To: Orion-Interest
 Subject: bad timestamp confusion
 
 
 Just like other people in the newsgroup, I am receiving a 
bad timestamp
 error once in a while with Postgres 7.0.
 
 I looked in the newsgroup and saw some possible solutions, but
 I am a bit
 confused.
 How can I solve this problem for ever in case of a DateTime 
field ???
 Someone talked about using java.sql.Date instead of 
java.util.Date, the
 other about getting the last postgres jdbc driver
 I got the last postgres driver from the postgres site, so what
 should I do
 ??
 
 I was thinking about just using Strings to store Date 
format info. What
 about this ?
 
 And what should I do when I get such an error. Filling the
 database all over
 again helps. But what, when I have everyting ready online ??
 
 Regards,
 Eddie
 
 








RE: Why Entity EJBs?

2001-03-20 Thread Jeff Schnitzer

I also am questioning entity beans, after 5 months of intensive
development with them.  If you run Hypersonic in server mode and watch
the sql output to the console, it should be readily apparent why... CMP
produces *WAY* too many queries for fine-grained entity beans.

The biggest problem is finder methods.  Since all beans are lazy-loaded,
iterating through the finder results of 1000 beans will produce 1001 SQL
calls.  There isn't any reason specwise that beans cannot be
eager-loaded, but few (if any) appservers seem to support this.

Does anyone know if there is any support for eager-loading of finder
results in Orion?  There doesn't appear to be from the documentation.


I'm really disappointed in the entity bean concept.  CMP should give us
faster development times, faster code (with caching), and database
independence, but at the moment we get *none* of the above.  By stating
in the blueprints that entity beans should only model course-grained
objects and _not_ "one row of the table" they are effectively saying DO
NOT USE CMP, because what is a CMP bean if not one row of a table?  I
noticed that most of the new J2EE patterns Sun recently posted are aimed
at BMP.  Sun's schizophrenia on this really pisses me off; with one face
they like to show off entity beans and CMP because MS doesn't have it,
with another they tell us to go back to the bronze age of handwritten
SQL because the technology doesn't work.  Gr.

Jeff


-Original Message-
From: Dan North [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 20, 2001 4:41 AM
To: Orion-Interest
Subject: Fwd: Why Entity EJBs?


Hi Johan.

two-pence-worth

I've been developing EJBs in a very (a) intensive and (b) 
short development 
cycle for about 5 months now.  I've found that my methodology 
has leant 
towards what the JRF guys are talking about, but in a less formal way.

 From the backend forwards: I tend to use entity beans for 
storing/retrieving and most manipulation of data - ie. I have 
quite "fat" 
beans rather than just purely getters and setters.  I then use session 
beans for workflow that doesn't seem to belong with any 
particular single 
bean, such as generating reports or anything that requires a few home 
interfaces' finders.  I also use session beans for their transactional 
integrity when populating new beans from an HTML (JSP) form, 
especially 
when several beans will be created from a single form's 
contents and I want 
the whole lot to be atomic.

We tend to use JSP and regular form beans for most of the 
other workflow 
stuff, and sometimes we'll have quite complex finder methods 
in the EJBs 
that join across several tables.

The benefits to EJBs, and specifically orion, for me are:
- Database independence: we're deploying on MS SQL Server but 
it's trivial 
to deploy to eg. Oracle for scalability or Hypersonic for 
local testing.

- Network independence: I need to change no code to cluster orion on 
several hosts and also to split its responsibilities between 
being a web 
server on one host talking to another orion instance being an 
app server on 
another host.

- Speed of development: I don't have to worry about how or 
where my data is 
being stored - I have orion's _fantastic_ OR mapping to do that for me.


It seems to me that the JRF is taking the "best practice" 
approach, which 
is a fine and noble thing to do, but then overcomplicating the 
issue by 
wandering off into its own specification.

All my SQL for each package is in one place (orion-ejb-jar.xml), and I 
don't have to worry about scalability or portability.  If it 
says J2EE on 
the box, it'll usually have J2EE in the box.  (Apart from the 
usual niggles 
with app servers being behind spec - again orion is pretty 
good for being 
up-to-date in this regard.)  So I have all the benefits of JRF 
but with the 
backing of a technology as widely-adopted as J2EE.

/two-pence-worth

Disclaimer: I don't work for orion, I just love their product. 
 And J2EE 
has been the most useful technology I've discovered since I 
picked up OO 
about 10 years ago!

Regards,
Dan.

ps. That passage in the EJB book about having a session bean 
talk straight 
to a database is again (imo) a throwback to the technology 
being pretty 
immature and inefficient when the book was written.  I have 
had no problems 
with orion's ability to manipulate and cache data for me 
comparably well 
with direct database access - but with the added benefit of 
lots of data 
integrity checking and no SQL on my part.  In fact you get two 
levels of 
caching - the database and the app server.


Date: Tue, 20 Mar 2001 09:22:52 +0100 (CET)
From: Johan Lundberg [EMAIL PROTECTED]
Subject: Why Entity EJBs?
To: Orion-Interest [EMAIL PROTECTED]
X-Mailer: Orion ListServer
Reply-To: Orion-Interest [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
X-MIME-Autoconverted: from 8bit to quoted-printable by 
druid.evermind.net 
id KAA23094

Hi

The more I study the J2EE technology, the more I
wonder why I should use it.


RE: Why Entity EJBs?

2001-03-20 Thread Jeff Schnitzer

A!  You are absolutely right, and I marvel at my own foolishness!
It was something in my code that made it look like finders were issuing
n+1 calls.  That, combined with my expectation of trouble because this
question (about n+1 sql calls for a finder) comes up with some
regularity on the ejb-interest mailing list.  I don't think many of the
(other) appserver vendors have a satisfactory solution.

My faith in CMP has been restored.  I'm finding that hacking around
case-sensitivity in String values is annoying, but it still beats
handwriting SQL.

Thanks Magnus!  It's too bad that Sun doesn't espouse this same line of
thought; it's pretty clear to me now that the arguments against
fine-grained entities are largely a product of deficient container
implementations.

This should be a FAQ.

Jeff

-Original Message-
From: Magnus Stenman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 20, 2001 10:33 AM
To: Orion-Interest
Subject: Re: Why Entity EJBs?


Orion should execute one SQL query for a finder (even with 
1000 rows) unless:
You're using BMP.
You're using exclusive-write-access="false" and are outside of a TX.

BMP is less than slim when it comes to SQL activity, we 
generally recommend CMP unless the condition is exceptional.

Another "common mistake" in EJB usage is not using 
transactions. The same code can generate 100x+ as many calls 
when run outside of a TX as inside a TX. Why this is specific 
to EJB is that EJB treats data integrity very carefully, while 
your "home brewed" (hope that word isnt offensive) access may 
delay persistance into larger chunks etc (a "semi TX").

So: avoid exclusive-write-access="false" unless absolutely 
needed, use CMP if possible, and identify where your app is 
really "TXs" logically but isnt defined to be.

What you get: cleaner and more easily abstracted code if all 
goes well. Transactional (and distributed, stay tuned some 
longer for that to come clustering doc) cache (it is fairly 
easy to make a cache, but another issue alltogether to make a 
transactional cache that scales, totally different tasks). 
More ease in code migration between programmers since you're 
closer to the "default", more of the backbone has been 
provided/standardized.

Weakest side of entities as of now: batch updates. No 
candidate to that one, it is the biggest limitation (but can 
be worked around).

As for "general design standpoint" it is usually not good 
custom for a vendor to push a practice; but we can say as much 
as that our recommendations are pretty much in line of those 
described by Dan North in a recent reply to this thread (CMP, 
logic in entities that apply to that entity - ignore the 
recommendation stating that they're simply data storage items, 
they're objects, and inter-bean logic in sessions).

Just a short note... we rarely mix into this category of 
discussions (the ones bordering on religious beliefs ;) but I 
thought I'd shed some technical light on some of the issues - 
everyone's free to chose their own architecture, but it's sad 
when it's done due to lack of knowledge of architecture X's 
facts and benefits.

Have a nice day!

/Magnus Stenman, the Orion team

PS. On the issue of "coarse grained" - entities fit perfectly 
well for fine grained access, but this is a political battle. 
You may have heard rumours about "local" entities, which 
consist more or less of entities allover but "allowed for fine 
grained access" this time. Our current position on that matter 
is that locals are superflous, what needs to change is just 
the notion of EJBs always being coarse grained. This is, of 
course, a very preliminary position. If there turns out to be 
genuine technical merits for the separation (things that 
cannot be done feasably via switch tags in the descriptor, see 
for instance copy-by-value in orion-ejb-jar.xml) that weight 
enough we'll reposition.

/Magnus Stenman, the Orion team


- Original Message - 
From: "Jeff Schnitzer" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Tuesday, March 20, 2001 6:31 PM
Subject: RE: Why Entity EJBs?


 I also am questioning entity beans, after 5 months of intensive
 development with them.  If you run Hypersonic in server mode 
and watch
 the sql output to the console, it should be readily apparent 
why... CMP
 produces *WAY* too many queries for fine-grained entity beans.
 
 The biggest problem is finder methods.  Since all beans are 
lazy-loaded,
 iterating through the finder results of 1000 beans will 
produce 1001 SQL
 calls.  There isn't any reason specwise that beans cannot be
 eager-loaded, but few (if any) appservers seem to support this.
 
 Does anyone know if there is any support for eager-loading of finder
 results in Orion?  There doesn't appear to be from the documentation.
 
 
 I'm really disappointed in the entity bean concept.  CMP

RE: Dependents remove not supported

2001-03-19 Thread Jeff Schnitzer

Nevermind pd1 vs pdf support; *this* should seriously make you
reconsider using dependent objects:
 
http://www.mail-archive.com/ejb-interest@java.sun.com/msg16733.html
http://www.mail-archive.com/ejb-interest@java.sun.com/msg16733.html 
 
Jeff

-Original Message-
From: Christian Billen [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 19, 2001 7:52 AM
To: Orion-Interest
Subject: RE: Dependents remove not supported


Thanks, I found it 9.4.4.2 page 119 in EJB2.pdf, and tried to use it by
putting the method remove in my DO : 
 
abstract remove(); 
 
however Orion doesn't seem to support it and pukes on startup:
 
"Illegal abstract method in dependent class com.mytest.ejb.MyDo: public
abstract void com.mytest.ejb.MyDo.remove()"
 
bummer! that seriously make me reconsider using the whole thing, or is
my method signature incorrect?
 
Christian

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Drury
Sent: Sunday, March 18, 2001 1:58 PM
To: Orion-Interest
Subject: RE: Dependents in 1-N don't go away


 
You may want to look at 9.4.4.2 in the proposed final draft which
defines the
remove() function of a DO.  I don't have PD1 to tell you what section it
is there.
 
-tim
 

-Original Message-
From: Christian Billen [mailto:[EMAIL PROTECTED]]
Sent: Sunday, March 18, 2001 12:30 PM
To: Orion-Interest
Subject: RE: Dependents in 1-N don't go away


 
Is that remove() method an abstract method to be implemented in the DO?
they inherit Object and the only required method to implement on them is
the deepCopy(), I don't see where the remove() method is or come from.
 
Since they are Depedent by nature shouldn't the remove call on the
parent set or collection remove them permanently as well in the design?
maybe it is a bug in Orion ?
 
Thanks,
 
Christian

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Drury
Sent: Sunday, March 18, 2001 10:25 AM
To: Orion-Interest
Subject: RE: Dependents in 1-N don't go away


 
I understand.  You have removed the DO from the parents list, but you
have not removed the DO from the database.  This is because you did
not call the removed method of the DO.  Try:
 
getDependents().remove(dependent);  // remove DO from parent's list
dependent.remove();  // remove DO from database/container
 
-tim
 

-Original Message-
From: Christian Billen [mailto:[EMAIL PROTECTED]]
Sent: Saturday, March 17, 2001 9:29 PM
To: Orion-Interest
Subject: RE: Dependents in 1-N don't go away


Hi Tim, thanks for the info, by my problem is different
 
my issue is I want to remove a dependent from the java.utill.Set in its
parent object and that if I call getDependents().remove(dependent) from
the parent object the dependent doesn't go away from the list (even
though it has been found since I implemented the equal method)
 
Any help on this is really greatly appreciated.
 
Thanks,
 
Christian

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Drury
Sent: Saturday, March 17, 2001 9:10 AM
To: Orion-Interest
Subject: RE: Dependents in 1-N don't go away




Dependent objects (DO) do not go away automatically. 
There is an un-implemented option in the deployment 
descriptor called cascade-delete, but alas, it is 
unimplemented. 

The DO life-cycle is one of the main issues with DOs 
in the spec and one reason they may be changed. 

For now, just implement ejbRemove in your entity 
and DOs so they call the remove of their children. 

-tim 


 -Original Message- 
 From: Christian Billen [ mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] ] 
 Sent: Friday, March 16, 2001 7:43 PM 
 To: Orion-Interest 
 Subject: Dependents in 1-N don't go away 
 
 
 Hi everyone, 
 
 I am having an issue with my 1-n dependents relationship.  My 
 dependents 
 don't get deleted when I remove them from the cmr Set. 
 
 I have a PhoneNumber dependent class which has a field type, 
 countrycode, 
 number, etc... 
 
 I implemented the equal method in my class such that two 
 phonenumber having 
 the same type are equal, these type being like "business", 
 "fax", "cell", 
 etc 
 
 Now I have an ejb class, the Customer ejb, which has : 
 
 abstract PhoneNumber createPhoneNumber() 
 abstract Set getPhoneNumbers() 
 abstract void setPhoneNumbers(Phonenumber n) 
 void addPhoneNumber(String type, String areaCode, ...) 
 { 
   PhoneNumber p = createPhoneNumber(); 
   //Remove an existing phone 
   //*1 
   getPhoneNumbers().remove(phoneNumber); 
   //*2 
   getPhoneNumbers().add(phoneNumber); 
   //*3 
 } 
 
 Basically since my phonenumber equals on type, the desired 
 effect is I want 
 to wipe out a previous phonenumber of the same type before 
 adding the new 
 one. 
 
 My problem is that I can see the phoneNumber being 
 successfully removed from 
 the list by putting debug calls at *1,*2 and *3 that checks on 
 getPhoneNumbers.size() ...and the method commits 

RE: Questions regarding 1-n bi-directional relationships...

2001-03-18 Thread Jeff Schnitzer

As of version 1.4.7, bidirectional relationships are not yet supported
by Orion.

Jeff

-Original Message-
From: Alex Paransky [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 16, 2001 5:26 PM
To: Orion-Interest
Subject: Questions regarding 1-n bi-directional relationships...


I have an entity called Account, and User.  One Account can 
have many Users
(bi-directional relationship).  When I add a new User to the 
Account, the
relationship table gets updated, but the AccountId field in 
the User table
is not updated.  Is this normal?  It thought that
account.getUsers().addUser(user) should BOTH update the 
relationship table
and configure the accountId field in the User table.

Can someone verify this?

Thanks.
-AP_







RE: Why is Hypersonic SQL still being integrated

2001-03-14 Thread Jeff Schnitzer

Why not?

Really, as a simple test/example database, what shortcoming does it
have?  Just because nobody is fixing/adding new bugs to the code at the
moment doesn't mean that the current incarnation is not perfectly
adequate for its task.

I don't think anyone in their right mind would run a production system
with hsql, but for development I've never used anything so convenient.
Having the sql spit out to the hypersonic console in server-mode is
great!

Jeff

-Original Message-
From: Kemp Randy-W18971 [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 14, 2001 6:36 AM
To: Orion-Interest
Subject: Why is Hypersonic SQL still being integrated


If HypersonicSQL is a dead project, why is it still being 
shipped with Orion? 






RE: Using another EJB as part of the Primary Key Class

2001-03-14 Thread Jeff Schnitzer

It works for me.  I have an entity whose PK is a compound of two CMR
1-N fields.  HOWEVER, I'm only using Collection mapping, not Set (which
it looks like you're using).  If you can't figure out what's wrong with
your code, try using Collection and see if that fixes the problem.

I would like to use Set and Map and all those cool interfaces too, but
(aside from whether or not they work) they are not portable.
Unfortunately the latest iteration of the spec only provides for
java.util.Collection.  :-(

Jeff

-Original Message-
From: Christian Billen [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 13, 2001 1:39 PM
To: Orion-Interest
Subject: Using another EJB as part of the Primary Key Class


Hi everyone,

Can one specify another EJB Entity object as part of the 
primary key for one
ejb?

Here is a imaginary example:

TreeEJB has a one to many relationship to AppleEJB

And I have a primary key for AppleEJB which contains TreeEJB 
and a AppleID

In my application when I tried to do something similar to the 
figurative
example above I got:
Apple_ORSet295.java:294: Exception java.rmi.RemoteException 
must be caught,
or it must be declared in the throws clause of this method.

I can't quite model this as a dependent relationship because I might be
refering this AppleEJB from other EJB.

Now my question: is this a bug or is it something I should not 
be doing? how
else could I model that an apple must be unique within its tree?
suggestions?

Thanks,

Christian







Orion Team Needs New List Software

2001-03-14 Thread Jeff Schnitzer

Someone desperately needs to replace the list software currently hosting
the Orion-Interest mailing list.  This is really getting out of hand.
It's bad enough that everyone who posts gets messages like this from
natch.se... but now they're echoing to the list as well.

If the only reason this hasn't been done is lack of suggestions, I've
found use (no idea about administration) of Mailman lists to be
pleasant.  http://www.list.org.

Somebody also needs to fix the Orion website so that when you click
"unsubscribe", it gives a response page to that effect rather than the
current erroneous "Thank you for subscribing" message.  This is probably
what generates most of the "how do I unsubscribe?" messages to the list.

Jeff

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 14, 2001 11:31 AM
To: Orion-Interest
Subject: Re:Why is Hypersonic SQL still being integrated


Sir or Madame-

I am no longer available to receive email at this address.

Please forward all email requests and/or information to 
[EMAIL PROTECTED] and/or [EMAIL PROTECTED]

Thank you.

___
James M. Morgenstein
VP Technology
Digital Demographics, Inc.
Home of Recommend-It (r)
http://www.recommend-it.com
(voice) 732-296-8885
  (fax) 732-296-8817

Recommend-It (r): The Internet's hottest website traffic 
generation service.  Completely free for surfers and website 
owners. More than 100,000 members and over 3 million 
newsletter subscriptions in over 220 countries and growing!






RE: Customizing CMP deployment

2001-03-12 Thread Jeff Schnitzer

You can put fragments of orion-ejb-jar.xml in your deployment package.
It should go in a directory called "orion" sibling to META-INF.  Check
the list archives for more details.

FYI, you can do the same thing with orion-application.xml, but it goes
in the ear's META-INF directory.  Very useful.

Good luck,
Jeff

-Original Message-
From: Sergei Batiuk [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 12, 2001 7:51 AM
To: Orion-Interest
Subject: Customizing CMP deployment


Is there any way to customize deployment of CMP bean - to 
indicate the table
name in the database to which the entity bean should map its 
persistence (in
case the name of the table is different from the bean name) or the data
source to connect to. As far as I know orion-ejb-jar.xml is 
responsible for
these properties, but it has no effect ibefore/i the deployment. Is
there an orion-specific (or some other) way to deliver such 
information to
the container?







RE: Design Advice (And Orion JNDI syntax) Needed

2001-03-12 Thread Jeff Schnitzer

Do these strings need to change dynamically without app redeployment?
If it's just error messages and the like, why not use
java.util.ResourceBundle?

String msg = ResourceBundle.getBundle("mymessages").getString(MSG_KEY);

You can store the resources in any format you like if you implement your
own ResourceBundle subclass, or you can use a .properties file.  If you
pass in the cool Orion classloader I believe it will dynamically reload
the data, too.  Check the javadocs.

Jeff

-Original Message-
From: Neal Kaiser [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 12, 2001 4:41 PM
To: Orion-Interest
Subject: Design Advice (And Orion JNDI syntax) Needed



Hello;

Problem: My application has many text strings (i.e. email 
messages, email
recipient addresses, canned messages, etc) that both my 
servlets and EJBs
need to access. It needs to be done in a way that these are 
not hardcoded
and can be accessed easily from servlets, ejbs, and possibly 
even standalone
applications.

My Solution: Have a MessageResources object that is created by 
a startup
servlet that contains all these strings. You can then use a
MessageResources.getValue(String) to get the desired string 
you want.  This
is all done, the startup servlet runs, reads in the XML file, 
and creates
the MessageResources.

My Problem: I now need a way to pass that MessageResource 
object into scope
so it is accessible by Servlets and EJBs (I'll worry about standalone
applications later).

However, I somehow need a way for the Stateless session bean 
to get this
MessageResource object.  I can't  do StartupServlet.getMR() 
because the EJBs
might be remote.

Is it possible to use JNDI and store an object? IF that is the 
case, then I
could do something like this in my stateless session bean:

public String getMessage(String key) {
  if (messageResources == null) {
 // lookup messageResources with JNDI
  }
}

How would I do this in OrionServer? I believe it is app server 
specific,
right?

Does anyone have any input? Is it the right way to do it?  
This must be a
common problem (global variables needed). How is everyone else 
doing this?








RE: Case insensitive primary keys

2001-03-11 Thread Jeff Schnitzer

Thanks for everyone's comments.

From: Rafael Alvarez [mailto:[EMAIL PROTECTED]]

You can do two things:
.- In the EJBCreate change the user name to Upper or Lower case  when
setting it. Also in the PK class change it to Upper or Lower case.

Not a good solution for me, because I want to preserve case.  I don't
want to maintain a second field with the correct case; I might as well
use an integer key.

.- Override the PK class equal() method, to compare the username in
Upper(Lower)case.

How does this work?  Doesn't the database need to be made aware of the
insensitivity?  How would finders work?

I'm confused about how an app server handles this.  Any information
would be very helpful :-)

Thanks,
Jeff


Thursday, March 08, 2001, 7:30:39 PM, you wrote:

JS I have a primary key which is a string (user's name), and 
I would like
JS it to be case-insensitive.  That is, if there is already a 
"bob" entity,
JS trying to create a "Bob" entity should throw a 
DuplicateKeyException.
JS Is there a way I can do this with Orion?
 
JS I vaguely recall reading something in the documentation 
about this, but
JS now I can't seem to find it.  I'm starting to think that I 
imagined it.
 
JS Thanks,
JS Jeff

-- 
Best regards,
 Rafaelmailto:[EMAIL PROTECTED]








Case insensitive primary keys

2001-03-08 Thread Jeff Schnitzer

I have a primary key which is a string (user's name), and I would like
it to be case-insensitive.  That is, if there is already a "bob" entity,
trying to create a "Bob" entity should throw a DuplicateKeyException.
Is there a way I can do this with Orion?
 
I vaguely recall reading something in the documentation about this, but
now I can't seem to find it.  I'm starting to think that I imagined it.
 
Thanks,
Jeff




RE: Problem retrieving dependents after Orion restart

2001-03-06 Thread Jeff Schnitzer

IMHO, it is unwise to be using EJB2.0 dependent objects at this point
because this is a part of the spec which is likely to change wildly.
There have even been significant changes between pd1 (when Orion's
implementation was built) and pfd.

You can circumvent the relationship table by creating a unidrectional
relationship from Phone to Person and a finder method for Phone which is
"findByPerson".  If you put a getPhone() method on Person, it can hide
the call to the finder on Phone.

Jeff

-Original Message-
From: Alex Paransky [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 05, 2001 10:37 PM
To: Orion-Interest
Subject: RE: Problem retrieving dependents after Orion restart


Has any one been able to get the Entity(1) to Dependent(N) relationship
working?  I am thinking of removing Dependent objects and just 
using Entity
Beans.  However, in the way Orion handles relationships, I will have an
extra table I do not really need.

If I have a PersonEntity relating to PhoneEntity in a 1-N 
scenario, then
Orion attempts to create PersonEntity-PhoneEntity join table.  
Is there a
way to modify orion-ejb-jar.xml to avoid this type of scenario.  All my
Entities are identified with integer key, so my phone table 
simply contains
a field called 'ownerId'.  Different types of entities can 
have phones, but
since all the entities are identified with the same type of 
primary key, I
can store that in the 'ownerId' field in the phone table.

Thanks.
-AP_

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Alex Paransky
Sent: Monday, March 05, 2001 6:13 PM
To: Orion-Interest
Subject: RE: Problem retrieving dependents after Orion restart


Here is an excerpt from orion-ejb-jar.xml, can someone tell me 
if I have
something configured incorrectly.  Again, the data is properly 
written to
the database, it is just NOT READ when orion is restarted and
getPhoneDependents() api is executed.

entity-deployment name="ejb.person.PersonEntity"
location="ejb.person.PersonEntity"
wrapper="PersonEntityHome_EntityHomeWrapper33"
table="ejb_person_PersonEntity" data-source="jdbc/siteDS"
  primkey-mapping
cmp-field-mapping
  fields
 cmp-field-mapping name="id" persistence-name="id" /
  /fields
/cmp-field-mapping
  /primkey-mapping
  cmp-field-mapping name="salutation" persistence-name="salutation" /
  cmp-field-mapping name="name" persistence-name="name" /
  cmp-field-mapping name="email" persistence-name="email" /
  cmp-field-mapping name="phoneDependents"
collection-mapping table="ejb_phones"
  primkey-mapping
cmp-field-mapping
  fields
cmp-field-mapping name="id" persistence-name="id" /
  /fields
/cmp-field-mapping
  /primkey-mapping
  value-mapping type="ejb.person.PersonPhone"
cmp-field-mapping name="value"
  properties
cmp-field-mapping name="id" persistence-name="id" /
cmp-field-mapping name="number" 
persistence-name="number" /
cmp-field-mapping name="person"
  entity-ref home="ejb.person.PersonEntity"
cmp-field-mapping name="person"
  fields
cmp-field-mapping name="id" 
persistence-name="ownerId"
/
  /fields
/cmp-field-mapping
  /entity-ref
/cmp-field-mapping
  /properties
/cmp-field-mapping
  /value-mapping
/collection-mapping
  /cmp-field-mapping
  ejb-ref-mapping name="ejb/id" /
/entity-deployment

Again, the ejb.person.PersonEntity has a 1 to N relation with dependend
ejb.pers.PersonPhone.

Thanks.
-AP_

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Alex Paransky
Sent: Monday, March 05, 2001 1:18 PM
To: Orion-Interest
Subject: Problem retrieving dependents after Orion restart


I have an entity bean with 1-N relationships to dependents.  I have two
clients, the first client executes a method on a session that 
populates and
works with the data.  The second client tries to access the 
data.  When I
run the first client followed by the second client, second client works
correctly.  When I run the first client, then RESTART ORION, 
then run second
client, second client fails to find dependents (but they are 
there, in the
table).

Here is the output:

Orion/1.4.7 initialized
Create person entity
Add phone1
Add phone2
Add phone3
Phone: 8551 (818) 541-0029 1
Phone: 8552 None 2
Phone: 8553 (310) 880-5962 3
Deleting last phone
Phones: [Lejb.util.Value;@44006e

[apara@junior orion]$ ./go
Orion/1.4.7 initialized
Phones: null

First we create a new person entity, set the phones 
(dependents), then list
the phones, finally delete the last phone.  Then restarting 
orion, we try to
lookup the phone dependents.  Phones returns as null.  The 
table contains
correct values.  Phones ARE there.

What could be wrong?

-AP_









RE: Database schema type mappings

2001-03-01 Thread 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":
type-mapping type="int" name="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

2001-03-01 Thread 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: CMP 2.0

2001-03-01 Thread 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]
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: Struts (was: I switch from X to Orion because: )

2001-03-01 Thread 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 
distributable / 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
us!  Even if the Struts code was slightly faster (which I doubt), any
performance gai

RE: Database schema type mappings

2001-03-01 Thread 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




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

2001-02-28 Thread Jeff Schnitzer

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 1:42 PM
To: Orion-Interest
Subject: RE: I switch from X to Orion because: 


Just a few comments...not angry comments. :-)

As a committer on an Apache project, let me just say that decisions to
support JDK 1.1, on a per-project basis, are not about supporting "dead
things". We have, in fact, people who _must_ use JDK 1.1 
(probably more than
you might think). As another example, we are a J2EE shop; but 
just recently
we had a (big) requirement to support ISAM data. That's 
ancient, too, but
I'll bet there's more ISAM data out there than there is 
relational data.
Would you personally turn up your nose at supporting ISAM? 
Well, maybe you
would. I dunno.

I haven't used Struts myself, but since you mention it, I'd 
guess you'd have
to ask Rickard himself why he decided to write his own 
framework. With all
due respect to him, the primary reason, 9 times out of 10, 
that people write
their own code is because as an industry we are damned 
terrible at re-use.
There are a whole bunch of bad reasons why this is so - 
laziness, arrogance,
reluctance to share the limelight, etc etc. Only rarely do you 
find that
somebody wrote code because they conducted a thorough search 
and couldn't
find anything that could even be modified. I'm personally 
pretty hot about
this topic because there is a huge amount of wasted time due to this.
Frameworks are a particularly bad offender - everybody and his 
brother wants
to write their own framework.

As far as bloat, well, that's in the eye of the beholder. If a product
provides 100 features, but any given user only needs 25 of 
them, but nearly
all of the features are useful to someone, it's "bloat" to 
almost everyone,
but also useful to almost everyone. It's only bad 

RE: Database schema type mappings

2001-02-28 Thread Jeff Schnitzer

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":
type-mapping type="int" name="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: CMP 2.0

2001-02-28 Thread Jeff Schnitzer

?
 
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]
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

2001-02-28 Thread Jeff Schnitzer

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: jsp form-based authentication

2001-02-27 Thread Jeff Schnitzer

You should look in the Orion javadocs for DataSourceUserManager.  Here's
an example of what to put in the orion-application.xml:
 
 user-manager class="com.evermind.sql.DataSourceUserManager"
  property name="table" value="Member" /
  property name="passwordField" value="password" /
  property name="defaultGroups" value="authenticated,god" /
  property name="usernameField" value="name" /
  property name="dataSource" value="jdbc/SimilarityCoreDS" /
  property name="staleness" value="0" /
 /user-manager

Note that you will also need to define your groups in principals.xml
(either the deployment version or the global version).
 
Good luck,
Jeff

 -Original Message-
From: Roland Dong [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 27, 2001 12:07 AM
To: Orion-Interest
Subject: RE: jsp form-based authentication



Has anyone responded to this message? I am also interested in that...
 
Roland

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Vaskin
Kissoyan
Sent: Friday, February 23, 2001 10:46 AM
To: Orion-Interest
Subject: jsp form-based authentication


I need a good example of looking up username/password in a database, how
do you override the security so that it checks a database instead of
checking the internal web.xml file and principals.xml?
 
 





RE: How do I map a .doc extension to a .jsp execution

2001-02-27 Thread Jeff Schnitzer

While that would work, you would have to create a separate jsp for each
document... really you should probably create your own servlet, map it
to *.doc in the same way, and use request.getPathInfo() and
request.getPathTranslated() (or just forward to the request to a URL in
a protected directory).

Or better yet, look into filters.  I haven't looked at the Servlet 2.3
specification for filters yet, but I suspect this is exactly the sort of
problem filters are designed to solve.

Jeff

-Original Message-
From: Christian Billen [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 27, 2001 5:03 AM
To: Orion-Interest
Subject: RE: How do I map a .doc extension to a .jsp execution


I haven't tried this but try to modify the 
config/global-web-application.xml
and add a mapping for the jsp servlet:
servlet-mapping
   servlet-namejsp/servlet-name
   url-pattern/*.doc/url-pattern
   /servlet-mapping


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Christian
 Kvalheim
 Sent: Monday, February 26, 2001 3:31 PM
 To: Orion-Interest
 Subject: How do I map a .doc extension to a .jsp execution


 Hello

 I have the following problem. We have a certain number
 of Word documents in out database that we want to
 output to the browser. Everything is fine, we get the
 document as a blob from the database and into the jsp
 variables. However for internet explorer to recognise
 the file as a word document (and start the viewer) we
 need to append a .doc extension. Since the urlcode is
 ...something/mydocument.jsp it does not get
 recognised. How can I make orion treat .doc files as
 .jsp files for execution on the server ?? This would
 allow me to wrap the execution logic into the .doc
 file and let the browser see the document (changing
 acording to which document is fetched from the server)

 Yours

 Christian Amor Kvalheim
 Quality Manager +

 __
 Do You Yahoo!?
 Get email at your own domain with Yahoo! Mail.
 http://personal.mail.yahoo.com/










RE: ONCE AGAIN !!!! PK.class CMP beans in ORION

2001-02-27 Thread Jeff Schnitzer

It's difficult to tell without seeing your deployment descriptor, but it
sounds like you're trying to use the PK class as a cmp-field.

You should not be doing this.  You should instead have cmp-fields for
each of the fields in the PK.  The only mention of the PK class in the
ejb-jar.xml should be the prim-key-class element.

I've found that it's pretty much necessary to read the DTDs for the
deployment descriptors.

Jeff

-Original Message-
From: faisal [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 27, 2001 11:09 AM
To: Orion-Interest
Subject: ONCE AGAIN  PK.class  CMP beans in ORION


Hi All
I already asked  this question long time ago.Including the pk 
class in Orion
ejb.jar seems to be beyond my intelligence.I ve been trying to 
apply Roman
e-commerce application from his book "Mastering Java Enterprise beans"
.May be there is another way of making the primary key in CMP 
bean available
to the rest of bean classes ...Any suggestion please..
Again the problem is : when I include the pk.class among the 
cmp bean CMP
FIELDS -the deployment descriptor can 't recognise the PK 
class  of the CMP
bean









RE: Orion FORM based authentication Configuraton problem

2001-02-26 Thread Jeff Schnitzer

If I'm reading the steps correctly, this behavior is actually fully
spec-compliant.  This is the reason I don't use FORM-based login.

j_security_check is only required to be valid immediately after an
attempt to visit a secured page.  There is no provision to be able to
re-enter credentials from the failure page, and the Orion implementation
doesn't allow it.  The user must hit the back button :-(

Also, Orion performs a forward() rather than a redirect() when a
successful login does occur.  Thus the ugly url in the user's browser.
I logged bug #126 against this issue but it was denied :-)

Jeff

-Original Message-
From: gnoht orion [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 26, 2001 3:41 AM
To: Orion-Interest
Subject: Re: Orion FORM based authentication Configuraton problem


ran into same problem, i think it's a bug in orion.
just remove the j_security_check from your action
field and login will still work, but correct url will
show up. can't really understand why it works this
way, hope it helps.

-t


--- cybermaster [EMAIL PROTECTED] wrote:
 When I use % authentication (1.4.5, W2K Server,
 jdk1.3), I've got a couple
 of problems:
 (1) Basic setup is: /Home.jsp, link to
 /secure/loginDummy.jsp
 (2) User tries to get to /secure/loginDummy.jsp -
 Orion redirects to
 /login.jsp
 (3) login correct works fine with /login.jsp -
 (browser shows
 /secure/dummyLogin as URL)
 (4a) browser displays /secure/loginDummy.jsp - OK,
 but: - (browser shows
 /secure/j_security_check as URL)
 BUT
 (4b) if first login incorrect, Orion redirects to
 /loginError.jsp - (browser
 shows /secure/j_security_check as URL)
 (5a) error again, page stays at /loginError.jsp jsp
 - (browser shows
 /secure/j_security_check as URL)
 (5b) user enteres correct passwd - "ERROR 404 Not
 Found - Resource
 /formAuth/secure/j_security_check not found on this
 server"
 somehow Orion forgets the correct URL (it shouldn't
 show j_security_check in
 the first place, I guess). The user is actually
 logged in, and can go to the
 /secure/* pages at this time.
 Peter Saurugger
 Everest eCommerce
 [EMAIL PROTECTED]
 
 
 


__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/






RE: Orion FORM based authentication Configuraton problem

2001-02-26 Thread Jeff Schnitzer

But then I also want to be able to enter login credentials on the
default page, so now that page must be login-required  error  the
homepage...

While I have no doubt that it could be made to work, this is not an
elegant or appropriate solution to the problem.  Sun needs to fix the
spec.

Jeff

-Original Message-
From: Nick Newman [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 26, 2001 12:26 PM
To: Orion-Interest
Subject: RE: Orion FORM based authentication Configuraton problem


I suppose that you could use the SAME page for login and 
error.  You could 
tell which context it's being called in by playing with a 
session variable, 
I think.  That should give you the flexibility you want, and 
all within spec.

Nick Newman

At 11:31 AM 2/26/01 -0700, you wrote:
I agree with Jeff the Servlet 2.2 Spec only specifies that an 
error page is
returned - so Orion's behaviour is up to spec. To allow 
continuation of the
login process from loginError page would be an add-on ... cerrtainly a
useful one, because it's more user friendly. But of course, 
it is Orion's
developers who call the shots.

--peter

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of 
Jeff Schnitzer
Sent: Monday, February 26, 2001 8:06 AM
To: Orion-Interest
Subject: RE: Orion FORM based authentication Configuraton problem

If I'm reading the steps correctly, this behavior is actually fully
spec-compliant.  This is the reason I don't use FORM-based login.

j_security_check is only required to be valid immediately after an
attempt to visit a secured page.  There is no provision to be able to
re-enter credentials from the failure page, and the Orion 
implementation
doesn't allow it.  The user must hit the back button :-(

Also, Orion performs a forward() rather than a redirect() when a
successful login does occur.  Thus the ugly url in the user's browser.
I logged bug #126 against this issue but it was denied :-)

Jeff








RE: HELP!!! - Using UserManagers - Logging in users without asking for credentials

2001-02-25 Thread Jeff Schnitzer

You want to use the RoleManager:

  Context ctx = new InitialContext();
  RoleManager roleMan =
(RoleManager)ctx.lookup("java:comp/RoleManager");

  try
  {
   roleMan.login(memberName, password);
  }
  catch (SecurityException ex)
  {
   return false;
  }
  
  return true;

-Original Message-
From: Chris Evans [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 25, 2001 3:49 PM
To: Orion-Interest
Subject: HELP!!! - Using UserManagers - Logging in users without asking
for credentials


Hey,

I've tried everything that I can think of without any proper
documentation/examples to go by.  What i'm trying to do is have a
servlet accept requests from another website.  Balled up in that request
would be user credentials(ie: username, password, etc...).  From the
request I want to log in that user to my application without them
knowing they have switched sites.  I thought EJBManager was the way to
go but without any real documentation i'm at a loss as to how to go
about doing this.  Right now we use DataSourceUserManager and form-based
login to accept the users info and that works fine.

Does anybody have any idea/examples on how to do this???

I've tried changing the user-manager in orion-application.xml to
"com.evermind.ejb.EJBManager" but I can't figure out how to use/see it
in a servlet to be able to do lookups on the DB.

Thanks,



Chris Evans
Canlink Interactive Technologies




RE: CMP 2.0

2001-02-24 Thread Jeff Schnitzer

From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]

Question A: Are the ones of you who are using CMP 2.0 using 
version 1.4.4,
1.4.5 or 1.4.7 of Orion?

I'm using 1.4.5 because 1.4.7 introduced a showstopper bug for me (fixed
in 1.4.8, whenver that happens).  Bug #296.

Question B: When _you_ use the uni-directional 
relationship-features does
that make Orion create a seperate table for the relation or is the
relationship stored as a serialized collection attribute (in 
the 1:N case,
of course)?

It depends on how you set the visibility.  If you put the unidirectional
relationship on the 1: side, a separate relationship table is created.
If you put the unidirectional relationship on the :N side, a column is
created in the N table.

Question C: Would you mind posting an example of a unidirectional
ejb-relation declaration that you have made work. Preferably 
both a 1:N and
1:1 relationship.

I couple weeks ago I posted some examples of "modern" ant buildfiles
which included a small test project you will probably find helpful:

http://www.infohazard.org/ServerTest.zip

This is the project I've been using to probe the rough spots of Orion.
It currently is set up for a bidirectional 1:N relationship between two
entities (Foo and Bar).  Changing it to unidirectional should be
trivial.

A think the ideas behind CMP 2.0 are absolute magnificent, but 
gee, it has
been a hard struggle for me to make it work on Orion :) . 
Often when I test
my new CMP 2.0 application Orion simply just crashes - no 
error messages,
nothing, it just closes. - I think I am starting to understand 
what was ment
with "CMP 2.0 preview" as it says on the web site (LOL).

It works.  I had a rough time when I started too, but mostly because the
only documentation for EJB2.0 was (and probably still is) the spec.  My
most perverse case is a bean whose PK is a compound of two CMR fields,
and it works just fine.

To be honest, and I think this is a common complaint with entity beans -
if I had simply used JDBC in session beans, I would have been done a
long, long time ago.  And the app would probably perform an order of
magnitude faster.  I cringe when I see the blizzard of select statements
issued by a finder method.

Jeff




RE: CLASSPATH setup

2001-02-23 Thread Jeff Schnitzer

The J2EE sdk is not necessary, and probably should be removed.  It is
the reference implementation of a J2EE server.  You will be using Orion
instead.

Why aren't you using the 1.3 jdk?

Put the postgres jdbc driver in the orion/lib directory.

That should work :-)

Jeff

-Original Message-
From: Peter Peltonen [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 23, 2001 4:27 AM
To: Orion-Interest
Subject: CLASSPATH setup



I'm a beginner with Orion and Java setup with Linux. I would 
like to know if I
have setup my system correctly.

I have installed the following on my RedHat 6.2 system:

postgresql-jdbc-7.0.2-2
jdk-1.2.2
j2sdkee-1.2.1
orion-1.4.5

For everything work right, I should have the CLASSPATH 
variable setup right,
yes? I am a bit confused where to setup it, actually.


Java 2 SDK Enterprise Edition
-

Reading the j2sdkee-1.2.1 installation instructions  I added 
the postgres
jdbc-driver to the J2EE_CLASSPATH variable in
/usr/local/java/j2sdkee1.2.1/bin/userconfig.sh:

--snip--
J2EE_CLASSPATH=/usr/src/j2sdkee1.2.1/lib/j2ee.jar:/usr/src/j2sd
kee1.2.1/lib/system/jdbc7.0-1.2.jar
export J2EE_CLASSPATH
--snip--

I tried running the userconfig.sh script but nothing seems to 
happen. My
J2EE_CLASSPATH variable did not appear to be existing when I 
ran echo. So,
when is this file read, then? 

And what does this warning mean (quoted from the installation 
instructions):

"Note: You should remove the driver .jar files from the 
CLASSPATH environment
variable."

So, what is the relation with J2EE_CLASSPATH and CLASSPATH?

In my setup (see below) J2EE_CLASSPATH is included in 
CLASSPATH, is this
wrong?



/etc/profile


As running usreconfig.sh did nothing, I configured the 
variables I needed in
/etc/profile. In my /etc/profile reads:

--snip--
JAVA_HOME=/usr/local/java/jdk1.2.2
J2EE_CLASSPATH=/usr/src/j2sdkee1.2.1/lib/system/jdbc7.0-1.2.jar
CLASSPATH=$JAVA_HOME:$J2EE_CLASSPATH

export JAVA_HOME J2EE_CLASSPATH CLASSPATH
--snip--

So, my current setup is this:

[peter@cayman orion]$ echo $CLASSPATH
/usr/local/java/jdk1.2.2:/usr/src/j2sdkee1.2.1/lib/system/jdbc7
.0-1.2.jar

[peter@cayman orion]$ echo $JAVA_HOME
/usr/local/java/jdk1.2.2

[peter@cayman orion]$ echo $J2EE_CLASSPATH
/usr/src/j2sdkee1.2.1/lib/system/jdbc7.0-1.2.jar


Is this alright? Am I missing something etc.?


Regards,
Peter






RE: deployment

2001-02-23 Thread Jeff Schnitzer

A side note:

In the current Orion release, you need to specify the action as

action="%= request.encodeURL("/servlet/MyServlet") %"

For some reason, Orion does not automatically rewrite action urls with
the session id like it does with other urls in pages.  I've logged this
in Bugzilla.

It's worthwhile stepping through your application with cookies turned
off to find the problem spots.

Jeff

-Original Message-
From: Richard Doust [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 23, 2001 12:42 PM
To: Orion-Interest
Cc: [EMAIL PROTECTED]
Subject: RE: deployment


There's more to deploying the servlet than just setting the 
correct values
in the FORM tag, here's some thoughts:
Use "POST" as the method for processing the FORM. That's 
basically what it's
meant for.
The ACTION attribute should be the name of your servlet. If you've
configured your servlet in the .xml files that Orion uses for 
that purpose,
there's more to it than if you simply deploy your 
Servlet.class file to the
default directory which I think is 
/orion/default-web-app/WEB-INF/Classes.
Assuming you put it in the default directory, your servlet should get
invoked when you click on the form's submit button.
Try:
   ACTION="/servlet/MyServlet"
/servlet is set up as the default servlet-webdir in the
global-web-application.xml file.
Rich

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Siling Zhang
Sent: Friday, February 23, 2001 3:11 PM
To: Orion-Interest
Cc: [EMAIL PROTECTED]
Subject: deployment


Does anyone know how to deploy a servlet and html form page on 
orion? What
should go into the Action=" " on the html form?
FROM METHOD = "get" ACTION = "??.."

Siling







RE: EJB 2.0 CMP features of Orion

2001-02-22 Thread Jeff Schnitzer

Unidirectional 1-1 and 1-n relationships between EJBs work, but
bidirectional relationships do not.  There are easy ways to fake it,
though.

It's not strictly according to the specification - with Orion, you must
define the CMR fields as cmp-fields in the entity.  pd2 and pdf say
you shouldn't.  This may have been a change going from pd1 to pd2; most
of the CMR (and DO) stuff is based on pd1.  I can't fault the Orion team
for not keeping up with every zigzag (there have been several).

Another thing I noticed is that (at least in 1.4.5) primitive EJB-QL
seems to work.  When I create a simple findByField method, Orion figures
out how to create the appropriate finder-method in orion-ejb-jar.xml.

Jeff

-Original Message-
From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 21, 2001 4:48 AM
To: Orion-Interest
Subject: EJB 2.0 CMP features of Orion


Has anyone tried out OR-mapping of 1-1 relationships and 1-n 
relationships
between two EJBs? I have seen Jim Archer's fine tutorial about 
EJBs having a
1-1 or 1-n relationship to a *dependent object*, but is the same thing
possible between two EJBs?
I know the web site states that Orion 1.2.9 does NOT support n-m
relationships, but is 1-1 or 1-n supported in the latest 
release, and is the
support for 1-1 and 1-n in accordance with the specification?

Randahl







RE: Application clients

2001-02-22 Thread Jeff Schnitzer

There are a number of posts in the archive about how to configure the
initial context (either programmatically or by using a jndi.properties
file).  In addition to that:

Define a META-INF/application-client.xml and package it in the client's
jar.
Define the application client in the j2ee application.xml descriptor
with modulejava.
Package the client jar in the ear.
Deploy the ear file.
Run the client from the "applications" directory.  Theoretically the
client has been "deployed", but I don't think Orion does anything to it
other than unpack the ear.

Make sure that orion.jar is in the classpath when executing the client.
This is more challenging that you would think.  The Sun JDK 1.3 "java"
ignores the classpath (even if you specify it on the command line) if
you use the -jar parameter ($@#%!!).  You can either put your app
client jar and orion.jar on the classpath and specify the main class, or
you can put orion.jar in the Class-Path field of the
META-INF/MANIFEST.MF for your application client (but be careful of the
path).

If you're running on Windows, watch out executing the app client from
the orion "applications" directory (or whever you have it deployed to);
subsequent deployments of the ear file will fail with an IO error
because it can't write to the client jar file.  Even if you haven't
changed the client jar file and it shouldn't need to be written.

There are probably other ways of doing this, but this is what seemed
most j2ee-correct to me.  I imagine some app servers do something
special to the client in the process of deploying it, but Orion is not
that sophisticated (yet).

Jeff

-Original Message-
From: Alexander Jerusalem [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 21, 2001 2:11 PM
To: Orion-Interest
Subject: Application clients


Hi,

Can anyone tell what I have to do to use EJBs in Orion from an 
application 
client?

thanks,

Alexander Jerusalem
vknn
[EMAIL PROTECTED]







RE: Any way to forward to j_security_check?

2001-02-22 Thread Jeff Schnitzer

Yes, this works, and is how I perform user authentication.  It's not app
server portable though.  :-(

Jeff

-Original Message-
From: Andre Vanha [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 22, 2001 8:52 AM
To: Orion-Interest
Subject: RE: Any way to "forward" to j_security_check?


It might be possible to achieve this without forwarding.   I 
haven't tried
it, but using Orion's role manager might do the trick.  First you can
retrieve the role manager using RoleManager manager = (RoleManager)new
InitialContext().lookup("java:comp/RoleManager"); The you can 
call login on
the RoleManager with the appropriate username and password. 
This may do the
trick.  You can get more info about the user manager in the 
Orion API docs
or at
http://www.orionserver.com/docs/api/com/evermind/security/RoleM
anager.html.

Let me know if this works, I'm curious muslef.

Andre


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 22, 2001 5:27 AM
To: Orion-Interest
Subject: Any way to "forward" to j_security_check?


Does anyone know a way to "forward" to the j_security_check 
processing in
Orion ? We use form-based login but have our own processing to 
do ahead of
the
standard j_security_check.

On J2EE Reference Implementation (and e.g. Weblogic) we post 
the form to our
own servlet instead of j_security_check, then forward from this to
j_security_check. This doesn't seem to work on Orion i.e. 
j_security_check
doesn't seem to be something one can get a request dispatcher for.

Of course, the servlet spec doesn't mandate anything about how 
the server
should implement the j_security_check mechanism, so 
potentially it doesn't
have to have anything that can be referenced and invoked from 
application
code. But it would be useful to be able to.

I've also thought about programmatically simulating a post to
j_security_check
instead of trying to forward to it, but doesn't look simple 
and not sure
this
would work on Orion either. Might be helped by Servlet 2.3 but 
can't move to
that yet.

Am I just missing some trick to this, or is it not possible on 
Orion? Or is
it
related to a bug somewhere ? (n.b. even a normal post to 
j_security_check
seems to fail, and to get sign-on to work I have to use 
Orion's non-standard
feature of leaving the action unspecified).




 
***
NIG
The National Insurance 
Guarantee Corporation PLC

Reg. Office :
   Crown House
   145 City Road
   London
   EC1V 1LP

Registered in England  Wales No : 42133
***
Legal disclaimer :
This message is confidential and for use by the addressee only.  If the
message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer.

NIG does not accept responsibility for changes made to this message
after it was sent.







RE: EJB Clustering -- ANYONE? [Urgent!]

2001-02-22 Thread Jeff Schnitzer

I would like to see the documentation for the orion deployment
descriptors fleshed out.  Right now it's sparse and choppy, with some
sentences just cut off in the middle.  Verbose explanations with
examples would be a major improvement.

More than anything else, though, I think Orion needs a FAQ-O-MATIC.

Jeff

-Original Message-
From: Magnus Stenman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 22, 2001 7:43 AM
To: Orion-Interest
Subject: Re: EJB Clustering -- ANYONE? [Urgent!]


Hello,
stay tune for a little while longer (if you want to and are 
able to). There will be a clustering-howto released in roughly 
a week or so (no promises though, just an estimate), and yes 
there's plenty of support (and more to come). The doc will be 
kind of an 'umbrella doc' to the already released 
http-clustering-howto covering the other tiers of an application.

While on that note, what are the other especially wanted areas 
for improved/more elaborate documentation (howto's and 
similar)? Please be as specific as possible (ie the opposite 
of "improved overall documentation" :) and keep in mind that 
the security-primer is already in the pipe. Thanks in advance!

/Magnus Stenman, the Orion team

PS. Not getting a reply when asking where to send money do 
sound strange indeed. We're understaffed relative to the 
demand so we have a hard time getting back to sales queries 
etc, but actual ordering should not be any problem whatsoever. 
Can you please forward what you sent to [EMAIL PROTECTED] 
and to me as well and I'll try to see what has happened to it. Thanks!


- Original Message - 
From: "Dylan Parker" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Wednesday, February 21, 2001 7:33 PM
Subject: EJB Clustering -- ANYONE? [Urgent!]


 Hello, all.
 
 My company is about to drop Orion.
 
 The documentation issues, the dead website, the documentation issues,
 the absence of company responses, the documentation issues...
 
 We've contacted them asking where to send our money. Nothing back.
 
 In one last futile attempt to keep Orion afloat in my 
company a little
 longer, can anyone provide me with the following information?
 
 How does one do EJB Clustering with Orion?
 Has anyone made this work?
 Can anyone give some background on the configuration steps?
 
 If I don't hear anything... then JRun, here we come.
 
 Thanks,
 Dylan Parker
 
 







  1   2   >