[jbosstools-dev] Re: [Soa-tools-list] Example of why consistent jar usage is important

[Denny Xu]

John Graham wrote:
>> How to change the order of classpaths ? Press F1 :)
>>     
>
> You might laugh, but in a previous life I dealt with a product team that
> was convinced users are not going to know about F1, and thus wanted big
> "Help" buttons added all over the product. ;)
>
>   
>> With respect to more specifically in ESB then sure, find a good spot
>> in the ESB docs and add it in.
>>     
>
> Yes, specifically about the jars we know are impacted: scout and juddi.
>
> Denny: Can you coordinate getting this information added to the JBDS ESB
> documentation? 
>   
OK, I will add the information to the JBDS documentation.

Denny
> -- John
>
> On Thu, 2009-02-19 at 16:48 +0100, Max Rydahl Andersen wrote:
>   
>> On 19-02-2009 16:47, John Graham wrote: 
>>     
>>>> That is something the user can fix then.
>>>>     
>>>>         
>>> Can we document this somewhere in the product?
>>>   
>>>       
>> How to change the order of classpaths ? Press F1 :)
>>
>> With respect to more specifically in ESB then sure, find a good spot
>> in the ESB docs and add it in.
>>
>> /max
>>     
>>> -- John
>>>
>>> On Thu, 2009-02-19 at 16:42 +0100, Max Rydahl Andersen wrote:
>>>   
>>>       
>>>> On 19-02-2009 07:54, Denny Xu wrote:
>>>>     
>>>>         
>>>>> John and Max, today ESB cp container has been being in front of AS cp 
>>>>> container on ESB project classpath, after you
>>>>> create a esb project, you can look at the .classpath file, the default 
>>>>> order is that the ESB cp container is in front of AS cp.
>>>>>
>>>>>       
>>>>>           
>>>> okey, sounds good...so what was the cause of the original error ?
>>>> Does it just work outside the box ?
>>>>     
>>>>         
>>>>> There might be a problem for a ESB client project, users might create 
>>>>> a Java project as ESB client project and then
>>>>> add ESB and AS library to the project with wrong order manually, so 
>>>>> the wrong scout.jar would be loaded.
>>>>>       
>>>>>           
>>>> That is something the user can fix then.
>>>> We can help by creating a "ESB client project" wizard (or facet?)
>>>>
>>>> /max
>>>>     
>>>>         
>>>>> Denny
>>>>>
>>>>> John Graham wrote:
>>>>>       
>>>>>           
>>>>>> Denny,
>>>>>>
>>>>>> Max and I discussed this, and for the time being (this release), we'd
>>>>>> just like to move the ESB cp container ahead of the AS cp container on
>>>>>> the project classpath. This will allow override libs in the ESB
>>>>>> classpath container to be loaded first.
>>>>>> Is this possible, and, if so, can you take care of this?
>>>>>>
>>>>>> -- John
>>>>>>
>>>>>> On Wed, 2009-02-18 at 21:56 +0800, Denny Xu wrote:
>>>>>>         
>>>>>>             
>>>>>>> Max Rydahl Andersen wrote:
>>>>>>>           
>>>>>>>               
>>>>>>>>>>> set up a development environment by
>>>>>>>>>>> a standalone ESB runtime and there is not a ESB specified 
>>>>>>>>>>> classpath container, how could he do?
>>>>>>>>>>>                   
>>>>>>>>>>>                       
>>>>>>>>>> Eh - how do you do if there is not an ESB in the runtime ? You 
>>>>>>>>>> would be in the same situation, right ?
>>>>>>>>>>                 
>>>>>>>>>>                     
>>>>>>>>> For current ESB project, there are two separate functions, the 
>>>>>>>>> first one
>>>>>>>>> is setting ESB runtime classpath for the project, and another is
>>>>>>>>> deployment. two functions have dependency on project target server
>>>>>>>>> runtime, but the two dependencies are different, Setting esb runtime
>>>>>>>>> classpath is just ensure that the project can
>>>>>>>>> compile against ESB.  if the project target runtime does not contain
>>>>>>>>> an ESB runtime, users can provide a predefined JBoss ESB runtime, 
>>>>>>>>> so users can write esb code at least, but if ESB project tight 
>>>>>>>>> couple with project target runtime server, users can do nothing 
>>>>>>>>> without setting target runtime correctly.
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>> I do not see how this requires a different ESB classpath container 
>>>>>>>> and especially since you would really
>>>>>>>> like to make sure that users compile against the same thing they 
>>>>>>>> deploy against.
>>>>>>>>             
>>>>>>>>                 
>>>>>>> Yes,  a reasonable logic should be that,  but users might deploy the 
>>>>>>> project to any server which runtime
>>>>>>> supports the project facet, as far as I know, wtp deployment does 
>>>>>>> not have limitation that the project only can be deployed
>>>>>>> to the project's target server,  that means the project target 
>>>>>>> server runtime has nothing to do with the deployment,
>>>>>>> so it maybe hard to ensure that users compile  against the same 
>>>>>>> thing they deploy against.
>>>>>>>
>>>>>>>           
>>>>>>>               
>>>>>>>> In what situations today is an ESB project useful without having a 
>>>>>>>> targeted runtime ?
>>>>>>>>             
>>>>>>>>                 
>>>>>>> Users can select a predefined standalone ESB runtime, so they can 
>>>>>>> program and then deploy,
>>>>>>> not sure if it's the best logic,  maybe ask the server runtime pick 
>>>>>>> up jars is a good solution.
>>>>>>>
>>>>>>> Denny
>>>>>>>           
>>>>>>>               
>>>   
>>>       
>
>