date:20010515

Re: 1.4.8 and JMS

2001-05-15 Thread Noah Nordrum

We are using them with EJB2.0 Message Driven Beans and they are working
great.

Noah

- Original Message -
From: Vidur Dhanda [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Monday, May 14, 2001 9:17 PM
Subject: 1.4.8 and JMS

 Has anyone successfully used JMS Topics after 1.4.5.  I have tried on
 all versions since and the clients do not receive any messages.

 Vidur

 --
 Vidur Dhanda
 Active Solutions
 tel: 617/566-1252
 cell: 617/821-7115
 [EMAIL PROTECTED]
 www.active-solutions-inc.com

_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

RE: CMP Primary Key and ejbCreate

2001-05-15 Thread Robert Nicholson


The signature for ejbCreate is the same for CMP and BMP. The idea is that
you should be able to subclass a CMP bean to make it BMP. ie. vendors can
ship beans designed to work with CMP but when that's too inflexible you can
subclass and make BMP beans instead.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Ben
 Christensen
 Sent: Monday, May 14, 2001 8:15 PM
 To: Orion-Interest
 Subject: CMP Primary Key and ejbCreate


 When I generate a CMP bean with a Primary Key Class, it compiles and
 packages fine as far as the java side is concerned, however, when it is
 deployed, it has an issue.

 According to page 69 of the J2EE developers guide (I checked to be sure
 I wasn't just talking about anything), it says that if the bean has
 Container Managed Persistence, then the ejbCreate method should return
 null... the container handles that along with ejbFindByPrimaryKey...

 So, I have left it as null, but am using a custom Primary Key class.
 When I try to deploy it, it says:

 Error compiling ... filename ... method public void ... ejbCreate()
 throws javax.ejb.CreateException, java.rmi.RemoteException doesn't
 return a ... PrimaryKey (the path to the primary key class)

 Then the deploy fails.

 In JBoss, just to see what it had to say, it at least will deploy it but
 still gives a warning saying:

 The return type of an ejbCreate(...) method must be the entity bean
 primary key type.


 From what I can tell in the documentation, these errors are wrong

 On a BMP bean, then yes I should have to return the Primary Key class
 type from the ejbCreate method, this is stated in the developers guide,
 but not for a CMP bean.

 In the 1.3 preview release of the developers guide, it states the same
 thing for BMP beans, however, it doesn't say anything about CMP -- it
 says TBD ... maybe To Be Discussed... like TBA, I don't know... but
 considering we're still using 1.2.1 standards, I'd like to know if I'm
 just completely wrong, or this issue has been overlooked in the
 orionserver (and jboss to some degree) deployment.

 If it has changed since earlier versions of EJB specs and I'm just not
 seeing it, I'd appreciate someone explaining it to me.

 I've run this through VisualAge Enterprise Edition 3.5 as well... it
 works fine with ejbCreate returning null on a CMP with a primary key
 class, and if I try to tell it to return the key type, then it flags
 warnings about it.

 I can fool it into thinking everything is alright by setting the
 ejbCreate to return the primary key, but is this the correct way of
 doing this considering what the specs say?

 Thanks in advance.


 --
 Ben Christensen
 Novisum Development Inc.
 www.novisum.com
 [EMAIL PROTECTED]
 780-909-4707

RE: CMP Primary Key and ejbCreate

2001-05-15 Thread Robert Nicholson

It's null but the return type of ejbCreate is always the primary key class
never void.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Ben
 Christensen
 Sent: Monday, May 14, 2001 8:15 PM
 To: Orion-Interest
 Subject: CMP Primary Key and ejbCreate

 When I generate a CMP bean with a Primary Key Class, it compiles and
 packages fine as far as the java side is concerned, however, when it is
 deployed, it has an issue.

 According to page 69 of the J2EE developers guide (I checked to be sure
 I wasn't just talking about anything), it says that if the bean has
 Container Managed Persistence, then the ejbCreate method should return
 null... the container handles that along with ejbFindByPrimaryKey...

 So, I have left it as null, but am using a custom Primary Key class.
 When I try to deploy it, it says:

 Error compiling ... filename ... method public void ... ejbCreate()
 throws javax.ejb.CreateException, java.rmi.RemoteException doesn't
 return a ... PrimaryKey (the path to the primary key class)

 Then the deploy fails.

 In JBoss, just to see what it had to say, it at least will deploy it but
 still gives a warning saying:

 The return type of an ejbCreate(...) method must be the entity bean
 primary key type.

 From what I can tell in the documentation, these errors are wrong

 On a BMP bean, then yes I should have to return the Primary Key class
 type from the ejbCreate method, this is stated in the developers guide,
 but not for a CMP bean.

 In the 1.3 preview release of the developers guide, it states the same
 thing for BMP beans, however, it doesn't say anything about CMP -- it
 says TBD ... maybe To Be Discussed... like TBA, I don't know... but
 considering we're still using 1.2.1 standards, I'd like to know if I'm
 just completely wrong, or this issue has been overlooked in the
 orionserver (and jboss to some degree) deployment.

 If it has changed since earlier versions of EJB specs and I'm just not
 seeing it, I'd appreciate someone explaining it to me.

 I've run this through VisualAge Enterprise Edition 3.5 as well... it
 works fine with ejbCreate returning null on a CMP with a primary key
 class, and if I try to tell it to return the key type, then it flags
 warnings about it.

 I can fool it into thinking everything is alright by setting the
 ejbCreate to return the primary key, but is this the correct way of
 doing this considering what the specs say?

 Thanks in advance.

 --
 Ben Christensen
 Novisum Development Inc.
 www.novisum.com
 [EMAIL PROTECTED]
 780-909-4707

SV: unable to configure form-based authentication correctly

2001-05-15 Thread Magnus Rydin

Title: SV: unable to configure form-based authentication correctly

No, the distinction between groups and roles are correct.
The mapping should be in the /deploy-dir/orion-application.xml and map the roles to groups, as done.
If you check out the deploy dir of the ATM you will notice that Orion has automatically mapped the role users to the group users per default.

Now, the mapping should look like:
security-role-mapping name=r_user
group name=g_users /
/security-role-mapping

You probably want this outside your namespace-access/ tag though.
WR

-Ursprungligt meddelande-
Från: elephantwalker [mailto:[EMAIL PROTECTED]]
Skickat: den 14 maj 2001 11:15
Till: Orion-Interest
Ämne: RE: unable to configure form-based authentication correctly

AFIK the role name and the group name have to be the same.
You use r_users
and g_users. This could be the problem. ATM app uses role=users and
group=users.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Humphrey Sheil
Sent: Monday, May 14, 2001 10:20 AM
To: Orion-Interest
Subject: unable to configure form-based authentication correctly

I am unable to achieve a basic goal with orion: to force form-based
authentication using the simplest form of authentication (userids and
passwords stored in principals.xml).

I have read all the posts on this subject on the mailing
list, but to no
avail. I also tried the security primer on jollem.com, but
the author of
this primer told me that this tutorial is not yet working. I
also saw the
posts by Bill Winspure on Fri, 11 May 2001, but the mail
archive hasn't got
the zip file attached to the mail.

My application works fine without authentication, so there
are no other
non-security related things affecting this.

My procedure to add form-based auth.

1. I add three new attributes to my web.xml:

!-- attribute 1. declare the role I want to access my pages --

security-role
role-namer_user/role-name
/security-role

!-- attribute 2. now tell the container what and how I want
protected --
!-- note that the role-name attribute matches my
security-role attribute
above --

security-constraint
web-resource-collection
web-resource-nameProtected Area/web-resource-name
!-- Define the context-relative URL(s) to be protected --
url-pattern/*/url-pattern
!-- If you list http methods, only those methods
are protected --
http-methodDELETE/http-method
http-methodGET/http-method
http-methodPOST/http-method
http-methodPUT/http-method
/web-resource-collection
auth-constraint
!-- Anyone with one of the listed roles may access
this area --
role-namer_user/role-name
/auth-constraint
/security-constraint

!-- attribute 3. let the container know that I want to
use form-based
auth., and redirect to login.jsp --
!-- the form in login.jsp conforms to the servlet 2.2
spec. naming
conventions --
login-config
auth-methodFORM/auth-method
realm-nameExample Form-Based Authentication Area/realm-name
form-login-config
form-login-pagelogin.jsp/form-login-page
form-error-pageerror.jsp/form-error-page
/form-login-config
/login-config

2. I edited the principals.xml contained in
$ORION_HOME/config to contain
my user and group:

group name=g_user/

user username=testuser password=xxx
group-membership group=g_user /
/user

3. I built and deployed the application at this point, and
started orion
server (with a fresh application-deployment directory).

Next, I went to my application sub-directory under
$ORION_HOME/application-deployments.

Here I edited orion-application.xml and added two
security-role-mapping
attributes, one each in the read-access and write-access sections as
follows:

namespace-access
read-access
namespace-resource root=
security-role-mapping
name=lt;jndi-user-rolegt;
group name=administrators /
/security-role-mapping
security-role-mapping name=lt;r_usergt;
group name=g_user /
/security-role-mapping
/namespace-resource
/read-access
write-access
namespace-resource root=
security-role-mapping
name=lt;jndi-user-rolegt;
group name=administrators /
/security-role-mapping
security-role-mapping name=lt;r_usergt;
group name=g_user /
/security-role-mapping
/namespace-resource
/write-access

(notes: I tried this with and without the lt; gt;. I also
tried adding
just one security-role-mapping).

The form-based auth. still does not work. I am presented
with the login
form correctly when I try to access a protected resource, but
my username
and password is always rejected.

Is this functionality working in orion server 1.4.5?

What have I missed in my steps above?

Has anybody gotten this to work?

Thanks in advance

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

RE: DeadLock with 25 users SOLVED

2001-05-15 Thread PHiL


Nick, In all my I use transactions only when I update/insert/delete
something in the database. When there is a risk of database's incoherents
datas you need to use transaction, just in case or you need to rollback
for let the datas unchanged.
When you read (only reading!) something from the database, no risk of damage
somethnig, no need to rollback, so transcations are not usefull (IMHO...).

I was using this rules with native/PHP/ASP coding, but maybe with EJB I'm
wrong. If it's the case, please just explain me, it's true that I'm not an
EJB wizard ;-)

Thanks,

PHiL.


 Philippe,

 It's Monday morning. Could you please help my fuzzy brain by
 explaining WHY
 it is so stupid to set all transactions to required. I'm
 afraid it
 sounds reasonable to me...  perhaps I don't understand what
 you mean by
 even when reading in the database.

 Thanks,
 Nick


 At 12:43 PM 5/14/01 +0200, you wrote:
 Hi,
 
 Thanks Johan and Kirk, you are both right.
 Those 2 parametres are usefull for tuning the app server.
 But pay attention, I've used the timeout (not
 inactivity-timeout) under
 1.3.8, it doesn't work, need to upgrade to 1.4.7 for get
 this working.
 
 I've discover another one:
 In the file orion-ejb-jar.xml you could add this option
 ligne: call-timeout
 = n
 n = number of millisec for waiting on the EJB's interface
 reply, 0 for
 infinite.
 
 My principal error with this deadlock was to set ALL
 transactions to
 required, even when reading in the database... So stupid ;-)
 
 My bench show that 100 users could access to our app wihtout
 crashing! I'll
 try to bench the same .EAR under BEA...
 
 Regards,
 
 Philippe PAGET.
 
   -Message d'origine-
   De : Johan Fredriksson
 [mailto:[EMAIL PROTECTED]]
   Envoyé : lundi 14 mai 2001 10:23
   À : Orion-Interest
   Objet : Re: DeadLock with 25 users
  
  
   Or decreasing the
  
   inactivity-timeout=10
  
   so the resource is more quickly released back to the container ?
  
  
   Johan
  
  
   - Original Message -
   From: KirkYarina [EMAIL PROTECTED]
   To: Orion-Interest [EMAIL PROTECTED]
   Cc: PHiL [EMAIL PROTECTED]
   Sent: Friday, May 11, 2001 9:10 PM
   Subject: Re: DeadLock with 25 users
  
  
I believe this is discussed in past; see the archives (
   
  
 http://www.mail-archive.com/orion-interest%40orionserver.com/ ).  Try
increasing max-connections in data-sources.xml
   
Kirk Yarina
   
At 09:13 AM 5/11/01 +0200, you wrote:
Hello, we just start some benchs with 25 fake users,
 here is the
   exeption:
Those 25 users try to access the same EJB. Any idears, or
   points to check
   in
our code to fix this kind of errors ???

Thanks.

Philippe.


ERROR | 09/05/2001 15:59:01:46 | NodeBmEJB :
   findNode(NodePK pk) | pk =
   (id
= 0, space = WA17, componentName = news35) |
Exception message: Transaction was rolled back: timed out,
   while waiting
   for
(id = 0, space = WA17, componentName = news35) (started at
   Wed May 09
15:58:25 GMT+01:00 2001, terminated at Wed May 09 15:59:01
   GMT+01:00
   2001)
com.evermind.server.DeadlockException: Transaction was
   rolled back: timed
out, while waiting for (id = 0, space = WA17,
   componentName = news35)
(started at Wed May 09 15:58:25 GMT+01:00 2001, terminated
   at Wed May 09
15:59:01 GMT+01:00 2001)
 at
   com.evermind.server.ejb.AbstractEJBObject.startCall(JAX)
 at
   
   NodeHome_EntityHomeWrapper3.findByPrimaryKey(NodeHome_EntityH
   omeWrapper3.ja
   v
a:195)
 at
   
   com.stratelia.webactiv.util.node.control.NodeBmEJB.findNode(N
   odeBmEJB.java:
   5
0)
 at
   
   com.stratelia.webactiv.util.node.control.NodeBmEJB.getFrequen
   tlyAskedChildr
   e
nDetails(NodeBmEJB.java:252)
 at
   
   NodeBm_StatelessSessionBeanWrapper1.getFrequentlyAskedChildre
   nDetails(NodeB
   m
_StatelessSessionBeanWrapper1.java:1677)
 at
   
   com.stratelia.webactiv.news.control.NewsSessionControl.getArc
   hiveList(NewsS
   e
ssionControl.java:315)
 at
   
   __jspPage1_news_jsp_news_jsp._jspService(__jspPage1_news_jsp_
   news_jsp.java:
   4
73)
 at com.orionserver.http.OrionHttpJspPage.service(JAX)
 at com.evermind.server.http.HttpApplication.xu(JAX)
 at com.evermind.server.http.JSPServlet.service(JAX)
 at com.evermind.server.http.d4.s3(JAX)
 at com.evermind.server.http.d4.s1(JAX)
 at com.evermind.server.http.d4.forward(JAX)
 at com.evermind.server.http.ew.forward(JAX)
 at
   
   com.stratelia.webactiv.servlets.ComponentRequestRooter.doPost
   (ComponentRequ
   e
stRooter.java:153)
 at
   
   com.stratelia.webactiv.servlets.ComponentRequestRooter.doGet(
   ComponentReque
   s
tRooter.java:172)
 at
   javax.servlet.http.HttpServlet.service(HttpServlet.java:190)
 at

SV: 1.4.8 and JMS

2001-05-15 Thread Magnus Rydin

Title: SV: 1.4.8 and JMS





I can confirm that the ATM demo still works with Orion/1.4.8 (build 10374).
WR


 -Ursprungligt meddelande-
 Från: Vidur Dhanda [mailto:[EMAIL PROTECTED]]
 Skickat: den 14 maj 2001 19:17
 Till: Orion-Interest
 Ämne: 1.4.8 and JMS
 
 
 Has anyone successfully used JMS Topics after 1.4.5. I have tried on
 all versions since and the clients do not receive any messages.
 
 Vidur
 
 --
 Vidur Dhanda
 Active Solutions
 tel: 617/566-1252
 cell: 617/821-7115
 [EMAIL PROTECTED]
 www.active-solutions-inc.com

Re: CMP Primary Key and ejbCreate

2001-05-15 Thread Armin Michel


The point is that the declaration of your ejbCreate() must specify that you 
will return the PrimKeyClass. In the implementation of the ejbCrate() however 
you just return null - a PrimKeyClass null.

That's how I do it and that's what I think is correct with respect to the 
spec.

Yours

Armin Michel

 When I generate a CMP bean with a Primary Key Class, it compiles and
 packages fine as far as the java side is concerned, however, when it is
 deployed, it has an issue.

 According to page 69 of the J2EE developers guide (I checked to be sure
 I wasn't just talking about anything), it says that if the bean has
 Container Managed Persistence, then the ejbCreate method should return
 null... the container handles that along with ejbFindByPrimaryKey...

 So, I have left it as null, but am using a custom Primary Key class.
 When I try to deploy it, it says:

 Error compiling ... filename ... method public void ... ejbCreate()
 throws javax.ejb.CreateException, java.rmi.RemoteException doesn't
 return a ... PrimaryKey (the path to the primary key class)

 Then the deploy fails.

 In JBoss, just to see what it had to say, it at least will deploy it but
 still gives a warning saying:

 The return type of an ejbCreate(...) method must be the entity bean
 primary key type.


 From what I can tell in the documentation, these errors are wrong

 On a BMP bean, then yes I should have to return the Primary Key class
 type from the ejbCreate method, this is stated in the developers guide,
 but not for a CMP bean.

 In the 1.3 preview release of the developers guide, it states the same
 thing for BMP beans, however, it doesn't say anything about CMP -- it
 says TBD ... maybe To Be Discussed... like TBA, I don't know... but
 considering we're still using 1.2.1 standards, I'd like to know if I'm
 just completely wrong, or this issue has been overlooked in the
 orionserver (and jboss to some degree) deployment.

 If it has changed since earlier versions of EJB specs and I'm just not
 seeing it, I'd appreciate someone explaining it to me.

 I've run this through VisualAge Enterprise Edition 3.5 as well... it
 works fine with ejbCreate returning null on a CMP with a primary key
 class, and if I try to tell it to return the key type, then it flags
 warnings about it.

 I can fool it into thinking everything is alright by setting the
 ejbCreate to return the primary key, but is this the correct way of
 doing this considering what the specs say?

 Thanks in advance.


 --
 Ben Christensen
 Novisum Development Inc.
 www.novisum.com
 [EMAIL PROTECTED]
 780-909-4707

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: Generating primary keys

2001-05-15 Thread Joni Suominen


Hi!
I use a bit similar approach that in the Brett's article. The difference
is that instead of hitting database every time a small cache is kept for
each sequence. The algorithm is simple. Each unique id consists of two
values: high and low (uid = high + low). The UidGenerator is initialized
from a database. It exclusively reads a high value from db and updates
high value in database by one. This ensures that each possible generator
gets a unique high value. Then on each getNextUid() call a value high +
low is returned and low is increased by one. If low value hits its
maximum it is set back to 0 and a new high value is read from the
database.

Consequences:
+ better scalability since most of the uids are generated in memory
without database access
+ works also in a distributed environment since each UidGenerator is
initialized with a unique high value
+ should work on any J2EE app server
- leaves unused uids every time the system is booted

This HIGH-LOW algorithm is explained in:
http://www.sdmagazine.com/articles/1999/9912/9912p/9912p.htm

Here's some sample code. My version is implemented as a BMP entity bean
and uids are Java long variables. LOW cache is set to be 16 numbers but
this is easy to change just by tweaking the constants: LOW_LENGTH and
LOW_MAX.

UidGenerator.java:
##
package org.shiftctrl.uid.persistence;

import java.rmi.RemoteException;

import javax.ejb.EJBObject;

/*
 * @author Joni Suominen
 * @version 
 */
public interface UidGenerator extends EJBObject {
public long getUid() throws RemoteException;
}


UidGeneratorHome.java
#
package org.shiftctrl.uid.persistence;

import java.rmi.RemoteException;

import javax.ejb.CreateException;
import javax.ejb.FinderException;
import javax.ejb.EJBHome;

import javax.naming.NamingException;


/**
 * The home interface of the UidGenerator EJB.
 */
public interface UidGeneratorHome extends EJBHome {

public UidGenerator create(String id)
throws RemoteException, NamingException, CreateException;

public UidGenerator findByPrimaryKey(String id) 
throws RemoteException, FinderException;

}


UidGeneratorEJB.java

package org.shiftctrl.uid.persistence;

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

import javax.ejb.EntityBean;
import javax.ejb.EntityContext;
import javax.ejb.EJBException;
import javax.ejb.CreateException;
import javax.ejb.FinderException;
import javax.ejb.ObjectNotFoundException;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.sql.DataSource;

import org.shiftctrl.framework.util.JndiNames;


/**
 * A unique id generator implementing 
 * a
href=http://www.sdmagazine.com/articles/1999/9912/9912p/9912p.htm;
 * high-low algorithm/a using BMP on relational database.
 * p
 * The required database structure:br
 * CREATE TABLE uids (id VARCHAR PRIMARY KEY, high LONGINT);
 *
 * p
 * The usage:
 * pre
 *
 * UidGenerator uidGenerator = null;
 * try {
 * uidGenerator = uidGeneratorHome.findByPrimaryKey(Generator
name);
 * } catch (FinderException fe) {
 * try {
 * System.out.println(No existing UidGenerator \Generator
name\, let's create a one);
 * uidGeneratorHome.create(Generator name);
 * uidGenerator = uidGeneratorHome.findByPrimaryKey(Generator
name);
 *  } catch (Exception e) {
 *  throw new EJBException(e);
 *  }
 * }
 *
 * uidGenerator.getId();
 *
 * /pre
 *
 * @author Joni Suominen
 * @version $Revision: 1.2 $
 */
public class UidGeneratorEJB implements EntityBean {
/** 
 * An id for a generator.
 */
private String id;

/**
 * The high value which forms the most significant bits of id.
 */
private long high;
private static final int HIGH_LENGTH = 60; // 60 bits

/**
 * The low value which forms the least significant bits of id.
 */
private int low;
private static final int LOW_LENGTH = 4;   // 4 bits
private static final int LOW_MAX = 15;// 2^4 - 1

private EntityContext context;

/**
 * Creates an UidGenerator.
 *
 * @param id an id for UidGenerator
 */
public String ejbCreate(String id)
throws NamingException, CreateException {

this.id = id;
this.high = 1;
this.low = 0;

Connection con = null;
PreparedStatement pStmt = null;
try {
con = getConnection();
pStmt = con.prepareStatement(insert into uids (id, high)
values (?, ?));
pStmt.setString(1, this.id);
pStmt.setLong(2, this.high + 1);

pStmt.executeUpdate();
pStmt.close();
} catch (SQLException se) {
se.printStackTrace();
throw new EJBException(se);
} finally {
if (pStmt != null) {
try {
pStmt.close();

Re: Cocoon in Harmony with Orion?

2001-05-15 Thread theis . meggerle


It whas some time ago but this is what I remember:

Rename the xerses.jar to xersesold.jar (under orion)
Copy cocoons xerses.jar to the orion lib.
(I think that orion is now shipped with the new xerses.jar)

Unpack the cocoon.jar.
Change the cocoon.properties to this:
processor.xsp.logicsheet.context.java   =
file://localhost/orion/default-web-app/web-inf/lib/org/apache/cocoon/processor/xsp/library/java/context.xsl
processor.xsp.logicsheet.cookie.java=
file://localhost/orion/default-web-app/web-inf/lib/org/apache/cocoon/processor/xsp/library/java/cookie.xsl
processor.xsp.logicsheet.global.java=
file://localhost/orion/default-web-app/web-inf/lib/org/apache/cocoon/processor/xsp/library/java/global.xsl
processor.xsp.logicsheet.request.java   =
file://localhost/orion/default-web-app/web-inf/lib/org/apache/cocoon/processor/xsp/library/java/request.xsl
processor.xsp.logicsheet.response.java  =
file://localhost/orion/default-web-app/web-inf/lib/org/apache/cocoon/processor/xsp/library/java/response.xsl
processor.xsp.logicsheet.session.java   =
file://localhost/orion/default-web-app/web-inf/lib/org/apache/cocoon/processor/xsp/library/java/session.xsl
processor.xsp.logicsheet.sql.java   =
file://localhost/orion/default-web-app/web-inf/lib/org/apache/cocoon/processor/xsp/library/sql/sql.xsl
processor.xsp.logicsheet.esql.java  =
file://localhost/orion/default-web-app/web-inf/lib/org/apache/cocoon/processor/xsp/library/sql/esql.xsl
processor.xsp.logicsheet.fp.java=
file://localhost/orion/default-web-app/web-inf/lib/org/apache/cocoon/processor/xsp/library/fp/fp.xsl

A strange solution but it did work!
I hope I didn't forget something.

/Theis.

Re: Taglib bug?

2001-05-15 Thread Mikko Kurki-Suonio


On Mon, 14 May 2001, Joseph B. Ottinger wrote:

 As one who's done quite a bit with taglibs on Orion, I've never seen this
 kind of behavior at all. Ever. Any version. (Bugs with it, sure - but that
 was related to tag instantiation and not location.)
 
 More information? Samples?

Here's a snippet:

%@ taglib uri=fetcher prefix=ftcr %
%@ taglib uri=ext prefix=ext %
%@ taglib uri=common prefix=common %
%@ page language=java 
 import=org.apache.oro.text.regex.*,java.util.*,java.text.*
%
ftcr:page 
  blah blah

/ftcr:page

% String foo = newscontent; 

common:iterate id=match 
type=org.apache.oro.text.regex.MatchResult 
collection=%= foo %


Generates:

Error parsing JSP page /pec/open/testfetch.jsp line 43

No tag named 'iterate' found in tag-library
file:/home/maxxon/orion/applications/pec/pecportal/WEB-INF/lib/fetcher.jar

Tomcat handles the WAR just fine.

//Mikko

Servlets by name

2001-05-15 Thread Henrik Skafsgaard Larsen


Hi

Is it possible to configure Orion to serve the servlets
by name and not all servlets in the servlet directory?
So even if someone puts another servlet in Orion
cannot/will not run the servlet, but only those I have specified.

med venlig hilsen / kind regards
Henrik Skafsgaard Larsen

simple questions

2001-05-15 Thread Hasan


hi, i am new to j2ee.
i have developed a simple app (just for adding, deleting, and editing the
dbase) using ejb.
i used jbuilder and inprise.

can anyone explain it to me the steps to deploy it on orion?
what files ,where the files to edit ,etc??

btw, though this is orion-specific, any one can tell me how to deploy it on
tomcat too??

thanks

RE: simple questions

2001-05-15 Thread Kemp Randy-W18971


The steps for deploying on Orion are found in the Orion documentation 
(www.orionserver.com), supplemented by Orion support (www.orionsupport.com).  I 
suggest that you look at and implement the examples at www.jollem.com, regarding the 
Orion primer and Orion CMP primer.  As far as Tomcat goes, look at the examples in the 
documentation of an open source effort that uses Tomcat, such as Jboss (www.jboss.org) 
or Enhydra Enterprise (www.enhydra.org).  If you specifically want to use Tomcat and 
Orion, then a search through the Orion interest archives should address that 
connection, but I would personally use Resin (www.caucho.com) and Orion, and follow 
the EJB doc in Resin on how to connect the two. 

-Original Message-
From: Hasan [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 15, 2001 4:46 AM
To: Orion-Interest
Subject: simple questions


hi, i am new to j2ee.
i have developed a simple app (just for adding, deleting, and editing the
dbase) using ejb.
i used jbuilder and inprise.

can anyone explain it to me the steps to deploy it on orion?
what files ,where the files to edit ,etc??

btw, though this is orion-specific, any one can tell me how to deploy it on
tomcat too??

thanks

Re: CMP Primary Key and ejbCreate

2001-05-15 Thread Jeff Hubbach


Ben,

From page 169 of Oreilly's Enterprise JavaBeans 2nd Edition:

The ejbCreate() method returns void in EJB 1.0 and a null value of type
ShipPK for the bean's primary key in EJB 1.1. The end result is the same:
in both EJB 1.0 and EJB 1.1, the return value of the ejbCreate() method for
a container-managed beain is ignored. EJB 1.1 changed its return value from
void to the primary key type to facilitate subclassing; the change was made
so that it's easier for a bean-managed bean to extend a container-managed
bean.

In short, the method signature in EJB 1.0 was void ejbCreate(), while in
EJB 1.1 it's BeanPK ejbCreate().

Jeff.

Ben Christensen wrote:

 When I generate a CMP bean with a Primary Key Class, it compiles and
 packages fine as far as the java side is concerned, however, when it is
 deployed, it has an issue.

 According to page 69 of the J2EE developers guide (I checked to be sure
 I wasn't just talking about anything), it says that if the bean has
 Container Managed Persistence, then the ejbCreate method should return
 null... the container handles that along with ejbFindByPrimaryKey...

 So, I have left it as null, but am using a custom Primary Key class.
 When I try to deploy it, it says:

 Error compiling ... filename ... method public void ... ejbCreate()
 throws javax.ejb.CreateException, java.rmi.RemoteException doesn't
 return a ... PrimaryKey (the path to the primary key class)

 Then the deploy fails.

 In JBoss, just to see what it had to say, it at least will deploy it but
 still gives a warning saying:

 The return type of an ejbCreate(...) method must be the entity bean
 primary key type.

 From what I can tell in the documentation, these errors are wrong

 On a BMP bean, then yes I should have to return the Primary Key class
 type from the ejbCreate method, this is stated in the developers guide,
 but not for a CMP bean.

 In the 1.3 preview release of the developers guide, it states the same
 thing for BMP beans, however, it doesn't say anything about CMP -- it
 says TBD ... maybe To Be Discussed... like TBA, I don't know... but
 considering we're still using 1.2.1 standards, I'd like to know if I'm
 just completely wrong, or this issue has been overlooked in the
 orionserver (and jboss to some degree) deployment.

 If it has changed since earlier versions of EJB specs and I'm just not
 seeing it, I'd appreciate someone explaining it to me.

 I've run this through VisualAge Enterprise Edition 3.5 as well... it
 works fine with ejbCreate returning null on a CMP with a primary key
 class, and if I try to tell it to return the key type, then it flags
 warnings about it.

 I can fool it into thinking everything is alright by setting the
 ejbCreate to return the primary key, but is this the correct way of
 doing this considering what the specs say?

 Thanks in advance.

 --
 Ben Christensen
 Novisum Development Inc.
 www.novisum.com
 [EMAIL PROTECTED]
 780-909-4707

--
Jeff Hubbach
Internet Developer
New Media Designs, Inc.
www.nmd.com

Where does one download 1.4.8 [EXPIRED TRIAL LICENCE]

2001-05-15 Thread Sam


I looked at www.orionserver.com

Where does one download 1.4.8

2001-05-15 Thread Sam


I looked at www.orionserver.com

1 2 >

1 - 100 of 117 matches

Mail list logo