[JBoss JIRA] (AS7-6120) Expand support for System Property substitution
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/AS7-6120?page=com.atlassian.jira.plugin.s... ]
Jeff Mesnil commented on AS7-6120:
----------------------------------
the spreadsheet from 09/Jan/13 has red crosses for 2 messaging subsystem attributes: /profile=*/subsystem=messaging/hornetq-server=*/address-setting=* dead-letter-address & expiry-address. They're flagged as MR but the HornetQ addresses they reference are not part of the model, they are only runtime resources managed internally by HornetQ. I think it's ok to keep expression support for them.
> Expand support for System Property substitution
> -----------------------------------------------
>
> Key: AS7-6120
> URL: https://issues.jboss.org/browse/AS7-6120
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Jimmy Wilson
> Assignee: Brian Stansberry
> Priority: Blocker
> Labels: eap-6.1-prd, rhq
> Fix For: 7.2.0.Alpha1
>
> Attachments: expressions.ods
>
>
> Audit the core AS and all subsystems shipped in the AS distribution for suport for expression in management resource attributes.
> The basic philosophy toward expressions in previous releases was to only push devs to add support if there was a clear important use case. Devs could choose to add support beyond that, but we wouldn't push that. This JIRA and PRODMGT-195 from which it is derived reflects a change in philosophy. Now the philosophy is to support expressions unless the dev foresees a technical or future compatibility problem arising from doing so.
> This task DOES NOT advocate adding expression support to attributes that represent references to other model elements. Such references may prove problematic in the future and should not be added. We already have some model ref attributes that support expressions; this task DOES NOT advocate removing such support, unless the support has never been provided in a Final release (i.e. it was added during 7.2 development.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (JBREM-1317) BisocketClientInvoker waits for failed clients
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1317?page=com.atlassian.jira.plugin... ]
Ron Sigal commented on JBREM-1317:
----------------------------------
Hi Doug,
Your analysis sounds right. If I remember correctly, Messaging sends messages to a consumer as a oneway invocation. I don't remember much about it, but I see that ServerSessionEndpont.performDelivery() calls
callbackHandler.handleCallbackOneway(callback);
That suggests that the problem you're describing wouldn't cause a problem, but I could be wrong. Are you seeing some negative consequences?
-Ron
> BisocketClientInvoker waits for failed clients
> ----------------------------------------------
>
> Key: JBREM-1317
> URL: https://issues.jboss.org/browse/JBREM-1317
> Project: JBoss Remoting
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: callbacks
> Affects Versions: 2.5.4.SP3
> Environment: JBoss EAP 5.1.2
> Reporter: Doug Grove
> Assignee: Ron Sigal
> Priority: Minor
>
> When a client dies or is killed, the failure is actually detected in org.jboss.remoting.transport.socket.MicroSocketClientInvoker:
> (NEW ClientSocketWrapper[Socket[addr=/10.0.0.212,port=36600,localport=4458].d3e837]) got Exception: java.io.IOException: Broken pipe
> The "Broken pipe" exception means that the client has disconnected and can not return. This exception is treated in the code a retry-able, however.
> This is ignored, however, and the ode carries on, finally calling BisocketClientInvoker.createSocket(). This code then waits for a socket to appear in a list. I can see no way for a new socket to ever appear in the list.
> This results in the code waiting for the full duration of the configured timeout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (AS7-5590) relax the requirement for having EJB bean class no-arg constructor
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/AS7-5590?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on AS7-5590:
----------------------------------
Though this is a spec requirement, we can look into relaxing it.
> relax the requirement for having EJB bean class no-arg constructor
> ------------------------------------------------------------------
>
> Key: AS7-5590
> URL: https://issues.jboss.org/browse/AS7-5590
> Project: Application Server 7
> Issue Type: Feature Request
> Components: EE
> Affects Versions: 7.2.0.Alpha1
> Reporter: Cheng Fang
> Assignee: David Lloyd
>
> Currently AS7 requires all EJB bean class to have a public no-arg
> constructor, even when cdi is enabled and there is a @Inject constructor.
> The deployment of EJB with no default constructor will fail
> validation. I understand this is a EJB spec requirement, but I guess it's
> more of legacy from pre-CDI days.
> I'm wondering if we can relax it, to support EJB bean classes with
> only @Inject constructor and no default constructor. This is currently supported in GlassFish/RI.
> The stacktrace from validation:
> {noformat}
> 10:13:36,354 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-9) MSC00001: Failed to start service jboss.deployment.unit."test.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "test.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:123) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_35]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_35]
> at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_35]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011030: Could not configure component TestBean
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> ... 5 more
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS014227: EJB TestBean of type test.TestBean must have public default constructor
> at org.jboss.as.ejb3.component.EJBValidationConfigurator.configure(EJBValidationConfigurator.java:59)
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:80)
> ... 6 more
> 10:13:36,360 INFO [org.jboss.as.server] (management-handler-thread - 2) JBAS015870: Deploy of deployment "test.war" was rolled back with failure message {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"test.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.war\".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment \"test.war\"
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011030: Could not configure component TestBean
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS014227: EJB TestBean of type test.TestBean must have public default constructor"}}
> 10:13:36,379 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment test.war in 19ms
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (AS7-5590) relax the requirement for having EJB bean class no-arg constructor
by James Livingston (JIRA)
[ https://issues.jboss.org/browse/AS7-5590?page=com.atlassian.jira.plugin.s... ]
James Livingston commented on AS7-5590:
---------------------------------------
JSR 318 (EJB 3.1), section 4.9.2 point 2:
* The class must have a public constructor that takes no parameters. The container uses this constructor to create instances of the session bean class.
This is discussed in the EG, see http://java.net/jira/browse/EJB_SPEC-54 and http://java.net/jira/browse/EJB_SPEC-66
> relax the requirement for having EJB bean class no-arg constructor
> ------------------------------------------------------------------
>
> Key: AS7-5590
> URL: https://issues.jboss.org/browse/AS7-5590
> Project: Application Server 7
> Issue Type: Feature Request
> Components: EE
> Affects Versions: 7.2.0.Alpha1
> Reporter: Cheng Fang
> Assignee: David Lloyd
>
> Currently AS7 requires all EJB bean class to have a public no-arg
> constructor, even when cdi is enabled and there is a @Inject constructor.
> The deployment of EJB with no default constructor will fail
> validation. I understand this is a EJB spec requirement, but I guess it's
> more of legacy from pre-CDI days.
> I'm wondering if we can relax it, to support EJB bean classes with
> only @Inject constructor and no default constructor. This is currently supported in GlassFish/RI.
> The stacktrace from validation:
> {noformat}
> 10:13:36,354 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-9) MSC00001: Failed to start service jboss.deployment.unit."test.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "test.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:123) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_35]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_35]
> at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_35]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011030: Could not configure component TestBean
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> ... 5 more
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS014227: EJB TestBean of type test.TestBean must have public default constructor
> at org.jboss.as.ejb3.component.EJBValidationConfigurator.configure(EJBValidationConfigurator.java:59)
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:80)
> ... 6 more
> 10:13:36,360 INFO [org.jboss.as.server] (management-handler-thread - 2) JBAS015870: Deploy of deployment "test.war" was rolled back with failure message {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"test.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.war\".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment \"test.war\"
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011030: Could not configure component TestBean
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS014227: EJB TestBean of type test.TestBean must have public default constructor"}}
> 10:13:36,379 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment test.war in 19ms
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (AS7-6327) Create JPA service callback for invoking database migration
by Anil Arora (JIRA)
[ https://issues.jboss.org/browse/AS7-6327?page=com.atlassian.jira.plugin.s... ]
Anil Arora commented on AS7-6327:
---------------------------------
Almost the simplest solution I can think about is to create a callback similar to the one in the org.jboss.as.jpa.spi.PersistenceProviderAdaptor class.
interface org.jboss.as.jpa.spi.PersistenceProviderAdaptor {
public void beforeCreateContainerEntityManagerFactory(PersistenceUnitInfo info);
}
The method is invoked before the call to javax.persistence.spi.PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map) method. The PersistentUnitInfo has everything already needed to do whatever.
I tried to make my own PersistnceProviderAdapter, but it didn't work because of some classloader issues.
> Create JPA service callback for invoking database migration
> -----------------------------------------------------------
>
> Key: AS7-6327
> URL: https://issues.jboss.org/browse/AS7-6327
> Project: Application Server 7
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Anil Arora
> Assignee: Scott Marlow
>
> Looking for a simple callback/listener mechanism so that we can invoke a database migration script before JPA persistent unit starts up and runs the Hibernate schema validation mechanism.
> Ideally, there would be a property within the persistence.xml that indicates which class to call. It would also pass in/inject the datasource that is being used for the persistence unit.
> Essentially, this would solve the lack of migration support in Hibernate itself.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (JBAS-9527) java.lang.OutOfMemoryError during JBoss-5.1.0 startup with my ear file
by Ramesh Pitani (JIRA)
Ramesh Pitani created JBAS-9527:
-----------------------------------
Summary: java.lang.OutOfMemoryError during JBoss-5.1.0 startup with my ear file
Key: JBAS-9527
URL: https://issues.jboss.org/browse/JBAS-9527
Project: Application Server 3 4 5 and 6
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: VFS
Affects Versions: JBossAS-5.1.0.GA
Reporter: Ramesh Pitani
I am getting in to weird problem when I am trying to upgrade JBoss to 5.1.0-GA. (OutOfMemory and OutOfMemory with Native threads). I am having ear file which is having several libraries inside and I am using jdk-1.6.0_29(32b). I am getting this error in the JBoss-5.1.0 start up itself. If you are aware of this problem, Can you please help me here and give your suggestions about this problem? What is the best solution here?
1. If I start server with –Xmx2048m and –Xms2048m, I am getting in to above problems. If I reduce memory to –Xmx1536m, then this problem go away. I am assuming that JBoss5 is not getting enough native memory for loading jar files.
2. I tried to update jboss-vfs.jar file to 2.2.1 version. Still having same error. Should I upgrade jboss-vfs.jar to higher than this version ex: 3.1.0?
3. If I upgrade jdk to 1.7. Does it resolve this problem?
4. I have added –Djboss.vfs.forVfsJar=true to JBoss start up script. Then server started successfully. Is it safe to use this parmeter. We want to know what is pros and cons of using this parameter.
2013-01-09 05:18:16,010 DEBUG [org.jboss.bootstrap.microcontainer.ServerImpl] Installing life thread Thread[JBossLifeThread,5,jboss]
2013-01-09 05:18:16,011 DEBUG [org.jboss.bootstrap.microcontainer.ServerImpl] Failed to start
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:640)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:476)
at org.jboss.Main.boot(Main.java:221)
at org.jboss.Main$1.run(Main.java:556)
at java.lang.Thread.run(Thread.java:662)
2013-01-09 05:18:18,977 ERROR [org.springframework.batch.core.step.AbstractStep] Encountered an error executing the step
java.lang.OutOfMemoryError
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:127)
at java.util.zip.ZipFile.<init>(ZipFile.java:143)
at org.jboss.virtual.plugins.context.zip.ZipFileWrapper.ensureZipFile(ZipFileWrapper.java:175)
at org.jboss.virtual.plugins.context.zip.ZipFileWrapper.openStream(ZipFileWrapper.java:213)
at org.jboss.virtual.plugins.context.zip.ZipEntryContext.openStream(ZipEntryContext.java:1082)
at org.jboss.virtual.plugins.context.zip.ZipEntryHandler.openStream(ZipEntryHandler.java:153)
at org.jboss.virtual.VirtualFile.openStream(VirtualFile.java:230)
at org.jboss.classloading.spi.vfs.policy.VFSClassLoaderPolicy.getResourceAsStream(VFSClassLoaderPolicy.java:483)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:534)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:789)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at org.springframework.batch.classify.SubclassClassifier$ClassComparator.<init>(SubclassClassifier.java:135)
at org.springframework.batch.classify.SubclassClassifier.classify(SubclassClassifier.java:109)
at org.springframework.batch.core.step.item.SimpleRetryExceptionHandler.handleException(SimpleRetryExceptionHandler.java:80)
at org.springframework.batch.repeat.support.RepeatTemplate.doHandle(RepeatTemplate.java:293)
at org.springframework.batch.repeat.support.RepeatTemplate.executeInternal(RepeatTemplate.java:219)
at org.springframework.batch.repeat.support.RepeatTemplate.iterate(RepeatTemplate.java:143)
at org.springframework.batch.core.step.tasklet.TaskletStep.doExecute(TaskletStep.java:248)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months