Re: deploying additional files
Of course, datasources.xml is the purvue of the J2EE Deployer role, not of the developers, but purity aside, not all Orion apps are delivered to sophisticated deployment environments with a full complement of skilled staff. I'm sure a lot of us have spent some time trying to pre-deploy things so that just tossing an .ear at Orion will do everything related to deployment. As far as datasources.xml is concerned, the only solution we could come up with that works is to make the deployment directory a subdirectory of the application directory. Something like this, in our server.xml, does the trick: application name=myapp path=../applications/myapp.ear deployment-directory=../applications/myapp/orion / datasources.xml winds up being unpacked directly into the deploment directory. P. Pontbriand Canlink Interactive Technologies Inc. - Original Message - From: Yves Bossel [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Thursday, May 17, 2001 9:53 AM Subject: deploying additional files Hello, I am trying to pack my application in as independently as possible of the deployment configuration (i.e. paths). data-sources.xml and principals.xml get packed into the application's META-INF. However, unlike orion-application.xml, data-sources.xml does not get copied into orion/application-deployments/my-app. Is there a deployment-path-independent way to pack such files and to specify in their location in the deployment descriptors ? Is there a way to get Orion deploy additional files in the META-INF (Orion seems to look first there for needed deployment files)? My goal is to have to modify the least possible number of configuration files at deployment. Thanks Yves Bossel L. Programmer www.neoris.com - Business Technology Partners Edificio Birmann 24, Sanchez Fontecilla 310, piso 7 (esq. Callao) Las Condes, Santiago; CHILE oficina: (56-2) 426-1260 email: [EMAIL PROTECTED]
Re: custom finder in CMPs
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. P.Pontbriand Canlink Interactive Technologies, Inc. - Original Message - From: Armin Michel [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Friday, May 04, 2001 4:31 AM Subject: custom finder in CMPs Hi. I want to add additional code to the finder-methods (for further restrictions on the find-results based upon security information). How can I achive this? I'd like to extend those auto-generated finder-methods and don't want to fall back to BMPs. Hope someone can help. Armin Michel
Re: deployment.cache and wrapper classes
I've been in the same boat. The deployment.cache file is not particularly interesting, since it doesn't contain the source. When creating the wrappers, Orion generates the source and compiles it in the root of the Orion installation. When done compiling, it places the class files in the "zip-file-ish" deployment.cache, and deletes everything it generated from the root of the Orion installation. Removing the filesystem delete permission from the root of the Orion installation means the source files stick around, so adding them to the path of your debugger is then a possibility. Of, course, they're not compiled with debugging info, so you can't get fancy with watches and the like, but you _can_ step through the code, actually seeing what's going on - and spot any bugs in Orion's code generation. ;) P. Pontbriand Canlink Interactive Technologies, Inc. - Original Message - From: "Adam Cassar" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Thursday, April 19, 2001 10:34 PM Subject: deployment.cache and wrapper classes Hey guys, I desperately need to have a look what's going on inside of orion's wrapper classes. How can I access them? Previously on the list it is mentioned that they are in the deployment.cache file, however when I attempt to unjar that file, I only get one or two classes, not the entire lot. Any idea on how to debug these wrappers? They are constantly producing Stack Overflow exceptions and it would be nice to see what is happening. -- 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: Collection Finders With Entity Argument Always Return Empty Collection
Your second suggestion's on the money. Although the primkey-mapping block for CatalogEJB used our standard listing of identity first and then locale, the orion-ejb-jar.xml had locale first and then identity in the cmp-field-mapping for CatalogEntryEJB's Catalog field. Reversing this causes the generated finder code to correctly insert the SQL parameters. Its too bad that the orion-ejb-jar.xml was not generated correctly the first time, but manually ensuring that the order of the primary key fields matches throughout the deployment descriptors does seem to resolve the problem. P.Pontbriand Canlink Interactive Technologies Inc. - Original Message - From: "Jeff Schnitzer" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Tuesday, April 03, 2001 7:32 PM Subject: RE: Collection Finders With Entity Argument Always Return Empty Collection 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.
Re: Collection Finders With Entity Argument Always Return Empty Collection
Whoops. I jumped the gun. There is no difference observed regardless of the order in which the primary key fields are listed in the orion-ejb-jar.xml contained in the EAR. In fact, when Orion generates the full orion-ejb-jar.xml it ignores the order in the provided orion-ejb-jar.xml, and imposes its own ordering. The original problem remains. Our ugly workaround is to eliminate the Catalog field in CatalogEntry and instead have a field for each of the composite PK fields of Catalog. This way, they can be specified individually in the finder queries, preventing Orion from screwing up the order of insertion in the finder code. P.Pontbriand Canlink Interactive Technologies Inc. - Original Message - From: "Peter Pontbriand" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Wednesday, April 04, 2001 10:56 AM Subject: Re: Collection Finders With Entity Argument Always Return Empty Collection Your second suggestion's on the money. Although the primkey-mapping block for CatalogEJB used our standard listing of identity first and then locale, the orion-ejb-jar.xml had locale first and then identity in the cmp-field-mapping for CatalogEntryEJB's Catalog field. Reversing this causes the generated finder code to correctly insert the SQL parameters. Its too bad that the orion-ejb-jar.xml was not generated correctly the first time, but manually ensuring that the order of the primary key fields matches throughout the deployment descriptors does seem to resolve the problem. P.Pontbriand Canlink Interactive Technologies Inc. - Original Message - From: "Jeff Schnitzer" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Tuesday, April 03, 2001 7:32 PM Subject: RE: Collection Finders With Entity Argument Always Return Empty Collection 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.
Re: Help me please domain was nul message is killing me here...
PS: Is this what it takes to get a question answered? Is there a different forum for paying customers? If I pay $1500, will I get my questions answered faster? One would assume so. Paying customers are prioritised in the support queue (from personal experience). Hani Interesting. As another paying customer, this hasn't been my experience. I'm ignored just as completely as non-paying customers. This ignoring includes formal messages to Orion's support email address as well. We're still in development, but purchased a license in the hope that something resembling support would be forthcoming. It was a misguided expenditure in that regard. P. Pontbriand Canlink Interactive Technologies Inc.
Re: Custom UserManager.
The DataSourceUserManager that is provided with Orion exhibits this same problem - the principals.xml must still contain the group declarations. We've created out own custom UserManager that uses our User and Group EJBs. This custom user manager will work fine for EJB and Web modules without anything in the principals.xml, but it fails miserably with Application Client modules. It is impossible to login with Application Clients no matter what's in the DB or in principals.xml. P. Pontbriand Canlink Interactive Technologies Inc. - Original Message - From: "Christian Billen" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Friday, March 16, 2001 2:17 AM Subject: RE: Custom UserManager. I don't know what type of User manager you made, but I had problems using EJBUserManager, I had to leave the principals.xml containing all my groups (not my users) and the link to it in orion-application.xml. I struggled for a while on this since it doesn't make sense as all my users are in the database. Maybe it is something related somehow and you could try it out? Christian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Gantz Sent: Thursday, March 15, 2001 11:40 PM To: Orion-Interest Subject: Custom UserManager. Server : Orion-1.4.5 I've created a custom UserManager and referenced it in application.xml, I've taken out the principal tags in all the other files. Here is my problem: my custom user manager loads up and the init method gets called but that's it. The server never calls getUser on my user manager. I'm very sure I'm missing something really silly and simple but I can't find it due to the complete lack of adequate documentation. Thanks in advance. Michael L. Gantz
Re: Custom UserManager.
Good point. However, our User and Group EJBs are exclusively CMP - we don't
get any DataSources outside of the constructor or inside it. We'll give the
delegate-to-parent-UserManager trick a shot, but I still think that such
things should be unnecessary. Why should the fact that a client is an
Application Client Module rather than a Web Module make any difference to
the way UserManager implementations work?
P. Pontbriand
Canlink Interactive Technologies Inc.
- Original Message -
From: [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Cc: "Orion-Interest" [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, March 16, 2001 11:51 AM
Subject: Re: Custom UserManager.
When using a custom user manager with an application, you must make sure
you are getting your DataSource references in the constructor.
This is extremely important. If you try to lookup the DataSource outside
of the constructor, you will have all sorts of problems. Do something
like this...
private DataSource ds;
public MyUserManager() {
...
try {
InitialContext context = new InitialContext();
ds = (DataSource) context.lookup("jdbc/OraclePooledDS");
}
catch (NamingException ne) {
ne.printStackTrace();
}
}
public Connection getConnection() throws SQLException {
return ds.getConnection();
}
James Birchfield
Ironmax
maximizing your construction equipment assets
5 Corporate Center
9960 Corporate Campus Drive,
Suite 2000
Louisville, KY 40223
"Peter Pontbriand"
peter.pontbriand@canlink.To:
Orion-Interest [EMAIL PROTECTED]
com cc:
Sent by: Subject: Re:
Custom UserManager.
owner-orion-interest@orion
server.com
03/16/01 10:14 AM
Please respond to
Orion-Interest
The DataSourceUserManager that is provided with Orion exhibits this same
problem - the principals.xml must still contain the group declarations.
We've created out own custom UserManager that uses our User and Group
EJBs.
This custom user manager will work fine for EJB and Web modules without
anything in the principals.xml, but it fails miserably with Application
Client modules. It is impossible to login with Application Clients no
matter
what's in the DB or in principals.xml.
P. Pontbriand
Canlink Interactive Technologies Inc.
- Original Message -
From: "Christian Billen" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Friday, March 16, 2001 2:17 AM
Subject: RE: Custom UserManager.
I don't know what type of User manager you made, but I had problems
using
EJBUserManager, I had to leave the principals.xml containing all my
groups
(not my users) and the link to it in orion-application.xml. I struggled
for
a while on this since it doesn't make sense as all my users are in the
database. Maybe it is something related somehow and you could try it
out?
Christian
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Michael
Gantz
Sent: Thursday, March 15, 2001 11:40 PM
To: Orion-Interest
Subject: Custom UserManager.
Server : Orion-1.4.5
I've created a custom UserManager and referenced it in
application.xml,
I've taken out the principal tags in all the other files. Here is my
problem: my custom user manager loads up and the init method gets
called
but that's it. The server never calls getUser on my user manager.
I'm
very sure I'm missing something really silly and simple but I can't
find
it due to the complete lack of adequate documentation.
Thanks in advance.
Michael L. Gantz
Re: Inconsistent EJB JNDI Locations
- Original Message -
From: "Valentijn Scholten" [EMAIL PROTECTED]
To: "Peter Pontbriand" [EMAIL PROTECTED]
Sent: Thursday, March 08, 2001 3:51 AM
Subject: RE: Inconsistent EJB JNDI Locations
what do you mean just the ejb-name?
So use "MyBean" instead of "java:comp/env/MyBean" ???
This doesn't work either for me!?
Yes, this is what works for us. Assuming that the Entity EJB is deployed
with ejb-nameMyBean/ejb-name and that the Session EJB's deployment
descriptor has an ejb-ref-nameejb/MyBean/ejb-ref-name, the home
interface for MyBean is supposed to be found with
'lookup("java:comp/env/ejb/MyBean")'. Unfortunately, this doesn't work, but
rather MyBean is found with 'lookup("MyBean")'.
If the second lookup doesn't work for you, I would suspect your deployment
descriptor(s). Do you have an ejb-ref element for the Entity EJB in your
Session EJB's session element? Have you tried using the Orion console to
see if your EJBs are both successfully deployed?
Do you have a complete example of a Session bean createing/looking op an
entity bean,
that works/should work on Orion?
Unfortunately, I don't have a handy example outside of our project code base
I could pass along without some major editing, which I simply don't have the
time to do. It sounds like you have the right idea already anyway. Keep at
it, its most likely a small ommission in your deployment descriptor as
mentioned above.
P. Pontbriand
Canlink Interactive Technologies Inc.
Re: relation between component
Hi Peter! As I'm not sure if you are on the mailing list (orion) and it was a while ago I posted my question, I send this question privately. I hope that this will not disturb you. Anyway, I succeeded in making relation between jars, but not between ears. As I understood it, by your reply, you have succeeded with this. I would be grateful if you could send me an example, the ejb-jar.xml, on this. Best regards /Theis Meggerle Sorry, we haven't created any CMRs between components in different applications. I seriously doubt whether this is possible. For one thing, both components participating in the relationship would have to be deployed into the same container for a relationship to be container-managed. It would be impossible to guarantee this if they were in two different J2EE applications. The real question is: Why would you feel the need to have a CMR between two components in different applications? I think your architecture could benefit from a re-assessment in this case. P. Pontbriand Canlink Interactive Technologies Inc.
Re: Relationships between components!
Hi everbody! I'm trying to create relationships between components, both within the same jar and outside to another jar. In the first alternative, i.e. within the same jar, I succeded in creating the relationship, but unfortunately orion maps this to a blob. I have been playing around with orion-ejb-jar.xml without any success. Have anyone succeded with this? In the second alternative, i.e. relationship to an outside jar, it does'nt find the class (java.lang.NoClassDefFoundError). Does orion support this kind of relationships. Regards /Theis. Yep, Orion supports this, but you have to make sure you use an ejb-entity-ref tag within the relationships element for every CMR component that is not defined in the same ejb-jar.xml as you're defining the relationships in. Took me a while to suss that one out myself. P.Pontbriand Canlink Interactive Technologies, Inc.
Re: Application Client Security
Arved - or anybody - have you found a solution to this problem? Our application uses DataSourceUserManager and accessing it from servlets works reasonable well so far. However, when accessing it from an application-client any credentials not declared in the principals.xml file are rejected. Even worse, when a datasource user is defined with the same login name, even credentials that are in principals.xml get rejected. How does one use applications-clients to access applications that use DataSourceUserManager? P. Pontbriand Canlink Interactive Technologies Inc. - Original Message - From: "Arved Sandstrom" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Wed, 13 Sep 2000 10:08:19 -0700 Subject: Application Client Security Hi, all I sort of asked about this before. Still haven't come up with a solution. A simple Yes or No as to feasibility would be helpful. In a nutshell, I switched over to a DataSourceUserManager plus the RoleManager. No real difficulty with EJB's, but using Orion API's for user management knocked an application-client out of the loop. No users, whether declared in the principals.xml or in the user database, are recognized anymore. I've tried all the obvious permutations, and am sort of at wits' end as to whether I can even use J2EE application clients once a user manager is in the picture. Any ideas? Arved Sandstrom
Re: Composite PK classes
We've been using composite primary key classes since the beginning of our J2EE project. Notably, a number of our Entity EJBs use a primary key composed of both an identity String and a Locale. Works perfectly for us. What's the problem you are having? P.Pontbriand Canlink Interactive Technologies Inc. - Original Message - From: "Jim Archer" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Cc: "Daniel Cardin" [EMAIL PROTECTED] Sent: Tuesday, January 23, 2001 3:53 PM Subject: Re: Composite PK classes Hi Daniel... I believe I have also been unable to make this work. Let me double check. I don't recall the exact problem I had but I think there is one. I'll check... Jim --On Tuesday, January 23, 2001 1:58 PM -0500 Daniel Cardin [EMAIL PROTECTED] wrote: Has anyone managed to build EJB 2.0 applications using Orion, CMP and composite primary keys using a PK class ? I believe I have followed all recommandations but can't seem to make it work. Cheers, Daniel
Re: Influencing the order that EJB jars are deployed
- Original Message - From: "Jennifer Grechuk" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Monday, January 22, 2001 4:08 PM Subject: Influencing the order that EJB jars are deployed Hello everyone, On friday I posted a question about the relationships between two ejb's. (it's at the bottom of this letter if you would like to read it). We have since determined that the problem we are having is in the order that Orion deploys the ejb-jars. Unfortunately we don't know of a way to influence this order, we have tried changing the order in orion-application.xml and application.xml with no luckIf anyone knows of a way to influence the order in which Orion deploys the ejb-jars, we would really love to hear it. Thanks very much. Jennifer Grechuk Canlink As a colleague of Jennifer's, let me clarify a little - at the heart of this problem in the fact that a Container-Managed Relationship was being declared between two Entity EJBs in _different_ jar files. Upon deployment, an exception indicating that the ejb in the other jar could not be found was thrown. It was noted that the jar in which this declaration is made was _always_ being deployed first, and it seemed that if Orion could be convinced to deploy the other jar first, the ejb might be found. Alas, no method of cajolling could be found that would influence the order in which Orion deployed an application's ejb jars whatsoever. However, this proved to be a proverbial red herring. In actual fact, the problem is not related to the order of jar deployment, but rather to the fact that a cross-jar Container-Managed Relationship needs to be handled slightly differently in the ejb-jar.xml. As per page 464 of the EJB 2.0 Draft, an ejb-entity-ref element needs to be specified within the relationships element for any entity beans from outside of the jar that will be participating in a relationship. Not indicated in the draft Spec but required by Orion are ejb-ref-name ejb-ref-type elements within the ejb-entity-ref element. One the deployment descriptor was modified accordingly, the desire to influence the order in which Orion deploys an application's jars vaporized along with Orion's inability to find the relationship participant. P. Pontbriand Canlink Interactive Technologies, Inc.
Re: Getting the home interface of another EJB from within an EJB
String homeName = "CustomerHome";
Context context = new InitialContext();
String interfaceName = "java:comp/env/ejb/" + homeName;
LogManager.log("Looking up " + interfaceName);
Object object;
try {
object = context.lookup(interfaceName);
}
catch(NameNotFoundException e) {
//Handle Orion bug
String orionInterfaceName = homeName;
LogManager.log("Because of Orion bug: Looking up " + orionInterfaceName);
object = context.lookup(orionInterfaceName);
}
ejbHome = (EJBHome) PortableRemoteObject.narrow(object, EJBHome.class);
At this point I get a second NameNotFoundException.
Is this what you do (with success) aswell?
It does in fact work for us. You may not have the EJB deployed properly.
Three suggestions:
1) Try the orionconsole GUI tool and see what it says about the beans that
are running in your app. It should indicate that "CustomerHome" is there
somewhere.
2) Throw together some code to display the contents of Orions JNDI tree.
This can be done in a simple java command-line program using the
RMIInitialContextFactory. Something like this might be enlightening:
NamingEnumeration ne = jndiContext.listBindings("");
System.out.println("Context bindings:");
System.out.println("-");
while (ne.hasMore())
{
NameClassPair binding = (NameClassPair)ne.next();
System.out.println(binding.toString());
}
System.out.println("-");
3) Post your deployment descriptor as well. Idiosyncracies aside, this
should give us some idea of where your CustomerHome _should_ be found.
Good luck.
P. Pontbriand
Canlink Interactive Technologies Inc.
Re: Getting the home interface of another EJB from within an EJB
but how do I get hold of the home interface of _another_ bean?
We've found that Orion exhibits an 'idiosyncracy' in this regard. It can't
seem to decide where to make the home interfaces available in the JNDI ENC.
As I understand it, using the following example EJB-REF in an EJB's
deployment descriptor should make a home interface available through the
described EJB's JNDI ENC:
ejb-ref
ejb-ref-nameejb/OrganizationEJB/ejb-ref-name
ejb-ref-typeEntity/ejb-ref-type
homecom.canlink.components.model.party.OrganizationHome/home
remotecom.canlink.components.model.party.Organization/remote
/ejb-ref
However, Orion (version 1.4.4 at least) seems to be uable to decide _where_
in the ENC to make this reference available. Again, as I understand it, the
reference should be found using lookup("java:comp/env/ejb/OrganizationEJB").
Unfortunately, we've found that in many cases the reference can only be
found using lookup("OrganizationEJB"). Being in the all-too-typical
situation of frantically trying to satisfy ridiculous deadline/resource
combinations, we haven't spent the time to try and discern a pattern to this
'idiosyncracy', intead prefering to implement a workaround wherein we try
_both_ lookups thusly:
try {
ref = jndiContext.lookup("java:comp/env/ejb/OrganizationEJB");
}catch(NamingException ne){
System.err.println("Failed to find Organization; attempting again using
non-standard mapping");
ref = jndiContext.lookup("OrganizationEJB");
}
If anyone knows (and cares to point out) that the 'idionsyncracy' is in our
understanding (or lack thereof) and not in Orion, please feel entirely free
to speak out.
P. Pontbriand
Canlink Interactive Technologies Inc.
Re: javax.naming.NameNotFoundException: agency not found
Does anybody know what could cause a javax.naming.NameNotFoundException:
my
bean name not found? I think my .xml files are fine, and I think this
used
to work!
We've got the same problem - it seems Orion 1.4.4 can't decide whether to
make EJB home interfaces available at "java:comp/env/ejb-name" or just
"ejb-name". We've replaced all our lookup code with something like this:
Object ref = null;
try{
ref = jndiContext.lookup("java:comp/env/ejb/WhateverEJB");
} catch(NamingException ne) {
System.err.println("Failed to find WhateverEJB attempting again
using non-standard mapping");
ref = jndiContext.lookup("WhateverEJB");
}
WhateverHome home = (WhateverHome)PortableRemoteObject.narrow(ref,
WhateverHome.class);
This at least lets the app function. Sometimes the first lookup works,
sometimes not. If and when we see a pattern that implies sort sort of reason
for this strange behaviour, I'll report it to the list.
P. Pontbriand
Canlink Interactive Technologies Inc.
Re: Inconsistent EJB JNDI Locations
We haven't been using any jndi.properties file. We've always gotten our
contexts from simply invoking the default constructor for
javax.naming.InitialContext.
Obviously some change in our code or DDs has caused Orion to change its
behaviour, but we have no idea what, and cannot waste any more time trying
to determine what.
Unless anyone has a better idea, I guess we'll have to catch the
NamingException thrown with jndiContext.lookup("java:comp/env/ejb/whatever")
and retry with jndiContext.lookup("whatever") everywhere we need a home
interface - and live without a working env-entry implementation - while
investigating other J2EE server offerings.
P.Pontbriand
Canlink Interactive Technologies Inc.
- Original Message -
From: "Tim Endres" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Wednesday, December 13, 2000 9:50 PM
Subject: Re: Inconsistent EJB JNDI Locations
Is it possible that your jndi.properties file has changed? From this
posting,
and the other posting regarding env-entry's, it sounds like your getting
an
InitialContext that is not correct. Could this happen if the factory
specified
in jndi.properties changed?
tim.
For quite some time, our Stateless Session EJBs have been finding the
home
interfaces for our Entity EJBs using "java:comp/env/ejb/whatever" in the
context lookup() invocation. Suddenly and for no apparent reason, we now
get
a "javax.naming.NameNotFoundException" exception when doing so. The
home
interfaces are now to be found only if we specify "whatever" in the
lookup()
invocation, without the "java:comp/env" prefix. I've been rooting around
for
an extremely long time now trying to ascertain exactly what it is that
we
might have done to cause this to happen without any luck. Our code has
not
changed in this regard, nor has the version of Orion we've been using
(1.4.4).
Any ideas as to what has happened?
P.Pontbriand
Canlink Interactive Technologies Inc.
Re: Servlet Context in 1.4.4
Strangely enough, context-param works fine in our Orion 1.4.4 installs, and the ejb-refs in our web.xml files can be properly found the the environment naming context "java:comp/env". Unfortunately, ejb-jar.xml env-entry doesn't, though. Nor are our ejb-jar.xml ejb-refs available in the environment naming context "java:comp/env", only in the root. P.Pontbriand Canlink Interactive Technologies Inc. - Original Message - From: "Roger Mosher" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Thursday, December 14, 2000 8:23 AM Subject: Servlet Context in 1.4.4 Hi all. I have several servlets which use the ServletContext getAttribute() method to get context-param values from my web.xml file. This stuff worked fine with version 1.3.8, but since upgrading to 1.4.4 I just get a null back instead of a useful string. init-param stuff still works fine but I have parameters which I don't want to redefine for each servlet. Has anyone else had this experience? Did I do something stupid or is it a new bug? I also had a problem with placing something into the HTTP Session object (Orion hung and I had to kill it... it didn't even respond to shutdown), but that bug disappeared as I was chasing it down... very disconcerting. Thanks -- %%% Roger Mosher eMail: [EMAIL PROTECTED] Center of Geographic Sciences phone: (902)825-5230 50 Elliott Roadfax: (902)825-6733 Lawrencetown, N.S. Canadaweb: http://www.cogs.nscc.ns.ca/ B0S 1M0 %%%
Re: Inconsistent EJB JNDI Locations
- Original Message - From: David Smith To: Orion-Interest Sent: Thursday, December 14, 2000 12:00 PM Subject: Re: Inconsistent EJB JNDI Locations How are you ejb-ref entries set up in your ejb-jar.xml? Here's a sample from one of our ejb-jar.xml files: session descriptionUse Case controller for producers/description display-nameProducerServicesComponent/display-name ejb-nameProducerServicesEJB/ejb-name homecom.canlink.components.services.ProducerServicesHome/home remotecom.canlink.components.services.ProducerServices/remote ejb-classcom.canlink.components.services.bean.ProducerServicesBean/ejb-cl ass session-typeStateless/session-type transaction-typeContainer/transaction-type env-entry env-entry-nameFoo/env-entry-name env-entry-typejava.lang.String/env-entry-type env-entry-valueBar/env-entry-value /env-entry ejb-ref ejb-ref-nameejb/OrganizationEJB/ejb-ref-name ejb-ref-typeEntity/ejb-ref-type homecom.canlink.components.model.party.OrganizationHome/home remotecom.canlink.components.model.party.Organization/remote ejb-linkOrganizationEJB/ejb-link /ejb-ref /session P. Pontbriand Canlink Interactive Technologies Inc.
Re: Inconsistent EJB JNDI Locations
The problem is with the default environment naming context used by EJBs
looking up other EJBs deployed in the same instance of Orion, not with
Application clients looking up EJBs remotely. This default environment
naming context is obtained by using the default (parameterless) constructor
for javax.naming.InitialContext.
The problem is limited to such contexts instantiated by an EJB - web module
servlets within the same EAR have no problem finding our Session beans
properly - (new
InitialContext()).lookup("java:comp/env/ejb/ProducerServicesEJB") works just
fine in this case. Only when a Session EJB implementation attempts to find
other (Entity) EJBs does the NamingException get thrown.
I might be worth noting that the ATM sample that comes with Orion does the
lookups within the default environment naming context correctly - and in an
identical fashion to the way our app does it. The ATM sample app executes
fine within the same Orion install as our troubled app. This suggests
something unusual about our app is causing Orion not to bind things properly
in its JNDI implementation, but I remain completely stumped as to what this
cause might be.
P. Pontbriand
Canlink Interactive Technologies Inc.
- Original Message -
From: "shlomo" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Thursday, December 14, 2000 12:54 PM
Subject: RE: Inconsistent EJB JNDI Locations
Hi ,
Instead of using jndi.properties try using a Hash table with your full IP
:
public static Context setJNDIEnv(String IP,String rmiType ,String user
,String pass,String j2eeName) throws javax.naming.NamingException
{
Hashtable env=new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.evermind.server.rmi.RMIInitialC
ontextFactory");
env.put(Context.PROVIDER_URL, rmiType+"://"+ IP + "/"+ j2eeName);
env.put(Context.SECURITY_PRINCIPAL, user);
env.put(Context.SECURITY_CREDENTIALS,pass);
return(new InitialContext(env) ) ;
}
:)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Peter Pontbriand
Sent: Thursday, December 14, 2000 5:58 PM
To: Orion-Interest
Subject: Re: Inconsistent EJB JNDI Locations
We haven't been using any jndi.properties file. We've always gotten our
contexts from simply invoking the default constructor for
javax.naming.InitialContext.
Obviously some change in our code or DDs has caused Orion to change its
behaviour, but we have no idea what, and cannot waste any more time trying
to determine what.
Unless anyone has a better idea, I guess we'll have to catch the
NamingException thrown with
jndiContext.lookup("java:comp/env/ejb/whatever")
and retry with jndiContext.lookup("whatever") everywhere we need a home
interface - and live without a working env-entry implementation - while
investigating other J2EE server offerings.
P.Pontbriand
Canlink Interactive Technologies Inc.
- Original Message -
From: "Tim Endres" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Wednesday, December 13, 2000 9:50 PM
Subject: Re: Inconsistent EJB JNDI Locations
Is it possible that your jndi.properties file has changed? From this
posting,
and the other posting regarding env-entry's, it sounds like your
getting
an
InitialContext that is not correct. Could this happen if the factory
specified
in jndi.properties changed?
tim.
For quite some time, our Stateless Session EJBs have been finding the
home
interfaces for our Entity EJBs using "java:comp/env/ejb/whatever" in
the
context lookup() invocation. Suddenly and for no apparent reason, we
now
get
a "javax.naming.NameNotFoundException" exception when doing so. The
home
interfaces are now to be found only if we specify "whatever" in the
lookup()
invocation, without the "java:comp/env" prefix. I've been rooting
around
for
an extremely long time now trying to ascertain exactly what it is that
we
might have done to cause this to happen without any luck. Our code has
not
changed in this regard, nor has the version of Orion we've been using
(1.4.4).
Any ideas as to what has happened?
P.Pontbriand
Canlink Interactive Technologies Inc.
Re: EJB2.0 Generated class uncompilable
- Original Message -
From: "Jeff Schnitzer" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Monday, December 11, 2000 4:57 PM
Subject: RE: EJB2.0 Generated class uncompilable
FYI, as a workaround, you can make bidirectional relationships work by
manually setting both sides of the relationship. Orion currently seems
to treat a bidirectional relationship as two unidirectional
relationships, so everything works as long as you update both sides.
Assuming hypothetical entities foo and bar, with a 1-M relationship
foo-bar, the method Foo.addBar can look like this:
void addBar(Bar bar) // on Foo
{
this.getBars().add(bar);
// TODO: Remove this code when bidir relationships work
try
{
bar.setFoo((Foo)ejbContext.getEJBObject());
}
catch (java.rmi.RemoteException ex)
{
throw new EJBException(ex);
}
}
Of course you get data duplication in the database, but it works :-)
Jeff Schnitzer
[EMAIL PROTECTED]
This makes sense. Lately, I've been thinking using an orion-ejb-jar.xml in
the EAR to map both set-mappings to the same table, setting
exclusive-write-access to false. You idea makes for a simpler change when
Orion does get bidir relationships working.
P. Pontbriand
Canlink Interactive Technologies Inc.
ENV-ENTRY Broken in orion 1.4.4?
Is there a problem with Orion 1.4.4's interpretation on the ejb-jar.xml env-entry tag? Nothing we put in such a tag is ever available in a Context lookup() call whether we prefix with "java:comp/env" or not. P. Pontbriand Canlink Interactive Technologies Inc.
Inconsistent EJB JNDI Locations
For quite some time, our Stateless Session EJBs have been finding the home interfaces for our Entity EJBs using "java:comp/env/ejb/whatever" in the context lookup() invocation. Suddenly and for no apparent reason, we now get a "javax.naming.NameNotFoundException" exception when doing so. The home interfaces are now to be found only if we specify "whatever" in the lookup() invocation, without the "java:comp/env" prefix. I've been rooting around for an extremely long time now trying to ascertain exactly what it is that we might have done to cause this to happen without any luck. Our code has not changed in this regard, nor has the version of Orion we've been using (1.4.4). Any ideas as to what has happened? P.Pontbriand Canlink Interactive Technologies Inc.
Re: EJB2.0 Generated class uncompilable
- Original Message -
From: "Tim Drury" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Friday, December 08, 2000 5:39 PM
Subject: RE: EJB2.0 Generated class uncompilable
Since your bean is called "Foo" I'm going to guess
that it is a trivial "Hello World" bean. Why don't
you post the bean code and the ejb-jar.xml (don't
attach/zip/etc - just dump it)?
-tim
Well, it is rather trivial at the moment. That makes the deployments errors
all the more frustrating, of course.
BTW, blowing away the entire deployment does _not_ eliminate the deploytment
problems - that was one of the first things we tried.
Here's the current state of the source:
Foo.java is:
-
/* Generated by Together */
package com.foo.components.foo.bean;
import javax.ejb.EntityBean;
import javax.ejb.EntityContext;
import java.rmi.RemoteException;
import javax.ejb.EJBException;
import javax.ejb.CreateException;
import java.sql.SQLException;
import javax.ejb.FinderException;
import java.util.Set;
import com.canlink.components.base.GUID;
import com.foo.components.foo.*;
public abstract class FooBean implements EntityBean, FooBusiness
{
private EntityContext ejbContext;
private transient boolean isModified = false;
public void setEntityContext(EntityContext context) throws
RemoteException, EJBException
{
ejbContext = context;
}
public void unsetEntityContext() throws RemoteException, EJBException
{
ejbContext = null;
}
public void ejbActivate() throws RemoteException, EJBException
{
}
public void ejbPassivate() throws RemoteException, EJBException
{
}
public void ejbRemove() throws RemoteException, EJBException
{
}
public void ejbStore() throws RemoteException, EJBException
{
isModified = false;
}
public void ejbLoad() throws RemoteException, EJBException
{
}
public EntityPK ejbCreate(Set bars)
throws
CreateException,
EJBException,
RemoteException,
SQLException
{
setIdentity(GUID.getNewGUID());
setBars(bars);
isModified = true;
return null;
}
public void ejbPostCreate(Set bars)
throws CreateException, EJBException, RemoteException, SQLException
{}
public boolean isModified()
{
return isModified;
}
abstract public Set getBars();
abstract protected void setBars(Set bars);
public FooValueObject get()
throws RemoteException
{
return new FooValueObject(
(EntityPK)ejbContext.getPrimaryKey(),
getBars());
}
public FooValueObject set(FooValueObject mutator)
throws RemoteException
{
setBars(mutator.getBars());
isModified = true;
return get();
}
abstract public long getIdentity();
abstract protected void setIdentity(long identity);
}
-
Bar.java is:
-
/* Generated by Together */
package com.foo.components.foo.bean;
import javax.ejb.EntityBean;
import javax.ejb.EntityContext;
import java.rmi.RemoteException;
import javax.ejb.EJBException;
import javax.ejb.CreateException;
import java.sql.SQLException;
import javax.ejb.FinderException;
import java.util.Set;
import com.canlink.components.base.GUID;
import com.foo.components.foo.*;
public abstract class BarBean implements BarBusiness, EntityBean
{
private EntityContext ejbContext;
private boolean isModified = false;
public void setEntityContext(EntityContext context) throws
RemoteException, EJBException
{
ejbContext = context;
}
public void unsetEntityContext() throws RemoteException, EJBException
{
ejbContext = null;
}
public void ejbActivate() throws RemoteException, EJBException
{
}
public void ejbPassivate() throws RemoteException, EJBException
{
}
public void ejbRemove() throws RemoteException, EJBException
{
}
public void ejbStore() throws RemoteException, EJBException
{
isModified = false;
}
public void ejbLoad() throws RemoteException, EJBException
{
}
public EntityPK ejbCreate(Set foos)
throws
CreateException,
EJBException,
RemoteException,
SQLException
{
setIdentity(GUID.getNewGUID());
isModified = true;
return null;
}
public void ejbPostCreate(Set foos)
throws CreateException, EJBException, RemoteException, SQLException
{}
public boolean isModified()
{
return isModified;
}
abstract public Set getFoos();
abstract protected void setFoos(Set foos);
public BarValueObject get()
throws RemoteException
{
return new BarValueObject(
(EntityPK)ejbContext.getPrimaryKey(),
getFoos());
}
public BarValueObject set(BarValueObject mutator)
Re: EJB2.0 Generated class uncompilable
EJB2.0 DTD _is_ specified in ejb-jar.xml ... ejb-jar.xml is: - ?xml version="1.0"? !DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_2_0.dtd" P.Pontbriand Canlink Interactive Technologies Inc.
EJB2.0 Generated class uncompilable
Hello All. We've just written our first pair of 2.0-spec EJBs and are experiencing some really strange problems deploying them. Orion 1.4.4 auto-generates the DB tables for these beans, but then spits out the following message for every CMP field in each EJB: ___ 6. public class FooBean_PersistenceManager22 extends com.foo.components.authorization.bean.FooBean implements ContainerManagedObject -- *** Error: The abstract method "void setBar(java.util.Set $1);", inherited from type "com/foo/components/authorization/bean/FooBean", is not implemented in the non-abstract class "FooBean_PersistenceManager22". Since the type "com/foo/components/authorization/bean/FooBean" was read from a class file, it is possible that it just needs to be recompiled because after having inherited method "void setBar(java.util.Set $1);" from an interface, the method was subsequently removed from that interface. Error compiling file:/C:/orion/applications/foo/admin-ejb.jar: Error in source ___ We're totally at a loss here. What's removing what from what interface? There's no indication in the message of what the problem is in the source. We've already spend an incredible amount of time trying to sort out extremely cryptic deployment error messages with 1.1 and now 2.0-spec CMP Entity EJBs. We're definitely beginning to wonder whether there is any point to CMP at all - it seems like we could have ported BMP Entity EJBs to quite a number of different DBs in the time its taken to try and deal with CMP problems like this. Anybody have any light to on this latest problem? P. Pontbriand Canlink Interactive Technologies Inc.
Re: JBuilder + Orion
- Original Message - And for what it's worth, setting up JProbe to run Orion is about as simple... Arved Sandstrom -Original Message- - Adding orion.jar and ejb.jar to the required libraries of the project properties 'paths' tab. - Setting the main class to 'com.evermind.server.ApplicationServer' and the VM parameters to '-Duser.dir=c:\orion' on the 'run' tab. Sven E. van 't Veer Unfortunately, when set up pretty much exactly as mentioned but in Together 4.1 (www.togethersoft.com), Orion chokes thusly: com.canlink.components.services.ProducerServicesException: catalog creation failed: Database error: File input/output error: ./database/defaultdb.properties; nested exception is: java.sql.SQLException: File input/output error: ./database/defaultdb.properties; --- nested com.evermind.server.rmi.OrionRemoteException: Database error: File input/output error: ./database/defaultdb.properties; nested exception is: java.sql.SQLException: File input/output error: ./database/defaultdb.properties at ProducerServices_StatelessSessionBeanWrapper3.createCatalog(ProducerServices _StatelessSessionBeanWrapper3.java:92) at com.canlink.catalog.CreateCatalogAction.perform(CreateCatalogAction.java:62) at org.apache.struts.action.ActionServlet.processActionInstance(ActionServlet.j ava:794) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:702) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:332) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at com.evermind.server.http.d3.so(JAX) at com.evermind.server.http.d3.sm(JAX) at com.evermind.server.http.ef.su(JAX) at com.evermind.server.http.ef.dn(JAX) at com.evermind.util.f.run(JAX) The '-Duser.dir=c:\orion' JVM argument is set correctly and the defaultdb.properties file is in the right place and perfectly usable to Orion when it is run outside of Together. Any ideas as to why this happens only when Orion is run within Together? P.Pontbriand Canlink Interactive Technologies
Re: Variable contained illegal space
Error compiling file:/C:/orion/applications/phlox/producer-ejb.jar: Variable contained illegal space Orion/1.2.9 initialized It seems that the cause of this error was defining a primkey-field in the deployment descriptor for a CMP bean with a custom primary key class. Dare I suggest that the "Variable contained illegal space" message is just a tad - well, cryptic? P. Pontbriand Canlink Interactive Technologies
Re: Error while compiling
I suspect that despite the erroneous deployment descriptor, the problem in this case is likely to be CMP fields and/or custom PK class properties not being declared public. P. Pontbriand Canlink Interactive Technologies - Original Message - From: "Lawrence Fry" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Saturday, September 23, 2000 6:34 PM Subject: RE: Error while compiling Claudio, I believe that the problem he is having is this unclosed comment. It makes this ejb-jar.xml not a well formed xml document...which is probably playing with the deployment's mind. Regards, Lawrence -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Claudio Miranda Sent: Saturday, September 23, 2000 9:17 AM To: Orion-Interest Subject: Re: Error while compiling You have a PK class, where you specify the fields (same name inside bean), that are the PK of your bean. If your prim-key-classcom.canlink.components.base.GUIDFactoryPK/prim-key-class have the fields (with same name of fields inside bean) of your bean, just remove the xml tag primkey-fieldname/primkey-field-- (wow whats is this end comment?) from your ejb-jar.xml Claudio Miranda Chris Evans wrote: Hey everybody, Has anybody got any ideas about why this won't work. It's really frustrating!!! G:\orionjava -jar orion.jar Auto-unpacking G:\3.0\rel\guid-factory.ear... done. Auto-unpacking G:\3.0\rel\guid-factory\guid-factory-web.war... done. Auto-deploying guid-factory (Assembly had been updated)... Auto-deploying guid-factory-ejb.jar (No previous deployment found)... Error compiling file:/G:/3.0/rel/guid- factory/guid-factory-ejb.jar: No direct database fields for primary key: bean GUID Factory Bean Orion/1.2.9 initialized Here's what my ejb-jar.xml file looks like ejb-jar description/description enterprise-beans entity descriptionThis bean implements a GUID factory/description display-nameGUID Factory Bean/display-name ejb-namecom.canlink.components.base.GUIDFactoryBean/ejb-name homecom.canlink.components.base.GUIDFactoryHome/home remotecom.canlink.components.base.GUIDFactory/remote ejb-classcom.canlink.components.base.GUIDFactoryBean/ejb-class persistence-typeContainer/persistence-type prim-key-classcom.canlink.components.base.GUIDFactoryPK/prim-key-class reentrantFalse/reentrant cmp-fieldfield-nameiFactory_ID/field-name/cmp-field cmp-fieldfield-namecity/field-name/cmp-field primkey-fieldname/primkey-field-- ^^ remove this tag, because the PK class already has the primkey-fields. /entity /enterprise-beans assembly-descriptor security-role descriptionUsers/description role-nameusers/role-name /security-role /assembly-descriptor /ejb-jar
Variable contained illegal space
Has anybody seen this error before: C:\orionjava -jar orion.jar Auto-deploying producer-ejb.jar (ejb-jar.xml had been touched since the previous deployment)... Error compiling file:/C:/orion/applications/phlox/producer-ejb.j ar: Variable contained illegal space Orion/1.2.9 initialized I've attached the ejb-jar.xml if it helps. There really doesn't seem to be anything wrong with the XML. We tried a hand-coded version and that which Together Control Center happily spits out. Both seem to be the same, both cause the problem. P. Pontbriand Canlink Interactive Technologies ?xml version="1.0"? !DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd' ejb-jar enterprise-beans entity descriptionXXX/description display-nameGUID_Factory_Component/display-name ejb-nameGUIDFactory/ejb-name homecom.canlink.components.base.GUIDFactoryHome/home remotecom.canlink.components.base.GUIDFactory/remote ejb-classcom.canlink.components.base.GUIDFactoryBean/ejb-class persistence-typeContainer/persistence-type prim-key-classcom.canlink.components.base.GUIDFactoryPK/prim-key-class reentrantFalse/reentrant cmp-field field-namefactoryID/field-name/cmp-field cmp-field field-namecurrentObjectID/field-name/cmp-field primkey-fieldfactoryID/primkey-field/entity session display-nameProducer_Services_Component/display-name ejb-nameProducerServices/ejb-name homecom.canlink.components.services.ProducerServicesHome/home remotecom.canlink.components.services.ProducerServices/remote ejb-classcom.canlink.components.services.ProducerServicesBean/ejb-class session-typeStateless/session-type transaction-typeContainer/transaction-type/session/enterprise-beans assembly-descriptor security-role descriptionUsers/description role-nameusers/role-name /security-role /assembly-descriptor/ejb-jar
