[JBoss JIRA] (AS7-4615) Define a database of system modules
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-4615:
-----------------------------------
Summary: Define a database of system modules
Key: AS7-4615
URL: https://issues.jboss.org/browse/AS7-4615
Project: Application Server 7
Issue Type: Task
Components: OSGi, Server
Reporter: Thomas Diesler
Assignee: Thomas Diesler
The OSGi configuration supports ModuleIdentifiers. So for example
{code}
<capability name="javax.transaction.api"/>
{code}
references the JTA API module. This actually delegates to the repository implementations which in turn delegates to the ModuleIdentityArtifactProvider.
If the AppServer supports the notion of multiple directories where modules can get loaded from, the ServerEnvironment should reflect that properly. I cannot just load a module on trial/error basis because we use the Repository for impact ananlysis. i.e. Find the modules/bundles that provide the transitive set of capabilities for a given set of requirements (without modifying the runtime).
--
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, 9 months
[JBoss JIRA] (AS7-5051) Allow EE deployments to define dependency requirements with OSGi metadata
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-5051:
-----------------------------------
Summary: Allow EE deployments to define dependency requirements with OSGi metadata
Key: AS7-5051
URL: https://issues.jboss.org/browse/AS7-5051
Project: Application Server 7
Issue Type: Task
Components: OSGi
Reporter: Thomas Diesler
Assignee: Thomas Diesler
This essentially means that you can put OSGi metadata into an EE deployment manifest, which essentially makes it an OSGi bundle.
Deployment unit processing should be such that the EE bundle gets resolved according to it's defined capabilities/requirements. Subsystem processors should not need to care whether the Module was created as a result of OSGi resolution or by the ModuleSpecProcessor.
This task is complete when we can do this with the EE core technologies (i.e. webapp, ejb3, cdi)
--
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, 9 months
[JBoss JIRA] (AS7-3019) Arquillian Managed Container fails to start JBoss AS with ServiceNotFoundException
by Martin Gencur (Created) (JIRA)
Arquillian Managed Container fails to start JBoss AS with ServiceNotFoundException
----------------------------------------------------------------------------------
Key: AS7-3019
URL: https://issues.jboss.org/browse/AS7-3019
Project: Application Server 7
Issue Type: Bug
Components: Test Suite
Reporter: Martin Gencur
Assignee: Aslak Knutsen
Affects JBossAS 7.1.0.CR1-SNAPSHOT (HEAD=d9e236d - Update timeout to be more reasonable with load)
When I'm starting AS with jboss-as-arquillian-container-managed (7.1.0.CR1-SNAPSHOT), I get the following exception (no configuration in standalone.xml was changed after building the distribution):
14:57:41,690 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS 7.1.0.CR1-SNAPSHOT "Tesla" started in 3547ms - Started 131 of 200 services (68 services are passive or on-demand)
14:57:42,037 ERROR [org.jboss.as.controller.management-operation] (pool-1-thread-1) JBAS014612: Operation ("read-attribute") failed - address: ({
"socket-binding-group" => "standard-sockets",
"socket-binding" => "undefined"
}): org.jboss.msc.service.ServiceNotFoundException: Service service jboss.binding.undefined not found
at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:447) [jboss-msc-1.0.1.GA.jar:]
at org.jboss.as.server.services.net.BindingMetricHandlers$AbstractBindingMetricsHandler$1.execute(BindingMetricHandlers.java:66) [jboss-as-server-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:359) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:254) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:190) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.server.services.net.BindingMetricHandlers$AbstractBindingMetricsHandler.execute(BindingMetricHandlers.java:76) [jboss-as-server-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.server.services.net.BindingMetricHandlers$BoundAddressHandler.execute(BindingMetricHandlers.java:106) [jboss-as-server-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.operations.global.GlobalOperationHandlers$ReadAttributeHandler.doExecute(GlobalOperationHandlers.java:452) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:974) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:359) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:254) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:190) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:432) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:359) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:254) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:190) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:119) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:121) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:98) [jboss-as-controller-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$3$1.doExecute(AbstractMessageHandler.java:268) [jboss-as-protocol-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:424) [jboss-as-protocol-7.1.0.CR1-SNAPSHOT.jar:]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Starting the same AS manually works fine.
--
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, 9 months
[JBoss JIRA] (AS7-4929) JBoss7 Fails ASV Scan Report Attestation of Scan Compliance
by Carlos Oliva (JIRA)
Carlos Oliva created AS7-4929:
---------------------------------
Summary: JBoss7 Fails ASV Scan Report Attestation of Scan Compliance
Key: AS7-4929
URL: https://issues.jboss.org/browse/AS7-4929
Project: Application Server 7
Issue Type: Quality Risk
Affects Versions: 7.0.2.Final
Environment: Centos
Reporter: Carlos Oliva
Fix For: 7.0.2.SP1
ASV Scan Report Attestation of Scan Compliance. Vulnerabilities Noted for each IP Address
https (tcp/443)
GET
/LETtoaCuluFoy4DePCwPLiT0HI1s36zHz9s712uSci
4zxnjnmPAmXpdcnGMYmVwDfBGtXI6zXgIJ1YC8lqJ0T
YlUP8hajSNTWZJH7RUk1K6JHLGgGnDaMfSojaxweHvj
cnRe3KKTJ8miLU3U3XnS4KZ4bihRqT2rIkowzQJHSk9
VbbQ26pdrzLoImGB4v9lqUFyewXsahnz55dwjEDBNRE
ZEbS7b67a<font%20size=50>DEFACED<!--//-- :
MyWebServer 1.0.2 is vulnerable to HTML
injection. Upgrade to a later version.
CVE-2002-1453
Medium 4.3 Fail
http (tcp/80)
GET
/LNSAZoL2iuV3PmcrZl0W5YhMwILOBPbZwzEHVi5QAM
dlOJcFL6Y0Ihv21bU7R3461Q80T3CFq9WqFvx3lfcgs
MIZ4MDac8YVcxkBralskmulwlrf5JnvLuewKZ402AkB
LBIK0CZY7ajOn7U9xzZ0LAgwAzrUaw9UViczNtTyvEK
hm7WnyF5dfR084QH966s324XgjXktxVXXaqe7xtf3d5
bTukJXDoo<font%20size=50>DEFACED<!--//-- :
MyWebServer 1.0.2 is vulnerable to HTML
injection. Upgrade to a later version.
CVE-2002-1453
--
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, 9 months
[JBoss JIRA] (AS7-5275) Vault shared key is displaying the byte[] address
by Jeff Mesnil (JIRA)
Jeff Mesnil created AS7-5275:
--------------------------------
Summary: Vault shared key is displaying the byte[] address
Key: AS7-5275
URL: https://issues.jboss.org/browse/AS7-5275
Project: Application Server 7
Issue Type: Bug
Components: Security
Environment: AS7 trunk branch
Reporter: Jeff Mesnil
Assignee: Anil Saldhana
Priority: Critical
I added a secured attribute with vault.sh but the shared key looked suspicious:
{noformat}
********************************************
Vault Block:HQ
Attribute Name:thePass
Shared Key:[B@52621f0c
Configuration should be done as follows:
VAULT::HQ::thePass::[B@52621f0c
********************************************
{noformat}
Looking at VaultSession#attributeCreatedDisplay(), the byte[] handshakeKey is displayed by calling toString() => this displays its address, not a textual representation of the bytes.
When the shared key is read in RuntimeVaultReader, we call String.getBytes() to get back the byte[].
A simple fix is to display the handshakeKey with new String(handshakeKey).
However this will work only if the default charset is the same on machines that store the secured attribute and read from it.
It'd be safe to use always the same Charset (e.g. US-ASCII or UTF-8).
I've raised the priority to critical since it is not possible to use any secured attribute if the handshake is not properly displayed
--
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, 9 months
[JBoss JIRA] (AS7-4301) JBOSS 7.1.1 turkish locale problem at startup
by Serkan Yıldırım (JIRA)
Serkan Yıldırım created AS7-4301:
------------------------------------
Summary: JBOSS 7.1.1 turkish locale problem at startup
Key: AS7-4301
URL: https://issues.jboss.org/browse/AS7-4301
Project: Application Server 7
Issue Type: Bug
Components: Server
Affects Versions: 7.1.1.Final
Environment: Windows 7 x64
Java 1.6 update 26
Locale: Turkish
Reporter: Serkan Yıldırım
Assignee: Jason Greene
Hi,
When i run standalone.bat with turkish locale, i got exception below. If I change locale to english, it starts with no problem. However, it is not a good solution to give locale as parameter at startup I think. Our environment works in Turkish locale for example. We want JBOSS AS to run in turkish locale also.
When i looked at the exception, i saw that in ThreadsParser class at line 882, there is a code piece like:
882 unit = Enum.valueOf(TimeUnit.class, value.toUpperCase());
At this line in upperCase method, 'i' is converted to capital letter I with dot above when locale is turkish due to information at "http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/String.html#toUppe..."
Therefore enum is not found and we got exception. If we give locale english as parameter to jboss as at startup, conversion is done correctly at the code above and enum is found.
Calling "D:\Development\Servers\jboss-as-7.1.1.Final\bin\standalone.conf.bat"
===============================================================================
JBoss Bootstrap Environment
JBOSS_HOME: D:\Development\Servers\jboss-as-7.1.1.Final
JAVA: C:\Program Files (x86)\Java\jdk1.6.0_26\bin\java
JAVA_OPTS: -XX:+TieredCompilation -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.
rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djb
oss.server.default.config=standalone.xml -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
===============================================================================
Listening for transport dt_socket at address: 8787
13:42:59,798 INFO [org.jboss.modules] JBoss Modules version 1.1.1.GA
13:43:00,496 INFO [org.jboss.msc] JBoss MSC version 1.0.2.GA
13:43:00,532 INFO [org.jboss.as] JBAS015899: JBoss AS 7.1.1.Final "Brontes" starting
13:43:02,146 ERROR [org.jboss.as.server] JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceExcepti
on: JBAS014676: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:141) [jboss-as-controller-7.1.1.Final.jar
:7.1.1.Final]
at org.jboss.as.server.ServerService.boot(ServerService.java:266) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Fina
l]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26]
Caused by: java.lang.IllegalArgumentException: No enum const class java.util.concurrent.TimeUnit.M¦LL¦SECONDS
at java.lang.Enum.valueOf(Enum.java:196) [rt.jar:1.6.0_26]
at org.jboss.as.threads.ThreadsParser.parseTimeSpec(ThreadsParser.java:874)
at org.jboss.as.threads.ThreadsParser.parseUnboundedQueueThreadPool(ThreadsParser.java:518)
at org.jboss.as.ejb3.subsystem.EJB3Subsystem12Parser.parseThreadPools(EJB3Subsystem12Parser.java:1103)
at org.jboss.as.ejb3.subsystem.EJB3Subsystem12Parser.readElement(EJB3Subsystem12Parser.java:297)
at org.jboss.as.ejb3.subsystem.EJB3Subsystem12Parser.readElement(EJB3Subsystem12Parser.java:55)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:894) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_1(StandaloneXml.java:330) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:127) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:100) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:133) [jboss-as-controller-7.1.1.Final.jar
:7.1.1.Final]
... 3 more
13:43:02,160 FATAL [org.jboss.as.server] JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
13:43:02,179 INFO [org.jboss.as] JBAS015950: JBoss AS 7.1.1.Final "Brontes" stopped in 2ms
Press any key to continue . . .
--
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, 9 months
[JBoss JIRA] (AS7-5249) Server freezes on marhalling exception
by Frank Ulbricht (JIRA)
Frank Ulbricht created AS7-5249:
-----------------------------------
Summary: Server freezes on marhalling exception
Key: AS7-5249
URL: https://issues.jboss.org/browse/AS7-5249
Project: Application Server 7
Issue Type: Bug
Components: Server
Affects Versions: 7.1.1.Final
Environment: Windows 7 64 bit, Java 1.7.0 64 bit
Reporter: Frank Ulbricht
Assignee: Jason Greene
Attachments: jboss-freeze-build.zip
If the server throwns an exception that is not in the classpath of a remote client, a ClassNotFoundException is thrown by the marshalling (River). This can be expected but after this the server freezes and does not anser anymore (btw: the http services still answers).
The attachted sample application was originally a try to hide the server exceptions from the client. It is an Eclipse/Maven project. If you remove the comment from the @Interceptors line in class HelloControllerBean everything works fine because the exception gets converted. But if executed as provided the expected ClassNotFoundException on the client will be thrown and after this the server freezes. You can not run the client again and Ctrl+C does not terminate the server.
--
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, 9 months