July 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5221) OSGi subsystem cannot get activated through the management API

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-5221: ----------------------------------- Summary: OSGi subsystem cannot get activated through the management API Key: AS7-5221 URL: https://issues.jboss.org/browse/AS7-5221 Project: Application Server 7 Issue Type: Bug Components: OSGi Reporter: Thomas Diesler Assignee: Thomas Diesler Priority: Critical Fix For: 7.2.0.Alpha1 There is regression in subsystem activation through the console/cli -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AS7-5220) tmp/auth/ challenge files are not deleted when access is via JMX client

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/AS7-5220?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated AS7-5220: ---------------------------------- > tmp/auth/ challenge files are not deleted when access is via JMX client > ----------------------------------------------------------------------- > > Key: AS7-5220 > URL: https://issues.jboss.org/browse/AS7-5220 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 7.1.2.Final (EAP) > Reporter: Tom Fonteyne > Assignee: Darran Lofthouse > Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 > > > the authentication process that creates temporary files in tmp/auth is not deleting them when a JMX client connects. > At an extreme, this would be a DOS attack, as the disk could fill up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AS7-5220) tmp/auth/ challenge files are not deleted when access is via JMX client

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/AS7-5220?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse moved JBPAPP-9528 to AS7-5220: ----------------------------------------------- Project: Application Server 7 (was: JBoss Enterprise Application Platform) Key: AS7-5220 (was: JBPAPP-9528) Workflow: GIT Pull Request workflow (was: jira) Affects Version/s: 7.1.2.Final (EAP) (was: EAP 6.0.0 (CR1)) Component/s: Domain Management Security (was: Security) Security: (was: Public) Docs QE Status: (was: NEW) > tmp/auth/ challenge files are not deleted when access is via JMX client > ----------------------------------------------------------------------- > > Key: AS7-5220 > URL: https://issues.jboss.org/browse/AS7-5220 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 7.1.2.Final (EAP) > Reporter: Tom Fonteyne > Assignee: Darran Lofthouse > > the authentication process that creates temporary files in tmp/auth is not deleting them when a JMX client connects. > At an extreme, this would be a DOS attack, as the disk could fill up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AS7-5220) tmp/auth/ challenge files are not deleted when access is via JMX client

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/AS7-5220?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated AS7-5220: ---------------------------------- Fix Version/s: 7.1.3.Final (EAP) 7.2.0.Alpha1 > tmp/auth/ challenge files are not deleted when access is via JMX client > ----------------------------------------------------------------------- > > Key: AS7-5220 > URL: https://issues.jboss.org/browse/AS7-5220 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 7.1.2.Final (EAP) > Reporter: Tom Fonteyne > Assignee: Darran Lofthouse > Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 > > > the authentication process that creates temporary files in tmp/auth is not deleting them when a JMX client connects. > At an extreme, this would be a DOS attack, as the disk could fill up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AS7-5219) CLONE - SingletonService is not stopped after cluster split/merge

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created AS7-5219: ------------------------------------- Summary: CLONE - SingletonService is not stopped after cluster split/merge Key: AS7-5219 URL: https://issues.jboss.org/browse/AS7-5219 Project: Application Server 7 Issue Type: Bug Components: Clustering, MSC Affects Versions: 7.1.2.Final (EAP) Environment: Two servers in standalone-ha mode Reporter: Wolf-Dieter Fink Assignee: Paul Ferraro If a SingletonService is deployed on both nodes it will start on one node only, also it works if nodes are leaving or joining the cluster if it is shutdowned, crashed or started. But in case of a cluster merge I expect that the method stop() will be called. But the service is still running on two nodes after merge. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AS7-4321) OSGi management console needs inspector of wiring

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-4321?page=com.atlassian.jira.plugin.s... ] Thomas Diesler commented on AS7-4321: ------------------------------------- Work on this can start > OSGi management console needs inspector of wiring > ------------------------------------------------- > > Key: AS7-4321 > URL: https://issues.jboss.org/browse/AS7-4321 > Project: Application Server 7 > Issue Type: Feature Request > Components: Console, OSGi > Affects Versions: 7.1.1.Final > Environment: Mac OS X 10.7.3 > Reporter: Tim Diekmann > Assignee: David Bosschaert > Fix For: 7.2.0.CR1 > > > The OSGi management console for AS 7 needs a viewer of the current wiring. The console log showed the following error on start of the bundle and there is no way to inspect the wiring to see where the problem lies and how to solve it. There is some inconsistency in the deployment, but how to find out what? > {code} > 00:09:14,480 ERROR [org.mortbay.log] (HttpManagementService-threads - 3) Error starting handlers: java.lang.IncompatibleClassChangeError: Class org.eclipse.equinox.http.servlet.HttpServiceServlet does not implement the requested interface javax.servlet.Servlet > at org.eclipse.equinox.http.jetty.internal.HttpServerManager$InternalHttpServiceServlet.init(HttpServerManager.java:294) > at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:431) > at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263) > at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:681) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) > at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) > at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) > at org.mortbay.jetty.Server.doStart(Server.java:224) > at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > at org.eclipse.equinox.http.jetty.internal.HttpServerManager.updated(HttpServerManager.java:109) > at org.eclipse.equinox.http.jetty.internal.Activator.start(Activator.java:60) > at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:300) > at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:223) > at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:488) > at org.jboss.as.osgi.parser.BundleRuntimeHandler.handleOperation(BundleRuntimeHandler.java:132) > at org.jboss.as.osgi.parser.BundleRuntimeHandler.executeRuntimeStep(BundleRuntimeHandler.java:89) > at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:90) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:387) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:274) > at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:202) > at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:461) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:387) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:274) > at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:202) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121) > at org.jboss.as.controller.ModelControllerImpl$1.execute(ModelControllerImpl.java:304) > at org.jboss.as.controller.ModelControllerImpl$1.execute(ModelControllerImpl.java:294) > at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:294) > at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:201) > at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:208) > at org.jboss.as.domain.http.server.security.SubjectAssociationHandler.handle(SubjectAssociationHandler.java:51) > at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78) > at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69) > at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81) > at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710) > at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78) > at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:54) > at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81) > at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_29] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_29] > at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_29] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AS7-5214) BundleContext not properly injected for non ARQ deployments

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-5214: ----------------------------------- Summary: BundleContext not properly injected for non ARQ deployments Key: AS7-5214 URL: https://issues.jboss.org/browse/AS7-5214 Project: Application Server 7 Issue Type: Bug Components: OSGi, Test Suite Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: 7.2.0.Alpha1 Currently there is a processing step in the arquillian-service that scans the deployment for @Inject fields of type org.osgi.framework. If found, it activates the Framework. This approach is flawed because it only works for deployments that come in through ARQ. {code} @Inject BundleContext {code} should work for other deployment paths too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AS7-5213) Add org.osgi.core dependency to ARQ generated test deployments

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-5213: ----------------------------------- Summary: Add org.osgi.core dependency to ARQ generated test deployments Key: AS7-5213 URL: https://issues.jboss.org/browse/AS7-5213 Project: Application Server 7 Issue Type: Task Components: OSGi, Test Suite Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: 7.2.0.Alpha1 We have a number of test deployments that integrate with OSGi, but don't have the necessary module dependencies. Currently such a deployment has to use code like this {code} @Deployment public static JavaArchive createdeployment() { final JavaArchive archive = ShrinkWrap.create(JavaArchive.class, "example-javaee"); archive.addClasses(HttpSupport.class); archive.setManifest(new Asset() { @Override public InputStream openStream() { ManifestBuilder builder = ManifestBuilder.newInstance(); builder.addManifestHeader("Dependencies", "org.osgi.core"); return builder.openStream(); } }); return archive; } {code} The ARQ protocol layer should transparently handle this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1306) Remoting tries to create SSLSocketFactory even when not desired

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1306?page=com.atlassian.jira.plugin... ] Ron Sigal commented on JBREM-1306: ---------------------------------- Updated documentation. > Remoting tries to create SSLSocketFactory even when not desired > --------------------------------------------------------------- > > Key: JBREM-1306 > URL: https://issues.jboss.org/browse/JBREM-1306 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.2.4, 2.5.4.SP3 > Reporter: Kyle Lape > Assignee: Ron Sigal > Priority: Minor > Fix For: 2.2.4.SP1, 2.5.4.SP4 > > > Running the following code is an alternative way to set the keystore/truststore in a remoting client: > {noformat} > KeyStore ksTrust = KeyStore.getInstance("JKS"); > ksTrust.load(new FileInputStream("testTrust"), passphrase); > TrustManagerFactory tmf = > TrustManagerFactory.getInstance("SunX509"); > tmf.init(ksTrust); > SSLContext sslContext = SSLContext.getInstance("TLS"); > sslContext.init(null, tmf.getTrustManagers(), null); > HttpsURLConnection.setDefaultSSLSocketFactory(sslContext.getSocketFactory()); > {noformat} > When this code is added, Remoting should not try to create its own {{SSLSocketFactory}}. Currently there is no way to tell Remoting to not try. This causes a confusing ERROR message: > {noformat} > Error creating SSL Socket Factory for client invoker: Error initializing socket factory SSL context: Can not find truststore url. > {noformat} > After this message is logged, the client still works because it falls back to the default {{SSLSocketFactory}} (that was already set). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AS7-4366) Facelets and JSF composite components doesn't work together on JBoss 7.1.1.Final

by Devinder Singh (JIRA)

Devinder Singh created AS7-4366: ----------------------------------- Summary: Facelets and JSF composite components doesn't work together on JBoss 7.1.1.Final Key: AS7-4366 URL: https://issues.jboss.org/browse/AS7-4366 Project: Application Server 7 Issue Type: Bug Components: JSF Affects Versions: 7.1.1.Final Environment: Operating System: Redhat 5.5 Linux; Firefox browser on redhat Linux Reporter: Devinder Singh Assignee: Stan Silvert Priority: Blocker Facelets and composite components doesn't work together with 7.1.1 final. Same code use to work with Jboss 7.1.0 release. Below link to the forum has all the details. This is a critical bug that can prevent us from migrating to 7.1.1 Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

7
21
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2012