[News & Announcements] - JBossAS 5.1.0.CR1 released
by rrajesh
JBossAS 5.1.0.CR1 has been released and is available for download.
http://www.jboss.org/jbossas/downloads/
This is the first candidate release of the JBoss 5.1 series. Along with many bug fixes and enhancements, this
release includes a first cut of our new, significantly improved open-source console. We are hoping to get as much
feedback as possible to ensure we have a great first version in the eventual 5.1.0.GA release. Please post your
feedback to the embedded JOPR forum here.
Overview
* Highlights
* Compatibility Issues
* Configuration Issues
* Other Issues
* JBoss/Thirdparty Library Updates
* Detailed Release Notes
* Additional Docs and Help
* Licenses
* About JBoss
Highlights
* New Web Console - This release includes our new administration console.
See the full release notes for the console here.
* Web Beans Update - In addition, this release includes an updated tech preview of the new JSR-299 Web Beans RI.
You can find out more information about Web Beans here.
* Farming Returns - Due to popular demand, the farming service is back!
See the following wiki page here.
Compatibility Issues
There are no known compatibility issues in 5.1.0.CR1.
from 5.0.1.GA
* This release resolves issues related to running JBossAS 5 under AIX with an IBM jdk. See JBAS-6506, JBAS-6428.
* A NamingContext issue was identified when using IPv6, take a look at JBAS-6390.
* If you are using HASingletons and/or depending on the BarrierController you'll find interesting the fixes in
JBAS-6440, JBAS-6441, JBAS-6363.
* The filtering of classes/packages of jars bundled with .wars has improved, see JBAS-6478 and the associated forum thread.
from 5.0.0.GA
JBossAS 5.0.0.GA can be compiled with both Java5 & Java6. The Java5 compiled binary is our primary/recommended binary
distribution. It has undergone rigorous testing and can run under both a Java 5 and a Java 6 runtime. When running
under Java 6 you need to manually copy the following libraries from the JBOSS_HOME/client directory to the
JBOSS_HOME/lib/endorsed directory, so that the JAX-WS 2.0 apis supported by JBossWS are used:
* jbossws-native-saaj.jar
* jbossws-native-jaxrpc.jar
* jbossws-native-jaxws.jar
* jbossws-native-jaxws-ext.jar
The other option is to download the jdk6 distribution (jboss-5.0.0.GA-jdk6.zip) in which case no configuration
changes are required. If you still have problems using JBoss with a Sun Java 6 runtime, you may want to set
-Dsun.lang.ClassLoader.allowArraySyntax=true, as described in JBAS-4491. Other potential problems under a Java 6 runtime include:
* ORB getting prematurely destroyed when using Sun JDK 6 (see Sun Bug ID: 6520484)
* Unimplemented methods in Hibernate for JDK6 interfaces.
* When JBossAS 5 is compiled with Java 6, support for the extended JDBC 4 API is included in the binary, however
this can only be used under a Java 6 runtime. In this case no manual configuration steps are necessary. It should be
noted however that the Java 6 compiled distribution of JBoss AS 5 is still in experimental stage.
Other compatibility issues:
* JBossMQ has been removed from the distribution and is no longer supported in AS5. JBoss Messaging Service is now
the default JMS provider.
* All the *-beans.xml configuration files have been renamed to *-jboss-beans.xml to avoid conflicts with spring
configuration files.
* For mod_cluster integration you will have to use the workaround described in JBAS-5966 until the tomcat service
mbean descriptor is converted to an MC bean descriptor.
* JBoss VFS provides a set of different switches to
control it's internal behavior. JBoss AS sets jboss.vfs.forceCopy=true by default. To see all the
provided VFS flags check out the code of the VFSUtils.java class.
* VFS uses an internal caching mechanism to speed up access to deployment artifacts. This means that files in
deploy/ remain open as long as they are accessed and then closed by a reaper thread after a 5 seconds inactivity. On
window platforms this may cause locking issues if files are re-deployed too quickly. In this case you may want to
turn-off the reaper by specifying the -Djboss.vfs.forceNoReaper=true property in the command line.
* Hibernate-core is now using slf4j-api as a logging facade. To properly integrate that in JBossAS we have
created an slf4j-to-jboss-logging adapter (slf4j-jboss-logging.jar) that creates a static binding between sl4j and
jboss-logging-spi . The jboss-logging default implementation is configured to use log4j. See JBAS-5519.
* The client/jbossall-client.jar library that used to bundle the majority of jboss client libraries, is now
referencing them instead through the Class-Path manifest entry. This allows swapping included libraries (e.g.
jboss-javaee.jar) without having to re-package jbossall-client.jar. On the other hand, it requires that you have
jbossall-client.jar together with the other client/*.jar libraries, so they can be found. See JBAS-4355.
* If using proprietary JBoss/EJB3 annotations, those have moved (since Beta4) into the org.jboss.ejb3.annotation
package, EJBTHREE-1099. Those are now included in a new artifact, jboss-ejb3-ext-api.jar
* Interoperating with previous JBoss EJB3 implementations may present problems due to
serialVersionUIDs issues, EJBTHREE-1118.
* Use of JBoss Cache 3.x. has a significantly different API from the 1.x releases used in JBoss AS 4.x and 3.2.x.
* @EJB injections should now work from servlets, JBAS-5646.
* The ClassPathExtension MBean has been replaced with a VFS classloader definition, see JBAS-5446.
* The old JMX-based ServiceBindingManager has been replaced by a POJO-based ServiceBindingManager, see JBAS-5192.
* The Farm service from 4.x has been removed.
* JBoss 5 is stricter when it comes to verifying/deploying JavaEE artifacts. EJB3 deployments that
run in AS 4.2 may fail in AS5. We have tried to keep the validation messages as accurate as possible in order to
help you modify your deployment descriptors/annotations to be in-line with the JavaEE 5 requirements.
Configuration Issues
* The ejb3-timer-service.xml has moved from deploy to docs/examples/ejb3 to avoid the runtime overhead, since
it's not used by default. If you want to use it, move it back to the deploy folder and set the
org.jboss.ejb3.timerservice.factory property to org.jboss.ejb3.timerservice.quartz.QuartzTimerServiceFactory.
>From 5.0.0.GA
JBossAS 5.0.0.GA introduces two new configuration, the standard and the web config.
* The standard config is the configuration that has been tested for JavaEE compliance. The major differences
with the existing configurations is that call-by-value and deployment isolation are enabled by default, along with
support for rmiiiop and juddi (taken from the all config), as shown below:
o deployers/ear-deployer-jboss-beans.xml
true
true
o conf/jboss-service.xml call-by-value for "jboss:service=Naming"
true
o conf/jndi.properties
java.naming.factory.initial=org.jboss.iiop.naming.ORBInitialContextFactory
o conf/jacorb.properties
deploy/iiop-service.xml
lib/avalon-framework.jar
lib/jacorb.jar
o deploy/juddi-service.sar
* The web config is a new experimental lightweight configuration created around JBoss Web that will follow the
developments of the JavaEE 6 web profile. Except for the servlet/jsp container it provides support for JTA/JCA and
JPA. It also limits itself to allowing access to the server only through the http port. Please note that this
configuration is not JavaEE certified and will most likely change in the following releases.
Another notable change is that the majority of the libraries common to the different configurations have moved
to a new shared location, JBOSS_HOME/common/lib/. This is so we avoid having multiple copies of the same libraries in
the distribution. The location of the common library directory can be controlled by the following properties:
* jboss.common.base.url defaulting to ${jboss.home.url}/common
* jboss.common.lib.url defaulting to ${jboss.common.base.url}/lib
The common library directory is shared by all the configurations except for the minimal config. It is
referenced in the very beginning of every configuration's conf/jboss-service.xml.
You can see that the library directory of the individual configurations is still in place, although in some cases
it's empty (e.g. JBOSS_HOME/server/default/lib/)
The directory structure of JBoss 5 resembles that of the 4.x series with some notable differences:
* bin - start scripts and run.jar
* client - client jars - note how jbossall-client.jar is now referencing the other client jars.
* common
o lib
* docs - docs, schemas/dtds, examples
* lib - core bootstrap jars, somewhat different with the introduction of the microcontainer and breakup of jboss-common.
* server - the same server configuration dirs.
o xyz configuration
+ conf
# bootstrap.xml - new mc kernel bootstrap configuration referencing other
# configuration files that contain the beans that setup each individual subsystem.
* bootstrap
o vfs.xml - vfs initialization
o classloader.xml
o aop.xml
o jmx.xml - legacy JMX support
o deployers.xml
o bindings.xml (POJO-based ServiceBindingManager & port bindings)
o profile-repository.xml (profile service enabled deployment repository)
# jax-ws-catalog.xml - oasis catalog driven schema/dtd namespace configuration
# jbossjta-properties.xml - new JBossTS properties
# jboss-service.xml - legacy static mbeans for compatibility, somewhat reduced
# jndi.properties - the same jndi props
# log4j.xml - the same log4j config
# login-config.xml - the same jaas login config
# props/ - the same default jaas login properties files
# standardjaws.xml - obsolete cmp config
# standardjbosscmp-jdbc.xml - the same cmp2 config
# standardjboss.xml - the same ejb2 config
# xmdesc/ - legacy xmbean descriptors
+ deploy/ - the same deploy directory.
# ...
# jca-jboss-beans.xml
# hdscanner-jboss-beans.xml - the hot deployment scanner
# legacy-invokers-service.xml
# profileservice-jboss-beans.xml
# remoting-jboss-beans.xml
# transaction-jboss-beans.xml
# vfs-jboss-beans.xml
+ deployers/ - new vdf deployers
# bsh-deployer - beanshell deployer
# ejb3.deployer - ejb3 deployers
# jboss-aop-jboss5.deployer - aspect deployer
# jboss-jca.deployer - JCA deployers
# jbossweb.deployer - war deployers
# jbossws.deployer - web services deployers
# seam.deployer - SEAM deployer
# alias-deployers-jboss-beans.xml
# clustering-deployers-jboss-beans.xml
# dependency-deployers-jboss-beans.xml
# directory-deployer-jboss-beans.xml
# ear-deployer-jboss-beans.xml - ear deployers
# ejb-deployer-jboss-beans.xml - ejb2.x deployers
# hibernate-deployer-jboss-beans.xml
# jsr77-deployers-jboss-beans.xml
# metadata-deployer-jboss-beans.xml - metadata handlers
# security-deployer-jboss-beans.xml - security deployers
+ lib/ - the same static library jars with a few jars, as most have moved to top level common/lib
Various configuration issues:
* A new jboss.server.log.threshold system property can be used to control the log/server.log threshold. It defaults to DEBUG.
* Use of the jboss.jgroups.udp.mcast_port property to control easy configuration of multicast port, JBAS-2395
* Overriding of ra.xml properties in jboss-ra.xml, JBAS-3343
* Support for defining dependencies in JCA adapters, JBAS-4508
* Controlling command line arguments for the appClientLauncher, JBAS-5888.
* Shutdown.sh now accepts a JNDI url, JBAS-5922.
* DeleteWorkDirOnContextDestroy property for JSP pages, JBAS-5453.
* The clustering configurations have been organized in the deploy dir in a new cluster subfolder (JBAS-4709).
* A separate cache is now used for Clustered SSO (JBAS-4676).
* Per webapp configuration of useJK, snapshot mode and snapshot interval (JBAS-3460). Default for useJK is whether
jvmRoute is set (JBAS-4961).
* Total replication (rather than buddy replication) is the default setting for session replication (JBAS-5085).
* The transaction manager configuration has moved from conf/jboss-service.xml to deploy/transaction-service.xml (JBAS-5103).
* The default conf/jboss-log4j.xml configuration now includes the thread name for entries in log/server.log (JBAS-5274).
* All the security related configuration files are now grouped under the deploy/security directory (JBAS-5318).
* Loopback is now set to true for all JGroups UDP stacks (JBAS-5323).
EJB3 configuration is now controlled by deployers/ejb3.deployer/META-INF/ejb3-deployers-jboss-beans.xml.
For more details check out this wiki page.
For security related configuration changes, please consult this wiki page.
For clustering related changes, check out the Wiki for more info.
Other Issues
>From 5.0.1.GA
* A major goal of the release is to address issues related to VFS handling of temporary files and
re-deployments. See JBAS-6935, JBAS-6504, JBAS-6373.
* Navigation in the jmx/web consoles was broken. This is fixed in JBAS-6493, JBAS-6328
* The dtds/schemas on www.jboss.org have been updated with the latest ones, see JBAS-6114.
>From 5.0.0.GA
* Bootstrap time has improved compared to AS5 CR1, but it still somewhat slower when compared to the 4.2.x series,
due to the extensive annotation scanning that goes on behind the scenes. There are ways to optimize the
annotation scanning, especially for large deployments. Check the JBoss Wiki for more information.
Changes:
Detailed Release Notes
Bug
* [JBAS-5941] - NullPointerException in ClusteredSession
* [JBAS-6425] - AbstractSecurityDeployer assumes VFSDeploymentUnit
* [JBAS-6426] - "jboss_5.0.xsd" of JBoss 5.0GA is invalid
* [JBAS-6535] - java.lang.LinkageErrors seen during start of JBoss AS 5.1 with admin-console.war deployed
* [JBAS-6553] - java:comp/env isn't available for SessionSynchronization callbacks
* [JBAS-6574] - Typo in 'Installation And Getting Started Guide'
* [JBAS-6600] - Setting isolated=true on EarClassLoaderDeployer does not work
* [JBAS-6601] - CryptoUtil is missing from jboss-srp-client.jar (or jbosssx-client.jar)
* [JBAS-6606] - Specifying mdb-client-id in jboss.xml causes mdb deployments to fail
* [JBAS-6617] - Server failure when including aop metadata inside a sar inside a zip
* [JBAS-6618] - Statistic properties are not tied to runtime component
* [JBAS-6641] - copying all JBAS 4.2 testsuite apps into AS 5.1 deploy dir causes profile service errors and
failure of server to start
* [JBAS-6643] - restoring a null managed object fails
* [JBAS-6682] - StringIndexOutOfBoundsException in JvmRouteValve
* [JBAS-6692] - JGroups protocol stacks need to have FC.ignore_synchronous_response set to "true"
* [JBAS-6694] - java.lang.OutOfMemoryErrors seen during automated Embedded Console testing
* [JBAS-6705] - AS5 plugin: Creating a new Topic or Queue now results in this error -
"java.lang.RuntimeException:Failed to process template"
* [JBAS-6715] - Redployment intermittently fails
* [JBAS-6718] - AS5 plugin: If the "use-java-context" property is left unset when creating a datasource, it now
gets set to "false" by default instead of to "true"
* [JBAS-6719] - AS5 plugin: After creating a new Topic or Queue, the configuration properties are set to their
default values instead of to the values that were specified during creation
* [JBAS-6736] - List operations for Topics and Queues (eg. List All Messages, List All Subscriptions, etc.) are
not producing the correct results
* [JBAS-6737] - contextRoot of webservicesType in jboss_5_0.xsd and jboss_5_1.xsd is not correct
* [JBAS-6742] - Updates to managed properties no longer persisting when changes made through embedded console
* [JBAS-6755] - Setting ObjectName ManagedProperties (eg. DLQ, serverPeer, expiryQueue) as removed=true causes Topic/Queue creation to fail
* [JBAS-6792] - callMethodOnPartition on MBeans extending HAServiceMBeanSupport not working
* [JBAS-6793] - IncompleteDeploymentException upon Stop'n'Start or Restart of EAR with nested WAR
* [JBAS-6799] - Attempting to configure a Topic or Queue that has the "securityConfig" property unset results
in an UndeclaredThrowableException
* [JBAS-6800] - Ejb3HAPartitionDependencyDeployer adds dependency to non-clustered beans
* [JBAS-6801] - After creating a Topic or Queue, the value of the "clustered" property is set to "false" even if
the user set it to "true" during creation
* [JBAS-6805] - java.lang.OutOfMemory: Heap Space during Runtime Discovery Scan
* [JBAS-6807] - Unable to form a cluster Branch_5_x (flush by coordinator at xyz failed)
Feature Request
* [JBAS-2595] - JMX Resolver for JSF
* [JBAS-5965] - Max file soft limit can not always be set to hard limit on Darwin (OS X)
* [JBAS-5993] - Need to add ProfileService failed deployment tests
* [JBAS-6092] - Check and warn if system time is off on joining node
* [JBAS-6142] - Include a more user friendly management and monitoring tool.
* [JBAS-6356] - Configure HA-JNDI automatic discovery socket via ServiceBindingManager
* [JBAS-6629] - Apply ${jboss.server.log.threshold} to root logger
* [JBAS-6644] - expose if the ManagementView was reloaded.
* [JBAS-6650] - configurable upload dir of a DeploymentRepository
* [JBAS-6653] - Switch to new classpools
* [JBAS-6678] - Upgrade to Hibvernate Search 3.1.1
* [JBAS-6752] - Include the datasource name when the connection manager reports a ResourceException
Task
* [JBAS-4666] - MBean for new EjbDeployer
* [JBAS-6038] - Examine use of SessionReplicationContext start/finishCacheActivity
* [JBAS-6466] - Log as TRACE not being able to find cache entry trying to be removed
* [JBAS-6552] - Track component updates - 5.1.0.CR1
* [JBAS-6626] - Order .jar before .war
* [JBAS-6630] - Change default value for ${jboss.server.log.threshold} to INFO
* [JBAS-6637] - Disable lock striping in JBoss Cache configs
* [JBAS-6648] - provide different profile implementations
* [JBAS-6649] - enable distribution of deployment contents to the deployers dir.
* [JBAS-6659] - Create brew build of glassfish-jaxb version 2.1.9 so we can patch
* [JBAS-6667] - Rename managed component subtype on TxConnectionFactoryDeploymentMetaData.java to be "Tx" rather than "XA"
* [JBAS-6716] - add back securityConfig config property to JMS destination resources
* [JBAS-6743] - start AS with xb.builder.useUnorderedSequence
* [JBAS-6757] - Reorganize source that populates the server/xxx/conf dir
* [JBAS-6760] - Add extra check for before NPE in JavaEEComponentHelper
* [JBAS-6780] - Get rid of DistributableSession interface
* [JBAS-6786] - Update ManagedObjects for JBAS server related components to have unique types
* [JBAS-6798] - Change AS Build to not bring in jboss-ejb3-proxy
* [JBAS-6816] - Reduce verbose FINE logging from sun classes
* [JBAS-6830] - Update release notes for 5.1.0.CR1
Thirdparty Change
* [JBAS-6739] - Synch with the latest patched jacorb version
* [JBAS-6756] - Use the latest patched version of xalan
Component Upgrade
* [JBAS-6027] - Upgrade jboss-metadata to 1.0.0.CR18
* [JBAS-6469] - Update to JBossXB 2.0.1.GA
* [JBAS-6605] - JBoss Security upgrade to 2.0.3.SP1
* [JBAS-6633] - Upgrade jboss-ha-server-api to 1.1.1.GA
* [JBAS-6634] - Upgrade JBossWS Native to 3.1.1.GA
* [JBAS-6635] - Upgrade JAXB to 2.1.9.patch
* [JBAS-6636] - Upgrade JBoss Cache to 3.1.0.CR1
* [JBAS-6639] - Upgrade JBossXacml 2.0.3
* [JBAS-6661] - Upgrade Web Beans to 1.0.0.PREVIEW
* [JBAS-6684] - Update EJB 3 to 1.1.3
* [JBAS-6691] - Upgrade JGroups to 2.6.9
* [JBAS-6726] - Update XNIO to 1.2.1.GA
* [JBAS-6727] - Update JBoss Threads to 1.0.0.CR3
* [JBAS-6729] - Update to JBoss LogBridge 1.0.0CR4
* [JBAS-6730] - Update to JBoss LogManager 1.0.0.CR3
* [JBAS-6740] - Upgrade JBoss Threads to 1.0.0.CR4
* [JBAS-6761] - Upgrade common-core to 2.2.12
* [JBAS-6778] - Update ha-server-cache-spi to 2.0.0.GA
* [JBAS-6779] - Update ha-server-cache-jbc to 2.0.0.CR1
* [JBAS-6787] - Upgrade Remoting to 2.5.1
* [JBAS-6826] - Upgrade to Common Core 2.2.13
* [JBAS-6827] - Upgrade to VFS 2.1.1.GA
* [JBAS-6837] - Upgrade to JBoss Web 2.1.3
Sub-task
* [JBAS-5703] - Make HA-JNDI use wait for first positive response
* [JBAS-6580] - org.jboss.test.web.test.JSFIntegrationUnitTestCase
* [JBAS-6582] - org.jboss.test.ejb3.servlet.unit.ServletUnitTestCase
* [JBAS-6598] - org.jboss.test.profileservice.testsecure.ProfileServiceUnitTestCase
* [JBAS-6599] - org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
* [JBAS-6607] - XACMLDeployer to parse xacml config/policies in the deployment
* [JBAS-6608] - ACLDeployer to pick up ACL files
* [JBAS-6631] - Make sure JBAS managed object has shutdown operation
* [JBAS-6647] - "XAConnectionFactoryTemplate" and possibly other templates are missing from ManagementView
* [JBAS-6654] - EJBVerifier21 should check messagingType for null
* [JBAS-6657] - managementView.load() fails to merge ServerInfo, ThreadPool, GlobalRequestProcessor, and Host ManagedObjects
* [JBAS-6662] - Remove unnecessary use of MBeanRegistry/Entry
* [JBAS-6664] - "config-property" ManagedProperty in all ConnectionFactory and Datasource templates has wrong type
* [JBAS-6668] - for Connection Factories, an extra prop.type config-prop is added to the "config-property"
MapCompositeMetaType property every time managementView.updateComponent(connFactoryComponent) is called
* [JBAS-6669] - when new items are added to the "config-property" composite ManagedProperty on a Datasource
component, after updateComponent() is called, the items that were added are gone
* [JBAS-6670] - *.type config-props within "config-property" composite ManagedProperty are set to the
corresponding connection factory prop's value, rather than its type
* [JBAS-6671] - on Connection Factory components, jndi-name, rar-name, and connection-definition
ManagedPropertys should all be mandatory, in both templates and properties on existing components
* [JBAS-6672] - when null values are specified for ManagedProperties, then updateComponent() is called, the
values are updated to incorrect defaults (e.g. "0" for integer properties)
* [JBAS-6681] - UndeclaredThrowableException:ReflectionException:IllegalArgumentException on call to ManagementViewImpl.updateComponent() on Topic or
Queue containing primitive int or boolean property with value of null
* [JBAS-6683] - QueueTemplate and TopicTemplate templates are missing most of the ManagedProperties defined
by the corresponding ComponentTypes - they only contain the "name" and "JNDIName" properties
* [JBAS-6686] - Unexpected parameters for JMS Topic managed operations
* [JBAS-6688] - expose ManagedProperties representing ObjectNames as SimpleMetaType.STRINGs rather than
ImmutableCompositeMetaType{javax.management.ObjectName}s
* [JBAS-6689] - add support for activation policy metadata on ManagedProperties
* [JBAS-6701] - DeploymentManager.remove() doesn't work for exploded apps that were deployed via
distribute(copyContent=false)
* [JBAS-6703] - XML config files persisted for Topics/Queues created via Profile Service still contain
ManagementObjectClass annotation tags
* [JBAS-6708] - once DeploymentManager.stop() is called on a WAR deployment, the next time
managementView.getDeploymentNamesForType("war") is called, a deployment is no longer returned for that WAR
* [JBAS-6709] - provide an API to determine the current state (i.e. Stopped/Started/Starting/Stopping/etc.) of a ManagedDeployment
* [JBAS-6711] - if non-null values are set for ObjectName ManagedProperties (i.e. DLQ, serverPeer, or
expiryQueue props) in Topic/Queue templates, applyTemplate() throws "IllegalArgumentException: Not
handled value: CompositeValueSupport"
* [JBAS-6721] - a few Topic/Queue ManagedProperties have the wrong ViewUse
* [JBAS-6728] - 'local-transaction' prop is missing from the template for Tx ConnectionFactories
* [JBAS-6733] - Avoid re-reading expired sessions from distributed cache
* [JBAS-6741] - Upgrade jboss-server-manager to 1.0.2.GA and jboss-test to 1.1.4.GA
* [JBAS-6750] - get Admin Console WAR integrated into JBAS 5.1 distribution
* [JBAS-6751] - Need to map org.jboss.jms.message.JBossMessage into simple composite
map in destination managed operations
* [JBAS-6762] - org.jboss.test.bootstrapdependencies.jbas5349.test.BootstrapDependenciesTestCase(EJB2Session)
* [JBAS-6765] - Setting ObjectName ManagedProperties (eg. DLQ, serverPeer, expiryQueue) to removed=true and
value=null causes NullPointerException in StringObjectNameMetaMapper.unwrapMetaValue()
* [JBAS-6770] - JBoss-AS-5.1.x-compatibilityMatrix - server fails to start
* [JBAS-6774] - Upgrade EJB3 to 1.1.4
* [JBAS-6796] - "java.lang.IllegalArgumentException: Null type." error in
DelegatingPersistencePlugin.getPlugin() when updating a
Datasource or Connection Factory's properties with
'security-domain' prop with null security deployment type
* [JBAS-6804] - org.jboss.test.jacc.test.*PermissionsValidationTestCase
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227619#4227619
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227619
16 years, 12 months
[Microcontainer] - Re: Using VFS to create a symbolic link from WEB-INF/lib
by mwringe
Is there anyupdate on the TLD issue? is is being tracked in jira anywhere?
There are a few ways of getting around it right now, but they are a pain.
- getting the actual location of where the webapp is deployed and copying the file across. Finding the actual file location is a big pain requiring many levels of hacks.
- manipulating the web.xml metadata (easily done with a deployer) to redefine the JspServlet. This will override the JspServlet setting in jboss-web.deployer/web.xml (the shared web.xml file for all webapps). By setting a properly formatted <init-param> for the JspServlet you can make it add any tld from any specified jar with no requirements on it existing in the WEB-INF directory of your webapp.
| <init-param>
| <description>JSTL standard tlds</description>
| <param-name>tagLibJar2</param-name>
| <param-value>../location-to-jar/jar-containing-tld.jar</param-value>
| </init-param>
|
The problem here is that it does change the global JspServlet setting and all webapps will be able to find your tlds. And its probably not the safest operation to be overwriting the JspServlet like this, but it is possible.
It would be a lot easier if this default global web.xml was being handled by deployers and was being exported as an attachment that other deployers could use (like the current MergedJBossWebMetaDataDeployer).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227616#4227616
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227616
16 years, 12 months
[JBoss jBPM] - Re: Design Patterns
by rwallis
1) there is a real persisted wait state (and its set from one minute to 19 days depending on the action taken by the user) but we have been getting stack overflow errors (after running 24/7 for about 2 weeks) and then timers stop working (we have to restart the application server) and this is considered the culprit. Given this, one of our developers doesn't want to use jBPM for batch processing that would require escalation (via a timer) every minute. I however would like to use jBPM because then we could leverage jBPM to create fail/retry logic with nodes and the jBPM console for visibility into the batch processing. (and yes there probably are alternatives to using the same token over in a loop but again thats why this was titled design patterns).
2) In the second part, in its simplest, its a task node to a fork with one transition from the fork going back to the task node and a second transition from the fork going to a different task node. When done manually from the first task node (user signals the transition rather then some external event or a timer) its an easy way to allow for a "Resend" A simple example would be "Supervisory Approval" where tokens comes into a "Processor" task node wHere they transition the token to "Supervisor Approval" but still want the token to remain in their task node in parallel, having the "send for approval" transition go to a fork solves this easily, the token goes back to the "Processor" task node and then also goes to the "Superviosr Approval" task node (with a join at the end of all of this of course). The processor continues to have it as an active task and so does the supervisor, then if the processor has an additional task that needs to be done by the supervisor (but again wants to continue to have the task as well) they simply transition the token to the supervisor task node again. In testing this all works perfectly, and all of the child tokens complete out of the join properly but it does seem that there is a limit to the number of inherited children (like maybe 1000) so if the transitions are manual no problem but if automated with timer then its a problem. The question was asked because there is concern that some "idiot" might want to click the button 1000 times an therefore cause stack overflow to occur, we can put a check in to limit this to something reasonable like 10 times but maybe we shouldn't do this at all...
P.S. sorry about posting initially to the wrong forum.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227613#4227613
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227613
16 years, 12 months
[JBoss jBPM] - Re: nothing persisting?
by ibivibiv
So, now that I know that the JTA persistance is not committing, can anyone give me a hint as to the why? I'll paste my config and a quick example of a MDB that starts a process that never commits to the database.
| <jbpm-configuration>
|
| <jbpm-context>
| <service name="persistence" factory="org.jbpm.persistence.jta.JtaDbPersistenceServiceFactory" />
| <!--<service name="persistence" factory="org.jbpm.persistence.db.DbPersistenceServiceFactory" />-->
| <service name="message" factory="org.jbpm.msg.jms.JmsMessageServiceFactory" />
| <service name="scheduler" factory="org.jbpm.scheduler.ejbtimer.EntitySchedulerServiceFactory" />
| <service name="tx" factory="org.jbpm.tx.TxServiceFactory" />
| <service name="logging" factory="org.jbpm.logging.db.DbLoggingServiceFactory" />
| <service name="authentication" factory="org.jbpm.security.authentication.DefaultAuthenticationServiceFactory" />
| </jbpm-context>
|
| <!-- use the context class loader -->
| <string name="jbpm.classLoader" value="context" />
|
| <!--
| Note, that the default job executor needs to be overwritten with a null value.
| In the enterprise configuration there should be no job executor.
| Async messaging is there bound to jms and scheduling to ejb timers.
| -->
| <null name="jbpm.job.executor" />
|
| </jbpm-configuration>
|
|
| package com.theplanet.jbpm.messagebeans;
|
| import javax.ejb.ActivationConfigProperty;
| import javax.ejb.MessageDriven;
| import javax.ejb.TransactionManagement;
| import javax.ejb.TransactionManagementType;
| import javax.ejb.TransactionAttribute;
| import javax.ejb.TransactionAttributeType;
| import javax.jms.Message;
| import javax.jms.TextMessage;
| import javax.jms.MessageListener;
|
| import org.jbpm.graph.exe.ProcessInstance;
| import org.jbpm.JbpmConfiguration;
| import org.jbpm.JbpmContext;
|
|
| /**
| * Message-Driven Bean implementation class for: ProcessMDB
| *
| */
| @MessageDriven(name = "ProcessMDB", activationConfig = {
| @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
| @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/ProcessQueue"),
| @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge") })
| @TransactionManagement(TransactionManagementType.CONTAINER)
| @TransactionAttribute(TransactionAttributeType.REQUIRED)
| public class CopyOfProcessMDB implements MessageListener {
|
| /**
| * Default constructor.
| */
| public CopyOfProcessMDB() {
| // TODO Auto-generated constructor stub
| }
|
| /**
| * @see MessageListener#onMessage(Message)
| */
| public void onMessage(Message message) {
|
| JbpmConfiguration jbpmConfig = JbpmConfiguration.getInstance();
| JbpmContext jbpmContext = jbpmConfig.createJbpmContext();
|
| try {
|
| TextMessage txt = (TextMessage) message;
| ProcessInstance processInstance = jbpmContext
| .newProcessInstanceForUpdate("TestProcess");
|
| processInstance.signal();
| jbpmContext.save(processInstance);
|
| } catch (final Exception exc) {
| try {
| exc.printStackTrace();
|
| // jbpmContext.setRollbackOnly(); old stuff when using bean managed
|
| } catch (final Exception e) {
|
| }
| } finally {
| // jbpmContext.close(); same on bean managed
|
| }
|
| }
|
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227607#4227607
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227607
16 years, 12 months