Hani, you have misunderstood me. My problem is not that orion does not overwrite the deployment file. This is good. The problem is that orion on redeployment totaly ignores DDs, and starts from scratch. I had to look for a mile to see, why my MDBs are not subscribed on redeployment. Orion ignores both the xml in the jar and the xml in the deployment dir.
I also support the idea of NOT overwriting the current DDs. The "bug" I was talking about is long known from 1.4.8, and I hoped it to be solved, but it emerges from time to time, mainly (if not only) with MDBs. Lachezar > Wrong, this is not a bug, this is part of application assembly/deployment. > > The reason that orion does not wipe out the application-deployments files is > so that you can have different deployments of the same app in different > systems, with different table names perhaps or column names (just as an > example). > > For example, the list of disallowed fields is different across DB's, so if > you're using CMP, you might have a field called parent, which is sometimes > parent_ on some db's. Another example, you might have a db to which you do > not have exclusive write access, so in that particular deployment, you want > to turn off that flag. > > Orion makes this possible by not destroying deployment specific files every > time you deploy something new. This means you can deliver updates to your > application and each particular deployment need not worry about your > shipping default settings clobbering their customisations. Makes sense? > > The only caveat with this is that orion will NOT do merges between the > shipping and deployed file. So for example if you add a new bean, it's xml > fragment will not be picked up from your shipping orion-ejb.xml, since a > previous deployment already exists in application-deployments. In this case > you'd have to add in the bean manually to the deployed descriptor. Hope this > clears this issue up. > > So please think carefully before deciding to scream out bug, or at least ask > around! > > On 11/4/02 10:24 am, "Lachezar Dobrev" <[EMAIL PROTECTED]> wrote: > > > Maybe I don't get it. What is the problem. When you redeploy the ear it > > should get the new DDs. > > However, I WILL recommend to delete the deployment dir before > > (re)deployment. Orion has a nasty "bug", that ignores the DD in the > > jar/ear/war on redeployment. That is nasty. You should delete the directory > > of the jar/ear/war deployment, before (re)deploying. > > > > I will also recommend to leave the EAR structure, and use plain directory > > structure for your app. Use only ejb-jars. > > > > Again. If this is not your problem, elaborate more to solve it. I have had > > quite some experience since 1.4.5 and can help in most cases. > > > > Lachezar > > > >> o.k. it works! Thanks for comments! > >> > >> Now we have got another problem, since the orion-ejb-jar.xml is placed in > >> the corresponding jar-file, > >> orion detects an updated orion-ejb-jar.xml every time i deployd the > >> ear-file, wich contains theses jar-file. > >> In my opinion this happens because the generated orion-ejb-jar.xml unde > > the > >> orion deployment-directory is newer then > >> the orion-ejb-jar.xml-file contained in the corresponding > >> jar-file (because it would be used as a template or sample). > >> Even there are only changes in other jar-files, which contains > >> session-beans, orion detected an new orion-ejb-jar.xml > >> on every deployment. > >> How could i prevent orion from detection of an "new" orion-ejb-jar.xml? > >> > >> > >>> At 13:50 10.04.2002 +0200, you wrote: > >>>> Hi. > >>>> Yes. You may include an orion-ejb-jar.xml in the jar file. Orion > > wiull > >>>> read it on deployment, mix-in the missing values, and then use that xml. > >>>> Since orion 1.4.8 the orion-ejb-jar.xml should be in the META-INF > >>>> directory in the jar. Earlier versions had the deployment dd in another > >>>> directory. > >>>> > >>>> A different problem is sharing the xml, and automaticaly including it > > in > >>>> the builded jars. JBuilder has the ability to include custom-generated > > DDs > >>>> in the generated jar. this is good, and is very well used in conjuction > > with > >>>> a CVS system. Other building tools may have different way to do that. > >>>> > >>>> Lachezar. > >>>> > >>>>> Hi, > >>>>> > >>>>> thank you for the comment on my last posting "distibute beans in > > different > >>>>> jar"! > >>>>> > >>>>> Here is another question: > >>>>> > >>>>> We develop in a small team. One person create the entity-beans with > >>>> finder, > >>>>> interfaces , dd and so on.... > >>>>> If he creates an new finder, he has to create the where clause of the > >>>>> SQL-Statement in the orion-ejb-jar-xml-file. > >>>>> Every developer runs his own orion-server for development, becaus we > > won't > >>>>> test agains a common server, because of the frequence of changes in > > the > >>>>> development process in a team. > >>>>> Is it possible to include the generated an corrected > >>>> orion-ejb-jar-xml-file > >>>>> in the jar-file or the era-file, so that orion read it? > >>>>> Then the developer could create this file, commit it in CVS and the > > other > >>>>> developers could work with the new ejb.jar-file without copy an new > >>>>> orion-ejb-jar-xml-file in the deployment-directory. > >>>>> > >>>>> > >>>>> best regards > >>>>> > >>>>> Matthias Gottschlich > >>>>> > >>>> > >> ------------------------------------------------------------------------- - > >>>> -------------------------- > >>>>> mail: [EMAIL PROTECTED] > >>>>> tel: 030 343462 30 / fax: 030 343462 58 / mobil: 0178 7796466 > >>>> > >> ------------------------------------------------------------------------- - > >>>> -------------------------- > >>>>> > >>> > >>> mit freundlichen Grüssen > >>> > >>> Matthias Gottschlich > >>> > >> > >> ------------------------------------------------------------------------- -- > > ------------------------- > >>> mail: [EMAIL PROTECTED] > >>> tel: 030 343462 30 / fax: 030 343462 58 / mobil: 0178 7796466 > >> > >> ------------------------------------------------------------------------- -- > > ------------------------- > >> > > > > >
