RE: Orion Friendly E-Commerce Components
We've been developing a set of components for use in our parts procurement platform that we targeted for Orion. They include login, security, shopping cart, catalog, content (message boards, classifieds, articles), advertising, pricing, and fulfillment functions. All told there are 90+ EJB's and almost 350 JSP's in an MVC architecture that we've tried to group so they could be reused in other projects. Depending on your needs, we may be able to license them to you. Thanks, Michael A Third Senior Software Architect Parts.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of xbill Sent: Wednesday, July 25, 2001 8:49 PM To: Orion-Interest Subject: Orion Friendly E-Commerce Components Hi- I am looking for basic E-Commerce components that run well under Orion. I am looking for something like a light version weblogic's commerce suite- but just the basics- login, shopping cart, etc. Has anyone had any success with any third party packages - either packaged as EJBS or JSP/Servlets running under Orion? thanks, -bill
FW: String.trim() for CMP
Same for this one -Original Message- From: Michael A Third [mailto:[EMAIL PROTECTED]] Sent: Monday, July 16, 2001 4:39 PM To: Orion-Interest Subject: String.trim() for CMP We have been trimming our string values in the ejbLoad successfully (or so we thought) for several months. We've recently started having problems in a web-app where a transaction expires and I think the trim is the culprit. Does anyone know of an issue with changing values in the ejbLoad method? Michael
RE: debug jsp pages and where is the source
You
have to use the fully qualified class name, ie java.lang.String for this to
work.
Michael
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Wendell
NicholsSent: Thursday, June 14, 2001 10:59 AMTo:
Orion-InterestCc: [EMAIL PROTECTED]Subject: debug jsp pages
and where is the sourceWhen I access a jsp page which
uses a tag library I get an error:
500 Internal Server Error
Error parsing JSP page /ectsdemo/TagLibDemos/booklist.jsp line 15
Bean type 'String' not found
I suspect that this is a problem creating the java file
from the jsp page related to the tag extra info class... At any rate I
can't find the source or class files that Orion generates from jsp pages so
it's impossible to proceed. Does anyone know how to make Orion place
java and class files for jsp pages somewhere where they can be viewed and
debugged? I see jsp cache files which are probably some sort of java
archive internal to Orion, but these don't help me as I can't open them...
Incidentally the jsp line that produced the above error looks like:
The taglib entry for eCTSTaglet:
eCTSTaglet
com.Amdahl.eCTS20.ects2taglet
com.Amdahl.eCTS20.ects2tagletTEI
JSP
Run a named taglet.
name
true
resultString
false
userdata
false
Its TEI class :
public VariableInfo[] getVariableInfo(TagData data) {
return new VariableInfo []
{
new
VariableInfo("eCTSResult",
"String",
true,
VariableInfo.AT_BEGIN),
new
VariableInfo("EndMsg",
"String",
true,
VariableInfo.AT_BEGIN),
new
VariableInfo("ReturnMsg",
"String",
true,
VariableInfo.AT_BEGIN)
}; }
Any help would be appreciated..
Wendell Nichols Amdahl Software Ltd. and Fujitsu Apserv.
RE: MVC/XML Framework Comments please
We too tried to use a liteweight persistence layer (jrf) with a few extensions, and found that Orion CMP was just as fast at most things, and significantly faster at relationships. I originally felt we needed to switch because some of our beans used bidirectional relationships implemented as get methods wrapping a finder method. This led to a pretty hefty performance hit. When Orion supports EJB QL and n:m relationships (1.5.0?), I think that performance issue will be lessoned. Until then, we had to denormalize our db a little while still use CMP. While looking at the various MVC frameworks, we too couldn't find anything to meet our needs. Struts and webWork were significantly more difficult to learn, which conflicted with the idea of making JSP easier for web designers, IMHO. Freemarker looked good until I found you had to write an adapter for each bean you wanted to expose for their template engine. We ended up writing our own MVC framework because of the unique requirements of our ASP based project. About 50% finished, we have been very pleased with our choice of Orion and CMP. Michael Third Parts.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Friday, April 27, 2001 2:12 PM To: Orion-Interest Subject: RE: MVC/XML Framework Comments please Cheers for Cory! Ejb is THE way to do persistance. By using EJB's properly, we make use of all of Orion's resource handling capabilities...and these guy's at Orion are much better at this than I am. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Cory Updyke Sent: Friday, April 27, 2001 10:05 AM To: Orion-Interest Subject: RE: MVC/XML Framework Comments please This may be off topic a little, but I am a little disheartened to see so many people disregarding EJB when considering a internet application framework. If you disregard transactions (NotSupported), and follow a few simple patterns (see java.sun.com/j2ee) you basically are able to build a powerful resource engine, which also completely isolates your business logic from your presentation tier. Although, you may be able to argue (trust me, I have done it in the past) that a JavaBean hitting a database is the same thing as an EJB call, it is likely that you will be wrong. Unless you have a server in Denver, CO talking to a server in Australia (which very seldom happens) the amount of time saved by having your resources (instance pools, db pools, jndi references, rmi pools, whatever else you can dream up) cached in the EJB server (even with RMI overhead), will blow the time it takes to make a DB request away. If you question this, run some tests. I have attempted to beat EJB performance by using a small self contained library a million times, and have seldom succeeded. I would recommend, unless your project is exceptionally simple, that a simple EJB logic abstraction is a valid consideration for the project. Back to the conversation. All of the recommendations for the web tier I believe are good, and come from years of development headaches that I am sure everybody has experienced. In reference to the web tier, the question that comes to mind when following this thread, is what are the needs of the system that is to be built. On one hand maintence is very important, but on the other hand, every abstraction hits performance. On one hand abstraction of content using XML is one of the most flexible ways to develop an internet application framework, but on the other hand, does your login page really need to be represented as an XML entity. Furthermore, is an additional transformation layer (cached or not) really worth it in terms of maintanence, performance, etc. I guess my point is, I have never found a global approach to data/presentation abstraction which I wasn't required to violate for a specific case. In fact, I have usually found that when approaching (an attempting to select) an architecture I often think "this is too complex from my needs," only later to find that I needed most of what it had to offer and just didn't know it at the time (and had to build it myself in the long run). My issue with XML/XSL transformations is this: My theory for the presentation tier is to keep it as simple as possible. Occasionally, you find a designer who has every right to be a engineer, but designs because they enjoy it. This person will scoff(sp?) at the simplicity of XSL. Most of the time you will find designers who know HTML (PDF, etc.). Which concept is closer to HTML, XML/XSL or JSP? I think JSP. I also have found it easier to say "Do you see the green (or whatever color depending upon your IDE) colored text? Please don't delete that" than it is to teach someone the concept behind XSL. You can have a good hour conversation, hand them the JSP Syntax Reference document and say DESIGN good man. Anyway... enough talk... we use Struts and our own Model-2-Brew. Cory
RE: A Swedish Idea
I think everyone needs to cool down and realize that Joseph's comment was sarcastic. I realize the sarcasm may not be easy to pick up on if English isn't your native language, but we don't need to resort to personal attacks. Michael -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of William JonesSent: Wednesday, April 18, 2001 1:34 PMTo: Orion-InterestSubject: Re: A Swedish Idea Would some people please just grow up. If you don't want to use Orion then that is your decision. Vote with your feet and leave this group to those who have valid issues to discuss. (Oh and best of luck finding anything else that is as cheap and quick) Joseph: as for making racist allegations about the intellectual or programming ability of people based on their national origin, I urge you to consider the following: - Your country is governed by George W. Bush - I haven't seen your place of education, Tallahassee Community College, featuring in the honours list in the ACM International Programming Contest (c.f. http://acm.baylor.edu/past/default.htm) - Original Message - From: "Joseph B. Ottinger" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Wednesday, April 18, 2001 3:20 PM Subject: Re: A Swedish Idea > Personally, I'm becoming more and more convinced that not only is Sweden> full of lousy programmers, but they're all lousy in congruent ways just to> make the rest of the world's jobs harder.> > I say we all start using Bavarian products, if only because Bavarian names> seem to have a better vowel/consonant ratio.> > Say, Randy... what country are YOU from? (That's the leading indicator for> quality of code...)> > On Wed, Apr 18, 2001 at 08:49:24AM -0500, Kemp Randy-W18971 wrote:> > Now this may be a dumb idea, and I am just thinking up brainstorms to promote Orion, but it occurred to me that both Mysql and Orion are in Sweden. Now I don't know how big Sweden is, but perhaps a meeting between the two teams could find ways to mutually promote or bridge the two products. Just a thought. Speaking of Sweden, since Rickard O. from Jboss lives there, does anyone know of Magnus or Karl have meet him? In once sense, but Jboss and Orion are trying to make this EJB technology available to more people. > > -- > ---> Joseph B. Ottinger [EMAIL PROTECTED]> http://epesh.com/ IT Consultant
RE: A modification to ejbtags.jar
Since I had already modified the Iterate tag to support sliding windows, I went ahead and incorporated Rafael's sorting tag and enhanced it to support descending order. I've only attached the IterateTag.java and a sample tld if anyone would like to use it. Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rafael Alvarez Sent: Tuesday, March 06, 2001 9:42 AM To: Orion-Interest Subject: Re: A modification to ejbtags.jar Ok. that resolve it :) I made two mistakes: 1) This mail was intended for Karl, but I misclicked in my email manager. 2) The version I sent is not a working one. I just realized that I lost the last version in the last crash of our CVS... Mea culpa not having a backup. Anyway, here is the working version. I'm interested in performance metrics, since it uses reflection... -- Best regards, Rafaelmailto:[EMAIL PROTECTED] IterateTag.java iterate.tld
Has anyone written an EJBDoclet impl for Orion?
If not, I'm probably going to write one. Thanks, Michael
RE: Database schema type mappings
Correction: The last bullet should be: * The home interface must always include the findByPrimaryKey method, which is always a single-object finder. The method must declare the primary key class as the method argument. Michael -Original Message- From: Michael A Third [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 01, 2001 11:46 AM To: Orion-Interest Subject: RE: Database schema type mappings I went digging through the EJB 1.1 specification, and it doesn't specifically say you can't use primitive types, but it does say they primary key class needs to be serializable. I have created a number of EJB's using the primitive long as the primary key and have had no problems using them. So I went back and looked at the deployment descriptor (it was originally generated by EJBMaker) and noticed that they was "java.lang.Long". All of the EJB class files are using the primitive type. It appears that at least Orion maps them intelligently(if not according to spec). On closer examination of the EJB 2.0 spec, I found these statements. * The primary key type must be a legal Value Type in RMI-IIOP. (this includes long) * The container must be able to manipulate the primary key type of an entity bean. * Primary key (must be a class or type?) that maps to a single field in the entity bean class. * The (create) method must declare the primary key class as the method argument. According to this statements, the primary key class and the primary key type don't necessarily have to be the same. Orion does allow the create method to accept the primary key type as opposed to the class, which isn't according to spec. Thanks, Michael PS - After my response on Java primitive data-types, I should probably keep my mouth shut for a while :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer Sent: Thursday, March 01, 2001 6:12 AM To: Orion-Interest Subject: RE: Database schema type mappings It's at the bottom of page 159 of Richard Monson-Haefel's _Enterprise Java Beans, 2nd Ed_: "Although primary keys can be primitive wrappers (Integer, Double, Long, etc.), primary keys cannot be primitive types (int, double, long, etc.)" I wasn't able to locate an explicit statement in the spec in my quick scan, but the spec always refers to the primary key as the "primary key class" and the deployment descriptor element is "prim-key-class". This is further reinforced by the comments in the DTD. It makes sense, because EntityContext.getPrimaryKey() returns an Object. Thus all PKs *must* be Objects. About question #1: I doubt there is any explicit requirement in the spec that Integers be converted to ints in the database. In fact, the spec doesn't require a relational database; that's simply an implementation detail. Still, I doubt you will find *any* appservers which serialize Integer keys as blobs - although it would work, the performance penalty would be severe. Jeff >-Original Message- >From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]] >Sent: Thursday, March 01, 2001 1:22 AM >To: Orion-Interest >Subject: RE: Database schema type mappings > > >Thanks for the reply Jeff. Know I have two replies: One saying >primary keys >can be primitive types and one that says they can't. >I am really looking forward to hearing your arguments, gentlemen ;-) > >BTW, Jeff: Your answer to question number 1 - do you have that from the >specification, or... > >Randahl > >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff >Schnitzer >Sent: 1. marts 2001 02:52 >To: Orion-Interest >Subject: RE: Database schema type mappings > > >>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]] >> >>1. Why is Integers automatically converted to int by Orion - >>and is this a >>standard EJB convention? > >Yes. All the class representations of the primitive types should work >that way. > >>2. Would it be legal to have a primary key of the primitive type "int" >>instead of Integer? > >No. Primary keys must be Objects. This makes sense because >EntityContext.getPrimaryKey() returns an Object. > >Jeff > > >
RE: Database schema type mappings
I went digging through the EJB 1.1 specification, and it doesn't specifically say you can't use primitive types, but it does say they primary key class needs to be serializable. I have created a number of EJB's using the primitive long as the primary key and have had no problems using them. So I went back and looked at the deployment descriptor (it was originally generated by EJBMaker) and noticed that they was "java.lang.Long". All of the EJB class files are using the primitive type. It appears that at least Orion maps them intelligently(if not according to spec). On closer examination of the EJB 2.0 spec, I found these statements. * The primary key type must be a legal Value Type in RMI-IIOP. (this includes long) * The container must be able to manipulate the primary key type of an entity bean. * Primary key (must be a class or type?) that maps to a single field in the entity bean class. * The (create) method must declare the primary key class as the method argument. According to this statements, the primary key class and the primary key type don't necessarily have to be the same. Orion does allow the create method to accept the primary key type as opposed to the class, which isn't according to spec. Thanks, Michael PS - After my response on Java primitive data-types, I should probably keep my mouth shut for a while :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer Sent: Thursday, March 01, 2001 6:12 AM To: Orion-Interest Subject: RE: Database schema type mappings It's at the bottom of page 159 of Richard Monson-Haefel's _Enterprise Java Beans, 2nd Ed_: "Although primary keys can be primitive wrappers (Integer, Double, Long, etc.), primary keys cannot be primitive types (int, double, long, etc.)" I wasn't able to locate an explicit statement in the spec in my quick scan, but the spec always refers to the primary key as the "primary key class" and the deployment descriptor element is "prim-key-class". This is further reinforced by the comments in the DTD. It makes sense, because EntityContext.getPrimaryKey() returns an Object. Thus all PKs *must* be Objects. About question #1: I doubt there is any explicit requirement in the spec that Integers be converted to ints in the database. In fact, the spec doesn't require a relational database; that's simply an implementation detail. Still, I doubt you will find *any* appservers which serialize Integer keys as blobs - although it would work, the performance penalty would be severe. Jeff >-Original Message- >From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]] >Sent: Thursday, March 01, 2001 1:22 AM >To: Orion-Interest >Subject: RE: Database schema type mappings > > >Thanks for the reply Jeff. Know I have two replies: One saying >primary keys >can be primitive types and one that says they can't. >I am really looking forward to hearing your arguments, gentlemen ;-) > >BTW, Jeff: Your answer to question number 1 - do you have that from the >specification, or... > >Randahl > >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff >Schnitzer >Sent: 1. marts 2001 02:52 >To: Orion-Interest >Subject: RE: Database schema type mappings > > >>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]] >> >>1. Why is Integers automatically converted to int by Orion - >>and is this a >>standard EJB convention? > >Yes. All the class representations of the primitive types should work >that way. > >>2. Would it be legal to have a primary key of the primitive type "int" >>instead of Integer? > >No. Primary keys must be Objects. This makes sense because >EntityContext.getPrimaryKey() returns an Object. > >Jeff > > >
RE: Database schema type mappings
Randahl, We use the primitive long for all of our primary keys for a couple of reasons: * primary keys can't be null so there isn't a need for Long (or Integer) * long's are always 4 bytes no matter what the CPU (32bit vs 64bit), which is currently not a problem but could be when Itanium platforms come out. int's depend on the CPU's native integer type which happens to be 32bits on ix86 architectures. Michael Third Chief Software Architect parts.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Randahl Fink Isaksen Sent: Wednesday, February 28, 2001 10:02 AM To: Orion-Interest Subject: Database schema type mappings If you look at the database schema in "orion/config/database-schemas/hypersonic.xml" it looks as if it is mapping between the primitive java type "int" and the corresponding database type "int": . In my EJBs my primary keys and other attributes are of type Integer. Since there is no mapping for class Integer one could think that Integers would be mapped to VARBINARY. Luckily my integers are mapped to the database type "int", but this makes me ask two questions: 1. Why is Integers automatically converted to int by Orion - and is this a standard EJB convention? 2. Would it be legal to have a primary key of the primitive type "int" instead of Integer? Yours Randahl
RE: CMP 2.0 OR mapping problem
Sorry! I didn't intend to offend anyone.
I know the 2.0 spec is only in public draft, but I thought that CMP
relationships were pretty stable. Having n:m support would be great, but I
would settle for 1:n support right now.
Again, thanks for all your help.
Michael
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Magnus Rydin
Sent: Friday, February 23, 2001 9:49 AM
To: Orion-Interest
Subject: SV: CMP 2.0 OR mapping problem
Please remember that the EJB 2.0 spec is not yet released.
Although the Orion Team has always be known to be fast to implement early
specifications,
this is a costly arrangement as specifications change.
Personally I hope that EJB 2.0 relations will soon be fully implemented.
WR
> -Ursprungligt meddelande-
> Från: Michael A Third [mailto:[EMAIL PROTECTED]]
> Skickat: den 23 februari 2001 06:15
> Till: Orion-Interest
> Ämne: RE: CMP 2.0 OR mapping problem
>
>
>
> Thanks for the reply. We were already doing this, and I realized how
> repetitive it was and hoped that 1.4.7 could cut the time we
> spent doing
> this (we have a lot of these relationships). Does anyone
> have a guess as to
> when full EJB 2.0 support will be available?
>
> Thanks,
>
> Michael
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Jeff Schnitzer
> Sent: Thursday, February 22, 2001 8:18 PM
> To: Orion-Interest
> Subject: RE: CMP 2.0 OR mapping problem
>
>
> Bidirectional relationships do not yet work.
>
> There are two workarounds that have worked for me:
>
> Manually add (and remove!) both sides of the relationship. So your
> Marketplace.addStorefront() method would look like this:
>
> void addStorefront(Storefront front)
> {
> this.getStorefronts().add(front);
>
> front.setMarketplace((Marketplace)this.ejbContext.getEJBObject());
> }
>
> etc. Alternatively you can modify your
> Marketplace.getMarketplaceStorefronts() method so that instead of
> obtaining the storefronts from the internal collection it runs a
> findByMarketplace finder method on the StorefrontHome. Then you just
> need to make sure that the storefronts->marketplace reference is kept
> solid.
>
> Jeff
>
> >-Original Message-
> >From: Michael A Third [mailto:[EMAIL PROTECTED]]
> >Sent: Thursday, February 22, 2001 3:37 PM
> >To: Orion-Interest
> >Subject: CMP 2.0 OR mapping problem
> >
> >
> >I have been trying to get Orion to correctly map a non-dependant
> >bidirectional 1:N relationship using EJB 2.0. It tries to generate a
> >collection mapping that uses a third table to hold the
> >reference. I was
> >able to deploy it properly using a unidirectional relationship.
> >
> >Here is the relevant entries from ejb-jar.xml (edited for brevity):
> >
> >
> >com.trademotion.ejb.base.Marketplace
> >
> >marketplaceID
> >
> >name
> >
> >storefronts
> > marketplaceID
> >
> >
> >
> >com.trademotion.ejb.base.Storefront
> >
> >storefrontID
> >
> >name
> >
> >marketplace
> > storefrontID
> >
> >
> >
> >
> >
> >
> >Marketplace-Storefront
> >
> >
> >
> >marketplace-has-storefronts
> >
> > One
> >
> >
> >com.trademotion.ejb.base.Marketplace
> >
> >
> >
> >storefronts
> >
> >java.util.Collection
> >
> >
> >
> >
> >
> >storefront-belongsto-marketplace
> >
> > Many
> >
> >
> >
> >com.trademotion.ejb.base.Storefront
> >
> >
> >
> >marketplace
> >
> >com.trademotion.ejb.base.Marketplace
> >
> >
> >
> >
> >
> >
> >Here is the generated orion-ejb-jar.xml (again, edited):
> > >name="com.trademotion.ejb.base.Marketplace">
> >
RE: CMP 2.0 OR mapping problem
Thanks for the reply. We were already doing this, and I realized how
repetitive it was and hoped that 1.4.7 could cut the time we spent doing
this (we have a lot of these relationships). Does anyone have a guess as to
when full EJB 2.0 support will be available?
Thanks,
Michael
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer
Sent: Thursday, February 22, 2001 8:18 PM
To: Orion-Interest
Subject: RE: CMP 2.0 OR mapping problem
Bidirectional relationships do not yet work.
There are two workarounds that have worked for me:
Manually add (and remove!) both sides of the relationship. So your
Marketplace.addStorefront() method would look like this:
void addStorefront(Storefront front)
{
this.getStorefronts().add(front);
front.setMarketplace((Marketplace)this.ejbContext.getEJBObject());
}
etc. Alternatively you can modify your
Marketplace.getMarketplaceStorefronts() method so that instead of
obtaining the storefronts from the internal collection it runs a
findByMarketplace finder method on the StorefrontHome. Then you just
need to make sure that the storefronts->marketplace reference is kept
solid.
Jeff
>-Original Message-
>From: Michael A Third [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, February 22, 2001 3:37 PM
>To: Orion-Interest
>Subject: CMP 2.0 OR mapping problem
>
>
>I have been trying to get Orion to correctly map a non-dependant
>bidirectional 1:N relationship using EJB 2.0. It tries to generate a
>collection mapping that uses a third table to hold the
>reference. I was
>able to deploy it properly using a unidirectional relationship.
>
>Here is the relevant entries from ejb-jar.xml (edited for brevity):
>
>
>com.trademotion.ejb.base.Marketplace
>
>marketplaceID
>
>name
>
>storefronts
> marketplaceID
>
>
>
>com.trademotion.ejb.base.Storefront
>
>storefrontID
>
>name
>
>marketplace
> storefrontID
>
>
>
>
>
>
>Marketplace-Storefront
>
>
>
>marketplace-has-storefronts
>
> One
>
>
>com.trademotion.ejb.base.Marketplace
>
>
>
>storefronts
>
>java.util.Collection
>
>
>
>
>
>storefront-belongsto-marketplace
>
> Many
>
>
>
>com.trademotion.ejb.base.Storefront
>
>
>
>marketplace
>
>com.trademotion.ejb.base.Marketplace
>
>
>
>
>
>
>Here is the generated orion-ejb-jar.xml (again, edited):
> name="com.trademotion.ejb.base.Marketplace">
>
> name="marketplaceID" persistence-
> name="marketplaceID" />
>
>
>
>table="com_trademotion_ejb_base_Marketplace_storefronts">
>
>
>
>name="marketplaceID" />
>
> type="com.trademotion.ejb.base.Storefront">
>
>
>
>home="com.trademotion.ejb.base.Storefront">
>
> persistence-name="value"
>/>
>
>
>
>
>
>
>
>The Storefront side of relationship is generated correctly.
>From previous
>posts, Orion supports what I'm trying to do (btw, I'm using 1.4.7).
>
>Thanks,
>
>Michael A Third
>Parts.com
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of
>Robert Krueger
>Sent: Thursday, February 22, 2001 1:44 PM
>To: Orion-Interest
>Subject: RE: No influence on CMP 2.0 getter setter methods - a feature
>or abug?
>
>
>
>>
>>There seems to be some smart-ass named "Robert Krueger"
>>who thinks he knows all the answers :) :) :)
>
>I've heard of him. he must be a real pain in the ass ;).
>
>cheers,
>
>robert
>
>>Thanks Robert!
>>
>>-tim
>
>(-) Robert Krüger
>(-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH
>(-) Brüder-Knauß-Str. 79 - 64285 Darmstadt,
>(-) Tel: 06151 665401, Fax: 06151 665373
>(-) [EMAIL PROTECTED], www.signal7.de
>
>
>
CMP 2.0 OR mapping problem
I have been trying to get Orion to correctly map a non-dependant bidirectional 1:N relationship using EJB 2.0. It tries to generate a collection mapping that uses a third table to hold the reference. I was able to deploy it properly using a unidirectional relationship. Here is the relevant entries from ejb-jar.xml (edited for brevity): com.trademotion.ejb.base.Marketplace marketplaceID name storefronts marketplaceID com.trademotion.ejb.base.Storefront storefrontID name marketplace storefrontID Marketplace-Storefront marketplace-has-storefronts One com.trademotion.ejb.base.Marketplace storefronts java.util.Collection storefront-belongsto-marketplace Many com.trademotion.ejb.base.Storefront marketplace com.trademotion.ejb.base.Marketplace Here is the generated orion-ejb-jar.xml (again, edited): The Storefront side of relationship is generated correctly. From previous posts, Orion supports what I'm trying to do (btw, I'm using 1.4.7). Thanks, Michael A Third Parts.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Krueger Sent: Thursday, February 22, 2001 1:44 PM To: Orion-Interest Subject: RE: No influence on CMP 2.0 getter setter methods - a feature or abug? > >There seems to be some smart-ass named "Robert Krueger" >who thinks he knows all the answers :) :) :) I've heard of him. he must be a real pain in the ass ;). cheers, robert >Thanks Robert! > >-tim (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
Custom UserManager Problem
This message is being sent on the behalf of Ernie Phelps at parts.com since it keeps rejecting his mails:) -- I am having difficulties getting a custom user manager to work. Here are the steps I have taken: Implemented User (as TMUser) Implemented Group (as TMGroup) Extended AbstractUserManager (as TMUserManager) Added the following to orion-application.xml: Added the following to web.xml: Main /* /list.jsp sr_guest BASIC TM sr_guest Here is the result: 1. I start Orion. It calls TMUserManager Init. 2. I start the browser, direct it to my controller. It pops the basic authentication dialog. I enter username and password. TMUserManager.getUser is called. TMUser.authenticate is called and returns true. 3. The basic authentication dialog pops again. This happens 3 times then fails. Any idea what I am missing here? I feel I have missed something basic, but can't put my finger on it. TIA, - Ernie ---- Michael A Third Chief Software Architect Parts.com
