[JBoss JIRA] Created: (JBPORTAL-1177) impossible to move the windows on the right with the management portlet
by St￩phane HUDEC (JIRA)
impossible to move the windows on the right with the management portlet
-----------------------------------------------------------------------
Key: JBPORTAL-1177
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1177
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Portlet
Affects Versions: 2.4.1 Final, 2.6.DR1, 2.4 Final
Reporter: St￩phane HUDEC
Assigned To: Julien Viet
Impossible to move the windows on the right with the management portlet.
To reproduce on the default portal : try to move the CatalogPortletWindow of the Test page to the right (left --> navigation), the window in fact is moved to the left (center).
I think that a "break" was omitted in the method "public void move(Window target, int direction) " of the "org.jboss.portal.core.portlet.management.PortalObjectManagerBean" before "case MOVE_LEFT" instruction.
--
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
19 years, 2 months
[JBoss JIRA] Created: (JBAS-3780) Deploying empty file to farm directory causes ScannerThread to hang
by Brian Stansberry (JIRA)
Deploying empty file to farm directory causes ScannerThread to hang
-------------------------------------------------------------------
Key: JBAS-3780
URL: http://jira.jboss.com/jira/browse/JBAS-3780
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Environment: Fedora Core 5
JBoss [Zion] 4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
As reported by Dan Delany in JBCLUSTER-151:
Creating a 0 byte long file in the farm directory causes the server to stop scanning the farm directory.
To reproduce:
Deploy a fresh instance of JBoss.
Do not deploy any applications to it.
Configure it to be part of a cluster.
Launch JBoss.
After it is running, touch farm/foo.xml
The log will show
07:45:34,555 INFO [JkMain] Jk running ID=0 time=0/33 config=null
07:45:34,562 INFO [Server] JBoss (MX MicroKernel) [4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)] Started in 42s:633ms
07:45:48,664 INFO [ClusterFileTransfer] Start push of file foo.xml to cluster.
--
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
19 years, 2 months
[JBoss JIRA] Created: (JBAS-3798) EJB Interceptors Initialised Before Dependent Services Started
by Darran Lofthouse (JIRA)
EJB Interceptors Initialised Before Dependent Services Started
--------------------------------------------------------------
Key: JBAS-3798
URL: http://jira.jboss.com/jira/browse/JBAS-3798
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services, EJB2
Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
Reporter: Darran Lofthouse
Assigned To: Dimitris Andreadis
Fix For: JBossAS-4.0.6.CR1
The interceptors for an EJB are initialised in the create step of EJB deployment, this means that they can be initialised before the services the EJB depends on have been started.
This can be reproduced by deploying a sar that contains a jar that contains a MDB and then starting JBoss, the CachedConnectionInterceptor is initialised before the CachedConnectionManager is available and the following warning is logged: -
12:27:54,179 WARN [EjbModule] Could not load the org.jboss.resource.connectionmanager.CachedConnectionInterceptor interceptor for this container
javax.management.InstanceNotFoundException: jboss.jca:service=CachedConnectionManager is not registered.
at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:523)
at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:550)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.<init>(CachedConnectionInterceptor.java:78)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at java.lang.Class.newInstance0(Class.java:350)
at java.lang.Class.newInstance(Class.java:303)
at org.jboss.ejb.EjbModule.addInterceptors(EjbModule.java:930)
at org.jboss.ejb.EjbModule.initializeContainer(EjbModule.java:816)
at org.jboss.ejb.EjbModule.createMessageDrivenContainer(EjbModule.java:602)
at org.jboss.ejb.EjbModule.createContainer(EjbModule.java:569)
at org.jboss.ejb.EjbModule.createService(EjbModule.java:342)
at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:260)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:243)
--
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
19 years, 2 months
[JBoss JIRA] Created: (JBAS-3757) Support for PostgreSQL 8.2beta1
by Juergen Zimmermann (JIRA)
Support for PostgreSQL 8.2beta1
-------------------------------
Key: JBAS-3757
URL: http://jira.jboss.com/jira/browse/JBAS-3757
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Environment: PostgreSQL 8.2beta1, JDK 5.0_09, JDBC driver 8.2dev-503.jdbc3, JBoss 4.0.5cr1
Reporter: Juergen Zimmermann
Fix For: JBossAS-4.0.5.GA
Starting JBoss with PostgreSQL 8.2beta1 fails (no problem with 8.1.4).
Here is the log message:
09:11:48,067 INFO [WrapperDataSourceService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
09:11:48,778 WARN [ServiceController] Problem starting service jboss.mq:service=PersistenceManager
org.jboss.mq.SpyJMSException: Could not resolve uncommited transactions. Message recovery may not be accurate; - nested throwable: (org.postgresql.util.PSQLException: Eingabe/Ausgabe-Fehler {0} beim Senden an das Backend.)
at org.jboss.mq.pm.jdbc2.PersistenceManager.resolveAllUncommitedTXs(PersistenceManager.java:489)
at org.jboss.mq.pm.jdbc2.PersistenceManager.startService(PersistenceManager.java:1807)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.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(ServiceController.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 org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.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 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.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 $Proxy39.start(Unknown Source)
at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
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.GeneratedMethodAccessor18.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.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 $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.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(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.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(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.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:464)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.postgresql.util.PSQLException: Eingabe/Ausgabe-Fehler {0} beim Senden an das Backend.
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:216)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:354)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:308)
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:251)
at org.jboss.mq.pm.jdbc2.PersistenceManager.resolveAllUncommitedTXs(PersistenceManager.java:441)
... 111 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:256)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1164)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:190)
... 116 more
--
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
19 years, 2 months
[JBoss JIRA] Created: (JGRP-341) Extend FLUSH to fully support virtual synchrony
by Bela Ban (JIRA)
Extend FLUSH to fully support virtual synchrony
-----------------------------------------------
Key: JGRP-341
URL: http://jira.jboss.com/jira/browse/JGRP-341
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.5
Currently, FLUSH makes sure that all members 'flush' their pending messages and then stop sending new ones until the join or state transfer is over. However, FLUSH does *not* (unlike the old version) make sure that - on JOIN - all members have seen the same set of messages before installing a new view. Example: P sends M, but immediately after sending M crashes. If another member Q received M, but R didn't see M, then - with the current FLUSH - R will *not* see M.
We need to run a messages exchange phase, as part of FLUSH, which makes sure that all member have seen the same set of messages in the same view, before installing a new view. Whether to run this or not could be made configurable. If enabled, we could piggyback the message exchange on START_FLUSH/FLUSH_OK etc.
A simple (but costly) solution would be to simply multicast all messages received from other members before multicasting the FLUSH_OK. A better solution would be to exchange digests with highest sequence numbers seen for all members, and then only multicast the missing messages. This *might* require an additional phase though.
--
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
19 years, 2 months
[JBoss JIRA] Created: (JBCACHE-876) Region marker in region-based marshalling message should be region fqn
by Brian Stansberry (JIRA)
Region marker in region-based marshalling message should be region fqn
----------------------------------------------------------------------
Key: JBCACHE-876
URL: http://jira.jboss.com/jira/browse/JBCACHE-876
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 1.4.1.GA
When region based marshalling is used, the replication message first has a serialized Fqn to identify the region, followed by a separately serialized method call. Receiver deserializes the identifier fqn and uses it to find the classloader to use to deserialize the main message.
Problem is the region identifier Fqn is the full Fqn of a node. This prevents the use in Fqns of classes that require the custom classloader to deserialize.
This can be mitigated by changing the marker Fqn to simply identify the Region, not some subnode. Now the restriction on use of custom classes is limited to the region Fqn; portions of Fqns below the region level can be of any serializable class.
This is needed to solve JBCLUSTER-150.
Downside is the node marshalling the message now needs to do a Region lookup to get the region Fqn.
Upsides are a reduced message size, since the shorter region fqn is marshalled, as well as a possibly faster region lookup time on the recipient nodes, since extraneous data can be ignored.
--
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
19 years, 2 months
[JBoss JIRA] Created: (JBCACHE-893) Create a pluggable PojoCache Collection class implementation
by Ben Wang (JIRA)
Create a pluggable PojoCache Collection class implementation
------------------------------------------------------------
Key: JBCACHE-893
URL: http://jira.jboss.com/jira/browse/JBCACHE-893
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: PojoCache
Reporter: Ben Wang
Assigned To: Ben Wang
Fix For: PojoCache
Currently PojoCache only supports a single flavor of Collection classes, e.g., HashMap, HashSet, and ArrayList. To fully support different flavor of Collection implementation, we can either:
1. Enable array interception from Jboss Aop such that we can instrument all Collection implementation classes (including java.util.*). But JBoss Aop currently doesn't support it yet, and issues of instrumenting the Sun system classes also is problematic.
2. Create a pluggable architecture for different flavor of Collection implementation.
I think Option #2 is more realistic now. What I propose is this:
1. Will need to implement a specific flavor of collection interceptor and cache impl. E.g., in the case of List, it will be CachedListInterceptor and CachedListImpl.
2. Register the specific impl and the corresponding Collection class name to a registry
During runtime, when we encounter Collection classes, we will check the registry first to see which interceptor (and the corresponding cache impl) that we will use for this case.
Performance impact should be minimal since this is needed only for attach phase.
--
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
19 years, 2 months