[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
13 years, 7 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
13 years, 7 months
[JBoss JIRA] Created: (JBAS-8791) log4j-appender seems not working in jboss-logging (AS6 final)
by Gregoire Botquin (JIRA)
log4j-appender seems not working in jboss-logging (AS6 final)
-------------------------------------------------------------
Key: JBAS-8791
URL: https://issues.jboss.org/browse/JBAS-8791
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Logging
Affects Versions: 6.0.0.Final
Reporter: Gregoire Botquin
Assignee: David Lloyd
We are using some custom logger based on log4j appenders. I made a jboss-logging.xml configuration but it seems that my log4j-appender doesn't log anything. I'm working in AS6 final version.
I made an example with a standard log4j appender (neither working). The category "com.sample" should be managed by the log4jappender. Every second the bean should write something, but nothing happens, the log file is not even created. I tried with other log4j loggers/ custom loggers and no success.
When activating CONSOLE handler the logs are correctly written in console, but when only using the log4j-appender nothing happens after server started.
The configuration file seems correct (?), but can't unfortunately check it against a documentation yet.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
<logging xmlns="urn:jboss:logging:6.0" xmlns:b="urn:jboss:bean-deployer:2.0">
<!-- ================================= -->
<!-- Preserve messages in a local file -->
<!-- ================================= -->
<!-- A time/date based rolling handler -->
<periodic-rotating-file-handler
file-name="${jboss.server.log.dir}/server.log"
name="FILE"
autoflush="true"
append="true"
suffix=".yyyy-MM-dd"> <!-- To roll over at the top of each hour, use ".yyyy-MM-dd-HH" instead -->
<error-manager>
<only-once/>
</error-manager>
<formatter>
<!-- To revert back to simple stack traces without JAR versions, change "%E" to "%e" below. -->
<!-- Uncomment this to get the class name in the log as well as the category
<pattern-formatter pattern="%d %-5p [%c] %C{1} (%t) %s%E%n"/>
-->
<!-- Uncomment this to log without the class name in the log -->
<pattern-formatter pattern="%d %-5p [%c] (%t) %s%E%n"/>
</formatter>
</periodic-rotating-file-handler>
<!-- ============================== -->
<!-- Append messages to the console -->
<!-- ============================== -->
<console-handler name="CONSOLE" autoflush="true" target="System.out">
<error-manager>
<only-once/>
</error-manager>
<level name="INFO"/>
<formatter>
<pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] %s%E%n"/>
</formatter>
</console-handler>
<log4j-appender name="Log4jAppender" class="org.apache.log4j.DailyRollingFileAppender">
<error-manager>
<only-once/>
</error-manager>
<level name="DEBUG"/>
<properties>
<!-- <property name="directory">${jboss.server.log.dir}/</property> -->
<property name="file">${jboss.server.log.dir}/log4j.log</property>
<property name="append">true</property>
<property name="datePattern">'.'yyyy-MM-dd</property>
</properties>
<formatter>
<pattern-formatter pattern="%d %-5p [%c] %m%n"/>
</formatter>
</log4j-appender>
<logger category="com.sample">
<level name="DEBUG"/>
<handlers>
<handler-ref name="Log4jAppender"/>
</handlers>
</logger>
<!-- ======================= -->
<!-- Setup the Root category -->
<!-- ======================= -->
<root-logger>
<!-- Set the root logger priority via a system property, with a default value. -->
<level name="${jboss.server.log.threshold:INFO}"/>
<handlers>
<handler-ref name="Log4jAppender"/>
<!--
<handler-ref name="CONSOLE"/>
<handler-ref name="FILE"/>
-->
</handlers>
</root-logger>
</logging>
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
package com.sample;
import javax.ejb.Schedule;
import javax.ejb.Stateless;
import org.apache.log4j.Logger;
//@Singleton
@Stateless
public class TestBean {
public static final Logger LOG = Logger.getLogger(TestBean.class);
public TestBean(){
System.out.println("TestBean is instantiated and should write someting in the log file");
LOG.info("This is information log");
}
@Schedule(second="*/1", minute="*",hour="*", persistent=false)
public void writeSomething(){
System.out.println("This should write something in the log file at scheduled times");
LOG.info("This is scheduled information log");
}
}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] Created: (JBAS-7468) Memory leak in org.jboss.security.plugins.authorization.JBossAuthorizationContext
by Ganesh Ingle (JIRA)
Memory leak in org.jboss.security.plugins.authorization.JBossAuthorizationContext
---------------------------------------------------------------------------------
Key: JBAS-7468
URL: https://jira.jboss.org/jira/browse/JBAS-7468
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.0.1.GA, JBossAS-5.0.0.GA
Environment: JBoss Version: jboss-5.1.0.GA, OS: Linux (2.6.18-164.el5), Architecture: amd64 64bit, JVM: Java HotSpot(TM) 64-Bit Server VM (14.0-b16, mixed mode)
Reporter: Ganesh Ingle
Assignee: Anil Saldhana
Our use case (only security related portion is mentioned here):
Axis 1.4 webservice, standard J2EE declarative security through WEB-INF/web.xml, a http client sends soap request and BASIC auth information, the JBoss server performs authentication and authorization as per WEB-INF/web.xml configuration.
We did a performance/stability test on above web service. After 8.5 million requests the server gone out of memory. We did heap dump analysis using VisualVM tool and found that the class org.jboss.security.plugins.authorization.JBossAuthorizationContext is consuming most of the memory. This class has a memer array named "controlFlags", this array was showing 25.7 million ControlFlag entries.
When we investigated the code we found that there is one instance of JBossAuthorizationManager per security domain and this manager has one instance of JBossAuthorizationContext. For every authorization the JBossAuthorizationContext initializes authorization modules and pushes their control flags (instances of class ControlFlag) in member arrays. When the authorization is complete, a commit/abort is invoked on all modules and finally the "modules" array is cleared. However, the "controlFlags" array is not cleared. We checked the entire class, this array never gets cleared.
We changed the code to clear both "modules" and "controlFlags" array in a finally block in method JBossAuthorizationContext.authorize(final Resource resource, final Subject subject, final RoleGroup callerRoles). We ran a 50million test after this fix, the test was successful which proves the fix worked.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] (AS7-2322) Stack trace improvements, summarize the things that broke to make them not so intimidating
by Jim Tyrrell (Created) (JIRA)
Stack trace improvements, summarize the things that broke to make them not so intimidating
------------------------------------------------------------------------------------------
Key: AS7-2322
URL: https://issues.jboss.org/browse/AS7-2322
Project: Application Server 7
Issue Type: Feature Request
Reporter: Jim Tyrrell
See the typical attached stack dump:
It would be nice if the stack dump could include all of the information above as a summary as shown below, basically just the first lines of the errors w/o the whole stack dump:
11:51:45,391 INFO [org.jboss.as.server.controller] (HttpManagementService-threads - 5) Deployment of "SpringWAR.war" was rolled back with failure message {"Failed services" => {"jboss.web.deployment.default-host./SpringWAR" => "org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./SpringWAR: failed to start context"}}
11:51:45,392 INFO [org.jboss.as.controller] (HttpManagementService-threads - 5) Service status report
Services which failed to start:
service jboss.web.deployment.default-host./SpringWAR: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./SpringWAR: failed to start context
11:51:45,417 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Stopped deployment SpringWAR.war in 26ms
11:51:45,417 Error Summary of Exceptions in deployment:
- [org.springframework.web.context.ContextLoader] (MSC service thread 1-5) Context initialization failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B
- [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B
- [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Error listenerStart
- ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Context [/SpringWAR] startup failed due to previous errors
- [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Closing Spring root WebApplicationContext
- [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.web.deployment.default-host./SpringWAR:
ERROR Scroll up to see more info...
Or
11:51:45,417 Error Summary of Exceptions in deployment:
[1] [org.springframework.web.context.ContextLoader] (MSC service thread 1-5) Context initialization failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B
[2] [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B
[3] [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Error listenerStart
[4] ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Context [/SpringWAR] startup failed due to previous errors
[5] [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Closing Spring root WebApplicationContext
[6] [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.web.deployment.default-host./SpringWAR:
ERROR Scroll up to see more info...
--
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
13 years, 7 months
[JBoss JIRA] (AS7-2385) Management - readding file handler logger fails
by Dominik Pospisil (Created) (JIRA)
Management - readding file handler logger fails
-----------------------------------------------
Key: AS7-2385
URL: https://issues.jboss.org/browse/AS7-2385
Project: Application Server 7
Issue Type: Bug
Components: Domain Management, Logging
Affects Versions: 7.1.0.Beta1
Reporter: Dominik Pospisil
Assignee: Brian Stansberry
Removing and adding file handler fails. Perhaps remove operation does not clean up all resources properlly.
Steps to reproduce:
[standalone@localhost:9999 /] /subsystem=logging/file-handler=test-fh:add(name="test-fh", level="WARN", file={"path" => "/home/dpospisi/testfh.log"})
{"outcome" => "success"}
[standalone@localhost:9999 /] /subsystem=logging/file-handler=test-fh:remove
{"outcome" => "success"}
[standalone@localhost:9999 /] /subsystem=logging/file-handler=test-fh:add(name="test-fh", level="WARN", file={"path" => "/home/dpospisi/testfh.log"})
{
"outcome" => "failed",
"failure-description" => "Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service jboss.logging.handler-file.test-fh is already registered",
"rolled-back" => true
}
[standalone@localhost:9999 /]
--
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
13 years, 7 months
[JBoss JIRA] (AS7-2873) EJB not defining an EJB 2 view method should not deploy
by Carlo de Wolf (Created) (JIRA)
EJB not defining an EJB 2 view method should not deploy
-------------------------------------------------------
Key: AS7-2873
URL: https://issues.jboss.org/browse/AS7-2873
Project: Application Server 7
Issue Type: Bug
Components: EJB
Reporter: Carlo de Wolf
Assignee: Stuart Douglas
A bean which does not implement the sayHello method of the following EJB 2 remote view:
{code:title=HelloRemote.java}
public interface HelloRemote extends EJBObject {
String sayHello(String name) throws RemoteException;
}
{code}
gets the following exception during invocation:
{noformat}
Caused by: javax.ejb.EJBException: org.jboss.invocation.CannotProceedException: INV-00002:Invocation cannot proceed (end of interceptor chain has been hit)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:241)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:316)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:201)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropogatingInterceptor.processInvocation(EJBRemoteTransactionPropogatingInterceptor.java:86)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:70)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:56)
... 126 more
{noformat}
Instead the EJB should not have deployed properly and throw a DeploymentException.
--
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
13 years, 7 months