[JBoss JIRA] Created: (JBAS-4938) source tarball contains non free code
by Torsten Werner (JIRA)
source tarball contains non free code
-------------------------------------
Key: JBAS-4938
URL: http://jira.jboss.com/jira/browse/JBAS-4938
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB3
Affects Versions: JBossAS-4.2.2.GA
Reporter: Torsten Werner
Assigned To: Carlo de Wolf
The following files
ejb3/src/test/org/jboss/ejb3/test/timestampentity/entity/Table1TimestampEntity.java
ejb3/src/test/org/jboss/ejb3/test/timestampentity/entity/Table1IntegerEntity.java
ejb3/src/test/org/jboss/ejb3/test/timestampentity/entity/Table1Key.java
ejb3/src/test/org/jboss/ejb3/test/timestampentity/entity/Table1TimestampEntity.java
ejb3/src/test/org/jboss/ejb3/test/timestampentity/TestManagerBean.java
ejb3/src/test/org/jboss/ejb3/test/timestampentity/TestManagerCommon.java
ejb3/src/test/org/jboss/ejb3/test/timestampentity/TestManagerConstants.java
ejb3/src/test/org/jboss/ejb3/test/timestampentity/TestManager.java
ejb3/src/test/org/jboss/ejb3/test/timestampentity/TestManagerLocal.java
start with the following header:
Research In Motion Proprietary. Do not reproduce without permission in writing.
That doesn't look compatible with the LGPL. Please make a very visible statement in the source tarball if you have the permission to relicense the code as LGPL or remove the files otherwise.
Cheers,
Torsten
--
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, 8 months
[JBoss JIRA] Created: (JBAS-4805) InitialContextFactory.getHAContext() should not use hardcoded localhost for lookup
by Galder Zamarreno (JIRA)
InitialContextFactory.getHAContext() should not use hardcoded localhost for lookup
----------------------------------------------------------------------------------
Key: JBAS-4805
URL: http://jira.jboss.com/jira/browse/JBAS-4805
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB3
Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2
Reporter: Galder Zamarreno
Assigned To: Carlo de Wolf
Fix For: JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
org.jboss.ejb3.InitialContextFactory.getHAContext() contains:
env.put(Context.PROVIDER_URL, "localhost:" + getHaJndiPort());
InitialContext haCtx = new InitialContext(env);
The code should not have hardcoded localhost because as soon as someone binds JBoss
to something different, a localhost lookup will fail.
This could should instead check HAJNDI service's BindAddress attribute and use that.
--
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, 8 months
[JBoss JIRA] Created: (BPEL-282) Engine runs process instances in serie instead of in parallel
by Santiago Erquicia (JIRA)
Engine runs process instances in serie instead of in parallel
-------------------------------------------------------------
Key: BPEL-282
URL: http://jira.jboss.com/jira/browse/BPEL-282
Project: JBoss jBPM BPEL
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Engine
Affects Versions: jBPM BPEL 1.1 beta 3
Environment: RHEL
Reporter: Santiago Erquicia
Assigned To: Alejandro Guizar
We are stress testing a BPEL process and we found out that the engine runs all the requests it receives in serie. That means that if there are two or more concurrent users of the system, one has to wait till the first process instance stops at some point (wait state) so the other request can be processed.
On our test environment, we are calling a web service which is also calling another web service. The are connection problems with the second one, so from time to time the web service just times out. This means that a concurrent user has to wait for that time out, and whatever is left of that process instance, in order to be processed.
On our JMeter test, the throughput keeps stable even if there number of request is bigger than the throughput of the BPEL engine. The result is that the time for response of each process request increases indefinitely if the usage is bigger than the throughput. This obviously doesn't scale at all for the processing requirement we are considering.
--
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, 8 months
[JBoss JIRA] Created: (JBPM-958) Can't display the non-ISO8859-1 characters!
by David Chan (JIRA)
Can't display the non-ISO8859-1 characters!
-------------------------------------------
Key: JBPM-958
URL: http://jira.jboss.com/jira/browse/JBPM-958
Project: JBoss jBPM
Issue Type: Bug
Components: Web Interface
Affects Versions: jBPM jPDL 3.2
Environment: Windows XP Professional English
JDK 1.5
Eclipse 3.2.2
JPDL Suite 3.2 GA
Reporter: David Chan
Assigned To: Tom Baeyens
When I run the console application, log in as the user bert, then start the sample process websale, it display a form.
So I input some Chinese characters as task variable, see the attachment(JPG). After click the save button, what the input has been saved into database and page was rendered again, but the character displayed is not same as I just inputed.
Please see the second attachment(JPG), I really don't know how the strange character came out.
I also checked the page encoding, which is all UTF-8.
--
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, 8 months
[JBoss JIRA] Created: (JBCACHE-1164) NodeNotExistException with concurent put/remove operations
by Jacek Halat (JIRA)
NodeNotExistException with concurent put/remove operations
----------------------------------------------------------
Key: JBCACHE-1164
URL: http://jira.jboss.com/jira/browse/JBCACHE-1164
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: PojoCache
Affects Versions: 1.4.1.SP4
Environment: Windows XP, Sun jdk150_06
Reporter: Jacek Halat
Assigned To: Jason T. Greene
When 2 Threads are putting/removing data from this same node, put operation fails with exception
org.jboss.cache.NodeNotExistsException: node /a/b/c/d not found (gtx=GlobalTransaction::2, caller=Thread[Thread-0,5,main])
at org.jboss.cache.TreeCache._put(TreeCache.java:4618)
at org.jboss.cache.TreeCache._put(TreeCache.java:4579)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330)
at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:89)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
(...)
Thread 1 is calling:
cache.remove("/a/b/c/d");
cache.remove("/a");
Thread 2 is calling:
cache.putObject("/a/b/c/d", "text" + x);
--
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, 8 months
[JBoss JIRA] Created: (JGRP-603) FLUSH: problems with TCP and concurrent startup/shutdowns
by Bela Ban (JIRA)
FLUSH: problems with TCP and concurrent startup/shutdowns
---------------------------------------------------------
Key: JGRP-603
URL: http://jira.jboss.com/jira/browse/JGRP-603
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
The attached ZIP file has code that reproduces this.
Modify props.props (pf.cluster.transport.protocol=udp) to "tcp" and "tcp-nio" if you want to test the different stacks.
To reproduce:
- Start a number of instances (e.g. 5) concurrently. This almost never works, even under "udp". Joiners' JOIN requests time out and they have to retry (possibly because the coord is busy with the FLUSH protocol). They become singleton members and *never* merge !
- This works fine without FLUSH
- With "udp", it works almost always, with "tcp" it works 50% of the time, with "tcp-nio" is almost never works
- Randomly kill and restart instances
--
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, 8 months
[JBoss JIRA] Created: (JBAS-4942) Using seperating classloader in an ear file can not deploy resource adapters from outside ear
by Michael Lipp (JIRA)
Using seperating classloader in an ear file can not deploy resource adapters from outside ear
---------------------------------------------------------------------------------------------
Key: JBAS-4942
URL: http://jira.jboss.com/jira/browse/JBAS-4942
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA service, Deployment services, ClassLoading
Affects Versions: JBossAS-4.0.5.GA
Environment: Windows XP SP2, jdk1.6, jdk1.5.0_07
Reporter: Michael Lipp
i have created an ear file which contains some resource adapters in embedded rar files. These rar files contains classes who implements the adapter. If i try to deploy this ear file with scoped classloading the adapters could not be deployed.
I always got the following traces:
2007-03-30 11:42:45,500 DEBUG [org.jboss.resource.connectionmanager.RARDeployment] Starting jboss.jca:service=ManagedConnectionFactory,name=AccountVerifierAdapter
2007-03-30 11:42:45,500 ERROR [org.jboss.resource.connectionmanager.RARDeployment] Could not find ManagedConnectionFactory class: de.wincor.fotop.verifier.connector.ManagedConnectionFactoryImpl
java.lang.ClassNotFoundException: No ClassLoaders found for: de.wincor.fotop.verifier.connector.ManagedConnectionFactoryImpl
at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:306)
at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:511)
at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:405)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.jboss.resource.connectionmanager.RARDeployment.startService(RARDeployment.java:322)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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 sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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 $Proxy32.start(Unknown Source)
at org.jboss.deployment.SimpleSubDeployerSupport.startService(SimpleSubDeployerSupport.java:356)
at org.jboss.deployment.SimpleSubDeployerSupport.start(SimpleSubDeployerSupport.java:127)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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:610)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
2007-03-30 11:42:45,515 DEBUG [org.jboss.resource.connectionmanager.RARDeployment] Starting failed jboss.jca:service=ManagedConnectionFactory,name=AccountVerifierAdapter
org.jboss.deployment.DeploymentException: Could not find ManagedConnectionFactory class: de.wincor.fotop.verifier.connector.ManagedConnectionFactoryImpl
at org.jboss.resource.connectionmanager.RARDeployment.startService(RARDeployment.java:327)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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 sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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 $Proxy32.start(Unknown Source)
at org.jboss.deployment.SimpleSubDeployerSupport.startService(SimpleSubDeployerSupport.java:356)
at org.jboss.deployment.SimpleSubDeployerSupport.start(SimpleSubDeployerSupport.java:127)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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:610)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
i have enabled scoped classloading in the jboss-app.xml with:
<jboss-app>
<loader-repository>
de.wincor:loader=FOtopApp.ear
<loader-repository-config>
java2ParentDelegation=false
</loader-repository-config>
</loader-repository>
</jboss-app>
--
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, 8 months