I have to agree - everyone is far to quick to yell about bug when this is
actually one of Orion's better features.

See this document for a full explanation of why Orion does what it does:

http://kb.atlassian.com/content/atlassian/howto/orionxml.jsp

Cheers,
Mike

Mike Cannon-Brookes
[EMAIL PROTECTED]

ATLASSIAN - Your J2EE Expert Partner
--------------------------------------------------------
> Brilliant Software - http://www.atlassian.com/software
> Legendary Services - http://www.atlassian.com/support

On 11/4/02 11:46 PM, "Hani Suleiman" ([EMAIL PROTECTED]) penned the
words:

> 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
>>> 
>>> ---------------------------------------------------------------------------
>> -------------------------
>>> 
>> 
>> 
> 
> 


Reply via email to