[jbosstools-dev] Re: [Fwd: Re: JBDS Beta with SOA-P]

Rob Stryker rob.stryker at redhat.com
Thu Jan 22 16:40:14 EST 2009


For WTP the API is pretty simple. Whenever a publish action is called it 
will perform the publish. Usually an incremental publish is called, 
either by a timer (every so often) or by request (user clicks the 
publish button).

The adopter (me, or wtp generic server) gets some delta objects and some 
code to know if the publish is meant to be a full publish or an 
incremental publish.  Most WTP adopters (generic server, or the jboss 
one that comes with wtp) ignore the "incremental" and do a full publish 
every time. Their publish method is via an ant-call, so any time you 
change a .txt or .xml or .xhtml file, it must repackage your entire app 
and then redeploy it.  This is very slow... especially since it's 
spawning an additional process + vm to do it.

My adapter takes the delta and coppies only those files which have 
changed. If the changed file is something like a .jsp or .xml file, I 
just copy those files. In fact, I copy any file that's changed, even a 
.class. The problem is that most app-servers do not recognize changed 
.class files deep inside a deployment. Most will recognize a changed 
.jsp or .xml file immediately (as touching a descriptor is a typical way 
to redeploy an app), but a changed .class file is typically ignored.  
This is not my fault at all. It's up to the app server to decide what 
file changes it wants to acknowledge and when.

I believe Seam gets around this by actively listening for changed .class 
files to redeploy them. I am unaware of any other frameworks we use 
doing this. Because of that, even though I faithfully copy changed 
.class files over to the server, the server simply ignores it. The user 
must do one of two things in the server's view to get the changed .class 
file to be recognized. He must either do a full-publish by 
right-clicking the module inside the server's view and selecting "full 
publish". This will delete whats there (undeploy) and put all new back, 
so the server recognizes it as one brand new app. Or, he can restart the 
module (for which I currently have no way to do it and so this isn't 
really an option. There is a JIRA opened for it though =D ).

However... even though the user must do a "full publish" to effect any 
changed .class files, my server adapter is *still* much faster than the 
one contributed by wtp. The reason is that I don't go and launch an 
external ant process to jar everythign up and copy it over.  Even using 
a full redeploy is typically much much much faster than the WTP adapters.

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.

- 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 at redhat.com>
>> To: John Graham <jgraham at redhat.com>, Max Rydahl Andersen
>> <max.andersen at 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 at redhat.com>
>>> Date:
>>> Thu, 08 Jan 2009 17:19:07 -0600
>>> To:
>>> se-private <se-private at jboss.com>, Randy Thomas 
>>> <althomas at redhat.com>, Tim Dalsing <tdalsing at redhat.com>, Babak 
>>> Mozaffari <bmozaffa at redhat.com>
>>>
>>> To:
>>> se-private <se-private at jboss.com>, Randy Thomas 
>>> <althomas at redhat.com>, Tim Dalsing <tdalsing at redhat.com>, Babak 
>>> Mozaffari <bmozaffa at redhat.com>
>>> CC:
>>> Burr Sutter <bsutter at 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 at redhat.com>
>>> Date:
>>> Thu, 08 Jan 2009 18:07:54 -0500
>>> To:
>>> Aaron Pestel <apestel at redhat.com>
>>>
>>> To:
>>> Aaron Pestel <apestel at redhat.com>
>>> CC:
>>> David Ward II <dward at redhat.com>, "jbride at redhat.com Bride" 
>>> <jbride at 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-team-formation-coordination-and-schedule 
>>>>
>>>>
>>>> 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 at redhat.com>
>>>>> Date:
>>>>> Thu, 08 Jan 2009 14:30:09 -0500
>>>>> To:
>>>>> Mark Little <mlittle at redhat.com>, Mark Proctor 
>>>>> <mproctor at redhat.com>, Kris Verlaenen <kverlaen at redhat.com>, Koen 
>>>>> Aers <kaers at redhat.com>, Burr Sutter <bsutter at redhat.com>, Leonard 
>>>>> Dimaggio <ldimaggi at redhat.com>, Kevin Conner <kconner at redhat.com>, 
>>>>> Jeffrey Delong <jdelong at redhat.com>, Garvin Dean 
>>>>> <garvin.dean at amentra.com>, Edgar A Silva <edgar.silva at redhat.com>, 
>>>>> Prakasha Aradhya <paradhya at redhat.com>, Max Andersen 
>>>>> <manderse at redhat.com>, Trevor Kirby <tkirby at redhat.com>
>>>>>
>>>>> To:
>>>>> Mark Little <mlittle at redhat.com>, Mark Proctor 
>>>>> <mproctor at redhat.com>, Kris Verlaenen <kverlaen at redhat.com>, Koen 
>>>>> Aers <kaers at redhat.com>, Burr Sutter <bsutter at redhat.com>, Leonard 
>>>>> Dimaggio <ldimaggi at redhat.com>, Kevin Conner <kconner at redhat.com>, 
>>>>> Jeffrey Delong <jdelong at redhat.com>, Garvin Dean 
>>>>> <garvin.dean at amentra.com>, Edgar A Silva <edgar.silva at redhat.com>, 
>>>>> Prakasha Aradhya <paradhya at redhat.com>, Max Andersen 
>>>>> <manderse at redhat.com>, Trevor Kirby <tkirby at 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/200812221144/ 
>>>>>>
>>>>>> 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 at 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
>>>>>>               
>>>>>           
>>
>>   
>




More information about the jbosstools-dev mailing list