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

[Denny Xu]

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 ?
The original error maybe caused by  the ESB client  example projects,  
it seems that ESB and AS cp container of the ESB client projects
have the wrong order,  I will update all ESB project and client project 
examples with the right classpath order.
>> 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?)
I don't think creating a "ESB client project" wizard or facet can solve 
this problem, since the ESB client can be any types of
project, such as java project, ESB project and sometimes it's might be a 
J2ee project,  all need to for ESB client is just adding
ESB classpath to the project, so I think we can just provide a popup 
menu "Set Up ESB Classpath" by pop up a wizard to select
all available ESB classpath container.

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