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

[Max Rydahl Andersen]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20090219/79f276d8/attachment.html