Here it is the one that describes why we choose to use AWS Elastic Beanstalk and Heroku and stopped trying with Google App Engine. César.
-------- Forwarded Message -------- From: Martin Grigorov <[email protected]> To: Cesar Lugo <[email protected]> Cc: Dan Haywood <[email protected]> Subject: Re: Error when I compile the project in the google cloud Date: Tue, 10 May 2016 21:18:39 +0200 Hello César, Please see inline. On Tue, May 10, 2016 at 6:24 PM, Cesar Lugo <[email protected]> wrote: Hello Martin. I am César Lugo, R&D Director of the company that is having this issue on Google Cloud with Apache ISIS. I see your kind response below, and also that you have tried keeping Wicket libraries compatible with Goggle App Engine in the past, with no success, due to certain limitations GAE imposes to the use of some functions of Java. If possible, I would like to ask you some guidance, to know in your experience, which route of action would you suggest: a) Try to overcome those limitations to make the Apache ISIS apps work in a GAE environment. If so, we would need to hire some services of someone how has the skills to do this, and keep in compatible with future versions of Apache ISIS. If this something you might want to provide us? In your opinion, would this make sense in terms of effort and ongoing compatibility? I haven't personally used GAE for any of the projects I have worked on. In the past (something like 4-5 years ago) some users have tried to deploy Wicket applications to GAE and I've tried to help them by creating https://github.com/wicketstuff/core/tree/master/gae-initializer-parent. This project provides a Wicket library that automatically reconfigures Wicket to be GAE-friendlier. Since then there were no complains about problems with GAE in Wicket mailing lists. The reasons could be that wicketstuff-gae-initializer solves all the problems (doubtful!) or that people don't use Wicket+GAE (likely!). If the issue is only with Webjars usage then as I suggested in my earlier mail we could try to make Wicket-Bootstrap Webjars independant. But I am almost certain that we will hit some other issue after that. E.g. GAE uses Jetty 7.x which implements Servlet API 2.4 - Apache Isis requires Servlet API 3.0.1. Also GAE uses DataNucleus 2.x and Apache Isis uses 4.x. GAE is intentionally designed this way so that it forbids usage of non-scalable features of Java (java.io, threads, AWT/Swing, ...). I know that its Python version is used wildly. Actually they hired Python's creator to work on it. Unfortunately this is not the case with Java (or at least I haven't heard of big success stories). b) Discard GAE and try some other PaaS service. I believe this is what Dan recommends. I see one choice here, AWS Elastic Beanstalk. I couldn’t find any other that would provide automatic scaling, load balancing, failover, no downtime version deployment, monitoring, health management. Any suggestions here? I'd also go with AWS. About an year ago I've worked with Dan on a Isis project deployed at Microsoft Azure. It was a good experience! But the project didn't have high requirements for scalability. We've setup 3 Nginx instances for load balancing and 3 Tomcat instances with the application for failover. The database was a single PostgreSQL instance. I appreciate in advance. Descripción: https://gallery.mailchimp.com/a51de198df6ec3312c8f1a4f7/images/3f5e209c-acbd-4eb7-ab4e-df592f0d74f7.jpg Cesar Lugo Marcos. Director de Investigacion y Desarrollo Tamaulipas #150, Torre "A" Piso 5 Hipódromo Condesa 06100, México D. F. Tel.: (55) 5256.4517; (55) 5286.0283 www.vortech-it.com -----Original Message----- From: Martin Grigorov [mailto:[email protected]] Sent: Sunday, May 8, 2016 2:23 PM To: Dan Haywood Cc: users Subject: Re: Error when I compile the project in the google cloud Hi, The problem is not with the compilation of the project but at runtime during start: at de.agilecoders.wicket.webjars.WicketWebjars.install(WicketWebjars.java:75) at org.apache.isis.viewer.wicket.viewer.IsisWicketApplication.configureWebJars(IsisWicketApplication.java:342) Google AppEngine has many restrictions - the one below, usage of java.io.*, usage of threads, and many more... I've stopped trying to keep Wicket and related libraries runnable on GAE several years ago. GAE is not practical to me. One solution would be to override IsisWicketApplication#configureWebJars() and do nothing in this method. The next step would be to provide plain (Css|JavaScript)ResourceReference for all resources the application uses (e.g. Bootstrap, Bootstrap widgets, etc.). I am aware that Webjars based resources also do not work nicely in OSGi environment, so I'd gladly accept PullRequests/issues for Wicket-Bootstrap [1] components which do not provide an easy way to be overridden to use non-Webjars ResourceReferences. 1. https://github.com/l0rdn1kk0n/wicket-bootstrap/ Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, May 6, 2016 at 12:10 PM, Dan Haywood <[email protected]> wrote: > Hi Arturo, > thanks for reporting this. > > > > @Martin - > any insights on this? I think we want to keep using webjars because > they are convenient, but is there any way to make them compatible with > GAE, do you know? > > Thx > Dan > > > > ---------- Forwarded message ---------- > From: Arturo Ulises Castañeda Estrada <[email protected]> > Date: 5 May 2016 at 16:15 > Subject: Error when I compile the project in the google cloud > To: "[email protected]" <[email protected]> > > > Hi Dan, I'm trying install my app in the google cloud but i get the > next error. > > In my local server I not get this error, Im working with java 7 and MySQL. > > [s~cqnz-web-app/1.392437955031148096].<stdout>: INFO - Application > - [WicketFilter] init: Wicket extensions initializer > > 11:25:15.199 > Uncaught exception from servlet > java.lang.NoClassDefFoundError: java.net.URLStreamHandler is a > restricted class. Please see the Google App Engine developer's guide for more details. > at > com.google.apphosting.runtime.security.shared.stub.java.net.URLStreamH > andler.<clinit>(URLStreamHandler.java) > at > de.agilecoders.wicket.webjars.util.UrlResourceStreamProvider.<init>(Ur > lResourceStreamProvider.java:22) > at > de.agilecoders.wicket.webjars.settings.ResourceStreamProvider $2.newIns > tance(ResourceStreamProvider.java:34) > at > de.agilecoders.wicket.webjars.util.file.WebjarsResourceFinder.<init>(W > ebjarsResourceFinder.java:35) > at > de.agilecoders.wicket.webjars.WicketWebjars.install(WicketWebjars.java > :75) > at > org.apache.isis.viewer.wicket.viewer.IsisWicketApplication.configureWe > bJars(IsisWicketApplication.java:342) > at > org.apache.isis.viewer.wicket.viewer.IsisWicketApplication.init(IsisWi > cketApplication.java:241) at > domainapp.webapp.DomainApplication.init(DomainApplication.java:64) > at > org.apache.wicket.Application.initApplication(Application.java:823) > at > org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:42 > 7) > at > org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:35 > 1) at > org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:5 > 0) > at > org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.jav > a:662) at > org.mortbay.jetty.servlet.Context.startContext(Context.java:140) > at > org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java > :1250) > at > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:5 > 17) at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:5 > 0) > at > com.google.apphosting.runtime.jetty.AppVersionHandlerMap.createHandler > (AppVersionHandlerMap.java:206) > at > com.google.apphosting.runtime.jetty.AppVersionHandlerMap.getHandler(Ap > pVersionHandlerMap.java:179) > at > com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceR > equest(JettyServletEngineAdapter.java:136) > at > com.google.apphosting.runtime.JavaRuntime $RequestRunnable.run(JavaRunt > ime.java:468) > at > com.google.tracing.TraceContext $TraceContextRunnable.runInContext(Trac > eContext.java:439) > at > com.google.tracing.TraceContext$TraceContextRunnable $1.run(TraceContex > t.java:446) at > com.google.tracing.CurrentContext.runInContext(CurrentContext.java:256 > ) > at > com.google.tracing.TraceContext $AbstractTraceContextCallback.runInInhe > ritedContextNoUnref(TraceContext.java:310) > at > com.google.tracing.TraceContext $AbstractTraceContextCallback.runInInhe > ritedContext(TraceContext.java:302) > at > com.google.tracing.TraceContext $TraceContextRunnable.run(TraceContext. > java:443) > at > com.google.apphosting.runtime.ThreadGroupPool $PoolEntry.run(ThreadGrou > pPool.java:235) at java.lang.Thread.run(Thread.java:745) > > >
