Re: EJB Example Needs Improvement

I agree 100%. The problem was when a rather foolish decision was made 
to move away from xdoclet in the first place. The sordid details are 
probably in the archives of this list from about a year ago or so (and 
yeah, I can't help but say that at the time, my prediction was that 
this is exactly what would happen).

That switch away from xdoclet resulted in all sorts of descriptors 
becoming invalid and out of sync with sources. I've just recently 
redone osworkflow, oscore, and propertyset to use xdoclet again so 
those 3 projects at least are easy to maintain and have descriptors 
that are hopefully no longer out of sync. I'm somewhat reluctant to fix 
osuser as there are a number of efforts underway to 
rewrite/rearchitect/redo it. I'll gladly ensure that the ejb providers 
work well in whatever new form osuser takes.

So sadly for now, you're stuck having to fix the osuser descriptors 
yourself so that they're not totally broken and are usable for you on 
jboss. If you do fix it though I'd appreciate it if you could submit 
patches so that they can be checked in so others don't hit upon the 
same problem.

On Tuesday, May 27, 2003, at 08:17 PM, Rod Macpherson wrote:

> Thanks to EJBDoclet the sample osworkflow has an EJB entity bean 
> option with JBoss 3.X support. This allows us to change the database 
> connection in one place (the deployment descriptor for the entity 
> beans) to connect to our own datasource. Unfortunately this does not 
> achieve the desired result because the embedded osuser has its own EJB 
> interface so no you have to change the datasource in two places and 
> the latter (osuser) it burried in the example EAR build.
>  
> OK, so you have to specify the datasouce twice, no big deal. The 
> problem is there is no JBoss 3.X descritor for osuser. They do not 
> build using EJBDoclet but rather provide hard-coded JAWS descriptors 
> for an older version of JBoss. To add to the confusion there are two 
> tables created in the sample osworkflow SQL scripts called OS_USER and 
> OS_GROUP but that is NOT what the descriptors in osuser look for; they 
> look for OSUSER and OSGROUP. Moreover, why does the osworkflow example 
> have table creates for osuser stuff?
>  
> This whole datasource issue could be resolved by allowing it to be 
> specified as part of the EJBDoclet task in BOTH osuser AND osworkflow 
> and perhaps building both osuser and osworkflow together. What about 
> the property stuff? Probably the same issue there. As long as you are 
> using in-memory (not a useful option for us) you are fine but there 
> seems to be a lack of coordination between the components when trying 
> to sync them all up to the same datasource. The README-JBoss-3.txt 
> tried to remedy this problem but now that document is useless because 
> they ask you to update files that do not even exist anymore:
>  
> Setting up the OSWorkflow example
> ----------------------------------------------------
> 1. Extract osworkflow..war to an empty directory..
> 2. In the file .../WEB_INF/classes/osuser.xml adapt all DataSource 
> lines to ...
>  
> WHAT? There is no such file.
>  
>  
>  
> Here is my question: can we not ditch osuser and use osworkflow 
> stand-alone? Barring that can we get an osuser build that uses 
> EJBDoclet and thereby generates up-to-date descriptors for whatever 
> platform? This would entail adding XDoclet tags to the osuser EJBs. I 
> will try this myself and perhaps we could check it in? It would really 
> be nice to specify the application server and datasource in ONE PLACE 
> and there is no reason why that could not be done.
>  
>  



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge