jboss-dev-forums — The jboss development forum posts

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: CLIENT_ACKNOWLEDGE optimization

[timfox <nu...@jb...>]

Absolutely.

I left this one for now, since I considered it an optimisation not necessary to get us through the basic compliance for the non distributed alpha.

Actually also the DUPS_OK_ACKNOWLEDGE mode is non optimised too - currently it just works as AUTO_ACKNOWLEDGE which I believe is compliant but obviously not optimal.

It's likely both of these could use the same operation to send their batch of messages to the server.

 


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880084#3880084

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880084

[Jboss-dev-forums] [Design of JBoss Portal] - How to design the Jboss portal

[sarangk <nu...@jb...>]

Hi All,

  Is there any tutorials that will guide the steps that we need to do for the designing a new portals. The reference guide is only says about the xml files and the configurations where exactly the the role of the java class come into picture. And how to figure out that we have to use these set of classes for the developement.

Thanks in advance. 

Saravanan.K

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880083#3880083

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880083

[Jboss-dev-forums] [Design of Mail Services] - need help running code from HEAD

[jeff87 <nu...@jb...>]

Hi everyone. I would like to start contributing and I am having some problems running the latest code. I need help please. I had M2 running just fine. I was sending myself e-mails. So I get the latest from CVS and do ant dev-deploy and I get some messages during the build. If they matter, it's many of these.

xdoclet:
  | [hibernatedoclet] 00:24:07,500 ERROR [findGetterMethod] Method getVerbose not found.
  | [hibernatedoclet] 00:24:07,500 ERROR [findGetterMethod] Method getForce not found.
  | [hibernatedoclet] 00:24:07,500 ERROR [findGetterMethod] Method getExcludePackageNames not found.
  | [hibernatedoclet] 00:24:07,500 ERROR [findGetterMethod] Method isExcludePackageNames not found.
  | [hibernatedoclet] 00:24:07,500 ERROR [fillConfigParamsHashMapUsingReflectionFor] Getter method not found.

Then when it deploys, the console shows these errors:

00:24:22,265 ERROR [SchemaUpdate] Unsuccessful: create table messageflags (storeid varchar(32) not null, flagvalue varchar(255), flagindex integer not null, primary key (storeid, flagindex))
  | 00:24:22,265 ERROR [SchemaUpdate] Table already exists: MESSAGEFLAGS in statement [create table messageflags]
  | 00:24:22,265 ERROR [SchemaUpdate] Unsuccessful: create table storedmessages (storeid varchar(32) not null, senderaddress varchar(255) not null, createtime timestamp not null, msgsize bigint not null, msgbytes varbinary(255), fpath varchar(255), primary key (storeid))
  | 00:24:22,265 ERROR [SchemaUpdate] Table already exists: STOREDMESSAGES in statement [create table storedmessages]
  | 00:24:22,265 ERROR [SchemaUpdate] Unsuccessful: create table MAILSTORE (ID bigint generated by default as identity (start with 1), LENGTH bigint, PAGESIZE integer, NUMPAGES integer)
  | 00:24:22,265 ERROR [SchemaUpdate] Table already exists: MAILSTORE in statement [create table MAILSTORE]
  | 00:24:22,265 ERROR [SchemaUpdate] Unsuccessful: create table PAGES (ID bigint generated by default as identity (start with 1), PAGE_NO integer, DATA varbinary(2147483647), BLOB_ID bigint)
  | 00:24:22,265 ERROR [SchemaUpdate] Table already exists: PAGES in statement [create table PAGES]
  | 00:24:22,265 ERROR [SchemaUpdate] Unsuccessful: alter table messageflags add constraint FKB3B6DAE08FB051BC foreign key (storeid) references storedmessages
  | 00:24:22,265 ERROR [SchemaUpdate] Constraint already exists: FKB3B6DAE08FB051BC in statement [alter table messageflags add constraint FKB3B6DAE08FB051BC foreign key (storeid) references storedmessages]

When I go in to Thunderbird, I can no longer send/receive e-mail. I get a connection refused message and nothing shows up in the console that there was a request. Below is my jboss-service.xml if that helps at all. 

Thanks everyone,
Jeff


  | <?xml version="1.0" encoding="UTF-8"?>
  | <!-- $Id: jboss-service.xml,v 1.117.2.3 2004/10/26 14:57:40 loubyansky Exp $ -->
  | 
  | <!-- ===================================================================== -->
  | <!--  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="lib" archives="*"/>
  | 
  | 
  |    <!-- ==================================================================== -->
  |    <!-- JSR-77 Single JBoss Server Management Domain                         -->
  |    <!-- ==================================================================== -->
  |    <mbean code="org.jboss.management.j2ee.LocalJBossServerDomain"
  |       name="jboss.management.local:j2eeType=J2EEDomain,name=Manager">
  |       <attribute name="MainDeployer">jboss.system:service=MainDeployer</attribute>
  |       <attribute name="SARDeployer">jboss.system:service=ServiceDeployer</attribute>
  |       <attribute name="EARDeployer">jboss.j2ee:service=EARDeployer</attribute>
  |       <attribute name="EJBDeployer">jboss.ejb:service=EJBDeployer</attribute>
  |       <attribute name="RARDeployer">jboss.jca:service=RARDeployer</attribute>
  |       <attribute name="CMDeployer">jboss.jca:service=ConnectionFactoryDeployer</attribute>
  |       <attribute name="WARDeployer">jboss.web:service=WebServer</attribute>
  |       <attribute name="MailService">jboss:service=Mail</attribute>
  |       <attribute name="JMSService">jboss.mq:service=DestinationManager</attribute>
  |       <attribute name="JNDIService">jboss:service=Naming</attribute>
  |       <attribute name="JTAService">jboss:service=TransactionManager</attribute>
  |       <attribute name="UserTransactionService">jboss:service=ClientUserTransaction</attribute>
  |       <attribute name="RMI_IIOPService">jboss:service=CorbaORB</attribute>
  |    </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>
  | 
  |    <!-- Preload all custom editors for VMs that don't use the thread
  |         context class loader when searching for PropertyEditors. Uncomment
  |         if your JDK 1.3.0 VM fails to find JBoss PropertyEditors.
  |    <mbean code="org.jboss.varia.property.PropertyEditorManagerService"
  |      name="jboss:type=Service,name=BootstrapEditors">
  |      <attribute name="BootstrapEditors">
  |        java.math.BigDecimal=org.jboss.util.propertyeditor.BigDecimalEditor
  |        java.lang.Boolean=org.jboss.util.propertyeditor.BooleanEditor
  |        java.lang.Class=org.jboss.util.propertyeditor.ClassEditor
  |        java.util.Date=org.jboss.util.propertyeditor.DateEditor
  |        java.io.File=org.jboss.util.propertyeditor.FileEditor
  |        java.net.InetAddress=org.jboss.util.propertyeditor.InetAddressEditor
  |        java.lang.Integer=org.jboss.util.propertyeditor.IntegerEditor
  |        javax.management.ObjectName=org.jboss.mx.util.propertyeditor.ObjectNameEditor
  |        java.util.Properties=org.jboss.util.propertyeditor.PropertiesEditor
  |        [Ljava.lang.String;=org.jboss.util.propertyeditor.StringArrayEditor
  |        java.net.URL=org.jboss.util.propertyeditor.URLEditor
  |      </attribute>
  |    </mbean>
  |    -->
  | 
  |    <!-- ==================================================================== -->
  |    <!-- Log4j Initialization                                                 -->
  |    <!-- ==================================================================== -->
  | 
  |    <mbean code="org.jboss.logging.Log4jService"
  |       name="jboss.system:type=Log4jService,service=Logging">
  |       <attribute name="ConfigurationURL">resource:log4j.xml</attribute>
  |       <!-- Set the org.apache.log4j.helpers.LogLog.setQuiteMode. As of log4j1.2.8
  |       this needs to be set to avoid a possible deadlock on exception at the
  |       appender level. See bug#696819.
  |       -->
  |       <attribute name="Log4jQuietMode">true</attribute>
  |       <!-- How frequently in seconds the ConfigurationURL is checked for changes -->
  |       <attribute name="RefreshPeriod">60</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>
  | 
  |    <!-- ==================================================================== -->
  |    <!-- Service Binding                                                      -->
  |    <!-- ==================================================================== -->
  | 
  |    <!-- Automatically activated when generatting the clustering environment -->
  |    <!-- @TESTSUITE_CLUSTER_CONFIG@ -->
  | 
  |    <!--
  |       | Binding service manager for port/host mapping. This is a sample
  |       | config that demonstrates a JBoss instances with a server name 'jboss1'
  |       | loading its bindings from an XML file using the ServicesStoreFactory
  |       | implementation returned by the XMLServicesStoreFactory.
  |       |
  |       | ServerName: The unique name assigned to a JBoss server instance for
  |       | lookup purposes. This allows a single ServicesStore to handle mulitiple
  |       | JBoss servers.
  |       |
  |       | StoreURL: The URL string passed to org.jboss.services.binding.ServicesStore
  |       | during initialization that specifies how to connect to the bindings store.
  |       | StoreFactory: The org.jboss.services.binding.ServicesStoreFactory interface
  |       | implementation to create to obtain the ServicesStore instance.
  | 
  |    <mbean code="org.jboss.services.binding.ServiceBindingManager"
  |      name="jboss.system:service=ServiceBindingManager">
  |      <attribute name="ServerName">ports-01</attribute>
  |      <attribute name="StoreURL">../docs/examples/binding-manager/sample-bindings.xml</attribute>
  |      <attribute name="StoreFactoryClassName">
  |        org.jboss.services.binding.XMLServicesStoreFactory
  |      </attribute>
  |    </mbean>
  | 
  |    -->
  | 
  | 
  |    <!-- ==================================================================== -->
  |    <!-- Class Loading                                                        -->
  |    <!-- ==================================================================== -->
  | 
  |    <mbean code="org.jboss.web.WebService"
  |       name="jboss:service=WebService">
  |       <attribute name="Port">8083</attribute>
  |       <!-- Should resources and non-EJB classes be downloadable -->
  |       <attribute name="DownloadServerClasses">true</attribute>
  |       <attribute name="Host">${jboss.bind.address}</attribute>
  |       <attribute name="BindAddress">${jboss.bind.address}</attribute>
  |    </mbean>
  | 
  |    <!-- ==================================================================== -->
  |    <!-- JNDI                                                                 -->
  |    <!-- ==================================================================== -->
  | 
  |    <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">1099</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">1098</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>
  |    </mbean>
  | 
  |    <mbean code="org.jboss.naming.JNDIView"
  |    		name="jboss:service=JNDIView"
  |    		xmbean-dd="resource:xmdesc/JNDIView-xmbean.xml">
  |    </mbean>
  | 
  |    <!-- ==================================================================== -->
  |    <!-- Security                                                             -->
  |    <!-- ==================================================================== -->
  | 
  |    <mbean code="org.jboss.security.plugins.SecurityConfig"
  |       name="jboss.security:service=SecurityConfig">
  |       <attribute name="LoginConfig">jboss.security:service=XMLLoginConfig</attribute>
  |    </mbean>
  |    <mbean code="org.jboss.security.auth.login.XMLLoginConfig"
  |       name="jboss.security:service=XMLLoginConfig">
  |       <attribute name="ConfigResource">login-config.xml</attribute>
  |    </mbean>
  | 
  |    <!-- JAAS security manager and realm mapping -->
  |    <mbean code="org.jboss.security.plugins.JaasSecurityManagerService"
  |       name="jboss.security:service=JaasSecurityManager">
  |       <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>
  |    </mbean>
  | 
  |    <!-- ==================================================================== -->
  |    <!-- Transactions                                                         -->
  |    <!-- ==================================================================== -->
  |    <!-- The configurable Xid factory.  For use with Oracle, set pad to true -->
  |    <mbean code="org.jboss.tm.XidFactory"
  |       name="jboss:service=XidFactory">
  |       <!--attribute name="Pad">true</attribute-->
  |    </mbean>
  | 
  |    <!--
  |       | The fast in-memory transaction manager.
  |     -->
  |    <mbean code="org.jboss.tm.TransactionManagerService"
  |       name="jboss:service=TransactionManager"
  |       xmbean-dd="resource:xmdesc/TransactionManagerService-xmbean.xml">
  |       <attribute name="TransactionTimeout">300</attribute>
  |       <!-- set to false to disable transaction demarcation over IIOP -->
  |       <attribute name="GlobalIdsEnabled">true</attribute>
  |       <depends optional-attribute-name="XidFactory">jboss:service=XidFactory</depends>
  |    </mbean>
  |    <!--
  |       | UserTransaction support.
  |     -->
  |    <mbean code="org.jboss.tm.usertx.server.ClientUserTransactionService"
  |       name="jboss:service=ClientUserTransaction"
  |       xmbean-dd="resource:xmdesc/ClientUserTransaction-xmbean.xml">
  |       <depends>
  |          <mbean code="org.jboss.invocation.jrmp.server.JRMPProxyFactory"
  |             name="jboss:service=proxyFactory,target=ClientUserTransactionFactory">
  |             <attribute name="InvokerName">jboss:service=invoker,type=jrmp</attribute>
  |             <attribute name="TargetName">jboss:service=ClientUserTransaction</attribute>
  |             <attribute name="JndiName">UserTransactionSessionFactory</attribute>
  |             <attribute name="ExportedInterface">org.jboss.tm.usertx.interfaces.UserTransactionSessionFactory</attribute>
  |             <attribute name="ClientInterceptors">
  |                <interceptors>
  |                   <interceptor>org.jboss.proxy.ClientMethodInterceptor</interceptor>
  |                   <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
  |                </interceptors>
  |             </attribute>
  |             <depends>jboss:service=invoker,type=jrmp</depends>
  |          </mbean>
  |       </depends>
  |       <depends optional-attribute-name="TxProxyName">
  |          <mbean code="org.jboss.invocation.jrmp.server.JRMPProxyFactory"
  |             name="jboss:service=proxyFactory,target=ClientUserTransaction">
  |             <attribute name="InvokerName">jboss:service=invoker,type=jrmp</attribute>
  |             <attribute name="TargetName">jboss:service=ClientUserTransaction</attribute>
  |             <attribute name="JndiName"></attribute>
  |             <attribute name="ExportedInterface">org.jboss.tm.usertx.interfaces.UserTransactionSession</attribute>
  |             <attribute name="ClientInterceptors">
  |                <interceptors>
  |                   <interceptor>org.jboss.proxy.ClientMethodInterceptor</interceptor>
  |                   <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
  |                </interceptors>
  |             </attribute>
  |             <depends>jboss:service=invoker,type=jrmp</depends>
  |          </mbean>
  |       </depends>
  |    </mbean>
  | 
  |    <!-- ==================================================================== -->
  |    <!-- Invokers to the JMX node                                             -->
  |    <!-- ==================================================================== -->
  | 
  |    <!-- RMI/JRMP invoker -->
  |    <mbean code="org.jboss.invocation.jrmp.server.JRMPInvoker"
  |       name="jboss:service=invoker,type=jrmp">
  |       <attribute name="RMIObjectPort">4444</attribute>
  |       <attribute name="ServerAddress">${jboss.bind.address}</attribute>
  |       <!--
  |       <attribute name="RMIClientSocketFactory">custom</attribute>
  |       <attribute name="RMIServerSocketFactory">custom</attribute>
  |       <attribute name="RMIServerSocketAddr">custom</attribute>
  |       <attribute name="SecurityDomain">ssl-domain-name</attribute>
  |       -->
  |       <depends>jboss:service=TransactionManager</depends>
  |    </mbean>
  | 
  |    <mbean code="org.jboss.invocation.local.LocalInvoker"
  |       name="jboss:service=invoker,type=local">
  | 
  |       <depends>jboss:service=TransactionManager</depends>
  |    </mbean>
  | 
  |    <mbean code="org.jboss.invocation.pooled.server.PooledInvoker"
  |       name="jboss:service=invoker,type=pooled">
  |       <attribute name="NumAcceptThreads">1</attribute>
  |       <attribute name="MaxPoolSize">300</attribute>
  |       <attribute name="ClientMaxPoolSize">300</attribute>
  |       <attribute name="SocketTimeout">60000</attribute>
  |       <attribute name="ServerBindAddress">${jboss.bind.address}</attribute>
  |       <attribute name="ServerBindPort">4445</attribute>
  |       <attribute name="ClientConnectAddress">${jboss.bind.address}</attribute>
  |       <attribute name="ClientConnectPort">0</attribute>
  |       <attribute name="EnableTcpNoDelay">false</attribute>
  | 
  |       <depends optional-attribute-name="TransactionManagerService">jboss:service=TransactionManager</depends>
  |    </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"/>
  | 
  |    <!-- ==================================================================== -->
  |    <!-- Deployment Scanning                                                  -->
  |    <!-- ==================================================================== -->
  | 
  |    <!-- An mbean for hot deployment/undeployment of archives.
  |    -->
  |    <mbean code="org.jboss.deployment.scanner.URLDeploymentScanner"
  |       name="jboss.deployment:type=DeploymentScanner,flavor=URL">
  | 
  |       <!-- Uncomment (and comment/remove version below) to enable usage of the
  |         DeploymentCache
  |       <depends optional-attribute-name="Deployer">jboss.deployment:type=DeploymentCache</depends>
  |       -->
  |       <depends optional-attribute-name="Deployer">jboss.system:service=MainDeployer</depends>
  | 
  |       <!-- The URLComparator can be used to specify a deployment ordering
  |            for deployments found in a scanned directory.  The class specified
  |            must be an implementation of java.util.Comparator, it must be able
  |            to compare two URL objects, and it must have a no-arg constructor.
  |            Two deployment comparators are shipped with JBoss:
  |              - org.jboss.deployment.DeploymentSorter
  |                Sorts by file extension, as follows:
  |                  "sar", "service.xml", "rar", "jar", "war", "wsr", "ear", "zip",
  |                  "*"
  |              - org.jboss.deployment.scanner.PrefixDeploymentSorter
  |                If the name portion of the url begins with 1 or more digits, those
  |                digits are converted to an int (ignoring leading zeroes), and
  |                files are deployed in that order.  Files that do not start with
  |                any digits will be deployed first, and they will be sorted by
  |                extension as above with DeploymentSorter.
  |       -->
  |       <attribute name="URLComparator">org.jboss.deployment.DeploymentSorter</attribute>
  |       <!--
  |       <attribute name="URLComparator">org.jboss.deployment.scanner.PrefixDeploymentSorter</attribute>
  |       -->
  | 
  |       <!-- The Filter specifies a java.io.FileFilter for scanned
  |            directories.  Any file not accepted by this filter will not be
  |            deployed.  The org.jboss.deployment.scanner.DeploymentFilter
  |            rejects the following patterns:
  |                "#*", "%*", ",*", ".*", "_$*", "*#", "*$", "*%", "*.BAK",
  |                "*.old", "*.orig", "*.rej", "*.bak", "*,v", "*~", ".make.state",
  |                ".nse_depinfo", "CVS", "CVS.admin", "RCS", "RCSLOG", "SCCS",
  |                "TAGS", "core", "tags"
  |       -->
  |       <attribute name="Filter">org.jboss.deployment.scanner.DeploymentFilter</attribute>
  | 
  |       <attribute name="ScanPeriod">5000</attribute>
  | 
  |       <!-- URLs are comma separated and resolve relative to the server home URL
  |          unless the given path is absolute. If the URL ends in "/" it is
  |          considered a collection and scanned, otherwise it is simply deployed;
  |          this follows RFC2518 convention and allows discrimination between
  |          collections and directories that are simply unpacked archives.
  | 
  |          URLs may be local (file:) or remote (http:). Scanning is supported
  |          for remote URLs but unpacked deployment units are not.
  | 
  |          Example URLs:
  |             deploy/
  |                  scans ${jboss.server.url}/deploy/, which is local or remote
  |                  depending on the URL used to boot the server
  |             ${jboss.server.home}/deploy/
  |                  scans ${jboss.server.home)/deploy, which is always local
  |             file:/var/opt/myapp.ear
  |                  deploy myapp.ear from a local location
  |             file:/var/opt/apps/
  |                  scans the specified directory
  |             http://www.test.com/netboot/myapp.ear
  |                  deploys myapp.ear from a remote location
  |             http://www.test.com/netboot/apps/
  |                  scans the specified WebDAV location
  |        -->
  |       <attribute name="URLs">
  |          deploy/
  |       </attribute>
  | 
  |       <!-- Indicates if the scanner should recursively scan directories that
  |       contain no "." in their names. This can be used to group applications
  |       and services that must be deployed and that have the same
  |       logical function in the same directory i.e.
  |         deploy/JMX/
  |         deploy/JMS/
  |         ...
  |       -->
  | 
  |       <attribute name="RecursiveSearch">True</attribute>
  | 
  |    </mbean>
  | 
  | </server>
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880070#3880070

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880070

[Jboss-dev-forums] [Design of Security on JBoss] - Removing MDB username and password from jboss.xml

[gray1 <nu...@jb...>]

Hi all,

I posted the following question 
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3880061#3880061 in the JBoss security jaas forum.

The response I got back indicates that what I am trying to do (remove the JMS username and password from the MDB section of jboss.xml so I don't have usernames and passwords in my deployment artifact - the EAR) is not currently possible but according to my understanding of the intentions of J2EE this is pretty important for anyone that has a true separation of roles between bean developer and bean deployer.

So as per Adrian Brock's suggestion I am raising this as an item for discussion.  Please read the above link and put forward your comments or suggestions for how this feature could be added to JBoss.

Thanks,

Graeme.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880062#3880062

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880062

[Jboss-dev-forums] [Nukes Development] - Re: does nukes support Oracle ? what version? and a lot of q

[thepriz <nu...@jb...>]

We run nukes on an oracle server. it is the 1.0 version. We had to create the nukes-ds for oracle. we also had to turn all auto create of the tables off and create the database ourselves. With these changes it works fine.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880050#3880050

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880050

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Connection handles transacted messages/acknowledgments

[<ovi...@jb...>]

I see.  The connection delegate, or more precisely the ResourceManager's map acts as an aggregator for messages possibly coming from different sessions that joined the same transaction. This only applies to XASessions, though, but it's enough to justify the current design.



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880042#3880042

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880042

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Connection handles transacted messages/acknowledgments

[<ad...@jb...>]

"ovi...@jb..." wrote : 
  | Why did you choose to involve the connection in this, at all? A JMS transaction is always localized at session level.
  | ...
  | I could see the reason JBossMQ does that: because only the connection has access to the ServerIL, which physically sends stuff to the server.
  | 

There is more to it that when JTA (transaction interleaving) is involved.
You can have one session do some work in the transaction, then it leaves
the transaction. Later another session takes over.
The jms session(s) maybe involved in a different transactions when the XAResource
commit lifecycle is invoked.
This is why there is the notion of transaction state is separate from the session.



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880040#3880040

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880040

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - CLIENT_ACKNOWLEDGE optimization

[<ovi...@jb...>]

Message.acknowledge() individually acknowledges each message accumulated by the session, in case that the  acknowledgment mode is CLIENT_ACKNOWLEDGE. 

It makes sense to have a special server call, acknowledgeBulk(messageID, destination, receiverID) - unless a better method name comes up- that acknowledges this specific message and ALL messages that have previously been sent to this receiver. It's more efficient, we save unecessary network calls.





View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880039#3880039

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880039

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Delegate implementation

[<ovi...@jb...>]

When implementing server delegates, we keep bumping in these "we don't handle this on the server" type of methods. 

Examples:
- ConnectionDelegate.getExceptionListener()
- ConnectionDelegate.setExceptionListener()
- SessionDelegate.delivered()
- SessionDelegate.acknowledgeSession()
- SessionDelegate.createMessage()
- SessionDelegate.createBytesMessage(), etc.

There is no reason to have noop server-side implementations for these methods. They are only useful on the client and they are fielded there. I makes sense to split each delegate interface in two parts: a client-side delegate interface that groups methods handled on the client and a server-side delegate interface, which exposes calls that must go to the server.

The dynamic proxy delegate implements both interfaces, but the corresponding server-side delegate implements only the server interface.

This is what I did for consumer: there is a ConsumerDelegate interface and (it used to be) an AcknowledgmentHandler interface. The client-side proxy implements both, while the ServerConsumerDelegate used to implement AcknowledgmentHandler.  



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880038#3880038

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880038

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Connection handles transacted messages/acknowledgments

[<ovi...@jb...>]

Tim,

The latest patch (http://jira.jboss.com/jira/browse/JBMESSAGING-58) is making the ConnectionDelegate responsible with transacted message/acknowledgment delivery to the server, on behalf of its sessions. The method in question is sendTransaction().

Why did you choose to involve the connection in this, at all? A JMS transaction is always localized at session level. A session could keep its own transacted messages and acknowledgments in a decentralized manner and avoid concurrent access to a shared resource, which is the ResourceManager's transaction map.

We could probably even think to a way to keep transacted messages per-producer and transacted acknowledgments per-cosumer, and have Session to just initiate the commit/rollback.

On the server-side, the ServerConnectionDelegate handles the transaction (sendTransaction()) by sending messages to their destinations (sendMessage()) or acknowledging messages (acknowledge()). I don't think these methods belong here. Sending transacted messages/acknowledgments would be more naturally a job for the ServerSessionDelegate, or even for ServerProducerDelegate/ServerConsumerDelegate.

I could see the reason JBossMQ does that: because only the connection has access to the ServerIL, which physically sends stuff to the server. The current implementation uses the InvokerInterceptor, which is PER_VM, so it doesn't matter which delegate makes the server invocation.



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880037#3880037

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880037

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Requirements - Top level build - versioning

[<ad...@jb...>]

Anyway, the need for "LATEST" which was to reproduce the "bleeding edge" cvs
notion for binary checkouts, isn't as strong now that cvs is no longer a bottleneck.

I still think it is a useful notion to track projects through the integration process.
But this is something for the future.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880034#3880034

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880034

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Requirements - Top level build - versioning

[<ad...@jb...>]

"sco...@jb..." wrote : 
  | So the term latest is quite ambiguous, and from this perspective at least LATEST-INTEGRATED is project specific. The others are useful snapshots of a given project cvs tree.
  | 

Yes obviously, you would need this per top level build that integrates the project
and per branch of that top level build.

anonymous wrote : 
  | If LATEST-INTEGRATED were a measure of compatibility with a reference project such as jbossas I suppose it has some value for other projects that need to integrate in jbossas. Otherwise, I don't know what it means.
  | [/quote
  | 
  | Wouldn't this be LATEST-INTEGRATED-JEMS?
  | i.e. this is the "lowest common denominator" version that works with everything.
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880033#3880033

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880033

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Requirements - Top level build - versioning

[<sco...@jb...>]

anonymous wrote : 
  | We were talking in the past about having different notions of LATEST
  | 
  | e.g.
  | LATEST-BLEEDING-EDGE: The head from cvs (source checkout only)
  | LATEST-COMPILED (cruisecontrol was able to compile it)
  | LATEST-TESTED (all unit tests pass)
  | LATEST-INTEGRATED (unit tests and integration tests pass) 
  | 

So the term latest is quite ambiguous, and from this perspective at least LATEST-INTEGRATED is project specific. The others are useful snapshots of a given project cvs tree.

If LATEST-INTEGRATED were a measure of compatibility with a reference project such as jbossas I suppose it has some value for other projects that need to integrate in jbossas. Otherwise, I don't know what it means.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880031#3880031

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880031

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Requirements - Top level build - versioning

[<sco...@jb...>]

anonymous wrote : 
  | So would the version-info.xml record the "LATEST" notion?
  | And also recorded the "tested with" notion?
  | 
Yes, that is what I am thinking.

The latest notion is not a function of project or branch. A given project wants to qualify the meaning of latest such as latest in the log4j 1.2.? series. Top level builds do not combine, so there can be no conflict in which latest is in effect.

There can be a conflict if portal switches its latest view, and also becomes incompatible with previous versions of log4j.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880030#3880030

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880030

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Requirements - Top level build - versioning

[<ad...@jb...>]

"rya...@jb..." wrote : Doesn't the notion of LATEST vary by project and by branch?  IE, just because jboss-portal upgrades to log4j 10.2 doesn't mean that every other component or project in the universe is ready to.

I would say the opposite, but it depends what you mean by LATEST.

If Bela is going to release a new jgroups, Bill a new aop, etc.
we would want to test this before release for integration issues, then use
it once tested. "LATEST-INTEGERATED"

But we don't want to be doing this while Bela/Bill are developing with changes
that might break their head "LATEST-BLEEDING-EDGE", otherwise
nobody will be able to get any work done :-).

Anyway, I think you are correct that we need to stay with something close
to what we know and introduce changes in incremental steps. Otherwise when
it breaks, we won't know which change in the process is the problem. :-)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880029#3880029

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880029

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Requirements - Top level build - versioning

[<rya...@jb...>]

Doesn't the notion of LATEST vary by project and by branch?  IE, just because jboss-portal upgrades to log4j 10.2 doesn't mean that every other component or project in the universe is ready to.

We should combine the materialize and pegging features.

Pegging the versions in the toplevel build reproduces the current behavior/expectations of storing libraries in CVS.  

Using the materialize target to generate/validate the pegged versions improves communication around versioning issues without creating total confusion as to which version of a component is being used in a developer's build.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880023#3880023

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880023

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: OnDemand + another animals

[<ad...@jb...>]

The management advice (I think you mean advice/interceptor by aspect?)
would need to introduce the additional JMX operations

  | target.setControllerState(mode) -> controller.change(context, state)
  | target.setControllerMode(mode) -> context.setMode(mode)
  | 

Just like ServiceMBeanSupport does now with the redirect through the
ServiceController.
Otherwise, you can always manage contexts through the controller directly.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880000#3880000

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880000

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Requirements - Top level build - versioning

[<ad...@jb...>]

So would the version-info.xml record the "LATEST" notion?
And also recorded the "tested with" notion?

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879997#3879997

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879997

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Requirements - Top level build - versioning

[<ad...@jb...>]

You would of course only be able to do check-ins if you have the
LATEST-BLEEDING-EDGE

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879996#3879996

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879996

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: getting the SQL out of PreparedStatement

[drakonis <nu...@jb...>]

Something like this?:

public class sqlPreparedStatement implements PreparedStatement {
		PreparedStatement st;
		SQLString SQLstr;
		public sqlPreparedStatement(PreparedStatement st) {
			this.st=st;
                  }
		public setString(int par, String str) {
			//do the wright work on the string
                      ...
                      st.setString(par,str);
		}
                  ........
                  .......
}

and in the interceptor:

            return new sqlPreparedStatement((PreparedStatement)invocation.invokeNext());

well that would be a great idea. If I understood it corectly i could say the solution is simplisticaly beautiful.

PS: 10x again Bill, just wondering how the hell do u get the time to answer on the forum when i've seen articles on aop,interviews on theserverside, the aop panel(that AspectJ IBM guy was boring:) ), heard u on ejb 3.0 tutorials on jboss, developing JBossAop, jessus u shouldn;t be answering the forum(although not many other people seem to be answering).

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879995#3879995

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879995

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Requirements - Top level build - versioning

[<ad...@jb...>]

We were talking in the past about having different notions of LATEST

e.g.
LATEST-BLEEDING-EDGE: The head from cvs (source checkout only)
LATEST-COMPILED (cruisecontrol was able to compile it)
LATEST-TESTED (all unit tests pass)
LATEST-INTEGRATED (unit tests and integration tests pass)

I even suggested that the compiled/tested be moving tags within CVS.

Currently with CVS we only have the bleeding edge. :-)

I think most developers would prefer to work at LATEST-INTEGRATED
on projects they are not currently developing.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879994#3879994

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879994

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Requirements - Top level build - versioning

[<sco...@jb...>]

By top-level I meant the top of a given component version, not across all components in the repository:


  | repository.jboss.com/
  |                               hibernate/
  |                               version-info.xml
  |                               3.0.5/
  |                                      component-info.xml
  |                                      lib
  | ...
  | 


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879993#3879993

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879993

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: OnDemand + another animals

[<sco...@jb...>]

Got it. The question was concerning the existence of the pure jmx mbean in relation to the ServiceContext integration, as well as the desire to expose a management aspect for a BeanMetaData.

With a fixed state model with explicit methods, these methods are the join points for the introduction of adding the management aspect. With a pluggable state model, where is this defined?


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879992#3879992

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879992

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Requirements - Top level build - versioning

[<sco...@jb...>]

Ok. The LATEST notion is still too vauge. It is currently restricted due to the fact that there is a banch that tends to limit when new binaries are added. When opened  up to a full repository with arbitrary versions, LATEST does not make sense to me.

A qualified notion of latest in a given series would make more sense. In terms of identifying such a version, it seems that there is a need for a top level respository descriptor which expresses the compatibility info.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879991#3879991

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879991

[Jboss-dev-forums] [Design of JBoss Portal] - Sample Portlets and Themes

[<roy...@jb...>]

I have finished updating the portlet samples in the wiki, and also added sample themes/layouts. You can check them out here: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossPortalSamples

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879989#3879989

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879989