Re: Roadmap / Things-to-do
Francis S Nazareth wrote: Are there plans to have tooling for Geronimo? I would preferrably see an eclipse-based IDE (for J2EE code generation), with a geronimo test environment embedded in eclipse. One of the things being worked on elsewhere is Geronimo support in the Eclipse Web Tools Project which I believe will provide some of this. http://www.eclipse.org/webtools/ -- Jeremy
Re: Roadmap / Things-to-do
Not sure what happened to this the first time ... Jeremy Boynes wrote: Francis S Nazareth wrote: Are there plans to have tooling for Geronimo? I would preferrably see an eclipse-based IDE (for J2EE code generation), with a geronimo test environment embedded in eclipse. One of the things being worked on elsewhere is Geronimo support in the Eclipse Web Tools Project which I believe will provide some of this. http://www.eclipse.org/webtools/ -- Jeremy
Re: Roadmap / Things-to-do
I was thinking the same thing but, for IntelliJ IDEA. ;) Regards, Alan Francis S Nazareth wrote, On 6/1/2005 12:35 AM: Are there plans to have tooling for Geronimo? I would preferrably see an eclipse-based IDE (for J2EE code generation), with a geronimo test environment embedded in eclipse. Regards, Francis - ISL, IBM India [EMAIL PROTECTED] Phone: +91 80 51927737 "Geir Magnusson Jr." <[EMAIL PROTECTED]> 05/31/2005 10:18 PM Please respond to dev To: dev@geronimo.apache.org cc: Subject: Roadmap / Things-to-do It should come as no surprise that as we come to the end of certification, there are a lot of things we'll want to get done, such as usability, performance, new features, etc. Can we start discussing what is on our personal wishlists/roadmaps and get a combined list we maintain here collectively? I think we want to provide better visibility for those that want to contribute... geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: How to build Geronimo offline.
kishor wrote:
Hi all,
I'm new to Geronimo,
I want to build Geronimo offline, Don't want Maven to download jars at build
time,
Can any one tell me where I will get the docs ?
First time through it is much easier to build online to get all the
dependencies. After that:
$ maven -o
If bandwidth is a big problem, you can download a lot of the
dependencies in one go by just trying to build the assembly module:
$ cd modules/assembly
$ maven build:start
and then go back to the root and build offline. A few modules not used
by assembly will not have been downloaded resulting in failures in those
modules. You can build those using
$ maven -Dmodules=${failed_module}
Painful, but a possible workaround to avoid all the snapshot checks.
--
Jeremy
How to build Geronimo offline.
Hi all, I'm new to Geronimo, I want to build Geronimo offline, Don't want Maven to download jars at build time, Can any one tell me where I will get the docs ? regards Kishor http://www.patni.com World-Wide Partnerships. World-Class Solutions. _ This e-mail message may contain proprietary, confidential or legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify us immediately at [EMAIL PROTECTED] and delete this mail. _
Re: Roadmap / Things-to-do
Are there plans to have tooling for Geronimo? I would preferrably see an eclipse-based IDE (for J2EE code generation), with a geronimo test environment embedded in eclipse. Regards, Francis - ISL, IBM India [EMAIL PROTECTED] Phone: +91 80 51927737 "Geir Magnusson Jr." <[EMAIL PROTECTED]> 05/31/2005 10:18 PM Please respond to dev To: dev@geronimo.apache.org cc: Subject: Roadmap / Things-to-do It should come as no surprise that as we come to the end of certification, there are a lot of things we'll want to get done, such as usability, performance, new features, etc. Can we start discussing what is on our personal wishlists/roadmaps and get a combined list we maintain here collectively? I think we want to provide better visibility for those that want to contribute... geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Stable/Unstable/Sandbox
On May 31, 2005, at 5:55 PM, Geir Magnusson Jr. wrote: On May 31, 2005, at 8:10 PM, David Jencks wrote: (reordered) Just going to throw out that I think the only goal we can all agree on is to not regress on certification once we achieve it. I certainly hope we agree on this :-) but hope we can find more to agree on. On May 31, 2005, at 4:40 PM, David Blevins wrote: On Tue, May 31, 2005 at 04:21:21PM -0700, David Blevins wrote: On Tue, May 31, 2005 at 11:50:43AM -0400, Geir Magnusson Jr. wrote: Can we agree that we need to somehow construct the stable, unstable and sandbox codebases? I don't think we have agreed on what is stable and what is unstable. We were having a discussion on the fact that it is now impossible to offer a stable upgrade/patch path for applications. That thread was killed with "PLEASE CAN WE PUT IT ON HOLD UNTIL AFTER CERTIFICATION." Now Jeremy has proposed that we ignore that discussion and begin cementing what we currently have as stable. How is that at all fair? I don't know about fair, but I am finding this discussion nearly as distracting as the previous one that we put on hold. I still don't see what exotic svn tricks might buy us over normal svn usage, and don't want to spend a lot of time thinking about it until we pass all the tests. I still think everyones perspective may change once we are passing all the tests and have fixed the few egregious architectural problems that crept in. I would like to put this discussion on hold until we pass all the tests if that happens, w/o a stable area, we have to put all changes except certification related changes on hold until we pass. right? Not really, I think anything we agree should be in our actual first certified release can be added. For instance I'd like to see Jeremy's configuration and assembly plugins get to a working state and be used for the build. There are a couple of other changes I have in mind that dont affect tests passing but improve the structure or usability. There's at least one patch (servlet start order) I want to apply soon. thanks david jencks geir thanks david jencks -David -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Who wants an M4 release?
David Blevins wrote: On Wed, May 25, 2005 at 11:31:40PM -0700, David Blevins wrote: ...now that I have your attention :) More importantly, who is willing to volunteer to test and give a "works" or "doesn't work" report? Any volunteers? Consider this the signup sheet. We have three so far. Gonna need at least three more people (a dozen would be great) or we'll end up with a broken release like M3. We should be able to handle pretty much any J2EE app at this point. Deploy an app, give a thumbs up or thumbs down. Easy. Any more volunteers? You don't have to be a committer. -David Is it too late for me to volunteer. I'm trying to get my head around Geronimo very much these days and can usually code my way out of holes and diagnose things. Let me know. -Neal
Re: Module restructure
Alan D. Cabrera wrote: I think that Jeremy's point is one part of the discussion. The other is how do we break up Geronimo so that people can mix and match pieces and still get a stable, functioning, product. I was also hoping being able to designate certain modules as stable would assist in the drive to certification by reducing the amount of regression testing needed (although of course we would still need to test everything before we released). Someone might even run some modules through the standalone TCKs ... -- Jeremy
Re: [VOTE] Certification stability
On May 31, 2005, at 7:49 PM, David Blevins wrote: We are having a lot of great discussion which should continue. I do want to make sure we are getting somewhere, so let's all vote that we at least agree on one form of stability; certification. Probably obvious, but one step toward inching our way to some form of agreement on stability. VOTE: Certification status is our primary mark of stability at this time. That doesn't even make sense to me. "Stability" refers to the rate and degree of change of the codebase, not if it passes a test suite. -1 geir Note this is not the multiple choice variety we usually do. Just +1/ +0/-0/-1 the statement above and give your $0.02 on negative votes. -David -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Stable/Unstable/Sandbox
On May 31, 2005, at 8:10 PM, David Jencks wrote: (reordered) Just going to throw out that I think the only goal we can all agree on is to not regress on certification once we achieve it. I certainly hope we agree on this :-) but hope we can find more to agree on. On May 31, 2005, at 4:40 PM, David Blevins wrote: On Tue, May 31, 2005 at 04:21:21PM -0700, David Blevins wrote: On Tue, May 31, 2005 at 11:50:43AM -0400, Geir Magnusson Jr. wrote: Can we agree that we need to somehow construct the stable, unstable and sandbox codebases? I don't think we have agreed on what is stable and what is unstable. We were having a discussion on the fact that it is now impossible to offer a stable upgrade/patch path for applications. That thread was killed with "PLEASE CAN WE PUT IT ON HOLD UNTIL AFTER CERTIFICATION." Now Jeremy has proposed that we ignore that discussion and begin cementing what we currently have as stable. How is that at all fair? I don't know about fair, but I am finding this discussion nearly as distracting as the previous one that we put on hold. I still don't see what exotic svn tricks might buy us over normal svn usage, and don't want to spend a lot of time thinking about it until we pass all the tests. I still think everyones perspective may change once we are passing all the tests and have fixed the few egregious architectural problems that crept in. I would like to put this discussion on hold until we pass all the tests if that happens, w/o a stable area, we have to put all changes except certification related changes on hold until we pass. right? geir thanks david jencks -David -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Stable/Unstable/Sandbox
On May 31, 2005, at 7:40 PM, David Blevins wrote: On Tue, May 31, 2005 at 04:21:21PM -0700, David Blevins wrote: On Tue, May 31, 2005 at 11:50:43AM -0400, Geir Magnusson Jr. wrote: Can we agree that we need to somehow construct the stable, unstable and sandbox codebases? I don't think we have agreed on what is stable and what is unstable. We were having a discussion on the fact that it is now impossible to offer a stable upgrade/patch path for applications. That thread was killed with "PLEASE CAN WE PUT IT ON HOLD UNTIL AFTER CERTIFICATION." Now Jeremy has proposed that we ignore that discussion and begin cementing what we currently have as stable. How is that at all fair? Just going to throw out that I think the only goal we can all agree on is to not regress on certification once we achieve it. I think that's a requirement, certainly in the "stable" tree :) geir -David -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Stable/Unstable/Sandbox
On May 31, 2005, at 7:21 PM, David Blevins wrote: On Tue, May 31, 2005 at 11:50:43AM -0400, Geir Magnusson Jr. wrote: Can we agree that we need to somehow construct the stable, unstable and sandbox codebases? I don't think we have agreed on what is stable and what is unstable. Fair enough - but can we agree that we need the *distinction* and then decide what goes *in*? We were having a discussion on the fact that it is now impossible to offer a stable upgrade/patch path for applications. That thread was killed with "PLEASE CAN WE PUT IT ON HOLD UNTIL AFTER CERTIFICATION." Now Jeremy has proposed that we ignore that discussion and begin cementing what we currently have as stable. How is that at all fair? I think that what Jeremy has proposed actually fixes that, doesn't it? We can have a stable area that we focus on going for cert and then version 1.0, and a unstable area where innovation and change (like the serialization experimentation) can happen - then things that work can be brought to stable, w/o affecting the work for cert and 1.0 geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Stable/Unstable/Sandbox
On 5/31/05, David Jencks <[EMAIL PROTECTED]> wrote:
> >> I don't think we have agreed on what is stable and what is unstable.
> >> We were having a discussion on the fact that it is now impossible to
> >> offer a stable upgrade/patch path for applications. That thread was
> >> killed with "PLEASE CAN WE PUT IT ON HOLD UNTIL AFTER CERTIFICATION."
> >>
> >> Now Jeremy has proposed that we ignore that discussion and begin
> >> cementing what we currently have as stable. How is that at all fair?
> >>
>
> I don't know about fair, but I am finding this discussion nearly as
> distracting as the previous one that we put on hold. I still don't see
> what exotic svn tricks might buy us over normal svn usage, and don't
> want to spend a lot of time thinking about it until we pass all the
> tests. I still think everyones perspective may change once we are
> passing all the tests and have fixed the few egregious architectural
> problems that crept in.
If you're referring to the circular dependency between Geronimo and
OpenEJB, I agree. This needs to be fixed ASAP.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: [VOTE] Certification stability
+1 Cert first. David Blevins wrote: We are having a lot of great discussion which should continue. I do want to make sure we are getting somewhere, so let's all vote that we at least agree on one form of stability; certification. Probably obvious, but one step toward inching our way to some form of agreement on stability. VOTE: Certification status is our primary mark of stability at this time. Note this is not the multiple choice variety we usually do. Just +1/+0/-0/-1 the statement above and give your $0.02 on negative votes. -David
Re: [VOTE] Certification stability
On Tue, May 31, 2005 at 04:49:59PM -0700, David Blevins wrote: > We are having a lot of great discussion which should continue. I do want to > make sure we are getting somewhere, so let's all vote that we at least agree > on one form of stability; certification. Probably obvious, but one step > toward inching our way to some form of agreement on stability. > > VOTE: Certification status is our primary mark of stability at this time. > > Note this is not the multiple choice variety we usually do. Just +1/+0/-0/-1 > the statement above and give your $0.02 on negative votes. > Alright, I'm killing my own vote thread. I agree with David J. I don't know if its appropriate to kill a vote thread even if you started it, but I just want to get some work done. -David
Re: Stable/Unstable/Sandbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Jencks wrote: | | I don't know about fair, but I am finding this discussion nearly as | distracting as the previous one that we put on hold. I still don't see | what exotic svn tricks might buy us over normal svn usage, and don't | want to spend a lot of time thinking about it until we pass all the | tests. I still think everyones perspective may change once we are | passing all the tests and have fixed the few egregious architectural | problems that crept in. | | I would like to put this discussion on hold until we pass all the tests | | thanks | david jencks Agreed. I'm still in favor of 'modification of structure' in the interests of ease of localized maintenance and possible deployment/deliverable options not currently available, but I'd much rather put that on a "TODO" list for after certification than take more time now to discuss it. Very difficult to advocate "certification first" and "restructure thoughts now" when those involved in the certification process would undoubtedly need to be in on the restructure thoughts process. First things first. My .02 Brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCnP38aCoPKRow/gARAuJCAKC6Abi1oUVMJA7Gq9wRAJyUsQo1DgCgprU0 nUtdvbP7y8vvNN4vvQvwVZk= =7+VS -END PGP SIGNATURE-
Re: Stable/Unstable/Sandbox
(reordered) Just going to throw out that I think the only goal we can all agree on is to not regress on certification once we achieve it. I certainly hope we agree on this :-) but hope we can find more to agree on. On May 31, 2005, at 4:40 PM, David Blevins wrote: On Tue, May 31, 2005 at 04:21:21PM -0700, David Blevins wrote: On Tue, May 31, 2005 at 11:50:43AM -0400, Geir Magnusson Jr. wrote: Can we agree that we need to somehow construct the stable, unstable and sandbox codebases? I don't think we have agreed on what is stable and what is unstable. We were having a discussion on the fact that it is now impossible to offer a stable upgrade/patch path for applications. That thread was killed with "PLEASE CAN WE PUT IT ON HOLD UNTIL AFTER CERTIFICATION." Now Jeremy has proposed that we ignore that discussion and begin cementing what we currently have as stable. How is that at all fair? I don't know about fair, but I am finding this discussion nearly as distracting as the previous one that we put on hold. I still don't see what exotic svn tricks might buy us over normal svn usage, and don't want to spend a lot of time thinking about it until we pass all the tests. I still think everyones perspective may change once we are passing all the tests and have fixed the few egregious architectural problems that crept in. I would like to put this discussion on hold until we pass all the tests thanks david jencks -David
Re: [VOTE] Certification stability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Blevins wrote: | We are having a lot of great discussion which should continue. I do want to make sure we are getting somewhere, so let's all vote that we at least agree on one form of stability; certification. Probably obvious, but one step toward inching our way to some form of agreement on stability. | | VOTE: Certification status is our primary mark of stability at this time. | | Note this is not the multiple choice variety we usually do. Just +1/+0/-0/-1 the statement above and give your $0.02 on negative votes. | | -David | | +1 (non-binding) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCnPidaCoPKRow/gARAteXAKDzC+8pT13YgXfQKVqUqbhx8UjongCgwicG GoTnSuuBZCxatUF8fsh6GNw= =ZfpT -END PGP SIGNATURE-
[VOTE] Certification stability
We are having a lot of great discussion which should continue. I do want to make sure we are getting somewhere, so let's all vote that we at least agree on one form of stability; certification. Probably obvious, but one step toward inching our way to some form of agreement on stability. VOTE: Certification status is our primary mark of stability at this time. Note this is not the multiple choice variety we usually do. Just +1/+0/-0/-1 the statement above and give your $0.02 on negative votes. -David
Re: Stable/Unstable/Sandbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Blevins wrote: | | Just going to throw out that I think the only goal we can all agree on is to not regress on certification once we achieve it. | | -David | Combined with not slowing down progress on attaining that certification. :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCnPbfaCoPKRow/gARAotlAKCpKqZNTRBvUz4yJENzXSYgZM6pAACeOXNn /Qaa/eRFdNLRRT0ozT02pDc= =Qex9 -END PGP SIGNATURE-
Re: Stable/Unstable/Sandbox
On Tue, May 31, 2005 at 04:21:21PM -0700, David Blevins wrote: > On Tue, May 31, 2005 at 11:50:43AM -0400, Geir Magnusson Jr. wrote: > > Can we agree that we need to somehow construct the stable, unstable > > and sandbox codebases? > > I don't think we have agreed on what is stable and what is unstable. We were > having a discussion on the fact that it is now impossible to offer a stable > upgrade/patch path for applications. That thread was killed with "PLEASE CAN > WE PUT IT ON HOLD UNTIL AFTER CERTIFICATION." > > Now Jeremy has proposed that we ignore that discussion and begin cementing > what we currently have as stable. How is that at all fair? > Just going to throw out that I think the only goal we can all agree on is to not regress on certification once we achieve it. -David
Re: Stable/Unstable/Sandbox
On Tue, May 31, 2005 at 11:50:43AM -0400, Geir Magnusson Jr. wrote: > Can we agree that we need to somehow construct the stable, unstable > and sandbox codebases? I don't think we have agreed on what is stable and what is unstable. We were having a discussion on the fact that it is now impossible to offer a stable upgrade/patch path for applications. That thread was killed with "PLEASE CAN WE PUT IT ON HOLD UNTIL AFTER CERTIFICATION." Now Jeremy has proposed that we ignore that discussion and begin cementing what we currently have as stable. How is that at all fair? -David
[jira] Assigned: (GERONIMO-650) POJO ws should not need to implement SEI
[ http://issues.apache.org/jira/browse/GERONIMO-650?page=all ] David Blevins reassigned GERONIMO-650: -- Assign To: David Blevins > POJO ws should not need to implement SEI > > > Key: GERONIMO-650 > URL: http://issues.apache.org/jira/browse/GERONIMO-650 > Project: Geronimo > Type: Bug > Components: webservices > Versions: 1.0-M3 > Reporter: David Jencks > Assignee: David Blevins > Fix For: 1.0-M4 > > I have not investigated the code but based on the following stack trace I > doubt we are correctly implementing ewebsvcs-1_1-mr-spec section 5.3.2.2: > The Service Implementation Bean may implement the Service Endpoint Interface > as defined by the JAX-RPC Servlet model. The bean must implement all the > method signatures of the SEI. In addition, a Service Implementation Bean may > be implemented that does not implement the SEI. This additional requirement > provides the same SEI implementation flexibility as provided by EJB service > endpoints. The business methods of the bean must be public and must not be > static. If the Service Implementation Bean does not implement the SEI, the > business methods must not be final. The Service Implementation Bean may > implement other methods in addition to those defined by the SEI, but only > the SEI methods are exposed to the client. > The app has a POJO implementing the same methods as but not extending the SEI. > stacktrace: > 12:01:28,427 INFO [RPCProvider] Tried to invoke method public abstract > java.lang.String foo.FooWs.foo(java.lang.String) throws > java.rmi.RemoteException with arguments java.lang.String. The arguments do > not match the signature. > java.lang.IllegalArgumentException: object is not an instance of declaring > class > 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:324) > at > org.apache.axis.providers.java.RPCProvider.invokeMethod(RPCProvider.java:388) > at > org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:283) > at > org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:323) > at > org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32) > at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) > at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) > at > org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:453) > at > org.apache.geronimo.axis.server.AxisWebServiceContainer.invoke(AxisWebServiceContainer.java:126) > at > org.apache.geronimo.webservices.WebServiceContainerInvoker.service(WebServiceContainerInvoker.java:78) > at > org.apache.geronimo.webservices.POJOWebServiceServlet.service(POJOWebServiceServlet.java:79) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) > at > org.apache.geronimo.jetty.JettyPOJOWebServiceHolder.handle(JettyPOJOWebServiceHolder.java:105) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:832) > at > org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:823) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:473) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:623) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) > at org.mortbay.http.HttpServer.service(HttpServer.java:954) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:814) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:831) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-650) POJO ws should not need to implement SEI
[ http://issues.apache.org/jira/browse/GERONIMO-650?page=all ] David Blevins closed GERONIMO-650: -- Resolution: Fixed Fix Version: 1.0-M4 > POJO ws should not need to implement SEI > > > Key: GERONIMO-650 > URL: http://issues.apache.org/jira/browse/GERONIMO-650 > Project: Geronimo > Type: Bug > Components: webservices > Versions: 1.0-M3 > Reporter: David Jencks > Assignee: David Blevins > Fix For: 1.0-M4 > > I have not investigated the code but based on the following stack trace I > doubt we are correctly implementing ewebsvcs-1_1-mr-spec section 5.3.2.2: > The Service Implementation Bean may implement the Service Endpoint Interface > as defined by the JAX-RPC Servlet model. The bean must implement all the > method signatures of the SEI. In addition, a Service Implementation Bean may > be implemented that does not implement the SEI. This additional requirement > provides the same SEI implementation flexibility as provided by EJB service > endpoints. The business methods of the bean must be public and must not be > static. If the Service Implementation Bean does not implement the SEI, the > business methods must not be final. The Service Implementation Bean may > implement other methods in addition to those defined by the SEI, but only > the SEI methods are exposed to the client. > The app has a POJO implementing the same methods as but not extending the SEI. > stacktrace: > 12:01:28,427 INFO [RPCProvider] Tried to invoke method public abstract > java.lang.String foo.FooWs.foo(java.lang.String) throws > java.rmi.RemoteException with arguments java.lang.String. The arguments do > not match the signature. > java.lang.IllegalArgumentException: object is not an instance of declaring > class > 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:324) > at > org.apache.axis.providers.java.RPCProvider.invokeMethod(RPCProvider.java:388) > at > org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:283) > at > org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:323) > at > org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32) > at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) > at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) > at > org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:453) > at > org.apache.geronimo.axis.server.AxisWebServiceContainer.invoke(AxisWebServiceContainer.java:126) > at > org.apache.geronimo.webservices.WebServiceContainerInvoker.service(WebServiceContainerInvoker.java:78) > at > org.apache.geronimo.webservices.POJOWebServiceServlet.service(POJOWebServiceServlet.java:79) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) > at > org.apache.geronimo.jetty.JettyPOJOWebServiceHolder.handle(JettyPOJOWebServiceHolder.java:105) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:832) > at > org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:823) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:473) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:623) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) > at org.mortbay.http.HttpServer.service(HttpServer.java:954) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:814) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:831) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Stable/Unstable/Sandbox
On May 31, 2005, at 1:37 PM, Bill Stoddard wrote: Geir Magnusson Jr. wrote: Can we agree that we need to somehow construct the stable, unstable and sandbox codebases? If so, can we move on to how? geir Check out the httpd project: http://svn.apache.org/repos/asf/httpd/httpd/ essential features: 'trunk' is 'development' (unstable) reporitory. It is constantly moving forward under loose rules for what can be committed. 'branches' contains the 'stable' code. httpd 2.0.x (and 1.3.x) constantly move forward but under a 'review-then-commit' policy. All code that goes into the stable branch must be reviewed and voted on before it can come into the stable branch. 'tags' contains all the tagged releases http://svn.apache.org/repos/asf/httpd/httpd/branches/ So using this model, one of the geronimo branches could be 1.0.x. When 1.0 is 'done', tag the release and continue on the next 'stable' drop, migrating function out of trunk and into 1.x using whatever process you like (RTC, CTR, votes, whatever). The RTC + vote policy httpd 2.0.x uses may be too restrictive for geronimo 1.0.x, so do whatever makes sense for this project. There will come a day when you want another stable branch of geronimo (presumably forked from trunk). When that day comes, just create a new tree under 'branches', named differently (maybe 2.0.x or 1.2.x, whatever). I know this doesn't really answer the more interesting question about how to structure the repository to support assemblying components into a 'custom' install. I'm not sure that's important here - we should be able to assemble any custom install from parts wherever they are - we can have assemblies in both stable an unstable... The key is that the code in stable remain so. I'm not sure I'm a fan of going to the full degree of "review-then- commit" right now (but probably in the future when we run 70% of the worlds J2EE app server installations ;) but now a "propose then commit" for stable branch might be nice. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Stable/Unstable/Sandbox
Geir Magnusson Jr. wrote: Can we agree that we need to somehow construct the stable, unstable and sandbox codebases? If so, can we move on to how? geir Check out the httpd project: http://svn.apache.org/repos/asf/httpd/httpd/ essential features: 'trunk' is 'development' (unstable) reporitory. It is constantly moving forward under loose rules for what can be committed. 'branches' contains the 'stable' code. httpd 2.0.x (and 1.3.x) constantly move forward but under a 'review-then-commit' policy. All code that goes into the stable branch must be reviewed and voted on before it can come into the stable branch. 'tags' contains all the tagged releases http://svn.apache.org/repos/asf/httpd/httpd/branches/ So using this model, one of the geronimo branches could be 1.0.x. When 1.0 is 'done', tag the release and continue on the next 'stable' drop, migrating function out of trunk and into 1.x using whatever process you like (RTC, CTR, votes, whatever). The RTC + vote policy httpd 2.0.x uses may be too restrictive for geronimo 1.0.x, so do whatever makes sense for this project. There will come a day when you want another stable branch of geronimo (presumably forked from trunk). When that day comes, just create a new tree under 'branches', named differently (maybe 2.0.x or 1.2.x, whatever). I know this doesn't really answer the more interesting question about how to structure the repository to support assemblying components into a 'custom' install. Bill
Re: Roadmap / Things-to-do
I'll start...here are a few... 1) A nice usable, and polished management console. 2) A GUI configuration tool that allows you to add/remove components, where the result is a set of plans with your custom configuration. (No more XML hacking for the newbies out there). 3) True clustering (I don't know the status so this may already is being dealt with) with rolling deployments similar to BEA (i.e. deploy but don't activate until I say I am ready). 4) True hot deploy/undeploy (is this working? or does it need work? I have been somewhat unsuccessful without some form of restart) 5) Sniffable deploy directory. It would be nice to drop EAR/WAR/etc in a directory and have it auto deploy. Jeff Geir Magnusson Jr. wrote: It should come as no surprise that as we come to the end of certification, there are a lot of things we'll want to get done, such as usability, performance, new features, etc. Can we start discussing what is on our personal wishlists/roadmaps and get a combined list we maintain here collectively? I think we want to provide better visibility for those that want to contribute... geir
Roadmap / Things-to-do
It should come as no surprise that as we come to the end of certification, there are a lot of things we'll want to get done, such as usability, performance, new features, etc. Can we start discussing what is on our personal wishlists/roadmaps and get a combined list we maintain here collectively? I think we want to provide better visibility for those that want to contribute... geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Stable/Unstable/Sandbox
Aaron Mulder wrote, On 5/31/2005 12:19 PM: Fine with me, though I'm not sure we really need sandbox -- unstable is unstable, right? Whatever. Are we planning that these locations are for modules, and the kernel and assembly/assemblies will be maintained outside of this structure? What are the concrete scenarios that we will use to evaluate all the proposed "solutions"? Since people are ready to jump into the "how", they must have the "what" readily available. Regards, Alan
Re: Stable/Unstable/Sandbox
I like the sandbox. It's a place where people can goof off w/ experimental stuff and propose significant changes . I tend to think that all non-sandbox stuff as things that the Geronimo community is commited to supporting. Regards, Alan Aaron Mulder wrote, On 5/31/2005 12:19 PM: Fine with me, though I'm not sure we really need sandbox -- unstable is unstable, right? Whatever. Are we planning that these locations are for modules, and the kernel and assembly/assemblies will be maintained outside of this structure? Aaron On Tue, 31 May 2005, Geir Magnusson Jr. wrote: Can we agree that we need to somehow construct the stable, unstable and sandbox codebases? If so, can we move on to how? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Stable/Unstable/Sandbox
On May 31, 2005, at 12:19 PM, Aaron Mulder wrote: Fine with me, though I'm not sure we really need sandbox -- unstable is unstable, right? Whatever. Well, maybe. For example, refactoring $foo is a lot different than adding something new and strange, or dropping in some code for people to decide how to introduce into the mainline, etc. Are we planning that these locations are for modules, and the kernel and assembly/assemblies will be maintained outside of this structure? Good questions :) I think that assemblies should be outside, because there are lots of interesting assemblies that people might want to do that aren't J2EE. For example, a simple Geronimmo server (no API stakc), a simple servlet/jsp stack, etc... geir Aaron On Tue, 31 May 2005, Geir Magnusson Jr. wrote: Can we agree that we need to somehow construct the stable, unstable and sandbox codebases? If so, can we move on to how? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Stable/Unstable/Sandbox
Fine with me, though I'm not sure we really need sandbox -- unstable is unstable, right? Whatever. Are we planning that these locations are for modules, and the kernel and assembly/assemblies will be maintained outside of this structure? Aaron On Tue, 31 May 2005, Geir Magnusson Jr. wrote: > Can we agree that we need to somehow construct the stable, unstable > and sandbox codebases? > > If so, can we move on to how? > > > geir > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > > >
Stable/Unstable/Sandbox
Can we agree that we need to somehow construct the stable, unstable and sandbox codebases? If so, can we move on to how? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
On May 30, 2005, at 10:56 PM, Alan D. Cabrera wrote:
Dain Sundstrom wrote, On 5/30/2005 10:43 PM:
On May 30, 2005, at 4:25 PM, Jeremy Boynes wrote:
The problem we have currently is that there is no continuity
between our releases - the APIs, deployment plans, etc. have all
changed incompatibly between them. This was fine with
milestones; however, when we do a production release users need
to have confidence that things won't break with the next one.
Ah we finally get to the root of what you are talking about. I
believe that if we address this issue directly the technical
structure of the svn tree will be obvious.
I agree, it makes no sense in talking about the how until we iron
out the what.
So lets do that.
Jeremy was proposing distinguishing between "stable" - where the
focus is getting to the next release - and "unstable" - where things
unrelated to linear progress to a release are done.
First - do we agree this is a good thing?
Second - if we do agree, besides the suggestion of separate roots
("stable", "unstable", "downright_wacky" (nee "sandbox")), what other
approaches are there?
Said another way, the technical discussion of the svn tree will
never get anywhere without addressing this core issue first.
I think that Jeremy's point is one part of the discussion. The
other is how do we break up Geronimo so that people can mix and
match pieces and still get a stable, functioning, product.
lets solve this one first. The other follows after that, IMO.
geir
Regards,
Alan
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
Re: Geronimo subprojects?
That is correct. For any standalone technology that is being released outside of J2EE, you need to pass the standalone version of the TCK. The tests are not always the same, as there are some additions and subtractions based on the requirements of how the technology is defined to work outside of J2EE. | | It depends on the specifications the subproject is implementing and if | Sun has a stand-alone tck for the specifications. For example, if it | were the Geronimo 'just a webserver edition' we could certify it for | servlets and jsp because they have standalone tcks, but if it were tx | and jca we could not certify it since there are no standalone tcks for | those specs. Understood. My main question was if there was some sort of 'prohibition' on the use of 'full system' pass/fail statistics for those pieces that do, in fact, have their own tcks. [I don't view this as a roadblock to anything, but a definite plus if each individual piece that was able (due to having and passing their own tcks) could state it passes.] Yes. If you want to know if the servlet part works on it's own, you need to test it on it's own geir
