[JBoss JIRA] (WFCORE-3090) Make script messages around process restarts consistent
by Marek Kopecký (Jira)
[ https://issues.jboss.org/browse/WFCORE-3090?page=com.atlassian.jira.plugi... ]
Marek Kopecký updated WFCORE-3090:
----------------------------------
Affects Version/s: 8.0.0.Beta5
> Make script messages around process restarts consistent
> -------------------------------------------------------
>
> Key: WFCORE-3090
> URL: https://issues.jboss.org/browse/WFCORE-3090
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 8.0.0.Beta5
> Reporter: Brian Stansberry
> Priority: Minor
>
> The message we output when a process is restarted is inconsistent:
> standalone.sh "Restarting application server..."
> domain.sh "Restarting JBoss..."
> standalone.ps1 "Restarting application server..." (from common.ps1)
> domain.ps1 "Restarting application server..." (from common.ps1)
> standalone.bat nothing
> domain.bat nothing
> Problems:
> 1) domain.ps1 is inaccurate as it's not just an application server being restarted
> 2) The bat files are inconsistent with the others
> 3) domain.sh's "Restarting JBoss..." is a bit vague and is odd theoretically given that WildFly Core is meant to be usable for all sorts of things that may not be regarded as "JBoss".
> Perhaps just KISS "Restarting..." in all cases? If we want to keep "application server" for the standalone.xxx cases then common.ps1's function will need to have a param added, and then we need to decide a meaningful value for that param (empty text being a valid choice.)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-3307) Parameters passed to standalone.sh are not printed on startup
by Marek Kopecký (Jira)
[ https://issues.jboss.org/browse/WFCORE-3307?page=com.atlassian.jira.plugi... ]
Marek Kopecký updated WFCORE-3307:
----------------------------------
Affects Version/s: 8.0.0.Beta5
> Parameters passed to standalone.sh are not printed on startup
> -------------------------------------------------------------
>
> Key: WFCORE-3307
> URL: https://issues.jboss.org/browse/WFCORE-3307
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Scripts
> Affects Versions: 3.0.3.Final, 8.0.0.Beta5
> Environment: linux / windows
> Reporter: jamie smith
> Assignee: James Perkins
> Priority: Minor
>
> Parameters passed to standalone.sh should also be printed on startup (like JAVA_OPTS).
> Actually I think something like the output of `ps aux | grep "org.jboss.as.standalone"` should also be printed, when jboss starts.
> Not printing them causes confusion between what is printed and what is actually applied.
> If for example someone runs this: `standalone.sh -Djboss.socket.binding.port-offset=100` and at the same time `-Djboss.socket.binding.port-offset=0` exists in JAVA_OPTS, then the latter will be printed but the first will be used.
> Someone might argue about setting only JAVA_OPTS before running standalone.sh.
> The reason I avoid setting JAVA_OPTS is that if I set them before running standalone.sh, then the default Wildfly opts (-Djava.net.preferIPv4Stack=true" -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true") are never used, which causes other problems. This could be a bug byitself, but for now I consider it as expected behaviour.
> So the most clean approach that I see for setting options in a single place (both with -D and custom flags (e.g. -b)) is appending them as params to standalone.sh (e.g. inside a wrapper script myapp-run.sh).
> It should be possible however to be able to see them being printed somewhere.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-2925) Separate heap settings in standalone.conf and domain.conf from rest of JAVA_OPTS
by Marek Kopecký (Jira)
[ https://issues.jboss.org/browse/WFCORE-2925?page=com.atlassian.jira.plugi... ]
Marek Kopecký updated WFCORE-2925:
----------------------------------
Affects Version/s: 8.0.0.Beta5
> Separate heap settings in standalone.conf and domain.conf from rest of JAVA_OPTS
> --------------------------------------------------------------------------------
>
> Key: WFCORE-2925
> URL: https://issues.jboss.org/browse/WFCORE-2925
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Scripts
> Affects Versions: 8.0.0.Beta5
> Reporter: Brian Stansberry
> Assignee: James Perkins
> Priority: Major
>
> Let's do this:
> {code}
> if [ "x$JBOSS_JAVA_SIZING" = "x" ]; then
> JBOSS_JAVA_SIZING="-Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m"
> fi
> if [ "x$JAVA_OPTS" = "x" ]; then
> JAVA_OPTS="$JBOSS_JAVA_SIZING -Djava.net.preferIPv4Stack=true"
> JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
> else
> echo "JAVA_OPTS already set in environment; overriding default settings with values: $JAVA_OPTS"
> fi
> {code}
> That will allow users to easily control memory sizing by setting that specific env var externally while still relying on our defaults for all the other fussy stuff in JAVA_OPTS.
> The JBOSS_JAVA_SIZING name was 20 secs of thought on my part.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-9577) Upgrade procrun to latest version
by Marek Kopecký (Jira)
[ https://issues.jboss.org/browse/WFLY-9577?page=com.atlassian.jira.plugin.... ]
Marek Kopecký updated WFLY-9577:
--------------------------------
Affects Version/s: 15.0.0.Final
> Upgrade procrun to latest version
> ---------------------------------
>
> Key: WFLY-9577
> URL: https://issues.jboss.org/browse/WFLY-9577
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 10.1.0.Final, 11.0.0.Final, 15.0.0.Final
> Environment: Windows 10, Windows Server 2012 R2
> Reporter: Markus Stier
> Assignee: Tomaz Cerar
> Priority: Major
>
> I've installed Wildflay as a Windows Service using the provided scripts in <Root>\docs\contrib\scripts\service. When stopping the windows service with
> {code}
> net stop <servicename>
> {code}
> the service terminates with an application error 1000.
> {code}
> Name der fehlerhaften Anwendung: wildfly-service.exe, Version: 1.0.15.0, Zeitstempel: 0x51543b9d
> Name des fehlerhaften Moduls: ntdll.dll, Version: 6.3.9600.18821, Zeitstempel: 0x59ba86db
> Ausnahmecode: 0xc0000005
> Fehleroffset: 0x00000000000356a0
> ID des fehlerhaften Prozesses: 0x608
> Startzeit der fehlerhaften Anwendung: 0x01d3637dd37fa9c8
> Pfad der fehlerhaften Anwendung: ....\wildfly-service.exe
> Pfad des fehlerhaften Moduls: C:\Windows\SYSTEM32\ntdll.dll
> Berichtskennung: ee6df2e2-d0eb-11e7-80e2-00505698739a
> {code}
> This is a known bug in the Apache Commons Daemon Service Runner version which is used in the wildfly distribution. See https://issues.apache.org/jira/browse/DAEMON-336
> The bug is fixed in version 1.1.x. Please update the Daemon Service to this version.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-2592) wildfly-service.exe and jbosspass wrong with # inside
by Marek Kopecký (Jira)
[ https://issues.jboss.org/browse/WFCORE-2592?page=com.atlassian.jira.plugi... ]
Marek Kopecký updated WFCORE-2592:
----------------------------------
Affects Version/s: 8.0.0.Beta5
> wildfly-service.exe and jbosspass wrong with # inside
> -----------------------------------------------------
>
> Key: WFCORE-2592
> URL: https://issues.jboss.org/browse/WFCORE-2592
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 8.0.0.Beta5
> Reporter: Seb Dk
> Priority: Major
>
> Hi there,
>
> I am installing wildfy 10.1.0 as service on a win 20012 server.
> It is working but I cannot stop the service.
> I figured out where the problem is coming from.
>
> When I installe Wildly as a service, I run the following command:
> E:\Products\wildfly-10.1.0.Final\bin\service>service.bat install /serviceuser .\JBoss /servicepass my#pass /controller localhost:9991 /jbossuser myuser /jbosspass *my#pass*
>
> But I can see whe I am trying to stop the service, the command running is:
> E:\Products\wildfly-10.1.0.Final\bin\jboss-cli.bat --controller=localhost:9991 --connect --user=myuser --password=*my" "pass* --command=:shutdown
>
> Any workaround?
>
> Thanks,
>
> S.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-8209) JAX-RS Executes resource method even when input validation fails
by Marek Kopecký (Jira)
[ https://issues.jboss.org/browse/WFLY-8209?page=com.atlassian.jira.plugin.... ]
Marek Kopecký commented on WFLY-8209:
-------------------------------------
[~ron_sigal]: I check jaxrs/jaxrs-cdi project in [swarm repo|https://github.com/jhovell/wildfly-swarm-examples/tree/jaxrs-validation]. I copied classes to new maven project just with resteasy-jaxrs and cdi-api dependencies (I don't use lombock). I don't see this issue on WF10, WF10.1 and WF15, application works as expected (stderr logs on server, reasonable curl responses). There is no response for previous [~rsearls]'s comment for ~2 years. Can you please close this jira? [~jhovell] can reopen this jira with reproducer if [~jhovell] still see this issue.
> JAX-RS Executes resource method even when input validation fails
> ----------------------------------------------------------------
>
> Key: WFLY-8209
> URL: https://issues.jboss.org/browse/WFLY-8209
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 10.1.0.Final
> Reporter: John Hovell
> Assignee: Alessio Soldano
> Priority: Major
>
> I have created an example which is actually a fork of the Wildfly Swarm repo. I could re-create the example:
> https://github.com/jhovell/wildfly-swarm-examples/tree/jaxrs-validation (project in subfolder jaxrs/jaxrs-cdi). The tip of this branch shows it is working in WF 10.0. The commit earlier shows it broken in WF 10.1.
> If a JAX-RS resource is defined as an interface with an implementation that doesn't have a single arg constructor, in WF 10.0 you had to work around the issue in a roundabout way by extending the Application class, using the BeanManager to get the actual bean (not the proxy) and register it with JAX-RS. This seemed to be the only solution as even if you made a bean with a @Produces method on a managed bean, Resteasy still wouldn't know how to construct the bean. You get a fairly generic error that Resteasy can't find a constructor for the implementation (not the interface). See error below.
> Despite being roundabout, this worked. In WF 10.1 the behavior is very surprising in that it executes the resource method even though input validation failed, and then it returns a 400 with a validation message (as expected) but with the nasty side effect that the resource method was executed (and it may have crashed due to null pointers, in which case the user gets 500 instead of 400).
> [pre]
> 2017-02-22 19:26:08,213 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 5) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./: java.lang.RuntimeException: RESTEASY003190: Could not find constructor for class: org.wildfly.swarm.examples.jaxrs.cdi.api.EmployeeController
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.RuntimeException: RESTEASY003190: Could not find constructor for class: org.wildfly.swarm.examples.jaxrs.cdi.api.EmployeeController
> at org.jboss.resteasy.spi.metadata.ResourceBuilder.constructor(ResourceBuilder.java:692)
> at org.jboss.resteasy.plugins.server.resourcefactory.POJOResourceFactory.registered(POJOResourceFactory.java:42)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:208)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:194)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:180)
> [pre]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-7371) JAXRS endpoint - CDI injection to constructor doesn't work
by Marek Kopecký (Jira)
[ https://issues.jboss.org/browse/WFLY-7371?page=com.atlassian.jira.plugin.... ]
Marek Kopecký commented on WFLY-7371:
-------------------------------------
[~ron_sigal]: JBEAP-6604 and RESTEASY-1538 clones of this jira were rejected. Can you close this jira as well?
> JAXRS endpoint - CDI injection to constructor doesn't work
> ----------------------------------------------------------
>
> Key: WFLY-7371
> URL: https://issues.jboss.org/browse/WFLY-7371
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, REST
> Affects Versions: 10.1.0.Final
> Reporter: Tomas Remes
> Assignee: Ron Sigal
> Priority: Major
>
> Deploying app with following JAXRS endpoint
> {code}
> @Path("/test")
> public class MyTimeResource {
> private final LocalDateTime dateTime;
> @Inject
> public MyTimeResource(LocalDateTime dateTime){
> this.dateTime = dateTime;
> };
> }
> {code}
> is failing with following stack trace:
> {noformat}
> Caused by: java.lang.RuntimeException: RESTEASY003190: Could not find constructor for class: org.example.microprofile.MyTimeResource
> at org.jboss.resteasy.spi.metadata.ResourceBuilder.constructor(ResourceBuilder.java:692)
> at org.jboss.resteasy.plugins.server.resourcefactory.POJOResourceFactory.registered(POJOResourceFactory.java:42)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:208)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:194)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:180)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:157)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:76)
> at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:409)
> at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:250)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:250)
> at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:133)
> at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:546)
> at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:517)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:559)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> ... 6 more
> {noformat}
> Note that app contains beans.xml so the JAXRS resource should be really managed by CDI.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-8064) Dependecy Injection not working
by Marek Kopecký (Jira)
[ https://issues.jboss.org/browse/WFLY-8064?page=com.atlassian.jira.plugin.... ]
Marek Kopecký commented on WFLY-8064:
-------------------------------------
[~ron_sigal]: No response for 2 years. Can you close this jira? [~gprade] can reopen this jira with reproducer if [~gprade] still see this issue ...
> Dependecy Injection not working
> -------------------------------
>
> Key: WFLY-8064
> URL: https://issues.jboss.org/browse/WFLY-8064
> Project: WildFly
> Issue Type: Release
> Components: CDI / Weld, REST
> Affects Versions: 10.0.0.Final
> Environment: Windows 2012 R2
> Reporter: Pradeep Ganapathy
> Assignee: Alessio Soldano
> Priority: Major
>
> All injected parameters after post construct are null. Jboss cant able to detect inject paramaters. Both dao and testDescription parameters are null. As a result null pointer exception
> RestEasy versions(All) ----> 3.0.14.Final.
> ApplicationScoped
> public class TestImpl implements ITest
> {
>
> @Inject
> private ITestDAO dao;
> public TestImpl setTestDAO(ITestDAO dao)
> {
> this.dao = dao;
> return this;
> }
> @Inject
> private TestDescription testDescription;
> public TestImpl setTestDescription(TestDescription testDescription)
> {
> this.testDescription = testDescription;
> return this;
> }
> }
> Error Logs:
> 2017-02-09 13:11:22,256 ERROR [io.undertow.request] (default task-128) UT005023: Exception handling request to( My EndPoint): org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> Caused by: java.lang.NullPointerException
> at ServiceRegistryImpl.lookup(ServiceRegistryImpl.java:142)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 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.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
> ... 35 more
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months