Maybe Max can have more info on the seam side and how / why they
listen for changed .class files. As far as I understand it, though,
this is a feature of the framework.
Your description is correct, except we got an
even faster way of
restarting/redeploy apps for those project types that supports it - The
Touch Icon! :)
The Touch Icon, touches (change the timestamp to now) the relevant
descriptor file (web.xml for war, application.xml for ear, esb.xml for
esb) which will result in Rob's excellent AS adaptor to copy the
descriptor which then will be discovered by the application server which
then will cause the redeploy - this of course assumes the server
supports this notion, but this is exactly what JBoss AS normally does
(unless you use something like the product configuration where they
disable reloading for performance reasons).
Thus must of the magic of redeploy is something that is implemented on
the server side when file changes (which means it is not dependent on a
specific tool which is a good thing); but in case of ESB they apparently
only react to changes to the descriptor - which is fair since reacting
to *everything* can also cause to many deployments.
Actually there are a lot of variations of hot deployment/redeployment so
let's just line them up to compare:
War:
General redeploy/restart of War is done by touching web.xml
Tomcat (embedded in JBoss) when configured for debug/devel should
listen to changes to .war\web-inf\classes, changes to web-inf\lib\*.jar
is afaik not picked up automatically. (need to verify)
*.html/*.xhtml is reread by Facelets if they changed (can be disabled
via some setting in facelets)
Special case is Seam App's - here web-inf/dev is a "magic" folder
monitored by Seam's classloader making it possible to redeploy Seam
components dynamically.
Ejb:
General redeploy/restart of War is done by touching ejb-jar.xml
No automatic redeploy afaik
Ear:
General redeploy/restart of War is done by touching application.xml
Esb:
General redeploy/restart of War is done by touching esb.xml
So why don't our deployer not just touch the descriptors everytime we do
a change ? Because it might be a big operation and just because I save a
.java files does not mean I want the app to do a full redeploy and as
you can see above not all files needs to touch the descriptors to get
re-read.
That is why we have the "Touch finger" for users to explicitly control
this. We do though some time help with this, i.e. when you use a Seam
wizard to create an new Entity - here the descriptors are touched after
the server finishes since JPA/Hibernate needs to restart to pick it up -
but this is ok, since we are doing it at the end of an ui-interaction
with the user via the wizard; doing it everytime users press Ctrl+S
would be to invasive IMO.
Going forward, I could though see us implement an option on
projects/deployed-resources to automatically touch the descriptors on a
change - but for now we got the above which I believe reaches a good
balance.
/max
- Rob.
Denny Xu wrote:
> Rob, could you please explain how the Publish works for wtp adaptors?
>
> Denny
>
> John Graham wrote:
>> More information about Aaron's question.
>>
>> -------- Forwarded Message --------
>> From: Aaron Pestel <apestel(a)redhat.com>
>> To: John Graham <jgraham(a)redhat.com>, Max Rydahl Andersen
>> <max.andersen(a)redhat.com>
>> Subject: Re: JBDS Beta with SOA-P
>> Date: Wed, 21 Jan 2009 16:09:27 -0600
>>
>> Also, if I change the ESB Java action, save, and republish, the
>> changes are not reflected in the SOA-P server. I actually have to
>> remove the project from the server and re-add it to the server to
>> get changes published.
>>
>> Using:
>>
>> Version: 2.0.0.CR1
>> Build id: R200812221144
>> Build date: 12/22/2008 11:54
>>
>> Thanks,
>>
>> Aaron Pestel
>> 214.395.1483 (cell)
>>
>>
>>
>> Aaron Pestel wrote:
>>
>>> John / Max,
>>>
>>> Testing time on CR1 is probably over, but just ran into something
>>> that we might want to look into.
>>>
>>> When I create a new ESB project and add a Java action to the
>>> project (which all works good), I can no longer deploy the ESB
>>> project to a SOA-P 4.3 environment. I think the reason is that the
>>> ESB Project defaults to a Java 6 facet, so it compiles the ESB
>>> class with Java 1.6 which won't deploy to SOA-P 4.3 because it
>>> requires Java 1.5. Maybe that's what we want because new versions
>>> (or FPs) of SOA-P may support Java 1.6, but for my environment I
>>> had to change the version of the Java facet in my ESB project from
>>> 6 to 5.
>>>
>>> Thanks,
>>>
>>> Aaron Pestel
>>> 214.395.1483 (cell)
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> Subject:
>>> [Fwd: Re: [Fwd: UPDATE: Assistance in testing JBDS with SOA-P]]
>>> From:
>>> Aaron Pestel <apestel(a)redhat.com>
>>> Date:
>>> Thu, 08 Jan 2009 17:19:07 -0600
>>> To:
>>> se-private <se-private(a)jboss.com>, Randy Thomas
>>> <althomas(a)redhat.com>, Tim Dalsing <tdalsing(a)redhat.com>, Babak
>>> Mozaffari <bmozaffa(a)redhat.com>
>>>
>>> To:
>>> se-private <se-private(a)jboss.com>, Randy Thomas
>>> <althomas(a)redhat.com>, Tim Dalsing <tdalsing(a)redhat.com>, Babak
>>> Mozaffari <bmozaffa(a)redhat.com>
>>> CC:
>>> Burr Sutter <bsutter(a)redhat.com>
>>>
>>>
>>> FYI - below.
>>>
>>> I'm planning to at least start using the new JBDS 2.0 beta they
>>> provide a link to below.
>>>
>>> Please note Burr's comment "all individuals need to communicate
>>> their participation interest back to John Graham" so you can get
>>> updated of progress, bugs found, and whatever else they notify of.
>>>
>>> Thanks,
>>>
>>> Aaron Pestel
>>> 214.395.1483 (cell)
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> Subject:
>>> Re: [Fwd: UPDATE: Assistance in testing JBDS with SOA-P]
>>> From:
>>> Burr Sutter <bsutter(a)redhat.com>
>>> Date:
>>> Thu, 08 Jan 2009 18:07:54 -0500
>>> To:
>>> Aaron Pestel <apestel(a)redhat.com>
>>>
>>> To:
>>> Aaron Pestel <apestel(a)redhat.com>
>>> CC:
>>> David Ward II <dward(a)redhat.com>, "jbride(a)redhat.com Bride"
>>> <jbride(a)redhat.com>
>>>
>>>
>>> This is a "community" effort. :-)
>>>
>>> Please forward.
>>>
>>> And all individuals need to communicate their participation
>>> interest back to John Graham.
>>>
>>> We are nearly out of time for this QA phase before the product ships.
>>>
>>> Aaron Pestel wrote:
>>>> Burr,
>>>>
>>>> Not really for me in a dedicated sense. I will download the
>>>> suggested version of JBDS beta and use that instead of the older
>>>> beta I use, so it will get some testing with SOA-P as I'm working
>>>> demos, examples, etc.
>>>>
>>>> I would suggest forwarding this to:
>>>>
>>>> JBDS SME Team: Jim Tyrrell
>>>>
>>>> SOA-P SME Team: David Ward, Jim Tyrrell, Uday Aarkoti, Randy
>>>> Thomas, Tim Dalsing, Aaron Pestel
>>>>
>>>> jBPM SME Team: Uday Aarkoti, Aaron Pestel, Jeff Bride, Babak
>>>> Mozaffari
>>>>
>>>> Rules SME Team: Ray Ploski David Ward, Blaine Mincey, Babak
>>>> Mozaffari, Randy Thomas
>>>>
>>>> Teams are all supposed to be creating demos, etc. and are defined
>>>> here:
>>>>
https://docspace.corp.redhat.com/clearspace/blogs/crunge/2009/01/05/sme-t...
>>>>
>>>>
>>>> Just a thought,
>>>>
>>>> Aaron Pestel
>>>> 214.395.1483 (cell)
>>>>
>>>>
>>>>
>>>> Burr Sutter wrote:
>>>>> Do any of you have time to review this?
>>>>>
>>>>>
------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> Subject:
>>>>> UPDATE: Assistance in testing JBDS with SOA-P
>>>>> From:
>>>>> John Graham <jgraham(a)redhat.com>
>>>>> Date:
>>>>> Thu, 08 Jan 2009 14:30:09 -0500
>>>>> To:
>>>>> Mark Little <mlittle(a)redhat.com>, Mark Proctor
>>>>> <mproctor(a)redhat.com>, Kris Verlaenen
<kverlaen(a)redhat.com>, Koen
>>>>> Aers <kaers(a)redhat.com>, Burr Sutter
<bsutter(a)redhat.com>,
>>>>> Leonard Dimaggio <ldimaggi(a)redhat.com>, Kevin Conner
>>>>> <kconner(a)redhat.com>, Jeffrey Delong
<jdelong(a)redhat.com>, Garvin
>>>>> Dean <garvin.dean(a)amentra.com>, Edgar A Silva
>>>>> <edgar.silva(a)redhat.com>, Prakasha Aradhya
<paradhya(a)redhat.com>,
>>>>> Max Andersen <manderse(a)redhat.com>, Trevor Kirby
<tkirby(a)redhat.com>
>>>>>
>>>>> To:
>>>>> Mark Little <mlittle(a)redhat.com>, Mark Proctor
>>>>> <mproctor(a)redhat.com>, Kris Verlaenen
<kverlaen(a)redhat.com>, Koen
>>>>> Aers <kaers(a)redhat.com>, Burr Sutter
<bsutter(a)redhat.com>,
>>>>> Leonard Dimaggio <ldimaggi(a)redhat.com>, Kevin Conner
>>>>> <kconner(a)redhat.com>, Jeffrey Delong
<jdelong(a)redhat.com>, Garvin
>>>>> Dean <garvin.dean(a)amentra.com>, Edgar A Silva
>>>>> <edgar.silva(a)redhat.com>, Prakasha Aradhya
<paradhya(a)redhat.com>,
>>>>> Max Andersen <manderse(a)redhat.com>, Trevor Kirby
<tkirby(a)redhat.com>
>>>>>
>>>>>
>>>>> Following up:
>>>>>
>>>>> 1. I should have prefaced the original message with "Please feel
>>>>> free to
>>>>> forward to anyone else (internal to RH/JB or under the appropriate
>>>>> agreements for this sort of internal information) who you might
>>>>> think
>>>>> would be interested in testing." If you do, please let me know,
>>>>> so I can
>>>>> add them into the list of people receiving these email updates.
>>>>>
>>>>> 2. Related to (1): Why not just use a mailing list like
>>>>> soa-tools? There
>>>>> are a couple of reasons: (a) There is no single list, or small
>>>>> set of
>>>>> lists, that covers everyone involved (and, no, I am not sending this
>>>>> request to thecore ;) ), (b) this is a short term, focused
>>>>> request, (c)
>>>>> list requests are like talking to a stadium of people, whereas this
>>>>> subset shows that I am talking to *you* :)
>>>>>
>>>>> 3. (Thanks, Len and Trev!) For the SOA-P download please use:
>>>>>
http://jawa05.englab.brq.redhat.com/released/soa-p-4.3.0.GA/
>>>>>
>>>>> 4. (Thanks, Max, Len, and Jeff!) Ignore the "all plug-ins"
zips
>>>>> for the
>>>>> tooling, and use the installer jar instead. You might find that your
>>>>> browser attempts to open this jar directly instead of downloading
>>>>> it, in
>>>>> which case you'll need to do a "save as" on the
installer jar. Once
>>>>> downloaded, from the command line issue "java -jar ...."
with the
>>>>> jar
>>>>> name to start the installer.
>>>>>
>>>>> 5. If you test but don't find any problems, still please drop an
>>>>> email
>>>>> to Max and I saying that you've tried. Since "no
response" does
>>>>> not mean
>>>>> "tried it and found no problems to report," these notes
will help
>>>>> Max
>>>>> and I determine the test coverage in place for this combination.
>>>>>
>>>>> 6. Particular importance of this JBDS release: This is the
>>>>> release that
>>>>> we'll take to EclipseCon in March, and we'd like to push it
hard,
>>>>> especially in the SOA area. We just need to be sure that what we
>>>>> push
>>>>> doesn't fall over. :)
>>>>>
>>>>> Thanks again!
>>>>> John
>>>>>
>>>>> On Wed, 2009-01-07 at 15:54 -0500, John Graham wrote:
>>>>>
>>>>>> As we reach the final stages of the JBoss Developer Studio
>>>>>> (JBDS) 2.0
>>>>>> release, we are seeking help in testing the JBDS/SOA-P
>>>>>> combination. In
>>>>>> particular, we're interested in how the jBPM and Drools
>>>>>> distributions
>>>>>> bundled in the SOA-P product work with JBDS.
>>>>>>
>>>>>> So, while testing and feedback at any stage is appreciated, the
>>>>>> critical
>>>>>> period for release will be over the next 10 days or so. Any
timely
>>>>>> feedback will help us to improve the tooling offered for this
>>>>>> product
>>>>>> configuration.
>>>>>>
>>>>>> The specific builds of each:
>>>>>>
>>>>>> * JBDS 2.0: Use
>>>>>>
http://reports.qa.atl.jboss.com/binaries/RHDS/release/2.0.0.CR1/200812221...
>>>>>>
>>>>>> via the installer. (EAP is optional.)
>>>>>>
>>>>>> * SOA-P: Use
>>>>>>
http://jawa05.englab.brq.redhat.com/candidate/soa-4.3.0.GA_IR5/
>>>>>> (SOA team: this is the link that was provided to JBDS QE a while
>>>>>> ago; if
>>>>>> a later build should be used, please let us know in this
thread.)
>>>>>>
>>>>>> If any questions come up during testing, it probably is best to
>>>>>> use the
>>>>>> jbosstools-dev(a)lists.jboss.org mailing list, since that will get
>>>>>> the
>>>>>> most people in the most time zones. (Of course there's always
>>>>>> JIRA for
>>>>>> bugs.)
>>>>>>
>>>>>> A number of people on thread have tested various milestones of
>>>>>> this JBDS
>>>>>> release, and the input has been very valuable. We hope each of
>>>>>> you can
>>>>>> spare a few cycles to help us wrap up testing for this product
>>>>>> combination.
>>>>>>
>>>>>> -- John
>>
>
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev