[JBoss JIRA] Created: (JBAS-5152) Tomcat SSL Configuration Problem of JBoss4.2.2.GA
by Anqin Zou (JIRA)
Tomcat SSL Configuration Problem of JBoss4.2.2.GA
-------------------------------------------------
Key: JBAS-5152
URL: http://jira.jboss.com/jira/browse/JBAS-5152
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-4.2.2.GA
Environment: Windows XP, JDK1.6.0, JBoss4.2.2.GA
Reporter: Anqin Zou
Assigned To: Remy Maucherat
Fix For: JBossAS-4.2.1.GA
The attached Tomcat SSL configuration works for JBoss4.2.1.GA, but not JBoss4.2.2.GA.
<Connector port="8443" address="${jboss.bind.address}" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="100" strategy="ms" maxHttpHeaderSize="8192"
emptySessionPath="true"
scheme="https" secure="true" clientAuth="false"
keystoreFile="${jboss.server.home.dir}/conf/stscorp.keystore"
keystorePass="stscorp" sslProtocol = "TLS" />
The Exception message attached as below;
09:33:40,085 INFO [AjpAprProtocol] Initializing Coyote AJP/1.3 on ajp-127.0.0.1
-8009
09:33:40,100 ERROR [Http11AprProtocol] Error initializing endpoint
java.lang.Exception: No Certificate file specified
at org.apache.tomcat.jni.SSLContext.setCertificate(Native Method)
at org.apache.tomcat.util.net.AprEndpoint.init(AprEndpoint.java:683)
at org.apache.coyote.http11.Http11AprProtocol.init(Http11AprProtocol.jav
a:107)
at org.apache.catalina.connector.Connector.initialize(Connector.java:107
3)
at org.apache.catalina.core.StandardService.initialize(StandardService.j
ava:668)
at org.apache.catalina.core.StandardServer.initialize(StandardServer.jav
a:791)
at org.apache.catalina.startup.Catalina.load(Catalina.java:528)
at org.apache.catalina.startup.Catalina.start(Catalina.java:568)
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:597)
at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.j
ava:296)
at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:1
64)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.web.tomcat.service.JBossWeb.startService(JBossWeb.java:440)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
upport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
eanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:142)
at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor
.java:97)
at org.jboss.deployment.SubDeployerInterceptor.invokeNext(SubDeployerInt
erceptor.java:124)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterce
ptor.java:109)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy9.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
upport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
eanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
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:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:508)
at java.lang.Thread.run(Thread.java:619)
09:33:40,335 ERROR [Catalina] Catalina.start
LifecycleException: Protocol handler initialization failed: java.lang.Exception
: No Certificate file specified
--
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
18 years
[JBoss JIRA] Created: (JBWEB-96) ATTRIBUTE level replication granularity not replicating session metadata
by Mike Van Noord (JIRA)
ATTRIBUTE level replication granularity not replicating session metadata
------------------------------------------------------------------------
Key: JBWEB-96
URL: http://jira.jboss.com/jira/browse/JBWEB-96
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Tomcat Module
Environment: JBoss AS 4.2.1, replication-trigger: SET, replication-granularity: ATTRIBUTE
Reporter: Mike Van Noord
Assigned To: Mladen Turk
When setting attributes in a session and using ATTRIBUTE-level replication granularity and the SET replication trigger, I expect certain session meta-data to be replicated along with the attribute being set (namely last access time). This isn't happening.
Since ClusteredSession only flags the metadata as dirty on access when the ACCESS replication trigger is used, the sessionMetadataDirty flag will only be set at the beginning and end of a session's lifecycle thereby preventing any metadata replication between those times.
It seems appropriate to flag the metadata as dirty when using ATTRIBUTE-level replication whenever the replication trigger specifies, in this case when an attribute is set.
--
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
18 years
[JBoss JIRA] Created: (JBAS-4282) Can't create a root context web app
by Stan Silvert (JIRA)
Can't create a root context web app
-----------------------------------
Key: JBAS-4282
URL: http://jira.jboss.com/jira/browse/JBAS-4282
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.Beta2
Reporter: Stan Silvert
Assigned To: Remy Maucherat
I am unable to deploy a web app as root context using the instructions here:
http://wiki.jboss.org/wiki/Wiki.jsp?page=SetupARootContextApp
One thing that is unclear is if ROOT.war "must" be removed from /deploy. In 4.2, root context web apps do not require removal of ROOT.war. IMHO, this is how it should work. If you deploy a WAR as the root context, it should simply override whatever was there before.
If ROOT.war is removed, 5.0 will allow a root context web app as long as it is deployed from an EAR and specified as such in application.xml. Otherwise, it will fail.
If you choose to deploy a stand-alone WAR and specify it as root context using jboss-web.xml, it will always fail - regardless of whether or not you remove ROOT.war.
I have committed a test for root deployment in both 4.2 and 5.0. The test passes in 4.2, but not in 5.0. You can run it with:
build one-test -Dtest=org.jboss.test.web.test.RootContextUnitTestCase
--
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
18 years
[JBoss JIRA] Created: (JGRP-494) Investigate marshalling format to simplify wireshark / ethereal plugin
by Bela Ban (JIRA)
Investigate marshalling format to simplify wireshark / ethereal plugin
-----------------------------------------------------------------------
Key: JGRP-494
URL: http://jira.jboss.com/jira/browse/JGRP-494
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
Currently, parsing JGroups network data via wireshark is difficult:
- message lists don't have (a) total number of bytes and (b) bytes/message and
- headers don't have (a) total bytes for all headers and (b) bytes / header
Investigate whether we can change the marshalling format to accommodate the wireshark plugin. This has the nice side effect that the JGroups wire format becomes standardized, ie. each header has the same format. This allows us to display a header even if we don't know how to parse it. In this case, we'd simply display the name and number of bytes.
Caveat: we want to avoid having to make messages bigger when marshalled.
--
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
18 years
[JBoss JIRA] Created: (JGRP-653) Streaming API for large messages
by Bela Ban (JIRA)
Streaming API for large messages
--------------------------------
Key: JGRP-653
URL: http://jira.jboss.com/jira/browse/JGRP-653
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.x
For large messages, to load the entire payload into memory might be bad because the payload might be bigger than the max memory available. It would be useful to have an API which allows for use of input and output streams, so that large payloads can be read iteratively by a user and streamed out to the cluster via the underlying channel breaking the data in the input stream into chunks, which are fed into the input stream on the receivers side.
Issues: we have to have 1 input stream per sender on the receiver side, because a stream is always defined between 2 parties (sender, receiver). Maybe something like NIO, where we register interest in a stream, are notified of new streams ('accept()') and get notified when data on any of the stream is available, would be beneficial.
Demo is attached
--
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
18 years
[JBoss JIRA] Created: (EJBTHREE-1116) Clustered container sees requests during shutdown
by Brian Stansberry (JIRA)
Clustered container sees requests during shutdown
-------------------------------------------------
Key: EJBTHREE-1116
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1116
Project: EJB 3.0
Issue Type: Bug
Components: Clustering
Affects Versions: AS 4.2.2.GA
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=123677 -- during undeploy the cache is being asked for beans after it has already gone into cleanup. It should not be exposed to requests at this point.
A couple points:
1) StatefulContainer.stop() does this:
if (cache != null) cache.stop();
super.stop();
Basically the cache is stopped before anything else.
2) The HA versions of the old detached invokers included this kind of logic in invoke():
HATarget target = (HATarget)beanMap.get(invocation.getObjectName());
if (!target.invocationsAllowed ())
throw new GenericClusteringException(GenericClusteringException.COMPLETED_NO,
"invocations are currently not allowed on this target");
.... else continue on and handle call
An HA proxy will catch the GenericClusteringException and fail over.
There is no equivalent interceptor in EJB3. In the container stop() methods there is a usage of Dispatcher.singleton.unregisterTarget(...) which will lead to an exception being thrown if a call comes in for the container, and an HA proxy will catch that exception and fail over. So, adding an interceptor to check the HATarget *may* not be necessary, if we are sure that Dispatcher.singleton.unregisterTarget(...) is always called very early in the stop() process.
--
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
18 years
