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

[Denny Xu]

On Tue, 2009-02-17 at 11:12 +0100, Max Rydahl Andersen wrote:
> >>
> >> The short term solution is to drop the ESB specific classpath 
> >> container IMO.
> >> And let the AS classpath container calculate which jars to return 
> >> dependent on which facets are installed.
> >>
> >> That will allow for dynamic calculation - I don't really understand 
> >> why it wasn't done like this in the beginning.
> >> Denny / Rob can you let us know ?
> > ESB project has two main functions
> > one is creating a ESB project for developing ESB by set up classpath 
> > and another is deploying ESB project,
> > ESB register itself to AS runtime, is just for deploying project using 
> > WTP deployment way.
> >
> > Let me explain why there is a ESB specified classpath container:
> > Firstly, AS server runtime can not ensure that it can provide a proper 
> > ESB runtime any time,
> > because not all JBoss Servers contain ESB runtime, if a user just want 
> > 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.


Denny


> 
> >
> > Currently, there are two options for creating  ESB classpath container,
> > 1. get ESB runtime jars from specified AS runtime
> > 2. get jars from a specified ESB runtime which predefined in 
> > preference page.
> > for now, AS classpath container is used as non-facet related 
> > classpath, I don't think it can pick up jars
> > for all project facet, there maybe JBossWS facet, it need JBossWS 
> > runtime, JBoss ESB facet need
> > ESB runtime, and  Seam facet Seam runtime,  AS classpath container 
> > almost don't know where the
> > location and structure of an new added runtime.
> Seam facet is not doable because Seam jar's are not part of the AS 
> runtime (it is "outside" and needs deploying inside the app),
> ESB and WS are all "inside" the AS runtime and AS could calculate these.
> 
> btw. I think all of this is more for jbosstools-dev than SOA tools since 
> it is not soa specific.
> > If AS classpath container can provide a extension point for new facet 
> > and runtime,  every new facet
> > just need extend the extension point by providing a jars calculation 
> > logic and AS runtime pick jars
> > from extensions.   that would be good.
> Yes - maybe runtime components can do this ?
> 
> /max
> >
> > Denny
> >
> >
> >>
> >> Nor do I understand how users is supposed to know which jars' to 
> >> compile/run against with the current platform
> >> setup we have ;)
> >>
> >> /max
> >>> I've been looking into this during the morning, and so far here is what
> >>> I've got:
> >>>
> >>> This appears to be a case of SOA-P using an AS capability that the
> >>> tooling has no easy way to accommodate at present. That is, SOA-P is
> >>> able to override certain libraries contained in AS by default for its
> >>> own use, and thus applications written for SOA-P (as opposed to just 
> >>> AS)
> >>> need to be configured accordingly. Now, we might wish that the world is
> >>> flat, but reality intrudes with much more complex demands. The simple
> >>> fact that there are library/classloader scope capabilities in AS that
> >>> are not readily supported by the current tools means that other more
> >>> complex enterprise applications could run into similar issues.
> >>> A potential solution (though not in this release of tools) is to 
> >>> provide
> >>> a Eclipse launch configuration that allows for classpath container
> >>> manipulation and perhaps makes some educated guesses ("if ESB and
> >>> duplicate jar between ESB and AS, remove AS jar from classpath" for
> >>> example) in the default settings. This would enable users to handle a
> >>> host of classpath configuration details when developing with AS, not
> >>> just for ESB.
> >>>
> >>> For the short term (this release), I think the only viable option is to
> >>> identify the known overlap and work-around it as best as possible. This
> >>> might include dropping known problematic jars from the classpath or
> >>> simply user documentation.
> >>>
> >>> -- John
> >>>
> >>> On Fri, 2009-02-13 at 15:22 +0000, Mark Little wrote:
> >>>> Hi Max. I'm not sure why this email is blank (at least I can't use
> >>>> it). Anyway, I've asked John to take a look at the problem from our
> >>>> side since I'm on vacation next week. I think we all know what we want
> >>>> to be able to do with tooling, so let's identify the issues and get
> >>>> them fixed. I don't believe this is an insurmountable issue.
> >>>>
> >>>>
> >>>> Mark.
> >>>>
> >>>>
> >>>>
> >>>> On 13 Feb 2009, at 14:46, Max Rydahl Andersen wrote:
> >>>>
> >>>>>
> >>>> ----
> >>>>
> >>>>
> >>>> Mark Little
> >>>> mlittle at redhat.com
> >>>>
> >>>>
> >>>> JBoss, a Division of Red Hat
> >>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
> >>>> Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in 
> >>>> UK and Wales under Company Registration No. 3798903 Directors: 
> >>>> Michael Cunningham (USA), Charlie Peters (USA), Matt
> >>>> Parsons (USA) and Brendan Lane (Ireland)
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Soa-tools-list mailing list
> >>>> Soa-tools-list at redhat.com
> >>>> https://www.redhat.com/mailman/listinfo/soa-tools-list
> >>>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> Soa-tools-list mailing list
> >> Soa-tools-list at redhat.com
> >> https://www.redhat.com/mailman/listinfo/soa-tools-list
> >
>