Ok Jim, I'd like start work on getting this Jetty based standalone
distribution going. Eventually I'd like a distribution which includes
things
like Jetty, Axis2/WS, rmi, json, groovy, javascript and spring. I'd also
like some pre-installed samples, maybe in addition to the bin, boot, and
extensions directories in the existing standalone distribution also have
an
applications directory to contain the samples and other applications. And
I
guess some bat/shell scripts to do startup etc.
Anyone else interested in helping with this?
...ant
On 8/19/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>
> I think it should basically work although we need to tidy up a few
> things. One thing is configuration. I'd like to be able to configure
> ports, ssl, etc. and the best way to probably do this is through
> SCA's use of include and XPath evaluation of external properties
> files. Basically, we would have a separate config file for standalone
> and in the Jetty SCDL do an include and have an XPath to the relevant
> Jetty data.
>
> If you want, since you are working on the ServletHost stuff, I can
> help trying to get standalone working with Jetty and Axis. Let me know.
>
> Jim
>
> On Aug 19, 2006, at 5:24 AM, ant elder wrote:
>
> > One of the good things about making it easy to create different
> > distributions is we can have distributions with or without pre-
> > installed
> > samples. There's obviously people who've found it useful to have them
> > pre-installed.
> >
> > I'd also really like a standalone distribution using Jetty, for one we
> > really need Jetty support to get references working well with the ajax
> > binding. Whats the status of the Jetty code in SVN?
> >
> > ...ant
> >
> > On 8/18/06, Jim Marino <[EMAIL PROTECTED]> wrote:
> >>
> >> I think there are a couple issues here which would benefit by
> >> stepping through what we expect users to actually be doing. From a
> >> user standpoint, I imagine most people will have the following goals:
> >>
> >> 1. Figure out how to write an SCA application
> >> 2. Figure out how to deploy the application
> >> 3. Run the application
> >>
> >> Starting with 3 in a server environment does not really do anything.
> >> For example, I start something up and hit a web page, but can't
> >> really debug or step through without setting a project up in my IDE.
> >> What I think most users want is a quick way (i.e 5 minutes) to do the
> >> following:
> >>
> >> 1. Download a sample that has an automated way to create a dev
> >> project
> >> 2. Build the sample and deploy it to whatever host environment I
> >> typically do my development with. For example, for web app
> >> development, I prefer Jetty since it is light, fast, and easily
> >> embedded. Others may prefer Resin, Websphere, WebLogic, etc. As I
> >> mention below, however, I don't think most Tuscany development will
> >> be done inside a web app.
> >> 3. Run the sample and debug it (either remotely or in my IDE) so I
> >> can see what is happening
> >> 4. Make changes to the sample and goto step 2
> >>
> >> The most time-consuming parts I have found in using new technologies
> >> is getting my dev environment setup properly. For example, with a
> >> binary distro, here is what I would have to go through:
> >>
> >> 1. Download the binary distro, including a pile of dependencies
> >> probably totaling over 200MB
> >> 2. Unzip the distro, follow the readme instructions to start the
> >> thing
> >> 3. Use a browser to hit a web page that prints something out
> >>
> >> At this point, I still can't really see what is going on much less do
> >> things like changing bindings, adding policy, swapping implementation
> >> types, etc. If I want to use really understand how SCA and Tuscany
> >> work, I would have to:
> >>
> >> 4. Download the source sample, maybe it is included in 1 but maybe
> >> not
> >> 5. Setup my dev environment with a sample project
> >> 6. Build the sample and package it
> >> 7. Figure out whether I want to deal with Tomcat the version of
> >> Tomcat my Tuscany download just came with. Probably not, since I
> >> already have a Tomcat install or use something else.
> >> 8. Make any necessary changes to my dev environment so I can debug
> >> the sample as it is run
> >> 9. Deploy the sample to the host I do my development with
> >>
> >> IMO what would be much simpler for end users would be to:
> >>
> >> 1. Download a sample distro
> >> 2. Build it with maven, which can generate the IDE project for me as
> >> well as deployment artifacts for whatever host type I choose, e.g. a
> >> WAR file
> >> 3. Set my IDE to use the source from the sample I just downloaded
> >> 4. Decide where I want to deploy it to. If it is a WAR, I just drop
> >> it in and either run it from within my IDE and debug or attach to a
> >> remote process
> >>
> >> I think it would be useful to look at projects that have been highly
> >> successful (i.e. one of the most widely used Java projects) and see
> >> how they do things, Spring and Hibernate. Both do not ship a pre-
> >> configured host environment.
> >>
> >> As a further thing to think about, I expect most SCA users will *not*
> >> be developing with or deploying to Tomcat and will probably instead
> >> use the standalone version. This is for a number of reasons:
> >>
> >> 1. The J2EE deployment model restricts some of the most important
> >> features implicit in SCA
> >> 2. Related to #1, most of the capabilities people really to want to
> >> see involve things like transactions and policy, dynamic re-wiring,
> >> etc. which are not directly supported in Tomcat. This will mean
> >> either having to configure Tomcat with a transaction manager or
> >> bundling one in the web application. Standalone can handle this
> >> dynamically. Consequently, I suspect the user experience will be more
> >> difficult on Tomcat. I also don't think most are going to be
> >> interested in "helloworld" variants as that can be done more easily
> >> with existing technologies.
> >> 3. With dependency injection, there is no need to develop within a
> >> container - just use mocks. When I build apps, I typically don't get
> >> them running in a host environment until integration testing.
> >>
> >> Jim
> >>
> >>
> >>
> >> On Aug 18, 2006, at 7:26 AM, Rick wrote:
> >>
> >> > +1 for both .. does that make 2? :-)
> >> > I like the idea of having the bar a low as possible for someone to
> >> > just start playing with samples to learn building SCA applications.
> >> > But I also see Jim's point. There are other set of users (IT
> >> > types) that may not even care about Tomcat and we definitely need
> >> > to please them too.
> >> > I think the trick here is to for the site documentation about what
> >> > download to to satisfy your particular interests is very important
> >> > and we make perfectly clear that Tuscany is not just a Tomcat/
> >> > webserver extension.
> >> > Luciano Resende wrote:
> >> >> +1 for what Jervis, Ant and Simon are saying... I really liked the
> >> >> pre-configured Tomcat installations available for the samples in
> >> >> M1, made
> >> >> my life much easier to get started in Tuscany. I have also
> >> >> recently created
> >> >> that for DAS samples and it's available today at samples/das/
> >> >> testing/tomcat
> >> >>
> >> >> - Luciano
> >> >>
> >> >> On 8/18/06, Simon Laws <[EMAIL PROTECTED]> wrote:
> >> >>>
> >> >>> On 8/18/06, ant elder <[EMAIL PROTECTED]> wrote:
> >> >>> >
> >> >>> > There are quite a few old threads where we've discussed
> >> >>> samples, here's
> >> >>> > just
> >> >>> > one of them:
> >> >>> >
> >> >>> >
> >> >>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/
> >> >>> 200604.mbox/%
> >> >>> [EMAIL PROTECTED]
> >> >>> >
> >> >>> > If we're moving towards multiple Tuscany distributions
> >> targeted at
> >> >>> > different
> >> >>> > areas then i think its fine (and even desirable) for one of
> >> those
> >> >>> > distributions to contain an entire host environment. One of the
> >> >>> good
> >> >>> > things
> >> >>> > about the M1 release was that it really did make it easy for
> >> >>> new users
> >> >>> to
> >> >>> > get started, just "unzip and click on startup".
> >> >>> >
> >> >>> > ...ant
> >> >>> >
> >> >>> > On 8/18/06, Jim Marino <[EMAIL PROTECTED]> wrote:
> >> >>> > >
> >> >>> > >
> >> >>> > > On Aug 17, 2006, at 11:21 PM, ant elder wrote:
> >> >>> > >
> >> >>> > > > I agree with Jervis, things just running out-of-box is much
> >> >>> nicer
> >> >>> > > > for first
> >> >>> > > > time users than having to fiddle about editing config
> >> files.
> >> >>> > > >
> >> >>> > > > Would an alternative be to change the structure of the
> >> >>> samples and
> >> >>> > > > move
> >> >>> > > > these technology specific samples into the extension that
> >> >>> they use.
> >> >>> > > > For
> >> >>> > > > example, something like having a javascript folder that
> >> >>> contained
> >> >>> > > > separate
> >> >>> > > > projects for the JavaScript container and each JavaScript
> >> >>> sample.
> >> >>> > > > There
> >> >>> > > > would still be lots of helloworld samples, but not all in
> >> >>> the one
> >> >>> > > > top level
> >> >>> > > > samples folder so wouldn't be quite so in your face.
> >> >>> > > I like the idea of moving the samples into the extensions
> >> >>> (except
> >> >>> > > maybe the samples that use multiple extensions) and actually
> >> >>> think it
> >> >>> > > could correspond to Jeremy's proposal. This would allow us to
> >> >>> > > compartmentalize things more which I think is going to be
> >> >>> fundamental
> >> >>> > > to scaling the project. I have several caveats for this
> >> though:
> >> >>> > >
> >> >>> > > - there is a clear distinction in the tree between the
> >> >>> samples and
> >> >>> > > runtime extension code. In other words, each sample project
> >> >>> should
> >> >>> > > not be a sibling to the project containing extension code but
> >> >>> should
> >> >>> > > go under a samples folder in separate projects
> >> >>> > > - the extensions are individually built from the core
> >> >>> projects and
> >> >>> > > fairly autonomous per my previous email
> >> >>> > > - samples are not built with the check-in build for
> >> >>> extensions and
> >> >>> > > are separately distributable
> >> >>> > >
> >> >>> > > In terms of end-user experience, I think things are going to
> >> >>> vary
> >> >>> > > greatly depending on the host environment. For example, in
> >> our
> >> >>> > > standalone environment, things can be automated fairly
> >> easily:
> >> >>> > >
> >> >>> > > 1. User downloads core distribution
> >> >>> > > 2. User downloads and drops in sample distribution and starts
> >> >>> the
> >> >>> > > standalone core
> >> >>> > > 3. Core reads the dependencies from the sample SCDL and pulls
> >> >>> down
> >> >>> > > the required extensions via the ArtifactFactory from a Maven
> >> >>> > > repository. This would resolve the transitive closure of all
> >> >>> > > extension dependencies. This would allow us to track
> >> >>> dependencies for
> >> >>> > > extension libraries such as Spring for "free" since most
> >> >>> projects
> >> >>> > > publish POMs to a Maven repo.
> >> >>> > > 4. If user chooses, they could avoid step 4 and just download
> >> >>> the
> >> >>> > > extension and plug it in
> >> >>> > >
> >> >>> > > Something similar to the above could be done for OSGi except
> >> >>> the end
> >> >>> > > user would just deploy a core bundle into an existing OSGi
> >> >>> host such
> >> >>> > > as Equinox they had installed.
> >> >>> > >
> >> >>> > > If we are deploying to a servlet container, things will
> >> >>> likely be
> >> >>> > > more complex but not too much:
> >> >>> > >
> >> >>> > > 1. User downloads sample application and builds it using
> >> >>> Maven, which
> >> >>> > > retrieves the core as a dependency and bundles everything
> >> >>> into a war.
> >> >>> > > 2 User deploys the sample war
> >> >>> > >
> >> >>> > > If we "prepackaged" every sample distribution so it could
> >> >>> just be
> >> >>> > > dropped in, I think we will wind up with a ton of packaging
> >> >>> problems
> >> >>> > > as core will need to be included in every one.
> >> >>> > >
> >> >>> > > I'm pretty firmly against distributions containing an entire
> >> >>> host
> >> >>> > > environment, such as Tomcat. I'd prefer we follow projects
> >> like
> >> >>> > > Spring, Struts, WebWork, Hibernate (take your pick) and
> >> provide
> >> >>> > > distributions which are simple to deploy into containers
> >> >>> using some
> >> >>> > > minimal configuration steps. My reason for this is partly
> >> >>> practical.
> >> >>> > > First, we should support deploying on a variety of host
> >> >>> environments
> >> >>> > > and having to rev versions would be a nightmare. Second, in
> >> >>> most data
> >> >>> > > centers I have come across, there is a standard image
> >> >>> technologies
> >> >>> > > must accommodate and they will not accept an "bundle of
> >> stuff".
> >> >>> > >
> >> >>> > >
> >> >>> > > Jim
> >> >>> > >
> >> >>> > > >
> >> >>> > > > ...ant
> >> >>> > > >
> >> >>> > > > On 8/17/06, Liu, Jervis <[EMAIL PROTECTED]> wrote:
> >> >>> > > >>
> >> >>> > > >> One thing concerns me would be the out-of-box user
> >> >>> experience. For
> >> >>> > > >> a first
> >> >>> > > >> time Tuscany user, don't you think it is more user
> >> >>> friendly if
> >> >>> > > >> users only
> >> >>> > > >> need to follow the readme, go to a directory, run a
> >> >>> common, then
> >> >>> > > >> everything
> >> >>> > > >> works out-of-box? Speaking in my experience, it does
> >> >>> encourage me
> >> >>> > > >> to explore
> >> >>> > > >> a new product further if I can set up and run a typical
> >> >>> helloworld
> >> >>> > > >> sample
> >> >>> > > >> successfully in 5 minutes without any coding. Well, maybe
> >> >>> just me
> >> >>> > > >> being too
> >> >>> > > >> lazy... ;-)
> >> >>> > > >>
> >> >>> > > >> Cheers,
> >> >>> > > >> Jervis
> >> >>> > > >>
> >> >>> > > >> > -----Original Message-----
> >> >>> > > >> > From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
> >> >>> > > >> > Sent: Thursday, August 17, 2006 6:54 AM
> >> >>> > > >> > To: [email protected]
> >> >>> > > >> > Subject: Sample framework
> >> >>> > > >> >
> >> >>> > > >> >
> >> >>> > > >> > We have had a rapid increase in the number of samples
> >> >>> recently
> >> >>> many
> >> >>> > > >> > of which do essentially the same thing. Some feedback
> >> >>> from M1
> >> >>> also
> >> >>> > > >> > said that we seemed to have invented the greatest
> >> number of
> >> >>> > > >> > varieties
> >> >>> > > >> > of HelloWorld but that it was hard to tell if SCA
> >> could do
> >> >>> anything
> >> >>> > > >> > else. I'd like to propose a change in how we
> >> structure the
> >> >>> > > >> > samples so
> >> >>> > > >> > that we make it clearer to illustrate the technology to
> >> >>> users.
> >> >>> > > >> >
> >> >>> > > >> > Rather than having separate projects for each technology
> >> >>> > > >> > variant, I'd
> >> >>> > > >> > like to suggest we have just a couple of projects that
> >> >>> provide a
> >> >>> > > >> > framework and then have instructions in the
> >> >>> documentation for
> >> >>> each
> >> >>> > > >> > technology that clearly show how to apply it.
> >> >>> > > >> >
> >> >>> > > >> > For example, I can see two framework environments:
> >> >>> > > >> > a) a client environment with a simple command line
> >> >>> client wires
> >> >>> > > >> > together a couple of local components
> >> >>> > > >> > b) a webapp environment with a simple JSP client that
> >> >>> also wires
> >> >>> > > >> > together a couple of local components
> >> >>> > > >> >
> >> >>> > > >> > Then, for example, the JavaScript extension could say:
> >> >>> > > >> > To illustrate the use of JavaScript as a component,
> >> >>> take the
> >> >>> > > >> > client a) and
> >> >>> > > >> > 1) replace <implementation.java class="Foo"/> with
> >> >>> > > >> > <implementation.javascript script=" foo.js"/>
> >> >>> > > >> > 2) Install javascript extension
> >> >>> > > >> > 2) rebuild/run sample
> >> >>> > > >> >
> >> >>> > > >> > Or, to illustrate the WebService binding:
> >> >>> > > >> > Server
> >> >>> > > >> > 1) Take webapp and add <service>< binding.ws ...>
> >> >>> > > >> > 2) Install Axis binding extension
> >> >>> > > >> > 3) Deploy server app to Tomcat
> >> >>> > > >> > Client
> >> >>> > > >> > 1) Take client application and replace <component
> >> >>> > > >> name="foo" ...>
> >> >>> > > >> > with <reference><binding.ws ...>
> >> >>> > > >> > 2) Install Axis binding extension
> >> >>> > > >> > 3) Run client
> >> >>> > > >> >
> >> >>> > > >> > The basic idea being, have a common framework and the
> >> >>> > > >> > instructions on
> >> >>> > > >> > how to use the particular extension.
> >> >>> > > >> > --
> >> >>> > > >> > Jeremy
> >> >>> > > >> >
> >> >>> > > >> >
> >> >>> > > >>
> >> >>>
> >> --------------------------------------------------------------------
> >> >>> -
> >> >>> > > >> > To unsubscribe, e-mail: tuscany-dev-
> >> >>> [EMAIL PROTECTED]
> >> >>> > > >> > For additional commands, e-mail: tuscany-dev-
> >> >>> [EMAIL PROTECTED]
> >> >>> > > >> >
> >> >>> > > >> >
> >> >>> > > >>
> >> >>> > > >>
> >> >>>
> >> --------------------------------------------------------------------
> >> >>> -
> >> >>> > > >> To unsubscribe, e-mail: tuscany-dev-
> >> [EMAIL PROTECTED]
> >> >>> > > >> For additional commands, e-mail: tuscany-dev-
> >> >>> [EMAIL PROTECTED]
> >> >>> > > >>
> >> >>> > > >>
> >> >>> > >
> >> >>> > >
> >> >>> > >
> >> >>>
> >> --------------------------------------------------------------------
> >> >>> -
> >> >>> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >>> > > For additional commands, e-mail: tuscany-dev-
> >> [EMAIL PROTECTED]
> >> >>> > >
> >> >>> > >
> >> >>>
> >> >>>
> >> >>>
> >> >>> I agree with Ant. As primarily a user (in the sense that I
> >> wanted to
> >> >>> understand it and try the samples) of the Java M1 release the
> >> >>> presence of
> >> >>> the pre-configured Tomcat installation was really handy for
> >> quickly
> >> >>> running
> >> >>> through the samples and getting a feel for what it was all about.
> >> >>> As you
> >> >>> are
> >> >>> constructing a build and distribution system/approach that allows
> >> >>> you to
> >> >>> cut
> >> >>> different distros to suit different requirements for hosting or
> >> >>> embedding
> >> >>> can you make a standalone samples distro for the interested
> >> >>> newbie. No
> >> >>> suggestion that this distro would get deployed into production or
> >> >>> used
> >> >>> other
> >> >>> than to get familiar with the technology or bootstrap a
> >> development
> >> >>> environment? This doesn't suit the hardcore techy who just
> >> wants the
> >> >>> latest
> >> >>> release of the components they are going to refresh into their
> >> hand
> >> >>> crafted
> >> >>> development/test/deployment environment but then they would go
> >> >>> and get one
> >> >>> of the other distros.
> >> >>>
> >> >>> Regards
> >> >>>
> >> >>> Simon
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
