September 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (AS7-1301) Update OSGi to be compatible with JBoss Modules 1.1 series

by David Lloyd (JIRA)

Update OSGi to be compatible with JBoss Modules 1.1 series ---------------------------------------------------------- Key: AS7-1301 URL: https://issues.jboss.org/browse/AS7-1301 Project: Application Server 7 Issue Type: Task Components: OSGi Reporter: David Lloyd Assignee: Thomas Diesler Fix For: 7.1.0.Alpha1 JBoss Modules 1.1 has two significant changes. First, jaxpmodule is eliminated. Second, the system module is no more - instead there's a dependency type for the system class loader. I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

5
19
0 / 0

[JBoss JIRA] Created: (AS7-1376) Implement EE.10 Application Clients

by Carlo de Wolf (JIRA)

Implement EE.10 Application Clients ----------------------------------- Key: AS7-1376 URL: https://issues.jboss.org/browse/AS7-1376 Project: Application Server 7 Issue Type: Task Components: EE Reporter: Carlo de Wolf Assignee: David Lloyd Priority: Critical Fix For: 7.1.0.CR1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

4
3
0 / 0

[JBoss JIRA] Created: (AS7-1876) Field type resolution in @Resource doesn't occur (<env-entry-type> in ejb-jar.xml is required)

by Pedro Kowalski (JIRA)

Field type resolution in @Resource doesn't occur (<env-entry-type> in ejb-jar.xml is required) ---------------------------------------------------------------------------------------------- Key: AS7-1876 URL: https://issues.jboss.org/browse/AS7-1876 Project: Application Server 7 Issue Type: Bug Components: EJB Affects Versions: 7.0.1.Final Environment: GNU/Linux Ubuntu 11.04 x86 Reporter: Pedro Kowalski Assignee: Carlo de Wolf While using @Resource on a field in EJB and defining it's value in ejb-jar.xml, the field type doesn't seem to be automatically resolved. It must be explicitly defined using <env-entry-type>. I attach exemplary application (+ sources) here: http://community.jboss.org/servlet/JiveServlet/download/627566-41282/ENVT... The deployment will fail if the following line is commented: <env-entry-type>java.lang.String</env-entry-type> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Could not determine type for <env-entry> java:comp/env/myEntry please specify the <env-entry-type>. After uncommenting it, the deployment runs fine. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

4
5
0 / 0

[JBoss JIRA] Created: (JBLOGGING-72) Debug log lines numbers are incorrect

by Hardy Ferentschik (JIRA)

Debug log lines numbers are incorrect ------------------------------------- Key: JBLOGGING-72 URL: https://issues.jboss.org/browse/JBLOGGING-72 Project: JBoss Logging Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.0.GA Reporter: Hardy Ferentschik Assignee: David Lloyd Priority: Critical In Hibernate we switched to JBoss logging. Looking at the debug log we get for example: {noformat} 11:20:06,528 (main) DEBUG ConfigContext:1269 - Setting Lucene compatibility to Version LUCENE_CURRENT 11:20:06,529 (main) DEBUG ConfigContext:1554 - Using default similarity implementation: org.apache.lucene.search.DefaultSimilarity 11:20:06,529 (main) DEBUG LuceneIndexingParameters:1559 - Set index writer parameter max_buffered_docs to value : 1000 11:20:06,529 (main) DEBUG LuceneIndexingParameters:1559 - Set index writer parameter merge_factor to value : 100 11:20:06,529 (main) DEBUG WorkspaceFactory:1549 - Starting workspace for index numeric_field_test using an exclusive index strategy 11:20:06,530 (main) INFO AvroSerializationProvider:73 - HSEARCH000079: Serialization protocol version 1.0 11:20:06,535 (main) DEBUG DocumentBuilderIndexedEntity:1559 - Field selection in projections is set to true for entity org.hibernate.search.test.engine.PinPoint. 11:20:06,536 (main) DEBUG DocumentBuilderIndexedEntity:1559 - Field selection in projections is set to true for entity org.hibernate.search.test.engine.Location. 11:20:06,537 (main) DEBUG FullTextIndexEventListener:1269 - Hibernate Search event listeners activated 11:20:06,537 (main) DEBUG FullTextIndexEventListener:1269 - Hibernate Search dirty checks enabled {noformat} The lines numbers for the debug trace are wrong and in most cases exceed even the actual line numbers in the corresponding file -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

9
10
0 / 0

[JBoss JIRA] Created: (LOGTOOL-29) The tooling does not properly implement the @FormatWith annotation

by James Perkins (JIRA)

The tooling does not properly implement the @FormatWith annotation ------------------------------------------------------------------ Key: LOGTOOL-29 URL: https://issues.jboss.org/browse/LOGTOOL-29 Project: Log Tool Issue Type: Bug Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: James Perkins Fix For: 1.0.0.Beta9 The equals on line 67 of the ParameterFactory does not work correctly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

4
3
0 / 0

[JBoss JIRA] Created: (JBLOGGING-52) Use of system property for proxy generation setting is too inflexible

by Dan Allen (JIRA)

Use of system property for proxy generation setting is too inflexible --------------------------------------------------------------------- Key: JBLOGGING-52 URL: https://issues.jboss.org/browse/JBLOGGING-52 Project: JBoss Logging Issue Type: Bug Security Level: Public (Everyone can see) Components: jboss-logging-spi Affects Versions: 3.0.0.Beta4-jboss-logging Reporter: Dan Allen Assignee: David Lloyd Fix For: 3.0.0.Beta5-jboss-logging JBoss Logging uses a system property to configure whether or not proxies are generated for type-safe loggers. This approach is very inflexible. The main issue is that the value of this system property is being cached too aggressively. In CDI extensions, we are forced to use a static code block to set the property so it is assigned early enough that JBoss Logging caches the correct value. However, with multiple extensions loading in a non-deterministic order, we end up having to put this static block in multiple places. [1] We need a better way to apply this setting. Perhaps a static method on a configuration API to assign the value before any logging takes place. [1] https://github.com/seam/solder/blob/master/impl/src/main/java/org/jboss/s... https://github.com/seam/servlet/blob/master/impl/src/main/java/org/jboss/... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

5
12
0 / 0

[JBoss JIRA] Created: (AS7-1794) urn:jboss:pojo:7.0 is a subset of *-jboss-beans.xml, aplication-policy is not available

by Karel Piwko (JIRA)

urn:jboss:pojo:7.0 is a subset of *-jboss-beans.xml, aplication-policy is not available --------------------------------------------------------------------------------------- Key: AS7-1794 URL: https://issues.jboss.org/browse/AS7-1794 Project: Application Server 7 Issue Type: Bug Environment: AS 7.1.0-Alpha1-SNAPSHOT - commit 335c262c7449e4f6667b5339838bfdf0a65f5263 Reporter: Karel Piwko I'm migrating an application which has security domain defined in *-jboss-beans.xml from AS 5 to AS 7. {code:xml} <?xml version="1.0" encoding="UTF-8"?> <deployment xmlns="urn:jboss:pojo:7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:jboss:pojo:7.0 jboss-pojo_7_0.xsd"> <application-policy name="security-preauth"> <authentication> <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"> <module-option name="usersProperties" value="security-preauth-users.properties" /> <module-option name="rolesProperties" value="security-preauth-roles.properties" /> </login-module> </authentication> </application-policy> </deployment> {code} This security domain is specified in jboss-web.xml, as: {code:xml} <?xml version="1.0" encoding="UTF-8"?> <jboss-web> <security-domain>security-preauth</security-domain> <context-root>spring-preauth</context-root> </jboss-web> {code} Here's corresponding configuration in web.xml {code:xml} <login-config> <auth-method>BASIC</auth-method> <realm-name>security-preauth</realm-name> </login-config> <security-role> <role-name>ROLE_USER</role-name> </security-role> <security-role> <role-name>ROLE_SUPERVISOR</role-name> </security-role> <security-constraint> <web-resource-collection> <web-resource-name>All areas</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>ROLE_USER</role-name> </auth-constraint> </security-constraint> {code} This is not correctly loaded by JBoss AS, failing with (after TRACE logging is enabled): {code} 16:46:44,287 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.deployment.unit."spring-preauth.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."spring-preauth.war".PARSE: Failed to process phase PARSE of deployment "spring-preauth.war" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) [jboss-as-server-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] 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:662) [:1.6.0_24] Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to parse POJO xml ["/content/spring-preauth.war/META-INF/security-preauth-jboss-beans.xml"] at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptor(KernelDeploymentParsingProcessor.java:130) at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptors(KernelDeploymentParsingProcessor.java:104) at org.jboss.as.pojo.KernelDeploymentParsingProcessor.deploy(KernelDeploymentParsingProcessor.java:73) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT] ... 5 more Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[5,5] Message: Unexpected element '{urn:jboss:pojo:7.0}application-policy' encountered at org.jboss.as.controller.parsing.ParseUtils.unexpectedElement(ParseUtils.java:65) at org.jboss.as.pojo.descriptor.KernelDeploymentXmlDescriptorParser.readElement(KernelDeploymentXmlDescriptorParser.java:174) at org.jboss.as.pojo.descriptor.KernelDeploymentXmlDescriptorParser.readElement(KernelDeploymentXmlDescriptorParser.java:50) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100) at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59) at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptor(KernelDeploymentParsingProcessor.java:123) ... 8 more {code} Note: With AS 7.0.1 this is not working at all, *-jboss-beans.xml is ignored. Workaround is modify standalone.xml and add the security domain there, but it's not a feasible solution as it makes automated testing much harder. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

6
12
0 / 0

[JBoss JIRA] Created: (AS7-1927) An EAR with 'urn:jboss:bean-deployer:2.0' namespace in META-INF/jboss-beans.xml can be deloyed to AS7 without any error

by Ivo Studensky (JIRA)

An EAR with 'urn:jboss:bean-deployer:2.0' namespace in META-INF/jboss-beans.xml can be deloyed to AS7 without any error ----------------------------------------------------------------------------------------------------------------------- Key: AS7-1927 URL: https://issues.jboss.org/browse/AS7-1927 Project: Application Server 7 Issue Type: Bug Components: EE Affects Versions: 7.1.0.Alpha1 Reporter: Ivo Studensky Assignee: David Lloyd An ear with no longer supported 'urn:jboss:bean-deployer:2.0' namespace in META-INF/jboss-beans.xml can be deployed to AS7 without any error. I tried to deploy it via command line copy and via web admin console. Both of them passed which is weird, because the same ear failed to deploy by Arquillian. If I modified the namespace to 'urn:jboss:pojo:7.0' then deployment by Arquillian passed too. It seems like META-INF/jboss-beans.xml is not fully processed if deployed by command line copy or by web admin console. Note: it was tried with the latest master of AS7. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

8
9
0 / 0

[JBoss JIRA] Created: (JBAS-9316) Indentation of multiline text content in standalone.xml keeps increasing on rewrites

by David Bosschaert (JIRA)

Indentation of multiline text content in standalone.xml keeps increasing on rewrites ------------------------------------------------------------------------------------ Key: JBAS-9316 URL: https://issues.jboss.org/browse/JBAS-9316 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: XML Services/Frameworks Affects Versions: 7.0.0.Beta3 Reporter: David Bosschaert Assignee: Jason Greene Priority: Minor The standalone.xml file contains some XML tags that contain multi-line XML text, e.g.: {code}<property name="org.jboss.osgi.system.modules"> org.apache.log4j, org.jboss.as.osgi, javax.inject.api, ...{code} The problem is that every automatic rewrite of the standalone.xml (e.g. when you deploy a new thing) the indentation increases from the 2nd line of the text, so after the first rewrite it looks like this: {code}<property name="org.jboss.osgi.system.modules"> org.apache.log4j, org.jboss.as.osgi, javax.inject.api, ...{code} after a few deploys it ends up looking like this: {code}<property name="org.jboss.osgi.system.modules"> org.apache.log4j, org.jboss.as.osgi, javax.inject.api, ...{code} Pretty ugly :( Would be nice if the indentation could be left untouched. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

6
5
0 / 0

[JBoss JIRA] Created: (AS7-1907) Provide suppor for expression across all form elements

by Heiko Braun (JIRA)

Provide suppor for expression across all form elements ------------------------------------------------------ Key: AS7-1907 URL: https://issues.jboss.org/browse/AS7-1907 Project: Application Server 7 Issue Type: Feature Request Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Priority: Blocker Fix For: 7.1.0.Alpha1 bstansberry: <inet-address value="${jboss.bind.address:127.0.0.1}"/> [3:11pm] hbraun: the first part is resolved from system properties? [3:11pm] hbraun: the later is the default? [3:11pm] bstansberry: yes [3:11pm] hbraun: wicked [3:12pm] bstansberry: but what's stored in the model is a ModelNode of type ModelType.EXPRESSION [3:12pm] bstansberry: and the metadata for the attribute includes "expression-allowed" => true [3:12pm] hbraun: ok [3:13pm] hbraun: did you just want to raise my attention? [3:13pm] bstansberry: those really should appearing all over the place [3:13pm] bstansberry: yeah [3:14pm] bstansberry: really a very heavy % of attributes should allow expressions [3:14pm] hbraun: damn [3:14pm] hbraun: i need to think about the implications [3:14pm] hbraun: for the UI [3:15pm] hbraun: so attributes actually allow multiple types? [3:15pm] hbraun: i.e. string or expression [3:15pm] bstansberry: yes, X or expression [3:15pm] bstansberry: where X is the "type" = X in the metadata [3:16pm] hbraun: do we have proper setters for expression values? [3:16pm] hbraun: in the DMR lib I mean? [3:16pm] hbraun: or how does it currently work [3:16pm] hbraun: ? [3:16pm] bstansberry: ModeNode.setExpression(String s) [3:16pm] hbraun: i.e. how do you create an add operation that contains an expression? [3:16pm] hbraun: ah, guess we didn't port that to the GWT lib yet -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

3
3
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 September 2011