[JBoss JIRA] Created: (AS7-1298) JBoss AS 7 doesn't appear to support container-managed security via web.xml and jboss-web.xml
by Craig Ringer (JIRA)
JBoss AS 7 doesn't appear to support container-managed security via web.xml and jboss-web.xml
---------------------------------------------------------------------------------------------
Key: AS7-1298
URL: https://issues.jboss.org/browse/AS7-1298
Project: Application Server 7
Issue Type: Feature Request
Affects Versions: 7.0.0.Final, 7.1.0.Alpha1
Environment: n/a
Reporter: Craig Ringer
There's no documentation for container-managed security in JBoss AS 7, and the schema for the main jboss config files and jboss-web.xml don't suggest any configuration mechanisms for JAAS realms, principal-to-user/group mappings, etc.
This is a significant limitation for apps porting from Glassfish 3, which expect to be able to access the current security principal from JNDI or inject it, and expect to be able to declare container-controlled access to particular URLs and different HTTP methods in web.xml.
Documenting this limitation in AS 7.0.0 would be a big improvement and would save porting time and hassle. Implementing support in a future version would, of course, be ideal.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBAS-8955) Injection of a WebServiceContext in an Interceptor fails when deployed.
by Peer Bech Hansen (JIRA)
Injection of a WebServiceContext in an Interceptor fails when deployed.
-----------------------------------------------------------------------
Key: JBAS-8955
URL: https://issues.jboss.org/browse/JBAS-8955
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB3
Affects Versions: JBossAS-5.1.0.GA
Environment: Windows 7 US, JDK 1.6.22
Reporter: Peer Bech Hansen
Assignee: Carlo de Wolf
Fix For: 6.0.0.Final
http://community.jboss.org/message/589104
public class WebserviceLogInterceptor {
@Resource
private WebServiceContext wsc;
@AroundInvoke
public Object logCall(InvocationContext context) throws Exception {
try {
return context.proceed();
} catch (Exception e) {
throw e;
}
}
}
org.jboss.deployers.spi.DeploymentException: Error deploying Project-1.0-SNAPSHOT.jar: Exception while processing container metadata for EJB: DemoService in unit: Project-1.0-SNAPSHOT.jar
at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:362)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.Exception: Exception while processing container metadata for EJB: DemoService in unit: Project-1.0-SNAPSHOT.jar
at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:549)
at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189)
... 29 more
Caused by: java.lang.ArrayStoreException: org.jboss.injection.WebServiceContextPropertyInjector
at java.util.AbstractCollection.toArray(AbstractCollection.java:171)
at org.jboss.ejb3.interceptor.InterceptorInjector.(InterceptorInjector.java:42)
at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:610)
at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
... 30 more
18:01:38,527 WARN Re: Bug: injecting WebServiceContext at AroundInvoke Failed to process changes
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBRULES-2853) ResourceFactory.newClassPathResource(drlPath) behaves differently on different platforms (linux, windows): it parses the file with different encodings
by Geoffrey De Smet (JIRA)
ResourceFactory.newClassPathResource(drlPath) behaves differently on different platforms (linux, windows): it parses the file with different encodings
------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-2853
URL: https://issues.jboss.org/browse/JBRULES-2853
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Geoffrey De Smet
Assignee: Mark Proctor
Priority: Critical
This really sucks for non English people :) English people write in pure ASCII, so they don't suffer from this problem.
French, Dutch etc mix in Latin-1 chars. Russian, Chinese use something else.
The root problem: There are 2 ways to create an InputStream:
- with encoding = GOOD, use encoding "UTF-8" and there are no problems.
- without encoding: use the default platform encoding = BAD
-- Linux: UTF-8, Windows in Belgium: Latin-1, Windows in China: Chinese-1, Windows in Sweden: Latin-2, ...
-- Java's InputStream should have just defaulted it on UTF-8
Proposition 1: Overloaded method which has an extra String encoding:
- ResourceFactory.newClassPathResource(drlPath, encoding)
- similar tactic as InputStream
Proposition 2: Keep it simple. We decide what a DRL file is.
Just like an XML file says to hell with the specified encoding, so can we.
Note: All XML files default to UTF-8 encoding, and you can overwrite it in a header in the XML file itself (= self-describing): no need to mess around in the java code.
Same principle: All DRL files are default UTF-8 encoding. Optionally we can define an encoding header later.
I strongly prefer proposition 2. The world has got enough encoding problems.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBRULES-1917) JBRMS does not support business rules with non ascii characters
by Gregory Chazalon (JIRA)
JBRMS does not support business rules with non ascii characters
---------------------------------------------------------------
Key: JBRULES-1917
URL: https://jira.jboss.org/jira/browse/JBRULES-1917
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0.7
Reporter: Gregory Chazalon
Assignee: Mark Proctor
A very simple rule containing some Latin1 characters (e.g. 'é', 'à'..), is not compiled correctly when using the JBRMS web app.
The exact same rule defined in a DRL file, and compiled with the drools compiler API is well handled (no characters mismatch).
Actually, the rule defined both ways is :
{code}
rule "latin_message"
when
Let information message
then
information message containing latin characters léger problème à résoudre hôpital
end
{/code}
I strongly suspect a poor character encoding scheme inside the JBRMS code, but I haven't been able to identify it.
The problem is illustrated by the LatinMessageTest test case, bundled inside the small eclipse project provided.
It has two test methods, one building the rule using the drools compiler API, and the other using a binary package built with JBRMS.
The second one fails as of the poor character encoding suspected inside JBRMS web app.
Any help is appreciated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] Created: (JBRULES-1602) The order of RHS statements shouldn't affect behavior (insertLogical)
by Patrick Gras (JIRA)
The order of RHS statements shouldn't affect behavior (insertLogical)
---------------------------------------------------------------------
Key: JBRULES-1602
URL: http://jira.jboss.com/jira/browse/JBRULES-1602
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Drools 4.0.7 & 4.0.4, Java5, eclipse compiler, windows XP.
Reporter: Patrick Gras
Assigned To: Mark Proctor
I have a class 'Cat' that is dynamic (JavaBean with PropertyChangeSupport ) with only a 'name' attribute.
Then I have the following rule:
rule "test"
when
$cat:Cat( name == "tom" )
then
$cat.setName("cat");
insertLogical(new String("test"));
end
When I test the rule against a Cat named tom, the logical inserted fact is not retracted. (So the fact is inserted because the rule matches, but is not retracted even if the rule is no more matching at the end.)
If I change the order of the RHS, it works fine. The fact is inserted and then retracted.
rule "test"
when
$cat:Cat( name == "tom" )
then
insertLogical(new String("test"));
$cat.setName("cat");
end
So the behavior depends on the ordering of the RHS statements.
Here is a complete example to show the problem:
public class Cat {
private String name;
protected PropertyChangeSupport changes = new PropertyChangeSupport(this);
public Cat(String name) {
super();
this.name = name;
}
public String getName() {
return this.name;
}
public void setName(String name) {
final String oldName = this.name;
this.name = name;
this.changes.firePropertyChange("name", oldName, name);
}
public void addPropertyChangeListener(final PropertyChangeListener listener) {
this.changes.addPropertyChangeListener(listener);
}
public void removePropertyChangeListener(
final PropertyChangeListener listener) {
this.changes.removePropertyChangeListener(listener);
}
}
public class RHSOrderingTest {
private static final String PACKAGE = "package ch.generali.pgr.rule ";
private static final String IMPORT = "import ch.generali.pgr.rules.Cat ";
private static final String WHEN = "rule \"test ok\" when $cat:Cat( name == \"tom\" ) ";
private static final String THEN_OK = "then insertLogical(Integer.valueOf(1)); $cat.setName(\"cat\"); end";
private static final String THEN_KO = "then $cat.setName(\"cat\"); insertLogical(Integer.valueOf(1)); end";
private static final String RULE_OK = PACKAGE + IMPORT + WHEN + THEN_OK;
private static final String RULE_KO = PACKAGE + IMPORT + WHEN + THEN_KO;
private static final String QUERY = "query \"My test Integer\" integer : Integer( intValue == 1 ) end";
public static void main(String[] args) {
boolean ok_1 = testWithRule(RULE_OK);
boolean ok_2 = testWithRule(RULE_KO);
System.out.println((ok_1 ? "SUCCESS: " : "FAILED: ") + THEN_OK);
System.out.println((ok_2 ? "SUCCESS: " : "FAILED: ") + THEN_KO);
}
private static boolean testWithRule(String rule) {
Cat tom = new Cat("tom");
RuleBase rb = createRuleBase(rule + "\n" + QUERY);
WorkingMemory wm = rb.newStatefulSession();
wm.insert(tom, true);
wm.fireAllRules();
QueryResults results = wm.getQueryResults("My test Integer");
return results.size() == 0;
}
private static RuleBase createRuleBase(String rules) {
try {
RuleBase ruleBase = RuleBaseFactory.newRuleBase();
PackageBuilderConfiguration conf = new PackageBuilderConfiguration();
PackageBuilder packageBuilder = new PackageBuilder(conf);
Reader source = new StringReader(rules);
packageBuilder.addPackageFromDrl(source);
Package pkg = packageBuilder.getPackage();
ruleBase.addPackage(pkg);
return ruleBase;
} catch (Exception e) {
throw new RuntimeException(e);
}
}
}
--
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
14 years, 1 month
[JBoss JIRA] Created: (JBRULES-2685) Performance degradation from 5.0.1 to 5.1.0
by Greg Barton (JIRA)
Performance degradation from 5.0.1 to 5.1.0
-------------------------------------------
Key: JBRULES-2685
URL: https://jira.jboss.org/browse/JBRULES-2685
Project: Drools
Issue Type: Quality Risk
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.1.0.FINAL
Environment: OSX 1.6.2
Reporter: Greg Barton
Assignee: Mark Proctor
Priority: Minor
Attachments: DroolsNested.tar.gz
I've observed a sizable (25%) performance degradation between the 5.0.1 and 5.1.0 releases. I've attached a sample project that tests the performance of matching nested objects. (ANd compares direct reference matching and the performance pitfalls of "from," but that's beside the current point.)
If you switch the pom.xml from using 5.0.1 to 5.1.0 for the drools dependencies you'll see 25% longer execution times on the tests. (mvn test)
Here's the test output:
5.0.1
reference.drl Count: 2000
reference.drl Time: 267ms
reference.drl Time per element: 0.1335ms
BAR Duplicates: 780
FOO Duplicates: 880
reference.drl Count: 20000
reference.drl Time: 1249ms
reference.drl Time per element: 0.06245ms
BAR Duplicates: 7702
FOO Duplicates: 8040
from.drl Count: 200
from.drl Time: 1139ms
from.drl Time per element: 5.695ms
BAR Duplicates: 112
FOO Duplicates: 102
reference.drl Count: 200
reference.drl Time: 5ms
reference.drl Time per element: 0.025ms
BAR Duplicates: 86
FOO Duplicates: 60
5.1.0
reference.drl Count: 2000
reference.drl Time: 300ms
reference.drl Time per element: 0.15ms
BAR Duplicates: 788
FOO Duplicates: 820
reference.drl Count: 20000
reference.drl Time: 1564ms
reference.drl Time per element: 0.0782ms
BAR Duplicates: 8142
FOO Duplicates: 7960
from.drl Count: 200
from.drl Time: 3543ms
from.drl Time per element: 17.715ms
BAR Duplicates: 68
FOO Duplicates: 90
reference.drl Count: 200
reference.drl Time: 13ms
reference.drl Time per element: 0.065ms
BAR Duplicates: 84
FOO Duplicates: 74
On the most taxing test (20k objects) 5.0.1 took 1249ms while 5.1.0 took 1564ms, and for larger tests the effect is more pronounced. This is primarily a test of == on object references.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] Created: (AS7-1189) When starting up more then one instance by accident can the error messages be better currently they are kinda long
by Jim Tyrrell (JIRA)
When starting up more then one instance by accident can the error messages be better currently they are kinda long
------------------------------------------------------------------------------------------------------------------
Key: AS7-1189
URL: https://issues.jboss.org/browse/AS7-1189
Project: Application Server 7
Issue Type: Feature Request
Reporter: Jim Tyrrell
I do like the fact that address in use do not leave a running instance laying around, I would much rather see one error message rather then pages and pages. To our users this is very overwhelming, especially when they come from our competitors. Also how does this kind of error not have an error code associated with it.
How many other exceptions do not have error codes?
Jim-Tyrrells-MacBook-Pro-2:bin jimtyrrell$ ./standalone.sh
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /Users/jimtyrrell 1/Servers/jboss-7.0.0.CR1
JAVA: java
JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman
=========================================================================
08:38:37,622 INFO [org.jboss.modules] JBoss Modules version 1.0.0.CR4
08:38:37,772 INFO [org.jboss.msc] JBoss MSC version 1.0.0.CR2
08:38:37,812 INFO [org.jboss.as] JBoss AS 7.0.0.CR1 "White Rabbit" starting
08:38:38,328 INFO [org.jboss.as] creating http management service using network interface (management) port (9990) securePort (-1)
08:38:38,333 INFO [org.jboss.as.logging] Removing bootstrap log handlers
08:38:38,343 INFO [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
08:38:38,413 INFO [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
08:38:38,420 INFO [org.jboss.as.naming] (MSC service thread 1-4) Starting Naming Service
08:38:38,425 INFO [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
08:38:38,436 INFO [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
08:38:38,442 INFO [org.jboss.remoting] (MSC service thread 1-10) JBoss Remoting version 3.2.0.Beta2
08:38:38,448 INFO [org.xnio] (MSC service thread 1-10) XNIO Version 3.0.0.Beta3
08:38:38,457 INFO [org.xnio.nio] (MSC service thread 1-10) XNIO NIO Implementation Version 3.0.0.Beta3
08:38:38,606 INFO [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-2) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: .:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
08:38:38,616 INFO [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-10) Starting remote JMX connector
08:38:38,618 INFO [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
08:38:38,618 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-9) MSC00001: Failed to start service jboss.remoting.server.management.9999: org.jboss.msc.service.StartException in service jboss.remoting.server.management.9999: java.net.BindException: Address already in use
at org.jboss.as.remoting.AbstractStreamServerService.start(AbstractStreamServerService.java:98)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind(Native Method) [:1.6.0_24]
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:126) [:1.6.0_24]
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) [:1.6.0_24]
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52) [:1.6.0_24]
at org.xnio.nio.NioXnio.createTcpServer(NioXnio.java:162)
at org.xnio.Xnio.createStreamServer(Xnio.java:230)
at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:162)
at org.jboss.as.remoting.AbstractStreamServerService.start(AbstractStreamServerService.java:93)
... 5 more
08:38:38,623 WARN [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-6) Unable to set the URLStreamHandlerFactory
08:38:38,624 WARN [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-6) Unable to set the ContentHandlerFactory
08:38:38,625 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: Failed to start serverManagement socket
at org.jboss.as.server.mgmt.HttpManagementService.start(HttpManagementService.java:89)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind(Native Method) [:1.6.0_24]
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:126) [:1.6.0_24]
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) [:1.6.0_24]
at org.jboss.sun.net.httpserver.ServerImpl.<init>(ServerImpl.java:112)
at org.jboss.sun.net.httpserver.HttpServerImpl.<init>(HttpServerImpl.java:47)
at org.jboss.sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:37)
at org.jboss.com.sun.net.httpserver.HttpServer.create(HttpServer.java:126)
at org.jboss.as.domain.http.server.ManagementHttpServer.create(ManagementHttpServer.java:99)
at org.jboss.as.server.mgmt.HttpManagementService.start(HttpManagementService.java:86)
... 5 more
08:38:38,632 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-10) MSC00001: Failed to start service jboss.mbean.connector: org.jboss.msc.service.StartException in service jboss.mbean.connector: java.rmi.server.ExportException: Port already in use: 1090; nested exception is:
java.net.BindException: Address already in use
at org.jboss.as.jmx.JMXConnectorService.start(JMXConnectorService.java:106)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
Caused by: java.rmi.server.ExportException: Port already in use: 1090; nested exception is:
java.net.BindException: Address already in use
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:310) [:1.6.0_24]
at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:218) [:1.6.0_24]
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:393) [:1.6.0_24]
at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:129) [:1.6.0_24]
at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:190) [:1.6.0_24]
at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92) [:1.6.0_24]
at sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:68) [:1.6.0_24]
at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:222) [:1.6.0_24]
at org.jboss.as.jmx.JMXConnectorService.start(JMXConnectorService.java:97)
... 5 more
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method) [:1.6.0_24]
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383) [:1.6.0_24]
at java.net.ServerSocket.bind(ServerSocket.java:328) [:1.6.0_24]
at org.jboss.as.network.ManagedServerSocketBinding.bind(ManagedServerSocketBinding.java:73)
at org.jboss.as.network.SocketBinding.createServerSocket(SocketBinding.java:149)
at org.jboss.as.jmx.JMXConnectorService$JMXServerSocketFactory.createServerSocket(JMXConnectorService.java:194)
at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:649) [:1.6.0_24]
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:299) [:1.6.0_24]
... 13 more
08:38:38,634 ERROR [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-13) Error initializing endpoint: java.net.BindException: Address already in use /127.0.0.1:8080
at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:1004)
at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:190)
at org.apache.catalina.connector.Connector.init(Connector.java:976)
at org.apache.catalina.core.StandardService.addConnector(StandardService.java:351)
at org.jboss.as.web.WebServerService.addConnector(WebServerService.java:121)
at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:223)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
08:38:38,636 ERROR [org.apache.catalina.core.StandardService] (MSC service thread 1-13) Connector.initialize: LifecycleException: Protocol handler initialization failed: java.net.BindException: Address already in use /127.0.0.1:8080
at org.apache.catalina.connector.Connector.init(Connector.java:978)
at org.apache.catalina.core.StandardService.addConnector(StandardService.java:351)
at org.jboss.as.web.WebServerService.addConnector(WebServerService.java:121)
at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:223)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
08:38:38,638 ERROR [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-13) Error starting endpoint: java.net.BindException: Address already in use /127.0.0.1:8080
at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:1004)
at org.apache.tomcat.util.net.JIoEndpoint.start(JIoEndpoint.java:1020)
at org.apache.coyote.http11.Http11Protocol.start(Http11Protocol.java:218)
at org.apache.catalina.connector.Connector.start(Connector.java:1051)
at org.apache.catalina.core.StandardService.addConnector(StandardService.java:359)
at org.jboss.as.web.WebServerService.addConnector(WebServerService.java:121)
at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:223)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
08:38:38,639 ERROR [org.apache.catalina.core.StandardService] (MSC service thread 1-13) Connector.start: LifecycleException: service.getName(): "jboss.web"; Protocol handler start failed: java.net.BindException: Address already in use /127.0.0.1:8080
at org.apache.catalina.connector.Connector.start(Connector.java:1058)
at org.apache.catalina.core.StandardService.addConnector(StandardService.java:359)
at org.jboss.as.web.WebServerService.addConnector(WebServerService.java:121)
at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:223)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
08:38:38,675 INFO [org.jboss.as.connector] (MSC service thread 1-6) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
08:38:38,700 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-12) Bound data source [java:jboss/datasources/ExampleDS]
08:38:38,920 INFO [org.jboss.as.deployment] (MSC service thread 1-10) Started FileSystemDeploymentService for directory /Users/jimtyrrell 1/Servers/jboss-7.0.0.CR1/standalone/deployments
08:38:39,130 INFO [org.jboss.as.controller] (Controller Boot Thread) Service status report
Services which failed to start:
service jboss.remoting.server.management.9999: org.jboss.msc.service.StartException in service jboss.remoting.server.management.9999: java.net.BindException: Address already in use
service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: Failed to start serverManagement socket
service jboss.mbean.connector: org.jboss.msc.service.StartException in service jboss.mbean.connector: java.rmi.server.ExportException: Port already in use: 1090; nested exception is:
java.net.BindException: Address already in use
08:38:39,134 ERROR [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.CR1 "White Rabbit" started (with errors) in 1668ms - Started 87 of 146 services (4 services failed or missing dependencies, 55 services are passive or on-demand)
^C08:39:03,929 INFO [org.jboss.as.logging] Restored bootstrap log handlers
08:39:03,933 INFO [com.arjuna.ats.jbossatx] ARJUNA32018: Destroying TransactionManagerService
08:39:03,933 INFO [com.arjuna.ats.jbossatx] ARJUNA32014: Stopping transaction recovery manager
08:39:03,934 INFO [org.jboss.as] JBoss AS 7.0.0.CR1 "White Rabbit" stopped in 4ms
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month