April 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (AS7-1752) Starting multiple standalone servers from the same install is not clean

by Brian Stansberry (JIRA)

Starting multiple standalone servers from the same install is not clean ----------------------------------------------------------------------- Key: AS7-1752 URL: https://issues.jboss.org/browse/AS7-1752 Project: Application Server 7 Issue Type: Task Components: Server Affects Versions: 7.0.1.Final, 7.0.0.Final Reporter: Brian Stansberry Fix For: 7.1.0.CR1 It should be easy to copy the standalone dir to another dir (say, "serverB" in the same level in the FS tree) and launch a second server using ./standalone.sh -Djboss.server.base.dir=serverB It somewhat works, but things that aren't as smooth as they should be: a) The resolution of jboss.server.base.dir isn't very smart. For example, to do the common thing and launch the script from within the bin dir you have to either use an absolute path to instance1/2 or do something kludgey like: ./standalone.sh -Djboss.server.base.dir=../serverB If the path is relative and resolving it doesn't result in a file that exists, an attempt should be made to resolve against jboss.home.dir. 2) The launch script directly references the standalone/configuration/logging.properties and standalone/log/boot.log files. So, if those files aren't present the server doesn't boot properly, and both, e.g. serverA and serverB will use the standalone/log/boot.log as their boot log file (where logging goes until the boot process starts the logging subsystem.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

4
4
0 / 0

[JBoss JIRA] (AS7-3106) @WebServiceProvider annotation is not processed when implementation class loaded from dependant module

by Peter Skopek (Created) (JIRA)

@WebServiceProvider annotation is not processed when implementation class loaded from dependant module ------------------------------------------------------------------------------------------------------ Key: AS7-3106 URL: https://issues.jboss.org/browse/AS7-3106 Project: Application Server 7 Issue Type: Bug Components: Web Services Affects Versions: 7.1.0.Beta1b Reporter: Peter Skopek Assignee: Alessio Soldano Fix For: 7.1.0.CR1 When deploying picketlink-sts.war with dependent module org.picketlink specified in META-INF/jboss-deployment-structure.xml which contains class referred to as servlet (in web.xml) annotated with @WebServiceProvider it is deployed as servlet and not as webservice. If I copy the class file to war to WEB-INF/classes it works as expected. See two attached .war files. Only correct one creates following log entries: {noformat} 17:30:33,595 INFO [org.jboss.wsf.stack.cxf.metadata.MetadataBuilder] (MSC service thread 1-5) Add Service id=PicketLinkSTS address=http://localhost:8080/picketlink-sts-correct implementor=org.picketlink.identity.federation.core.wstrust.PicketLinkSTS invoker=org.jboss.wsf.stack.cxf.JBossWSInvoker serviceName={urn:picketlink:identity-federation:sts}PicketLinkSTS portName={urn:picketlink:identity-federation:sts}PicketLinkSTSPort wsdlLocation=null mtomEnabled=false 17:30:33,597 INFO [org.jboss.ws.common.management.DefaultEndpointRegistry] (MSC service thread 1-5) register: jboss.ws:context=picketlink-sts-correct,endpoint=PicketLinkSTS 17:30:33,859 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-5) Creating Service {urn:picketlink:identity-federation:sts}PicketLinkSTS from WSDL: WEB-INF/wsdl/PicketLinkSTS.wsdl 17:30:34,070 INFO [org.jboss.wsf.stack.cxf.transport.AddressRewritingEndpointInfo] (MSC service thread 1-5) Setting new service endpoint address in wsdl: http://localhost:8080/picketlink-sts/PicketLinkSTS 17:30:34,132 INFO [org.jboss.wsf.stack.cxf.transport.AddressRewritingEndpointInfo] (MSC service thread 1-5) Setting new service endpoint address in wsdl: http://localhost:8080/picketlink-sts-correct 17:30:34,179 INFO [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-5) Setting the server's publish address to be http://localhost:8080/picketlink-sts-correct {noformat} -- 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

14 years

6
6
0 / 0

[JBoss JIRA] (AS7-3715) Improve logging for JBAS014101 failed to find in cache

by Radoslav Husar (JIRA)

Radoslav Husar created AS7-3715: ----------------------------------- Summary: Improve logging for JBAS014101 failed to find in cache Key: AS7-3715 URL: https://issues.jboss.org/browse/AS7-3715 Project: Application Server 7 Issue Type: Enhancement Components: EJB Affects Versions: 7.1.0.CR1, 7.1.0.Final Reporter: Radoslav Husar Assignee: jaikiran pai Priority: Minor {code} [JBossINF] 09:36:35,460 INFO [org.jboss.as.ejb3] (EJB default - 7) JBAS014101: Failed to find {[-82, 118, -38, -43, -10, -125, 71, -61, -65, -31, -2, -47, 58, 55, -81, -22]} in cache {code} As per earlier discussions somewhere else please improve logging for JBAS014101. This message is rather cryptic for users. -- 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

14 years

3
7
0 / 0

[JBoss JIRA] Created: (AS7-1769) Exposing deployments services through the xml deployment descriptor of the jar/sar/war/ear

by Nikos Ballas (JIRA)

Exposing deployments services through the xml deployment descriptor of the jar/sar/war/ear ------------------------------------------------------------------------------------------ Key: AS7-1769 URL: https://issues.jboss.org/browse/AS7-1769 Project: Application Server 7 Issue Type: Feature Request Components: EJB, JPA / Hibernate Affects Versions: 7.0.1.Final Environment: Linux, Window, MacOS, *BSD Reporter: Nikos Ballas Assignee: Carlo de Wolf Following scenario: Web application which is assembled by 4 different jars/wars: (1)myapp-model.jar -> contains the model + persistence.xml containing the definition of a CMT. (2)myapp-buisness.jar -> contains buisness EJB3's Spring Beans, whatever you can think of. (3)myapp-messaging.jar -> Contains MDB's for sending messages to several queues. (4)myapp-console.war -> Contains the web interface of the app. Now the -> define a dependency from a project to another to function,i.e. A->B means that A project has a dependency in B. Now the graph of dependencies between projects are: (4)->(2)->(1). Currently in jboss as 7 you are able to deploy your application either as module exposing several services(even though there is no clear documentation on how you do that.You follow the old way, you have to do something else?Nowhere in any documentation isn't that documented.) or you can use the deployments folder and copy everything there.Given the previous scenario if we deploy the module(2) then even if we have as dependency in the jboss-deployment-structure.xml the reference to the module(1) then we will get an exception saying that the persistence unit defined isn't accessible or undefined for the module(2). Now with the new version of jboss that allow us to manipulate the dependencies using the module mechanism and the well defined deployment and dependencies between projects it would be really useful if. When we define a dependency from one module to another, in my example from (2)->(1), also the mcs services defined are also exported in the target deployment, thus allowing access to the pu with the name for example is deployed. I don't know if this can be applied for the module architecture also. regards Nick -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

5
18
0 / 0

[JBoss JIRA] (JBRULES-3364) Outdated Drools 5.3.0.Final documentation

by L Carlon (JIRA)

L Carlon created JBRULES-3364: --------------------------------- Summary: Outdated Drools 5.3.0.Final documentation Key: JBRULES-3364 URL: https://issues.jboss.org/browse/JBRULES-3364 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-docs Affects Versions: 5.3.0.Final Reporter: L Carlon Assignee: Geoffrey De Smet Priority: Minor Originally reported to BZ. Geoffrey, I wasn't sure who to assign this to, I hope you don't mind I gave it to you to reassign as appropriate. Copied from BZ: Description of problem: Documentation for Drools 5.3.0.Final is outdated because in part Drools Expert, section 8.6.4. The Audit View, is used outdated example about creating audit log where deprecated RuleBase is used instead of KnowledgeBase. Link to this documentation: http://docs.jboss.org/drools/release/5.3.0.Final/drools-expert-docs/html/... Version-Release number of selected component (if applicable): Drools 5.3.0.Final Documentation Actual results: WorkingMemory workingMemory = ruleBase.newWorkingMemory(); // Create a new Working Memory Logger, that logs to file. WorkingMemoryFileLogger logger = new WorkingMemoryFileLogger(workingMemory); // An event.log file is created in the subdirectory log (which must exist) // of the working directory. logger.setFileName( "log/event" ); workingMemory.assertObject(...); workingMemory.fireAllRules(); // stop logging logger.writeToDisk(); Expected results: ...something like this... KnowledgeBase kbase = readKnowledgeBase(); StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession(); KnowledgeRuntimeLogger logger = KnowledgeRuntimeLoggerFactory.newFileLogger(ksession, "test"); ksession.insert(...); ksession.fireAllRules(); logger.close(); -- 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

14 years

3
15
0 / 0

[JBoss JIRA] (AS7-4530) BasicComponent#waitForComponentStart() can result in deadlock if there is a deployment failure

by Stuart Douglas (JIRA)

Stuart Douglas created AS7-4530: ----------------------------------- Summary: BasicComponent#waitForComponentStart() can result in deadlock if there is a deployment failure Key: AS7-4530 URL: https://issues.jboss.org/browse/AS7-4530 Project: Application Server 7 Issue Type: Bug Components: EE Affects Versions: 7.1.1.Final Reporter: Stuart Douglas Assignee: David Lloyd If an invocation happens on a component that has not started yet then the MSC thread will block in waitForComponentStart(). If a deployment problem prevents this component from starting then MSC will jam. -- 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

14 years

1
2
0 / 0

[JBoss JIRA] (AS7-4017) CLI --commands attribute don't work with comma separated

by Samuel Tauil (JIRA)

Samuel Tauil created AS7-4017: --------------------------------- Summary: CLI --commands attribute don't work with comma separated Key: AS7-4017 URL: https://issues.jboss.org/browse/AS7-4017 Project: Application Server 7 Issue Type: Bug Components: CLI Affects Versions: 7.1.0.Final Environment: I'm using fedora 16 and java.1.6.0_25. JBoss AS 7 Final 7.1.0 Reporter: Samuel Tauil Assignee: Alexey Loubyansky When I try to execute multiple commands in CLI using the script I got an error. The parameter --commands of the jboss-cli.sh seems to do a string split by comma, but are commands that use comma as character to separate attributes. -- 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

14 years

2
1
0 / 0

[JBoss JIRA] (AS7-4630) add-user script broken

by Dustin Kut Moy Cheung (JIRA)

Dustin Kut Moy Cheung created AS7-4630: ------------------------------------------ Summary: add-user script broken Key: AS7-4630 URL: https://issues.jboss.org/browse/AS7-4630 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.1.1.Final Reporter: Dustin Kut Moy Cheung Assignee: Dustin Kut Moy Cheung ./add-user.sh dustin dustin1 does not work anymore. In previous versions it would work. It has to do with the "theConsole" object being null. In the same breadth, the --silent=true option in add-user.sh does not work anymore. Again has to do with the need for "theConsole" object NOT being null. The --silent=true option was added because in some environments, System.console() returns null [for example when the Izpack installer calls that script] and the add-user.sh script breaks because of its dependence on System.console() object to print stuff. -- 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

14 years

3
13
0 / 0

[JBoss JIRA] (AS7-4470) JPA should allow for a bean validator factory per persistence unit or per application deployment

by Scott Marlow (JIRA)

Scott Marlow created AS7-4470: --------------------------------- Summary: JPA should allow for a bean validator factory per persistence unit or per application deployment Key: AS7-4470 URL: https://issues.jboss.org/browse/AS7-4470 Project: Application Server 7 Issue Type: Task Components: JPA / Hibernate Affects Versions: 7.1.0.Final Reporter: Scott Marlow Currently, a new bean validator factory instance is associated with each deployed persistence unit. This jira calls for adding a new PU property that specifies that a 'per app bean validator factory' should be used for a persistence unit (via a persistence unit property). This can be controlled by a new persistence unit property (see existing ones [here|https://docs.jboss.org/author/display/AS71/JPA+Reference+Guide#JPARe...]. The new property can be something like "org.jboss.as.jpa.shareValidatorFactory" which defaults to false. Look at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit() to make this change. -- 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

14 years

1
1
0 / 0

[JBoss JIRA] (AS7-4097) Using an extended persistence context in a stateless session bean should throw an exception

by Karsten Wutzke (JIRA)

Karsten Wutzke created AS7-4097: ----------------------------------- Summary: Using an extended persistence context in a stateless session bean should throw an exception Key: AS7-4097 URL: https://issues.jboss.org/browse/AS7-4097 Project: Application Server 7 Issue Type: Bug Reporter: Karsten Wutzke Using an extended persistence context in a stateless session bean should not initiate. It should throw an exception to notify the user of incorrect use. See JPA 2.0 spec, section 7.6.2: "A container-managed extended persistence context can only be initiated within the scope of a stateful session bean." -- 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

14 years

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 April 2012