[Design of JBoss jBPM] - jBPM project structure and direction
by thomas.diesler＠jboss.com
Folks,
as you might know already, we wanted to give the jBPM project a more professional infrastructure that allows us to work more effectively and regularly produce the quality releases that you would expect from a jboss project. Generally, as with all other jboss projects the formula holds
| project == product
|
Currently we have two branches of the jBPM project
jBPM3: http://anonsvn.jboss.org/repos/jbpm/jbpm3
jBPM4: http://anonsvn.jboss.org/repos/jbpm/jbpm4
jBPM3 is the codebase that is currently in production and will be maintained for the lifetime of these production releases (i.e. 5 years). The next jBPM3 release, which is jbpm-3.3.0 will come out 1-Nov-2008 and will improve on productization aspects
* SVN code repository
* Maven build system
* Automated Hudson QA http://jbpm.dyndns.org:8280/hudson/job/jBPM-Matrix
* Defined set of target containers http://jbpm.dyndns.org/jbpmwiki/index.php?title=JBPM3SupportedTargetConta...
* Defined set of target databases http://jbpm.dyndns.org/jbpmwiki/index.php?title=JBPM3SupportedTargetDatab...
* Defined set of supported JDK's (see Hudson Matrix)
* IzPack based installer http://jbpm.dyndns.org/jbpmwiki/index.php?title=JBPM3BuildingTheInstaller
in jBPM4 we removed the notion of separate jPDL, PVM projects. It is all jBPM4 now. The next jBPM4 release, which is jbpm-4.0.0-Alpha1 will also come out 1-Nov-2008 and is about setting up the project infrastructure that, as I mentioned above already, will allow us to work effectively. You will also have
* SVN code repository
* Maven build system
* Automated Hudson QA http://jbpm.dyndns.org:8180/hudson/job/jBPM-Matrix
Additionally to that we are going to start an API+CTS effort, that will introduce a stable public API that jBPM clients can interact with. Maybe not so obvious clients are ESB, Management Console, BI/BAM, Test Environments, Graphical designer, etc. Every concept that we introduce in the API will be verified in a compatibility test suite (CTS). Starting in November, you should see regular design discussions about the API in this forum.
Following on from the 1-Nov release you should expect to see regular jBPM releases every 8 weeks.
cheers
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178982#4178982
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4178982
16 years, 3 months
[Design of JBoss Web Services] - Re: Deploying web services in service archive
by alessio.soldano＠jboss.com
"heiko.braun(a)jboss.com" wrote : anonymous wrote :
| | the jbossws deployer relies upon injection into beans declared in server//deploy/jbossws.sar/META-INF/jboss-beans.xml
| |
|
| Careful here. The deployers don't use injection, they use a service locator lookup to get to the jbossws runtime. The KernelLocator.class however (part of the runtime) uses injection and is initialized when jbossws.sar is deployed.
|
Yes, I expressed that not clearly, but that's what I meant.
anonymous wrote :
| So, the problem you encounter looks like a deployment ordering problem to me. Until jbossws.sar is fully initilaized, the WS deployers cannot do their job. The NPE could be read "JBossWS not initialized yet".
It's actually that problem.
anonymous wrote : Since both WS deployers and WS runtime have different scopes and classloaders you cannot easily put a dependency which prevents these errors. (deployers would depend on deployment)
Exactly, I can't and this would probably be against the as5 design. That's why I was thinking about having everything we need for deployment in server//deployers. So I'm wondering if doing this was evaluated in the past and not done for some reasons ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178978#4178978
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4178978
16 years, 3 months
[Design of POJO Server] - Re: Getting rid of conf/jboss-service.xml
by scott.stark＠jboss.org
The tests are working against the default config after that change, but still fail against all due to an iiop-service.xml naming dependnecy failure:
| *** CONTEXTS IN ERROR: Name -> Error
|
| vfsfile:/Users/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.GA/server/all/deploy/iiop-service.xml -> java.net.SocketTimeoutException: Receive timed out
|
I fixed this as JBAS-5997, and now all of the smoke tests are passing. We need to talk about what legacy services are needed, if they should be moved to a separate beans/service.xml, etc.
| <?xml version="1.0" encoding="UTF-8"?>
|
| <!-- $Id: jboss-service.xml 77499 2008-08-26 18:38:57Z dimitris(a)jboss.org $ -->
|
| <!-- ===================================================================== -->
| <!-- JBoss Server Configuration -->
| <!-- ===================================================================== -->
|
| <server>
|
| <!-- Load all jars from the JBOSS_DIST/server/<config>/lib directory. This
| can be restricted to specific jars by specifying them in the archives
| attribute.
| -->
| <classpath codebase="${jboss.server.lib.url:lib}" archives="*"/>
|
| <!-- ==================================================================== -->
| <!-- Main Deployer -->
| <!-- ==================================================================== -->
| <mbean code="org.jboss.deployment.MainDeployer"
| name="jboss.system:service=MainDeployer">
| <!-- This is used to delegate the deployment handling -->
| <attribute name="KernelMainDeployer"><inject bean="MainDeployer" /></attribute>
| <!-- This is used to validate incomplete deployments -->
| <attribute name="Controller"><inject bean="jboss.kernel:service=Kernel" property="controller"/></attribute>
| </mbean>
|
| <!-- ==================================================================== -->
| <!-- SAR Deployer -->
| <!-- ==================================================================== -->
| <mbean code="org.jboss.deployment.SARDeployer"
| name="jboss.system:service=ServiceDeployer">
| <depends>jboss.system:service=MainDeployer</depends>
| </mbean>
|
| <!-- ==================================================================== -->
| <!-- XMBean Persistence -->
| <!-- ==================================================================== -->
| <mbean code="org.jboss.system.pm.AttributePersistenceService"
| name="jboss:service=AttributePersistenceService"
| xmbean-dd="resource:xmdesc/AttributePersistenceService-xmbean.xml">
| <!-- the AttributePersistenceService is persistent, itself -->
|
| <!--
| <attribute name="AttributePersistenceManagerClass">org.jboss.system.pm.XMLAttributePersistenceManager</attribute>
| <attribute name="AttributePersistenceManagerConfig">
| <data-directory>data/xmbean-attrs</data-directory>
| </attribute>
| <attribute name="ApmDestroyOnServiceStop">false</attribute>
| <attribute name="VersionTag"></attribute>
| -->
| </mbean>
|
| <!-- A Thread pool service -->
| <mbean code="org.jboss.util.threadpool.BasicThreadPool"
| name="jboss.system:service=ThreadPool">
| <attribute name="Name">JBoss System Threads</attribute>
| <attribute name="ThreadGroupName">System Threads</attribute>
| <!-- How long a thread will live without any tasks in MS -->
| <attribute name="KeepAliveTime">60000</attribute>
| <!-- The max number of threads in the pool -->
| <attribute name="MaximumPoolSize">10</attribute>
| <!-- The max number of tasks before the queue is full -->
| <attribute name="MaximumQueueSize">1000</attribute>
| <!-- The behavior of the pool when a task is added and the queue is full.
| abort - a RuntimeException is thrown
| run - the calling thread executes the task
| wait - the calling thread blocks until the queue has room
| discard - the task is silently discarded without being run
| discardOldest - check to see if a task is about to complete and enque
| the new task if possible, else run the task in the calling thread
| -->
| <attribute name="BlockingMode">run</attribute>
| </mbean>
|
|
| <!-- ==================================================================== -->
| <!-- JBoss RMI Classloader - only install when available -->
| <!-- ==================================================================== -->
| <mbean code="org.jboss.util.property.jmx.SystemPropertyClassValue"
| name="jboss.rmi:type=RMIClassLoader">
| <attribute name="Property">java.rmi.server.RMIClassLoaderSpi</attribute>
| <attribute name="ClassName">org.jboss.system.JBossRMIClassLoader</attribute>
| </mbean>
|
| <!-- ==================================================================== -->
| <!-- JNDI -->
| <!-- ==================================================================== -->
|
| <!-- A simple mbean wrapper around the jndi Naming object. This
| only handles an in memory instance. The NamingService uses this
| as the JNDI store and exposes it remotely.
| -->
| <mbean code="org.jnp.server.NamingBeanImpl"
| name="jboss:service=NamingBeanImpl"
| xmbean-dd="resource:xmdesc/NamingBean-xmbean.xml">
| </mbean>
|
| <mbean code="org.jboss.naming.NamingService"
| name="jboss:service=Naming"
| xmbean-dd="resource:xmdesc/NamingService-xmbean.xml">
| <!-- The call by value mode. true if all lookups are unmarshalled using
| the caller's TCL, false if in VM lookups return the value by reference.
| -->
| <attribute name="CallByValue">false</attribute>
|
| <!-- The listening port for the bootstrap JNP service. Set this to -1
| to run the NamingService without the JNP invoker listening port.
| -->
| <attribute name="Port">
| <value-factory bean="ServiceBindingManager" method="getIntBinding">
| <parameter>jboss:service=Naming</parameter>
| <parameter>Port</parameter>
| </value-factory>
| </attribute>
|
| <!-- The bootstrap JNP server bind address. This also sets the default
| RMI service bind address. Empty == all addresses
| -->
| <attribute name="BindAddress">${jboss.bind.address}</attribute>
| <!-- The port of the RMI naming service, 0 == anonymous -->
| <attribute name="RmiPort">
| <value-factory bean="ServiceBindingManager" method="getIntBinding">
| <parameter>jboss:service=Naming</parameter>
| <parameter>RmiPort</parameter>
| </value-factory>
| </attribute>
| <!-- The RMI service bind address. Empty == all addresses
| -->
| <attribute name="RmiBindAddress">${jboss.bind.address}</attribute>
| <!-- The thread pool service used to control the bootstrap lookups -->
| <depends optional-attribute-name="LookupPool"
| proxy-type="attribute">jboss.system:service=ThreadPool</depends>
| <!-- An example of using the unifed invoker as the transport.
| <depends optional-attribute-name="InvokerProxyFactory"
| proxy-type="attribute">jboss:service=proxyFactory,type=unified,target=Naming</depends>
| -->
| <depends optional-attribute-name="Naming"
| proxy-type="attribute">jboss:service=NamingBeanImpl</depends>
| </mbean>
|
| <mbean code="org.jboss.naming.JNDIView"
| name="jboss:service=JNDIView"
| xmbean-dd="resource:xmdesc/JNDIView-xmbean.xml">
| <!-- The HANamingService service name -->
| <attribute name="HANamingService">jboss:service=HAJNDI</attribute>
| </mbean>
|
| <!-- ==================================================================== -->
| <!-- Security -->
| <!-- ==================================================================== -->
|
| <!-- JAAS security manager and realm mapping -->
| <mbean code="org.jboss.security.plugins.JaasSecurityManagerService"
| name="jboss.security:service=JaasSecurityManager">
| <!-- A flag which indicates whether the SecurityAssociation server mode
| is set on service creation. This is true by default since the
| SecurityAssociation should be thread local for multi-threaded server
| operation.
| -->
| <attribute name="ServerMode">true</attribute>
| <attribute name="SecurityManagerClassName">org.jboss.security.plugins.JaasSecurityManager</attribute>
| <attribute name="DefaultUnauthenticatedPrincipal">anonymous</attribute>
| <!-- DefaultCacheTimeout: Specifies the default timed cache policy timeout
| in seconds.
| If you want to disable caching of security credentials, set this to 0 to
| force authentication to occur every time. This has no affect if the
| AuthenticationCacheJndiName has been changed from the default value.
| -->
| <attribute name="DefaultCacheTimeout">1800</attribute>
| <!-- DefaultCacheResolution: Specifies the default timed cache policy
| resolution in seconds. This controls the interval at which the cache
| current timestamp is updated and should be less than the DefaultCacheTimeout
| in order for the timeout to be meaningful. This has no affect if the
| AuthenticationCacheJndiName has been changed from the default value.
| -->
| <attribute name="DefaultCacheResolution">60</attribute>
| <!-- DeepCopySubjectMode: This set the copy mode of subjects done by the
| security managers to be deep copies that makes copies of the subject
| principals and credentials if they are cloneable. It should be set to
| true if subject include mutable content that can be corrupted when
| multiple threads have the same identity and cache flushes/logout clearing
| the subject in one thread results in subject references affecting other
| threads.
| -->
| <attribute name="DeepCopySubjectMode">false</attribute>
| </mbean>
|
| <!-- ==================================================================== -->
| <!-- Remoting services -->
| <!-- ==================================================================== -->
|
| <!-- For detailed description of all these configuration attributes, please see the -->
| <!-- JBoss Remoting User's Guide or wiki (http://www.jboss.org/wiki/Wiki.jsp?page=Remoting_configuration) -->
|
| <!-- The NetworkRegistry contains all the local and remote -->
| <!-- servers that it recognizes. The remote ones registered -->
| <!-- are dependant on the detectors running and which domains -->
| <!-- they are configured to identify. -->
| <mbean code="org.jboss.remoting.network.NetworkRegistry"
| name="jboss.remoting:service=NetworkRegistry"/>
|
| <!-- The Connector is the core component of the remoting server service. -->
| <!-- It binds the remoting invoker (transport protocol, callback configuration, -->
| <!-- data marshalling, etc.) with the invocation handlers. -->
| <mbean code="org.jboss.remoting.transport.Connector"
| name="jboss.remoting:service=Connector,transport=socket"
| display-name="Socket transport Connector">
|
| <!-- Can either just specify the InvokerLocator attribute and not the invoker element in the -->
| <!-- Configuration attribute, or do the full invoker configuration in the in invoker element -->
| <!-- of the Configuration attribute. -->
|
| <!-- Remember that if you do use more than one param on the uri, will have to include as a CDATA, -->
| <!-- otherwise, parser will complain. -->
| <!--
| <attribute name="InvokerLocator">
| <value-factory bean="ServiceBindingManager" method="getStringBinding">
| <parameter>jboss.remoting:service=Connector,transport=socket</parameter>
| <parameter><![CDATA[socket://${host}:${port}/?datatype=invocation]]></parameter>
| </value-factory>
| </attribute>
| -->
|
| <attribute name="Configuration">
| <!-- Using the following <invoker> element instead of the InvokerLocator above because specific attributes needed. -->
| <!-- If wanted to use any of the parameters below, can just add them as parameters to the url above if wanted use the InvokerLocator attribute. -->
|
| <value-factory bean="ServiceBindingManager" method="getElementBinding">
| <parameter>jboss.remoting:service=Connector,transport=socket</parameter>
| <parameter><![CDATA[
| <config>
| <!-- Other than transport type and handler, none of these configurations are required (will just use defaults). -->
| <invoker transport="socket">
| <attribute name="dataType" isParam="true">invocation</attribute>
| <attribute name="marshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationMarshaller</attribute>
| <attribute name="unmarshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationUnMarshaller</attribute>
| <!-- This will be port on which the marshall loader port runs on. -->
| <!-- <attribute name="loaderport" isParam="true">4447</attribute> -->
| <!-- The following are specific to socket invoker -->
| <!-- <attribute name="numAcceptThreads">1</attribute>-->
| <!-- <attribute name="maxPoolSize">303</attribute>-->
| <!-- <attribute name="clientMaxPoolSize" isParam="true">304</attribute>-->
| <!-- <attribute name="timeout" isParam="true">600000</attribute>-->
| <attribute name="serverBindAddress">${host}</attribute>
| <attribute name="serverBindPort">${port}</attribute>
| <!-- <attribute name="clientConnectAddress">216.23.33.2</attribute> -->
| <!-- <attribute name="clientConnectPort">7777</attribute> -->
| <attribute name="enableTcpNoDelay" isParam="true">true</attribute>
| <!-- <attribute name="backlog">200</attribute>-->
| <!-- The following is for callback configuration and is independant of invoker type -->
| <!-- <attribute name="callbackMemCeiling">30</attribute>-->
| <!-- indicates callback store by fully qualified class name -->
| <!-- <attribute name="callbackStore">org.jboss.remoting.CallbackStore</attribute>-->
| <!-- indicates callback store by object name -->
| <!-- <attribute name="callbackStore">jboss.remoting:service=CallbackStore,type=Serializable</attribute> -->
| <!-- config params for callback store. if were declaring callback store via object name, -->
| <!-- could have specified these config params there. -->
| <!-- StoreFilePath indicates to which directory to write the callback objects. -->
| <!-- The default value is the property value of 'jboss.server.data.dir' and if this is not set, -->
| <!-- then will be 'data'. Will then append 'remoting' and the callback client's session id. -->
| <!-- An example would be 'data\remoting\5c4o05l-9jijyx-e5b6xyph-1-e5b6xyph-2'. -->
| <!-- <attribute name="StoreFilePath">callback</attribute>-->
| <!-- StoreFileSuffix indicates the file suffix to use for the callback objects written to disk. -->
| <!-- The default value for file suffix is 'ser'. -->
| <!-- <attribute name="StoreFileSuffix">cst</attribute>-->
| </invoker>
|
| <!-- At least one handler is required by the connector. If have more than one, must decalre -->
| <!-- different subsystem values. Otherwise, all invocations will be routed to the only one -->
| <!-- that is declared. -->
| <handlers>
| <!-- The JSR88 deployment service StreamingTarget handler -->
| <handler subsystem="JSR88">org.jboss.deployment.remoting.DeployHandler</handler>
| </handlers>
| </config>
| ]]>
| </parameter>
| </value-factory>
| </attribute>
| <depends>jboss.remoting:service=NetworkRegistry</depends>
| </mbean>
|
|
| <!-- <mbean code="org.jboss.remoting.detection.jndi.JNDIDetector"-->
| <!-- name="jboss.remoting:service=Detector,transport=jndi">-->
| <!-- host to which the detector will connect to for the JNDI server. -->
| <!-- <attribute name="Host">localhost</attribute>-->
| <!-- port to which detector will connect to for the JNDI server. -->
| <!-- <attribute name="Port">5555</attribute>-->
| <!-- context factory string used when connecting to the JNDI server. -->
| <!-- The default is org.jnp.interfaces.NamingContextFactory. -->
| <!-- <attribute name="ContextFactory">org.acme.NamingContextFactory</attribute> -->
| <!-- url package string to use when connecting to the JNDI server. -->
| <!-- The default is org.jboss.naming:org.jnp.interfaces. -->
| <!-- <attribute name="URLPackage">org.acme.naming</attribute> -->
| <!-- Sets the number of detection iterations before manually pinging -->
| <!-- remote server to make sure still alive. This is needed since remote server -->
| <!-- could crash and yet still have an entry in the JNDI server, -->
| <!-- thus making it appear that it is still there. The default value is 5. -->
| <!-- <attribute name="CleanDetectionNumber">20</attribute>-->
|
| <!-- Specifies the domains in which the detector will recognize -->
| <!-- detections. If servers are not configured to be in these -->
| <!-- domains, they will not be added to NetworkRegistry. -->
| <!-- <attribute name="Configuration">-->
| <!-- <domains>-->
| <!-- <domain>roxanne</domain>-->
| <!-- <domain>sparky</domain>-->
| <!-- </domains>-->
| <!-- </attribute>-->
| <!-- </mbean>-->
|
| <!-- ==================================================================== -->
| <!-- Monitoring and Management -->
| <!-- ==================================================================== -->
|
| <!-- Uncomment to enable JMX monitoring of the bean cache
| <mbean code="org.jboss.monitor.BeanCacheMonitor"
| name="jboss.monitor:name=BeanCacheMonitor"/>
| -->
|
| <!-- Uncomment to enable JMX monitoring of the entity bean locking
| <mbean code="org.jboss.monitor.EntityLockMonitor"
| name="jboss.monitor:name=EntityLockMonitor"/>
| -->
|
| <!-- ==================================================================== -->
| <!-- An MBean that is a registry for JDBC type-mapping metadata -->
| <!-- ==================================================================== -->
|
| <mbean code="org.jboss.ejb.plugins.cmp.jdbc.metadata.MetaDataLibrary"
| name="jboss.jdbc:service=metadata"/>
|
| </server>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178952#4178952
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4178952
16 years, 3 months