问题标签 [gretty]

我不知道为什么我的 gretty 需要很长时间才能运行 appStart 任务。任何人都知道为什么它会在“appStart”步骤停止，我需要等待大约 30 分钟才能继续下一步...

它是在后台处理某事，还是只是在等待某事？

它总是运行到 :appStart 步骤，然后在继续下一行之前停止。是因为没有 spring webapplicationinitializer 造成的吗？

任何人都可以指导我如何确定根本原因或解决问题的解决方案？

我正在使用 gretty 1.4.0

谢谢

更新： 我在运行应用程序之前将这些添加到我的 eclipse jvm 参数中，它向我表明它确实在做某事。

根据我的最新观察，它正在尝试扫描

奇怪的是，这最后一行扫描文件大约每秒生成一次，显示的文件列表完全一样……

所有扫描的行都显示为红色（我认为这意味着它无法扫描？）因此，它将继续向红线发送垃圾邮件 30 分钟，然后再继续..

任何想法 ？

项目： Gradle 网络项目

IDE：日食

JAVA 版本：

构建工具： Gradle

网络服务器：码头 9.4.20.v20190813

目前 build.gradle 中的 gretty 配置如下，

我有两点要确认：

1）我知道jetty9将使用jetty 9.2.22.v20170606，甚至jetty9.4将使用9.4.6.v20170531，我确认从eclipse运行Web应用程序。引用自https://stackoverflow.com/a/49676985/11733763

由于我们将码头服务器升级到 9.4.20.v20190813，因此我需要在我的开发环境中使用码头 9.4.20.v20190813。这怎么可能实现？

2) 我最近将Jersey 库升级到 2.29.1，将 Jackson 库升级到 2.10.0。

泽西库

杰克逊库

当我从 Eclipse 运行 Web 应用程序时，我遇到以下异常

堆栈跟踪

如何解决这个问题？

将项目升级到gradle5.0。码头不再启动。我正在使用 org.gretty 3.0.1 版本。

从我的 build.gradle：

错误是：

是否可以在Docker Gradle容器中运行Gretty项目？

通常 Gretty 任务tomcatRun会启动 Tomcat 应用程序服务器，您可以在http://localhost:8080/app-name浏览应用程序。使用 Docker Gradle 映像，任务成功启动，但容器在此之后立即终止。

重现问题的步骤：

1. 安装 Docker。
2. 克隆https://github.com/haba713/hello_gretty。
3. cd hello_gretty
4. 安装 Gradle 包装器： docker run --rm -u gradle -v "$PWD":/home/gradle/project -w /home/gradle/project gradle gradle wrapper
5. 运行任务tomcatRun：./gradlew tomcatRun
6. 浏览http://localhost:8080/hello_gretty。
7. 在终端中按回车键终止任务。
8. tomcatRun使用 Gradle Docker 映像 运行任务：docker run --rm -u gradle -p 8080:8080 -v "$PWD":/home/gradle/project -w /home/gradle/project gradle gradle tomcatRun
9. 任务tomcatRun已启动（需要一些时间），但由于某种原因，容器在此之后立即终止。也许任务在没有按任何键的情况下完成了。

我还创建了一个关于该问题的Docker问题。

我正在尝试升级一些在 Gradle中使用Jetty 插件的旧代码。我想将 Gradle 版本升级到 Gradle v3.5 之后，但 Gradle v4.0 及更高版本已删除 Jetty 插件。不幸的是，我们现在需要使用Gretty。

我正在使用 IntelliJ。我对较新的 Gretty 插件的问题是：

• 命令行上指定的 JVM Args 和 System 属性必须手动放入 Gretty 配置中。

• 至少在 IntelliJ 中，我可以使用 Jetty 插件进行开箱即用的调试，但需要运行两个执行，包括应用程序和远程，并使用不同的 Gradle 任务与 Gretty 进行调试（例如 jettyRunDebug）。

  Gretty 的替代品有哪些？任何可以替代旧 Jetty 插件的东西。

我正在尝试完成“构建 Java Web 应用程序”Gradle 指南（kotlin dsl），但 gradle 在构建时会引发异常。我非常感谢任何帮助使本指南生效。我正在使用 gradle 6.2.2。我已经克隆了 gradle / guides 并尝试在那里构建示例，结果相同。

settings.gradle.kts

构建.gradle.kts

例外

运行良好的 GRADLE 构建，我看不到 gradle 配置的任何更改，最近开始出现错误

无法为 org.gradle.api.tasks.bundling.Zip 类型的任务“：archiveProduct”设置未知属性“archiveBaseName”。

解决方案是什么？使用 Gretty，如果有用的话。

我正在使用以下简单的 build.gradle 项目模板：

并使用指定的版本产生以下问题：

gradlew appRunDebug 拾取 JAVA_TOOL_OPTIONS：-Duser.language=en 在地址监听传输 dt_socket：5005 10:45:40.594 [main] DEBUG org.akhikhl.gretty.ServiceProtocol - ServiceProtocol.send(61607, init 61611) 线程中的异常“ main" java.net.ConnectException：连接超时：在 java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79) 在 java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl) 的 java.net.DualStackPlainSocketImpl.connect0(Native Method) 连接.java:350) 在 java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) 在 java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) 在 java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)在 java.net。SocksSocketImpl.connect(SocksSocketImpl.java:392) 在 java.net.Socket.connect(Socket.java:589) 在 java.net.Socket.connect(Socket.java:538) 在 java.net.Socket.(Socket. java:434) 在 java.net.Socket.(Socket.java:244) 在 org.akhikhl.gretty.ServiceProtocol$Writer.write(ServiceProtocol.groovy:76) 在 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 在sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus .groovy.runtime.callsite.PlainObjectMetaMethodSite.doInvoke(PlainObjectMetaMethodSite.java:43) 在 org.codehaus.groovy.runtime.callsite。PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrap.invoke(PogoMetaMethodSite.java:179) at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.call(PogoMetaMethodSite.java:70) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray. java:47) 在 org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:127) 在 org.akhikhl .gretty.Runner.run(Runner.groovy:118) 在 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 在 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 在 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:43) 在 java.lang.reflect.Method.invoke(Method.java:498) 在 org.codehaus.groovy.runtime.callsite.PlainObjectMetaMethodSite.doInvoke(PlainObjectMetaMethodSite.java:43) 在 org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:190) 在 org .codehaus.groovy.runtime.callsite.PogoMetaMethodSite.call(PogoMetaMethodSite.java:70) 在 org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47) 在 org.codehaus.groovy.runtime.callsite .AbstractCallSite.call(AbstractCallSite.java:115) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:119) at org.akhikhl.gretty.Runner.main(Runner.groovy:53) up JAVA_TOOL_OPTIONS：-Duser.language=en 线程“Thread-65”org.gradle.process.internal 中的异常。ExecException: Process 'command 'C:\Java\jdk1.8.0_191\bin\java.exe'' 在 org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java: 396）在 org.gradle.process.internal.DefaultExecActionFactory.javaexec（DefaultExecActionFactory.java:129）在 org.gradle.api.internal.project 的.DefaultProject.javaexec(DefaultProject.java:1105) 在 org.gradle.api.internal.project.DefaultProject.javaexec(DefaultProject.java:1100) 在 org.gradle.api.Project$javaexec$6.call(Unknown Source) 在org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47) 在 org.codehaus.groovy.runtime。callsite.AbstractCallSite.call(AbstractCallSite.java:115) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:127) at org.akhikhl.gretty.DefaultLauncher.javaExec(DefaultLauncher.groovy:100)在 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 在 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 在 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 在 java.lang.reflect.Method .invoke(Method.java:498) 在 org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:104) 在 groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:326) 在 org.codehaus.groovy。 org.codehaus 的 runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:352)。org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:51) 在 org.codehaus.groovy.runtime.callsite.AbstractCallSite 的 groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:68)。 callCurrent(AbstractCallSite.java:156) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:168) at org.akhikhl.gretty.LauncherBase$_launchThread_closure5.doCall(LauncherBase.groovy:208) at org .akhikhl.gretty.LauncherBase$_launchThread_closure5.doCall(LauncherBase.groovy) 在 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 在 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 在 sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) 在 java.lang.reflect.Method.invoke(Method.java:498) 在 org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:104) 在 groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java :326) at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:264) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1041) at groovy.lang.Closure.call(Closure. java:411) 在 groovy.lang.Closure.call(Closure.java:405) 在 groovy.lang.Closure.run(Closure.java:492) 在 java.lang.Thread.run(Thread.java:748)326）在 org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:264) 在 groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1041) 在 groovy.lang.Closure.call(Closure.java :411) 在 groovy.lang.Closure.call(Closure.java:405) 在 groovy.lang.Closure.run(Closure.java:492) 在 java.lang.Thread.run(Thread.java:748)326）在 org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:264) 在 groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1041) 在 groovy.lang.Closure.call(Closure.java :411) 在 groovy.lang.Closure.call(Closure.java:405) 在 groovy.lang.Closure.run(Closure.java:492) 在 java.lang.Thread.run(Thread.java:748)

设置 gretty 插件版本 3.0.1 后，脚本可以正常工作。知道为什么脚本不兼容吗？

我正在尝试使用 Gradle 的 gretty 插件运行 Spring MVC 应用程序（JVM 版本是 14）要部署应用程序我使用tomcatRun任务（tomcat 版本是 8.5.49）。

如果我使用一些预览功能（例如java.lang.String#formatted method），我必须在任务中添加enable-preview标志compileJava：

但是，如果build.gradle包含此类更改，则会出现问题，并且日志中会出现以下消息：

INFO: No Spring WebApplicationInitializer types detected on classpath 因此，所有应用程序端点都不可用。

如果使用jettyRun任务，则会引发以下异常：

是否可以通过 gretty 插件使用预览功能？

我正在尝试在 Eclipse 上使用 jersey 构建我的第一个 REST API。这是我的build.gradle：

当我使用gradle jettyStartorgradle jettyRunWar时，出现以下错误：

FAILURE：构建失败并出现异常。

• 出了什么问题：任务“：jettyStart”执行失败。

无法解析配置“：grettyRunnerJetty94”的所有文件。找不到 org.gretty:gretty-runner-jetty94:3.0.3。要求：项目：

我也尝试了 gretty 2.1.0 版本，但无法访问。Gradle 版本是 6.5.1