I think what I would do here is have one big database project, containing
all the entity beans for the database together with session beans to
access them. I don't think having multiple CMP trying to access the same
table would be a good idea.
Every application would have a separate war file, containing the
interfaces needed to access the common database app.
Anyway this is more of a J2EE architectural design choice than actually
On Tue, 21 Oct 2003, Michael Harm wrote:
> Hi Eivind.
> Actually, maybe I've made this harder than it is. I guess I can stick
> everything into the same schema. But that doesn't by itself solve my
> problem. Here's concretely what I'd like to do.
> We have a set of tables that implement a medical vocabulary. Lots of
> applications use these tables. One is a clinical data repository. So
> it's a nice little project, with ant build script and everything, that
> one developer is working on. It gets deployed into jboss as a war and
> jar. It has tables that have foreign keys into the vocabulary tables.
> So we can use middlegen to generate an entity bean for, say,
> VocabularyTerm, Diagnosis, and a bunch of other things, where there's a
> CMR between Diagnosis.diagnosisCode and VocabularyTerm.termId. Grand.
> I could cram everything into the same schema, and explicitly list all
> my tables that this app uses using the <table> directive and end up
> with entity beans for VocabularyTerm, Diagnosis, and a couple others.
> Now, someone else is working on an app for a free clinic. They'd like
> to be able to deploy into jboss, using their own war and jar files,
> totally independent of the repository project. Different project,
> different source tree, different build.xml, everything. They've got
> tables of their own, like Patient, that have CMR relations into
> VocabularyTerm. Set the middlegen <table> directive to get entity
> beans for Patient, VocabularyTerm and a couple others. The
> VocabularyTerm guy is now common across both applications, and hence
> both war files.
> If this happens, will jboss freak out that two separate apps (the
> repository and the free clinic) both have beans for VocabularyTerm? Or
> will it figure out that it's the same thing? Or do I want there to be
> just *one* VocabularyTerm entity bean in jboss, and reference it from
> Diagnosis in the repository application, and Patient in the clinic app,
> maybe using xdoclet tags like @ejb.ejb-external-ref or some such?
> I'd like to avoid having one titanic project with a massive build.xml
> that deploys every single app we use into a single ear file, with a
> single massive ejb-jar.xml. If we have 10 applications deployed to our
> jboss server, I'd like each to be in its own war file, even if they all
> reference the (largely stable) VocabularyTerm bean.
> Sorry if I was unclear. My question isn't really about CMR across
> schemas I guess, as much as its about sharing Entity beans across apps.
> Yeah, I know that ejb is supposed to be *all about* sharing primitive
> things, I just don't know how to do it the *right* way. All my ejb
> projects up to now have been entirely self contained.
> I asked the xdoclet crowd about this too, as it may (or may not) be
> more of an ejbdoclet thing than a middlegen thing.
> Again, sorry for the novice questions. Any further hand-holding would
> be greatly appreciated.
> On Monday, October 20, 2003, at 11:01 PM, Eivind Waaler wrote:
> > Hi, sorry there seems to be no replies to your message.
> > Currently Middlegen does not support more than one schema..
> > Not sure I entirely understand your problem. You want to access the
> > entities from several WAR files? This should be no problem as long as
> > all
> > WAR files are placed in the same EAR as the ejb-jar file.. If you want
> > it
> > more split up, you'd have to use some remote session bean facade to
> > access
> > the entity beans since CMP should use local and not remote
> > interfaces. Using the VALUEOBJECT_REFACTORING_BRANCH from cvs will let
> > you
> > create such session bean facades..
> > If the problem is having a set of entity beans from different schemas,
> > Middlegen would have to be modified some to support this. I don't even
> > know if this is common practice in J2EE..
> > .eivind
> > On Sat, 18 Oct 2003, Michael Harm wrote:
> >> Hi.
> >> Sorry if this is a silly one.. I'm new to this.
> >> We have a set of tables that are sort of a shared resource to be used
> >> across multiple projects. It's in a schema called "vocabulary" (on
> >> oracle 9i).
> >> There are other projects that use these tables, with foreign key
> >> relationships into them. Those projects each are in their own schema.
> >> I'd like to be able to deploy these projects separately into jboss
> >> (3.2.1), each in their own WAR file, but preserving the CMR
> >> relationships to "vocabulary".
> >> But middlegen operates at the granularity of a single schema, as near
> >> as I can tell. So the CMR relationships don't happen. I can run
> >> middlegen twice for a given project, once on, say, "clinical_trials",
> >> and again on "vocabulary", but it doesn't kick out the right cmr
> >> stuff.
> >> ejbdoclet lets me add additional entity descriptors to the
> >> ejb-jar.xml, but doesn't seem to have a hook for additional
> >> <ejb-relation> thingies. And maybe it's a bad idea to have an
> >> entitity
> >> (say, a bean from the "vocabulary" schema) existing in multiple WAR
> >> files anyway.
> >> I've tried using oracle's synonyms, creating a synonym of
> >> vocabulary.concept as 'concept' visible in schema 'clinical_trials'
> >> with the fk relationship on that, but middlegen still doesn't see the
> >> 'concept' guy, even if its explicitly named in the <table> directives.
> >> I've also tried leaving off the 'schema' attribute to the middlegen
> >> task and coding the schema prefix in the <table> directives, but it
> >> doesn't see the tables with a schema prefix.
> >> What's the best practice for having a bean that is used across
> >> multiple
> >> projects? Keep everything in the same schema, and each project picks
> >> the stuff it needs using the middlegen <table> directive rather than
> >> scooping in everything? Is there a danger in having beans referencing
> >> a given table deployed to multiple WAR files? Or is jboss smart
> >> enough
> >> to figure this out?
> >> I'll get more concrete: in schema vocabulary, there's a table called
> >> CONCEPT with pk concept_id. In schema clinical_trials there's a table
> >> TRIAL, with a field trial_type_id. It's got a foreign key
> >> relationship
> >> to vocabulary.concept(concept_id). When I do a project relating to
> >> clinical_trials, I'd like to end up with cmr relationships, and be
> >> able
> >> to get to the concept bean. And there's another project in schema
> >> clinical_repository that has other tables with fk relationships into
> >> vocabulary.concept(concept_id), and I'd like those to be able to
> >> reference a concept bean as well.
> >> Any tips on the right way to architect this?
> >> (in this case, the stuff in the 'vocabulary' schema is all read-only.
> >> That may help with this particular case, and any info that would be
> >> great, but I'd also like to know about the more general case where the
> >> shared schema isn't readonly).
> >> Thanks!
> >> Michael Harm
> >> Stanford University School of Medicine
> >> -------------------------------------------------------
> >> This SF.net email sponsored by: Enterprise Linux Forum Conference &
> >> Expo
> >> The Event For Linux Datacenter Solutions & Strategies in The
> >> Enterprise
> >> Linux in the Boardroom; in the Front Office; & in the Server Room
> >> http://www.enterpriselinuxforum.com
> >> _______________________________________________
> >> middlegen-user mailing list
> >> middlegen-user@...
> >> https://lists.sourceforge.net/lists/listinfo/middlegen-user
> > -------------------------------------------------------
> > This SF.net email is sponsored by OSDN developer relations
> > Here's your chance to show off your extensive product knowledge
> > We want to know what you know. Tell us and you have a chance to win
> > $100
> > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> > _______________________________________________
> > middlegen-user mailing list
> > middlegen-user@...
> > https://lists.sourceforge.net/lists/listinfo/middlegen-user
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> middlegen-user mailing list