[JBoss JIRA] Created: (JBAS-8316) Simple command line installer
by Brian Stansberry (JIRA)
Simple command line installer
-----------------------------
Key: JBAS-8316
URL: https://jira.jboss.org/browse/JBAS-8316
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 7.0.0.M1
The AS is going to support two different running modes (see "Standalone Server" vs the rest of the discussion on http://community.jboss.org/docs/DOC-15215) and a flexible configuration for defining the "profile" a server will run. Profiles will not be represented via filesystem directories; rather they will be pure configuration.
The two different running modes will result in slightly different filesystem layouts -- see discussion in http://community.jboss.org/thread/153858.
The upshot of all this is using AS 7 will not be like previous versions where you could download the distribution, unzip, cd to bin/ and type ./run.sh -c some-std-config". Rather, I envision something like this:
1) download, unzip, cd bin
2) ./install.sh --someparamstotellitwhatyouwant
Params to tell it what you want would be whether you're running in standalone mode or full domain, which of a set of pre-packaged profiles you want, maybe some more stuff. From this, installer would create the appropriate filesystem layout, generate a domain.xml+host.mxl or standalone.xml
3) ./run.sh
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (AS7-5560) jboss-cli.bat --debug option not shifted properly
by Cheng Fang (JIRA)
Cheng Fang created AS7-5560:
-------------------------------
Summary: jboss-cli.bat --debug option not shifted properly
Key: AS7-5560
URL: https://issues.jboss.org/browse/AS7-5560
Project: Application Server 7
Issue Type: Feature Request
Components: Scripts
Affects Versions: 7.2.0.Alpha1
Reporter: Cheng Fang
Assignee: Brian Stansberry
Windows only.
After appending debug options to JAVA_OPTS, the original --debug xxxx is not stripped out, and is passed to JBoss Modules, which failed:
{noformat}
C:\jboss-as7\jboss-as-7.2.0.Alpha1-SNAPSHOT\bin>"C:\Program Files\Java\jdk1.6.0_31\bin\java" -XX:+TieredCompilation -XX:
+UseCompressedOops -Dprogram.name=-d -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n "-Dorg.jboss.boot.l
og.file=C:\jboss-as7\jboss-as-7.2.0.Alpha1-SNAPSHOT\standalone\log\boot.log" "-Dlogging.configuration=file:C:\jboss-as7
\jboss-as-7.2.0.Alpha1-SNAPSHOT\standalone/configuration/logging.properties" -jar "C:\jboss-as7\jboss-as-7.2.0.Alpha
1-SNAPSHOT\jboss-modules.jar" -mp "C:\jboss-as7\jboss-as-7.2.0.Alpha1-SNAPSHOT\modules" -jaxpmodule "javax.xml.j
axp-provider" org.jboss.as.standalone -Djboss.home.dir="C:\jboss-as7\jboss-as-7.2.0.Alpha1-SNAPSHOT" -d
Listening for transport dt_socket at address: 8787
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (AS7-5422) Logging configuration DUP should be more deterministic
by James Perkins (JIRA)
James Perkins created AS7-5422:
----------------------------------
Summary: Logging configuration DUP should be more deterministic
Key: AS7-5422
URL: https://issues.jboss.org/browse/AS7-5422
Project: Application Server 7
Issue Type: Feature Request
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
Notes from [~kconner]:
The findConfigFile method does a recursive search of the resource, looking for the configuration files, but there seems to be a couple of problems with this
- the order of the search may be dependent on the platform as VFS seems
to rely on the filesystem order (not classpath) so it may not be
deterministic across platforms.
- any log4j.xml/log4j.properties/jboss-log4j.xml will overwrite the
previously discovered resource, resulting in the last being chosen.
I came across this while debugging some strange behaviour when deploying drools-guvnor.war into EAP 6. What I discovered is that this loop first identified the top most resource (/content/drools-guvnor.war/WEB-INF/classes/log4j.xml) but then overwrote it with an embedded one (/content/drools-guvnor.war/WEB-INF/lib/webdav-servlet-2.0.jar/log4j.xml) but it doesn't appear as if this method has a well defined behaviour.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (JBRULES-3499) MVEL failing on new added packages
by Mauricio Salatino (JIRA)
Mauricio Salatino created JBRULES-3499:
------------------------------------------
Summary: MVEL failing on new added packages
Key: JBRULES-3499
URL: https://issues.jboss.org/browse/JBRULES-3499
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Mauricio Salatino
Assignee: Mark Proctor
Fix For: 5.4.0.Final, 5.5.0.Beta1
Attachments: mvel-issue.zip
In this simple rule:
when
r: Request( amount > 500 )
String( this == r.id ) from requests
For some reason MVEL is failing with the following exception:
Testcase: hello(com.salaboy.mvelissue.MvelTest): Caused an ERROR
unable to invoke method: com.salaboy.mvelissue.Request.getId: target of method is null
java.lang.RuntimeException: unable to invoke method: com.salaboy.mvelissue.Request.getId: target of method is null
at org.mvel2.optimizers.impl.refl.nodes.GetterAccessor.getValue(GetterAccessor.java:66)
When a new set of rules is being added to the kbase and an activation is generated.
I've included a version of the failing rule working with a workaround, but both should work
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (AS7-5556) Authentication failure of AS instance connecting to host controller with different file.encoding
by Darran Lofthouse (JIRA)
Darran Lofthouse created AS7-5556:
-------------------------------------
Summary: Authentication failure of AS instance connecting to host controller with different file.encoding
Key: AS7-5556
URL: https://issues.jboss.org/browse/AS7-5556
Project: Application Server 7
Issue Type: Bug
Components: Domain Management, Security
Affects Versions: 7.1.2.Final (EAP)
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
If a server group is updated to say the following: -
{code}
<server-group name="main-server-group" profile="full">
<jvm name="default">
<heap size="64m" max-size="512m"/>
</jvm>
<socket-binding-group ref="full-sockets"/>
<system-properties>
<property name="file.encoding" value="ISO8859_1" boot-time="true"/>
</system-properties>
</server-group>
{code}
Then when server within this server group attempt to connect back to their host controller the following is logged: -
{code}
[Server:server-one] 15:11:02,069 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: java.util.concurrent.ExecutionException: Operation failed
[Server:server-one] at org.jboss.as.server.ServerStartTask$2$1.load(ServerStartTask.java:179) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
[Server:server-one] at org.jboss.as.server.ServerService.boot(ServerService.java:292) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
[Server:server-one] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:156) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
[Server:server-one] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32]
[Server:server-one] Caused by: java.util.concurrent.ExecutionException: Operation failed
[Server:server-one] at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
[Server:server-one] at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
[Server:server-one] at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$2.get(ServerBootOperationsService.java:107) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
[Server:server-one] at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$2.get(ServerBootOperationsService.java:89) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
[Server:server-one] at org.jboss.as.server.ServerStartTask$2$1.load(ServerStartTask.java:176) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
[Server:server-one] ... 3 more
[Server:server-one] Caused by: java.net.ConnectException: JBAS012174: Could not connect to remote://127.0.0.1:9999. The connection failed
[Server:server-one] at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118) [jboss-as-protocol-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
[Server:server-one] at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:247) [jboss-as-protocol-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
[Server:server-one] at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) [jboss-as-protocol-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
[Server:server-one] at org.jboss.as.server.mgmt.domain.HostControllerConnection.openConnection(HostControllerConnection.java:105) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
[Server:server-one] at org.jboss.as.server.mgmt.domain.HostControllerClient.resolveBootUpdates(HostControllerClient.java:81) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
[Server:server-one] at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$1.run(ServerBootOperationsService.java:69) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_32]
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_32]
[Server:server-one] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32]
[Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
[Server:server-one] Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
[Server:server-one] at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:327) [jboss-remoting-3.2.8.SP1.jar:3.2.8.SP1]
[Server:server-one] at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:226) [jboss-remoting-3.2.8.SP1.jar:3.2.8.SP1]
[Server:server-one] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.6.GA.jar:3.0.6.GA]
[Server:server-one] at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) [xnio-api-3.0.6.GA.jar:3.0.6.GA]
[Server:server-one] at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) [xnio-api-3.0.6.GA.jar:3.0.6.GA]
[Server:server-one] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.6.GA.jar:3.0.6.GA]
[Server:server-one] at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) [xnio-api-3.0.6.GA.jar:3.0.6.GA]
[Server:server-one] at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180) [xnio-api-3.0.6.GA.jar:3.0.6.GA]
[Server:server-one] at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) [xnio-api-3.0.6.GA.jar:3.0.6.GA]
[Server:server-one] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.6.GA.jar:3.0.6.GA]
[Server:server-one] at org.xnio.nio.NioHandle.run(NioHandle.java:90)
[Server:server-one] at org.xnio.nio.WorkerThread.run(WorkerThread.java:187)
[Server:server-one] at ...asynchronous invocation...(Unknown Source)
[Server:server-one] at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270) [jboss-remoting-3.2.8.SP1.jar:3.2.8.SP1]
[Server:server-one] at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251) [jboss-remoting-3.2.8.SP1.jar:3.2.8.SP1]
[Server:server-one] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349) [jboss-remoting-3.2.8.SP1.jar:3.2.8.SP1]
[Server:server-one] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:337) [jboss-remoting-3.2.8.SP1.jar:3.2.8.SP1]
[Server:server-one] at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:74) [jboss-as-protocol-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
[Server:server-one] at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:88) [jboss-as-protocol-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
[Server:server-one] ... 9 more
{code}
A network trace of the communication between the AS instance and it's host controller shows that it is the Digest authentication that is failing and being rejected.
This is most likely one of the following causes: -
1 - The individual password for the AS is passed to it as the process starts - the change in file.encoding could be affecting how this password is read.
2 - A couple of digests are created based on this password, one or both of these could be wrong due to the new encoding - the message itself still claims utf-8.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (JBVFS-183) Cannot discover URLStreamHandler
by Thomas Diesler (JIRA)
Thomas Diesler created JBVFS-183:
------------------------------------
Summary: Cannot discover URLStreamHandler
Key: JBVFS-183
URL: https://issues.jboss.org/browse/JBVFS-183
Project: JBoss VFS
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
Assignee: David Lloyd
Fix For: 3.1.1.GA
In VFS we set java.protocol.handler.pkgs. In Karaf it was reported that URL.class can see the sysprop but cannot load the handler from the defining class loader (i.e. Class.forName(...))
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (JBJCA-884) Integrate EIS test server
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-884:
-------------------------------------
Summary: Integrate EIS test server
Key: JBJCA-884
URL: https://issues.jboss.org/browse/JBJCA-884
Project: IronJacamar
Issue Type: Task
Components: Code Generator
Reporter: Jesper Pedersen
Assignee: Jeff Zhang
The code generator should allow integration of the EIS test server into the generated environment.
A Handler implementation should be generated (same location as the test case), plus the needed changes to either the build.xml or pom.xml file.
{noformat}
Generate a MBean class (Y/Yes/N/No) [Y]:
Integrate EIS test server (Y/Yes/N/No) [N]:
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] Created: (AS7-784) Remove deployment doesn't really remove it
by Stan Silvert (JIRA)
Remove deployment doesn't really remove it
------------------------------------------
Key: AS7-784
URL: https://issues.jboss.org/browse/AS7-784
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.0.0.Beta3
Reporter: Stan Silvert
Assignee: Brian Stansberry
Steps:
1) Deploy something by copying an archive to the standalone/deployments directory.
2) Using the CLI or Console, remove the deployment.
i.e. /deployment=mywar.war/:remove
The deployment will stop, but the .war file and .deployed marker remain on the file system. When you restart the server, mywar.war will deploy again.
The problem is that "remove" doesn't really remove. It only stops the deployment until the next full restart. If you try to do some other operation on the deployment you will get a NoSuchElementException.
And from the file system, it looks like the deployment is still deployed.
So we need to do something to fully "remove" the deployment. Perhaps we need (yet another) marker file called .removed
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months