[JBoss AS7 Development] - Re: Thoughts on filesystem action driven hot deployment
by Dimitris Andreadis
Dimitris Andreadis [http://community.jboss.org/people/dimitris] created the discussion
"Re: Thoughts on filesystem action driven hot deployment"
To view the discussion, visit: http://community.jboss.org/message/593490#593490
--------------------------------------------------------------
> Is it worth making it the default scanner in our next release?
I'd say let's experiment a bit first.
Just for aesthetics, I think the informative markers should be called: deploying, deployed/failed, undeploying, undeployed.
Then, the removal of the packed archive makes for a more symmetrical trigger, too. Do you know if that causes any resource/class-loading issues in the unpacked case? If this is so, maybe removing the .deployed descriptor is a preferred trigger, but that should delete the deployment, too.
I'm not set about the redeploy trigger. Maybe touching the .deployed descriptor is a good option, after all.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/593490#593490]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 4 months
[jBPM Development] - Re: Strange behavior using JBPM 4.4 with nested fork/joins having a Multiplicity
by helal jean-noel
helal jean-noel [http://community.jboss.org/people/jnhelal] created the discussion
"Re: Strange behavior using JBPM 4.4 with nested fork/joins having a Multiplicity"
To view the discussion, visit: http://community.jboss.org/message/595372#595372
--------------------------------------------------------------
Hi Silvio
We rely on the relased 4.4 and we have comparable problem:
* 2 branches fork/join works fine without specifying the multiplicity attribute
* 2 branches fork/join with multiplicity = 1 leave the unjoinded branch as a normal executing task while the joined execution goes on. What is wrong is that THERE EXIST 2 executions after the join.
I aggree with you, this is abnormal and I can confirm it exists on the JBPM 4.4 release, and has be reported elswhere.
I do not see why Ronald thought about a kill flag. In any case a not joined execution should be set to state END or inactive or killed. It should not remain active because this lead to uncorrect implementation of the JPDL join semantic. Maybe also this has to do with the time people thought about using this multiplicity attribute to deal the JPDL for/loop semantic...
Thanks for your patch, I will take a look at it, but I'm not the expected expert and we might need some additional help on this question.
Regards
JeanNo Helal
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/595372#595372]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 5 months
[JMX Development] - Help with MDB getting "Security Context is null" error when accessing the JMX RMI Adaptor
by Alexandre Santoro
Alexandre Santoro [http://community.jboss.org/people/santoro63] created the discussion
"Help with MDB getting "Security Context is null" error when accessing the JMX RMI Adaptor"
To view the discussion, visit: http://community.jboss.org/message/586821#586821
--------------------------------------------------------------
I am at my wit's end and would appreciate some help with this problem. Here's what's happening.
I am running JBoss AS 5.1.0.GA and have created an mdb with an onMessage() method that looks like this:
public void onMessage(Message m) {
processMessage(m);
LOG.info("finished processing " + m");
}
The processMessage method eventually gets the RMIAdaptor from jndi and makes a call to it.
When the code runs, it prints the LOG.info message in the log file suggesting it has finished processing, but after that fails with the following stack trace:
16:56:47,994 ERROR [JmsServerSession] Unexpected error delivering message delegator->JBossMessage[21256369076322305]:PERSISTENT, deliveryId=0
javax.ejb.EJBException: RuntimeException
at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:417)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:209)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
at org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContainer.java:415)
at org.jboss.ejb.Container.invoke(Container.java:1029)
at sun.reflect.GeneratedMethodAccessor376.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:169)
at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:118)
at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:209)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:195)
at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
at org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor.delivery(MessageEndpointInterceptor.java:249)
at org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor.invoke(MessageEndpointInterceptor.java:128)
at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101)
at $Proxy293.onMessage(Unknown Source)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
at org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160)
at org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831)
at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRun_494204024.invoke(SessionAspect_z_handleRun_494204024.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java)
at org.jboss.jms.client.JBossSession.run(JBossSession.java:199)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:234)
at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalStateException: Security Context is null
at org.jboss.ejb.plugins.SecurityActions$RunAsIdentityActions$2.pop(SecurityActions.java:143)
at org.jboss.ejb.plugins.SecurityActions.popRunAsIdentity(SecurityActions.java:244)
at org.jboss.ejb.plugins.RunAsSecurityInterceptor.process(RunAsSecurityInterceptor.java:139)
at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:103)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
I have tried setting the unauthenticatedIdentity property in the <application-context name="other"> element, as well as
including the <run-as> element in the ejb-jar.xml descriptor for this bean. No matter what I do I get the same error.
Does anyone what is it that causes this stack trace to happen AFTER the method uses the RMIAdaptor and exits? Am I missing some RMI configuration I am not aware of?
Thanks for your help in advance,
- Alex
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/586821#586821]
Start a new discussion in JMX Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 5 months
[IronJacamar Development] - IronJacamar Management
by Jesper Pedersen
Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] modified the document:
"IronJacamar Management"
To view the document, visit: http://community.jboss.org/docs/DOC-16674
--------------------------------------------------------------
h1. IronJacamar management
The goal of this page is to describe the management features of the IronJacamar container, the design and key implementation classes.
*
#IronJacamar_management IronJacamar management
**
#Requirements Requirements
**
#Design Design
***
#ManagementRepository ManagementRepository
***
#Connector Connector
***
#Resource_Adapter Resource Adapter
***
#Connection_Factory Connection Factory
***
#ManagedConnectionFactory ManagedConnectionFactory
***
#AdminObject AdminObject
***
#ConfigProperty ConfigProperty
***
#DataSource DataSource
**
#Features Features
***
#Operations Operations
****
#PoolConfiguration PoolConfiguration
***
#Statistics Statistics
**
#Implementation Implementation
***
#Operations_868100 Operations
****
#PoolConfiguration_962692 PoolConfiguration
***
#Statistics_515985 Statistics
**
#Test_suite Test suite
**
#Related Related
h2. Requirements
The overall requirements are
* Show the configuration of deployed resource adapters and datasources
* Show statistics for resource adapters and datasources
* Apply changes to the configuration of deployed resource adapters and datasources
* Invoke operations on the deployed resource adapters and datasources
h2. Design
We should a central place where the management view of resource adapters and datasources are registered (ManagementRepository).
This repository provides access to classes (Connector / DataSource) that represent a single deployment of either a resource adapter or a datasource.
Each of these classes are split into a hierarchy where information about the deployment and references to the live objects are maintained. It must be a design goal that the management classes uses methods from the public API of the IronJacamar container.
ManagementRepository
|
|- Connector
| |
| |- Resource Adapter
| |
| |- Connection Factories
| |
| |- Admin Objects
|
|- DataSource
See a description of each class below.
The implementation must be pure POJO, and only depend on the IronJacamar container.
Clients of the management repository contains the management specific technology, such as
* Java Management Extensions (JMX)
* JBoss Application Server 7 domain model
* RHQ
That way we can provide an API that can be used from all client types.
h3. ManagementRepository
|| *Method
* || *Description* ||
| getConnectors() | The active resource adapters |
| getDataSources() | The active datasources |
h3. Connector
|| *Method
* || *Description* ||
| getUniqueId() | The unique identifier for the deployment |
| getResourceAdapter() | The resource adapter |
| getConnectionFactories() | The connection factories |
| getAdminObjects() | The admin objects |
h3. Resource Adapter
|| *Method
* || *Description
* ||
| getResourceAdapter() | A reference to the live object |
| getConfigProperties() | The config-property's for the resource adapter |
h3. Connection Factory
|| *Method
* || *Description
* ||
| getJndiName() | The JNDI name of the connection factory |
| getManagedConnectionFactory() | A reference to the managed connection factory |
| getPool() | A reference to the pool |
| getPoolConfiguration() | A reference to the pool configuration |
h3. ManagedConnectionFactory
|| *Method
* || *Description* ||
| getManagedConnectionFactory() | A reference to the live object |
| getConfigProperties() | The config-property's for the managed connection factory |
h3. AdminObject
|| *Method
* || *Description
* ||
| getJndiName() | The JNDI name for the admin object |
| getAdminObject() | A reference to the live object |
| getConfigProperties() | The config-property's for the admin object |
h3. ConfigProperty
|| *Method
* || *Description
* ||
| getName() | The name of the config-property |
| isDynamic() | Is the config-property dynamic - e.g. supports live updates |
| isConfidential() | Is the config-property confidential |
h3. DataSource
|| *Method
* || *Description* ||
| getJndiName() | The JNDI name of the datasource |
| isXA() | Is the datasource XA capable |
| getPool() | A reference to the pool |
| getPoolConfiguration() | A reference to the pool configuration |
h2. Features
TBD
h3. Operations
Description of the operations that can be invoked are listed below.
* "Per request" -- Once an update has been performed it will be used at the next invocation of a method which uses the property in question
* "Per container" -- Is applied once a container is started/restarted
h4. PoolConfiguration
|| *Property
* || *Read* || *Write* || *Applied* ||
| MinSize | Y | Y | Per request |
| MaxSize | Y | Y | Per request |
| BlockingTimeout | Y | Y | Per request |
| IdleTimeout | Y | Y | Per container |
| BackgroundValidation | Y | Y | Per container |
| BackgroundValidationMinutes | Y | Y | Per container |
| Prefill | Y | Y | Per container |
| StrictMin | Y | Y | Per request |
| UseFastFail | Y | Y | Per request |
h3. Statistics
TBD
h2. Implementation
The implementation is located in the core module of the IronJacamar repository. The package is
org.jboss.jca.core.api.management
The implementing classes must use java.lang.ref.WeakReference for all live object references, such that won't prevent a garbage collection of the object in question.
h3. Operations
h4. PoolConfiguration
Access can be done directly on the reference.
h3. Statistics
TBD
h2. Test suite
The management model is currently tested through the RHQ plugin.
h2. Related
* JBoss Application Server 7
* http://community.jboss.org/docs/DOC-16378 RHQ platform
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16674]
Create a new document in IronJacamar Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 5 months
[IronJacamar Development] - IronJacamar Management
by Jesper Pedersen
Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] modified the document:
"IronJacamar Management"
To view the document, visit: http://community.jboss.org/docs/DOC-16674
--------------------------------------------------------------
h1. IronJacamar management
The goal of this page is to describe the management features of the IronJacamar container, the design and key implementation classes.
*
#IronJacamar_management IronJacamar management
**
#Requirements Requirements
**
#Design Design
***
#ManagementRepository ManagementRepository
***
#Connector Connector
***
#Resource_Adapter Resource Adapter
***
#Connection_Factory Connection Factory
***
#ManagedConnectionFactory ManagedConnectionFactory
***
#AdminObject AdminObject
***
#ConfigProperty ConfigProperty
***
#DataSource DataSource
**
#Features Features
***
#Operations Operations
*****
#PoolConfiguration PoolConfiguration
***
#Statistics Statistics
**
#Implementation Implementation
***
#Operations_642295 Operations
***
#Statistics_743686 Statistics
**
#Test_suite Test suite
**
#Related Related
h2. Requirements
The overall requirements are
* Show the configuration of deployed resource adapters and datasources
* Show statistics for resource adapters and datasources
* Apply changes to the configuration of deployed resource adapters and datasources
* Invoke operations on the deployed resource adapters and datasources
h2. Design
We should a central place where the management view of resource adapters and datasources are registered (ManagementRepository).
This repository provides access to classes (Connector / DataSource) that represent a single deployment of either a resource adapter or a datasource.
Each of these classes are split into a hierarchy where information about the deployment and references to the live objects are maintained. It must be a design goal that the management classes uses methods from the public API of the IronJacamar container.
ManagementRepository
|
|- Connector
| |
| |- Resource Adapter
| |
| |- Connection Factories
| |
| |- Admin Objects
|
|- DataSource
See a description of each class below.
The implementation must be pure POJO, and only depend on the IronJacamar container.
Clients of the management repository contains the management specific technology, such as
* Java Management Extensions (JMX)
* JBoss Application Server 7 domain model
* RHQ
That way we can provide an API that can be used from all client types.
h3. ManagementRepository
|| *Method
* || *Description* ||
| getConnectors() | The active resource adapters |
| getDataSources() | The active datasources |
h3. Connector
|| *Method
* || *Description* ||
| getUniqueId() | The unique identifier for the deployment |
| getResourceAdapter() | The resource adapter |
| getConnectionFactories() | The connection factories |
| getAdminObjects() | The admin objects |
h3. Resource Adapter
|| *Method
* || *Description
* ||
| getResourceAdapter() | A reference to the live object |
| getConfigProperties() | The config-property's for the resource adapter |
h3. Connection Factory
|| *Method
* || *Description
* ||
| getJndiName() | The JNDI name of the connection factory |
| getManagedConnectionFactory() | A reference to the managed connection factory |
| getPool() | A reference to the pool |
| getPoolConfiguration() | A reference to the pool configuration |
h3. ManagedConnectionFactory
|| *Method
* || *Description* ||
| getManagedConnectionFactory() | A reference to the live object |
| getConfigProperties() | The config-property's for the managed connection factory |
h3. AdminObject
|| *Method
* || *Description
* ||
| getJndiName() | The JNDI name for the admin object |
| getAdminObject() | A reference to the live object |
| getConfigProperties() | The config-property's for the admin object |
h3. ConfigProperty
|| *Method
* || *Description
* ||
| getName() | The name of the config-property |
| isDynamic() | Is the config-property dynamic - e.g. supports live updates |
| isConfidential() | Is the config-property confidential |
h3. DataSource
|| *Method
* || *Description* ||
| getJndiName() | The JNDI name of the datasource |
| isXA() | Is the datasource XA capable |
| getPool() | A reference to the pool |
| getPoolConfiguration() | A reference to the pool configuration |
h2. Features
TBD
h3. Operations
Description of the operations that can be invoked are listed below.
* "Per request" -- Once an update has been performed it will be used at the next invocation of a method which uses the property in question
* "Per container" -- Is applied once a container is started/restarted
h5. PoolConfiguration
|| *Property
* || *Read* || *Write* || *Applied* ||
| MinSize | Y | Y | Per request |
| MaxSize | Y | Y | Per request |
| BlockingTimeout | Y | Y | Per request |
| IdleTimeout | Y | Y | Per container |
| BackgroundValidation | Y | Y | Per container |
| BackgroundValidationMinutes | Y | Y | Per container |
| Prefill | Y | Y | Per container |
| StrictMin | Y | Y | Per request |
| UseFastFail | Y | Y | Per request |
h3. Statistics
TBD
h2. Implementation
The implementation is located in the core module of the IronJacamar repository. The package is
org.jboss.jca.core.api.management
The implementing classes must use java.lang.ref.WeakReference for all live object references, such that won't prevent a garbage collection of the object in question.
h3. Operations
TBD
h3. Statistics
TBD
h2. Test suite
The management model is currently tested through the RHQ plugin.
h2. Related
* JBoss Application Server 7
* http://community.jboss.org/docs/DOC-16378 RHQ platform
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16674]
Create a new document in IronJacamar Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 5 months
Re: [jboss-dev-forums] [JBoss AS7 Development] - Data Source Configuration in AS 7
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabirkhan] commented on the document
"Data Source Configuration in AS 7"
To view all comments on this document, visit: http://community.jboss.org/docs/DOC-16657#comment-5963
--------------------------------------------------
> Also, the jar file must have a META-INF/services/java.sql.Driver file.
If the jar does not contain that file, it can be included in the module by adding a jboss-7.0.0.<release>/modules/com/mysql/main/files/META-INF/services/java.sql.Driver and to have the module.xml reference the extra resource root
<module xmlns="urn:jboss:module:1.0" name="com.mysql">
<resources>
<resource-root path="files"/>
<resource-root path="mysql-connector-java-5.1.15.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
</dependencies>
</module>
--------------------------------------------------
13 years, 5 months