web-servers / noe-core Goto Github PK

There are occurrences of <url>http://... in our pom. Please, fix it...

When unzip is not available on machine, Ant is used to unzip a file. This method however won't preserve symlinks and filesystem permissions which is crucial for httpd for example. Ant has to be either:

• Removed and unzip has to be listed as a dependency for noe-core
• Replaced by a method/dependency which knows how to handle symlinks

PR #48 provided workspace and httpd abstraction, which is currently untested. We need to code up integration tests for it as well.

Migrating the integration testsuite is WIP.

Java class [1] takes into consideration runtime Java information, but when SERVER_JAVA_HOME is set, we want to take into consideration Java version of SERVER_JAVA_HOME (for testing purposes).

The solution would be to execute SERVER_JAVA_HOME/bin/java -version and parse all necessary properties from there.

CC @mmadzin @rusak5

[1] https://github.com/web-servers/noe-core/blob/master/core/src/main/groovy/noe/common/utils/Java.groovy

@rusak5 If possible, please drop a line or two into the readme on how to run Noe on one java, and servers on another one.

Noe Core is compilable with JDK 8 and lower. We need to change it to 8+ (i.e. 11+)

Location: https://github.com/web-servers/noe-core/blob/master/core/src/main/groovy/noe/server/ServerAbstract.groovy#L296

If file is not ending with war, deployment fails telling user that source deployment file doesn't exist.

xcopy is limited by path length and this constantly causes issues in test environment. robocopy should be available in every Windows Server version we are currently using for testing.

Destroy method is not implemented for ApacheDS workspace hence destroy from abstract method is call and that method removes all servers, not only ApacheDS server.

First project structure

Do we still care about JDK6 and JDK7 these days? Would it be problem to ditch support for it and move to the JDK8+ only?

I can provide some MR if this is a welcomed change.

Seems that TomcatConfigurator's function httpsConnector generates invalid configuration:

e.g.
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" secure="true" scheme="https" SSLEnabled="true" keystoreFile="/tmp/ssl/self_signed/server.jks" keystorePass="changeit" clientAuth="false"/> <Connector redirectPort="8443"/>

which results in:
SEVERE [main] org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to initialize component [Connector[HTTP/1.1-auto-1]] org.apache.catalina.LifecycleException: Protocol handler initialization failed at org.apache.catalina.connector.Connector.initInternal(Connector.java:983) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:533) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1057) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.startup.Catalina.load(Catalina.java:584) at org.apache.catalina.startup.Catalina.start(Catalina.java:621) 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.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474) Caused by: java.lang.IllegalArgumentException: port out of range:-1 at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143) at java.net.InetSocketAddress.<init>(InetSocketAddress.java:188) at org.apache.tomcat.util.net.NioEndpoint.initServerSocket(NioEndpoint.java:228) at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:212) at org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1141) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1154) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:575) at org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:74) at org.apache.catalina.connector.Connector.initInternal(Connector.java:980) ... 13 more

Source code:
TomcatConfigurator configurator = new TomcatConfigurator(tomcat)

SecureHttpConnectorTomcat conn = new SecureHttpConnectorTomcat()
    .setPort(tomcat.getMainHttpsPort())
    .setScheme("https")
    .setSecure(true)
    .setProtocol(protocol)
    .setKeystoreFile(tomcat.keystorePath)
    .setKeystorePass(tomcat.sslKeystorePassword)

configurator.httpsConnector(conn)

I see OOM error on Windows intermittently:

org.jboss.qa.startstop.standalone.StartWithServerStateOptionIT.startModeAdminOnlyTest  Time elapsed: 415.349 s  <<< ERROR!
java.lang.OutOfMemoryError: Java heap space
	at java.base/java.util.HashMap.resize(HashMap.java:700)
	at java.base/java.util.HashMap.putVal(HashMap.java:625)
	at java.base/java.util.HashMap.putMapEntries(HashMap.java:511)
	at java.base/java.util.HashMap.<init>(HashMap.java:486)
	at noe.common.newcmd.ListProcessData.put(ListProcessData.java:407)
	at noe.common.newcmd.ListProcessData.put(ListProcessData.java:86)
	at noe.common.newcmd.ListProcessData.putAll(ListProcessData.java:97)
	at noe.common.newcmd.ListProcessData.filterBy(ListProcessData.java:258)
	at noe.common.newcmd.ListProcessData.filterBy(ListProcessData.java:197)
	at noe.common.newcmd.ListProcess.listProcessTree(ListProcess.java:204)
	at noe.common.newcmd.ListProcess$listProcessTree$0.call(Unknown Source)
	at noe.common.utils.Cmd.destroyProcessWithTree(Cmd.groovy:579)
	at jdk.internal.reflect.GeneratedMethodAccessor187.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
	at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite$StaticMetaMethodSiteNoUnwrapNoCoerce.invoke(StaticMetaMethodSite.java:149)
	at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.callStatic(StaticMetaMethodSite.java:100)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:231)
	at noe.common.utils.Cmd.destroyProcess(Cmd.groovy:573)
	at noe.common.utils.Cmd$destroyProcess$5.call(Unknown Source)
	at noe.server.ServerAbstract.kill(ServerAbstract.groovy:189)
	at noe.server.ServerAbstract$kill$3.call(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
	at noe.server.ServerController$_killAll_closure4.doCall(ServerController.groovy:93)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)

The current project description is:
Library for instalaltion and managing

There is an issue with return variable 'output' from Cmd.executeCommandConsumeStreams which doesn't hold the whole output if it is longer than 1024 signs. 'Cmd.
executeCommandRedirectIO' is not affected by this issue and should be used instead of executeCommandConsumeStreams if longer outputs are expected.

CC @Karm << "please provide perms for me for the upstream Jenkins instance as we talked before"

When adding tests for PR #20, I realized some tests are abundant. We need to:

• Analyze which tests are redundant
• Remove reduntant integration tests
• Investigate why Solaris 10 tests take 5x time than Solaris 11 tests We have stopped testing on Sol 10.

... the reason is WFCORE-3771 fix .

Tomcat 9 supports both old and new TLS connector notations in server.xml Tomcat 10, however, will not support the old notation, AFAIK, and will require an explicit <SSLHostConfig>, i.e. something like:

    <Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol"
               maxThreads="150" SSLEnabled="true" >
        <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
        <SSLHostConfig>
            <Certificate certificateKeyFile="conf/localhost-rsa-key.pem"
                         certificateFile="conf/localhost-rsa-cert.pem"
                         certificateChainFile="conf/localhost-rsa-chain.pem"
                         type="RSA" />
        </SSLHostConfig>
    </Connector>

Noe Core does not support this style of config as of yet.

Library.groovy needs to be broken up into logical pieces; every new piece of code that gets into it gets lost, and is forgotten quickly by all but the author.

There are multiple places (e.g. JwsNameHelper and PlatformSuffixHelper) where we try to determine what is the name of the underlying OS. This should be a function of a separate class, possibly the platform class. This code is then duplicated and fragile. Should be an easy-ish refactoring target.