March 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8827) Deal with expression values in all operation handlers

by Brian Stansberry (JIRA)

Deal with expression values in all operation handlers ----------------------------------------------------- Key: JBAS-8827 URL: https://issues.jboss.org/browse/JBAS-8827 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Priority: Critical Fix For: 7.0.0.Beta1 Pretty much any simple value in a detyped operation can be of type ModelType.EXPRESSION instead something an OperationHandler might expect, like ModelType.STRING or ModelType.INT. All handlers need to deal with this fact. There are two main aspects to this: 1) Any parameter validation that goes on needs to account for the presence of expression values. Basically that means a) accept the expression for storage in the model b) call resolve() on the operation and use the resolved version for application to the runtime. c) re-validation of the resolved value may be necessary -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

6
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2110) Add flag to enable an optimization to skip serialization/deserialization of Remote interfaces running locally

by Ben Schofield (JIRA)

Add flag to enable an optimization to skip serialization/deserialization of Remote interfaces running locally ------------------------------------------------------------------------------------------------------------- Key: EJBTHREE-2110 URL: https://jira.jboss.org/browse/EJBTHREE-2110 Project: EJB 3.0 Issue Type: Feature Request Reporter: Ben Schofield When an application uses a remote EJB3 interface the call is serialized and deserialized. While mandated by spec this is unnecessary if the EJB is running in the same JVM as the calling client. Having the option to skip serialization would bring JBoss inline with other major JEE vendors. Performance tests on a transactional application that has all business logic in stateless session bean methods is showing 20% cpu overhead just for the serialization. Having 20% more production CPU capacity is more important than claiming strict EJB3 compliance. JBoss AS response times are better too. -- 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, 3 months

5
12
0 / 0

[JBoss JIRA] Created: (JBAS-9096) Management only domain mode

by Brian Stansberry (JIRA)

Management only domain mode --------------------------- Key: JBAS-9096 URL: https://issues.jboss.org/browse/JBAS-9096 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Fix For: 7.0.0.Beta4 See parent task for core concept. With domain mode this is fairly simple. A host controller / domain controller is essentially a "management only" process. So implement this feature should be a simple matter of adding a command line flag that tells the process not to launch servers. If the host is the master DC, we need to think through what the behavior should be if a remote host tries to register. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

6
12
0 / 0

[JBoss JIRA] Created: (JBJCA-496) IronJacamar under a security manager

by Jesper Pedersen (JIRA)

IronJacamar under a security manager ------------------------------------ Key: JBJCA-496 URL: https://issues.jboss.org/browse/JBJCA-496 Project: IronJacamar Issue Type: Task Components: Test suite Reporter: Jesper Pedersen Assignee: Peter Skopek We should have a test case which tests deploying a resource adapter to IronJacamar running under a security manager. The rules should be as strict as possible to catch any issues. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8135) By default use a common identifier anywhere a server "id" notion is exposed in the configuration

by Brian Stansberry (JIRA)

By default use a common identifier anywhere a server "id" notion is exposed in the configuration ------------------------------------------------------------------------------------------------ Key: JBAS-8135 URL: https://jira.jboss.org/browse/JBAS-8135 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 7.0.0.M1 This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010: >> * JBoss Transactions, jvm-route, jboss messaging all require a >> unique identifier for them to behave properly in a clustered >> environment. I would like one unique identifier for each server >> configuration and for all services that need a unique identifier >> to reference it by default. Then I don't have to worry about >> unique identifiers when creating new servers. (The jboss messaging bit is out of date with respect to AS 7, which will use HornetQ and thus has no ServerPeerId configuration required. But the basic point is spot-on.) -- 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, 3 months

6
14
0 / 0

[JBoss JIRA] Created: (JBAS-9193) Tighten up the ServerEnvironment and HostControllerEnvironment contracts

by Brian Stansberry (JIRA)

Tighten up the ServerEnvironment and HostControllerEnvironment contracts ------------------------------------------------------------------------ Key: JBAS-9193 URL: https://issues.jboss.org/browse/JBAS-9193 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Fix For: 7.0.0.Beta4 Right now the contract/usage of these classes is a bit of a mishmash. The idea was to store state that's read from Main(). But if there's anything in these that can be overridden from standalone.xml, either we should restrict access to that data or make sure that it has the correct value if a change is made via the management API. For example, the server name can come from standalone.xml if the 'name' attribute is set and for sure will come from the HostController in domain mode. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-9113) Verify consistent handling of default values and resolved expressions when populating the domain model.

by Darran Lofthouse (JIRA)

Verify consistent handling of default values and resolved expressions when populating the domain model. ------------------------------------------------------------------------------------------------------- Key: JBAS-9113 URL: https://issues.jboss.org/browse/JBAS-9113 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Domain Management Reporter: Darran Lofthouse Fix For: 7.0.0.CR1 On reading the descriptors and executing the operations care needs to be taken to ensure either default values or resolved expressions are not transferred into the domain model - the consequence of this is that when the descriptors are re-written if these values are present in the model they are written as is loosing any default handling / expression resolving. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

7
7
0 / 0

[JBoss JIRA] Created: (JBAS-9098) Identify operations that require restart as part of the operation/attribute description

by Brian Stansberry (JIRA)

Identify operations that require restart as part of the operation/attribute description --------------------------------------------------------------------------------------- Key: JBAS-9098 URL: https://issues.jboss.org/browse/JBAS-9098 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Fix For: 7.0.0.Beta4 The implications of an operation with respect to whether invoking it will require a restart (or reload) to take effect should be part of the metadata description of the operation. This makes it possible for things like the console to advise users of the implications of their actions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

4
10
0 / 0

[JBoss JIRA] Created: (JBRULES-2293) Classpath resources being scanned by ResourceChangeScanner could cause improper resource removal

by Steve Ronderos (JIRA)

Classpath resources being scanned by ResourceChangeScanner could cause improper resource removal ------------------------------------------------------------------------------------------------ Key: JBRULES-2293 URL: https://jira.jboss.org/jira/browse/JBRULES-2293 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.1.FINAL Environment: Windows XP Java 5 Running in Oracle OC4J 10.1.3.2 Reporter: Steve Ronderos Assignee: Mark Proctor I encountered an issue today with my KnowledgeAgent removing resources from its RuleBase shortly after creating it. I have the ResourceChangeScanner running in my application. I tracked the issue back to the scan() method in ResourceChangeScannerImpl. It appears that the method is trying to identify resources that are no longer available and remove them from both the RuleBase and future scans. To do this it is checking lastModified on the resource and on a result of 0 removing the resource. The resources that I configured in my change-set definitely still exist, but due to URL handler implementation provided by my classloader, getLastModified always returns 0. (The resource I'm retrieving is coming from a jar that is in my application's classpath and the URL handler implementation is oracle.classloader.SharedCodeSourceURL) Full Email Group trail: http://www.nabble.com/Issue-with-ResourceChangeScanner-td25792358.html Michael recommends to never scan classpath resources. -- 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, 3 months

6
13
0 / 0

[JBoss JIRA] Created: (JBAS-8985) Filter javax.api

by David Lloyd (JIRA)

Filter javax.api ---------------- Key: JBAS-8985 URL: https://issues.jboss.org/browse/JBAS-8985 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 7.0.0.CR1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

4
6
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 March 2011