[JBoss JIRA] Created: (JBESB-184) loanbroker config script can't cope with spaces in install dir
by Mark Little (JIRA)
loanbroker config script can't cope with spaces in install dir
--------------------------------------------------------------
Key: JBESB-184
URL: http://jira.jboss.com/jira/browse/JBESB-184
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0 Beta 1 Maintenance Pack 1
Reporter: Mark Little
Assigned To: Kurt Stam
Fix For: 4.0
I checked out JBossESB into a directory called JBossESB HEAD. The loanbroker 'ant deploy' rule failed because of the space. However, if I look in the LoanBrokerConfig.xml file, sometimes it gets the escaping right:
conf/LoanBrokerConfig.xml: loanbrokerRequestDir="/Users/marklittle/Documents/workspace/JBossESB HEAD/product/samples/trailblazer/bankloanbrokerdemo/TrailBlazer-rtfiles/BankInput"
conf/LoanBrokerConfig.xml: loanbrokerEmailTemplatePath="/Users/marklittle/Documents/workspace/JBossESB HEAD/product/samples/trailblazer/bankloanbrokerdemo/template"
conf/LoanBrokerConfig.xml: <file URI="file:/Users/marklittle/Documents/workspace/JBossESB%20HEAD/product/samples/trailblazer/bankloanbrokerdemo/./TrailBlazer-rtfiles/notification_output_files/creditAgency.notifOK" append="true"/>
--
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, 8 months
[JBoss JIRA] Commented: (JBCACHE-608) Cache loader does not load data for cache.get(Fqn fqn) calls
by Jeevan Sunkersett (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-608?page=comments#action_12347887 ]
Jeevan Sunkersett commented on JBCACHE-608:
-------------------------------------------
FYI,
I did not need to use workaround,
for me a
cache.load(<the-value-with-which-the-Fqn-is-created>)
works.
~g1
PS: My code:
myFQN = new Fqn(new Object[] {myName,"Jeevan"});
this.cache = new TreeCache();
cache.setClusterName(myName); // use myName in the cache.load() to load existing data
cache.setCacheMode("local");
//set the Transaction Manager to enable flushing of cache to disk
cache.setTransactionManagerLookupClass(DummyTransactionManagerLookup.class.getName());
cache.setCacheLoaderConfiguration(getSingleCacheLoaderConfig("",
BdbjeCacheLoader.class.getName(), "location="
+ f.getAbsolutePath(), false, true, false));
create();
cache.load(myName); // this is required, to read in data from existing cache
> Cache loader does not load data for cache.get(Fqn fqn) calls
> ------------------------------------------------------------
>
> Key: JBCACHE-608
> URL: http://jira.jboss.com/jira/browse/JBCACHE-608
> Project: JBoss Cache
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Cache loaders
> Affects Versions: 1.2.3, 1.2.4beta, 1.3.0.GA, 1.2.4, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1
> Reporter: Manik Surtani
> Assigned To: Manik Surtani
> Fix For: 1.4.0.GA
>
> Time Spent: 3 hours
> Remaining Estimate: 0 minutes
>
--
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, 8 months
[JBoss JIRA] Created: (JBAS-3843) Deployment fails the second time on JBoss 4.0.5 GA
by milan w?lke (JIRA)
Deployment fails the second time on JBoss 4.0.5 GA
--------------------------------------------------
Key: JBAS-3843
URL: http://jira.jboss.com/jira/browse/JBAS-3843
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-4.0.5.GA
Environment: Win XP SP2; JBoss 4.0.5 GA installation profile ejb3; Java 1.5 Update 9; P4 2,8 GHz 1GB
Reporter: milan w?lke
When deploying the same ear twice on 4.0.5 GA the application cannot be run anymore.
Details:
The ear Im deploying works fine with 4.0.4 GA. Its an ejb3 based application.
When deploying it the first time after the server is started, and running my tests everything is fine. When undeploying and then deploying the same ear again to the application server, something seems to go wrong, because all my tests fail. Its always the same exception:
15:22:38,820 ERROR [ServiceControlBean] Left ServiceControlBean.executeService( SecurityManager.DELETE_REC.Role, [ UserRole0.ServiceControlBeanTestUser ], [ ], null ) due to thrown exception.
java.lang.IllegalArgumentException: Wrong target. class de.psitrans.vl.base.session.ServiceControlBean for public de.psitrans.vl.base.comm.ServiceResult de.psitrans.vl.base.session.ServiceControlBean.executeService(de.psitrans.vl.base.comm.ServiceKey,java.lang.Object[],java.lang.String[],java.lang.Long)
at org.jboss.aop.joinpoint.MethodInvocation.handleErrors(MethodInvocation.java:141)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:116)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at de.psitrans.vl.base.interceptors.ProfilingInterceptor.profileMethodOnInvoke(ProfilingInterceptor.java:46)
at sun.reflect.GeneratedMethodAccessor346.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:118)
at de.psitrans.vl.base.interceptors.TraceInterceptor.traceMethodOnInvoke(TraceInterceptor.java:68)
at sun.reflect.GeneratedMethodAccessor345.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:118)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:197)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:166)
at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:108)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:131)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:263)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:412)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
The bean which should be called here only has a local interface. the only bean of our application with a remote interface can be accessed without any problems. but all calls to local interfaces from within that bean fail with this exception.
Regards, Milan Wölke
--
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, 8 months
[JBoss JIRA] Created: (JBAS-3837) WARs nested in EARs fail
by Jason T. Greene (JIRA)
WARs nested in EARs fail
------------------------
Key: JBAS-3837
URL: http://jira.jboss.com/jira/browse/JBAS-3837
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Reporter: Jason T. Greene
Assigned To: Remy Maucherat
The cause appears to be that tomcat expects the location to be expanded, and the deployer does not.
22:00:16,046 ERROR [StandardContext] Error starting static Resources
java.lang.IllegalArgumentException: Document base C:\Documents and Settings\jgreene\Local Settings\Temp\nestedjar10487.tmp does not exist or is not a readable directory
at org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:140)
at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:3940)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4111)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
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.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:296)
at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.apache.catalina.core.StandardContext.init(StandardContext.java:5277)
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.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:296)
at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.web.tomcat.tc6.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:289)
at org.jboss.web.tomcat.tc6.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:120)
at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:362)
at org.jboss.web.deployers.WebModule.startModule(WebModule.java:88)
at org.jboss.web.deployers.WebModule.start(WebModule.java:66)
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:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
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:668)
at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:184)
at $Proxy0.start(Unknown Source)
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
at org.jboss.system.microcontainer.ServiceControllerContextAction.install(ServiceControllerContextAction.java:46)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:226)
at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:198)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:429)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:538)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:472)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:320)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
at org.jboss.system.ServiceController.doChange(ServiceController.java:656)
at org.jboss.system.ServiceController.start(ServiceController.java:431)
at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:124)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:85)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:44)
at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:53)
at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52)
at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:145)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:440)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:381)
at org.jboss.deployment.services.DeploymentManagerService.start(DeploymentManagerService.java:
--
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, 8 months
[JBoss JIRA] Commented: (JBAS-3861) DeploymentFileRepository can be used to write/remove arbitrary files in the filesystem
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3861?page=comments#action_12347865 ]
Dimitris Andreadis commented on JBAS-3861:
------------------------------------------
one-test:
[junit] Running org.jboss.test.console.jbas3861.JBAS3861TestCase
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.411 sec
> DeploymentFileRepository can be used to write/remove arbitrary files in the filesystem
> --------------------------------------------------------------------------------------
>
> Key: JBAS-3861
> URL: http://jira.jboss.com/jira/browse/JBAS-3861
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Management services
> Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA, JBossAS-3.2.8.SP1, JBossAS-3.2.8 Final, JBossAS-4.0.3 Final, JBossAS-4.0.2 Final, JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-3.2.6 Final, JBossAS-4.0.0 Final, JBossAS-3.2.5 Final
> Reporter: Dimitris Andreadis
> Assigned To: Dimitris Andreadis
> Priority: Critical
> Fix For: JBossAS-4.0.5.SP1 , JBossAS-5.0.0.Beta1, JBossAS-4.2.0.CR1, JBossAS-3.2.8.SP2
>
>
> Symantec discovered a flaw in the DeploymentFileRepository
> class of the JBoss application server. A remote attacker who
> is able to access the console manager could read or write to
> files with the permissions of the JBoss user. This could
> potentially lead to arbitrary code execution as the JBoss
> user. (CVE-2006-5750)
> Please note that the JBoss console manager should always be
> secured prior to deployment. By default, the JBoss installer
> gives users the ability to password protect the console
> manager, limiting an attack using this vulnerability to
> authorised users. These steps can also be performed manually.
> http://wiki.jboss.org/wiki/Wiki.jsp?page=SecureJBoss
> This vulnerability afffects all JBoss releases from v3.2.4 to v.4.0.5
--
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, 8 months