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

[Max Rydahl Andersen]

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