[JBoss JIRA] Created: (JBPORTAL-1324) Multiple portals / custom url : set the default portal name
by Antoine Herzog (JIRA)
Multiple portals / custom url : set the default portal name
-----------------------------------------------------------
Key: JBPORTAL-1324
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1324
Project: JBoss Portal
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Portal Core
Environment: JBoss Portal 2.4.0 final
Reporter: Antoine Herzog
Assigned To: Julien Viet
Here the code of the jmx service class
public class ConfigurableDefaultPortalCommandFactory extends
DefaultPortalCommandFactory {
private static final Log logger = LogFactory
.getLog(ConfigurableDefaultPortalCommandFactory.class);
/**
* The JMX attribute for default portal name.
*/
private String defaultPortalName;
/**
*
*/
public ConfigurableDefaultPortalCommandFactory() {
super();
}
/*
* (non-Javadoc)
*
* @see org.jboss.portal.core.model.portal.DefaultPortalCommandFactory#doMapping(org.jboss.portal.server.ServerInvocation,
* java.lang.String, java.lang.String)
*/
public ControllerCommand doMapping(ServerInvocation invocation,
String portalContextPath, String portalRequestPath) {
// orginal code : ControllerCommand cmd =
// nextFactory.doMapping(invocation,
ControllerCommand cmd = getNextFactory().doMapping(invocation,
portalContextPath, portalRequestPath);
if (cmd == null) {
// orginal code : Context ctx = container.getContext();
Context ctx = getContainer().getContext();
if (ctx == null) {
throw new IllegalStateException(
"Default context does not exist");
}
// orginal code : Portal portal = ctx.getDefaultPortal();
PortalObject portalObject = ctx.getChild(getDefaultPortalName());
if (portalObject == null) {
throw new IllegalStateException(
"PortalObject as Default Portal is not found. Default Portal name is defined to : "
+ getDefaultPortalName());
}
Portal portal = null;
if (portalObject instanceof Portal) {
portal = (Portal) portalObject;
} else {
throw new IllegalStateException(
"Can't find PortalObject with default portal name : "
+ getDefaultPortalName());
}
// if (portal == null) {
// throw new IllegalStateException("Default portal does not exist");
// }
Page page = portal.getDefaultPage();
if (page == null) {
throw new IllegalStateException("Default page does not exist");
}
String handle = page.getId();
cmd = new RenderPageCommand(handle);
}
return cmd;
}
/**
* The JMX attribute for default portal name.
*
* @return the defaultPortalName
*/
public String getDefaultPortalName() {
return this.defaultPortalName;
}
/**
* The JMX attribute for default portal name.
*
* @param defaultPortalName
* the defaultPortalName to set
*/
public void setDefaultPortalName(String defaultPortalName) {
this.defaultPortalName = defaultPortalName;
}
/**
* Call the super method first, then check the {@link #defaultPortalName} is
* not null and not "". Throw an exception if so.
*/
protected void createService() throws Exception {
super.createService();
if (getDefaultPortalName() == null
|| getDefaultPortalName().compareTo("") == 0) {
throw new Exception(
"The attribute DefaultPortalName can't be null or empty string. Set it in the JMX service descriptor.");
}
}
/*
* (non-Javadoc)
*
* @see org.jboss.system.ServiceMBeanSupport#startService()
*/
@Override
protected void startService() throws Exception {
logger.info(this.getName() + " service starting. Default portal name : getDefaultPortalName() = "+getDefaultPortalName());
super.startService();
}
/*
* (non-Javadoc)
*
* @see org.jboss.system.ServiceMBeanSupport#stopService()
*/
@Override
protected void stopService() throws Exception {
super.stopService();
logger.info(this.getName() + " service stoping.");
}
}
And add the attribute in the jmx service descriptor :
<!-- Default portal name : "default" is the default for native jboss portal (downloaded version). -->
<attribute name="DefaultPortalName">MyDefaultPortalNameHere</attribute>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JBAS-3654) The deploy dependency fails between WAR of one EAR and EJB of the other EAR.
by Sakthi Samabsivam (JIRA)
The deploy dependency fails between WAR of one EAR and EJB of the other EAR.
----------------------------------------------------------------------------
Key: JBAS-3654
URL: http://jira.jboss.com/jira/browse/JBAS-3654
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services
Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA, JBossAS-4.0.4RC1, JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final, JBossAS-4.0.3RC2, JBossAS-4.0.3RC1
Reporter: Sakthi Samabsivam
Assigned To: Dimitris Andreadis
When I try to setup a deployment order between two EARS using depends tag in the Jboss-web.xml of one EAR's WAR with other EAR's EJB component, it fails.
for example. I have two ears example1. ear and example2.ear.
I want my example1.ear's war file to be deployed after the example2.ear's EJB component is deployed..
So I am wrting this depends tag entry in my example1.ear's WAR compoent jboss-web.xml
<depends>jboss.j2ee:url='FiboApp.ear',service=EARDeployment</depends>
This depends is working till jboss 4.0.1
It fails in 4.0.3 SP1 , 4.0.4 GA
15:52:24,359 WARN [ServiceController] Problem starting service jboss.web.deploy
ment:war=crimeportal.war,id=-1360680885
org.jboss.deployment.DeploymentException: Error during deploy; - nested throwabl
e: (javax.security.jacc.PolicyContextException: Operation not allowed)
at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:366)
at org.jboss.web.WebModule.startModule(WebModule.java:68)
at org.jboss.web.WebModule.startService(WebModule.java:46)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
upport.java:274)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
eanSupport.java:230)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:943)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:428)
at org.jboss.system.ServiceController.start(ServiceController.java:446)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy21.start(Unknown Source)
at org.jboss.deployment.EARDeployer.start(EARDeployer.java:297)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:118)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:127)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy9.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:319)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:507)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:192)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:265)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
upport.java:274)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
eanSupport.java:230)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:943)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:428)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:285)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:737)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:118)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:127)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:453)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:330)
at org.jboss.Main.boot(Main.java:187)
at org.jboss.Main$1.run(Main.java:438)
at java.lang.Thread.run(Thread.java:595)
Caused by: javax.security.jacc.PolicyContextException: Operation not allowed
at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
olicyConfiguration.java:201)
at org.jboss.security.jacc.JBossPolicyConfiguration.linkConfiguration(JB
ossPolicyConfiguration.java:160)
at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:347)
... 94 more
Caused by: org.jboss.util.state.IllegalTransitionException: No transition for ac
tion: linkConfiguration from state:inService
at org.jboss.util.state.StateMachine.nextState(StateMachine.java:111)
at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
olicyConfiguration.java:196)
... 96 more
15:52:24,359 INFO [EARDeployer] Started J2EE application: file:/C:/jboss/traini
ng/JBossForAdvancedJ2EE/labs/jboss-4.x/server/default/deploy/FiboApp.ear
15:52:24,359 ERROR [URLDeploymentScanner] Incomplete Deployment listing:
--- MBeans waiting for other MBeans ---
ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
State: FAILED
Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
I Depend On:
jboss.j2ee:url='FiboApp.ear',service=EARDeployment
--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
State: FAILED
Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
I Depend On:
jboss.j2ee:url='FiboApp.ear',service=EARDeployment
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JBAS-3591) For SESSION and ATTRIBUTE don't marshal values if UseRegionBasedMarshalling is on
by Brian Stansberry (JIRA)
For SESSION and ATTRIBUTE don't marshal values if UseRegionBasedMarshalling is on
---------------------------------------------------------------------------------
Key: JBAS-3591
URL: http://jira.jboss.com/jira/browse/JBAS-3591
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Clustering, Web (Tomcat) service
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-5.0.0.CR1
Storing session or attributes in the cache as byte[] or MarshalledValue is unnecessary if region based marshalling is used. Doing it greatly increases the memory footprint of distributed sessions.
Need to benchmark the performance impact of this (could be positive or negative), although the memory savings would outweigh all but a major performance loss.
Can't do this in Branch_4_0 is it breaks binary compatibility.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JBAS-3914) Thread dumps from ServerInfo MBean do not contain line breaks.
by Darran Lofthouse (JIRA)
Thread dumps from ServerInfo MBean do not contain line breaks.
--------------------------------------------------------------
Key: JBAS-3914
URL: http://jira.jboss.com/jira/browse/JBAS-3914
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JMX
Affects Versions: JBossAS-4.0.5.GA
Reporter: Darran Lofthouse
Assigned To: Darran Lofthouse
Fix For: JBossAS-4.2.0.CR1
Thread dumps from ServerInfo MBean do not contain line breaks, as the output HTML and displayed in a browser this is generally not a problem as the browser formats the output using the HTML tags not based on the presence of line breaks.
If users copy the data from the web browser to a text editor as there are no line breaks in the original output the data is pasted to the text editor without breaks which causes everything to be on one line.
The ouput thread dumps should have line breaks added to get round this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JBAS-4083) Ejb timers fire before the ear completely deploys
by Vadim Kopichenko (JIRA)
Ejb timers fire before the ear completely deploys
-------------------------------------------------
Key: JBAS-4083
URL: http://jira.jboss.com/jira/browse/JBAS-4083
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB2, Scheduling/Timers
Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
Environment: WinNT, Sun JDK 1.5
Reporter: Vadim Kopichenko
Assigned To: Scott M Stark
Consider the following usecase.
The is an ear containing several ejb modules.
One of them has a ejb2.1 timed cmp entity bean.
If the timer associated with the bean fires during application deployment unexpected errors happen, cause other beans could be not already deployed.
This breaks application logic.
The problem happens both while server starts/stops and while hot ear's redeployment.
It would be much better if timers began to fire after the application had completely deployed.
I've also experienced a similar problem with undeployment.
Timer code was executed about a half of second after the undeployment had begun. Several ejb modules had been already undeployed by that moment.
I guess that timer actually fired exactly before the undeployment had begun but the ejbTimeout executed later due to threads syncronization issue.
Please, try also to investigate if this can be avoided.
PS
Some kind of patch or workaround for 4.0.5 (or even a hint about how this can be fixed) would be greatly appreciated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JBCACHE-991) Non-JTA based mechanism for batching invocations
by Brian Stansberry (JIRA)
Non-JTA based mechanism for batching invocations
------------------------------------------------
Key: JBCACHE-991
URL: http://jira.jboss.com/jira/browse/JBCACHE-991
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Currently JBC uses the lifecycle of a JTA Transaction to scope a series of cache invocations doing things like lock release, replication and cache loader storage as part of the transaction commit. Need a mechanism to do this kind of invocation batching that doesn't depend on JTA. Needed to allow callers that don't wish their work to be associated with an active JTA transaction to still get the batching behavior JBC provides.
AS web session replication is an example use case. It uses BatchModeTransactionManger to ensure its activity doesn't impact any ongoing transaction. But BatchModeTransactionManager isn't a good JTA transaction manager even though it implements the JTA interfaces. So using it is problematic; it can easily be misused by those who don't understand it's limitations (e.g. hooking it up to a JTA Datasource.)
A couple of possible approaches have been discussed:
1) A new API added to Cache. Methods like startBatch(), commitBatch(), rollbackBatch(), along with some internal mechanism to timeout a batch that's been started but never committed/rolled-back.
2) Abstract away the JTA API such that JBC doesn't use JTA directly, but rather its own interfaces that largely parallel TransactionManager and Transaction. Provide an impl that simply wraps a real JTA TransactionManager. BatchModeTransactionManger would be another impl. API includes a method like 'boolean isJTACompliant()' that things like CacheLoader impls can check at startup to confirm they are working with a compatible impl (e.g. if JBDCCacheLoader is configured to use a JTA Datasource but isJTACompliant() returns false, throw an exception at startup.)
Apologies if this is a duplicate issue. Thought there was something like this but couldn't find it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months