Nabble - Jetty Discuss

Re: How to build org.mortbay.jetty.j2se6

2009-11-10T09:21:12Z

Jesse,

1) Could you please point me to instructions about how to get the agreement? I remember I had to fill & sign via PGP some contributor agreement file when I got contributor SVN access for Jetty 6 but I can't remember the details nor find the old agreement back.

2) There a two ways to make use of this module:
* J2SE mode: just drop the Jetty binaries and this module's jar in your classpath and any call to javax.xml.ws.Endpoint.publish() will actually publish the web service on Jetty instead of on Sun's embedded web server.
* J2EE/mixed mode: use this mode when you write a web application which needs to expose some web services (again with javax.xml.ws.Endpoint.publish()) but you want the web services to re-use the Jetty server and just create a new context per published web service. This requires the JettyHttpServerProvider.setServer() method to be called before any web service is published to tell the code to which server to add contexts.

3) I use both modes, the J2SE mode mostly for quick'n'dirty development and mixed mode mostly for production-quality code. The explanation at point (2) should gibe you a clear overview of the only possible use cases. If not shoot me as I wasn't clear enough describing them.

Re: How to build org.mortbay.jetty.j2se6

2009-11-10T09:06:51Z

Setting the system property is useless, just having the module on the classpath should be sufficient to have Jetty replace the Sun HTTP server.

Re: How to build org.mortbay.jetty.j2se6

2009-11-08T23:31:25Z

Hi all,

my usage scenario is this:

I have some kind of server using a propriatory protocol. To make the
server usable for 3rd party developers there is a web service interface
using SOAP messages over http.

Up til now I use JAX-WS, build a war file and deploy that to a servlet
container.

With embedded Jetty I can now provide the SOAP interface directly from
my main server, short, simple and effective by just setting a property

System.setProperty(
"com.sun.net.httpserver.HttpServerProvider",
"org.eclipse.jetty.jaxws2spi.JettyHttpServerProvider");

The SOAP endpoint for a sample Calculator service is published thusly:

Calculator calculator = new Calculator();
Endpoint endpoint = Endpoint.create(calculator);
endpoint.publish(calcContext);

Regards,
Axel

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: How to build org.mortbay.jetty.j2se6

2009-11-08T13:21:49Z

I have reviewed and committed this into the codehaus trunk and wired
it into the build...

A couple of things I would like to see here:

1) Ludovic: as the sole contributor of this and while we have your
attention, should this be a candidate for migrating to the eclipse
side of the jetty project would you also attach to the jira issue your
agreement that this contribution would also be acceptable to you for
being dual licensed EPL 1.0 and ASL 2.0? That way it will be easier
to get that contribution through should this be something the project
decides to do down the road.

2) Axel and Ludovic: a little bit of documentation as to how you guys
use this module would be great, if you just replied to this mail with
the info I'll get a wiki page going for it.

3) Axel and Ludovic: What is your general usage scenario for making
use of this context...is this something that you guys do standalone
just for a particular server or do you wire this into the default
jetty server on startup? Once I have a good idea on the usage and
configuration of this thing I'll go ahead and wire it into the
jetty-hightide distribution.

cheers and thanks for the contribution guys

jesse

--
jesse mcconnell
jesse.mcconnell@...

On Sun, Nov 8, 2009 at 07:20, Ludovic Orban <ludovic.orban@...> wrote:

>
> Jesse,
>
> This Jetty module is the only way I know to get scalable JAX-WS2 web
> services on J2SE.
>
> I've attached to JETTY-1143 a slightly cleaned up version which compiles and
> works with Jetty 7. I'd appreciate if that module could be reviewed and
> eventually committed back to the SVN repository.
>
> Thanks,
> Ludovic
> --
> View this message in context: http://old.nabble.com/How-to-build-org.mortbay.jetty.j2se6-tp26204777p26253711.html
> Sent from the Jetty Discuss mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Bamboo] Jetty - Trunk build 3166 has FAILED (0 tests failed). Change made by Jesse McConnell

2009-11-08T13:15:51Z

JETTY-TRUNK-3166 failed.
Code has been updated by Jesse McConnell.
No failed tests found, a possible compilation error.

Code Changes

See full change details

	Jesse McConnell JETTY-1143 adding into build and mentioning in VERSION.txt	(5659)
	Jesse McConnell JIRA-1143 port of jetty-j2se6 package to jetty7	(5658)

JIRA Issues

See full issue details

	JETTY-1143 (Related) make Jetty7 serve WebService request
	JIRA-1143 (Related) Could not obtain issue details from JIRA

Error Summary

See full build log

                    [INFO] ------------------------------------------------------------------------

                

                    [ERROR] BUILD ERROR

                

                    [INFO] ------------------------------------------------------------------------

                

                    [INFO] Failed to resolve artifact.

                

                    Missing:

                

                    ----------

                

                    1) com.sun.net.httpserver:http:jar:20070405

                

                      Try downloading the file manually from the project website.

                

                      Then, install it using the command: 

                

                          mvn install:install-file -DgroupId=com.sun.net.httpserver -DartifactId=http -Dversion=20070405 -Dpackaging=jar -Dfile=/path/to/file

                

                      Alternatively, if you host your own repository you can deploy the file there: 

                

                          mvn deploy:deploy-file -DgroupId=com.sun.net.httpserver -DartifactId=http -Dversion=20070405 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

                

                      Path to dependency: 

                

                              1) org.mortbay.jetty:jetty-jaxws2spi:jar:7.0.1.M0-SNAPSHOT

                

                              2) com.sun.net.httpserver:http:jar:20070405

                

                    ----------

                

                    1 required artifact is missing.

                

                    for artifact: 

                

                      org.mortbay.jetty:jetty-jaxws2spi:jar:7.0.1.M0-SNAPSHOT

                

                    from the specified remote repositories:

                

                      central (http://repo1.maven.org/maven2),

                

                      oss.sonatype.org (http://oss.sonatype.org/content/repositories/jetty-snapshots/)

                

                    [INFO] ------------------------------------------------------------------------

                

                    [INFO] For more information, run Maven with the -e switch

                

Email generated by Atlassian Bamboo - if you wish to stop receiving these emails edit your user profile or notify your administrator
Want this information in your IDE?

Actions

View Online
Add Comments
View Artifacts
Download Logs
Link to JIRA issue

Re: How to build org.mortbay.jetty.j2se6

2009-11-08T11:30:07Z

It's working for me.

Phantastic!!

Many thanks for spending time during the weekend Ludovic

Cheers,
Axel.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: How to build org.mortbay.jetty.j2se6

2009-11-08T07:52:43Z

great! I'll take a look, if it is working then we'll probably be able
to get it into the next release cycle of 7.0.1, otherwise would be the
one right after that

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@...

On Sun, Nov 8, 2009 at 07:20, Ludovic Orban <ludovic.orban@...> wrote:

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: How to build org.mortbay.jetty.j2se6

2009-11-08T05:20:32Z

Jesse,

This Jetty module is the only way I know to get scalable JAX-WS2 web services on J2SE.

I've attached to JETTY-1143 a slightly cleaned up version which compiles and works with Jetty 7. I'd appreciate if that module could be reviewed and eventually committed back to the SVN repository.

Thanks,
Ludovic

verifier and logging back in the sandbox

2009-11-07T22:59:40Z

I've moved the webapp-verifier and centralized logging back to the sandbox
for now.

They really "belong" in the codehaus as part of the non-core components.
But they've been developed at eclipse under the eclipse terms, so it's
best to keep them eclipse clean and in eclipse SVN.

svn+ssh://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/sandbox/trunk

So we need to come up with way to build non-core optional components
that are at eclipse. The eclipse update site and some of the OSGi
integration stuff are also examples of this are are currently
living at svn+ssh://gwilkins@.../svnroot/rt/org.eclipse.jetty/eclipse

Let's ponder this ASAP and get a solution, because I don't want these modules
to fester too long outside a good home.

cheers

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Bamboo] Jetty - Jetty 6 Branch build 821 was SUCCESSFUL (with 448 tests). Change made by Greg Wilkinson

2009-11-06T22:49:31Z

JETTY-JETTY6-821 was successful.
Code has been updated by Greg Wilkinson.
448 tests in total.

Code Changes

See full change details

Greg Wilkinson
check bamboo 3

(5652)

Error Summary

See full build log

                    2009-11-07 00:48:04,676 INFO - Terracotta 2.6.4, as of 20080822-130833 (Revision 9831 by cruise@rh4mo0 from 2.6)

                

                    2009-11-07 00:48:05,107 INFO - Configuration loaded from the file at '/opt/j2ee/domains/ci.codehaus.org/bamboo/webapps/atlassian-bamboo/data/atlassian-bamboo-2.3.1/xml-data/build-dir/JETTY-JETTY6/contrib/terracotta/src/test/resources/tc-config.xml'.

                

                    2009-11-07 00:48:13,437 INFO - Configuration loaded from the file at '/opt/j2ee/domains/ci.codehaus.org/bamboo/webapps/atlassian-bamboo/data/atlassian-bamboo-2.3.1/xml-data/build-dir/JETTY-JETTY6/contrib/terracotta/src/test/resources/tc-config.xml'.

                

                    2009-11-07 00:48:13,522 INFO - Log file: '/opt/j2ee/domains/ci.codehaus.org/bamboo/webapps/atlassian-bamboo/data/atlassian-bamboo-2.3.1/xml-data/build-dir/JETTY-JETTY6/target/terracotta/server-logs/terracotta-server.log'.

                

                    2009-11-07 00:48:15,823 INFO - Configuration loaded from the file at '/opt/j2ee/domains/ci.codehaus.org/bamboo/webapps/atlassian-bamboo/data/atlassian-bamboo-2.3.1/xml-data/build-dir/JETTY-JETTY6/contrib/terracotta/src/test/resources/tc-config.xml'.

                

Email generated by Atlassian Bamboo - if you wish to stop receiving these emails edit your user profile or notify your administrator
Want this information in your IDE?

Actions

View Online
Add Comments
View Artifacts
Download Logs
Link to JIRA issue

[Bamboo] Jetty - Jetty 6 Branch build 820 has FAILED (1 tests failed, no failures were new). Change made by Greg Wilkinson

2009-11-06T22:13:09Z

JETTY-JETTY6-820 failed.
Code has been updated by Greg Wilkinson.
1/449 tests failed.

Code Changes

See full change details

Greg Wilkinson
check bamboo 2

(5651)

Tests

See full test details

Failed Tests (1)
	HttpGeneratorTest : Output (Existing)

Error Summary

See full build log

                    [INFO] ------------------------------------------------------------------------

                

                    [ERROR] BUILD FAILURE

                

                    [INFO] ------------------------------------------------------------------------

                

                    [INFO] There are test failures.

                

                    Please refer to /opt/j2ee/domains/ci.codehaus.org/bamboo/webapps/atlassian-bamboo/data/atlassian-bamboo-2.3.1/xml-data/build-dir/JETTY-JETTY6/modules/jetty/target/surefire-reports for the individual test results.

                

                    [INFO] ------------------------------------------------------------------------

                

                    [INFO] For more information, run Maven with the -e switch

                

Email generated by Atlassian Bamboo - if you wish to stop receiving these emails edit your user profile or notify your administrator
Want this information in your IDE?

Actions

View Online
Add Comments
View Artifacts
Download Logs
Link to JIRA issue

[Bamboo] Jetty - Jetty 6 Branch build 819 has FAILED (1 tests failed, no failures were new)

2009-11-06T22:04:42Z

JETTY-JETTY6-819 failed.
This build was manually triggered by Greg Wilkinson.
1/449 tests failed.

Code Changes

This build does not have any commits.

Tests

See full test details

Failed Tests (1)
	HttpGeneratorTest : Output (Existing)

Error Summary

See full build log

                    [INFO] ------------------------------------------------------------------------

                

                    [ERROR] BUILD FAILURE

                

                    [INFO] ------------------------------------------------------------------------

                

                    [INFO] There are test failures.

                

                    Please refer to /opt/j2ee/domains/ci.codehaus.org/bamboo/webapps/atlassian-bamboo/data/atlassian-bamboo-2.3.1/xml-data/build-dir/JETTY-JETTY6/modules/jetty/target/surefire-reports for the individual test results.

                

                    [INFO] ------------------------------------------------------------------------

                

                    [INFO] For more information, run Maven with the -e switch

                

Email generated by Atlassian Bamboo - if you wish to stop receiving these emails edit your user profile or notify your administrator
Want this information in your IDE?

Actions

View Online
Add Comments
View Artifacts
Download Logs
Link to JIRA issue

[Bamboo] Jetty - Jetty 6 Branch build 818 has FAILED (1 tests failed, no failures were new). Change made by Greg Wilkinson

2009-11-06T21:47:15Z

JETTY-JETTY6-818 failed.
Code has been updated by Greg Wilkinson.
1/449 tests failed.

Code Changes

See full change details

Greg Wilkinson
check bamboo

(5650)

Tests

See full test details

Failed Tests (1)
	HttpGeneratorTest : Output (Existing)

Error Summary

See full build log

                    [INFO] ------------------------------------------------------------------------

                

                    [ERROR] BUILD FAILURE

                

                    [INFO] ------------------------------------------------------------------------

                

                    [INFO] There are test failures.

                

                    Please refer to /opt/j2ee/domains/ci.codehaus.org/bamboo/webapps/atlassian-bamboo/data/atlassian-bamboo-2.3.1/xml-data/build-dir/JETTY-JETTY6/modules/jetty/target/surefire-reports for the individual test results.

                

                    [INFO] ------------------------------------------------------------------------

                

                    [INFO] For more information, run Maven with the -e switch

                

Email generated by Atlassian Bamboo - if you wish to stop receiving these emails edit your user profile or notify your administrator
Want this information in your IDE?

Actions

View Online
Add Comments
View Artifacts
Download Logs
Link to JIRA issue

[Bamboo] Jetty - Jetty 6 Branch build 817 has FAILED (1 tests failed, no failures were new)

2009-11-06T21:29:32Z

JETTY-JETTY6-817 failed.
This build was manually triggered by Greg Wilkinson.
1/449 tests failed.

Code Changes

This build does not have any commits.

Tests

See full test details

Failed Tests (1)
	HttpGeneratorTest : Output (Existing)

Error Summary

See full build log

                    [INFO] ------------------------------------------------------------------------

                

                    [ERROR] BUILD FAILURE

                

                    [INFO] ------------------------------------------------------------------------

                

                    [INFO] There are test failures.

                

                    Please refer to /opt/j2ee/domains/ci.codehaus.org/bamboo/webapps/atlassian-bamboo/data/atlassian-bamboo-2.3.1/xml-data/build-dir/JETTY-JETTY6/modules/jetty/target/surefire-reports for the individual test results.

                

                    [INFO] ------------------------------------------------------------------------

                

                    [INFO] For more information, run Maven with the -e switch

                

Email generated by Atlassian Bamboo - if you wish to stop receiving these emails edit your user profile or notify your administrator
Want this information in your IDE?

Actions

View Online
Add Comments
View Artifacts
Download Logs
Link to JIRA issue

[Bamboo] Jetty - Jetty 6 Branch build 816 has FAILED (1 tests failed, no failures were new). Change made by Greg Wilkinson

2009-11-06T16:21:56Z

JETTY-JETTY6-816 failed.
Code has been updated by Greg Wilkinson.
1/449 tests failed.

Code Changes

See full change details

Greg Wilkinson
JETTY-1144 fixed multi-byte character overflow

(5648)

Tests

See full test details

Failed Tests (1)
	HttpGeneratorTest : Output (Existing)

JIRA Issues

See full issue details

JETTY-1144 (Related)
multibyte character overflow.

Error Summary

See full build log

                    [INFO] ------------------------------------------------------------------------

                

                    [ERROR] BUILD FAILURE

                

                    [INFO] ------------------------------------------------------------------------

                

                    [INFO] There are test failures.

                

                    Please refer to /opt/j2ee/domains/ci.codehaus.org/bamboo/webapps/atlassian-bamboo/data/atlassian-bamboo-2.3.1/xml-data/build-dir/JETTY-JETTY6/modules/jetty/target/surefire-reports for the individual test results.

                

                    [INFO] ------------------------------------------------------------------------

                

                    [INFO] For more information, run Maven with the -e switch

                

Email generated by Atlassian Bamboo - if you wish to stop receiving these emails edit your user profile or notify your administrator
Want this information in your IDE?

Actions

View Online
Add Comments
View Artifacts
Download Logs
Link to JIRA issue

[Bamboo] Jetty - Jetty 6 Branch build 815 has FAILED (1 tests failed). Change made by Greg Wilkinson

2009-11-06T16:16:36Z

JETTY-JETTY6-815 failed.
Code has been updated by Greg Wilkinson.
1/449 tests failed.

Code Changes

See full change details

Greg Wilkinson
JETTY-1144 fixed multi-byte character overflow

(5647)

Tests

See full test details

Failed Tests (1)
	HttpGeneratorTest : Output (New)

JIRA Issues

See full issue details

JETTY-1144 (Related)
multibyte character overflow.

Error Summary

See full build log

                    [INFO] ------------------------------------------------------------------------

                

                    [ERROR] BUILD FAILURE

                

                    [INFO] ------------------------------------------------------------------------

                

                    [INFO] There are test failures.

                

                    Please refer to /opt/j2ee/domains/ci.codehaus.org/bamboo/webapps/atlassian-bamboo/data/atlassian-bamboo-2.3.1/xml-data/build-dir/JETTY-JETTY6/modules/jetty/target/surefire-reports for the individual test results.

                

                    [INFO] ------------------------------------------------------------------------

                

                    [INFO] For more information, run Maven with the -e switch

                

Email generated by Atlassian Bamboo - if you wish to stop receiving these emails edit your user profile or notify your administrator
Want this information in your IDE?

Actions

View Online
Add Comments
View Artifacts
Download Logs
Link to JIRA issue

Re: How to build org.mortbay.jetty.j2se6

2009-11-06T07:06:37Z

i will try and look at this tonight or this weekend, I don't think I
really ever paid attention to this module, but I agree if its serving
soap goop its probably good to get going

jesse

--
jesse mcconnell
jesse.mcconnell@...

On Fri, Nov 6, 2009 at 04:28, Axel Rose <axel.roeslein@...> wrote:

> Well, it was easy to make the code compilable but ...
>
> I have no success at runtime because the code relies somehow on
> org.eclipse.jetty.server.handler._handlers being non volatile. This
> has been changed in Jetty 7.
>
> Now it would be probably best to ask the original author lorban. Is he
> (are you) still actively
> working on this package?
>
> Otherwise -- has somebody else time to help on this?
>
> It would be a real benefit for Jetty 7 to serve SOAP request IMO.
>
>
> Regards,
> Axel
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: How to build org.mortbay.jetty.j2se6

2009-11-06T02:28:55Z

Well, it was easy to make the code compilable but ...

I have no success at runtime because the code relies somehow on
org.eclipse.jetty.server.handler._handlers being non volatile. This
has been changed in Jetty 7.

Now it would be probably best to ask the original author lorban. Is he
(are you) still actively
working on this package?

Otherwise -- has somebody else time to help on this?

It would be a real benefit for Jetty 7 to serve SOAP request IMO.

Regards,
Axel

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: iJetty on Android

2009-11-05T22:18:13Z

Hi Jan,

are there any examples of servlets deployed on the iJetty server as
well?
I will look around but just in case you can tell me it will help.

Thanks

Jan Bartel wrote:

> Demetris,
>
> Yes, you can certainly run i-jetty both on the emulator and on a real
> handset.
>
> If you go to http://code.google.com/p/i-jetty/ you'll see some links to
> wiki pages over on the right-hand side that explains how to use it to
> download webapps. The README in the distro should also have instructions.
>
> Jan
>
> Demetris wrote:
>>
>> Hi all,
>>
>> I want to host RESTful services on Android based mobile devices and
>> it seems
>> to me that iJetty is the best current solution for that. Can I run
>> iJetty on the Android
>> emulator and how do I "download" war files that I have build for the
>> Jetty web server?
>>
>> Thanks
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: How to build org.mortbay.jetty.j2se6

2009-11-05T00:22:08Z

> The jetty j2se6 module has not been ported to jetty-7 yet.

Thanks for the information.

Perhaps I try this on my own.

Regards
Axel

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: How to build org.mortbay.jetty.j2se6

2009-11-04T15:16:26Z

Axel,

The jetty j2se6 module has not been ported to jetty-7 yet.
It is only available in jetty-6. Note you only need to check
out and build https://svn.codehaus.org/jetty/jetty/branches/jetty-6.1
and it will also build most modules from contrib.

cheers
Jan

Axel Rose wrote:

> (repeated from user@...)
>
> Hello all,
>
> I wanted to test the org.mortbay.jetty.j2se6 classes but couldn't succeed
> to build them on my own using maven.
>
> This is what I did:
>
> svn co http://svn.codehaus.org/jetty/jetty/trunk jetty
> cd jetty
> mvn -Pall-modules install
>
> This works well. Now
>
> svn co http://svn.codehaus.org/jetty-contrib/trunk jetty-contrib
> cd jetty-contrib
> mvn install
>
> gives this error:
> ---
> [INFO] Scanning for projects...
> [INFO] ------------------------------------------------------------------------
> [ERROR] FATAL ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Error building POM (may not be this project's POM).
>
>
> Project ID: org.mortbay.jetty:jetty-contrib-parent:pom:7.0.0.1-SNAPSHOT
>
> Reason: Cannot find parent: org.mortbay.jetty:jetty-project for
> project: org.mortbay.jetty:jetty-contrib-parent:pom:7.0.0.1-SNAPSHOT
> for project org.mortbay.jetty:jetty-contrib-parent:pom:7.0.0.1-SNAPSHOT
>
>
> [INFO] ------------------------------------------------------------------------
> [INFO] Trace
> org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
> org.mortbay.jetty:jetty-project for project:
> org.mortbay.jetty:jetty-contrib-parent:pom:7.0.0.1-SNAPSHOT for
> project org.mortbay.jetty:jetty-contrib-parent:pom:7.0.0.1-SNAPSHOT
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.project.ProjectBuildingException: Cannot
> find parent: org.mortbay.jetty:jetty-project for project:
> org.mortbay.jetty:jetty-contrib-parent:pom:7.0.0.1-SNAPSHOT for
> project org.mortbay.jetty:jetty-contrib-parent:pom:7.0.0.1-SNAPSHOT
> at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1370)
> ---
>
> How could I continue?
>
> What is the state of the contrib code anyway?
> It looks to me as if this is not yet ported to Jetty 7 org.eclipse
>
>
> Thanks
> Axel
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

--
Jan Bartel, Webtide LLC | janb@... | http://www.webtide.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

How to build org.mortbay.jetty.j2se6

2009-11-04T13:17:29Z

(repeated from user@...)

Hello all,

I wanted to test the org.mortbay.jetty.j2se6 classes but couldn't succeed
to build them on my own using maven.

This is what I did:

svn co http://svn.codehaus.org/jetty/jetty/trunk jetty
cd jetty
mvn -Pall-modules install

This works well. Now

svn co http://svn.codehaus.org/jetty-contrib/trunk jetty-contrib
cd jetty-contrib
mvn install

gives this error:
---
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).

Project ID: org.mortbay.jetty:jetty-contrib-parent:pom:7.0.0.1-SNAPSHOT

Reason: Cannot find parent: org.mortbay.jetty:jetty-project for
project: org.mortbay.jetty:jetty-contrib-parent:pom:7.0.0.1-SNAPSHOT
for project org.mortbay.jetty:jetty-contrib-parent:pom:7.0.0.1-SNAPSHOT

[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
org.mortbay.jetty:jetty-project for project:
org.mortbay.jetty:jetty-contrib-parent:pom:7.0.0.1-SNAPSHOT for
project org.mortbay.jetty:jetty-contrib-parent:pom:7.0.0.1-SNAPSHOT
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.ProjectBuildingException: Cannot
find parent: org.mortbay.jetty:jetty-project for project:
org.mortbay.jetty:jetty-contrib-parent:pom:7.0.0.1-SNAPSHOT for
project org.mortbay.jetty:jetty-contrib-parent:pom:7.0.0.1-SNAPSHOT
at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1370)
---

How could I continue?

What is the state of the contrib code anyway?
It looks to me as if this is not yet ported to Jetty 7 org.eclipse

Thanks
Axel

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: iJetty on Android

2009-11-02T23:05:58Z

Super - I will give it a shot - thanks Jan.

Jan Bartel wrote:

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: iJetty on Android

2009-11-02T22:17:58Z

Demetris,

Yes, you can certainly run i-jetty both on the emulator and on a real
handset.

If you go to http://code.google.com/p/i-jetty/ you'll see some links to
wiki pages over on the right-hand side that explains how to use it to
download webapps. The README in the distro should also have instructions.

Jan

Demetris wrote:

>
> Hi all,
>
> I want to host RESTful services on Android based mobile devices and it
> seems
> to me that iJetty is the best current solution for that. Can I run
> iJetty on the Android
> emulator and how do I "download" war files that I have build for the
> Jetty web server?
>
> Thanks
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

iJetty on Android

2009-11-02T22:12:12Z

Hi all,

I want to host RESTful services on Android based mobile devices and it seems
to me that iJetty is the best current solution for that. Can I run
iJetty on the Android
emulator and how do I "download" war files that I have build for the
Jetty web server?

Thanks

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: org/mortbay/jetty/webapp/WebAppClassLoader previously initiated loading for a different type with name "javax/management/MBeanServer"

2009-11-02T02:04:05Z

i just try an upgrade with grails 1.2M3
and i get a similar error, but with different class

Error executing script RunApp: loader constraint violation: loader (instance of <bootloader>) previously initiated loading for a different type with name "javax/management/NotificationListener"

what it could be?

vedil wrote:

I have a web application which uses webwork, hibernate and c3p0 which was working on apache tomcat.
I do not have any data source configured.

On jetty when i deploy the same war, the deployment was fine.
But when i try to use the dynamic content where a server side action tries to access database i get this exception
14:14:29,718 ERROR DispatcherUtils: Could not execute action
java.lang.reflect.InvocationTargetException

the cause or it is,
Caused by: java.lang.LinkageError: loader constraint violation: loader (instance
of org/mortbay/jetty/webapp/WebAppClassLoader) previously initiated loading for
a different type with name "javax/management/MBeanServer"
down the stack trace I see c3p0 classes and hibernate ones.

So I am assuming some how the application is not bale to access database.

I have searched a lot for this could not find any useful results some of the relevant links that i found are
1. http://www.nabble.com/Help-a-sysadmin-smile-today-%3A)-tt16031477.html#a16031477
2. http://inventorsparadox.blogspot.com/2008_11_01_archive.html

I have tried the second link mentioned but without any success.

Can any body help me on this.

LocalConnector

2009-10-29T19:25:49Z

simone,

the updated localconnector is really cool.
It makes concurrent unit testing so much simpler!

cheers

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Deployment manager states

2009-10-23T12:56:05Z

Jesse,

I agree.

In some ways, deploy, verifier and centralized logging are all about
bundling of jetty in various ways - so they almost kind of live better
at codehaus anyway.

Having said that, the existing deployers are definitely part of core
and we do need to replace them eventually with a cleaner, meaner, leaner
implementations.

So I can see the deplay manager going over sooner.... but potentially
into the existing jetty-deploy package.

cheers

Jesse McConnell wrote:

> All this being said...I wanted to take a quick step back and start the
> review of the artifacts going into 7.0.1 as this has direct bearing on
> that...
>
> there are a couple of things in jetty trunk that are currently
> deploying snapshot wise into jetty @ eclipse maven central artifact
> space and that bears review with this.
>
> namely the jetty-webapp-verifier and the jetty-centalized-logging bits
> and pieces..
>
> So, with the idea in mind that jetty @ eclipse is supposed to be best
> of breed components and represent the _core_ of jetty I am thinking
> that maybe we want to change this a bit.
>
> I propose that maybe the above artifacts and this jetty-deployer work
> all go back to codehaus trunk for stewing and to gain some community
> traction. Then if and when these artifacts gain a larger backing and
> usage and we want to accept them into honest to god jetty core, we go
> ahead and move them over (following whatever processes we need).
>
> This represents a bit of backpedaling on my part (ok maybe a lot) as I
> have been an advocate of just getting new development going on at
> eclipse, but at least for now I am thinking that we ought to let
> things stew at codehaus longer...and also focus on making sure that
> eclipse side is a trim lean mean fighting machine, both code and
> process wise within eclipse.
>
> thoughts?
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Deployment manager states

2009-10-23T09:22:48Z

All this being said...I wanted to take a quick step back and start the
review of the artifacts going into 7.0.1 as this has direct bearing on
that...

there are a couple of things in jetty trunk that are currently
deploying snapshot wise into jetty @ eclipse maven central artifact
space and that bears review with this.

namely the jetty-webapp-verifier and the jetty-centalized-logging bits
and pieces..

So, with the idea in mind that jetty @ eclipse is supposed to be best
of breed components and represent the _core_ of jetty I am thinking
that maybe we want to change this a bit.

I propose that maybe the above artifacts and this jetty-deployer work
all go back to codehaus trunk for stewing and to gain some community
traction. Then if and when these artifacts gain a larger backing and
usage and we want to accept them into honest to god jetty core, we go
ahead and move them over (following whatever processes we need).

This represents a bit of backpedaling on my part (ok maybe a lot) as I
have been an advocate of just getting new development going on at
eclipse, but at least for now I am thinking that we ought to let
things stew at codehaus longer...and also focus on making sure that
eclipse side is a trim lean mean fighting machine, both code and
process wise within eclipse.

thoughts?

jesse

--
jesse mcconnell
jesse.mcconnell@...

On Thu, Oct 22, 2009 at 22:28, Michael Gorovoy <michael@...> wrote:

> +1 for Jesse, and here's my 2 cents worth of thoughts on this issues.
>
> It would take a very sophisticated developer as well as a major effort right
> now to be able to re-wire the application deployment lifecycle, and I agree
> with Jesse that Jetty needs to have a way to extend the core lifecycle at
> the configuration phase to include additional arbitrary steps at any point
> in the lifecycle, as well as change the cofiguration of the existing steps.
>
> I would suggest to specify the application deployment lifecycle in terms of
> 'goals' describing where the application is in the deployment process, and
> 'transitions', that define the conditions that need to be met and actions
> that need to be performed to move the application to the next 'goal' in the
> lifecycle.
>
> Each goal would be reachable by any number of transitions, but would have
> only one exit transition associated with it. Each goal could be either
> stateful or transitional. When deployment process reaches a stateful goal,
> the lifecycle will not process the next transition until it is externally
> re-activated, whereas when deployment process reaches a transitional goal,
> the next transition will be processed immediately after reaching this goal.
> Each transition would have two possible result goals that it can bring the
> lifecycle to, one for success and the other one for failure.
>
> As long as the new architecture will be flexible enough to allow configuring
> an arbitrary deployment lifecycle using the above abstractions, with goals
> possibly represented by entries in a data structure, and transitions defined
> by classes that implement a specified interface, it would be possible to
> achieve the configurability and avoid having to create an one-size-fits-all
> solution.
>
> Michael Gorovoy / michael@...
>
>
> On Thu, Oct 22, 2009 at 9:08 PM, Jesse McConnell <jesse.mcconnell@...>
> wrote:
>>
>> lets see...
>>
>> I see the action of wiring up something like the webapp verifier as a
>> step in the deployment of a webapp, maybe not a full on 'STATE" but
>> certainly one step in the process
>>
>> so long as there is a simple way of arbitrarily wiring functionality X
>> to the lifecycle of deployment I am pretty happy personally
>>
>> and that functionality X should be able to run the gambit from webapp
>> verification, to mailing a mailing list that a webapp has deployed, to
>> complex scenarios involving coordination in a cluster
>>
>> I should also be able to wire those up so they execute in a simple
>> order as well...
>>
>> When I was looking at wiring up the webapp verifier previously I added
>> it as a part of webapp configuration itself which it really wasn't I
>> guess, it was more of a sanity check that this webapp was going to be
>> allowed to deploy at all, much less get configured, etc...so it really
>> should have been able to slot in somewhere prior to webapp
>> configuration even taking place....
>>
>> we can do a lot of this kinda stuff as jetty developers, but my
>> concern here is that I see definite points in here that a third party
>> could want to insert their own functionality in the deployment process
>> and it currently takes a harder core developer to implement
>>
>> anyway, I have said my bit...i like the idea of a simple framework
>> located on this part of jetty that allows third parties to implement
>> new workflows on top of (like the jetty maven plugin for example)
>>
>> jesse
>>
>> --
>> jesse mcconnell
>> jesse.mcconnell@...
>>
>>
>>
>> On Thu, Oct 22, 2009 at 18:48, Greg Wilkins <gregw@...> wrote:
>> > Jesse McConnell wrote:
>> >> Core lifecycle? certainly not
>> >>
>> >> a common use case for workflow as it relates to deployment, sure
>> >
>> >
>> > If Stage is the only optional workflow state that we can think of,
>> > then I'd prefer to have it in the base state machine and avoid
>> > the hassles of a dynamically extensible state machine that would
>> > be required to optionally support extra states.
>> >
>> >
>> > cheers
>> >
>> >
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe from this list, please visit:
>> >
>> > http://xircles.codehaus.org/manage_email
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Deployment manager states

2009-10-22T20:28:32Z

+1 for Jesse, and here's my 2 cents worth of thoughts on this issues.

It would take a very sophisticated developer as well as a major effort right now to be able to re-wire the application deployment lifecycle, and I agree with Jesse that Jetty needs to have a way to extend the core lifecycle at the configuration phase to include additional arbitrary steps at any point in the lifecycle, as well as change the cofiguration of the existing steps.

I would suggest to specify the application deployment lifecycle in terms of 'goals' describing where the application is in the deployment process, and 'transitions', that define the conditions that need to be met and actions that need to be performed to move the application to the next 'goal' in the lifecycle.

Each goal would be reachable by any number of transitions, but would have only one exit transition associated with it. Each goal could be either stateful or transitional. When deployment process reaches a stateful goal, the lifecycle will not process the next transition until it is externally re-activated, whereas when deployment process reaches a transitional goal, the next transition will be processed immediately after reaching this goal. Each transition would have two possible result goals that it can bring the lifecycle to, one for success and the other one for failure.

As long as the new architecture will be flexible enough to allow configuring an arbitrary deployment lifecycle using the above abstractions, with goals possibly represented by entries in a data structure, and transitions defined by classes that implement a specified interface, it would be possible to achieve the configurability and avoid having to create an one-size-fits-all solution.

Michael Gorovoy / michael@...

On Thu, Oct 22, 2009 at 9:08 PM, Jesse McConnell <jesse.mcconnell@...> wrote:

lets see...

I see the action of wiring up something like the webapp verifier as a
step in the deployment of a webapp, maybe not a full on 'STATE" but
certainly one step in the process

so long as there is a simple way of arbitrarily wiring functionality X
to the lifecycle of deployment I am pretty happy personally

and that functionality X should be able to run the gambit from webapp
verification, to mailing a mailing list that a webapp has deployed, to
complex scenarios involving coordination in a cluster

I should also be able to wire those up so they execute in a simple
order as well...

When I was looking at wiring up the webapp verifier previously I added
it as a part of webapp configuration itself which it really wasn't I
guess, it was more of a sanity check that this webapp was going to be
allowed to deploy at all, much less get configured, etc...so it really
should have been able to slot in somewhere prior to webapp
configuration even taking place....

we can do a lot of this kinda stuff as jetty developers, but my
concern here is that I see definite points in here that a third party
could want to insert their own functionality in the deployment process
and it currently takes a harder core developer to implement

anyway, I have said my bit...i like the idea of a simple framework
located on this part of jetty that allows third parties to implement
new workflows on top of (like the jetty maven plugin for example)

jesse

--
jesse mcconnell
jesse.mcconnell@...

On Thu, Oct 22, 2009 at 18:48, Greg Wilkins <gregw@...> wrote:
> Jesse McConnell wrote:
>> Core lifecycle? certainly not
>>
>> a common use case for workflow as it relates to deployment, sure
>
>
> If Stage is the only optional workflow state that we can think of,
> then I'd prefer to have it in the base state machine and avoid
> the hassles of a dynamically extensible state machine that would
> be required to optionally support extra states.
>
>
> cheers
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Deployment manager states

2009-10-22T18:08:58Z

lets see...

I see the action of wiring up something like the webapp verifier as a
step in the deployment of a webapp, maybe not a full on 'STATE" but
certainly one step in the process

so long as there is a simple way of arbitrarily wiring functionality X
to the lifecycle of deployment I am pretty happy personally

and that functionality X should be able to run the gambit from webapp
verification, to mailing a mailing list that a webapp has deployed, to
complex scenarios involving coordination in a cluster

I should also be able to wire those up so they execute in a simple
order as well...

When I was looking at wiring up the webapp verifier previously I added
it as a part of webapp configuration itself which it really wasn't I
guess, it was more of a sanity check that this webapp was going to be
allowed to deploy at all, much less get configured, etc...so it really
should have been able to slot in somewhere prior to webapp
configuration even taking place....

we can do a lot of this kinda stuff as jetty developers, but my
concern here is that I see definite points in here that a third party
could want to insert their own functionality in the deployment process
and it currently takes a harder core developer to implement

anyway, I have said my bit...i like the idea of a simple framework
located on this part of jetty that allows third parties to implement
new workflows on top of (like the jetty maven plugin for example)

jesse

--
jesse mcconnell
jesse.mcconnell@...

On Thu, Oct 22, 2009 at 18:48, Greg Wilkins <gregw@...> wrote:

> Jesse McConnell wrote:
>> Core lifecycle? certainly not
>>
>> a common use case for workflow as it relates to deployment, sure
>
>
> If Stage is the only optional workflow state that we can think of,
> then I'd prefer to have it in the base state machine and avoid
> the hassles of a dynamically extensible state machine that would
> be required to optionally support extra states.
>
>
> cheers
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Another deployment mode was: Deployment manager states

2009-10-22T16:50:43Z

A frequent request that we get is to have the jetty-maven plugin able to
run more than 1 webapp at once... both in development (edit the sources)
mode.

I don't think that could be done in the traditional mvn jetty-run style,
but perhaps we could have a MavenDeployer configuration of the deployment
manager that would discover and configure webapps from 1 or more maven
projects. It could then share some/most of the guts of the maven
jetty plugin and setup classpaths etc from the project and run in
development mode.

cheers

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Deployment manager states

2009-10-22T16:48:16Z

Jesse McConnell wrote:
> Core lifecycle? certainly not
>
> a common use case for workflow as it relates to deployment, sure

If Stage is the only optional workflow state that we can think of,
then I'd prefer to have it in the base state machine and avoid
the hassles of a dynamically extensible state machine that would
be required to optionally support extra states.

cheers

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Deployment manager states

2009-10-21T18:09:44Z

Core lifecycle? certainly not

a common use case for workflow as it relates to deployment, sure

staged is not something to get hung up on imo, it is one example of a
phase in a lifecycle of deployment, one of a full on cornucopia
(thanksgiving coming up!) of potential deployment scenarios which is
at the heart of the discussion at this point. in reality, we have run
across a couple of scenarios that deployment needed to be extended in
arbitrary ways. as developers we certainly have the ability to 'make
something work' but as engineers the desire is to create something
that others with less internals knowledge can easily work with to
extend

jetty by default has a simple state machine worth of deployment
'steps' to its workflow...and ideally we would like a way to embrace
and extend that in a simple and easy to visualize way...something that
could wire up arbitrary workflows, from the simple webapp appears in a
directory and it gets unpacked and deployed (oh so simple, ya I know
:P) to the most convoluted cluster coordinated and webapp registered
human workflow finger clicky required audited and reaudited ugly
workflow someone could create (probably a government committee)

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@...

On Wed, Oct 21, 2009 at 17:49, Jan Bartel <janb@...> wrote:

> I'm not totally onboard (yet) with the STAGED state. Are we saying
> that is part of the core lifecycle of deployment? It seems to me
> like something that a specific _type_ of deployer might want
> to implement.
>
> Jesse's example makes it sound like it is some verification step
> after it is started (eg can you hit the app and get back something?)
> before the context is declared to be LIVE?
>
> Jan
>
> Jesse McConnell wrote:
>>>
>>> OK - so I understand STAGED now. It is like it's running
>>> but the load balancer has not been told yet to direct
>>> real load to it.
>>
>> Yes, or I have some application I want to test with live data through
>> a restricted environment like only though some vpn connection to
>> ensure it 'looks right' before openning to the public or 'is wired up
>> to all the correct databases' or any of the countless fearful
>> situations companies processes get themselves into to 'approving
>> something to go live'
>>
>>
>>> Thus we do need a better name for the initial state
>>> so it does not clash with the JEE unavailable state.
>>> Let's call it DISCOVERED for now (now == this email
>>> or until a better suggestion comes up).
>>
>> Fair enough, Discovered works for clusters as well, the webapp has
>> been pushed out the all of the machines on the cluster and is in
>> discovered state...ie everyone knows about it.
>>
>> This gives me the side thought of a corridinated cluster
>> deployment...where there is corridination of the lifecycles, ie, ALL
>> machines on cluster have to be in DISCOVERED before they are told to
>> advance to next phase, and so on and so forth, ensuring that the
>> webapps transition from phase to phase in lockstep.
>>
>>> I'm cool with these being meta states that hide the
>>> nuts and bolts below. But we do need to know
>>> exactly what the nuts and bolts are.
>>>
>>> I think the meta states we have are:
>>>
>>> DISCOVERED : constructed, !validated !linked !configured
>>>
>>> DEPLOYED: constructed, validated, linked, configured, !started
>>>
>>> UNAVAILABLE: started, Unavailable(in JEE sense)
>>>
>>> STAGED: started, !active
>>>
>>> LIVE: started, active
>>
>> joakim has some pretty graphics for this he should bust out here
>>
>>
>>> For most webapps, STAGED will automatically flow through to LIVE
>>> (ie if there is no other switch needed to direct traffic to it).
>>> Or it may need even need a manual step in some environments.
>>
>> agreed, I think the gist behind joakim's efforts are rooted in the
>> 'one size does not fit all' approach to webapp deployment. So instead
>> of codifying it strictly in interfaces you extend, you make it more
>> generally extendable such that the default deployer for jetty is
>> functionally equivalent in lifecycle as to how it is now, but in other
>> scenarios where the user needs a staged environment, or the ability to
>> add in a webapp registry service, or even the lockstep cluster stuff I
>> mentioned above you have the ability to wire up the workflow as needed
>> calling out the bits of functionality as needed.
>>
>> at least that is how I see it
>>
>>> UNAVAILABLE: might transit to STAGED if the unavailable exception
>>> had a timeout and on a subsequent attempt to unavailable status
>>> was clear. We might need to extend jetty with some callback for
>>> this occurrence?
>>
>> I see it that in the normal jetty deployer sense, STAGED is not even a
>> factor as it is not a part of the default deployer workflow...just
>> that it will be a very popular component (maybe even developed as a
>> separate module that they activate and wire in via the deployer
>> workflow configuration).
>>
>> I could see users like google app engine tie into this, create a
>> custom deployment workflow and bundle it up as its own maven artifact,
>> drop it into lib, drop in a jetty-mydeployment.xml file and good to
>> go.
>>
>> Shoot, that would make it really easy to make an ascii image of a
>> dinosaur that is wired to print to console when a webapp
>> deploys...awesome test case! :)
>>
>> cheers,
>> jesse
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
> --
> Jan Bartel, Webtide LLC | janb@... | http://www.webtide.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Deployment manager states

2009-10-21T15:49:59Z

I'm not totally onboard (yet) with the STAGED state. Are we saying
that is part of the core lifecycle of deployment? It seems to me
like something that a specific _type_ of deployer might want
to implement.

Jesse's example makes it sound like it is some verification step
after it is started (eg can you hit the app and get back something?)
before the context is declared to be LIVE?

Jan

Jesse McConnell wrote:

>> OK - so I understand STAGED now. It is like it's running
>> but the load balancer has not been told yet to direct
>> real load to it.
>
> Yes, or I have some application I want to test with live data through
> a restricted environment like only though some vpn connection to
> ensure it 'looks right' before openning to the public or 'is wired up
> to all the correct databases' or any of the countless fearful
> situations companies processes get themselves into to 'approving
> something to go live'
>
>
>> Thus we do need a better name for the initial state
>> so it does not clash with the JEE unavailable state.
>> Let's call it DISCOVERED for now (now == this email
>> or until a better suggestion comes up).
>
> Fair enough, Discovered works for clusters as well, the webapp has
> been pushed out the all of the machines on the cluster and is in
> discovered state...ie everyone knows about it.
>
> This gives me the side thought of a corridinated cluster
> deployment...where there is corridination of the lifecycles, ie, ALL
> machines on cluster have to be in DISCOVERED before they are told to
> advance to next phase, and so on and so forth, ensuring that the
> webapps transition from phase to phase in lockstep.
>
>> I'm cool with these being meta states that hide the
>> nuts and bolts below. But we do need to know
>> exactly what the nuts and bolts are.
>>
>> I think the meta states we have are:
>>
>> DISCOVERED : constructed, !validated !linked !configured
>>
>> DEPLOYED: constructed, validated, linked, configured, !started
>>
>> UNAVAILABLE: started, Unavailable(in JEE sense)
>>
>> STAGED: started, !active
>>
>> LIVE: started, active
>
> joakim has some pretty graphics for this he should bust out here
>
>
>> For most webapps, STAGED will automatically flow through to LIVE
>> (ie if there is no other switch needed to direct traffic to it).
>> Or it may need even need a manual step in some environments.
>
> agreed, I think the gist behind joakim's efforts are rooted in the
> 'one size does not fit all' approach to webapp deployment. So instead
> of codifying it strictly in interfaces you extend, you make it more
> generally extendable such that the default deployer for jetty is
> functionally equivalent in lifecycle as to how it is now, but in other
> scenarios where the user needs a staged environment, or the ability to
> add in a webapp registry service, or even the lockstep cluster stuff I
> mentioned above you have the ability to wire up the workflow as needed
> calling out the bits of functionality as needed.
>
> at least that is how I see it
>
>> UNAVAILABLE: might transit to STAGED if the unavailable exception
>> had a timeout and on a subsequent attempt to unavailable status
>> was clear. We might need to extend jetty with some callback for
>> this occurrence?
>
> I see it that in the normal jetty deployer sense, STAGED is not even a
> factor as it is not a part of the default deployer workflow...just
> that it will be a very popular component (maybe even developed as a
> separate module that they activate and wire in via the deployer
> workflow configuration).
>
> I could see users like google app engine tie into this, create a
> custom deployment workflow and bundle it up as its own maven artifact,
> drop it into lib, drop in a jetty-mydeployment.xml file and good to
> go.
>
> Shoot, that would make it really easy to make an ascii image of a
> dinosaur that is wired to print to console when a webapp
> deploys...awesome test case! :)
>
> cheers,
> jesse
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>