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

Max Rydahl Andersen max.andersen at redhat.com
Wed Feb 18 12:16:29 EST 2009


>>> 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.
afaik, the server needs to support your ESB facet to deploy it.
>
>>
>> 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.
>
Sure, I'm not saying to *remove* the ESB classpath container, but I'm 
saying that in the case of
the runtime is *embedded* inside the server runtime it would make sense 
that the server runtime
provides the classpath instead of the separate ESB classpath container.

But lets get back to seeing what we can do now.

We haven't heard why there are different .jar's yet but I guess the 
thing we can do know is to ensure that the ESB classpath container
gets added in front of the server runtime - that should solve this 
issue, right ?

/max




More information about the jbosstools-dev mailing list