From do-not-reply at jboss.com  Mon Jan  1 02:04:53 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Mon, 1 Jan 2007 02:04:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] -
	Update AOPTestDelegate to better integrate into eclipse
Message-ID: <654045.1167635093379.JavaMail.jboss@colo-br-02.atl.jboss.com>

Currently you cannot run the tests easily from within eclise using the run as junit... capability because the test harness does not locate the jboss-aop.xml based on the classpath. Something like this does this:


  | package org.jboss.test.aop;
  | 
  | import java.net.URL;
  | import java.util.Properties;
  | 
  | import org.jboss.aop.AspectXmlLoader;
  | import org.jboss.test.AbstractTestDelegate;
  | 
  | /**
  |  * 
  |  * @author <a href="kabir.khan at jboss.com">Kabir Khan</a>
  |  * @version $Revision: 45977 $
  |  */
  | public class AOPTestDelegate extends AbstractTestDelegate
  | {
  |    /** The AOP URL used */
  |    private URL aopURL;
  |    
  |    Properties systemProps;
  | 
  |    public AOPTestDelegate(Class clazz)
  |    {
  |       // FIXME AOPTestDelegate constructor
  |       super(clazz);
  |       systemProps = (Properties)System.getProperties().clone();
  |    }
  | 
  |    public Properties getSystemProperties()
  |    {
  |       return systemProps;
  |    }
  | 
  |    /**
  |     * Look for a test specific aop descriptor based on the ctor
  |     * class first, and if none is found, the ManagedTest.class.
  |     */
  |    public void setUp() throws Exception
  |    {
  |       super.setUp();
  |       deployAOP(clazz);
  |    }
  | 
  |    /**
  |     * Undeployment any test specific aop descriptor deployed in setUp.
  |     */
  |    public void tearDown() throws Exception
  |    {
  |       super.tearDown();
  |       undeployAOP();
  |    }
  | 
  |    /**
  |     * Look for a test specific resource name by appending "-aop.xml"
  |     * to the referenceClass name as a resource. For example, a.b.SomeTest
  |     * would produce a a/b/SomeTest-aop.xml resource that is queried
  |     * for using clazz.getClassLoader().getResource("a/b/SomeTest-aop.xml");
  |     *  
  |     * @param referenceClass - the class to use as the aop descriptor base name.
  |     * @return true if the aop descriptor was found and deployed,
  |     *    false otherwise.
  |     * @throws Exception on failure to deploy the aop descriptor.
  |     */
  |    protected boolean deployAOP(Class referenceClass) throws Exception
  |    {
  |       String testName = referenceClass.getName();
  |       String pkg = referenceClass.getPackage().getName();
  |       int dot = pkg.lastIndexOf('.');
  |       if( dot > 0 )
  |          pkg = pkg.substring(dot+1);
  |       testName = pkg + "/jboss-aop.xml";
  |       URL url = clazz.getClassLoader().getResource(testName);
  |       if (url != null)
  |       {
  |          log.debug("Deploying " + url);
  |          aopURL = url;
  |          try
  |          {
  |             AspectXmlLoader.deployXML(aopURL);
  |          }
  |          catch (Throwable t)
  |          {
  |             throw new RuntimeException("Error deploying: " + url, t);
  |          }
  |          return true;
  |       }
  |       else
  |       {
  |          log.debug("No test specific deployment " + testName);
  |          return false;
  |       }
  |    }
  | 
  |    /**
  |     * Undeploy the aop descriptor deployed in deployAOP if
  |     * one was found.
  |     *
  |     */
  |    protected void undeployAOP()
  |    {
  |       if (aopURL == null)
  |          return;
  |       try
  |       {
  |          log.debug("Undeploying " + aopURL);
  |          AspectXmlLoader.undeployXML(aopURL);
  |       }
  |       catch (Exception e)
  |       {
  |          log.warn("Ignored error undeploying " + aopURL, e);
  |       }
  |    }
  | 
  | }
  | 

Although this does deploy the aspects, the test I tried this with (org.jboss.test.aop.precedence.PrecedenceTester) is still failing. Can you look into getting this working Kabir?


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

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


From do-not-reply at jboss.com  Mon Jan  1 06:08:21 2007
From: do-not-reply at jboss.com (alesj)
Date: Mon, 1 Jan 2007 06:08:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: OSGi
	integration
Message-ID: <22864714.1167649701263.JavaMail.jboss@colo-br-02.atl.jboss.com>

"scott.stark at jboss.org" wrote : Its not clear that this is the right thing to do as mapping osgi onto spring on top of the mc is not what we want. What we want is a mapping of the osgi concepts onto the mc metdata/wiring of the beans with help from supporting osgi interface implementations. 
  | 
I wouldn't go over Spring to map it to MC.
I ment that we can go in the same impl direction - core + starter (extender) bundle. But definitely with our metadata/wiring.

"scott.stark at jboss.org" wrote : 
  | The starting point should be usecases decribing what we mean by support for osgi. 
I would support similar things as the Spring spec (+ joined work of OSGi EG members) supports - as I went over that, I saw no problems that we might have with implementing this on top of MC.
That is a simple introduction of additional OSGi based XML (annotation) definition - OSGi service, reference, ... - but wired with existing MC beans.

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

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


From do-not-reply at jboss.com  Mon Jan  1 17:47:54 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Mon, 1 Jan 2007 17:47:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Parse jar to detect
	ejb3 beans
Message-ID: <3463303.1167691674253.JavaMail.jboss@colo-br-02.atl.jboss.com>

I wouldn't suggest doing it this way....

What you should do is have your JACC deployer come after the EJB3 deployers and look for:


  | 
  |    public void deploy(DeploymentUnit unit) throws DeploymentException
  |    {
  |       Ejb3Deployment deployment = unit.getAttachment(Ejb3Deployment.class);
  |       if (deployment == null) return; // there is no EJB3 deployment in this file
  | 


Scanning is time consuming.  We don't want 50 deployers doing scanning.






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

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


From do-not-reply at jboss.com  Mon Jan  1 22:05:02 2007
From: do-not-reply at jboss.com (anil.saldhana@jboss.com)
Date: Mon, 1 Jan 2007 22:05:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Parse jar to detect
	ejb3 beans
Message-ID: <5119596.1167707102684.JavaMail.jboss@colo-br-02.atl.jboss.com>

As long as I am able to register the policy configuration for the EJB3 deployment before getting active, it should be fine.

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

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


From do-not-reply at jboss.com  Tue Jan  2 04:05:36 2007
From: do-not-reply at jboss.com (mahendra_kutare)
Date: Tue, 2 Jan 2007 04:05:36 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Internal Benchmarking] - Re:
	JBoss 4.0.4 + MySQL 5.0.17c Pro + SpecJ2004
Message-ID: <26438180.1167728736260.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have also encountered the similar program and somewhere in the jboss code it checks whether its a single phase or two phase commit and if its two phase commit then it set some STATUS on prepare and commit. 

I believe may be the reason for this is JBOSS is not able to handle the 2PC due to -

a) MySQL version of j-connector which do not support 2PC. Anything earlier than 5.0 would not be have 2PC commit capabilities.

I will be performing tests runs to cross check if this is the case. If anyone has any other view or explaination of this error, please let me know.

- Mahendra

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

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


From do-not-reply at jboss.com  Tue Jan  2 05:51:54 2007
From: do-not-reply at jboss.com (wolfc)
Date: Tue, 2 Jan 2007 05:51:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Component Proposal -
	Configurable Service Locator
Message-ID: <16049381.1167735114750.JavaMail.jboss@colo-br-02.atl.jboss.com>

Please take a look at: http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/injection/

I'm rewriting the injection framework there.

Note that the JavaEE 5 client specifications already solve most of the problems you describe. With the new clients you can do: @EJB MySession session; to get a reference without JNDI calls. I don't know about the caching part. It's easier to have every injection do a JNDI call, then try to differentiate which calls won't create a new object and which calls do. The usual client application will most likely cache SLSB references anyway.

A public ServiceLocater might be nice to get references to EJB's based on interface.

With the last item you mean: having the client use services located on difference hosts? That would be cool. It's in violation with JavaEE 5 spec though so we need to clearly separate it from a regular JavaEE 5 client.

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

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


From do-not-reply at jboss.com  Tue Jan  2 05:57:21 2007
From: do-not-reply at jboss.com (wolfc)
Date: Tue, 2 Jan 2007 05:57:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Parse jar to detect
	ejb3 beans
Message-ID: <16309762.1167735441231.JavaMail.jboss@colo-br-02.atl.jboss.com>

With the EJB3 deployer rewrite you should fit snuggly in between the annation scanner deployer and the component deployer.

Something like:
- EJB3ParsingDeployer
- EJB3JBossParsingDeployer
- EJB3ScanningDeployer (after class loader)
- JACCDeployer
- EJB3Deployer

http://jira.jboss.com/jira/browse/EJBTHREE-811

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

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


From do-not-reply at jboss.com  Tue Jan  2 06:33:38 2007
From: do-not-reply at jboss.com (koen.aers@jboss.com)
Date: Tue, 2 Jan 2007 06:33:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <12168151.1167737618805.JavaMail.jboss@colo-br-02.atl.jboss.com>

We have fixed the FileDefinition class so that it does not throw an error when looking for a file that does not exist. This solved part of the stack trace problem when using the webapp with a processdefinition without a forms.xml file. 
A related problem remains however. This is when the webapp is used with a processdefinition with tasks for which there is no assiciated taskform. In this case the webapp should not try to render an unexisting form to show the task information. 
We will nevertheless proceed with the beta1 release.

Regards,
Koen 

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

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


From do-not-reply at jboss.com  Tue Jan  2 07:12:10 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Tue, 2 Jan 2007 07:12:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	Array interception needed for jboss cache
Message-ID: <16189215.1167739930163.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have added the ability to have different advice chains when reading and writing arrays. The following snippet from the tests should explain it

  |    <arraybind type="READ_WRITE">
  |    	<advice aspect="org.jboss.test.aop.array.AspectForPrecedence" name="advice"/>
  |    	<interceptor-ref name="org.jboss.test.aop.array.TestArrayElementInterceptor"/>
  |    </arraybind>
  |    <arraybind type="READ_ONLY">
  | 	   <interceptor-ref name="org.jboss.test.aop.array.TestArrayElementReadInterceptor"/>
  |    </arraybind>
  |    <arraybind type="WRITE_ONLY">
  | 	   <interceptor-ref name="org.jboss.test.aop.array.TestArrayElementWriteInterceptor"/>
  |    </arraybind>
  | 

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

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


From do-not-reply at jboss.com  Tue Jan  2 08:29:31 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Tue, 2 Jan 2007 08:29:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	Update AOPTestDelegate to better integrate into eclipse
Message-ID: <3452211.1167744571152.JavaMail.jboss@colo-br-02.atl.jboss.com>

To set  up for debug, you need to 
1) set the jboss.aop.path system property to point to the jboss-aop.xml file
2) set -javaagent:%OUTPUT_LIB_FOLDER%\jboss-aop-jdk50.jar

While the requirement for 1) could be optimized out by the mechanism you describe, it means rewriting all the tests since things like field, constructor and array interception need weaving of the testcase class, which in turn depends on the aop.xml file being deployed before the testcase class is loaded.

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

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


From do-not-reply at jboss.com  Tue Jan  2 09:53:05 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Tue, 2 Jan 2007 09:53:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <32841813.1167749585373.JavaMail.jboss@colo-br-02.atl.jboss.com>

"koen.aers at jboss.com" wrote : A related problem remains however. This is when the webapp is used with a processdefinition with tasks for which there is no assiciated taskform. In this case the webapp should not try to render an unexisting form to show the task information.

Is there a reliable way to tell whether a file exists within a FileDefinition, short of catching the exception?

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

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


From do-not-reply at jboss.com  Tue Jan  2 10:03:38 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Tue, 2 Jan 2007 10:03:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <8252529.1167750218726.JavaMail.jboss@colo-br-02.atl.jboss.com>

"david.lloyd at jboss.com" wrote : Is there a reliable way to tell whether a file exists within a FileDefinition, short of catching the exception?

...and if not, can we add one?  e.g. fileDefinition.containsFile(file) or something like that?

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

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


From do-not-reply at jboss.com  Tue Jan  2 10:50:09 2007
From: do-not-reply at jboss.com (ravishbhupesh)
Date: Tue, 2 Jan 2007 10:50:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: unable to resolve
	beanClass method from remote proxy cal
Message-ID: <4515983.1167753009997.JavaMail.jboss@colo-br-02.atl.jboss.com>

hey I also got the same problem. actually I tried on 3-4 systems. on some the application is working fine but on 2-3 systems it is giving same error... if anybody got some sol. plz do reply....

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

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


From do-not-reply at jboss.com  Tue Jan  2 10:55:49 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Tue, 2 Jan 2007 10:55:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover refactoring
Message-ID: <22180057.1167753349887.JavaMail.jboss@colo-br-02.atl.jboss.com>

Why did you remove testSimpleFailover from FailoverTest?

This test killed the server, and performed an invocation while the server is dead. Something would intercept an exception from the communication layer and activate failover from that exception.

I reactivated the test on my local copy, and the test is fails.


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

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


From do-not-reply at jboss.com  Tue Jan  2 10:55:52 2007
From: do-not-reply at jboss.com (tom.elrod@jboss.com)
Date: Tue, 2 Jan 2007 10:55:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Re: JSR-160 support
Message-ID: <9665103.1167753352641.JavaMail.jboss@colo-br-02.atl.jboss.com>

Probably not.  There were only two initial reasons for JSR-160 implementation:

1. JDK 1.4 did not have it built in, so would need to drop in an implementation.
2. Performance could potentially be better with custom implementation.

Since are so far behind on JBoss implementation, don't know that 1 applies anymore (since JBoss 5 will be jdk 1.5, which has JSR-160 built in).  As for 2, don't know how good/bad Sun's implementation is in regards to performance.  Since remote jmx calls is not part of core JBoss infrastructure, may not really be an issue (where as jboss jmx microkernel was dependent upon jmx, rolling our own implementation made sense for performance reasons).

I personally don't care either way, just don't have the time/resources to devote to it at the moment (and don't know when I would as has always been a low priority). 

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

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


From do-not-reply at jboss.com  Tue Jan  2 11:03:32 2007
From: do-not-reply at jboss.com (tom.elrod@jboss.com)
Date: Tue, 2 Jan 2007 11:03:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Re: JSR-160 support
Message-ID: <30313581.1167753812188.JavaMail.jboss@colo-br-02.atl.jboss.com>

jmx-remoting.sar is already included in HEAD and would use the JDK 1.5 JSR-160 implementation by default.  Could also include this for JBoss 4.2 if desired.  At that point, is only a question of performance (assuming JDK 1.5 or higher is required for JBossAS 4.2+)

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

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


From do-not-reply at jboss.com  Tue Jan  2 12:59:50 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Tue, 2 Jan 2007 12:59:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Problem deploying a
	-beans.xml in a SAR
Message-ID: <14891001.1167760790913.JavaMail.jboss@colo-br-02.atl.jboss.com>

There are problems deploying the tc6 clustering cache on trunk.  It's deployed  via a -beans.xml nested in an expanded .sar. I get errors deploying some of the nested beans in the config as follows; which bean fails seems to vary.

2006-12-31 17:28:44,527 ERROR [org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer] Error during deployment: jboss:id=tc6-cluster.sar,service=jacc
  | org.jboss.deployers.spi.DeploymentException: Error deploying: TomcatClusteringBuddyLocatorConfig
  | 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
  | 	at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:71)
  | 	at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42)
  | 	at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:53)
  | 	at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52)
  | 	at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:145)
  | 	at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:440)
  | 	at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:451)
  | 	at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:451)
  | 	at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:381)
  | 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:366)
  | 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:246)
  | 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
  | 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
  | 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
  | 	at org.jboss.Main.boot(Main.java:210)
  | 	at org.jboss.Main$1.run(Main.java:508)
  | 	at java.lang.Thread.run()V(Unknown Source)
  | Caused by: java.lang.IllegalStateException: TomcatClusteringBuddyLocatorConfig is already installed.
  | 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:249)
  | 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:177)
  | 	at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:67)
  | 	... 16 more

This may be an odd case due to funky packaging.  The sar looks like this:

tc6-cluster.sar
-- META-INF
-- -- tc6-cluster-beans.xml
-- tc6-cluster.aop

That packaging is a bit of a 4.x legacy and doesn't need to be that way; using a simple directory to logically group the two files is fine, even better:

tc6-cluster
-- tc6-cluster-beans.xml
-- tc6-cluster.aop

When I shift to this packaging, it seems to deploy without issue.  But, the other packaging was working with the Beta1 release, so I want to mention it in case this is a sign of something more fundamental being broken.

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

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


From do-not-reply at jboss.com  Tue Jan  2 13:15:27 2007
From: do-not-reply at jboss.com (ryan.campbell@jboss.com)
Date: Tue, 2 Jan 2007 13:15:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	Code Coverage in JBoss AS Test Suite
Message-ID: <10191675.1167761727371.JavaMail.jboss@colo-br-02.atl.jboss.com>

Manik,

Where should we document this test case?  A readme in the src/etc folder?  Somewhere else?

Thanks,
Ryan

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

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


From do-not-reply at jboss.com  Tue Jan  2 13:28:03 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Tue, 2 Jan 2007 13:28:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss ESB] - Re: JMS Provider(s)
	Design - JBossMQ/JBossMessaging/ActiveMQ
Message-ID: <32127122.1167762483942.JavaMail.jboss@colo-br-02.atl.jboss.com>

I built jbossesb from trunk and deployed sar to jboss-4.0.5.GA along with esb configuration files and war. I am getting an exception when I start the server

org.jboss.soa.esb.listeners.message.EsbListenerControllerFactory$EsbListenerControllerImpl] Cannot launch <org.jboss.soa.esb.listeners.message.MessageAwareListener>

java.lang.NoSuchMethodException: org.jboss.soa.esb.listeners.message.MessageAwareListener.(org.jboss.soa.esb.listeners.message.EsbListenerController, org.jboss.soa.esb.helpers.ConfigTree)
	at java.lang.Class.getConstructor0(Class.java:2647)
	at java.lang.Class.getConstructor(Class.java:1629)
	at org.jboss.soa.esb.listeners.message.EsbListenerControllerFactory$EsbListenerControllerImpl.tryToLaunchChildListener(EsbListenerControllerFactory.java:394)
	at org.jboss.soa.esb.listeners.message.EsbListenerControllerFactory$EsbListenerControllerImpl.run(EsbListenerControllerFactory.java:346)
	at java.lang.Thread.run(Thread.java:595)
2007-01-02 11:04:25,640 ERROR [org.jboss.soa.esb.listeners.message.EsbListenerControllerFactory$EsbListenerControllerImpl] Cannot launch <org.jboss.soa.esb.listeners.message.MessageAwareListener>

java.lang.NoSuchMethodException: org.jboss.soa.esb.listeners.message.MessageAwareListener.(org.jboss.soa.esb.listeners.message.EsbListenerController, org.jboss.soa.esb.helpers.ConfigTree)
	at java.lang.Class.getConstructor0(Class.java:2647)
	at java.lang.Class.getConstructor(Class.java:1629)
	at org.jboss.soa.esb.listeners.message.EsbListenerControllerFactory$EsbListenerControllerImpl.tryToLaunchChildListener(EsbListenerControllerFactory.java:394)
	at org.jboss.soa.esb.listeners.message.EsbListenerControllerFactory$EsbListenerControllerImpl.run(EsbListenerControllerFactory.java:346)
	at java.lang.Thread.run(Thread.java:595)
2007-01-02 11:04:25,656 DEBUG [org.jboss.soa.esb.listeners.message.EsbListenerControllerFactory$EsbListenerControllerImpl] About to sleep 49969
2007-01-02 11:04:25,734 INFO  [org.jboss.soa.esb.listeners.State] Listener component [org.jboss.soa.esb.listeners.message.EsbListenerControllerFactory$EsbListenerControllerImpl] is now in a state of 'Ready'.
2007-01-02 11:04:25,734 DEBUG [org.jboss.soa.esb.listeners.message.EsbListenerControllerService] Started jboss.org:service=EsbListenerController
2007-01-02 11:04:25,734 DEBUG [org.jboss.system.ServiceController] Starting dependent components for: jboss.org:service=EsbListenerController dependent components: []
2007-01-02 11:04:25,734 DEBUG [org.jboss.system.ServiceController] starting service jboss.org:service=GatewayListenerController
2007-01-02 11:04:25,734 DEBUG [org.jboss.soa.esb.listeners.gateway.GatewayListenerControllerService] Starting jboss.org:service=GatewayListenerController
2007-01-02 11:04:25,734 INFO  [org.jboss.soa.esb.listeners.gateway.GatewayListenerControllerService] starting message aware listener with config file jbossesb-gateway.xml
2007-01-02 11:04:25,734 INFO  [org.jboss.soa.esb.listeners.gateway.GatewayListenerController] No value specified for: endTime - Listener will run until parent container/process terminates.
2007-01-02 11:04:25,750 DEBUG [org.jboss.soa.esb.listeners.gateway.GatewayListenerControllerService] Started jboss.org:service=GatewayListenerController
2007-01-02 11:04:25,750 DEBUG [org.jboss.system.ServiceController] Starting dependent components for: jboss.org:service=GatewayListenerController dependent components: []
2007-01-02 11:04:25,750 DEBUG [org.jboss.system.ServiceController] starting service jboss.jca:service=DataSourceBinding,name=JBossESBDS
2007-01-02 11:04:25,750 DEBUG [org.jboss.system.ServiceController] Ignoring start request for service: jboss.jca:service=DataSourceBinding,name=JBossESBDS
2007-01-02 11:04:25,750 DEBUG [org.jboss.system.ServiceController] starting service jboss.jdbc:service=metadata,datasource=JBossESBDS
2007-01-02 11:04:25,750 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.metadata.DataSourceMetaData] Starting jboss.jdbc:service=metadata,datasource=JBossESBDS
2007-01-02 11:04:25,750 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.metadata.DataSourceMetaData] Started jboss.jdbc:service=metadata,datasource=JBossESBDS
2007-01-02 11:04:25,750 DEBUG [org.jboss.system.ServiceController] Starting dependent components for: jboss.jdbc:service=metadata,datasource=JBossESBDS dependent components: []
2007-01-02 11:04:25,750 DEBUG [org.jboss.system.ServiceController] starting 




Also getting:

2007-01-02 11:04:34,750 INFO  [org.apache.juddi.registry.local.Registry] Loading jUDDI configuration.
2007-01-02 11:04:34,750 INFO  [org.apache.juddi.registry.local.Registry] Resources loaded from: /C:/jboss-ps-0.1/jboss-4.0.5.GA/server/ps/conf/juddi.properties
2007-01-02 11:04:34,750 INFO  [org.apache.juddi.registry.local.Registry] Initializing jUDDI components.
2007-01-02 11:04:34,750 INFO  [org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl] Service name: trailblazer-jmsbank:jmsbankreplies
2007-01-02 11:04:34,750 INFO  [org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl] Description: null
2007-01-02 11:04:34,750 INFO  [org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl] Key id: 8A386AE0-909D-11DB-AAE0-C8137B127B1B
2007-01-02 11:04:34,781 ERROR [STDERR] Exception in thread "Thread-36" 
2007-01-02 11:04:34,781 ERROR [STDERR] java.lang.LinkageError: loader constraints violated when linking org/w3c/dom/Document class
2007-01-02 11:04:34,781 ERROR [STDERR] 	at org.jboss.internal.soa.esb.addressing.helpers.EPRHelper.toXMLString(EPRHelper.java:151)
2007-01-02 11:04:34,781 ERROR [STDERR] 	at org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl.registerEPR(JAXRRegistryImpl.java:185)
2007-01-02 11:04:34,781 ERROR [STDERR] 	at org.jboss.soa.esb.listeners.gateway.GatewayListenerController.register(GatewayListenerController.java:644)
2007-01-02 11:04:34,781 ERROR [STDERR] 	at org.jboss.soa.esb.listeners.gateway.JmsGatewayListener.run(JmsGatewayListener.java:75)
2007-01-02 11:04:34,781 ERROR [STDERR] 	at java.lang.Thread.run(Thread.java:595)



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

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


From do-not-reply at jboss.com  Tue Jan  2 13:29:16 2007
From: do-not-reply at jboss.com (pavel.tsekov@redhat.com)
Date: Tue, 2 Jan 2007 13:29:16 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	Code Coverage in JBoss AS Test Suite
Message-ID: <18886213.1167762556302.JavaMail.jboss@colo-br-02.atl.jboss.com>

Posted to the wrong forum thread ?

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

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


From do-not-reply at jboss.com  Tue Jan  2 13:36:52 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 2 Jan 2007 13:36:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Problem deploying
	a -beans.xml in a SAR
Message-ID: <23233288.1167763012450.JavaMail.jboss@colo-br-02.atl.jboss.com>

I see the error and will look at it.


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

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


From do-not-reply at jboss.com  Tue Jan  2 13:41:06 2007
From: do-not-reply at jboss.com (dimitris@jboss.org)
Date: Tue, 2 Jan 2007 13:41:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] -
	DeployerInterceptorEJB3 depends on jboss.ejb3:service=EJB3De
Message-ID: <31326411.1167763266753.JavaMail.jboss@colo-br-02.atl.jboss.com>

The latest refactoring on Branch_4_2 that replaced jbossws14.sar with jbossws.sar expects the EJB3Deployer to be present. 

EJB3 is still an optional component in JBossAS, so although we now require jdk5, we may not have EJB3 present. 

We need to include a jboss-service.xml descriptor that doesn't have this dependency, in the standard (no EJB3) jbossAS config.

http://jira.jboss.com/jira/browse/JBAS-3964

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

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


From do-not-reply at jboss.com  Tue Jan  2 13:50:10 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Tue, 2 Jan 2007 13:50:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss ESB] - Re: JMS Provider(s)
	Design - JBossMQ/JBossMessaging/ActiveMQ
Message-ID: <22591621.1167763810862.JavaMail.jboss@colo-br-02.atl.jboss.com>

I removed xml-apis-1.3.02.jar and xercesImpl-2.7.1 from the jbossesb.sar and the second exception appears to have gone away. There are versions of these jars in jboss-4.0.5/lib/endorsed (xalan.jar is in lib and the sar as ell). 

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

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


From do-not-reply at jboss.com  Tue Jan  2 14:03:38 2007
From: do-not-reply at jboss.com (ryan.campbell@jboss.com)
Date: Tue, 2 Jan 2007 14:03:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	Code Coverage in JBoss AS Test Suite
Message-ID: <32471540.1167764618450.JavaMail.jboss@colo-br-02.atl.jboss.com>

Oops, you are right, sorry.  Will delete the bad postings.

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

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


From do-not-reply at jboss.com  Tue Jan  2 14:04:46 2007
From: do-not-reply at jboss.com (ryan.campbell@jboss.com)
Date: Tue, 2 Jan 2007 14:04:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Serialization
	Compatibility Tests
Message-ID: <19280211.1167764686200.JavaMail.jboss@colo-br-02.atl.jboss.com>

Manik,

Where should we document this test case? A readme in the src/etc folder? Somewhere else?

Thanks,
Ryan

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

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


From do-not-reply at jboss.com  Tue Jan  2 14:08:20 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 2 Jan 2007 14:08:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Problem deploying
	a -beans.xml in a SAR
Message-ID: <19016328.1167764900235.JavaMail.jboss@colo-br-02.atl.jboss.com>

This is a problem with the beans created by the SecurityDeployer. It is not being selective enough about what contexts its processing.


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

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


From do-not-reply at jboss.com  Tue Jan  2 14:17:21 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 2 Jan 2007 14:17:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Security on JBoss] - Re:
	SecurityContext
Message-ID: <3552438.1167765441915.JavaMail.jboss@colo-br-02.atl.jboss.com>

This has to be part of the client proxy interceptor stack. Today there is only the SecurityInterceptor that accesses the SecurityAssociation. The interceptor stack associated with a proxy needs to include whatever security aspects are needed based on the security metadata. One way would be to include several different security interceptors in the proper order so that the aggregate security context of the call is correct. Some interceptors may do nothing if there already is a security context associated with the call while others may augment it.


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

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


From do-not-reply at jboss.com  Tue Jan  2 14:28:56 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 2 Jan 2007 14:28:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	Update AOPTestDelegate to better integrate into eclipse
Message-ID: <10364815.1167766136997.JavaMail.jboss@colo-br-02.atl.jboss.com>

Its not clear why the aop processing cannot be done before the test classes are loaded by expanding the AOPTestWithSetup/AOPTestDelegate. It should just require an aop aware class loader be installed at the proper level in the test harness. I assume this is what the javaagent is doing. 

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

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


From do-not-reply at jboss.com  Tue Jan  2 14:29:26 2007
From: do-not-reply at jboss.com (dimitris@jboss.org)
Date: Tue, 2 Jan 2007 14:29:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - New jboss
	version info attributes
Message-ID: <19380533.1167766166067.JavaMail.jboss@colo-br-02.atl.jboss.com>

Just saw 4 new attributed added to jboss.system:type=ServerConfig mbean (I'm posting here 'cause Thomas added them)

SpecificationTitle
  (JBoss)
ImplementationTitle
  (JBoss [Trinity]) and
ImplementationVersion
  (4.2.0.CR1 (build: SVNTag=JBoss_4_2_0_CR1 date=200701021921))

are either obvious or exist already in a jboss.system:type=Server mbean:

Version
   (4.2.0CR1(build: CVSTag=JBoss_4_2_0_CR1 date=200701021921))
VersionName
   (Trinity)

The only useful addition seems to be the
SpecificationVersion (4.2.0.CR1)

which again looks more appropriate to appear in jboss.system:type=Server mbean as, e.g., VersionNumber, VersionId, or similar.

Are those new attributes used somewhere?





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

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


From do-not-reply at jboss.com  Tue Jan  2 14:30:29 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 2 Jan 2007 14:30:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Security on JBoss] - SecurityDeployer
	needs to be more selective about what is pr
Message-ID: <16493770.1167766229268.JavaMail.jboss@colo-br-02.atl.jboss.com>

Starting the all configuration is producing a duplicate mbean problem as mentioned here:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3997313#3997313

The SecurityDeployer needs to be looking for some security related metadata to trigger its behavior.


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

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


From do-not-reply at jboss.com  Tue Jan  2 15:02:06 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Tue, 2 Jan 2007 15:02:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	Update AOPTestDelegate to better integrate into eclipse
Message-ID: <14209610.1167768126085.JavaMail.jboss@colo-br-02.atl.jboss.com>

The initialization of the AOPSetup/TestDelegate results from the  testcase setUp() method. Once that is called the class has already been loaded:


  | Thread [main] (Suspended (breakpoint at line 39 in AOPTestDelegate))	
  | 	AOPTestDelegate.<init>(Class) line: 39	
  | 	AOPTestWithSetup.getDelegate(Class) line: 51	
  | 	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
  | 	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
  | 	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
  | 	Method.invoke(Object, Object...) line: 585	
  | 	AbstractTestDelegate.getDelegate(Class) line: 70	
  | 	AbstractTestSetup.setUp() line: 62	
  | 	AOPArrayTestCase(AbstractTestCaseWithSetup).setUp() line: 90	
  | 	AOPArrayTestCase(TestCase).runBare() line: 125	
  | 	TestResult$1.protect() line: 106	
  | 	TestResult.runProtected(Test, Protectable) line: 124	
  | 	TestResult.run(TestCase) line: 109	
  | 	AOPArrayTestCase(TestCase).run(TestResult) line: 118	
  | 	TestSuite.runTest(Test, TestResult) line: 208	
  | 	TestSuite.run(TestResult) line: 203	
  | 	TestSuite.runTest(Test, TestResult) line: 208	
  | 	TestSuite.run(TestResult) line: 203	
  | 	JUnit3TestReference.run(TestExecution) line: 128	
  | 	TestExecution.run(ITestReference[]) line: 38	
  | 	RemoteTestRunner.runTests(String[], String, TestExecution) line: 460	
  | 	RemoteTestRunner.runTests(TestExecution) line: 673	
  | 	RemoteTestRunner.run() line: 386	
  | 	RemoteTestRunner.main(String[]) line: 196	
  | 

The classloader uses whatever -aop.xml info has been deployed in AOP to determine if the class should be woven, in other words having this deployed by the Setup/Delegate is too late.

2 possible solutions:
1) Refactor all existing xxxTestCase classes to xxxTestCaseDelegate and create new xxxTestCase classes delegating to the xxxTestCaseDelegate

2) Create a new javaagent that delegates to the exisiting transformer. This transformer should be able to leverage the existing transformer for it's work and deploy use the info about the testcase to 

1) is a pain, and 2) while conceptually straight-forward is complicated by the fact that there doesn't seem to be a way to tell which test is being run.

One option though could be to have my classloader dig into the junit stack, and weave the org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main() method so this information is available in a system property somewhere. Eclipse seems to load that class for each test run.

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

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


From do-not-reply at jboss.com  Tue Jan  2 15:27:49 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 2 Jan 2007 15:27:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <9509926.1167769669130.JavaMail.jboss@colo-br-02.atl.jboss.com>

i have updated the file definition so that a null value is returned if the file doesn't exist.

most part of the webapp is updated for this.

but the view should be redirected to the process instance view instead of the task instance view in case a process is started without a start task.

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

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


From do-not-reply at jboss.com  Tue Jan  2 15:53:49 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Tue, 2 Jan 2007 15:53:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss ESB] - Re: JMS Provider(s)
	Design - JBossMQ/JBossMessaging/ActiveMQ
Message-ID: <8913183.1167771229800.JavaMail.jboss@colo-br-02.atl.jboss.com>

As for the first exception, it appears that

MessageAwareListerner extends AbstractManagedListener and the constructor takes a org.jboss.soa.esb.listener.ListenerManager as an argument. However, from the stack trace it appears that a org.jboss.soa.esb.listener.message.ESBListenerController  is being passed, which does not implement ListenerManager.

So the messageAwareListener.getContructor(org.jboss.soa.esb.listener.ListenerManager, org.jboss.soa.esb.helper.ConfigTree) is failing.

Not clear to me the relationship between the two interfaces: ListenerManager and ESBListenerController

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

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


From do-not-reply at jboss.com  Tue Jan  2 16:00:23 2007
From: do-not-reply at jboss.com (anil.saldhana@jboss.com)
Date: Tue, 2 Jan 2007 16:00:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Problem deploying
	a -beans.xml in a SAR
Message-ID: <553350.1167771623653.JavaMail.jboss@colo-br-02.atl.jboss.com>

I will fix this.

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

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


From do-not-reply at jboss.com  Tue Jan  2 16:00:40 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Tue, 2 Jan 2007 16:00:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <2177997.1167771640637.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, no problem, that should be simple to do.  Thanks...

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

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


From do-not-reply at jboss.com  Tue Jan  2 16:29:51 2007
From: do-not-reply at jboss.com (unibrew)
Date: Tue, 2 Jan 2007 16:29:51 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: How do you a
	forum and a wiki to a jportal
Message-ID: <14773994.1167773391174.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hello

Please do not user questions on this forum  ( http://www.jboss.com/index.html?module=bb&op=viewtopic&t=75280)
You should find all needed info on: http://labs.jboss.com/portal/jbosswiki/?prjlist=false and 
http://labs.jboss.com/portal/jbossforums/?prjlist=true .

Regards
----------------------
Ryszard Kozmik
JBoss Forums
JBoss Labs Team

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

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


From do-not-reply at jboss.com  Tue Jan  2 16:52:15 2007
From: do-not-reply at jboss.com (anil.saldhana@jboss.com)
Date: Tue, 2 Jan 2007 16:52:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Security on JBoss] - Re:
	SecurityContext
Message-ID: <6366021.1167774735856.JavaMail.jboss@colo-br-02.atl.jboss.com>

Now where will the client side interceptors pick up the caller Security Context from?  I need something like the old SecurityAssociation threadlocal.

This is just a minute issue but this is where I cannot throw away the threadlocal concept. In my current prototype, I have a SecurityContextAssociation with a single threadlocal to hold the securitycontext object.  The Security Interceptor in the proxy looks at the threadlocal object to obtain the call-path security context. If it exists and it holds the invocation principal(means there is no explicit jaas login), I just send the security context over the invocation. If the invocation principal does not match with the SC on the threadlocal, it means there is an explicit jaas login - create a new SC (plug the call-path sc as its parent) and set this new SC on the threadlocal as well as sending it on the invocation. Takes care of end-to-end security.

The security context can hold the caller's security context and be passed via invocation. So we get the stack like behavior for the caller's context.



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

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


From do-not-reply at jboss.com  Tue Jan  2 17:35:24 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Tue, 2 Jan 2007 17:35:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- JBMESSAGING-578 - Multiplex JGroups Channel
Message-ID: <27317819.1167777324238.JavaMail.jboss@colo-br-02.atl.jboss.com>

This is a thread discussion on http://jira.jboss.com/jira/browse/JBMESSAGING-578.

For a call on JChannelFactory, we are supposed to send an ID identifying the system.

We could have a constant (such as JBOSS_MESSAGING) on that ID, but per my discussion with Brian Stansberry we should have the ID configured.

Briand recomended using ${jboss.partition.name:DefaultPartition}-JMS for the Application Server.

I will keep the partitionID configurable on the ClusteredPostOfficeMBean then.



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

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


From do-not-reply at jboss.com  Tue Jan  2 18:59:15 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Tue, 2 Jan 2007 18:59:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-578 - Multiplex JGroups Channel
Message-ID: <21722683.1167782355235.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have a question regarding this:

Should we aways use JGroups Multiplexor by default, or only when running under JBoss5?



I'm creating a new interface to perform JChannel creations called ChannelFactory. This interface is only used at DefaultClusteredPostOffice and its service.

Since I don't want to put everything on the same package as DefaultClusteredPostOffice, I have created a new package under postoffice.cluster, called jgroups which can be easily renamed/moved later if that's not the proper place.


I haven't committed my changes yet by the time of this post, but I will as soon as I have finished running testcases.

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

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


From do-not-reply at jboss.com  Tue Jan  2 19:32:17 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 2 Jan 2007 19:32:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Security on JBoss] - Re:
	SecurityContext
Message-ID: <3177084.1167784337469.JavaMail.jboss@colo-br-02.atl.jboss.com>

Setting the security context has to be reconcilled with the security aspect behavior. If you do an explicit jaas login, all that really results is an authenticated subject. Instead of having a ClientLoginModule push this to a thread local, it could associate this info with the mc metadata repository at a request scope. The aspect checking the security context would use the metadata repository to pickup scope starting from the request and moving up to higher levels like deployment, security domain default, etc.

Alternatively we could look at Subject.doAs*()/Subject.getSubject(AccessControlContext acc) with validation of the authentication as data in the subject private credentials to better leverage the jaas apis.


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

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


From do-not-reply at jboss.com  Tue Jan  2 23:59:28 2007
From: do-not-reply at jboss.com (ron_sigal)
Date: Tue, 2 Jan 2007 23:59:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Re: Detached invokers are
	too detached from the transport
Message-ID: <763396.1167800368328.JavaMail.jboss@colo-br-02.atl.jboss.com>

How about a generalization of HandshakeCompletedListener:


  |  interface SocketCreatedListener
  |  {
  |    void socketCreated(Socket socket);
  |  }
  | 
 
An instance of SocketCreatedListener could be passed in on the client side:


  |   SocketCreatedListener listener = ... ;
  |   HashMap config = new HashMap();
  |   config.put(Remoting.SOCKET_CREATED_LISTENER, listener);
  |   Client client = new Client(locator, config);
  | 

and on the server side:


  |   SocketCreatedListener listener = ... ;
  |   HashMap config = new HashMap();
  |   config.put(Remoting.SOCKET_CREATED_LISTENER, listener);
  |   Connector = new Connector(locator, config);
  | 

The client and server invokers would be responsible for calling the listener whenever they create a socket.  A customized SocketFactory would probably be necessary for some of the less transparent transports.

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

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


From do-not-reply at jboss.com  Wed Jan  3 02:19:20 2007
From: do-not-reply at jboss.com (bela@jboss.com)
Date: Wed, 3 Jan 2007 02:19:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	Array interception needed for jboss cache
Message-ID: <4699356.1167808760346.JavaMail.jboss@colo-br-02.atl.jboss.com>

This is cool stuff ! Ben, please see whether this covers all the requirements from the PojoCache side.

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

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


From do-not-reply at jboss.com  Wed Jan  3 03:18:54 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 3 Jan 2007 03:18:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Re: Detached invokers are
	too detached from the transport
Message-ID: <25280935.1167812334132.JavaMail.jboss@colo-br-02.atl.jboss.com>

That sounds fine.


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

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


From do-not-reply at jboss.com  Wed Jan  3 04:02:51 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Wed, 3 Jan 2007 04:02:51 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <18105989.1167814971206.JavaMail.jboss@colo-br-02.atl.jboss.com>

build for 3.2.Beta1 succeeds... but there is still a problem in the web app.  when starting a new process instance, it doesn't navigate to the form in case there is one.  so the original problem is fixed but it introduced a new problem.

david, can you have a look at this asap ?  thanks.

please, keep me posted when fixing things for an imminent release.

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

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


From do-not-reply at jboss.com  Wed Jan  3 04:05:29 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Wed, 3 Jan 2007 04:05:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <7296806.1167815129367.JavaMail.jboss@colo-br-02.atl.jboss.com>

ah... and david, it would be good if you focus on communication and keep me posted in your morning.  

then we still have a few extra cycles during our short working time overlap :-)

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

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


From do-not-reply at jboss.com  Wed Jan  3 06:49:02 2007
From: do-not-reply at jboss.com (ben.wang@jboss.com)
Date: Wed, 3 Jan 2007 06:49:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	Array interception needed for jboss cache
Message-ID: <12891720.1167824942973.JavaMail.jboss@colo-br-02.atl.jboss.com>

Kabir, I need more to work out a prototype from PojoCache side once alpha2 is out this week (or early next week).

But here are my initial questions:

1. We have discussed multi-dimensional array before. Can your prototyoe handle it now?

2. I have some reservation regarding to per-VM scope of array interception.

a) What happens when I have multiple instances in the VM. E.g., 

  | p1 = new POJO();
  | 
  | p2 = new POJO();
  | 
  | ...
  | 
  | p1.array[2] = 10;
  | 
  | p2.array[2] = 20;
  | 
can you differentiate this?

3. Since we don't distinguish the target object, what happens when I have same array field name in different POJO? E.g.,

  | class POJO_A
  | {
  |   int[] array;
  | }
  | 
and

  | class POJO_B
  | {
  |   int[] array;
  | }
  | 
Will I have a problem here?

4. With per-VM scope, we are saying this is like a static field, I think. So naturally, we can't use the "Region" concept that is in JBoss Cache. We will just need to document that.

5. Finally, upon invocation in MyArrayInterceptor, do I have access to the array reference itself, e.g., POJO.array? Can I get it from the ArrayRegistry during invocation? I need this such that I can tie the array to the internal cache store.

Thanks,

-Ben


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

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


From do-not-reply at jboss.com  Wed Jan  3 08:47:40 2007
From: do-not-reply at jboss.com (aamonten)
Date: Wed, 3 Jan 2007 08:47:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] -
	default.mf does not exist
Message-ID: <4470892.1167832060404.JavaMail.jboss@colo-br-02.atl.jboss.com>

HI I have just downloaded the latest revision (59310) of the head, following the instructions at http://www.jboss.com/wiki/Wiki.jsp?page=BuildingJBossAOPFromSubversion

my problem arise when I try to build the project, I got a build failed
  | amontenegro at loki ~/jboss-aop/build $ ./build.sh 
  | Searching for build.xml ...
  | Buildfile: /home/amontenegro/jboss-aop/build/build.xml
  | 
  | check.inhibit.downloads:
  | 
  | check.proxy:
  | 
  | set.proxy:
  | 
  | createthirdparty:
  | 
  | _buildmagic:init:
  | Trying to override old definition of task property
  | 
  | _buildmagic:init:buildlog:
  | 
  | configure:
  |      [echo] groups:  default
  |      [echo] modules: aop
  | 
  | init:
  | 
  | _buildmagic:modules:most:
  | 
  |     ======================================================================
  |     ==  Executing 'most' in module 'aop'...
  |     ==
  | 
  | _buildmagic:init:
  | 
  | configure:
  | 
  | init:
  | 
  | _buildmagic:build-bypass-checker:
  | 
  | _buildmagic:build-bypass-notice:
  | 
  | _buildmagic:build-bypass-check:
  | 
  | source-jar:
  | 
  | BUILD FAILED
  | /home/amontenegro/jboss-aop/aop/build.xml:420: Manifest file: /home/amontenegro/jboss-aop/aop/output/etc/default.mf does not exist.
  | 
  | Total time: 4 seconds
  | 
I had the same problem both at linux and windows.

So my doubt is if there are dependencies on another repository or are the documentation about building the project outdated. Any help would be appretiated.

best regards
Alejandro


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

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


From do-not-reply at jboss.com  Wed Jan  3 09:20:21 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 3 Jan 2007 09:20:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <2094836.1167834021131.JavaMail.jboss@colo-br-02.atl.jboss.com>

When the process instance starts, it navigates to the task assignment list, if there are tasks... the reason for this (which might be flawed) is that the process may contain, for example, a fork before any tasks, so there could be several tasks initially created.  Then you pick the task you are interested in and this brings you to the task instance.

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

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


From do-not-reply at jboss.com  Wed Jan  3 09:30:21 2007
From: do-not-reply at jboss.com (pavel.tsekov@redhat.com)
Date: Wed, 3 Jan 2007 09:30:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Serialization
	Compatibility Tests
Message-ID: <8820918.1167834621013.JavaMail.jboss@colo-br-02.atl.jboss.com>

"manik.surtani at jboss.com" wrote : Agreed that some exceptions may get serialised as return values, but as you pointed out, this is not in the list of errors.
  | 
  | As for other JGroups classes, those that are transported across the wire are marshalled using the TreeCacheMarshaller in 1.4.0, so this is not a problem when talking to 1.4.x.

So, if I got it right this means that it is safe to exclude all jgroups classes excepth "*Exception" when testing agains 1.4.0 GA ?

"manik.surtani at jboss.com" wrote : 
  | This does break down in one scenario though; and this is when we use region-based marshalling (JBC 1.2.x/1.3.x) which forces Java serialization on the payload, including JGroups classes.  (When not using region-based marshalling, JGroups Streamable interface is used, which does not make use of Java seriaization)

Does 1.4.x support region-based marshalling i.e. for backward compatibility with older versions i.e. is it possible to run 1.4.x with 1.3.x so that they'll exchange java serialized objects ?


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

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


From do-not-reply at jboss.com  Wed Jan  3 09:47:02 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Wed, 3 Jan 2007 09:47:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - new user guide
Message-ID: <31124874.1167835622088.JavaMail.jboss@colo-br-02.atl.jboss.com>

i think it is about time for a complete update of the jbpm user guide.  here is the outline that i currently had in mind:

http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmNewUserGuide

please, provide feedback here in this forum topic

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

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


From do-not-reply at jboss.com  Wed Jan  3 10:10:30 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Wed, 3 Jan 2007 10:10:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new user guide
Message-ID: <31429567.1167837030186.JavaMail.jboss@colo-br-02.atl.jboss.com>

A section on delegations would be useful. The delegation APIs are simple and can be covered quickly. More interesting would be to point to some examples.

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

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


From do-not-reply at jboss.com  Wed Jan  3 10:58:50 2007
From: do-not-reply at jboss.com (phillips4jc)
Date: Wed, 3 Jan 2007 10:58:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Problems compiling
	JBoss Labs
Message-ID: <32844693.1167839930561.JavaMail.jboss@colo-br-02.atl.jboss.com>

We downloaded the latest code from http://anonsvn.labs.jboss.com/labs/jbosslabs/trunk/ and have been trying to compile it.  We installed Maven 1.0.2 per the install instructions.  We are getting a lot of errors with it just trying to download jar dependencies.   Is there a more up to date repository that we should be checking out from?  Are there any plans to go to Maven 2, or at least to maven 1.1?  What is the time frame for the release of JBossLabs V. 2?  Our company would like to evaluate it for use for all their internal projects, as well as projects with business partners.  Your help would be greatly appreciated.

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

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


From do-not-reply at jboss.com  Wed Jan  3 11:02:02 2007
From: do-not-reply at jboss.com (anil.saldhana@jboss.com)
Date: Wed, 3 Jan 2007 11:02:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Security on JBoss] - Re:
	SecurityContext
Message-ID: <31710203.1167840122620.JavaMail.jboss@colo-br-02.atl.jboss.com>

The metadata repository at the request level is certainly a good alternative to the threadlocal setup.

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

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


From do-not-reply at jboss.com  Wed Jan  3 11:14:33 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Wed, 3 Jan 2007 11:14:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <18558117.1167840873165.JavaMail.jboss@colo-br-02.atl.jboss.com>

David, please try creating a process in the designer with a wait state and then create a task on the start state.  Generate a form with 1 variable for that start task.  Deploy and Start It.

Then i was navigated to the process instance view.

Can you see if that is the case for you ?

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

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


From do-not-reply at jboss.com  Wed Jan  3 11:19:27 2007
From: do-not-reply at jboss.com (unibrew)
Date: Wed, 3 Jan 2007 11:19:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Problems compiling
	JBoss Labs
Message-ID: <20215872.1167841167601.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hello

I think there are no plans to move to mvn2 yet. Could you provide log of your build problems? The timeframe for JBLabs 2.0 is end of this month but it might be delayed.

Regards
----------------------
Ryszard Kozmik
JBoss Forums Lead
JBoss Labs Developer

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

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


From do-not-reply at jboss.com  Wed Jan  3 11:27:11 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Wed, 3 Jan 2007 11:27:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new user guide
Message-ID: <19983407.1167841631687.JavaMail.jboss@colo-br-02.atl.jboss.com>

delegations chapter added.  pointers to examples were already present at the end of the tutorial.

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

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


From do-not-reply at jboss.com  Wed Jan  3 11:38:44 2007
From: do-not-reply at jboss.com (thomas.diesler@jboss.com)
Date: Wed, 3 Jan 2007 11:38:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: New jboss
	version info attributes
Message-ID: <25213107.1167842324158.JavaMail.jboss@colo-br-02.atl.jboss.com>

I use 

  |             ObjectName oname = ObjectNameFactory.create("jboss.system:type=ServerConfig");
  |             jbossVersion = (String)getServer().getAttribute(oname, "SpecificationVersion");
  | 

to enable/disable parts of our testsuite dependeing on the target environment. I only added the others for completeness.

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

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


From do-not-reply at jboss.com  Wed Jan  3 11:42:56 2007
From: do-not-reply at jboss.com (phillips4jc)
Date: Wed, 3 Jan 2007 11:42:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Problems compiling
	JBoss Labs
Message-ID: <4135668.1167842576935.JavaMail.jboss@colo-br-02.atl.jboss.com>

Thanks for the quick response.  The problem is that the ibiblio repository that the config files point to, no longer exists.  We are manually downloading the jar files one by one. So we get a little further with each iteration.  Just very time consuming.  I suspect that if you delete your local repo, and try to build from scratch you will see what we are seeing.

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

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


From do-not-reply at jboss.com  Wed Jan  3 11:54:56 2007
From: do-not-reply at jboss.com (phillips4jc)
Date: Wed, 3 Jan 2007 11:54:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Problems compiling
	JBoss Labs
Message-ID: <30503673.1167843296212.JavaMail.jboss@colo-br-02.atl.jboss.com>

We have run across one jar that is referenced that we cannot find.  jsf-facelets-portlet.jar.  Do you have a copy of this jar that you could send?

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

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


From do-not-reply at jboss.com  Wed Jan  3 11:55:38 2007
From: do-not-reply at jboss.com (phillips4jc)
Date: Wed, 3 Jan 2007 11:55:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Problems compiling
	JBoss Labs
Message-ID: <9408970.1167843338882.JavaMail.jboss@colo-br-02.atl.jboss.com>

We have run across one jar that is referenced that we cannot find.  jsf-facelets-portlet.jar.  Do you have a copy of this jar that you could send?

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

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


From do-not-reply at jboss.com  Wed Jan  3 12:36:24 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Wed, 3 Jan 2007 12:36:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-578 - Multiplex JGroups Channel
Message-ID: <30736405.1167845784405.JavaMail.jboss@colo-br-02.atl.jboss.com>

We will deploy JChannelFactory as part of jboss-messaging.sar for deployment under jboss-4, and we will use the default ChannelFactory under JBoss5.

I will add /META-INF/multiplexer-stacks.xml under jboss-messaging.sar, to use the exact same location jgroups.sar (forgot the exact name of the package under jboss-5). Under the source tree this will be located under /src/etc/META-INF (this was a perfect location for the testsuite also)

Also.. as there is an issue with JGroups and IPV6 (as documented on their WIKI page), I will add  -Djava.net.preferIPv4Stack=true on ServerManagement.spawn and every start-rmi-clustering-service, as the new stacks introduced by ChannelFactory and multiplexer-stacks.xml are using IPV6.


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

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


From do-not-reply at jboss.com  Wed Jan  3 12:40:01 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Wed, 3 Jan 2007 12:40:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-578 - Multiplex JGroups Channel
Message-ID: <14114211.1167846001299.JavaMail.jboss@colo-br-02.atl.jboss.com>

Please note that I'm hoping to get the JGroups multiplexer as a standard sar in the 4.2 release -- see http://jira.jboss.com/jira/browse/JBAS-3940.

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

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


From do-not-reply at jboss.com  Wed Jan  3 12:49:55 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Wed, 3 Jan 2007 12:49:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-578 - Multiplex JGroups Channel
Message-ID: <14391357.1167846595130.JavaMail.jboss@colo-br-02.atl.jboss.com>

Brian... what about this?

- We lookup for the JChannelFactory MBean...
- If not found, we create channels as we always used to do.

In our configurations we would aways have the MBean name by default, and the JGroups stack to be used case the MBean was not found.

This way, if jboss-messaging is deployed on 4.0, we would use the regular Channel, if on 4.2 or 5 we would use the multiplexor.

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

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


From do-not-reply at jboss.com  Wed Jan  3 12:56:42 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 3 Jan 2007 12:56:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <23154915.1167847002798.JavaMail.jboss@colo-br-02.atl.jboss.com>

Along the way to verifying this I ran across what looks like a separate bug.  I made a process with no tasks in it at all.  When you start such a process it should run right through and immediately exit the process.  However, what is actually happening is that the TaskMgmtInstance is creating a kind of null task instance that is getting assigned (thus generating an entry in the assignment logs).  This task instance has mostly null property values so everything is generating NPEs when trying to view the task.

Shouldn't "taskMgmtInstance.createStartTaskInstance();" return null and not add a task if there is no start task instance?  Also, why is this step even necessary?  I would think that task instances should be created automatically when a node is entered.

Any clarification is appreciated.

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

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


From do-not-reply at jboss.com  Wed Jan  3 13:08:47 2007
From: do-not-reply at jboss.com (aamonten)
Date: Wed, 3 Jan 2007 13:08:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	default.mf does not exist
Message-ID: <22989990.1167847727045.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, I fixed the problem, the latest change made on the aop/build.xml (31-12-2006) makes the build fails when building a recent checked out jbossaop project, because it can't find some files/directories

To fix it I had to create :

  | aop/output/etc/default.mf
  | aop/output/etc
  | aop/output/lib
  | 

maybe adding a dependency at the source-jar in aop/build.xml target could solve this problem, I will look for it.

regards
Alejandro



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

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


From do-not-reply at jboss.com  Wed Jan  3 13:14:05 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Wed, 3 Jan 2007 13:14:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-578 - Multiplex JGroups Channel
Message-ID: <8827972.1167848045193.JavaMail.jboss@colo-br-02.atl.jboss.com>

JBoss Cache actually basically does it that way.  The downside to it is that it masks errors (if the JChannelFactory really should be found).  For that reason I'm tempted to change the JBC behavior so it fails if it can't find a configured JChannelFactory.  But it sounds like the JBM case is different from JBC in that you have a standard config file that you want to work in multiple environments.  JBC doesn't have such a requirement.  So, for JBM what you propose sounds reasonable.

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

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


From do-not-reply at jboss.com  Wed Jan  3 13:15:42 2007
From: do-not-reply at jboss.com (anil.saldhana@jboss.com)
Date: Wed, 3 Jan 2007 13:15:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: EJB References
Message-ID: <5450189.1167848142672.JavaMail.jboss@colo-br-02.atl.jboss.com>

Where are we with MDBs getting reference to JMS destinations?

anonymous wrote : ant -Dtest=org.jboss.test.security.test.EJBSpecUnitTestCase one-test

anonymous wrote : Caused by: javax.naming.NameNotFoundException: QueueC not bound

The queues are created. But the jndi lookup is failing.

Maybe the JMSContainerInvoker/JMSProviderAdapter need look here?

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

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


From do-not-reply at jboss.com  Wed Jan  3 13:30:10 2007
From: do-not-reply at jboss.com (james.williams@jboss.com)
Date: Wed, 3 Jan 2007 13:30:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new user guide
Message-ID: <793241.1167849010963.JavaMail.jboss@colo-br-02.atl.jboss.com>

I like the tutorial outline. It might be a good idea to break out the outline bullets into 2 different guides. One for operations, basically configuration/deployment/optimization and one for Java app developers. Also, I have been working on Seam Labs that are basically a set of helloworld projects that show 1 or 2 Seam features in action with code/configuration. Something like this might be a good thing for standalone jBPM.

http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossSeamLabs. 

I know Burr is doing something similar for ESB, and we plan on converging to a single lab, he calls them "workshops" format/scheme.

James

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

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


From do-not-reply at jboss.com  Wed Jan  3 13:38:05 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Wed, 3 Jan 2007 13:38:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <4652611.1167849485326.JavaMail.jboss@colo-br-02.atl.jboss.com>

I noticed this same issue when I was working with Seam and jBPM several months ago. The way tasks are implemented at a start node, they are not created automatically, but must be explicitly created. Seam did not know this, so it would not create startTaskInstances. The web console always did it, assuming that there were always startTasks. Which is true for the web sale process but not true in general.

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

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


From do-not-reply at jboss.com  Wed Jan  3 13:40:35 2007
From: do-not-reply at jboss.com (phillips4jc)
Date: Wed, 3 Jan 2007 13:40:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Problems compiling
	JBoss Labs
Message-ID: <25440483.1167849635057.JavaMail.jboss@colo-br-02.atl.jboss.com>

After renaming jsf-facelets.jar to jsf-facelets-porlet.jar we were able to compile and deploy.  Is there some documentation that explains how to create and manage multiple projects, etc.   The information that I found online indicates that it is integrated with SVN, JIRA, Cruise Control, has blogs, wiki, etc..  The complany currently uses CVS but is wanting to transition to SVN, they use JIRA, and they use CruiseControl, so this would be a great fit. When logging in to a specific project, will you only see the source, bugs, etc for that particular project?

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

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


From do-not-reply at jboss.com  Wed Jan  3 13:49:20 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 3 Jan 2007 13:49:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	default.mf does not exist
Message-ID: <17778224.1167850160261.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have fixed the build.

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

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


From do-not-reply at jboss.com  Wed Jan  3 14:05:33 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 3 Jan 2007 14:05:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <12615446.1167851133340.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hm, so I guess to work around it I need to examine the start node and determine whether there is a task associated with it.  Seems like there should be a better way...

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

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


From do-not-reply at jboss.com  Wed Jan  3 14:09:27 2007
From: do-not-reply at jboss.com (phillips4jc)
Date: Wed, 3 Jan 2007 14:09:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Problems Deploying
	JBoss Labs
Message-ID: <9027555.1167851367162.JavaMail.jboss@colo-br-02.atl.jboss.com>

We were able to compile after making a copy of the jsf-facelets.jar file and calling the copy jsf-facelets-porltet.jar.  Next we deployed it.  We are able to view the portal but it is throwing exceptions and complaining about incompletely deployed packages.  Can you offer some exceptions.

=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /usr/local/portal

  JAVA: /usr/lib/jdk1.5.0_09//bin/java

  JAVA_OPTS: -Djava.security.auth.login.config=../conf/jaas.conf -javaagent:pluggable-instrumentor.jar -Dprogram.name=run.sh

  CLASSPATH: /usr/local/portal/bin/run.jar:/usr/lib/jdk1.5.0_09//lib/tools.jar

=========================================================================

12:54:14,488 INFO  [Server] Starting JBoss (MX MicroKernel)...
12:54:14,490 INFO  [Server] Release ID: JBoss [Zion] 4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000)
12:54:14,493 INFO  [Server] Home Dir: /usr/local/portal
12:54:14,493 INFO  [Server] Home URL: file:/usr/local/portal/
12:54:14,495 INFO  [Server] Patch URL: null
12:54:14,495 INFO  [Server] Server Name: default
12:54:14,495 INFO  [Server] Server Home Dir: /usr/local/portal/server/default
12:54:14,495 INFO  [Server] Server Home URL: file:/usr/local/portal/server/default/
12:54:14,496 INFO  [Server] Server Log Dir: /usr/local/portal/server/default/log
12:54:14,496 INFO  [Server] Server Temp Dir: /usr/local/portal/server/default/tmp
12:54:14,497 INFO  [Server] Root Deployment Filename: jboss-service.xml
12:54:15,386 INFO  [ServerInfo] Java version: 1.5.0_09,Sun Microsystems Inc.
12:54:15,386 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.5.0_09-b01,Sun Microsystems Inc.
12:54:15,386 INFO  [ServerInfo] OS-System: Linux 2.6.9-42.0.3.EL,i386
12:54:16,438 INFO  [Server] Core system initialized
12:54:18,687 INFO  [WebService] Using RMI server codebase: http://B-0359:8083/
12:54:18,722 INFO  [Log4jService$URLWatchTimerTask] Configuring from URL: resource:log4j.xml
12:54:19,050 INFO  [NamingService] JNDI bootstrap JNP=/0.0.0.0:1099, RMI=/0.0.0.0:1098, backlog=50, no client SocketFactory, Server SocketFactory=class org.jboss.net.sockets.DefaultSocketFactory
12:54:20,800 ERROR [MainDeployer] Could not initialise deployment: file:/usr/local/portal/server/default/deploy/jboss-hibernate.deployer/
org.jboss.deployment.DeploymentException: Failed to find META-INF/jboss-service.xml for archive jboss-hibernate.deployer
	at org.jboss.deployment.SARDeployer.parseDocument(SARDeployer.java:616)
	at org.jboss.deployment.SARDeployer.init(SARDeployer.java:181)
	at org.jboss.deployment.MainDeployer.init(MainDeployer.java:861)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:798)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy8.deploy(Unknown Source)
	at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
	at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
	at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
	at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
	at $Proxy0.start(Unknown Source)
	at org.jboss.system.ServiceController.start(ServiceController.java:417)
	at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy4.start(Unknown Source)
	at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy5.deploy(Unknown Source)
	at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
	at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
	at org.jboss.Main.boot(Main.java:200)
	at org.jboss.Main$1.run(Main.java:464)
	at java.lang.Thread.run(Thread.java:595)
12:54:23,183 INFO  [AspectDeployer] Deployed AOP: file:/usr/local/portal/server/default/deploy/jboss-portal.sar/portal-aop.xml
12:54:28,188 ERROR [MainDeployer] Could not initialise deployment: file:/usr/local/portal/server/default/deploy/jboss-ws4ee.sar/
org.jboss.deployment.DeploymentException: Failed to find META-INF/jboss-service.xml for archive jboss-ws4ee.sar
	at org.jboss.deployment.SARDeployer.parseDocument(SARDeployer.java:616)
	at org.jboss.deployment.SARDeployer.init(SARDeployer.java:181)
	at org.jboss.deployment.MainDeployer.init(MainDeployer.java:861)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:798)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy8.deploy(Unknown Source)
	at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
	at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
	at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
	at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
	at $Proxy0.start(Unknown Source)
	at org.jboss.system.ServiceController.start(ServiceController.java:417)
	at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy4.start(Unknown Source)
	at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy5.deploy(Unknown Source)
	at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
	at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
	at org.jboss.Main.boot(Main.java:200)
	at org.jboss.Main$1.run(Main.java:464)
	at java.lang.Thread.run(Thread.java:595)
12:54:29,405 INFO  [Embedded] Catalina naming disabled
12:54:29,519 INFO  [ClusterRuleSetFactory] Unable to find a cluster rule set in the classpath. Will load the default rule set.
12:54:29,521 INFO  [ClusterRuleSetFactory] Unable to find a cluster rule set in the classpath. Will load the default rule set.
12:54:30,108 INFO  [Http11BaseProtocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080
12:54:30,111 INFO  [Catalina] Initialization processed in 590 ms
12:54:30,111 INFO  [StandardService] Starting service jboss.web
12:54:30,121 INFO  [StandardEngine] Starting Servlet Engine: Apache Tomcat/5.5.17
12:54:30,196 INFO  [StandardHost] XML validation disabled
12:54:30,240 INFO  [Catalina] Server startup in 129 ms
12:54:30,451 INFO  [TomcatDeployer] deploy, ctxPath=/invoker, warUrl=.../deploy/http-invoker.sar/invoker.war/
12:54:30,967 INFO  [WebappLoader] Dual registration of jndi stream handler: factory already defined
12:54:31,769 INFO  [TomcatDeployer] deploy, ctxPath=/portal-cms, warUrl=.../deploy/jboss-portal.sar/portal-cms.war/
12:54:32,007 INFO  [TomcatDeployer] deploy, ctxPath=/portal-core, warUrl=.../deploy/jboss-portal.sar/portal-core.war/
12:54:33,134 INFO  [FacesConfigurator] Reading standard config org/apache/myfaces/resource/standard-faces-config.xml
12:54:33,314 INFO  [FacesConfigurator] Reading config jar:file:/usr/local/portal/server/default/tmp/deploy/tmp35816jsf-facelets.jar!/META-INF/faces-config.xml
12:54:33,335 INFO  [FacesConfigurator] Reading config jar:file:/usr/local/portal/server/default/tmp/deploy/tmp35833tomahawk.jar!/META-INF/faces-config.xml
12:54:33,422 INFO  [FacesConfigurator] Reading config /WEB-INF/faces-config.xml
12:54:33,709 ERROR [LocaleUtils] Locale name null or empty, ignoring
12:54:35,086 INFO  [StartupServletContextListener] ServletContext '/usr/local/portal/server/default/./deploy/jboss-portal.sar/portal-core.war/' initialized.
12:54:35,222 INFO  [TomcatDeployer] deploy, ctxPath=/portal-samples, warUrl=.../deploy/jboss-portal.sar/portal-samples.war/
12:54:35,489 INFO  [TomcatDeployer] deploy, ctxPath=/portal, warUrl=.../deploy/jboss-portal.sar/portal-server.war/
12:54:35,836 INFO  [TomcatDeployer] deploy, ctxPath=/, warUrl=.../deploy/jbossweb-tomcat55.sar/ROOT.war/
12:54:36,837 INFO  [TomcatDeployer] deploy, ctxPath=/jbossws, warUrl=.../tmp/deploy/tmp35864jbossws-exp.war/
12:54:40,322 INFO  [TomcatDeployer] deploy, ctxPath=/portal-wsrp, warUrl=.../tmp/deploy/portal-wsrp-exp.war/
12:54:40,632 INFO  [WSDLFilePublisher] WSDL published to: file:/usr/local/portal/server/default/data/wsdl/portal-wsrp.war/wsrp_services.wsdl
12:54:41,906 INFO  [ServiceEndpointManager] WebService started: http://B-0359:8080/portal-wsrp/ServiceDescriptionService
12:54:41,907 INFO  [ServiceEndpointManager] WebService started: http://B-0359:8080/portal-wsrp/MarkupService
12:54:41,907 INFO  [ServiceEndpointManager] WebService started: http://B-0359:8080/portal-wsrp/RegistrationService
12:54:41,907 INFO  [ServiceEndpointManager] WebService started: http://B-0359:8080/portal-wsrp/PortletManagementService
12:54:42,016 INFO  [SubscriptionManager] Bound event dispatcher to java:/EventDispatcher
12:54:42,233 INFO  [TomcatDeployer] deploy, ctxPath=/jbossmq-httpil, warUrl=.../deploy/jms/jbossmq-httpil.sar/jbossmq-httpil.war/
12:54:44,050 INFO  [ClientDeployer] Client ENC bound under: wsrp-client
12:54:46,354 INFO  [TomcatDeployer] deploy, ctxPath=/web-console, warUrl=.../deploy/management/console-mgr.sar/web-console.war/
12:54:47,871 INFO  [MailService] Mail Service bound to java:/Mail
12:54:48,300 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-ha-local-jdbc.rar
12:54:48,386 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-ha-xa-jdbc.rar
12:54:48,433 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-local-jdbc.rar
12:54:48,494 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-xa-jdbc.rar
12:54:48,553 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jms/jms-ra.rar
12:54:48,610 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/mail-ra.rar
12:54:49,928 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
12:54:50,407 INFO  [A] Bound to JNDI name: queue/A
12:54:50,408 INFO  [B] Bound to JNDI name: queue/B
12:54:50,410 INFO  [C] Bound to JNDI name: queue/C
12:54:50,411 INFO  [D] Bound to JNDI name: queue/D
12:54:50,412 INFO  [ex] Bound to JNDI name: queue/ex
12:54:50,454 INFO  [testTopic] Bound to JNDI name: topic/testTopic
12:54:50,456 INFO  [securedTopic] Bound to JNDI name: topic/securedTopic
12:54:50,457 INFO  [testDurableTopic] Bound to JNDI name: topic/testDurableTopic
12:54:50,460 INFO  [testQueue] Bound to JNDI name: queue/testQueue
12:54:50,573 INFO  [UILServerILService] JBossMQ UIL service available at : /0.0.0.0:8093
12:54:50,674 INFO  [DLQ] Bound to JNDI name: queue/DLQ
12:54:50,993 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
12:54:51,165 INFO  [Environment] Hibernate 3.2 cr2
12:54:51,183 INFO  [Environment] hibernate.properties not found
12:54:51,192 INFO  [Environment] Bytecode provider name : cglib
12:54:51,222 INFO  [Environment] using JDK 1.4 java.sql.Timestamp handling
12:54:51,475 INFO  [Configuration] configuring from url: file:/usr/local/portal/server/default/deploy/jboss-portal.sar/portal-cms.sar/conf/hibernate/cms/hibernate.cfg.xml
12:54:51,486 INFO  [Configuration] Reading mappings from resource: conf/hibernate/cms/domain.hbm.xml
12:54:52,271 INFO  [HbmBinder] Mapping class: org.jboss.portal.cms.hibernate.state.VersionBinVal -> jbp_cms_version_binval
12:54:52,337 INFO  [HbmBinder] Mapping class: org.jboss.portal.cms.hibernate.state.VersionNode -> jbp_cms_version_node
12:54:52,338 INFO  [HbmBinder] Mapping class: org.jboss.portal.cms.hibernate.state.VersionProp -> jbp_cms_version_prop
12:54:52,340 INFO  [HbmBinder] Mapping class: org.jboss.portal.cms.hibernate.state.VersionRefs -> jbp_cms_version_refs
12:54:52,341 INFO  [HbmBinder] Mapping class: org.jboss.portal.cms.hibernate.state.WSPBinVal -> jbp_cms_wsp_binval
12:54:52,341 INFO  [HbmBinder] Mapping class: org.jboss.portal.cms.hibernate.state.WSPNode -> jbp_cms_wsp_node
12:54:52,341 INFO  [HbmBinder] Mapping class: org.jboss.portal.cms.hibernate.state.WSPProp -> jbp_cms_wsp_prop
12:54:52,342 INFO  [HbmBinder] Mapping class: org.jboss.portal.cms.hibernate.state.WSPRefs -> jbp_cms_wsp_refs
12:54:52,342 INFO  [HbmBinder] Mapping class: org.jboss.portal.cms.hibernate.CMSEntry -> jbp_cms_cmsentry
12:54:52,343 INFO  [HbmBinder] Mapping class: org.jboss.portal.cms.hibernate.RepositoryEntry -> jbp_cms_repositoryentry
12:54:52,344 INFO  [HbmBinder] Mapping class: org.jboss.portal.cms.hibernate.VersionEntry -> jbp_cms_versionentry
12:54:52,344 INFO  [Configuration] Configured SessionFactory: null
12:54:52,348 INFO  [Configuration] configuring from url: file:/usr/local/portal/server/default/deploy/jboss-portal.sar/conf/hibernate/user/hibernate.cfg.xml
12:54:52,352 INFO  [Configuration] Reading mappings from resource: conf/hibernate/user/domain.hbm.xml
12:54:52,393 INFO  [HbmBinder] Mapping class: org.jboss.portal.identity.db.UserImpl -> jbp_users
12:54:52,399 INFO  [HbmBinder] Mapping collection: org.jboss.portal.identity.db.UserImpl.dynamic -> jbp_user_prop
12:54:52,421 INFO  [HbmBinder] Mapping collection: org.jboss.portal.identity.db.UserImpl.roles -> jbp_role_membership
12:54:52,421 INFO  [HbmBinder] Mapping class: org.jboss.portal.identity.db.RoleImpl -> jbp_roles
12:54:52,422 INFO  [HbmBinder] Mapping collection: org.jboss.portal.identity.db.RoleImpl.users -> jbp_role_membership
12:54:52,422 INFO  [Configuration] Configured SessionFactory: null
12:54:52,427 INFO  [Configuration] configuring from url: file:/usr/local/portal/server/default/deploy/jboss-portal.sar/conf/hibernate/instance/hibernate.cfg.xml
12:54:52,438 INFO  [Configuration] Reading mappings from resource: conf/hibernate/instance/domain.hbm.xml
12:54:52,462 INFO  [HbmBinder] Mapping class: org.jboss.portal.core.impl.model.instance.InstanceImpl -> JBP_INSTANCE
12:54:52,499 INFO  [HbmBinder] Mapping class: org.jboss.portal.core.impl.model.instance.UserInstance -> JBP_INSTANCE_PER_USER
12:54:52,747 INFO  [HbmBinder] Mapping class: org.jboss.portal.core.impl.model.instance.InstanceSecurityBinding -> JBP_INSTANCE_SECURITY
12:54:52,755 INFO  [HbmBinder] Mapping collection: org.jboss.portal.core.impl.model.instance.InstanceSecurityBinding.actions -> JBP_INSTANCE_SECURITY_ACTIONS
12:54:52,755 INFO  [Configuration] Configured SessionFactory: null
12:54:52,759 INFO  [Configuration] configuring from url: file:/usr/local/portal/server/default/deploy/jboss-portal.sar/conf/hibernate/portal/hibernate.cfg.xml
12:54:52,764 INFO  [Configuration] Reading mappings from resource: conf/hibernate/portal/domain.hbm.xml
12:54:52,801 INFO  [HbmBinder] Mapping class: org.jboss.portal.core.impl.model.portal.ObjectNode -> JBP_OBJECT_NODE
12:54:52,830 INFO  [HbmBinder] Mapping class: org.jboss.portal.core.impl.model.portal.PortalObjectImpl -> JBP_PORTAL_OBJECT
12:54:52,831 INFO  [HbmBinder] Mapping collection: org.jboss.portal.core.impl.model.portal.PortalObjectImpl.declaredProperties -> JBP_PORTAL_OBJECT_PROPS
12:54:52,911 INFO  [HbmBinder] Mapping joined-subclass: org.jboss.portal.core.impl.model.portal.ContextImpl -> JBP_CONTEXT
12:54:52,912 INFO  [HbmBinder] Mapping joined-subclass: org.jboss.portal.core.impl.model.portal.PortalImpl -> JBP_PORTAL
12:54:52,912 INFO  [HbmBinder] Mapping collection: org.jboss.portal.core.impl.model.portal.PortalImpl.modes -> JBP_PORTAL_MODE
12:54:52,923 INFO  [HbmBinder] Mapping collection: org.jboss.portal.core.impl.model.portal.PortalImpl.windowStates -> JBP_PORTAL_WINDOW_STATE
12:54:52,924 INFO  [HbmBinder] Mapping joined-subclass: org.jboss.portal.core.impl.model.portal.PageImpl -> JBP_PAGE
12:54:52,924 INFO  [HbmBinder] Mapping joined-subclass: org.jboss.portal.core.impl.model.portal.WindowImpl -> JBP_WINDOW
12:54:52,930 INFO  [HbmBinder] Mapping class: org.jboss.portal.core.impl.model.portal.ObjectNodeSecurityConstraint -> JBP_OBJECT_NODE_SEC
12:54:52,936 INFO  [HbmBinder] Mapping collection: org.jboss.portal.core.impl.model.portal.ObjectNodeSecurityConstraint.actions -> JBP_OBJECT_NODE_SEC_ACTIONS
12:54:52,937 INFO  [Configuration] Configured SessionFactory: null
12:54:52,966 INFO  [Configuration] configuring from url: file:/usr/local/portal/server/default/deploy/jboss-portal.sar/conf/hibernate/portlet/hibernate.cfg.xml
12:54:52,975 INFO  [Configuration] Reading mappings from resource: conf/hibernate/portlet/domain.hbm.xml
12:54:52,999 INFO  [HbmBinder] Mapping class: org.jboss.portal.core.impl.portlet.state.PersistentState -> JBP_PORTLET_STATE
12:54:53,004 INFO  [HbmBinder] Mapping class: org.jboss.portal.core.impl.portlet.state.PersistentStateEntry -> JBP_PORTLET_STATE_ENTRY
12:54:53,005 INFO  [HbmBinder] Mapping collection: org.jboss.portal.core.impl.portlet.state.PersistentStateEntry.strings -> JBP_PORTLET_STATE_ENTRY_VALUE
12:54:53,007 INFO  [Configuration] Configured SessionFactory: null
12:54:53,024 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=PortalDS' to JNDI name 'java:PortalDS'
12:54:53,308 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:53,308 INFO  [DatasourceConnectionProvider] Using datasource: java:PortalDS
12:54:53,309 INFO  [SettingsFactory] RDBMS: HSQL Database Engine, version: 1.8.0
12:54:53,310 INFO  [SettingsFactory] JDBC driver: HSQL Database Engine Driver, version: 1.8.0
12:54:53,390 INFO  [Dialect] Using dialect: org.hibernate.dialect.HSQLDialect
12:54:53,429 INFO  [TransactionFactoryFactory] Transaction strategy: org.hibernate.transaction.JTATransactionFactory
12:54:53,444 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:53,451 INFO  [TransactionManagerLookupFactory] instantiating TransactionManagerLookup: org.hibernate.transaction.JBossTransactionManagerLookup
12:54:53,461 INFO  [TransactionManagerLookupFactory] instantiated TransactionManagerLookup
12:54:53,462 INFO  [TransactionManagerLookupFactory] instantiating TransactionManagerLookup: org.hibernate.transaction.JBossTransactionManagerLookup
12:54:53,462 INFO  [TransactionManagerLookupFactory] instantiated TransactionManagerLookup
12:54:53,462 INFO  [SettingsFactory] Automatic flush during beforeCompletion(): enabled
12:54:53,462 INFO  [SettingsFactory] Automatic session close at end of transaction: disabled
12:54:53,462 INFO  [SettingsFactory] JDBC batch size: 15
12:54:53,462 INFO  [SettingsFactory] JDBC batch updates for versioned data: disabled
12:54:53,464 INFO  [SettingsFactory] Scrollable result sets: enabled
12:54:53,464 INFO  [SettingsFactory] JDBC3 getGeneratedKeys(): disabled
12:54:53,464 INFO  [SettingsFactory] Connection release mode: auto
12:54:53,466 INFO  [SettingsFactory] Default batch fetch size: 1
12:54:53,466 INFO  [SettingsFactory] Generate SQL with comments: disabled
12:54:53,466 INFO  [SettingsFactory] Order SQL updates by primary key: disabled
12:54:53,466 INFO  [SettingsFactory] Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory
12:54:53,487 INFO  [ASTQueryTranslatorFactory] Using ASTQueryTranslatorFactory
12:54:53,487 INFO  [SettingsFactory] Query language substitutions: {}
12:54:53,487 INFO  [SettingsFactory] Second-level cache: disabled
12:54:53,487 INFO  [SettingsFactory] Query cache: disabled
12:54:53,503 INFO  [SettingsFactory] Optimize cache for minimal puts: disabled
12:54:53,503 INFO  [SettingsFactory] Structured second-level cache entries: disabled
12:54:53,518 INFO  [SettingsFactory] Statistics: disabled
12:54:53,518 INFO  [SettingsFactory] Deleted entity synthetic identifier rollback: disabled
12:54:53,518 INFO  [SettingsFactory] Default entity-mode: pojo
12:54:53,611 INFO  [SessionFactoryImpl] building session factory
12:54:54,851 INFO  [SessionFactoryObjectFactory] Factory name: java:/portal/cms/CMSSessionFactory
12:54:54,852 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:54,852 INFO  [NamingHelper] Creating subcontext: portal
12:54:54,853 INFO  [NamingHelper] Creating subcontext: cms
12:54:54,855 INFO  [SessionFactoryObjectFactory] Bound factory to JNDI name: java:/portal/cms/CMSSessionFactory
12:54:54,856 WARN  [SessionFactoryObjectFactory] InitialContext did not implement EventContext
12:54:54,856 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:55,776 INFO  [JCRCMS] Starting JCR CMS
12:54:56,069 INFO  [RepositoryImpl] Starting repository...
12:54:57,363 INFO  [RepositoryImpl] initializing workspace 'default'...
12:54:57,458 INFO  [RepositoryImpl] workspace 'default' initialized
12:54:57,689 INFO  [RepositoryImpl] Repository started
12:54:57,690 INFO  [JackrabbitJCRService] Repository 'PortalRepository' created
12:54:57,792 INFO  [JackrabbitJCRService] The repository has already the CMS node types registered
12:54:57,807 INFO  [JCRCMS] Started JCR CMS in: 2s:31ms
12:54:57,818 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:57,819 INFO  [DatasourceConnectionProvider] Using datasource: java:PortalDS
12:54:57,819 INFO  [SettingsFactory] RDBMS: HSQL Database Engine, version: 1.8.0
12:54:57,819 INFO  [SettingsFactory] JDBC driver: HSQL Database Engine Driver, version: 1.8.0
12:54:57,819 INFO  [Dialect] Using dialect: org.hibernate.dialect.HSQLDialect
12:54:57,820 INFO  [TransactionFactoryFactory] Transaction strategy: org.hibernate.transaction.JTATransactionFactory
12:54:57,820 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:57,820 INFO  [TransactionManagerLookupFactory] instantiating TransactionManagerLookup: org.hibernate.transaction.JBossTransactionManagerLookup
12:54:57,820 INFO  [TransactionManagerLookupFactory] instantiated TransactionManagerLookup
12:54:57,820 INFO  [TransactionManagerLookupFactory] instantiating TransactionManagerLookup: org.hibernate.transaction.JBossTransactionManagerLookup
12:54:57,820 INFO  [TransactionManagerLookupFactory] instantiated TransactionManagerLookup
12:54:57,820 INFO  [SettingsFactory] Automatic flush during beforeCompletion(): enabled
12:54:57,820 INFO  [SettingsFactory] Automatic session close at end of transaction: disabled
12:54:57,820 INFO  [SettingsFactory] JDBC batch size: 15
12:54:57,820 INFO  [SettingsFactory] JDBC batch updates for versioned data: disabled
12:54:57,820 INFO  [SettingsFactory] Scrollable result sets: enabled
12:54:57,821 INFO  [SettingsFactory] JDBC3 getGeneratedKeys(): disabled
12:54:57,821 INFO  [SettingsFactory] Connection release mode: auto
12:54:57,821 INFO  [SettingsFactory] Default batch fetch size: 1
12:54:57,821 INFO  [SettingsFactory] Generate SQL with comments: disabled
12:54:57,821 INFO  [SettingsFactory] Order SQL updates by primary key: disabled
12:54:57,821 INFO  [SettingsFactory] Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory
12:54:57,821 INFO  [ASTQueryTranslatorFactory] Using ASTQueryTranslatorFactory
12:54:57,821 INFO  [SettingsFactory] Query language substitutions: {}
12:54:57,821 INFO  [SettingsFactory] Second-level cache: enabled
12:54:57,821 INFO  [SettingsFactory] Query cache: enabled
12:54:57,821 INFO  [SettingsFactory] Cache provider: org.hibernate.cache.EhCacheProvider
12:54:57,843 INFO  [SettingsFactory] Optimize cache for minimal puts: disabled
12:54:57,844 INFO  [SettingsFactory] Structured second-level cache entries: disabled
12:54:57,844 INFO  [SettingsFactory] Query cache factory: org.hibernate.cache.StandardQueryCacheFactory
12:54:57,854 INFO  [SettingsFactory] Statistics: disabled
12:54:57,854 INFO  [SettingsFactory] Deleted entity synthetic identifier rollback: disabled
12:54:57,855 INFO  [SettingsFactory] Default entity-mode: pojo
12:54:57,859 INFO  [SessionFactoryImpl] building session factory
12:54:57,932 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.identity.db.UserImpl]; using defaults.
12:54:58,017 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.identity.db.RoleImpl]; using defaults.
12:54:58,062 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.identity.db.UserImpl.roles]; using defaults.
12:54:58,093 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.identity.db.UserImpl.dynamic]; using defaults.
12:54:58,098 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.identity.db.RoleImpl.users]; using defaults.
12:54:58,125 INFO  [SessionFactoryObjectFactory] Factory name: java:/portal/UserSessionFactory
12:54:58,125 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:58,126 INFO  [SessionFactoryObjectFactory] Bound factory to JNDI name: java:/portal/UserSessionFactory
12:54:58,127 WARN  [SessionFactoryObjectFactory] InitialContext did not implement EventContext
12:54:58,128 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:58,134 INFO  [UpdateTimestampsCache] starting update timestamps cache at region: org.hibernate.cache.UpdateTimestampsCache
12:54:58,134 WARN  [EhCacheProvider] Could not find configuration [org.hibernate.cache.UpdateTimestampsCache]; using defaults.
12:54:58,137 INFO  [StandardQueryCache] starting query cache at region: org.hibernate.cache.StandardQueryCache
12:54:58,137 WARN  [EhCacheProvider] Could not find configuration [org.hibernate.cache.StandardQueryCache]; using defaults.
12:54:58,188 INFO  [HbmBinder] Mapping collection: org.jboss.portal.core.impl.model.instance.InstanceImpl.securityBindings -> JBP_INSTANCE_SECURITY
12:54:58,191 INFO  [HbmBinder] Mapping collection: org.jboss.portal.core.impl.model.instance.InstanceImpl.userInstances -> JBP_INSTANCE_PER_USER
12:54:58,202 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:58,203 INFO  [DatasourceConnectionProvider] Using datasource: java:PortalDS
12:54:58,203 INFO  [SettingsFactory] RDBMS: HSQL Database Engine, version: 1.8.0
12:54:58,203 INFO  [SettingsFactory] JDBC driver: HSQL Database Engine Driver, version: 1.8.0
12:54:58,204 INFO  [Dialect] Using dialect: org.hibernate.dialect.HSQLDialect
12:54:58,204 INFO  [TransactionFactoryFactory] Transaction strategy: org.hibernate.transaction.JTATransactionFactory
12:54:58,204 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:58,204 INFO  [TransactionManagerLookupFactory] instantiating TransactionManagerLookup: org.hibernate.transaction.JBossTransactionManagerLookup
12:54:58,204 INFO  [TransactionManagerLookupFactory] instantiated TransactionManagerLookup
12:54:58,205 INFO  [TransactionManagerLookupFactory] instantiating TransactionManagerLookup: org.hibernate.transaction.JBossTransactionManagerLookup
12:54:58,205 INFO  [TransactionManagerLookupFactory] instantiated TransactionManagerLookup
12:54:58,205 INFO  [SettingsFactory] Automatic flush during beforeCompletion(): enabled
12:54:58,205 INFO  [SettingsFactory] Automatic session close at end of transaction: disabled
12:54:58,205 INFO  [SettingsFactory] JDBC batch size: 15
12:54:58,205 INFO  [SettingsFactory] JDBC batch updates for versioned data: disabled
12:54:58,205 INFO  [SettingsFactory] Scrollable result sets: enabled
12:54:58,205 INFO  [SettingsFactory] JDBC3 getGeneratedKeys(): disabled
12:54:58,205 INFO  [SettingsFactory] Connection release mode: auto
12:54:58,205 INFO  [SettingsFactory] Default batch fetch size: 1
12:54:58,205 INFO  [SettingsFactory] Generate SQL with comments: disabled
12:54:58,205 INFO  [SettingsFactory] Order SQL updates by primary key: disabled
12:54:58,205 INFO  [SettingsFactory] Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory
12:54:58,205 INFO  [ASTQueryTranslatorFactory] Using ASTQueryTranslatorFactory
12:54:58,205 INFO  [SettingsFactory] Query language substitutions: {}
12:54:58,205 INFO  [SettingsFactory] Second-level cache: enabled
12:54:58,205 INFO  [SettingsFactory] Query cache: enabled
12:54:58,205 INFO  [SettingsFactory] Cache provider: org.hibernate.cache.EhCacheProvider
12:54:58,206 INFO  [SettingsFactory] Optimize cache for minimal puts: disabled
12:54:58,206 INFO  [SettingsFactory] Structured second-level cache entries: disabled
12:54:58,206 INFO  [SettingsFactory] Query cache factory: org.hibernate.cache.StandardQueryCacheFactory
12:54:58,206 INFO  [SettingsFactory] Statistics: disabled
12:54:58,206 INFO  [SettingsFactory] Deleted entity synthetic identifier rollback: disabled
12:54:58,206 INFO  [SettingsFactory] Default entity-mode: pojo
12:54:58,210 INFO  [SessionFactoryImpl] building session factory
12:54:58,221 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.model.instance.InstanceSecurityBinding]; using defaults.
12:54:58,224 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.model.instance.UserInstance]; using defaults.
12:54:58,258 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.model.instance.InstanceImpl]; using defaults.
12:54:58,292 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.model.instance.InstanceImpl.securityBindings]; using defaults.
12:54:58,296 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.model.instance.InstanceImpl.userInstances]; using defaults.
12:54:58,296 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.model.instance.InstanceSecurityBinding.actions]; using defaults.
12:54:58,310 INFO  [SessionFactoryObjectFactory] Factory name: java:/portal/InstanceSessionFactory
12:54:58,311 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:58,312 INFO  [SessionFactoryObjectFactory] Bound factory to JNDI name: java:/portal/InstanceSessionFactory
12:54:58,312 WARN  [SessionFactoryObjectFactory] InitialContext did not implement EventContext
12:54:58,312 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:58,312 INFO  [UpdateTimestampsCache] starting update timestamps cache at region: org.hibernate.cache.UpdateTimestampsCache
12:54:58,312 WARN  [EhCacheProvider] Could not find configuration [org.hibernate.cache.UpdateTimestampsCache]; using defaults.
12:54:58,313 INFO  [StandardQueryCache] starting query cache at region: org.hibernate.cache.StandardQueryCache
12:54:58,313 WARN  [EhCacheProvider] Could not find configuration [org.hibernate.cache.StandardQueryCache]; using defaults.
12:54:58,375 INFO  [HbmBinder] Mapping collection: org.jboss.portal.core.impl.model.portal.ObjectNode.children -> JBP_OBJECT_NODE
12:54:58,376 INFO  [HbmBinder] Mapping collection: org.jboss.portal.core.impl.model.portal.ObjectNode.securityConstraints -> JBP_OBJECT_NODE_SEC
12:54:58,408 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:58,408 INFO  [DatasourceConnectionProvider] Using datasource: java:PortalDS
12:54:58,409 INFO  [SettingsFactory] RDBMS: HSQL Database Engine, version: 1.8.0
12:54:58,409 INFO  [SettingsFactory] JDBC driver: HSQL Database Engine Driver, version: 1.8.0
12:54:58,409 INFO  [Dialect] Using dialect: org.hibernate.dialect.HSQLDialect
12:54:58,410 INFO  [TransactionFactoryFactory] Transaction strategy: org.hibernate.transaction.JTATransactionFactory
12:54:58,410 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:58,410 INFO  [TransactionManagerLookupFactory] instantiating TransactionManagerLookup: org.hibernate.transaction.JBossTransactionManagerLookup
12:54:58,410 INFO  [TransactionManagerLookupFactory] instantiated TransactionManagerLookup
12:54:58,410 INFO  [TransactionManagerLookupFactory] instantiating TransactionManagerLookup: org.hibernate.transaction.JBossTransactionManagerLookup
12:54:58,410 INFO  [TransactionManagerLookupFactory] instantiated TransactionManagerLookup
12:54:58,410 INFO  [SettingsFactory] Automatic flush during beforeCompletion(): enabled
12:54:58,410 INFO  [SettingsFactory] Automatic session close at end of transaction: disabled
12:54:58,410 INFO  [SettingsFactory] JDBC batch size: 15
12:54:58,410 INFO  [SettingsFactory] JDBC batch updates for versioned data: disabled
12:54:58,410 INFO  [SettingsFactory] Scrollable result sets: enabled
12:54:58,411 INFO  [SettingsFactory] JDBC3 getGeneratedKeys(): disabled
12:54:58,411 INFO  [SettingsFactory] Connection release mode: auto
12:54:58,411 INFO  [SettingsFactory] Default batch fetch size: 1
12:54:58,411 INFO  [SettingsFactory] Generate SQL with comments: disabled
12:54:58,411 INFO  [SettingsFactory] Order SQL updates by primary key: disabled
12:54:58,411 INFO  [SettingsFactory] Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory
12:54:58,411 INFO  [ASTQueryTranslatorFactory] Using ASTQueryTranslatorFactory
12:54:58,411 INFO  [SettingsFactory] Query language substitutions: {}
12:54:58,411 INFO  [SettingsFactory] Second-level cache: enabled
12:54:58,411 INFO  [SettingsFactory] Query cache: enabled
12:54:58,412 INFO  [SettingsFactory] Cache provider: org.hibernate.cache.EhCacheProvider
12:54:58,412 INFO  [SettingsFactory] Optimize cache for minimal puts: disabled
12:54:58,412 INFO  [SettingsFactory] Structured second-level cache entries: disabled
12:54:58,412 INFO  [SettingsFactory] Query cache factory: org.hibernate.cache.StandardQueryCacheFactory
12:54:58,412 INFO  [SettingsFactory] Statistics: disabled
12:54:58,412 INFO  [SettingsFactory] Deleted entity synthetic identifier rollback: disabled
12:54:58,412 INFO  [SettingsFactory] Default entity-mode: pojo
12:54:58,416 INFO  [SessionFactoryImpl] building session factory
12:54:58,421 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.model.portal.PortalObjectImpl]; using defaults.
12:54:58,547 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.model.portal.ObjectNode]; using defaults.
12:54:58,568 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.model.portal.ObjectNodeSecurityConstraint]; using defaults.
12:54:58,613 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.model.portal.PortalImpl.windowStates]; using defaults.
12:54:58,614 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.model.portal.PortalObjectImpl.declaredProperties]; using defaults.
12:54:58,615 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.model.portal.ObjectNodeSecurityConstraint.actions]; using defaults.
12:54:58,617 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.model.portal.ObjectNode.children]; using defaults.
12:54:58,619 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.model.portal.ObjectNode.securityConstraints]; using defaults.
12:54:58,619 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.model.portal.PortalImpl.modes]; using defaults.
12:54:58,650 INFO  [SessionFactoryObjectFactory] Factory name: java:/portal/PortalObjectSessionFactory
12:54:58,650 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:58,650 INFO  [SessionFactoryObjectFactory] Bound factory to JNDI name: java:/portal/PortalObjectSessionFactory
12:54:58,650 WARN  [SessionFactoryObjectFactory] InitialContext did not implement EventContext
12:54:58,652 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:58,653 INFO  [UpdateTimestampsCache] starting update timestamps cache at region: org.hibernate.cache.UpdateTimestampsCache
12:54:58,653 WARN  [EhCacheProvider] Could not find configuration [org.hibernate.cache.UpdateTimestampsCache]; using defaults.
12:54:58,653 INFO  [StandardQueryCache] starting query cache at region: org.hibernate.cache.StandardQueryCache
12:54:58,653 WARN  [EhCacheProvider] Could not find configuration [org.hibernate.cache.StandardQueryCache]; using defaults.
12:54:59,713 INFO  [HbmBinder] Mapping collection: org.jboss.portal.core.impl.portlet.state.PersistentState.entries -> JBP_PORTLET_STATE_ENTRY
12:54:59,714 INFO  [HbmBinder] Mapping collection: org.jboss.portal.core.impl.portlet.state.PersistentState.children -> JBP_PORTLET_STATE
12:54:59,719 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:59,719 INFO  [DatasourceConnectionProvider] Using datasource: java:PortalDS
12:54:59,719 INFO  [SettingsFactory] RDBMS: HSQL Database Engine, version: 1.8.0
12:54:59,719 INFO  [SettingsFactory] JDBC driver: HSQL Database Engine Driver, version: 1.8.0
12:54:59,720 INFO  [Dialect] Using dialect: org.hibernate.dialect.HSQLDialect
12:54:59,720 INFO  [TransactionFactoryFactory] Transaction strategy: org.hibernate.transaction.JTATransactionFactory
12:54:59,720 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:59,721 INFO  [TransactionManagerLookupFactory] instantiating TransactionManagerLookup: org.hibernate.transaction.JBossTransactionManagerLookup
12:54:59,721 INFO  [TransactionManagerLookupFactory] instantiated TransactionManagerLookup
12:54:59,721 INFO  [TransactionManagerLookupFactory] instantiating TransactionManagerLookup: org.hibernate.transaction.JBossTransactionManagerLookup
12:54:59,721 INFO  [TransactionManagerLookupFactory] instantiated TransactionManagerLookup
12:54:59,721 INFO  [SettingsFactory] Automatic flush during beforeCompletion(): enabled
12:54:59,721 INFO  [SettingsFactory] Automatic session close at end of transaction: disabled
12:54:59,721 INFO  [SettingsFactory] JDBC batch size: 15
12:54:59,721 INFO  [SettingsFactory] JDBC batch updates for versioned data: disabled
12:54:59,721 INFO  [SettingsFactory] Scrollable result sets: enabled
12:54:59,721 INFO  [SettingsFactory] JDBC3 getGeneratedKeys(): disabled
12:54:59,721 INFO  [SettingsFactory] Connection release mode: auto
12:54:59,721 INFO  [SettingsFactory] Default batch fetch size: 1
12:54:59,721 INFO  [SettingsFactory] Generate SQL with comments: disabled
12:54:59,721 INFO  [SettingsFactory] Order SQL updates by primary key: disabled
12:54:59,721 INFO  [SettingsFactory] Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory
12:54:59,721 INFO  [ASTQueryTranslatorFactory] Using ASTQueryTranslatorFactory
12:54:59,721 INFO  [SettingsFactory] Query language substitutions: {}
12:54:59,721 INFO  [SettingsFactory] Second-level cache: enabled
12:54:59,721 INFO  [SettingsFactory] Query cache: enabled
12:54:59,721 INFO  [SettingsFactory] Cache provider: org.hibernate.cache.EhCacheProvider
12:54:59,721 INFO  [SettingsFactory] Optimize cache for minimal puts: disabled
12:54:59,721 INFO  [SettingsFactory] Structured second-level cache entries: disabled
12:54:59,722 INFO  [SettingsFactory] Query cache factory: org.hibernate.cache.StandardQueryCacheFactory
12:54:59,722 INFO  [SettingsFactory] Statistics: disabled
12:54:59,722 INFO  [SettingsFactory] Deleted entity synthetic identifier rollback: disabled
12:54:59,722 INFO  [SettingsFactory] Default entity-mode: pojo
12:54:59,727 INFO  [SessionFactoryImpl] building session factory
12:54:59,734 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.portlet.state.PersistentStateEntry]; using defaults.
12:54:59,769 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.portlet.state.PersistentState]; using defaults.
12:54:59,795 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.portlet.state.PersistentState.children]; using defaults.
12:54:59,795 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.portlet.state.PersistentStateEntry.strings]; using defaults.
12:54:59,796 WARN  [EhCacheProvider] Could not find configuration [org.jboss.portal.core.impl.portlet.state.PersistentState.entries]; using defaults.
12:54:59,814 INFO  [SessionFactoryObjectFactory] Factory name: java:/portal/PortletSessionFactory
12:54:59,814 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:59,815 INFO  [SessionFactoryObjectFactory] Bound factory to JNDI name: java:/portal/PortletSessionFactory
12:54:59,815 WARN  [SessionFactoryObjectFactory] InitialContext did not implement EventContext
12:54:59,815 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:54:59,815 INFO  [UpdateTimestampsCache] starting update timestamps cache at region: org.hibernate.cache.UpdateTimestampsCache
12:54:59,815 WARN  [EhCacheProvider] Could not find configuration [org.hibernate.cache.UpdateTimestampsCache]; using defaults.
12:54:59,816 INFO  [StandardQueryCache] starting query cache at region: org.hibernate.cache.StandardQueryCache
12:54:59,816 WARN  [EhCacheProvider] Could not find configuration [org.hibernate.cache.StandardQueryCache]; using defaults.
12:55:02,580 INFO  [FacesConfigurator] Reading standard config org/apache/myfaces/resource/standard-faces-config.xml
12:55:02,683 INFO  [FacesConfigurator] Reading config jar:file:/usr/local/portal/server/default/tmp/deploy/tmp35816jsf-facelets.jar!/META-INF/faces-config.xml
12:55:02,692 INFO  [FacesConfigurator] Reading config jar:file:/usr/local/portal/server/default/tmp/deploy/tmp35833tomahawk.jar!/META-INF/faces-config.xml
12:55:02,784 INFO  [FacesConfigurator] Reading config /WEB-INF/faces-config.xml
12:55:02,835 ERROR [LocaleUtils] Locale name null or empty, ignoring
12:55:02,838 INFO  [RenderKitFactoryImpl] RenderKit with renderKitId 'HTML_BASIC' was replaced.
12:55:02,847 INFO  [MyFacesGenericPortlet] PortletContext '/usr/local/portal/server/default/./deploy/jboss-portal.sar/portal-core.war/' initialized.
12:55:03,031 INFO  [TomcatDeployer] deploy, ctxPath=/jmx-console, warUrl=.../deploy/jmx-console.war/
12:55:03,317 ERROR [URLDeploymentScanner] Incomplete Deployment listing:

--- Incompletely deployed packages ---
org.jboss.deployment.DeploymentInfo at a9b6c041 { url=file:/usr/local/portal/server/default/deploy/jboss-hibernate.deployer/ }
  deployer: org.jboss.deployment.SARDeployer at 1a116c9
  status: null
  state: FAILED
  watch: file:/usr/local/portal/server/default/deploy/jboss-hibernate.deployer/META-INF/jboss-service.xml
  altDD: null
  lastDeployed: 1167850460795
  lastModified: 1167844340000
  mbeans:

org.jboss.deployment.DeploymentInfo at e4299095 { url=file:/usr/local/portal/server/default/deploy/jboss-ws4ee.sar/ }
  deployer: org.jboss.deployment.SARDeployer at 1a116c9
  status: null
  state: FAILED
  watch: file:/usr/local/portal/server/default/deploy/jboss-ws4ee.sar/META-INF/jboss-service.xml
  altDD: null
  lastDeployed: 1167850468188
  lastModified: 1167844340000
  mbeans:


12:55:03,485 INFO  [Http11BaseProtocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080
12:55:03,881 INFO  [ChannelSocket] JK: ajp13 listening on /0.0.0.0:8009
12:55:03,903 INFO  [JkMain] Jk running ID=0 time=0/77  config=null
12:55:03,922 INFO  [Server] JBoss (MX MicroKernel) [4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000)] Started in 49s:412ms
12:55:52,837 INFO  [Server] Runtime shutdown hook called, forceHalt: true
12:55:52,838 INFO  [Server] JBoss SHUTDOWN: Undeploying all packages
12:55:52,841 INFO  [TomcatDeployer] undeploy, ctxPath=/jmx-console, warUrl=.../deploy/jmx-console.war/
12:55:52,937 WARN  [MainDeployer] undeploy 'file:/usr/local/portal/server/default/deploy/jmx-console.war/WEB-INF/' : package not deployed
12:55:53,023 INFO  [JCRCMS] Stopping JCR CMS
12:55:53,023 INFO  [JackrabbitJCRService] Shutting down repository
12:55:53,165 INFO  [JackrabbitJCRService] Repository shut down successfully
12:55:53,166 INFO  [SessionFactoryImpl] closing
12:55:53,167 INFO  [SessionFactoryObjectFactory] Unbinding factory from JNDI name: java:/portal/cms/CMSSessionFactory
12:55:53,167 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:55:53,168 INFO  [SessionFactoryObjectFactory] Unbound factory from JNDI name: java:/portal/cms/CMSSessionFactory
12:55:53,173 INFO  [SessionFactoryImpl] closing
12:55:53,174 INFO  [SessionFactoryObjectFactory] Unbinding factory from JNDI name: java:/portal/UserSessionFactory
12:55:53,174 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:55:53,175 INFO  [SessionFactoryObjectFactory] Unbound factory from JNDI name: java:/portal/UserSessionFactory
12:55:53,183 WARN  [ServerDeployer] Unknown setup url by main deployer provided by factory ObjectDeploymentFactory : file:/usr/local/portal/server/default/deploy/jboss-portal.sar/conf/data/default-object.xml
12:55:53,192 WARN  [MainDeployer] undeploy 'file:/usr/local/portal/server/default/deploy/jboss-portal.sar/portal-cms.war/WEB-INF/' : package not deployed
12:55:53,192 WARN  [MainDeployer] undeploy 'file:/usr/local/portal/server/default/deploy/jboss-portal.sar/portal-samples.war/WEB-INF/' : package not deployed
12:55:53,193 WARN  [MainDeployer] undeploy 'file:/usr/local/portal/server/default/deploy/jbossweb-tomcat55.sar/ROOT.war/WEB-INF/' : package not deployed
12:55:53,194 WARN  [MainDeployer] undeploy 'file:/usr/local/portal/server/default/deploy/management/console-mgr.sar/web-console.war/WEB-INF/' : package not deployed
12:55:53,200 WARN  [MainDeployer] undeploy 'file:/usr/local/portal/server/default/deploy/http-invoker.sar/invoker.war/WEB-INF/' : package not deployed
12:55:53,202 WARN  [MainDeployer] undeploy 'file:/usr/local/portal/server/default/deploy/jboss-portal.sar/portal-core.war/WEB-INF/' : package not deployed
12:55:53,202 WARN  [MainDeployer] undeploy 'file:/usr/local/portal/server/default/deploy/jboss-portal.sar/portal-server.war/WEB-INF/' : package not deployed
12:55:53,203 WARN  [MainDeployer] undeploy 'file:/usr/local/portal/server/default/deploy/jms/jbossmq-httpil.sar/jbossmq-httpil.war/WEB-INF/' : package not deployed
12:55:53,222 INFO  [SessionFactoryImpl] closing
12:55:53,222 INFO  [SessionFactoryObjectFactory] Unbinding factory from JNDI name: java:/portal/InstanceSessionFactory
12:55:53,223 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:55:53,223 INFO  [SessionFactoryObjectFactory] Unbound factory from JNDI name: java:/portal/InstanceSessionFactory
12:55:53,243 INFO  [SessionFactoryImpl] closing
12:55:53,243 INFO  [SessionFactoryObjectFactory] Unbinding factory from JNDI name: java:/portal/PortalObjectSessionFactory
12:55:53,243 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:55:53,244 INFO  [SessionFactoryObjectFactory] Unbound factory from JNDI name: java:/portal/PortalObjectSessionFactory
12:55:53,252 INFO  [SessionFactoryImpl] closing
12:55:53,252 INFO  [SessionFactoryObjectFactory] Unbinding factory from JNDI name: java:/portal/PortletSessionFactory
12:55:53,253 INFO  [NamingHelper] JNDI InitialContext properties:{}
12:55:53,253 INFO  [SessionFactoryObjectFactory] Unbound factory from JNDI name: java:/portal/PortletSessionFactory
12:55:53,255 INFO  [ConnectionFactoryBindingService] Unbound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=PortalDS' from JNDI name 'java:PortalDS'
12:55:53,360 INFO  [ConnectionFactoryBindingService] Unbound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' from JNDI name 'java:JmsXA'
12:55:53,404 INFO  [testTopic] Unbinding JNDI name: topic/testTopic
12:55:53,406 INFO  [securedTopic] Unbinding JNDI name: topic/securedTopic
12:55:53,408 INFO  [testDurableTopic] Unbinding JNDI name: topic/testDurableTopic
12:55:53,409 INFO  [testQueue] Unbinding JNDI name: queue/testQueue
12:55:53,416 INFO  [A] Unbinding JNDI name: queue/A
12:55:53,428 INFO  [B] Unbinding JNDI name: queue/B
12:55:53,429 INFO  [C] Unbinding JNDI name: queue/C
12:55:53,431 INFO  [D] Unbinding JNDI name: queue/D
12:55:53,432 INFO  [ex] Unbinding JNDI name: queue/ex
12:55:53,440 INFO  [DLQ] Unbinding JNDI name: queue/DLQ
12:55:53,448 INFO  [ConnectionFactoryBindingService] Unbound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' from JNDI name 'java:DefaultDS'
12:55:55,242 INFO  [HypersonicDatabase] Database standalone closed clean
12:55:55,387 INFO  [MailService] Mail service 'java:/Mail' removed from JNDI
12:55:55,413 INFO  [TomcatDeployer] undeploy, ctxPath=/web-console, warUrl=.../deploy/management/console-mgr.sar/web-console.war/
12:55:55,645 INFO  [ClientDeployer] Removing client ENC from: wsrp-client
12:55:55,705 INFO  [TomcatDeployer] undeploy, ctxPath=/jbossmq-httpil, warUrl=.../deploy/jms/jbossmq-httpil.sar/jbossmq-httpil.war/
12:55:55,752 INFO  [TomcatDeployer] undeploy, ctxPath=/jbossws, warUrl=.../tmp/deploy/tmp35864jbossws-exp.war/
12:55:55,788 INFO  [ServiceEndpointManager] WebService stopped: http://B-0359:8080/portal-wsrp/ServiceDescriptionService
12:55:55,789 INFO  [ServiceEndpointManager] WebService stopped: http://B-0359:8080/portal-wsrp/MarkupService
12:55:55,789 INFO  [ServiceEndpointManager] WebService stopped: http://B-0359:8080/portal-wsrp/RegistrationService
12:55:55,793 INFO  [ServiceEndpointManager] WebService stopped: http://B-0359:8080/portal-wsrp/PortletManagementService
12:55:55,793 INFO  [TomcatDeployer] undeploy, ctxPath=/portal-wsrp, warUrl=.../tmp/deploy/portal-wsrp-exp.war/
12:55:55,893 INFO  [TomcatDeployer] undeploy, ctxPath=/, warUrl=.../deploy/jbossweb-tomcat55.sar/ROOT.war/
12:55:55,944 INFO  [Http11BaseProtocol] Pausing Coyote HTTP/1.1 on http-0.0.0.0-8080
12:55:56,951 INFO  [StandardService] Stopping service jboss.web
12:55:57,074 INFO  [Http11BaseProtocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080
12:55:57,091 INFO  [TomcatDeployer] undeploy, ctxPath=/invoker, warUrl=.../deploy/http-invoker.sar/invoker.war/
12:55:57,101 INFO  [TomcatDeployer] undeploy, ctxPath=/portal-cms, warUrl=.../deploy/jboss-portal.sar/portal-cms.war/
12:55:57,108 INFO  [TomcatDeployer] undeploy, ctxPath=/portal-core, warUrl=.../deploy/jboss-portal.sar/portal-core.war/
12:55:57,121 INFO  [TomcatDeployer] undeploy, ctxPath=/portal-samples, warUrl=.../deploy/jboss-portal.sar/portal-samples.war/
12:55:57,125 INFO  [TomcatDeployer] undeploy, ctxPath=/portal, warUrl=.../deploy/jboss-portal.sar/portal-server.war/
12:55:57,214 WARN  [MainDeployer] undeploy 'file:/usr/local/portal/server/default/deploy/jboss-portal.sar/portal-wsrp.sar/default-wsrp.xml' : package not deployed
12:55:58,579 INFO  [Server] Shutdown complete
Shutdown complete
Halting VM


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

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


From do-not-reply at jboss.com  Wed Jan  3 14:22:37 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Wed, 3 Jan 2007 14:22:37 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Serialization
	Compatibility Tests
Message-ID: <16420658.1167852157176.JavaMail.jboss@colo-br-02.atl.jboss.com>

"pavel.tsekov at redhat.com" wrote : 
  | So, if I got it right this means that it is safe to exclude all jgroups classes excepth "*Exception" when testing agains 1.4.0 GA ?
  | 

Yes

"pavel.tsekov at redhat.com" wrote : 
  | Does 1.4.x support region-based marshalling i.e. for backward compatibility with older versions i.e. is it possible to run 1.4.x with 1.3.x so that they'll exchange java serialized objects ?
  | 

Yes.  This is how backward compat is maintained, and in such a case, the same version of JGroups needs to be used on both nodes, so svuid problems on the JGroups level goes away.

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

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


From do-not-reply at jboss.com  Wed Jan  3 14:26:27 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Wed, 3 Jan 2007 14:26:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Serialization
	Compatibility Tests
Message-ID: <13749064.1167852387102.JavaMail.jboss@colo-br-02.atl.jboss.com>

"ryan.campbell at jboss.com" wrote : Manik,
  | 
  | Where should we document this test case? A readme in the src/etc folder? Somewhere else?
  | 
  | Thanks,
  | Ryan

For JUnit tests, I normally have a list of "known failures" as a set of test excludes in build.xml, each exclude listed with a comment pointing to the relevant JIRA task.  These excludes are passed to JUnit tasks so these tests are excluded from reports (such as the cruise control target).

Perhaps a similar approach could be adopted here?  Better still, maybe this could be an external properties file that build.xml reads and excludes?  We could then use the same external file for known JUnit excludes as well?

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

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


From do-not-reply at jboss.com  Wed Jan  3 14:27:25 2007
From: do-not-reply at jboss.com (pavel.tsekov@redhat.com)
Date: Wed, 3 Jan 2007 14:27:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Serialization
	Compatibility Tests
Message-ID: <7970262.1167852445972.JavaMail.jboss@colo-br-02.atl.jboss.com>

Thanks for the explanation Manik! :) I'll adjust the code accordingly.

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

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


From do-not-reply at jboss.com  Wed Jan  3 14:29:11 2007
From: do-not-reply at jboss.com (anil.saldhana@jboss.com)
Date: Wed, 3 Jan 2007 14:29:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: EJB References
Message-ID: <9623145.1167852551114.JavaMail.jboss@colo-br-02.atl.jboss.com>

If a jar contains a sar, shouldn't the sar be deployed first?

If you run the 
anonymous wrote : 
  | ant -Dtest=org.jboss.test.security.test.EJBSpecUnitTestCase one-test
  | 

It seems the ejb deployment which is contained in the jar is happening before the queues that need to be created, whose defs are contained inside the embedded sar.

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

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


From do-not-reply at jboss.com  Wed Jan  3 15:06:50 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Wed, 3 Jan 2007 15:06:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <24387661.1167854810945.JavaMail.jboss@colo-br-02.atl.jboss.com>

i just added an if-then-else in the code with a check for the existence of a task in the start-state.

all tests succeed.  so now when there is no start task, createStartTaskInstance will return null in case there is no start task.

just checked it in.  hopefully it is still in time for you to check it out

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

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


From do-not-reply at jboss.com  Wed Jan  3 15:27:04 2007
From: do-not-reply at jboss.com (adamw)
Date: Wed, 3 Jan 2007 15:27:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Problems compiling
	JBoss Labs
Message-ID: <26549141.1167856024147.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hello,
I have fixed the build to work with the new repositories.
Some information on creating and managing projects can be found here:
http://labs.jboss.com/wiki/Main
in sections about .xml files that should be placed in CMS.

Have you downloaded and installed the CMS template?

About integration:
we have currently very good wiki, a simple blog viewer and you can use jboss forums; a new blog, and some integration w/ cc & jira will be included in labs 2.0, which is scheduled for the end of february.

-- 
Regards,
Adam Warski



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

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


From do-not-reply at jboss.com  Wed Jan  3 15:28:17 2007
From: do-not-reply at jboss.com (adamw)
Date: Wed, 3 Jan 2007 15:28:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Problems Deploying
	JBoss Labs
Message-ID: <29329875.1167856097649.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hello,
it looks like there is a problem with some basic jboss services - like hibernate. Have you changed anything in the configuration of the AS, installed from the Labs repository?
Are you starting the AS in the "all" configuration?

-- 
Regards,
Ada Warski

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

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


From do-not-reply at jboss.com  Wed Jan  3 16:17:44 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Wed, 3 Jan 2007 16:17:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	Array interception needed for jboss cache
Message-ID: <20196414.1167859064194.JavaMail.jboss@colo-br-02.atl.jboss.com>

Please take a look at the tests

1) Yes, this is done in AOPArrayTestCase

2) & 3)By querying the ArrayRegistry, you get the full path to the array as it is referenced - with the "root" instance (or the class in the case of a static field), field name, and if a nested array the sub elements.

ArrayReferenceTestCase has examples of this, but a quick summary here: 

  | class POJOx{
  |    int[] array;
  | }
  | 
  | class POJOy{
  |    static Object[] array = new Object[][]{new Object[3]}, new Object[3], new Object[3]}};
  | }
  | 
  | int[] arr = new int[]{1,2,3};
  | POJOx x1 = new POJOx(); //POJOx at 1111
  | POJOx x2 = new POJOx(); //POJOx at 2222
  | x1.array = arr;
  | x2.array = arr;
  | POJOy.array[1][2] = arr;
  | 

If we now do

  | List<ArrayReference> refs = ArrayRegistry.getInstance().getArrayOwners(arr);
  | 

We get the following 3 array references for arr:


  | ArrayReference-1: root=POJOx at 1111; rootField="array"; nestedIndices=null
  | ArrayReference-2: root=POJOx at 2222; rootField="array"; nestedIndices=null
  | ArrayReference-3: root=POJOy.class; rootField="array"; nestedIndeces=[1,2]
  | 

4) Not sure what you mean by "Region", but with the reference counting you should be able to determine if there is only one reference or if more than one reference to use the special reference area in the cache. One thing which might be an issue is that I update the references in the woven code before creating an invocation

5) Yes, the ArrayElementInvocation base class getTargetObject() method returns the array

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

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


From do-not-reply at jboss.com  Wed Jan  3 17:05:49 2007
From: do-not-reply at jboss.com (phillips4jc)
Date: Wed, 3 Jan 2007 17:05:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Problems compiling
	JBoss Labs
Message-ID: <7410880.1167861949598.JavaMail.jboss@colo-br-02.atl.jboss.com>

I updated tio the latest source code, deleted the repository to make sure we are using the right jars.  I get this error.  I will download manually to see if there are others.

Attempting to download commons-jelly-tags-log-20030211.142821.jar.
Error retrieving artifact from [ http://www.ibiblio.org/maven/commons-jelly/jars/commons-jelly-tags-log-20030211.142821.jar]: java.io.IOException: Unknown error downloading; status code was: 301
WARNING: Failed to download commons-jelly-tags-log-20030211.142821.jar.
Attempting to download commons-jelly-tags-velocity-20030303.205659.jar.
Error retrieving artifact from [ http://www.ibiblio.org/maven/commons-jelly/jars/commons-jelly-tags-velocity-20030303.205659.jar]: java.io.IOException: Unknown error downloading; status code was: 301
WARNING: Failed to download commons-jelly-tags-velocity-20030303.205659.jar.
The build cannot continue because of the following unsatisfied dependencies:


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

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


From do-not-reply at jboss.com  Wed Jan  3 17:16:21 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Wed, 3 Jan 2007 17:16:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover refactoring
Message-ID: <11737414.1167862581522.JavaMail.jboss@colo-br-02.atl.jboss.com>

I just want to add two points that were also part of the refactoring. 

- performFailover was made part of ClientConnectionDelegate (public method)
- There is one instance of the Valve per Delegate. That means when a failure happens we will have to close multiple valves.

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

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


From do-not-reply at jboss.com  Wed Jan  3 17:40:34 2007
From: do-not-reply at jboss.com (phillips4jc)
Date: Wed, 3 Jan 2007 17:40:34 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Problems compiling
	JBoss Labs
Message-ID: <765813.1167864034258.JavaMail.jboss@colo-br-02.atl.jboss.com>

Disregard previous post.  We had an error in the build.properties file that was overriding the project.properties setting for the remote repo.cd.

However, it really is missing gwt-dev-linux.jar.  In fact there is a file there saying put linux version here.

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

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


From do-not-reply at jboss.com  Wed Jan  3 17:47:23 2007
From: do-not-reply at jboss.com (phillips4jc)
Date: Wed, 3 Jan 2007 17:47:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Problems compiling
	JBoss Labs
Message-ID: <14568054.1167864443857.JavaMail.jboss@colo-br-02.atl.jboss.com>

After building successfully, I get an OutOfMemoryError  Here is the output

[root at B-0359 bin]# ./run.sh -c all
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /usr/local/portal

  JAVA: /usr/lib/jdk1.5.0_09//bin/java

  JAVA_OPTS: -Djava.security.auth.login.config=../conf/jaas.conf -javaagent:pluggable-instrumentor.jar -Dprogram.name=run.sh

  CLASSPATH: /usr/local/portal/bin/run.jar:/usr/lib/jdk1.5.0_09//lib/tools.jar

=========================================================================

16:37:32,077 INFO  [Server] Starting JBoss (MX MicroKernel)...
16:37:32,079 INFO  [Server] Release ID: JBoss [Zion] 4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000)
16:37:32,081 INFO  [Server] Home Dir: /usr/local/portal
16:37:32,081 INFO  [Server] Home URL: file:/usr/local/portal/
16:37:32,082 INFO  [Server] Patch URL: null
16:37:32,082 INFO  [Server] Server Name: all
16:37:32,083 INFO  [Server] Server Home Dir: /usr/local/portal/server/all
16:37:32,083 INFO  [Server] Server Home URL: file:/usr/local/portal/server/all/
16:37:32,083 INFO  [Server] Server Log Dir: /usr/local/portal/server/all/log
16:37:32,083 INFO  [Server] Server Temp Dir: /usr/local/portal/server/all/tmp
16:37:32,084 INFO  [Server] Root Deployment Filename: jboss-service.xml
16:37:32,674 INFO  [ServerInfo] Java version: 1.5.0_09,Sun Microsystems Inc.
16:37:32,675 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.5.0_09-b01,Sun Microsystems Inc.
16:37:32,675 INFO  [ServerInfo] OS-System: Linux 2.6.9-42.0.3.EL,i386
16:37:33,502 INFO  [Server] Core system initialized
16:37:37,033 INFO  [WebService] Using RMI server codebase: http://B-0359:8083/
16:37:37,071 INFO  [Log4jService$URLWatchTimerTask] Configuring from URL: resource:log4j.xml
16:37:37,389 INFO  [NamingService] JNDI bootstrap JNP=/0.0.0.0:1099, RMI=/0.0.0.0:1098, backlog=50, no client SocketFactory, Server SocketFactory=class org.jboss.net.sockets.DefaultSocketFactory
16:37:39,755 INFO  [SocketServerInvoker] Invoker started for locator: InvokerLocator [socket://127.0.0.1:3873/]
16:37:41,552 INFO  [AspectDeployer] Deployed AOP: file:/usr/local/portal/server/all/deploy/shotoku-aop.aop
16:37:41,759 INFO  [AspectDeployer] Deployed AOP: file:/usr/local/portal/server/all/deploy/ejb3-interceptors-aop.xml
16:37:46,828 INFO  [AspectDeployer] Deployed AOP: file:/usr/local/portal/server/all/deploy/jboss-portal.sar/portal-aop.xml
16:37:50,854 ERROR [STDERR] [warn] AOP Instrumentor failed to transform org.jboss.forge.common.projects.Projects
16:37:50,855 ERROR [STDERR] org.jboss.aop.instrument.TransformationException: Failed to aspectize class org.jboss.forge.common.projects.Projects.  Could not find class it references org.jboss.forge.common.projects.ProjectDescriptor  It may not be in your classpath and you may not be getting field and constructor weaving for this class.
16:37:50,856 ERROR [STDERR]     at org.jboss.aop.instrument.Instrumentor.convertReferences(Instrumentor.java:619)
16:37:50,856 ERROR [STDERR]     at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:673)
16:37:50,856 ERROR [STDERR]     at org.jboss.aop.AspectManager.translate(AspectManager.java:970)
16:37:50,856 ERROR [STDERR]     at org.jboss.aop.AspectManager.transform(AspectManager.java:882)
16:37:50,856 ERROR [STDERR]     at org.jboss.aop.standalone.AOPTransformer.aspectTransform(AOPTransformer.java:88)
16:37:50,856 ERROR [STDERR]     at org.jboss.aop.standalone.AOPTransformer.transform(AOPTransformer.java:75)
16:37:50,857 ERROR [STDERR]     at sun.instrument.TransformerManager.transform(TransformerManager.java:122)
16:37:50,857 ERROR [STDERR]     at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:155)
16:37:50,857 ERROR [STDERR]     at java.lang.ClassLoader.defineClass1(Native Method)
16:37:50,857 ERROR [STDERR]     at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
16:37:50,857 ERROR [STDERR]     at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
16:37:50,857 ERROR [STDERR]     at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
16:37:50,857 ERROR [STDERR]     at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
16:37:50,857 ERROR [STDERR]     at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
16:37:50,858 ERROR [STDERR]     at java.security.AccessController.doPrivileged(Native Method)
16:37:50,858 ERROR [STDERR]     at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
16:37:50,858 ERROR [STDERR]     at org.jboss.mx.loading.RepositoryClassLoader.findClassLocally(RepositoryClassLoader.java:672)
16:37:50,858 ERROR [STDERR]     at org.jboss.mx.loading.RepositoryClassLoader.findClass(RepositoryClassLoader.java:652)
16:37:50,858 ERROR [STDERR]     at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
16:37:50,858 ERROR [STDERR]     at org.jboss.mx.loading.RepositoryClassLoader.loadClassLocally(RepositoryClassLoader.java:190)
16:37:50,858 ERROR [STDERR]     at org.jboss.mx.loading.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:131)
16:37:50,858 ERROR [STDERR]     at org.jboss.mx.loading.LoadMgr3.nextTask(LoadMgr3.java:399)
16:37:50,859 ERROR [STDERR]     at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:517)
16:37:50,859 ERROR [STDERR]     at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:405)
16:37:50,859 ERROR [STDERR]     at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
16:37:50,859 ERROR [STDERR]     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
16:37:50,859 ERROR [STDERR]     at java.lang.Class.getDeclaredMethods0(Native Method)
16:37:50,859 ERROR [STDERR]     at java.lang.Class.privateGetDeclaredMethods(Class.java:2395)
16:37:50,860 ERROR [STDERR]     at java.lang.Class.getDeclaredMethods(Class.java:1763)
16:37:50,860 ERROR [STDERR]     at org.jboss.portal.common.mx.JavaBeanModelMBeanBuilder.(JavaBeanModelMBeanBuilder.java:89)
16:37:50,860 ERROR [STDERR]     at org.jboss.portal.common.mx.JavaBeanModelMBeanBuilder.build(JavaBeanModelMBeanBuilder.java:287)
16:37:50,860 ERROR [STDERR]     at org.jboss.portal.common.system.JBossServiceModelMBean.(JBossServiceModelMBean.java:76)
16:37:50,860 ERROR [STDERR]     at sun.reflect.GeneratedConstructorAccessor11.newInstance(Unknown Source)
16:37:50,860 ERROR [STDERR]     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
16:37:50,860 ERROR [STDERR]     at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
16:37:50,861 ERROR [STDERR]     at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:1233)
16:37:50,861 ERROR [STDERR]     at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:286)
16:37:50,861 ERROR [STDERR]     at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:344)
16:37:50,861 ERROR [STDERR]     at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
16:37:50,861 ERROR [STDERR]     at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449)
16:37:50,861 ERROR [STDERR]     at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
16:37:50,861 ERROR [STDERR]     at org.jboss.system.ServiceController.install(ServiceController.java:226)
16:37:50,861 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
16:37:50,861 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
16:37:50,862 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:37:50,862 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:585)
16:37:50,862 ERROR [STDERR]     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:37:50,863 ERROR [STDERR]     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:37:50,863 ERROR [STDERR]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
16:37:50,863 ERROR [STDERR]     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:37:50,863 ERROR [STDERR]     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:37:50,863 ERROR [STDERR]     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
16:37:50,863 ERROR [STDERR]     at $Proxy4.install(Unknown Source)
16:37:50,864 ERROR [STDERR]     at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
16:37:50,865 ERROR [STDERR]     at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
16:37:50,865 ERROR [STDERR]     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
16:37:50,865 ERROR [STDERR]     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
16:37:50,865 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
16:37:50,865 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
16:37:50,865 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:37:50,866 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:585)
16:37:50,866 ERROR [STDERR]     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:37:50,866 ERROR [STDERR]     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:37:50,866 ERROR [STDERR]     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
16:37:50,866 ERROR [STDERR]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
16:37:50,866 ERROR [STDERR]     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
16:37:50,866 ERROR [STDERR]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
16:37:50,866 ERROR [STDERR]     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:37:50,866 ERROR [STDERR]     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:37:50,867 ERROR [STDERR]     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
16:37:50,867 ERROR [STDERR]     at $Proxy8.deploy(Unknown Source)
16:37:50,867 ERROR [STDERR]     at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
16:37:50,867 ERROR [STDERR]     at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
16:37:50,867 ERROR [STDERR]     at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
16:37:50,867 ERROR [STDERR]     at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
16:37:50,867 ERROR [STDERR]     at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
16:37:50,868 ERROR [STDERR]     at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
16:37:50,868 ERROR [STDERR]     at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
16:37:50,868 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:37:50,869 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:585)
16:37:50,869 ERROR [STDERR]     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:37:50,869 ERROR [STDERR]     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:37:50,869 ERROR [STDERR]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
16:37:50,869 ERROR [STDERR]     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:37:50,869 ERROR [STDERR]     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:37:50,869 ERROR [STDERR]     at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
16:37:50,870 ERROR [STDERR]     at $Proxy0.start(Unknown Source)
16:37:50,870 ERROR [STDERR]     at org.jboss.system.ServiceController.start(ServiceController.java:417)
16:37:50,870 ERROR [STDERR]     at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
16:37:50,870 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:37:50,870 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:585)
16:37:50,870 ERROR [STDERR]     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:37:50,871 ERROR [STDERR]     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:37:50,871 ERROR [STDERR]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
16:37:50,871 ERROR [STDERR]     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:37:50,871 ERROR [STDERR]     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:37:50,871 ERROR [STDERR]     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
16:37:50,871 ERROR [STDERR]     at $Proxy4.start(Unknown Source)
16:37:50,871 ERROR [STDERR]     at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
16:37:50,871 ERROR [STDERR]     at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
16:37:50,872 ERROR [STDERR]     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
16:37:50,872 ERROR [STDERR]     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
16:37:50,872 ERROR [STDERR]     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
16:37:50,872 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
16:37:50,872 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
16:37:50,872 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:37:50,872 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:585)
16:37:50,872 ERROR [STDERR]     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:37:50,872 ERROR [STDERR]     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:37:50,873 ERROR [STDERR]     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
16:37:50,873 ERROR [STDERR]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
16:37:50,873 ERROR [STDERR]     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
16:37:50,873 ERROR [STDERR]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
16:37:50,873 ERROR [STDERR]     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:37:50,873 ERROR [STDERR]     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:37:50,873 ERROR [STDERR]     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
16:37:50,873 ERROR [STDERR]     at $Proxy5.deploy(Unknown Source)
16:37:50,873 ERROR [STDERR]     at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
16:37:50,874 ERROR [STDERR]     at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
16:37:50,874 ERROR [STDERR]     at org.jboss.Main.boot(Main.java:200)
16:37:50,874 ERROR [STDERR]     at org.jboss.Main$1.run(Main.java:464)
16:37:50,874 ERROR [STDERR]     at java.lang.Thread.run(Thread.java:595)
16:37:57,942 INFO  [SubscriptionManager] Bound event dispatcher to java:/EventDispatcher
16:38:08,957 INFO  [Ejb3Deployment] EJB3 deployment time took: 814
16:38:09,191 INFO  [JmxKernelAbstraction] installing MBean: jboss.j2ee:jar=shotoku-base.ejb3,name=ShotokuServiceImpl,service=EJB3 with dependencies:
16:38:09,624 INFO  [EJBContainer] STARTED EJB: org.jboss.shotoku.service.ShotokuServiceImpl ejbName: ShotokuServiceImpl
16:38:09,880 INFO  [AdministratedService] Creating Shotoku service...
16:38:10,416 INFO  [ContentManager] Added content manager: default, org.jboss.shotoku.svn.SvnContentManager
16:38:10,417 INFO  [AdministratedService] ContentManager setup completed.  Getting the default service timer interval...
16:38:10,417 INFO  [AdministratedService] Shotoku service created.
16:38:10,421 INFO  [AdministratedService] Starting Shotoku service...
16:38:10,421 INFO  [AdministratedService] Starting main update thread...
16:38:10,430 INFO  [AdministratedService] Starting update threads...
16:38:10,435 INFO  [AdministratedService] Update thread count set to: 10.
16:38:10,436 INFO  [AdministratedService] Reseting keys during update in cache items...
16:38:10,436 INFO  [AdministratedService] Shotoku service started.
16:38:10,438 INFO  [EJB3Deployer] Deployed: file:/usr/local/portal/server/all/deploy/shotoku.sar/shotoku-base.ejb3
16:38:11,996 INFO  [SnmpAgentService] SNMP agent going active
16:38:12,334 INFO  [AspectDeployer] Deployed AOP: file:/usr/local/portal/server/all/deploy/tc5-cluster.sar/tc5-cluster.aop
16:38:13,127 INFO  [TreeCache] setting cluster properties from xml to: UDP(down_thread=false;enable_bundling=true;ip_ttl=2;loopback=false;max_bundle_size=64000;max_bundle_timeout=30;mcast_addr=230.1.2.7;mcast_port=45577;mcast_recv_buf_size=25000000;mcast_send_buf_size=640000;ucast_recv_buf_size=20000000;ucast_send_buf_size=640000;up_thread=false;use_incoming_packet_handler=true;use_outgoing_packet_handler=true):PING(down_thread=false;num_initial_members=3;timeout=2000;up_thread=false):MERGE2(down_thread=false;max_interval=100000;min_interval=20000;up_thread=false):FD(down_thread=false;max_tries=5;shun=true;timeout=2500;up_thread=false):VERIFY_SUSPECT(down_thread=false;timeout=1500;up_thread=false):pbcast.NAKACK(discard_delivered_msgs=true;down_thread=false;gc_lag=50;max_xmit_size=60000;retransmit_timeout=100,200,300,600,1200,2400,4800;up_thread=false;use_mcast_xmit=false):UNICAST(down_thread=false;timeout=300,600,1200,2400,3600;up_thread=false):pbcast.STABLE(desired_avg_gossip=50000;down_thread=false;max_bytes=2100000;stability_delay=1000;up_thread=false):pbcast.GMS(down_thread=false;join_retry_timeout=2000;join_timeout=3000;print_local_addr=true;shun=true;up_thread=false):FC(down_thread=false;max_credits=10000000;min_threshold=0.20;up_thread=false):FRAG2(down_thread=false;frag_size=60000;up_thread=false):pbcast.STATE_TRANSFER(down_thread=false;up_thread=false)
16:38:13,177 INFO  [TreeCache] interceptor chain is:
class org.jboss.cache.interceptors.CallInterceptor
class org.jboss.cache.interceptors.PessimisticLockInterceptor
class org.jboss.cache.interceptors.UnlockInterceptor
class org.jboss.cache.interceptors.ReplicationInterceptor
16:38:13,178 INFO  [TreeCache] cache mode is REPL_ASYNC
16:38:15,952 INFO  [STDOUT] 
-------------------------------------------------------
GMS: address is localhost:32845
-------------------------------------------------------
16:38:18,183 INFO  [TreeCache] viewAccepted(): [localhost:32845|0] [localhost:32845]
16:38:18,215 INFO  [TreeCache] my local address is localhost:32845
16:38:18,222 INFO  [TreeCache] new cache is null (may be first member in cluster)
16:38:18,222 INFO  [TreeCache] state could not be retrieved (must be first member in group)
16:38:18,222 INFO  [TreeCache] Cache is started!!
16:38:18,684 INFO  [Embedded] Catalina naming disabled
16:38:18,918 INFO  [ClusterRuleSetFactory] Unable to find a cluster rule set in the classpath. Will load the default rule set.
16:38:18,921 INFO  [ClusterRuleSetFactory] Unable to find a cluster rule set in the classpath. Will load the default rule set.
16:38:19,849 INFO  [Http11BaseProtocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080
16:38:19,859 INFO  [Catalina] Initialization processed in 938 ms
16:38:19,859 INFO  [StandardService] Starting service jboss.web
16:38:19,871 INFO  [StandardEngine] Starting Servlet Engine: Apache Tomcat/5.5.17
16:38:19,997 INFO  [StandardHost] XML validation disabled
16:38:20,052 INFO  [Catalina] Server startup in 193 ms
16:38:20,593 INFO  [TomcatDeployer] deploy, ctxPath=/invoker, warUrl=.../deploy/httpha-invoker.sar/invoker.war/
16:38:21,379 INFO  [WebappLoader] Dual registration of jndi stream handler: factory already defined
16:38:22,408 INFO  [TomcatDeployer] deploy, ctxPath=/portal-cms, warUrl=.../deploy/jboss-portal.sar/portal-cms.war/
16:38:22,677 INFO  [TomcatDeployer] deploy, ctxPath=/portal-core, warUrl=.../deploy/jboss-portal.sar/portal-core.war/
16:38:24,214 INFO  [FacesConfigurator] Reading standard config org/apache/myfaces/resource/standard-faces-config.xml
16:38:24,442 INFO  [FacesConfigurator] Reading config jar:file:/usr/local/portal/server/all/tmp/deploy/tmp62208jsf-facelets.jar!/META-INF/faces-config.xml
16:38:24,458 INFO  [FacesConfigurator] Reading config jar:file:/usr/local/portal/server/all/tmp/deploy/tmp62226tomahawk.jar!/META-INF/faces-config.xml
16:38:24,556 INFO  [FacesConfigurator] Reading config jar:file:/usr/local/portal/server/all/tmp/deploy/tmp62243tomahawk.jar!/META-INF/faces-config.xml
16:38:24,637 INFO  [FacesConfigurator] Reading config /WEB-INF/faces-config.xml
16:38:25,096 ERROR [LocaleUtils] Locale name null or empty, ignoring
16:38:27,345 INFO  [StartupServletContextListener] ServletContext '/usr/local/portal/server/all/./deploy/jboss-portal.sar/portal-core.war/' initialized.
16:38:27,586 INFO  [TomcatDeployer] deploy, ctxPath=/portal, warUrl=.../deploy/jboss-portal.sar/portal-server.war/
16:38:28,149 INFO  [TomcatDeployer] deploy, ctxPath=/jbossws, warUrl=.../tmp/deploy/tmp62257jbossws-exp.war/
16:38:28,453 INFO  [TomcatDeployer] deploy, ctxPath=/juddi, warUrl=.../deploy/juddi-service.sar/juddiws.war/
16:38:28,635 INFO  [RegistryServlet] Loading jUDDI configuration.
16:38:28,636 INFO  [RegistryServlet] Resources loaded from: /WEB-INF/juddi.properties
16:38:28,637 INFO  [RegistryServlet] Initializing jUDDI components.
16:38:31,150 INFO  [Ejb3Deployment] EJB3 deployment time took: 107
16:38:31,221 INFO  [JmxKernelAbstraction] installing MBean: jboss.j2ee:jar=forge-service.ejb3,name=ForgeService,service=EJB3 with dependencies:
16:38:31,221 INFO  [JmxKernelAbstraction]       shotoku:service=shotoku
16:38:31,279 INFO  [EJBContainer] STARTED EJB: org.jboss.forge.service.ForgeService ejbName: ForgeService
16:38:31,326 INFO  [AdministratedService] Creating Forge service...
16:38:32,620 INFO  [ForgeService] Forge service created, with timer interval: 30000
16:38:32,621 INFO  [AdministratedService] Starting Forge service...
16:38:32,622 INFO  [AdministratedService] Forge service started.
16:38:32,622 INFO  [EJB3Deployer] Deployed: file:/usr/local/portal/server/all/deploy/w-jboss-forge.sar/forge-service.ejb3
16:38:33,602 INFO  [DefaultPartition] Initializing
16:38:33,764 INFO  [STDOUT] 
-------------------------------------------------------
GMS: address is localhost:32848 (additional data: 14 bytes)
-------------------------------------------------------
16:38:35,779 INFO  [DefaultPartition] Number of cluster members: 1
16:38:35,779 INFO  [DefaultPartition] Other members: 0
16:38:35,779 INFO  [DefaultPartition] Fetching state (will wait for 30000 milliseconds):
16:38:35,779 INFO  [DefaultPartition] New cluster view for partition DefaultPartition (id: 0, delta: 0) : [127.0.0.1:1099]
16:38:35,800 INFO  [DefaultPartition] I am (127.0.0.1:1099) received membershipChanged event:
16:38:35,801 INFO  [DefaultPartition] Dead members: 0 ([])
16:38:35,801 INFO  [DefaultPartition] New Members : 0 ([])
16:38:35,801 INFO  [DefaultPartition] All Members : 1 ([127.0.0.1:1099])
16:38:35,998 INFO  [HANamingService] Started ha-jndi bootstrap jnpPort=1100, backlog=50, bindAddress=/0.0.0.0
16:38:36,017 INFO  [DetachedHANamingService$AutomaticDiscovery] Listening on 0.0.0.0/0.0.0.0:1102, group=230.0.0.4, HA-JNDI address=127.0.0.1:1100
16:38:38,520 INFO  [TomcatDeployer] deploy, ctxPath=/jbossmq-httpil, warUrl=.../deploy-hasingleton/jms/jbossmq-httpil.sar/jbossmq-httpil.war/
16:38:39,166 INFO  [TreeCache] setting cluster properties from xml to: UDP(ip_mcast=true;ip_ttl=64;loopback=false;mcast_addr=228.1.2.3;mcast_port=45551;mcast_recv_buf_size=80000;mcast_send_buf_size=150000;ucast_recv_buf_size=80000;ucast_send_buf_size=150000):PING(down_thread=false;num_initial_members=3;timeout=2000;up_thread=false):MERGE2(max_interval=20000;min_interval=10000):FD(down_thread=true;shun=true;up_thread=true):VERIFY_SUSPECT(down_thread=false;timeout=1500;up_thread=false):pbcast.NAKACK(down_thread=false;gc_lag=50;max_xmit_size=8192;retransmit_timeout=600,1200,2400,4800;up_thread=false):UNICAST(down_thread=false;min_threshold=10;timeout=600,1200,2400;window_size=100):pbcast.STABLE(desired_avg_gossip=20000;down_thread=false;up_thread=false):FRAG(down_thread=false;frag_size=8192;up_thread=false):pbcast.GMS(join_retry_timeout=2000;join_timeout=5000;print_local_addr=true;shun=true):pbcast.STATE_TRANSFER(down_thread=false;up_thread=false)
16:38:39,244 INFO  [TreeCache] setEvictionPolicyConfig(): [config: null]
16:38:39,262 WARN  [TreeCache] No transaction manager lookup class has been defined. Transactions cannot be used
16:38:39,299 INFO  [TreeCache] interceptor chain is:
class org.jboss.cache.interceptors.CallInterceptor
class org.jboss.cache.interceptors.PessimisticLockInterceptor
class org.jboss.cache.interceptors.CacheLoaderInterceptor
class org.jboss.cache.interceptors.UnlockInterceptor
class org.jboss.cache.interceptors.ReplicationInterceptor
class org.jboss.cache.interceptors.CacheStoreInterceptor
16:38:39,366 INFO  [TreeCache] cache mode is REPL_SYNC
16:38:39,386 INFO  [STDOUT] 
-------------------------------------------------------
GMS: address is localhost:32851
-------------------------------------------------------
16:38:41,389 INFO  [TreeCache] my local address is localhost:32851
16:38:41,389 INFO  [TreeCache] state could not be retrieved (must be first member in group)
16:38:41,390 INFO  [LRUPolicy] Starting eviction policy using the provider: org.jboss.ejb3.cache.tree.StatefulEvictionPolicy
16:38:41,390 INFO  [LRUPolicy] Starting a eviction timer with wake up interval of (secs) 1
16:38:41,390 INFO  [TreeCache] viewAccepted(): [localhost:32851|0] [localhost:32851]
16:38:41,390 INFO  [TreeCache] new cache is null (may be first member in cluster)
16:38:41,391 INFO  [TreeCache] Cache is started!!
16:38:41,488 INFO  [TreeCache] setting cluster properties from xml to: UDP(ip_mcast=true;ip_ttl=2;loopback=false;mcast_addr=228.1.2.3;mcast_port=43333;mcast_recv_buf_size=80000;mcast_send_buf_size=150000;ucast_recv_buf_size=80000;ucast_send_buf_size=150000):PING(down_thread=false;num_initial_members=3;timeout=2000;up_thread=false):MERGE2(max_interval=20000;min_interval=10000):FD(down_thread=true;shun=true;up_thread=true):VERIFY_SUSPECT(down_thread=false;timeout=1500;up_thread=false):pbcast.NAKACK(down_thread=false;gc_lag=50;max_xmit_size=8192;retransmit_timeout=600,1200,2400,4800;up_thread=false):UNICAST(down_thread=false;min_threshold=10;timeout=600,1200,2400;window_size=100):pbcast.STABLE(desired_avg_gossip=20000;down_thread=false;up_thread=false):FRAG(down_thread=false;frag_size=8192;up_thread=false):pbcast.GMS(join_retry_timeout=2000;join_timeout=5000;print_local_addr=true;shun=true):pbcast.STATE_TRANSFER(down_thread=false;up_thread=false)
16:38:41,516 INFO  [TreeCache] setEvictionPolicyConfig(): [config: null]
16:38:41,542 INFO  [TreeCache] interceptor chain is:
class org.jboss.cache.interceptors.CallInterceptor
class org.jboss.cache.interceptors.PessimisticLockInterceptor
class org.jboss.cache.interceptors.UnlockInterceptor
class org.jboss.cache.interceptors.ReplicationInterceptor
16:38:41,547 INFO  [TreeCache] cache mode is REPL_SYNC
16:38:41,646 INFO  [STDOUT] 
-------------------------------------------------------
GMS: address is localhost:32854
-------------------------------------------------------
16:38:43,650 INFO  [TreeCache] my local address is localhost:32854
16:38:43,650 INFO  [TreeCache] state could not be retrieved (must be first member in group)
16:38:43,650 INFO  [LRUPolicy] Starting eviction policy using the provider: org.jboss.cache.eviction.LRUPolicy
16:38:43,650 INFO  [LRUPolicy] Starting a eviction timer with wake up interval of (secs) 5
16:38:43,650 INFO  [TreeCache] viewAccepted(): [localhost:32854|0] [localhost:32854]
16:38:43,651 INFO  [TreeCache] new cache is null (may be first member in cluster)
16:38:43,651 INFO  [TreeCache] Cache is started!!
16:38:50,304 INFO  [CorbaNamingService] Naming: [IOR:000000000000002B49444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578744578743A312E3000000000000200000000000000D0000102000000000A3132372E302E302E31000DC8000000114A426F73732F4E616D696E672F726F6F74000000000000050000000000000008000000004A414300000000010000001C00000000000100010000000105010001000101090000000105010001000000210000004C000000000000000100000000000000240000001C0000007E00000000000000010000000A3132372E302E302E31000DC9000000000000000000000000000000000000000000000000000000000000002000000004000000000000001F0000000400000003000000010000002000000000000000020000002000000004000000000000001F0000000400000003]
16:38:51,003 INFO  [CorbaTransactionService] TransactionFactory: [IOR:000000000000003049444C3A6F72672F6A626F73732F746D2F69696F702F5472616E73616374696F6E466163746F72794578743A312E30000000000200000000000000D0000102000000000A3132372E302E302E31000DC8000000144A426F73732F5472616E73616374696F6E732F46000000050000000000000008000000004A414300000000010000001C00000000000100010000000105010001000101090000000105010001000000210000004C000000000000000100000000000000240000001C0000007E00000000000000010000000A3132372E302E302E31000DC9000000000000000000000000000000000000000000000000000000000000002000000004000000000000001F0000000400000003000000010000002000000000000000020000002000000004000000000000001F0000000400000003]
16:38:53,447 INFO  [TomcatDeployer] deploy, ctxPath=/web-console, warUrl=.../deploy/management/console-mgr.sar/web-console.war/
16:38:59,848 INFO  [MailService] Mail Service bound to java:/Mail
16:39:00,340 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-ha-local-jdbc.rar
16:39:00,971 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-ha-xa-jdbc.rar
16:39:01,041 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-local-jdbc.rar
16:39:01,114 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-xa-jdbc.rar
16:39:01,773 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jms/jms-ra.rar
16:39:01,856 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/mail-ra.rar
16:39:02,518 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/quartz-ra.rar
16:39:03,357 INFO  [QuartzResourceAdapter] start quartz!!!
16:39:03,408 ERROR [STDERR] [warn] AOP Instrumentor failed to transform org.quartz.impl.StdSchedulerFactory
16:39:03,408 ERROR [STDERR] org.jboss.aop.instrument.TransformationException: Failed to aspectize class org.quartz.impl.StdSchedulerFactory.  Could not find class it references org.quartz.utils.PoolingConnectionProvider  It may not be in your classpath and you may not be getting field and constructor weaving for this class.
16:39:03,409 ERROR [STDERR]     at org.jboss.aop.instrument.Instrumentor.convertReferences(Instrumentor.java:619)
16:39:03,409 ERROR [STDERR]     at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:673)
16:39:03,409 ERROR [STDERR]     at org.jboss.aop.AspectManager.translate(AspectManager.java:970)
16:39:03,409 ERROR [STDERR]     at org.jboss.aop.AspectManager.transform(AspectManager.java:882)
16:39:03,410 ERROR [STDERR]     at org.jboss.aop.standalone.AOPTransformer.aspectTransform(AOPTransformer.java:88)
16:39:03,410 ERROR [STDERR]     at org.jboss.aop.standalone.AOPTransformer.transform(AOPTransformer.java:75)
16:39:03,410 ERROR [STDERR]     at sun.instrument.TransformerManager.transform(TransformerManager.java:122)
16:39:03,410 ERROR [STDERR]     at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:155)
16:39:03,410 ERROR [STDERR]     at java.lang.ClassLoader.defineClass1(Native Method)
16:39:03,410 ERROR [STDERR]     at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
16:39:03,410 ERROR [STDERR]     at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
16:39:03,410 ERROR [STDERR]     at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
16:39:03,410 ERROR [STDERR]     at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
16:39:03,411 ERROR [STDERR]     at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
16:39:03,411 ERROR [STDERR]     at java.security.AccessController.doPrivileged(Native Method)
16:39:03,411 ERROR [STDERR]     at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
16:39:03,411 ERROR [STDERR]     at org.jboss.mx.loading.RepositoryClassLoader.findClassLocally(RepositoryClassLoader.java:672)
16:39:03,412 ERROR [STDERR]     at org.jboss.mx.loading.RepositoryClassLoader.findClass(RepositoryClassLoader.java:652)
16:39:03,412 ERROR [STDERR]     at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
16:39:03,412 ERROR [STDERR]     at org.jboss.mx.loading.RepositoryClassLoader.loadClassLocally(RepositoryClassLoader.java:190)
16:39:03,412 ERROR [STDERR]     at org.jboss.mx.loading.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:131)
16:39:03,412 ERROR [STDERR]     at org.jboss.mx.loading.LoadMgr3.nextTask(LoadMgr3.java:399)
16:39:03,412 ERROR [STDERR]     at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:517)
16:39:03,412 ERROR [STDERR]     at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:405)
16:39:03,413 ERROR [STDERR]     at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
16:39:03,413 ERROR [STDERR]     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
16:39:03,413 ERROR [STDERR]     at org.jboss.resource.adapter.quartz.inflow.QuartzResourceAdapter.start(QuartzResourceAdapter.java:53)
16:39:03,413 ERROR [STDERR]     at org.jboss.resource.deployment.RARDeployment.startService(RARDeployment.java:109)
16:39:03,413 ERROR [STDERR]     at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
16:39:03,413 ERROR [STDERR]     at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
16:39:03,413 ERROR [STDERR]     at org.jboss.system.ServiceDynamicMBeanSupport.invoke(ServiceDynamicMBeanSupport.java:124)
16:39:03,414 ERROR [STDERR]     at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
16:39:03,414 ERROR [STDERR]     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:39:03,414 ERROR [STDERR]     at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
16:39:03,414 ERROR [STDERR]     at $Proxy0.start(Unknown Source)
16:39:03,414 ERROR [STDERR]     at org.jboss.system.ServiceController.start(ServiceController.java:417)
16:39:03,414 ERROR [STDERR]     at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
16:39:03,414 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:39:03,414 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:585)
16:39:03,415 ERROR [STDERR]     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:39:03,415 ERROR [STDERR]     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:39:03,415 ERROR [STDERR]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
16:39:03,416 ERROR [STDERR]     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:39:03,416 ERROR [STDERR]     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:39:03,416 ERROR [STDERR]     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
16:39:03,416 ERROR [STDERR]     at $Proxy123.start(Unknown Source)
16:39:03,416 ERROR [STDERR]     at org.jboss.deployment.SimpleSubDeployerSupport.startService(SimpleSubDeployerSupport.java:345)
16:39:03,416 ERROR [STDERR]     at org.jboss.deployment.SimpleSubDeployerSupport.start(SimpleSubDeployerSupport.java:127)
16:39:03,416 ERROR [STDERR]     at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
16:39:03,416 ERROR [STDERR]     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
16:39:03,416 ERROR [STDERR]     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
16:39:03,417 ERROR [STDERR]     at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
16:39:03,417 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:39:03,417 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:585)
16:39:03,417 ERROR [STDERR]     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:39:03,417 ERROR [STDERR]     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:39:03,417 ERROR [STDERR]     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
16:39:03,417 ERROR [STDERR]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
16:39:03,418 ERROR [STDERR]     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
16:39:03,418 ERROR [STDERR]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
16:39:03,418 ERROR [STDERR]     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:39:03,418 ERROR [STDERR]     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:39:03,418 ERROR [STDERR]     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
16:39:03,418 ERROR [STDERR]     at $Proxy8.deploy(Unknown Source)
16:39:03,418 ERROR [STDERR]     at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
16:39:03,418 ERROR [STDERR]     at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
16:39:03,418 ERROR [STDERR]     at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
16:39:03,419 ERROR [STDERR]     at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
16:39:03,419 ERROR [STDERR]     at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
16:39:03,419 ERROR [STDERR]     at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
16:39:03,419 ERROR [STDERR]     at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
16:39:03,419 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:39:03,419 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:585)
16:39:03,419 ERROR [STDERR]     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:39:03,419 ERROR [STDERR]     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:39:03,420 ERROR [STDERR]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
16:39:03,420 ERROR [STDERR]     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:39:03,420 ERROR [STDERR]     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:39:03,420 ERROR [STDERR]     at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
16:39:03,420 ERROR [STDERR]     at $Proxy0.start(Unknown Source)
16:39:03,420 ERROR [STDERR]     at org.jboss.system.ServiceController.start(ServiceController.java:417)
16:39:03,420 ERROR [STDERR]     at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
16:39:03,420 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:39:03,421 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:585)
16:39:03,421 ERROR [STDERR]     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:39:03,421 ERROR [STDERR]     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:39:03,421 ERROR [STDERR]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
16:39:03,421 ERROR [STDERR]     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:39:03,421 ERROR [STDERR]     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:39:03,421 ERROR [STDERR]     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
16:39:03,421 ERROR [STDERR]     at $Proxy4.start(Unknown Source)
16:39:03,421 ERROR [STDERR]     at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
16:39:03,422 ERROR [STDERR]     at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
16:39:03,422 ERROR [STDERR]     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
16:39:03,422 ERROR [STDERR]     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
16:39:03,422 ERROR [STDERR]     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
16:39:03,422 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
16:39:03,422 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
16:39:03,422 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:39:03,422 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:585)
16:39:03,422 ERROR [STDERR]     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:39:03,423 ERROR [STDERR]     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:39:03,423 ERROR [STDERR]     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
16:39:03,423 ERROR [STDERR]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
16:39:03,423 ERROR [STDERR]     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
16:39:03,423 ERROR [STDERR]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
16:39:03,423 ERROR [STDERR]     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:39:03,423 ERROR [STDERR]     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:39:03,423 ERROR [STDERR]     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
16:39:03,424 ERROR [STDERR]     at $Proxy5.deploy(Unknown Source)
16:39:03,424 ERROR [STDERR]     at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
16:39:03,424 ERROR [STDERR]     at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
16:39:03,424 ERROR [STDERR]     at org.jboss.Main.boot(Main.java:200)
16:39:03,424 ERROR [STDERR]     at org.jboss.Main$1.run(Main.java:464)
16:39:03,424 ERROR [STDERR]     at java.lang.Thread.run(Thread.java:595)
16:39:06,357 INFO  [SimpleThreadPool] Job execution threads will use class loader of thread: main
16:39:07,167 INFO  [QuartzScheduler] Quartz Scheduler v.1.5.2 created.
16:39:07,730 INFO  [RAMJobStore] RAMJobStore initialized.
16:39:07,731 INFO  [StdSchedulerFactory] Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties'
16:39:07,731 INFO  [StdSchedulerFactory] Quartz scheduler version: 1.5.2
16:39:07,732 INFO  [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
16:39:09,487 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=LabsDS' to JNDI name 'java:LabsDS'
16:39:33,617 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
16:40:07,877 ERROR [STDERR] [warn] AOP Instrumentor failed to transform org.hsqldb.persist.NIOScaledRAFile
16:40:07,877 ERROR [STDERR] java.lang.OutOfMemoryError: Java heap space

*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at ../../../src/share/instrument/JPLISAgent.c line: 801
16:41:58,836 WARN  [ServiceController] Problem starting service jboss.mq:service=DestinationManager
java.lang.OutOfMemoryError: Java heap space
16:42:11,338 ERROR [BasicMBeanRegistry] Cannot register MBean
java.lang.OutOfMemoryError: Java heap space
16:42:24,420 ERROR [BasicMBeanRegistry] Cannot register MBean
java.lang.OutOfMemoryError: Java heap space
16:42:27,280 ERROR [BasicMBeanRegistry] Cannot register MBean
java.lang.OutOfMemoryError: Java heap space
16:42:40,520 ERROR [MainDeployer] Could not initialise deployment: file:/usr/local/portal/server/all/deploy/jms/hajndi-jms-ds.xml
java.lang.OutOfMemoryError: Java heap space



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

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



From do-not-reply at jboss.com  Wed Jan  3 20:07:17 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 3 Jan 2007 20:07:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <23233213.1167872837024.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, with that fix I've done the following:

- The "new tasks" list is now a list of created tasks, not assigned tasks.  This should fix the problem that no tasks are being presented on the screen when a process is started having a start task and no swimlanes or assignment magic.

- Fixed another NPE that happens on task instance view if there is no forms.xml.

- Added a "signal" button to the token list to allow a token to be moved along transitions.

I did run across a new problem.  Some of the nodes that I create in the GPD have a width and height of -1 in gpd.xml, making the process diagram fail to work properly.  Also, I have one more screen to make tonight that links to a new process instance in the case where a process definition is started which contains an initial wait state, but no tasks (right now there's no direct link to take you to the newly created process instance, as I realized in today's testing session).

Also one question I have is this: when a process starts that does not have a task on the start state (and therefore, I presume, no reason to wait), should the token automatically proceed out of the start state?  Right now the user must signal the token manually in this case.

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

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


From do-not-reply at jboss.com  Wed Jan  3 20:11:43 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Wed, 3 Jan 2007 20:11:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <31302573.1167873103755.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : Also one question I have is this: when a process starts that does not have a task on the start state (and therefore, I presume, no reason to wait), should the token automatically proceed out of the start state? Right now the user must signal the token manually in this case.

In this situation the client should signal the token via the api, i.e, the web app should signal the token.

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

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


From do-not-reply at jboss.com  Wed Jan  3 20:25:21 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 3 Jan 2007 20:25:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <19580973.1167873921973.JavaMail.jboss@colo-br-02.atl.jboss.com>

"jeffdelong" wrote : anonymous wrote : Also one question I have is this: when a process starts that does not have a task on the start state (and therefore, I presume, no reason to wait), should the token automatically proceed out of the start state? Right now the user must signal the token manually in this case.
  | 
  | In this situation the client should signal the token via the api, i.e, the web app should signal the token.

In this case I have to establish the criteria for signalling the token.  The start node might have multiple transitions, so I presume that I'd only signal if there is a default leaving transition (node.getDefaultLeavingTransition() != null).  The main thing that concerns me though is, how do we know that the start token isn't intended to be a wait state, for whatever reason.  In a normal Node, we rely on the execute() method to determine whether a transition is immediately taken or the Node is a wait state.  However, since StartState's execute() is an illegal operation (in other words, the Token is just pointed at the Node without calling execute()), you never "arrive" in the start state; therefore the start state node never has an opportunity to establish its intention.

My personal opinion is that the start state should be executed like any other node, but of course I'm probably missing critical background on the issue. :-)

I think the best I can do with what we've got now, is something like this: if (no start task instance && initial node has a default leaving transition) { signal the token along the default transition }

Make sense?

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

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


From do-not-reply at jboss.com  Wed Jan  3 21:26:01 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 3 Jan 2007 21:26:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <5648179.1167877561184.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, now if a process is started with no initial tasks, the user is sent to the correct process instance with a link, rather than being left wherever they were beforehand.

Last thing to do is to implement the auto-signalling as described above...

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

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


From do-not-reply at jboss.com  Wed Jan  3 21:53:42 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 3 Jan 2007 21:53:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <29741689.1167879222499.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, that's done.  Let me know if anything isn't as expected.

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

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


From do-not-reply at jboss.com  Wed Jan  3 22:12:21 2007
From: do-not-reply at jboss.com (anil.saldhana@jboss.com)
Date: Wed, 3 Jan 2007 22:12:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - ObjectModelFactories
	parsing empty xml elements
Message-ID: <3803442.1167880341626.JavaMail.jboss@colo-br-02.atl.jboss.com>

What should be the exact behavior of the ObjectModelFactory be for parsing the following security-domain element.


  |   <container-configurations>
  |      <!-- A stateless session config that is not secured -->
  |      <container-configuration extends="Standard Stateless SessionBean">
  |         <container-name>Unsecure Stateless SessionBean</container-name>
  |         <security-domain/>
  |      </container-configuration>
  |   </container-configurations>
  | 

Currently the JBossEjbObjectFactory has a setValue method on the ConfigurationMetaData, but I see that a setValue call is not happening for the security-domain tag.

A similar concept exists for web.xml "auth-constraint" empty tag, but the way the WebMetaDataObjectFactory handles this is via a new AuthConstraint() object which can be either populated with 1 or more roles.

Is there a need for a SecurityDomain object to handle this case?

Note that the following setting works fine:

  | <!-- A stateless session config that uses the spec-test-domain -->
  | <container-configuration extends="Standard Stateless SessionBean">
  |    <container-name>Domain Stateless SessionBean</container-name>
  |    <security-domain>java:/jaas/spec-test-domain</security-domain>
  | </container-configuration>
  | 

My question in general is how should the following xml element C be handled by an ObjectModelFactory?

  | <A name="xyz">
  |   <B>Hello Again</B>
  |   <C/>
  |  </A>
  | 

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

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


From do-not-reply at jboss.com  Wed Jan  3 22:38:24 2007
From: do-not-reply at jboss.com (giahieu2710)
Date: Wed, 3 Jan 2007 22:38:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Using Portlet to .NET
	Environment?
Message-ID: <16258904.1167881904693.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi everyone,
I'm new to Jboss Portal and portlet and I want to use a Java portlet in the .NET environment. Althought I have converted the Java code to a *.dll library using Jnbridge 3.1 which can be used in .NET environment but I find myself difficult to deploy it in .NET. 
>From the guides, it seems like the only way to deploy a Portlet is to hot-deploy it using Jboss Portal. Is there any other way to invoke the Portlet in .NET 2005 environment, such as create an instance of the portlet and 

Thank you very much. 
Harry. 

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

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


From do-not-reply at jboss.com  Wed Jan  3 23:56:15 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 3 Jan 2007 23:56:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	ObjectModelFactories parsing empty xml elements
Message-ID: <20023594.1167886575143.JavaMail.jboss@colo-br-02.atl.jboss.com>

There is no reason for the setValue to be called on an empty element. There would have to be both a newChild and setValue to handle both cases. You don't need a separate SecurityDomain as you can return the parent element:


  |    public Object newChild(ConfigurationMetaData md, UnmarshallingContext navigator,
  |          String namespaceURI, String localName, Attributes attrs)
  |    {
  |       Object child = null;
  |       if (localName.equals("cluster-config"))
  |       {
  |          child = new ClusterConfigMetaData();
  |       }
  |       else if(localName.equals("container-interceptors") ||
  |          localName.equals("container-cache-conf") ||
  |          localName.equals("container-pool-conf"))
  |       {
  |          child = new DomElement(newDomElement(localName, attrs));
  |       }
  |       else if(localName.equals("security-domain"))
  |       {
  |          child = md;
  |          // Indicate a security-domain element was seen...
  |          md.setSecurityDomain(null);
  |       }
  |       return child;
  |    }
  | 
  | 


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

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


From do-not-reply at jboss.com  Thu Jan  4 03:50:00 2007
From: do-not-reply at jboss.com (koen.aers@jboss.com)
Date: Thu, 4 Jan 2007 03:50:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <29805350.1167900600452.JavaMail.jboss@colo-br-02.atl.jboss.com>

"david" wrote : I did run across a new problem.  Some of the nodes that I create in the GPD have a width and height of -1 in gpd.xml, making the process diagram fail to work properly.

This is a known initialization problem. It can be worked around by moving the node a little bit on the canvas after it was added. Not a real good solution, but this will be solved in the 3.1 branch of the GPD.

Regards,
Koen

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

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


From do-not-reply at jboss.com  Thu Jan  4 03:50:30 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Thu, 4 Jan 2007 03:50:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <30211829.1167900630132.JavaMail.jboss@colo-br-02.atl.jboss.com>

"david.lloyd at jboss.com" wrote : - The "new tasks" list is now a list of created tasks, not assigned tasks.  This should fix the problem that no tasks are being presented on the screen when a process is started having a start task and no swimlanes or assignment magic.
  | 

i would call that list the "Unassigned tasks".  it's a good idea.  also you could make the initiator responsible for the assignment in case a task is created without an assignment.

"david.lloyd at jboss.com" wrote : 
  | Also one question I have is this: when a process starts that does not have a task on the start state (and therefore, I presume, no reason to wait), should the token automatically proceed out of the start state?  Right now the user must signal the token manually in this case.

wether or not the process should signal automatic with the start should be in the process definition.  not in the webapp.  currently there is no such feature in which you can specify that the default transition has to be taken automatically when a process instance is created.

for functional behaviour i don't think this is really necessary.  you can always add an action on event process-start.  then a developer could always turn the start-state into a wait state.  but of course, this seriously limits the modeling freedom.

another way to solve this is to do the same as in SEAM page flow.  there you can specify an attribute initial="myStartNode" in the process-definition.  that way, you are not forced to have a start-state as the initial node in your process definition.  i think this would be the most elegant solution.

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

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


From do-not-reply at jboss.com  Thu Jan  4 04:18:26 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Thu, 4 Jan 2007 04:18:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - free choice of initial
	node
Message-ID: <17373565.1167902306305.JavaMail.jboss@colo-br-02.atl.jboss.com>

currently, you are forced to have a start-state to mark the initial node in your process-definition.

i think it is a good idea to expand this so that any type of node could be the first node in the process.  we already did this with SEAM.  

IMO, the most elegant way to achieve this is by adding an optional attribute 'initial' to the process-definition.  the value must be a node name.  when the initial node is specified as an attribute, the process should not have a start-state.

the result is that with the initial attribute on the process-definition, any node type can be used as the start state.

we would have to update the core engine new ProcessInstance(processDefinition) method.  after creating the process instance and positioning the token in the initial node, the initial node has to be executed.  now that is not the case.  the initial node is not executed.  

because the start-state now has an empty implementation, this will be backwards compatible.

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

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


From do-not-reply at jboss.com  Thu Jan  4 04:31:55 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Thu, 4 Jan 2007 04:31:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <20409372.1167903115715.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : "david.lloyd at jboss.com" wrote : - The "new tasks" list is now a list of created tasks, not assigned tasks.  This should fix the problem that no tasks are being presented on the screen when a process is started having a start task and no swimlanes or assignment magic.
  |   | 
  | 
  | i would call that list the "Unassigned tasks".  it's a good idea.  also you could make the initiator responsible for the assignment in case a task is created without an assignment.
  | 
  | 

i forgot to mention that this has no real priority as this is navigation and the navigation will probably be shaken pretty significantly when the se's give their feedback.

also i just saw a potential minor problem with this.  i just started the websale process.  and as the feedback on starting a process instance, i got the 'New Tasks Created' screen with in the table, '(nobody)' in the 'Assigned To' column.  When i clicked the task, it appears to be assigned to ernie (the initiator) as to be expected from the process definition.  So after starting a new websale process, the user should have been navigated to the task screen instead of the 'New Tasks Created' screen, i think.

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

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


From do-not-reply at jboss.com  Thu Jan  4 04:45:25 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Thu, 4 Jan 2007 04:45:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <5179251.1167903925147.JavaMail.jboss@colo-br-02.atl.jboss.com>

just noticed another problem with the webapp.  the user task list shows tasks for all users.  that is not good.  the user task list should only show the tasks that are assigned to the authenticated user.  also the column 'Assigned To' should then be removed.

later, we should concentrate on searching tasks with various criteria.  so that a manager can keep track and intervene with tasks for his subordinates.  this also requires a better authorization mechanism then the one we currently have.

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

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


From do-not-reply at jboss.com  Thu Jan  4 04:56:25 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Thu, 4 Jan 2007 04:56:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <6186481.1167904585818.JavaMail.jboss@colo-br-02.atl.jboss.com>

functionally the webapp is MORE THEN RICH ENGOUGH for the 3.2 release.  Good work, David !

so for the 3.2.Beta1 release, please focus on getting these last issues resolved.  this has highest priority.  i'll go through the web console some more and summarize the high prio issues to be resolved for 3.2.Beta1

then we should collect feedback from SE's and other people on the navigation.  i think that with a few minor enhancements we are pretty close to what i consider a professional and great console.



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

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


From do-not-reply at jboss.com  Thu Jan  4 05:24:31 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Thu, 4 Jan 2007 05:24:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	Update AOPTestDelegate to better integrate into eclipse
Message-ID: <25938249.1167906272001.JavaMail.jboss@colo-br-02.atl.jboss.com>

I've made a start, but more is needed
http://jira.jboss.com/jira/browse/JBAOP-337

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

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


From do-not-reply at jboss.com  Thu Jan  4 06:20:20 2007
From: do-not-reply at jboss.com (alesj)
Date: Thu, 4 Jan 2007 06:20:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: OSGi
	integration
Message-ID: <9241497.1167909620535.JavaMail.jboss@colo-br-02.atl.jboss.com>

I did start with some initial deployment code, but I saw that doing the deployment differently from our deployers is not the way to go - since we already have a mechanism that finds appropriate deployer and deploys metadata.
I will look how we can hook into existing OSGi framework deployment and write our deployer on top of that - probably replacing their 'scanner' mechanism.

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

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


From do-not-reply at jboss.com  Thu Jan  4 06:42:14 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Thu, 4 Jan 2007 06:42:14 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <14699473.1167910934462.JavaMail.jboss@colo-br-02.atl.jboss.com>

summary: high priority for 3.2.Beta1

a) make sure that the user task list only displays tasks for which the current authenticated user is the actorId.  (the group task list should display all the tasks for which the current authenticated actor is somewhere in the list of pooled actor ids.  also note that the pooled actors could contain the group id to which a user belongs)  

The group task stuff is just for your info.  In case there would be a problem with it, that doesn't have to be solved in 3.2.Beta1

b) starting the websale process does not navigate to the task form.  somehow the web console thinks that the task is unassigned.

David, could you fix these two problems asap and post feedback here ?  thanks.

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

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


From do-not-reply at jboss.com  Thu Jan  4 07:26:58 2007
From: do-not-reply at jboss.com (dimitris@jboss.org)
Date: Thu, 4 Jan 2007 07:26:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: New jboss
	version info attributes
Message-ID: <8262020.1167913618713.JavaMail.jboss@colo-br-02.atl.jboss.com>

Can you switch (4.2/HEAD) to use a new attribute VersionNumber I added on Server mbean:

  | ObjectName oname = ObjectNameFactory.create("jboss.system:type=Server");
  | jbossVersion = (String)getServer().getAttribute(oname, "VersionNumber");
  | 
I can then revert the ServerConfig changes to avoid attribute bloat.

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

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


From do-not-reply at jboss.com  Thu Jan  4 09:35:10 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Thu, 4 Jan 2007 09:35:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <12452957.1167921310821.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : also i just saw a potential minor problem with this.  i just started the websale process.  and as the feedback on starting a process instance, i got the 'New Tasks Created' screen with in the table, '(nobody)' in the 'Assigned To' column.  When i clicked the task, it appears to be assigned to ernie (the initiator) as to be expected from the process definition.

This is an oversight on my part - I'm pulling the assigned actor from the TaskCreateLog entry.  Apparently the actor ID is always null here (the actor ID isn't assigned until the subsequent TaskAssignLog entry).  I'll just pull the actor ID from the task itself, that way it won't be wrong.

As far as redirecting to the task form: That's a navigation bit that I've left undone.  In my estimation, users probably want to go to the task form directly, but managers may want to see the task list to know that there are (or are not) other tasks for other users.  When the SEs give their feedback, I'll have to assemble a list of criteria that I use to choose how navigation goes.

As far as the tasklist goes: what I've implemented isn't really a user task list, it's really a "manager" task list , with all tasks for all users being listed.  This is something else that will be changed I expect.  I think that in the end, both variations will exist, but one will be chosen based upon user role; or perhaps the manager version will be in a separate set of screens and the manager will have access to both.  I can easily split it out though.

The group task list still needs more testing.


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

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


From do-not-reply at jboss.com  Thu Jan  4 09:44:58 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Thu, 4 Jan 2007 09:44:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <25743240.1167921898762.JavaMail.jboss@colo-br-02.atl.jboss.com>

"david.lloyd at jboss.com" wrote : I'll just pull the actor ID from the task itself, that way it won't be wrong.

This is done.

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

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


From do-not-reply at jboss.com  Thu Jan  4 10:44:01 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Thu, 4 Jan 2007 10:44:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - SELECT FOR UPDATE
	semantics
Message-ID: <660770.1167925441437.JavaMail.jboss@colo-br-02.atl.jboss.com>

I know I raised this issue somewhere before, but can't find it, so here we go again...

We're about to finalize the 2.x API; before we do, can we add something that provides semantics similar to SELECT FOR UPDATE, i.e. ability to do a read, but acquire a WL in the process?  As it is now, there is no clean way for a tx to read a node and then be confident it can subsequently write to that node.  It's possible for another tx to also get a RL on the node, which will prevent the first tx getting the needed WL.

This would be very helpful with http sessions that are shared between webapps, where I'd like to use a cache node to store the session, and use the node lock to prevent concurrent access to the session.  The natural flow is to do a read, and then *maybe* do a write later if the session data has changed.  The RL from the initial read doesn't provide a strong enough semantic.  To work around that I'd need to do some hack like doing a put() at the beginning w/ a dummy key/value pair.

I've seen other threads that raised similar requirements.

I think doing this should be pretty simple.  I believe it only applies to pessimistic locking.  If we implemented it as an Option (e.g setReadForUpdate(boolean)) it would only affect the pessimistic lock interceptor.  That interceptor would, on a get request, check the option and if present:

1) If the requested node does not exist, create it, like it does with a put.
2) Acquire a WL instead of a RL.

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

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


From do-not-reply at jboss.com  Thu Jan  4 11:07:39 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Thu, 4 Jan 2007 11:07:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <25159407.1167926859532.JavaMail.jboss@colo-br-02.atl.jboss.com>

"david.lloyd at jboss.com" wrote : As far as the tasklist goes: what I've implemented isn't really a user task list, it's really a "manager" task list , with all tasks for all users being listed.  This is something else that will be changed I expect.  I think that in the end, both variations will exist, but one will be chosen based upon user role; or perhaps the manager version will be in a separate set of screens and the manager will have access to both.  I can easily split it out though.
  | 

please fix this so that the user task list only shows the tasks DIRECTLY assigned to the logged on user.  

to have the manager task list, i want a search for tasks later as a separate functionality from the user task list. 

"david.lloyd at jboss.com" wrote : 
  | The group task list still needs more testing.
  | 

keep that for later.  not important for this beta release.


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

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


From do-not-reply at jboss.com  Thu Jan  4 11:09:18 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Thu, 4 Jan 2007 11:09:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <9728720.1167926958193.JavaMail.jboss@colo-br-02.atl.jboss.com>

great that you fixed the the actorId thing so quickly.

can you also fix the user task list and then let me know when that is done.  i'll try to have some time to test it later this evening, but i'm not sure if i'll make it...

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

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


From do-not-reply at jboss.com  Thu Jan  4 11:11:29 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Thu, 4 Jan 2007 11:11:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover refactoring
Message-ID: <13451482.1167927089657.JavaMail.jboss@colo-br-02.atl.jboss.com>

New stuff:

Messages that come over a failed-over connection are now preferentially routed to their corresponding failover queues (and not the other local queues, as it was the case so far)


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

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


From do-not-reply at jboss.com  Thu Jan  4 11:17:33 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Thu, 4 Jan 2007 11:17:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <517817.1167927454006.JavaMail.jboss@colo-br-02.atl.jboss.com>

Done.  There is now a separate manager and user task list.  The actor ID still is shown on the user task list;  I can remove that if it's a problem.

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

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


From do-not-reply at jboss.com  Thu Jan  4 11:27:50 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Thu, 4 Jan 2007 11:27:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <5640880.1167928070723.JavaMail.jboss@colo-br-02.atl.jboss.com>

Coooooolll.... you see all your 'hidden' work now pay off... R.E.S.P.E.C.T

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

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


From do-not-reply at jboss.com  Thu Jan  4 11:32:50 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Thu, 4 Jan 2007 11:32:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: releasing 3.2.Beta1
Message-ID: <25577769.1167928370558.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes, it's nice that my investment in the infrastructure paid off.  It was really, really easy to make those last two changes (like minutes each).  Granted there are some things I wish I'd done differently, but by and large I expect that the upcoming navigation overhaul will be pretty easy.... once the requirements are figured out (which is always the hardest part, in my opinion).

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

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


From do-not-reply at jboss.com  Thu Jan  4 11:39:27 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Thu, 4 Jan 2007 11:39:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	Metadata rewrite
Message-ID: <3324656.1167928767383.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : 
  | However, this does not tell you if there are instance annotations.
  | What you really need to do is the following (pseudo code):
  | 
  | 
  |   | // Get the instance retrieval for this context
  |   | KernelMetaDataRepository repository = kernel.getMetaDataRepository();
  |   | MetaDataRetrieval retrieval = repository.getMetaDataRetrieval(context);
  |   | 
  |   | if (retrieval.isEmpty() == false)
  |   |    // Need an instance proxy
  |   | 
  | 

I'm not really gettting this... I have found a way (not necessarily the best and final, but it works for my tests) to get hold of the context so I can get hold of the kernel. But for a bean annotated with "real" annotations as

  | @Test
  | public class AnnotatedChild extends Base
  | {
  | }
  | 

  |       Annotation[] ai = retrieval.retrieveAnnotations().getValue();
  |       Annotation[] ai2 = retrieval.retrieveLocalAnnotations().getValue();      
  |       Annotation[] anns = metaData.getAnnotations();
  | 
The ai, ai2 and anns all contain the same annotations. I

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

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


From do-not-reply at jboss.com  Thu Jan  4 11:41:51 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Thu, 4 Jan 2007 11:41:51 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	Metadata rewrite
Message-ID: <14905600.1167928911355.JavaMail.jboss@colo-br-02.atl.jboss.com>

In fact

  | metaData.getAnnotations() 
  | 
ends up in its retrieval.getAnnotations()

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

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


From do-not-reply at jboss.com  Thu Jan  4 11:50:19 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Thu, 4 Jan 2007 11:50:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover refactoring
Message-ID: <17915336.1167929419766.JavaMail.jboss@colo-br-02.atl.jboss.com>

> (and not the other local queues, as it was the case so far) 

We had routers taking care of this, balancing between local queues and failedover queues. Did you change this policy?

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

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


From do-not-reply at jboss.com  Thu Jan  4 12:24:27 2007
From: do-not-reply at jboss.com (ALRubinger)
Date: Thu, 4 Jan 2007 12:24:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Component Proposal -
	Configurable Service Locator
Message-ID: <23625049.1167931467791.JavaMail.jboss@colo-br-02.atl.jboss.com>

Thanks for your input, Carlo.

I've reviewed the relevant parts of the JEE5 Spec (Injection and Client Chapters) and am in the process of putting together my own Application Client to run against JBoss built from TRUNK.

Yes, a lot of the issues I'd addressed are handled in the spec.  Not covered, and handled by a potential ServiceLocator:

* Lookup by interface

* Lookup AFTER the main method is called (the spec dictates that injection is done once, via static members, before "main" on the client.  What about after?)

* @Service injection?  How is this currently being handled as a JMX Service Bean is a JBoss-specific extension?

And yes, I'd really like to have a client access services on more than one host.  This may be outside the discussion of the client container; take into account the case of an EJB with dependencies on other remote EJBs:

* Client contacts Application Services as JEE5 Application Client
* Application Services depend on some set of Core Services used by many applications - contact via ServiceLocator

The core services may be hosted at any number of locations.

I'd like to determine how to best address this issue if possible.

S,
ALR


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

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


From do-not-reply at jboss.com  Thu Jan  4 12:33:22 2007
From: do-not-reply at jboss.com (anil.saldhana@jboss.com)
Date: Thu, 4 Jan 2007 12:33:22 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	ObjectModelFactories parsing empty xml elements
Message-ID: <6901767.1167932002647.JavaMail.jboss@colo-br-02.atl.jboss.com>

Thanks Scott. That did the trick. I had tried the combination of setValue and newChild but did not figure out returning the parent element.

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

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


From do-not-reply at jboss.com  Thu Jan  4 12:44:17 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Thu, 4 Jan 2007 12:44:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover refactoring
Message-ID: <7761611.1167932657087.JavaMail.jboss@colo-br-02.atl.jboss.com>

I had this conversation in private with Ovidiu, and I wanted to make a public post about this.

I'm kind of concerned about the fact we are using multiple valves (instead of a single instance per connection).

The way is implemented now, you have a Valve on every descendant of Connection (Sessions, Producers, Consumers and Browsers).

When we get a failure, we have to close every single valve before performing a failover, i.e. The lock is not atomic and you have multiple locks.

The problem is when you place a try..catch(IOException) on the ValveIntercetor to capture failure exceptions. In cases where you have multiple threads using the same Connection (multiple sessions/threads on the same Connection). As the lock should be aways atomic (close every valve for the failed Connection), you can have multiple Threads trying to close the whole hierarchy of valves.

Lets talk in examples:

- You have one Connection and 50 Threads/50 Sessions. Suppose all these 50 Threads are communicating at the same time.

- We kill the server, all of the 50 threads are going to catch an IOException at the same time.

- As all of the 50 threads are going to catch the exception at the same time... All of them are going to close the valve at the same time. Valve close is a loop on the hierarchy:


  |    // from HierarchicalStateSupport
  |    public void closeChildrensValves() throws Exception
  |    {
  |       if (children == null)
  |       {
  |          return;
  |       }
  | 
  |       for(Iterator i = children.iterator(); i.hasNext(); )
  |       {
  |          HierarchicalState s = (HierarchicalState)i.next();
  |          ((Valve)s.getDelegate()).closeValve();
  |       }
  |    }
  | 
  |    public void openChildrensValves() throws Exception
  |    {
  |       if (children == null)
  |       {
  |          return;
  |       }
  | 
  |       for(Iterator i = children.iterator(); i.hasNext(); )
  |       {
  |          HierarchicalState s = (HierarchicalState)i.next();
  |          ((Valve)s.getDelegate()).openValve();
  |       }
  |    }
  | 

I belive we should use a single Valve instance, the way it was done before.
The only reason for this refactoring was the fact I was using a single instance but using AOP API to install the Valve on the right place with the proper instantiation. This could be refactored in another way such as delegating the Valve to an external object on the ValveAspect (which was going to be renamed to FailureInterceptor).

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

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


From do-not-reply at jboss.com  Thu Jan  4 12:46:40 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Thu, 4 Jan 2007 12:46:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover refactoring (Repost)
Message-ID: <15315354.1167932800381.JavaMail.jboss@colo-br-02.atl.jboss.com>

I had this conversation in private with Ovidiu, and I wanted to make a public post about this.

I'm kind of concerned about the fact we are using multiple valves (instead of a single instance per connection).

The way is implemented now, you have a Valve on every descendant of Connection (Sessions, Producers, Consumers and Browsers).

When we get a failure, we have to close every single valve before performing a failover, i.e. The lock is not atomic and you have multiple locks.

The problem is when you place a try..catch(IOException) on the ValveIntercetor to capture failure exceptions. In cases where you have multiple threads using the same Connection (multiple sessions/threads on the same Connection). As the lock should be aways atomic (close every valve for the failed Connection), you can have multiple Threads trying to close the whole hierarchy of valves.

Lets talk in examples:

- You have one Connection and 50 Threads/50 Sessions. Suppose all these 50 Threads are communicating at the same time.

- We kill the server, all of the 50 threads are going to catch an IOException at the same time.

- As all of the 50 threads are going to catch the exception at the same time... All of them are going to close the valve at the same time. Valve close is a loop on the hierarchy:


  |    // from HierarchicalStateSupport
  |    public void closeChildrensValves() throws Exception
  |    {
  |       if (children == null)
  |       {
  |          return;
  |       }
  | 
  |       for(Iterator i = children.iterator(); i.hasNext(); )
  |       {
  |          HierarchicalState s = (HierarchicalState)i.next();
  |          ((Valve)s.getDelegate()).closeValve();
  |       }
  |    }
  | 
  |    public void openChildrensValves() throws Exception
  |    {
  |       if (children == null)
  |       {
  |          return;
  |       }
  | 
  |       for(Iterator i = children.iterator(); i.hasNext(); )
  |       {
  |          HierarchicalState s = (HierarchicalState)i.next();
  |          ((Valve)s.getDelegate()).openValve();
  |       }
  |    }
  | 

I belive we should use a single Valve instance, the way it was done before.
The only reason for this refactoring was the fact I was using a single instance but using AOP API to install the Valve on the right place with the proper instantiation. This could be refactored in another way such as delegating the Valve to an external object on the ValveAspect (which was going to be renamed to FailureInterceptor).

I'm playing with another Branch and I have already refactored it to use a single instance of Valve, and have installed the try...catch(IOException) in place. I'm only using standard XML config.

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

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


From do-not-reply at jboss.com  Thu Jan  4 13:01:43 2007
From: do-not-reply at jboss.com (brittm)
Date: Thu, 4 Jan 2007 13:01:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: decision conditions
Message-ID: <18565231.1167933703518.JavaMail.jboss@colo-br-02.atl.jboss.com>

As stated, It is very un-intuitive and certainly doesn't clearly document what is going on in the decision.  I always try to make all of my transition criteria explicit, and can't imagine ever seriously writing a Decision node that would rely on the old behavior.  I imagine other developers aren't relying on it either.  

As Tom mentioned, the docs were wrong and no one even noticed.

I would vote for the change.

-Britt

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

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


From do-not-reply at jboss.com  Thu Jan  4 13:30:15 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Thu, 4 Jan 2007 13:30:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Component Proposal -
	Configurable Service Locator
Message-ID: <10215324.1167935415228.JavaMail.jboss@colo-br-02.atl.jboss.com>

Maybe we should allow a pluggable default strategy for determining JNDI bindings?  This would be plugged into the server side and would specify how the EJB container should bind to JNDI.

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

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


From do-not-reply at jboss.com  Thu Jan  4 13:30:55 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Thu, 4 Jan 2007 13:30:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover refactoring
Message-ID: <17740930.1167935455734.JavaMail.jboss@colo-br-02.atl.jboss.com>

I talked to Kabir. We could control instantiation of interceptors by using Factories (witch is a straighforward and documented way), but getInstance is not exposed.

So, I requested a feature that will be useful on future releases. 

http://jira.jboss.org/jira/browse/JBAOP-338

I won't use such feature now as we will stick with delegates or with the muliple valves. (something we will have to decide later), but I think the feature request is valid.

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

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


From do-not-reply at jboss.com  Thu Jan  4 13:59:26 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Thu, 4 Jan 2007 13:59:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: ejb3-head testsuite
Message-ID: <31752098.1167937166605.JavaMail.jboss@colo-br-02.atl.jboss.com>

I found that the clustering tests would fail to start due to OOM.  The start-jboss macro in testsuite/imports/server-config.xml only gives 64M to the AS by default, which is no longer enough to start the server. I expect other tests that use the AS are failing for the same reason.

For the clustering tests, I found modifying the tests-clustering-startup target so start-jboss looked like the following let them run:

<start-jboss  conf="node0" host="${node0}" jvmargs="-Xmx128M"/>

I've checked in build-test.xml with that applied to all the start-jboss calls.

I don't know if that will resolve all issues, but it's something.

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

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


From do-not-reply at jboss.com  Thu Jan  4 14:29:44 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Thu, 4 Jan 2007 14:29:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of the JBoss EJB Container] - Re:
	Support of J2EE 5.0 in JBoss 5.x
Message-ID: <8179203.1167938984904.JavaMail.jboss@colo-br-02.atl.jboss.com>

When certification is complete. Q1-Q2 timeframe.

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

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


From do-not-reply at jboss.com  Thu Jan  4 14:32:30 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Thu, 4 Jan 2007 14:32:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of the JBoss EJB Container] - Interface
	exception checking seems broken
Message-ID: <5134938.1167939150642.JavaMail.jboss@colo-br-02.atl.jboss.com>

"henke.eriksson"  wrote : 
  | We ran into some trouble today when we tried to deploy an EJB with a
  | Local interface on JBoss 4.0.4. The business interface had one method,
  | which looked something like this:
  | 
  | Object doStuff(Command c) throws Throwable;
  | 
  | At deploy-time the verifier complained that we had a method in a local
  | interface that threw a RemoteException violating section 7.11.7 of the
  | EJB spec.
  | 
  | We did some digging and stumbled across the bug report JBAS-1463. The
  | fix for this "bug" basically disallows a method in a local interface
  | to declare that it throws a RemoteException or any of its
  | SUPERclasses. As the report mentions, the RMI spec says that a Remote
  | method must declare that it throws a RemoteException or one of it
  | superclasses. But as far as I know a remote method can still declare
  | that it throws a subclass of RemoteException, right?
  | 
  | Right now the verifier assumes that a method that declares that it
  | throws Throwable is a remote method. And I can see in the code that
  | fixes to allow Exception and IOException has been applied. But I still
  | feel that this logic is a bit weird, or am I missing something? 
  | 


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

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


From do-not-reply at jboss.com  Thu Jan  4 14:42:24 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Thu, 4 Jan 2007 14:42:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design of the JBoss EJB Container] - Re:
	Interface exception checking seems broken
Message-ID: <16971824.1167939744974.JavaMail.jboss@colo-br-02.atl.jboss.com>

The rmi spec(which is hardly a spec) should not be dictating the exception checking, as its the ejb specs which define what is needed. Allowing superclasses of RemoteException is obvisously going to collide with generic application exceptions. The ejb spec is pretty clear about remote methods must be identified by a RemoteException, with any number of application exceptions. 

The current throwsRemoteException(Method) method is a confusion of checks that are mixing local and remote interface semantics:

  |    /**
  |     * Checks if the method includes java.rmi.RemoteException or its
  |     * subclass in its throws clause.
  |     *
  |     * See bug report #434739 and #607805
  |     */
  |    public boolean throwsRemoteException(Method method)
  |    {
  |       Class[] exception = method.getExceptionTypes();
  | 
  |       for (int i = 0; i < exception.length; ++i)
  |       {
  |          // Fix for bug #607805: an IOException is OK for local interfaces
  |          // Fix for bug #626430: java.lang.Exception is also OK
  |          if (exception.equals(java.io.IOException.class)
  |                  || exception.equals(java.lang.Exception.class))
  |          {
  |             continue;
  |          }
  | // Not true see bug report #434739
  | //            if (java.rmi.RemoteException.class.isAssignableFrom(exception))
  | // According to the RMI spec. a remote interface must throw an RemoteException
  | // or any of its super classes therefore the check must be done vice versa
  | 
  |          if (isAssignableFrom(exception, "java.rmi.RemoteException"))
  |          {
  |             return true;
  |          }
  |       }
  | 
  |       return false;
  |    }
  | 

None of the methods in this interface should be valid:

  | public interface X extends EJBObject
  | {
  |    void m0() throws IOException;
  |    void m1() throws Exception;
  |    void m2() throws Throwable;
  | }
  | 

They are all valid for a local interface.


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

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


From do-not-reply at jboss.com  Thu Jan  4 14:52:59 2007
From: do-not-reply at jboss.com (akostadinov)
Date: Thu, 4 Jan 2007 14:52:59 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: ejb3-head testsuite
Message-ID: <21233598.1167940379583.JavaMail.jboss@colo-br-02.atl.jboss.com>

could that be commited to svn?


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

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


From do-not-reply at jboss.com  Thu Jan  4 14:55:48 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Thu, 4 Jan 2007 14:55:48 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover refactoring
Message-ID: <2142708.1167940548909.JavaMail.jboss@colo-br-02.atl.jboss.com>

"clebert.suconic at jboss.com" wrote : > (and not the other local queues, as it was the case so far) 
  | 
  | We had routers taking care of this, balancing between local queues and failedover queues. Did you change this policy?

No. This comes in top of the message pull policy, that it still in effect (well, right now it isn't since we're using a NullMessagePullPolicy, but if we were using one, it would be in effect).

These behaviors complement each other.

And by thew way, this reminds me that we should also test the pull policy, currently we have 0 tests for it.

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

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


From do-not-reply at jboss.com  Thu Jan  4 15:06:02 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Thu, 4 Jan 2007 15:06:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: ejb3-head testsuite
Message-ID: <26466923.1167941162641.JavaMail.jboss@colo-br-02.atl.jboss.com>

It was committed before I posted.  Latest jboss-head-jdk-matrix build report from cruisecontrol shows it.  Perhaps hasn't made it to anonymous svn yet?

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

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


From do-not-reply at jboss.com  Thu Jan  4 15:24:56 2007
From: do-not-reply at jboss.com (akostadinov)
Date: Thu, 4 Jan 2007 15:24:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: ejb3-head testsuite
Message-ID: <10081053.1167942296960.JavaMail.jboss@colo-br-02.atl.jboss.com>

Sorry, I didn't checked.
I'll see how is it now.

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

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


From do-not-reply at jboss.com  Thu Jan  4 16:14:13 2007
From: do-not-reply at jboss.com (charles.crouch@jboss.com)
Date: Thu, 4 Jan 2007 16:14:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Deployment through
	the ProfileService api
Message-ID: <8298911.1167945253340.JavaMail.jboss@colo-br-02.atl.jboss.com>

"scott.stark at jboss.org" wrote : 
  | Correct. However, for the initial tests I expect that the base deployment exists, so the way to add a deployment to a profile is:
  | 
  | 
  |   |       URL deploymentURL = ...
  |   |       VFS vfs = VFS.getVFS(deploymentURL);
  |   |       VirtualFile deploymentVF = vfs.getRoot();
  |   |       AbstractDeploymentContext context = new AbstractDeploymentContext(deploymentVF);
  |   |       ps.addDeployment(context);
  |   | 
  | 

I'm confused about this last point.
1) What do you mean a "base" deployment? What is the "base" deployment in the scenario of wanting to deploy a brand new datasource?
2) In the pseudo code, deploymentURL presumably refers to this "base" deployment. Where would one obtain the deploymentURL from in the first place?

Thanks


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

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


From do-not-reply at jboss.com  Thu Jan  4 17:02:55 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Thu, 4 Jan 2007 17:02:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Deployment through
	the ProfileService api
Message-ID: <6523815.1167948175448.JavaMail.jboss@colo-br-02.atl.jboss.com>

The base deploymentURL is the raw deployment content location (user supplied ear, war, sar, rar, etc.). It has not admin edits associated with it.

See the current org.jboss.system.server.profileservice.VFSScanner for how the current basic ProfileImpl is feed the deployment contexts from the standard bootstrap, deployers and deploy directory contents.

The Profile api is being refactored to tie together repository support so that there is a base deployment notion coming from the addProfileContent method:


  | package org.jboss.profileservice.spi;
  | 
  | import java.io.IOException;
  | import java.util.Collection;
  | import java.util.Map;
  | import java.util.zip.ZipInputStream;
  | 
  | import org.jboss.deployers.spi.structure.DeploymentContext;
  | 
  | /**
  |  * A profile represents a named collection of deployments on a server.
  |  * 
  |  * @author Scott.Stark at jboss.org
  |  * @version $Revision$
  |  */
  | public interface Profile
  | {
  |    /** The class of deployment */
  |    public enum DeploymentPhase {
  |       /** A deployment loaded during the server bootstrap phase */
  |       BOOTSTRAP,
  |       /** An mc/service deployment for a Deployer to be loaded after the BOOTSTRAP phase */
  |       DEPLOYER,
  |       /** Any deployment content to be loaded after the DEPLOYER phase */
  |       APPLICATION
  |    };
  | 
  |    /**
  |     * The x.y.z version of the profile
  |     * 
  |     * @return the version if known, null if its unspecified.
  |     */
  |    public String getVersion();
  | 
  |    /**
  |     * Add raw content (bootstrap, deployers, deployments, libraries, etc) to a
  |     * profile.
  |     * 
  |     * @param name - a logical name for the content added
  |     * @param contentIS - a zip input stream of the content layout as it is
  |     * to be added to the profile.
  |     * @param phase - the phase of the deployment as it relates to when the
  |     * deployment is loaded
  |     * @throws IOException
  |     */
  |    public void addProfileContent(String name, ZipInputStream contentIS, DeploymentPhase phase)
  |       throws IOException;
  | 
  |    /**
  |     * Add a deployment
  |     * 
  |     * @param d the deployment
  |     * @param phase - the phase of the deployment as it relates to when the
  |     * deployment is loaded
  |     */
  |    public void addDeployment(DeploymentContext d, DeploymentPhase phase)
  |       throws Exception;
  | 
  |    /**
  |     * Remove a deployment
  |     * 
  |     * @param name the name
  |     * @param phase - the phase of the deployment as it relates to when the
  |     * deployment is loaded
  |     */
  |    public void removeDeployment(String name, DeploymentPhase phase)
  |       throws Exception;
  | 
  |    /**
  |     * Get a named deployment.
  |     * 
  |     * @param name - the deployment name
  |     * @param phase - the phase of the deployment as it relates to when the
  |     * deployment is loaded
  |     * @return the named bootstrap
  |     * @throws NoSuchDeploymentException - if there is no such bootstrap
  |     */
  |    public DeploymentContext getDeployment(String name, DeploymentPhase phase)
  |       throws NoSuchDeploymentException;
  | 
  |    /**
  |     * Get the names of the deployments in the profile
  |     * @return names of deployments
  |     */
  |    public Collection<String> getDeploymentNames();
  | 
  |    /**
  |     * Get the names of the deployments for the given phase defined in this profile
  |     * @param phase - the phase of the deployment as it relates to when the
  |     * deployment is loaded
  |     * @return names of deployments
  |     */
  |    public Collection<String> getDeploymentNames(DeploymentPhase phase);
  | 
  |    /**
  |     * Get all deployments for the given phase defined in this profile
  |     * 
  |     * @param phase - the phase of the deployment as it relates to when the
  |     * deployment is loaded
  |     * @return the bootstrap instances in this profile.
  |     */
  |    public Collection<DeploymentContext> getDeployments(DeploymentPhase phase);
  | 
  | 
  |    /**
  |     * Get all deployments defined in this profile
  |     * 
  |     * @return the deployment instances in this profile.
  |     */
  |    public Collection<DeploymentContext> getDeployments();
  | 
  |    /**
  |     * Get the config
  |     * 
  |     * @return the config
  |     */
  |    public Map<String, Object> getConfig();
  | }
  | 

The DeploymentTemplate notion has been moved to the ManagedView since it depends on the ManagedObject/ManagedProperty notions. These have been updated to the new mc versions of the classes.

I'm still working to finalize this by tieing together the Profile, ManagentView and repository notions with the aspects that map the admin edits to a ManagedProperty back to the profile repository in the form a DeploymentContext Attachment overrides to the base DeploymentContext Attachments.

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

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


From do-not-reply at jboss.com  Thu Jan  4 18:41:35 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Thu, 4 Jan 2007 18:41:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	Metadata rewrite
Message-ID: <28443863.1167954095994.JavaMail.jboss@colo-br-02.atl.jboss.com>

I am now able to figure out whether there is instance metadata. The problem is to get the context into the AOPConstructorJoinpoint where I am doing the checks. Locally, I have made AOPConstructorJoinpoint implement KernelControllerContextAware, and KernelControllerContextAction.dispatchJoinpoint() set the  context if the joinpoint implements the KCCA interface.

All tests now pass, although I am not able to get hold of the context if instantiating the bean via the GenericBeanAspectFactory/GenericBeanFactory.

I will tidy up this and commit tomorrow, and we can discuss from there

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

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


From do-not-reply at jboss.com  Thu Jan  4 22:02:56 2007
From: do-not-reply at jboss.com (anil.saldhana@jboss.com)
Date: Thu, 4 Jan 2007 22:02:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Security on JBoss] - Re:
	SecurityContext
Message-ID: <17528280.1167966176673.JavaMail.jboss@colo-br-02.atl.jboss.com>

Two questions:
a) On the server side, can I know if the call originated within the same vm or not? Do I need to put something on the invocation via the InvokerInterceptor?

b) Is there anything equivalent to ServletRequest.isSecure() for jboss ejb invocations? I do not think so looking at the Invocation interface. What is the right way to inject transport semantics(like ssl) into the invocation?

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

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


From do-not-reply at jboss.com  Fri Jan  5 01:56:44 2007
From: do-not-reply at jboss.com (alesj)
Date: Fri, 5 Jan 2007 01:56:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	Metadata rewrite
Message-ID: <26301106.1167980204100.JavaMail.jboss@colo-br-02.atl.jboss.com>

"kabir.khan at jboss.com" wrote : Locally, I have made AOPConstructorJoinpoint implement KernelControllerContextAware
  | 

There were added more state 'precise' KCCAware interfaces.
And I think we should drop the plain KCCA, since that way you don't know when it gets applied or which is the right state to do that.

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

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


From do-not-reply at jboss.com  Fri Jan  5 02:49:15 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 5 Jan 2007 02:49:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Aspect
	integration to bootstrap classes
Message-ID: <27184137.1167983355932.JavaMail.jboss@colo-br-02.atl.jboss.com>

Short of moving the AspectManager into the bootstrap-beans.xml, what mechanism do we have to introduce aspects into the bootstrap classes like MainDeployer, and ProfileService?


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

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


From do-not-reply at jboss.com  Fri Jan  5 03:44:27 2007
From: do-not-reply at jboss.com (timfox)
Date: Fri, 5 Jan 2007 03:44:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-578 - Multiplex JGroups Channel
Message-ID: <3445737.1167986667591.JavaMail.jboss@colo-br-02.atl.jboss.com>

I think we can always assume the MBean is there, therefore no need to create the channels ourself.

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

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


From do-not-reply at jboss.com  Fri Jan  5 03:48:18 2007
From: do-not-reply at jboss.com (timfox)
Date: Fri, 5 Jan 2007 03:48:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover refactoring
Message-ID: <28650178.1167986898322.JavaMail.jboss@colo-br-02.atl.jboss.com>

"ovidiu.feodorov at jboss.com" wrote : 
  | And by thew way, this reminds me that we should also test the pull policy, currently we have 0 tests for it.

The pull functionality is tested in the core clustering tests, but not in the jms clustering tests.

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

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


From do-not-reply at jboss.com  Fri Jan  5 04:52:53 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Fri, 5 Jan 2007 04:52:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-578 - Multiplex JGroups Channel
Message-ID: <26983248.1167990773913.JavaMail.jboss@colo-br-02.atl.jboss.com>

Amen.

Clebert, I haven't changed a single word with Tim on the subject :)

This is re: our previous discussion ... :)

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

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


From do-not-reply at jboss.com  Fri Jan  5 04:53:47 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Fri, 5 Jan 2007 04:53:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover refactoring
Message-ID: <31870889.1167990827905.JavaMail.jboss@colo-br-02.atl.jboss.com>

OK. We still need jms tests for it.

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

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


From do-not-reply at jboss.com  Fri Jan  5 05:34:13 2007
From: do-not-reply at jboss.com (regisba)
Date: Fri, 5 Jan 2007 05:34:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - Problem
	with JBOSS IDE
Message-ID: <8683668.1167993253289.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi!

I try the Tutorial of JBOSS IDE but it doesn't work like the example. anonymous wrote : 11:31:28,578 INFO  [Server] Starting JBoss (MX MicroKernel)...
  | 11:31:28,578 INFO  [Server] Release ID: JBoss [WonderLand] 3.2.5 (build: CVSTag=JBoss_3_2_5 date=200406251954)
  | 11:31:28,578 INFO  [Server] Home Dir: D:\logiciel\jboss3\jboss-3.2.5\jboss-3.2.5
  | 11:31:28,578 INFO  [Server] Home URL: file:/D:/logiciel/jboss3/jboss-3.2.5/jboss-3.2.5/
  | 11:31:28,593 INFO  [Server] Library URL: file:/D:/logiciel/jboss3/jboss-3.2.5/jboss-3.2.5/lib/
  | 11:31:28,593 INFO  [Server] Patch URL: null
  | 11:31:28,593 INFO  [Server] Server Name: default
  | 11:31:28,593 INFO  [Server] Server Home Dir: D:\logiciel\jboss3\jboss-3.2.5\jboss-3.2.5\server\default
  | 11:31:28,593 INFO  [Server] Server Home URL: file:/D:/logiciel/jboss3/jboss-3.2.5/jboss-3.2.5/server/default/
  | 11:31:28,593 INFO  [Server] Server Data Dir: D:\logiciel\jboss3\jboss-3.2.5\jboss-3.2.5\server\default\data
  | 11:31:28,609 INFO  [Server] Server Temp Dir: D:\logiciel\jboss3\jboss-3.2.5\jboss-3.2.5\server\default\tmp
  | 11:31:28,609 INFO  [Server] Server Config URL: file:/D:/logiciel/jboss3/jboss-3.2.5/jboss-3.2.5/server/default/conf/
  | 11:31:28,609 INFO  [Server] Server Library URL: file:/D:/logiciel/jboss3/jboss-3.2.5/jboss-3.2.5/server/default/lib/
  | 11:31:28,609 INFO  [Server] Root Deployment Filename: jboss-service.xml
  | 11:31:28,609 INFO  [Server] Starting General Purpose Architecture (GPA)...
  | 11:31:29,203 INFO  [ServerInfo] Java version: 1.5.0_09,Sun Microsystems Inc.
  | 11:31:29,203 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.5.0_09-b03,Sun Microsystems Inc.
  | 11:31:29,203 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
  | 11:31:30,171 INFO  [Server] Core system initialized
  | 11:31:34,468 INFO  [Log4jService$URLWatchTimerTask] Configuring from URL: resource:log4j.xml
  | 11:31:35,000 INFO  [WebService] Using RMI server codebase: http://AOFR00671:8083/
  | 11:31:35,359 INFO  [NamingService] Started jnpPort=1099, rmiPort=1098, backlog=50, bindAddress=/0.0.0.0, Client SocketFactory=null, Server SocketFactory=org.jboss.net.sockets.DefaultSocketFactory at ad093076
  | 11:31:45,140 INFO  [RARMetaData] Loading JBoss Resource Adapter for JDBC 2 XA drivers
  | 11:31:45,140 INFO  [RARMetaData] Required license terms present. See deployment descriptor.
  | 11:31:50,406 INFO  [MailService] Mail Service bound to java:/Mail
  | 11:31:51,609 INFO  [Embedded] Catalina naming disabled
  | 11:31:52,718 INFO  [Http11Protocol] Initialisation de Coyote HTTP/1.1 sur http-0.0.0.0-8080
  | 11:31:52,796 INFO  [Catalina] Initialization processed in 1046 ms
  | 11:31:52,796 INFO  [StandardService] Starting service jboss.web
  | 11:31:52,812 INFO  [StandardEngine] Starting Servlet Engine: Apache Tomcat/5.0.26
  | 11:31:52,828 INFO  [StandardHost] XML validation disabled
  | 11:31:52,906 INFO  [Catalina] Server startup in 110 ms
  | 11:31:53,062 WARN  [DeploymentInfo] Only the root deployment can set the loader repository, ingoring config=null
  | 11:31:53,140 INFO  [TomcatDeployer] deploy, ctxPath=/invoker, warUrl=file:/D:/logiciel/jboss3/jboss-3.2.5/jboss-3.2.5/server/default/deploy/http-invoker.sar/invoker.war/
  | 11:31:54,812 WARN  [DeploymentInfo] Only the root deployment can set the loader repository, ingoring config=null
  | 11:31:54,828 INFO  [TomcatDeployer] deploy, ctxPath=, warUrl=file:/D:/logiciel/jboss3/jboss-3.2.5/jboss-3.2.5/server/default/deploy/jbossweb-tomcat50.sar/ROOT.war/
  | 11:31:55,203 WARN  [DeploymentInfo] Only the root deployment can set the loader repository, ingoring config=null
  | 11:31:55,218 INFO  [TomcatDeployer] deploy, ctxPath=/jbossmq-httpil, warUrl=file:/D:/logiciel/jboss3/jboss-3.2.5/jboss-3.2.5/server/default/deploy/jms/jbossmq-httpil.sar/jbossmq-httpil.war/
  | 11:31:55,609 INFO  [DefaultDS] Bound connection factory for resource adapter for ConnectionManager 'jboss.jca:service=LocalTxCM,name=DefaultDS to JNDI name 'java:/DefaultDS'
  | 11:31:56,046 INFO  [A] Bound to JNDI name: queue/A
  | 11:31:56,046 INFO  [B] Bound to JNDI name: queue/B
  | 11:31:56,046 INFO  [C] Bound to JNDI name: queue/C
  | 11:31:56,046 INFO  [D] Bound to JNDI name: queue/D
  | 11:31:56,046 INFO  [ex] Bound to JNDI name: queue/ex
  | 11:31:56,125 INFO  [testTopic] Bound to JNDI name: topic/testTopic
  | 11:31:56,125 INFO  [securedTopic] Bound to JNDI name: topic/securedTopic
  | 11:31:56,125 INFO  [testDurableTopic] Bound to JNDI name: topic/testDurableTopic
  | 11:31:56,125 INFO  [testQueue] Bound to JNDI name: queue/testQueue
  | 11:31:56,281 INFO  [UILServerILService] JBossMQ UIL service available at : /0.0.0.0:8093
  | 11:31:56,453 INFO  [DLQ] Bound to JNDI name: queue/DLQ
  | 11:31:56,500 INFO  [JmsXA] Bound connection factory for resource adapter for ConnectionManager 'jboss.jca:service=TxCM,name=JmsXA to JNDI name 'java:/JmsXA'
  | 11:31:56,687 INFO  [TomcatDeployer] deploy, ctxPath=/jmx-console, warUrl=file:/D:/logiciel/jboss3/jboss-3.2.5/jboss-3.2.5/server/default/deploy/jmx-console.war/
  | 11:32:02,375 INFO  [TomcatDeployer] deploy, ctxPath=/web-console, warUrl=file:/D:/logiciel/jboss3/jboss-3.2.5/jboss-3.2.5/server/default/tmp/deploy/tmp55733web-console.war/
  | 11:32:05,203 INFO  [EARDeployer] Init J2EE application: file:/D:/logiciel/jboss3/jboss-3.2.5/jboss-3.2.5/server/default/deploy/FiboApp.ear
  | 11:32:05,578 WARN  [DeploymentInfo] Only the root deployment can set the loader repository, ingoring config=null
  | 11:32:06,046 INFO  [EjbModule] Deploying Fibo
  | 11:32:06,484 INFO  [EJBDeployer] Deployed: file:/D:/logiciel/jboss3/jboss-3.2.5/jboss-3.2.5/server/default/tmp/deploy/tmp55734FiboApp.ear-contents/FiboEJB.jar
  | 11:32:06,578 INFO  [TomcatDeployer] deploy, ctxPath=/fibo, warUrl=file:/D:/logiciel/jboss3/jboss-3.2.5/jboss-3.2.5/server/default/tmp/deploy/tmp55734FiboApp.ear-contents/FiboWeb.war/
  | 11:32:06,750 INFO  [TomcatDeployer] ClusteredHTTPSessionService not found
  | 11:32:06,750 ERROR [TomcatDeployer] Failed to setup clustering, clustering disabled
  | 11:32:07,031 INFO  [EARDeployer] Started J2EE application: file:/D:/logiciel/jboss3/jboss-3.2.5/jboss-3.2.5/server/default/deploy/FiboApp.ear
  | 11:32:07,375 INFO  [Server] JBoss (MX MicroKernel) [3.2.5 (build: CVSTag=JBoss_3_2_5 date=200406251954)] Started in 38s:766ms
  | 11:32:07,375 INFO  [Tomcat5] Saw org.jboss.system.server.started notification, starting connectors
  | 11:32:07,484 INFO  [Http11Protocol] D?marrage de Coyote HTTP/1.1 sur http-0.0.0.0-8080
  | 11:32:08,000 INFO  [ChannelSocket] JK2: ajp13 listening on /0.0.0.0:8009
  | 11:32:08,015 INFO  [JkMain] Jk running ID=0 time=0/172  config=null

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

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



From do-not-reply at jboss.com  Fri Jan  5 06:10:06 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Fri, 5 Jan 2007 06:10:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - remove context
	sensitive menus
Message-ID: <21296581.1167995406752.JavaMail.jboss@colo-br-02.atl.jboss.com>

this topic is part of the web console feedback: http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback

I think it's better to remove the left-hand side context sensitive menus for task instance and process instance.

These navigations should be offered in the content of the page displayed.  See other web console feedback for more info.

That prevents unavailable links in the menu (or a jumping menu if you would make them dissappear if they are unavailable)

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

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


From do-not-reply at jboss.com  Fri Jan  5 06:12:12 2007
From: do-not-reply at jboss.com (radzish)
Date: Fri, 5 Jan 2007 06:12:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Portlet states
	strategy
Message-ID: <5115565.1167995532046.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi All!
I have the following requirement and do not see the way how to implement it on JBoss 2.4.0.

For all the portlets within one region the following strategy must be applied:
initially portlet1 is maximazed, all the rest are minimized;
if portletX is maximized, all the rest must be minimized;
if maximazed portletX is minimized, that portletX+1 is maximized.
in other words: within all the portlets of the region, one of them must be always maximized.

I was playing with layout strategy in order to implement this functionality, but unfortunatelly StrategyResponse.addWindowStateChange takes WindowContext as parameter, not WindowLocation and I have access to window locations of other portlets only.

Maybe somebody has other ideas how to solve my problem.

thanks in advance.

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

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


From do-not-reply at jboss.com  Fri Jan  5 06:14:00 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Fri, 5 Jan 2007 06:14:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1260 -
	Sequence containing 2 elements
Message-ID: <2693501.1167995640482.JavaMail.jboss@colo-br-02.atl.jboss.com>

Related to the partial unwrapping wscompile was doing what should we do if any of the message parts reference an element that is a simple type?  

e.g.

<s:element name="string" nillable="true" type="s:string" />

At the moment if the element references anything other than a complex type we reject the WSDL.

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

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


From do-not-reply at jboss.com  Fri Jan  5 06:52:17 2007
From: do-not-reply at jboss.com (radzish)
Date: Fri, 5 Jan 2007 06:52:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Portlet states
	strategy
Message-ID: <6144577.1167997937211.JavaMail.jboss@colo-br-02.atl.jboss.com>

There is one mistake in requirement description in my previous topic.
Instead of "maximized", "bring-to-normal-state" must be used.

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

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


From do-not-reply at jboss.com  Fri Jan  5 06:56:20 2007
From: do-not-reply at jboss.com (radzish)
Date: Fri, 5 Jan 2007 06:56:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Portlet states
	strategy
Message-ID: <29115529.1167998180389.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have found one sollution, it worksm but it is not proper enough:

I still use layout strategy approach. Currently WindowLocation is wrapper around WindowsContext, so I use reflection in order to get the context :), and then I pass it to StrategyResponse.addWindowStateChange in order to achieve mu goal.

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

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


From do-not-reply at jboss.com  Fri Jan  5 07:44:25 2007
From: do-not-reply at jboss.com (mythilisan)
Date: Fri, 5 Jan 2007 07:44:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Integration of third
	party CMS with JBoss portal
Message-ID: <3588632.1168001065563.JavaMail.jboss@colo-br-02.atl.jboss.com>

hi,

My requirement is to integrate any content management system like documentum,Interwoven with JBoss portal.
I am very new to working with JBoss portals.
I am confused whether this is feasible with jboss portals.
Please help me regarding this.

If you can provide any relevant docs/links, it would be very helpful.
Thanks in advance.

Regards,
Mythili

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

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


From do-not-reply at jboss.com  Fri Jan  5 08:17:27 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Fri, 5 Jan 2007 08:17:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - new simplified menu
	structure
Message-ID: <16708665.1168003047450.JavaMail.jboss@colo-br-02.atl.jboss.com>

I would like less navigation and more content in one page.  Here are the direct navigations that i would propose in the left hand menu:

Task list : shows 2 tables, the personal task list and the group task list.  The personal task list should be shown on top and only contains tasks that are assigned directly to the authenticated user.  From each task in the personal task list, the user should be able to navigate to the task instance view to perform the task.  

The group task list should show all tasks for which the authenticated user is in the pooled actors.  Note that the pooled actors list can also contain one of the groups for which the authenticated user is a member.  Also in that case, such  task should show up in the users group task list.  Users should might be able to navigate directly to the task instance view, but they should not be allowed to perform any operations on those tasks.  To do that, the user has to 'take' the group task into his/her personal task list.  'Taking' the task should be the only allowed operation on group tasks.  That prevents that multiple people start working on group tasks simultaniously. 

Processes : Should display a list of processes similar to the current Find Processes menu screen.  By default, this screen shows only the latest versions of the processes in alphabetical order.  Users should be able to sort and filter the list.  For each process, the user should be able to start a new process instance.

Search : Should display a search screen with a form to start searching for tasks, tokens and process instances.  From many locations in the webapplication, there will be links to this search page.  E.g. in a task instance page you could add a link 'Show all tokens for this process'.  There are many such convenience links thinkable and they should all point to the unified search page.

Reports : Should always display an overview of system-wide reports.  How many total number of instances.  How many transactions per minute/hour/day,  How many open tasks per user,  Avg time for task per user, ...

In case a process definition is selected, links to reports per process definition, should be shown as well.

Admin : Groups all admin functionality.  Currently I see 2 such functionalities.  Deploying a process as is already available.  And viewing/managing the job-and-timer queue.    I think that both of these two functionalities can currently be easily combined in one screen.

Logout

===============================================

Apart from those directly navigatable screens, i think that only 2 other screens are needed: task instance view and process instance view.

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

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


From do-not-reply at jboss.com  Fri Jan  5 08:28:01 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Fri, 5 Jan 2007 08:28:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - simplified task
	instance view
Message-ID: <22699969.1168003681640.JavaMail.jboss@colo-br-02.atl.jboss.com>

This topic is part of the web console feedback: http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback

I would like to have more data on one screen.  Especially for task instances, it would be great to combine the form, summary data and comments in one page.  This is what i have in mind:

http://wiki.jboss.org/wiki/attach?page=JbpmConsoleFeedback/task.instance.view.jpg

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

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


From do-not-reply at jboss.com  Fri Jan  5 08:39:18 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Fri, 5 Jan 2007 08:39:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - simplified process
	instance view
Message-ID: <3285902.1168004358182.JavaMail.jboss@colo-br-02.atl.jboss.com>

This topic is part of the web console feedback : http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback

I would like to have one central screen that combines all the process instance information : 
* general process instance properties (aka summary)
* open tasks
* variables
* comments
* tokens

I would put the diagram and history on separate tabs in the same page.  So 3 tabs in total.


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

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


From do-not-reply at jboss.com  Fri Jan  5 08:52:13 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Fri, 5 Jan 2007 08:52:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - direct navigation when
	starting a new process instance
Message-ID: <17856666.1168005133561.JavaMail.jboss@colo-br-02.atl.jboss.com>

This topic is part of the web console feedback: http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback

When starting a new process instance, the web console currently handles both processes without a start task form and with a start task form.

But in both cases, after clicking the 'Start It!' button, the user is navigated to an intermediate screen that only has 1 link.  I think that the user should be navigated directly to those referred pages.

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

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


From do-not-reply at jboss.com  Fri Jan  5 09:02:39 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Fri, 5 Jan 2007 09:02:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - replace separate
	managers task list view with generic search
Message-ID: <14829475.1168005759020.JavaMail.jboss@colo-br-02.atl.jboss.com>

This topic is part of the web console feedback: http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback

In stead of having a separate managers task list view, i think that these should be convenience options in the general search page.

If you're a manager, you should have various links in the search criteria options for this:

In case the user is searching for tasks, the user could be presented a list of his subordinates with a check box in front of each person.  Checking that box means that the manager will filter tasks for this person (these persons) and still the manager will be able to specify all other task instance criteria as well.

I don't think this has a high priority so i would not include this feature in 3.2

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

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


From do-not-reply at jboss.com  Fri Jan  5 09:18:15 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Fri, 5 Jan 2007 09:18:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - replace sources tabs
	with links
Message-ID: <25284234.1168006695768.JavaMail.jboss@colo-br-02.atl.jboss.com>

This topic is part of the web console feedback: http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback 

I would not display the sources for tasks and processes as separate tabs.  I would make them links in the task instance view and the process instance view.  Wether or not the links to the sources are visible should be configurable.  One configuration in jbpm.cfg.xml should control the visibility of all the source links.  

In the suite, i think it is a good idea to turn on those links.  As we will have more examples deployed out of the box and evaluators can then immediately browse the webapp and take a look at the sources.

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

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


From do-not-reply at jboss.com  Fri Jan  5 10:19:18 2007
From: do-not-reply at jboss.com (epbernard)
Date: Fri, 5 Jan 2007 10:19:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Component Proposal -
	Configurable Service Locator
Message-ID: <13424747.1168010358024.JavaMail.jboss@colo-br-02.atl.jboss.com>

Seam provide a JNDI binding strategy using an el

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

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


From do-not-reply at jboss.com  Fri Jan  5 10:20:27 2007
From: do-not-reply at jboss.com (jc7442)
Date: Fri, 5 Jan 2007 10:20:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Component Proposal -
	Configurable Service Locator
Message-ID: <21225912.1168010427636.JavaMail.jboss@colo-br-02.atl.jboss.com>

Sorry if it is not the right place for my comments.

My client application uses Spring framework as ServiceLocator. Injection is done using spring configuration files instead of annotations. 

>From my point of view one of the most important features of the ServiceLocator is to make client application source code independant of the technology used. With my "Spring" solution, client only see interfaces for the service. It does not have to know if the service is an EJB3, RMI, ... It is quite important for me in order to be able to reuse existing services (some of them are distibuted with RMI, others as EJB3 services and some of them with a custom distribution based on Corba).

Another requirements for a ServiceLocator is to be able to add at runtime some interceptors. For example, during the debug, I change the interceptor to provides some specific features such as chech that remote service are not invoked in Swing EventispatcherThread, measure time required to perform  a service, ... With Spring I have been able to do that (for stateless services only) using a MBean that force Spring framework to reload XML service description file.

JNDI parameters are in XMLs, they can be changed easily. 
Moving services from one EAR to another does not have impact on client source code but only on XMLs. 

Injection is performed on method not on field. 

>From your point of view is what I am doing wrong or is it just another way to do the same things ?



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

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


From do-not-reply at jboss.com  Fri Jan  5 10:21:01 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Fri, 5 Jan 2007 10:21:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: SELECT FOR UPDATE
	semantics
Message-ID: <14918988.1168010461385.JavaMail.jboss@colo-br-02.atl.jboss.com>

Is the options api the best/cleanest way to do this?

Like you said, as it only applies to pessimistic locking, it does seem fairly straightforward to implement.

Is there a JIRA task for this?

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

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


From do-not-reply at jboss.com  Fri Jan  5 10:42:56 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 5 Jan 2007 10:42:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Deployment through
	the ProfileService api
Message-ID: <5128316.1168011776979.JavaMail.jboss@colo-br-02.atl.jboss.com>

Now that I have tried to make this usable by a remote client this is not going to work. We need another DeploymentContentRepository view from the ProfileService that allows a more natural content repository view for adding/removing/associating content with a Profile. The Profile interface is then a server side notion for expressing the the active deployment content to the deployers.


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

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


From do-not-reply at jboss.com  Fri Jan  5 10:49:57 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Fri, 5 Jan 2007 10:49:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: SELECT FOR UPDATE
	semantics
Message-ID: <22236138.1168012197148.JavaMail.jboss@colo-br-02.atl.jboss.com>

"manik.surtani at jboss.com" wrote : Is the options api the best/cleanest way to do this?

Not sure about best.  It perturbs things the least.  The alternative I can think of would be to add a method to Cache.  But then all the interceptors that check for "get" calls would have to have that method(s) added.  And a target method would have to be added to CacheImpl.  With the Option, everyone is blissfully unaware except for PessimisticLockInterceptor.

anonymous wrote : Like you said, as it only applies to pessimistic locking, it does seem fairly straightforward to implement.

Yeah, I took a look at the interceptor yesterday to check for any gotcha, and it took me about 10 mins to add it w/ a simple 3-4 statement if block. Didn't test at all though.

anonymous wrote : Is there a JIRA task for this?

No, I wanted to check on the forum first whether people thought the whole concept was off. If you think its a useful feature, I'll open one.  Deciding exactly how to implement, timing, etc can come later.

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

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


From do-not-reply at jboss.com  Fri Jan  5 11:04:34 2007
From: do-not-reply at jboss.com (adamw)
Date: Fri, 5 Jan 2007 11:04:34 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Problems compiling
	JBoss Labs
Message-ID: <532261.1168013074414.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hello,
and how much RAM do you have? There is a couple of services started that take up some memory. Have you checked the server settings (-Xmm and -Xms in run.conf)?

-- 
Adam

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

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


From do-not-reply at jboss.com  Fri Jan  5 11:21:02 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Fri, 5 Jan 2007 11:21:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: SELECT FOR UPDATE
	semantics
Message-ID: <24536849.1168014062076.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | 
  | 
  | No, I wanted to check on the forum first whether people thought the whole concept was off. If you think its a useful feature, I'll open one. Deciding exactly how to implement, timing, etc can come later.
  | 
  | 

Useful enough, I guess, given the requests we've had for it.  I'd implement it as an option for now, and upgrade it to a full API feature in 2.2.0/3.0.0 timeframe if enough usage warrants it.

Found a JIRA task for it though: JBCACHE-629

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

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


From do-not-reply at jboss.com  Fri Jan  5 12:18:30 2007
From: do-not-reply at jboss.com (phillips4jc)
Date: Fri, 5 Jan 2007 12:18:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Out of Memory Error
	when Deploying JBoss Labs
Message-ID: <2318092.1168017510495.JavaMail.jboss@colo-br-02.atl.jboss.com>

After building successfully, I get an OutOfMemoryError when I try to deploy it. 

Here is the output

[root at B-0359 bin]# ./run.sh -c all
=========================================================================

JBoss Bootstrap Environment

JBOSS_HOME: /usr/local/portal

JAVA: /usr/lib/jdk1.5.0_09//bin/java

JAVA_OPTS: -Djava.security.auth.login.config=../conf/jaas.conf -javaagent:pluggable-instrumentor.jar -Dprogram.name=run.sh

CLASSPATH: /usr/local/portal/bin/run.jar:/usr/lib/jdk1.5.0_09//lib/tools.jar

=========================================================================

16:37:32,077 INFO [Server] Starting JBoss (MX MicroKernel)...
16:37:32,079 INFO [Server] Release ID: JBoss [Zion] 4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000)
16:37:32,081 INFO [Server] Home Dir: /usr/local/portal
16:37:32,081 INFO [Server] Home URL: file:/usr/local/portal/
16:37:32,082 INFO [Server] Patch URL: null
16:37:32,082 INFO [Server] Server Name: all
16:37:32,083 INFO [Server] Server Home Dir: /usr/local/portal/server/all
16:37:32,083 INFO [Server] Server Home URL: file:/usr/local/portal/server/all/
16:37:32,083 INFO [Server] Server Log Dir: /usr/local/portal/server/all/log
16:37:32,083 INFO [Server] Server Temp Dir: /usr/local/portal/server/all/tmp
16:37:32,084 INFO [Server] Root Deployment Filename: jboss-service.xml
16:37:32,674 INFO [ServerInfo] Java version: 1.5.0_09,Sun Microsystems Inc.
16:37:32,675 INFO [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.5.0_09-b01,Sun Microsystems Inc.
16:37:32,675 INFO [ServerInfo] OS-System: Linux 2.6.9-42.0.3.EL,i386
16:37:33,502 INFO [Server] Core system initialized
16:37:37,033 INFO [WebService] Using RMI server codebase: http://B-0359:8083/
16:37:37,071 INFO [Log4jService$URLWatchTimerTask] Configuring from URL: resource:log4j.xml
16:37:37,389 INFO [NamingService] JNDI bootstrap JNP=/0.0.0.0:1099, RMI=/0.0.0.0:1098, backlog=50, no client SocketFactory, Server SocketFactory=class org.jboss.net.sockets.DefaultSocketFactory
16:37:39,755 INFO [SocketServerInvoker] Invoker started for locator: InvokerLocator [socket://127.0.0.1:3873/]
16:37:41,552 INFO [AspectDeployer] Deployed AOP: file:/usr/local/portal/server/all/deploy/shotoku-aop.aop
16:37:41,759 INFO [AspectDeployer] Deployed AOP: file:/usr/local/portal/server/all/deploy/ejb3-interceptors-aop.xml
16:37:46,828 INFO [AspectDeployer] Deployed AOP: file:/usr/local/portal/server/all/deploy/jboss-portal.sar/portal-aop.xml
16:37:50,854 ERROR [STDERR] [warn] AOP Instrumentor failed to transform org.jboss.forge.common.projects.Projects
16:37:50,855 ERROR [STDERR] org.jboss.aop.instrument.TransformationException: Failed to aspectize class org.jboss.forge.common.projects.Projects. Could not find class it references org.jboss.forge.common.projects.ProjectDescriptor It may not be in your classpath and you may not be getting field and constructor weaving for this class.
16:37:50,856 ERROR [STDERR] at org.jboss.aop.instrument.Instrumentor.convertReferences(Instrumentor.java:619)
16:37:50,856 ERROR [STDERR] at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:673)
16:37:50,856 ERROR [STDERR] at org.jboss.aop.AspectManager.translate(AspectManager.java:970)
16:37:50,856 ERROR [STDERR] at org.jboss.aop.AspectManager.transform(AspectManager.java:882)
16:37:50,856 ERROR [STDERR] at org.jboss.aop.standalone.AOPTransformer.aspectTransform(AOPTransformer.java:88)
16:37:50,856 ERROR [STDERR] at org.jboss.aop.standalone.AOPTransformer.transform(AOPTransformer.java:75)
16:37:50,857 ERROR [STDERR] at sun.instrument.TransformerManager.transform(TransformerManager.java:122)
16:37:50,857 ERROR [STDERR] at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:155)
16:37:50,857 ERROR [STDERR] at java.lang.ClassLoader.defineClass1(Native Method)
16:37:50,857 ERROR [STDERR] at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
16:37:50,857 ERROR [STDERR] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
16:37:50,857 ERROR [STDERR] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
16:37:50,857 ERROR [STDERR] at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
16:37:50,857 ERROR [STDERR] at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
16:37:50,858 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method)
16:37:50,858 ERROR [STDERR] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
16:37:50,858 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.findClassLocally(RepositoryClassLoader.java:672)
16:37:50,858 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.findClass(RepositoryClassLoader.java:652)
16:37:50,858 ERROR [STDERR] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
16:37:50,858 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClassLocally(RepositoryClassLoader.java:190)
16:37:50,858 ERROR [STDERR] at org.jboss.mx.loading.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:131)
16:37:50,858 ERROR [STDERR] at org.jboss.mx.loading.LoadMgr3.nextTask(LoadMgr3.java:399)
16:37:50,859 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:517)
16:37:50,859 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:405)
16:37:50,859 ERROR [STDERR] at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
16:37:50,859 ERROR [STDERR] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
16:37:50,859 ERROR [STDERR] at java.lang.Class.getDeclaredMethods0(Native Method)
16:37:50,859 ERROR [STDERR] at java.lang.Class.privateGetDeclaredMethods(Class.java:2395)
16:37:50,860 ERROR [STDERR] at java.lang.Class.getDeclaredMethods(Class.java:1763)
16:37:50,860 ERROR [STDERR] at org.jboss.portal.common.mx.JavaBeanModelMBeanBuilder.(JavaBeanModelMBeanBuilder.java:89)
16:37:50,860 ERROR [STDERR] at org.jboss.portal.common.mx.JavaBeanModelMBeanBuilder.build(JavaBeanModelMBeanBuilder.java:287)
16:37:50,860 ERROR [STDERR] at org.jboss.portal.common.system.JBossServiceModelMBean.(JBossServiceModelMBean.java:76)
16:37:50,860 ERROR [STDERR] at sun.reflect.GeneratedConstructorAccessor11.newInstance(Unknown Source)
16:37:50,860 ERROR [STDERR] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
16:37:50,860 ERROR [STDERR] at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
16:37:50,861 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:1233)
16:37:50,861 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:286)
16:37:50,861 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:344)
16:37:50,861 ERROR [STDERR] at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
16:37:50,861 ERROR [STDERR] at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449)
16:37:50,861 ERROR [STDERR] at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
16:37:50,861 ERROR [STDERR] at org.jboss.system.ServiceController.install(ServiceController.java:226)
16:37:50,861 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
16:37:50,861 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
16:37:50,862 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:37:50,862 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
16:37:50,862 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:37:50,863 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:37:50,863 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
16:37:50,863 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:37:50,863 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:37:50,863 ERROR [STDERR] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
16:37:50,863 ERROR [STDERR] at $Proxy4.install(Unknown Source)
16:37:50,864 ERROR [STDERR] at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
16:37:50,865 ERROR [STDERR] at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
16:37:50,865 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
16:37:50,865 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
16:37:50,865 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
16:37:50,865 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
16:37:50,865 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:37:50,866 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
16:37:50,866 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:37:50,866 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:37:50,866 ERROR [STDERR] at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
16:37:50,866 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
16:37:50,866 ERROR [STDERR] at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
16:37:50,866 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
16:37:50,866 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:37:50,866 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:37:50,867 ERROR [STDERR] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
16:37:50,867 ERROR [STDERR] at $Proxy8.deploy(Unknown Source)
16:37:50,867 ERROR [STDERR] at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
16:37:50,867 ERROR [STDERR] at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
16:37:50,867 ERROR [STDERR] at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
16:37:50,867 ERROR [STDERR] at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
16:37:50,867 ERROR [STDERR] at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
16:37:50,868 ERROR [STDERR] at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
16:37:50,868 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
16:37:50,868 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:37:50,869 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
16:37:50,869 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:37:50,869 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:37:50,869 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
16:37:50,869 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:37:50,869 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:37:50,869 ERROR [STDERR] at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
16:37:50,870 ERROR [STDERR] at $Proxy0.start(Unknown Source)
16:37:50,870 ERROR [STDERR] at org.jboss.system.ServiceController.start(ServiceController.java:417)
16:37:50,870 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
16:37:50,870 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:37:50,870 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
16:37:50,870 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:37:50,871 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:37:50,871 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
16:37:50,871 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:37:50,871 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:37:50,871 ERROR [STDERR] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
16:37:50,871 ERROR [STDERR] at $Proxy4.start(Unknown Source)
16:37:50,871 ERROR [STDERR] at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
16:37:50,871 ERROR [STDERR] at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
16:37:50,872 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
16:37:50,872 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
16:37:50,872 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
16:37:50,872 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
16:37:50,872 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
16:37:50,872 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:37:50,872 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
16:37:50,872 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:37:50,872 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:37:50,873 ERROR [STDERR] at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
16:37:50,873 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
16:37:50,873 ERROR [STDERR] at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
16:37:50,873 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
16:37:50,873 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:37:50,873 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:37:50,873 ERROR [STDERR] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
16:37:50,873 ERROR [STDERR] at $Proxy5.deploy(Unknown Source)
16:37:50,873 ERROR [STDERR] at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
16:37:50,874 ERROR [STDERR] at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
16:37:50,874 ERROR [STDERR] at org.jboss.Main.boot(Main.java:200)
16:37:50,874 ERROR [STDERR] at org.jboss.Main$1.run(Main.java:464)
16:37:50,874 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595)
16:37:57,942 INFO [SubscriptionManager] Bound event dispatcher to java:/EventDispatcher
16:38:08,957 INFO [Ejb3Deployment] EJB3 deployment time took: 814
16:38:09,191 INFO [JmxKernelAbstraction] installing MBean: jboss.j2ee:jar=shotoku-base.ejb3,name=ShotokuServiceImpl,service=EJB3 with dependencies:
16:38:09,624 INFO [EJBContainer] STARTED EJB: org.jboss.shotoku.service.ShotokuServiceImpl ejbName: ShotokuServiceImpl
16:38:09,880 INFO [AdministratedService] Creating Shotoku service...
16:38:10,416 INFO [ContentManager] Added content manager: default, org.jboss.shotoku.svn.SvnContentManager
16:38:10,417 INFO [AdministratedService] ContentManager setup completed. Getting the default service timer interval...
16:38:10,417 INFO [AdministratedService] Shotoku service created.
16:38:10,421 INFO [AdministratedService] Starting Shotoku service...
16:38:10,421 INFO [AdministratedService] Starting main update thread...
16:38:10,430 INFO [AdministratedService] Starting update threads...
16:38:10,435 INFO [AdministratedService] Update thread count set to: 10.
16:38:10,436 INFO [AdministratedService] Reseting keys during update in cache items...
16:38:10,436 INFO [AdministratedService] Shotoku service started.
16:38:10,438 INFO [EJB3Deployer] Deployed: file:/usr/local/portal/server/all/deploy/shotoku.sar/shotoku-base.ejb3
16:38:11,996 INFO [SnmpAgentService] SNMP agent going active
16:38:12,334 INFO [AspectDeployer] Deployed AOP: file:/usr/local/portal/server/all/deploy/tc5-cluster.sar/tc5-cluster.aop
16:38:13,127 INFO [TreeCache] setting cluster properties from xml to: UDP(down_thread=false;enable_bundling=true;ip_ttl=2;loopback=false;max_bundle_size=64000;max_bundle_timeout=30;mcast_addr=230.1.2.7;mcast_port=45577;mcast_recv_buf_size=25000000;mcast_send_buf_size=640000;ucast_recv_buf_size=20000000;ucast_send_buf_size=640000;up_thread=false;use_incoming_packet_handler=true;use_outgoing_packet_handler=true):PING(down_thread=false;num_initial_members=3;timeout=2000;up_thread=false):MERGE2(down_thread=false;max_interval=100000;min_interval=20000;up_thread=false):FD(down_thread=false;max_tries=5;shun=true;timeout=2500;up_thread=false):VERIFY_SUSPECT(down_thread=false;timeout=1500;up_thread=false):pbcast.NAKACK(discard_delivered_msgs=true;down_thread=false;gc_lag=50;max_xmit_size=60000;retransmit_timeout=100,200,300,600,1200,2400,4800;up_thread=false;use_mcast_xmit=false):UNICAST(down_thread=false;timeout=300,600,1200,2400,3600;up_thread=false):pbcast.STABLE(desired_avg_gossip=50000;down_thread=false;max_bytes=2100000;stability_delay=1000;up_thread=false):pbcast.GMS(down_thread=false;join_retry_timeout=2000;join_timeout=3000;print_local_addr=true;shun=true;up_thread=false):FC(down_thread=false;max_credits=10000000;min_threshold=0.20;up_thread=false):FRAG2(down_thread=false;frag_size=60000;up_thread=false):pbcast.STATE_TRANSFER(down_thread=false;up_thread=false)
16:38:13,177 INFO [TreeCache] interceptor chain is:
class org.jboss.cache.interceptors.CallInterceptor
class org.jboss.cache.interceptors.PessimisticLockInterceptor
class org.jboss.cache.interceptors.UnlockInterceptor
class org.jboss.cache.interceptors.ReplicationInterceptor
16:38:13,178 INFO [TreeCache] cache mode is REPL_ASYNC
16:38:15,952 INFO [STDOUT]
-------------------------------------------------------
GMS: address is localhost:32845
-------------------------------------------------------
16:38:18,183 INFO [TreeCache] viewAccepted(): [localhost:32845|0] [localhost:32845]
16:38:18,215 INFO [TreeCache] my local address is localhost:32845
16:38:18,222 INFO [TreeCache] new cache is null (may be first member in cluster)
16:38:18,222 INFO [TreeCache] state could not be retrieved (must be first member in group)
16:38:18,222 INFO [TreeCache] Cache is started!!
16:38:18,684 INFO [Embedded] Catalina naming disabled
16:38:18,918 INFO [ClusterRuleSetFactory] Unable to find a cluster rule set in the classpath. Will load the default rule set.
16:38:18,921 INFO [ClusterRuleSetFactory] Unable to find a cluster rule set in the classpath. Will load the default rule set.
16:38:19,849 INFO [Http11BaseProtocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080
16:38:19,859 INFO [Catalina] Initialization processed in 938 ms
16:38:19,859 INFO [StandardService] Starting service jboss.web
16:38:19,871 INFO [StandardEngine] Starting Servlet Engine: Apache Tomcat/5.5.17
16:38:19,997 INFO [StandardHost] XML validation disabled
16:38:20,052 INFO [Catalina] Server startup in 193 ms
16:38:20,593 INFO [TomcatDeployer] deploy, ctxPath=/invoker, warUrl=.../deploy/httpha-invoker.sar/invoker.war/
16:38:21,379 INFO [WebappLoader] Dual registration of jndi stream handler: factory already defined
16:38:22,408 INFO [TomcatDeployer] deploy, ctxPath=/portal-cms, warUrl=.../deploy/jboss-portal.sar/portal-cms.war/
16:38:22,677 INFO [TomcatDeployer] deploy, ctxPath=/portal-core, warUrl=.../deploy/jboss-portal.sar/portal-core.war/
16:38:24,214 INFO [FacesConfigurator] Reading standard config org/apache/myfaces/resource/standard-faces-config.xml
16:38:24,442 INFO [FacesConfigurator] Reading config jar:file:/usr/local/portal/server/all/tmp/deploy/tmp62208jsf-facelets.jar!/META-INF/faces-config.xml
16:38:24,458 INFO [FacesConfigurator] Reading config jar:file:/usr/local/portal/server/all/tmp/deploy/tmp62226tomahawk.jar!/META-INF/faces-config.xml
16:38:24,556 INFO [FacesConfigurator] Reading config jar:file:/usr/local/portal/server/all/tmp/deploy/tmp62243tomahawk.jar!/META-INF/faces-config.xml
16:38:24,637 INFO [FacesConfigurator] Reading config /WEB-INF/faces-config.xml
16:38:25,096 ERROR [LocaleUtils] Locale name null or empty, ignoring
16:38:27,345 INFO [StartupServletContextListener] ServletContext '/usr/local/portal/server/all/./deploy/jboss-portal.sar/portal-core.war/' initialized.
16:38:27,586 INFO [TomcatDeployer] deploy, ctxPath=/portal, warUrl=.../deploy/jboss-portal.sar/portal-server.war/
16:38:28,149 INFO [TomcatDeployer] deploy, ctxPath=/jbossws, warUrl=.../tmp/deploy/tmp62257jbossws-exp.war/
16:38:28,453 INFO [TomcatDeployer] deploy, ctxPath=/juddi, warUrl=.../deploy/juddi-service.sar/juddiws.war/
16:38:28,635 INFO [RegistryServlet] Loading jUDDI configuration.
16:38:28,636 INFO [RegistryServlet] Resources loaded from: /WEB-INF/juddi.properties
16:38:28,637 INFO [RegistryServlet] Initializing jUDDI components.
16:38:31,150 INFO [Ejb3Deployment] EJB3 deployment time took: 107
16:38:31,221 INFO [JmxKernelAbstraction] installing MBean: jboss.j2ee:jar=forge-service.ejb3,name=ForgeService,service=EJB3 with dependencies:
16:38:31,221 INFO [JmxKernelAbstraction] shotoku:service=shotoku
16:38:31,279 INFO [EJBContainer] STARTED EJB: org.jboss.forge.service.ForgeService ejbName: ForgeService
16:38:31,326 INFO [AdministratedService] Creating Forge service...
16:38:32,620 INFO [ForgeService] Forge service created, with timer interval: 30000
16:38:32,621 INFO [AdministratedService] Starting Forge service...
16:38:32,622 INFO [AdministratedService] Forge service started.
16:38:32,622 INFO [EJB3Deployer] Deployed: file:/usr/local/portal/server/all/deploy/w-jboss-forge.sar/forge-service.ejb3
16:38:33,602 INFO [DefaultPartition] Initializing
16:38:33,764 INFO [STDOUT]
-------------------------------------------------------
GMS: address is localhost:32848 (additional data: 14 bytes)
-------------------------------------------------------
16:38:35,779 INFO [DefaultPartition] Number of cluster members: 1
16:38:35,779 INFO [DefaultPartition] Other members: 0
16:38:35,779 INFO [DefaultPartition] Fetching state (will wait for 30000 milliseconds):
16:38:35,779 INFO [DefaultPartition] New cluster view for partition DefaultPartition (id: 0, delta: 0) : [127.0.0.1:1099]
16:38:35,800 INFO [DefaultPartition] I am (127.0.0.1:1099) received membershipChanged event:
16:38:35,801 INFO [DefaultPartition] Dead members: 0 ([])
16:38:35,801 INFO [DefaultPartition] New Members : 0 ([])
16:38:35,801 INFO [DefaultPartition] All Members : 1 ([127.0.0.1:1099])
16:38:35,998 INFO [HANamingService] Started ha-jndi bootstrap jnpPort=1100, backlog=50, bindAddress=/0.0.0.0
16:38:36,017 INFO [DetachedHANamingService$AutomaticDiscovery] Listening on 0.0.0.0/0.0.0.0:1102, group=230.0.0.4, HA-JNDI address=127.0.0.1:1100
16:38:38,520 INFO [TomcatDeployer] deploy, ctxPath=/jbossmq-httpil, warUrl=.../deploy-hasingleton/jms/jbossmq-httpil.sar/jbossmq-httpil.war/
16:38:39,166 INFO [TreeCache] setting cluster properties from xml to: UDP(ip_mcast=true;ip_ttl=64;loopback=false;mcast_addr=228.1.2.3;mcast_port=45551;mcast_recv_buf_size=80000;mcast_send_buf_size=150000;ucast_recv_buf_size=80000;ucast_send_buf_size=150000):PING(down_thread=false;num_initial_members=3;timeout=2000;up_thread=false):MERGE2(max_interval=20000;min_interval=10000):FD(down_thread=true;shun=true;up_thread=true):VERIFY_SUSPECT(down_thread=false;timeout=1500;up_thread=false):pbcast.NAKACK(down_thread=false;gc_lag=50;max_xmit_size=8192;retransmit_timeout=600,1200,2400,4800;up_thread=false):UNICAST(down_thread=false;min_threshold=10;timeout=600,1200,2400;window_size=100):pbcast.STABLE(desired_avg_gossip=20000;down_thread=false;up_thread=false):FRAG(down_thread=false;frag_size=8192;up_thread=false):pbcast.GMS(join_retry_timeout=2000;join_timeout=5000;print_local_addr=true;shun=true):pbcast.STATE_TRANSFER(down_thread=false;up_thread=false)
16:38:39,244 INFO [TreeCache] setEvictionPolicyConfig(): [config: null]
16:38:39,262 WARN [TreeCache] No transaction manager lookup class has been defined. Transactions cannot be used
16:38:39,299 INFO [TreeCache] interceptor chain is:
class org.jboss.cache.interceptors.CallInterceptor
class org.jboss.cache.interceptors.PessimisticLockInterceptor
class org.jboss.cache.interceptors.CacheLoaderInterceptor
class org.jboss.cache.interceptors.UnlockInterceptor
class org.jboss.cache.interceptors.ReplicationInterceptor
class org.jboss.cache.interceptors.CacheStoreInterceptor
16:38:39,366 INFO [TreeCache] cache mode is REPL_SYNC
16:38:39,386 INFO [STDOUT]
-------------------------------------------------------
GMS: address is localhost:32851
-------------------------------------------------------
16:38:41,389 INFO [TreeCache] my local address is localhost:32851
16:38:41,389 INFO [TreeCache] state could not be retrieved (must be first member in group)
16:38:41,390 INFO [LRUPolicy] Starting eviction policy using the provider: org.jboss.ejb3.cache.tree.StatefulEvictionPolicy
16:38:41,390 INFO [LRUPolicy] Starting a eviction timer with wake up interval of (secs) 1
16:38:41,390 INFO [TreeCache] viewAccepted(): [localhost:32851|0] [localhost:32851]
16:38:41,390 INFO [TreeCache] new cache is null (may be first member in cluster)
16:38:41,391 INFO [TreeCache] Cache is started!!
16:38:41,488 INFO [TreeCache] setting cluster properties from xml to: UDP(ip_mcast=true;ip_ttl=2;loopback=false;mcast_addr=228.1.2.3;mcast_port=43333;mcast_recv_buf_size=80000;mcast_send_buf_size=150000;ucast_recv_buf_size=80000;ucast_send_buf_size=150000):PING(down_thread=false;num_initial_members=3;timeout=2000;up_thread=false):MERGE2(max_interval=20000;min_interval=10000):FD(down_thread=true;shun=true;up_thread=true):VERIFY_SUSPECT(down_thread=false;timeout=1500;up_thread=false):pbcast.NAKACK(down_thread=false;gc_lag=50;max_xmit_size=8192;retransmit_timeout=600,1200,2400,4800;up_thread=false):UNICAST(down_thread=false;min_threshold=10;timeout=600,1200,2400;window_size=100):pbcast.STABLE(desired_avg_gossip=20000;down_thread=false;up_thread=false):FRAG(down_thread=false;frag_size=8192;up_thread=false):pbcast.GMS(join_retry_timeout=2000;join_timeout=5000;print_local_addr=true;shun=true):pbcast.STATE_TRANSFER(down_thread=false;up_thread=false)
16:38:41,516 INFO [TreeCache] setEvictionPolicyConfig(): [config: null]
16:38:41,542 INFO [TreeCache] interceptor chain is:
class org.jboss.cache.interceptors.CallInterceptor
class org.jboss.cache.interceptors.PessimisticLockInterceptor
class org.jboss.cache.interceptors.UnlockInterceptor
class org.jboss.cache.interceptors.ReplicationInterceptor
16:38:41,547 INFO [TreeCache] cache mode is REPL_SYNC
16:38:41,646 INFO [STDOUT]
-------------------------------------------------------
GMS: address is localhost:32854
-------------------------------------------------------
16:38:43,650 INFO [TreeCache] my local address is localhost:32854
16:38:43,650 INFO [TreeCache] state could not be retrieved (must be first member in group)
16:38:43,650 INFO [LRUPolicy] Starting eviction policy using the provider: org.jboss.cache.eviction.LRUPolicy
16:38:43,650 INFO [LRUPolicy] Starting a eviction timer with wake up interval of (secs) 5
16:38:43,650 INFO [TreeCache] viewAccepted(): [localhost:32854|0] [localhost:32854]
16:38:43,651 INFO [TreeCache] new cache is null (may be first member in cluster)
16:38:43,651 INFO [TreeCache] Cache is started!!
16:38:50,304 INFO [CorbaNamingService] Naming: [IOR:000000000000002B49444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578744578743A312E3000000000000200000000000000D0000102000000000A3132372E302E302E31000DC8000000114A426F73732F4E616D696E672F726F6F74000000000000050000000000000008000000004A414300000000010000001C00000000000100010000000105010001000101090000000105010001000000210000004C000000000000000100000000000000240000001C0000007E00000000000000010000000A3132372E302E302E31000DC9000000000000000000000000000000000000000000000000000000000000002000000004000000000000001F0000000400000003000000010000002000000000000000020000002000000004000000000000001F0000000400000003]
16:38:51,003 INFO [CorbaTransactionService] TransactionFactory: [IOR:000000000000003049444C3A6F72672F6A626F73732F746D2F69696F702F5472616E73616374696F6E466163746F72794578743A312E30000000000200000000000000D0000102000000000A3132372E302E302E31000DC8000000144A426F73732F5472616E73616374696F6E732F46000000050000000000000008000000004A414300000000010000001C00000000000100010000000105010001000101090000000105010001000000210000004C000000000000000100000000000000240000001C0000007E00000000000000010000000A3132372E302E302E31000DC9000000000000000000000000000000000000000000000000000000000000002000000004000000000000001F0000000400000003000000010000002000000000000000020000002000000004000000000000001F0000000400000003]
16:38:53,447 INFO [TomcatDeployer] deploy, ctxPath=/web-console, warUrl=.../deploy/management/console-mgr.sar/web-console.war/
16:38:59,848 INFO [MailService] Mail Service bound to java:/Mail
16:39:00,340 INFO [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-ha-local-jdbc.rar
16:39:00,971 INFO [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-ha-xa-jdbc.rar
16:39:01,041 INFO [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-local-jdbc.rar
16:39:01,114 INFO [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-xa-jdbc.rar
16:39:01,773 INFO [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jms/jms-ra.rar
16:39:01,856 INFO [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/mail-ra.rar
16:39:02,518 INFO [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/quartz-ra.rar
16:39:03,357 INFO [QuartzResourceAdapter] start quartz!!!
16:39:03,408 ERROR [STDERR] [warn] AOP Instrumentor failed to transform org.quartz.impl.StdSchedulerFactory
16:39:03,408 ERROR [STDERR] org.jboss.aop.instrument.TransformationException: Failed to aspectize class org.quartz.impl.StdSchedulerFactory. Could not find class it references org.quartz.utils.PoolingConnectionProvider It may not be in your classpath and you may not be getting field and constructor weaving for this class.
16:39:03,409 ERROR [STDERR] at org.jboss.aop.instrument.Instrumentor.convertReferences(Instrumentor.java:619)
16:39:03,409 ERROR [STDERR] at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:673)
16:39:03,409 ERROR [STDERR] at org.jboss.aop.AspectManager.translate(AspectManager.java:970)
16:39:03,409 ERROR [STDERR] at org.jboss.aop.AspectManager.transform(AspectManager.java:882)
16:39:03,410 ERROR [STDERR] at org.jboss.aop.standalone.AOPTransformer.aspectTransform(AOPTransformer.java:88)
16:39:03,410 ERROR [STDERR] at org.jboss.aop.standalone.AOPTransformer.transform(AOPTransformer.java:75)
16:39:03,410 ERROR [STDERR] at sun.instrument.TransformerManager.transform(TransformerManager.java:122)
16:39:03,410 ERROR [STDERR] at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:155)
16:39:03,410 ERROR [STDERR] at java.lang.ClassLoader.defineClass1(Native Method)
16:39:03,410 ERROR [STDERR] at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
16:39:03,410 ERROR [STDERR] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
16:39:03,410 ERROR [STDERR] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
16:39:03,410 ERROR [STDERR] at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
16:39:03,411 ERROR [STDERR] at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
16:39:03,411 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method)
16:39:03,411 ERROR [STDERR] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
16:39:03,411 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.findClassLocally(RepositoryClassLoader.java:672)
16:39:03,412 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.findClass(RepositoryClassLoader.java:652)
16:39:03,412 ERROR [STDERR] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
16:39:03,412 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClassLocally(RepositoryClassLoader.java:190)
16:39:03,412 ERROR [STDERR] at org.jboss.mx.loading.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:131)
16:39:03,412 ERROR [STDERR] at org.jboss.mx.loading.LoadMgr3.nextTask(LoadMgr3.java:399)
16:39:03,412 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:517)
16:39:03,412 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:405)
16:39:03,413 ERROR [STDERR] at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
16:39:03,413 ERROR [STDERR] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
16:39:03,413 ERROR [STDERR] at org.jboss.resource.adapter.quartz.inflow.QuartzResourceAdapter.start(QuartzResourceAdapter.java:53)
16:39:03,413 ERROR [STDERR] at org.jboss.resource.deployment.RARDeployment.startService(RARDeployment.java:109)
16:39:03,413 ERROR [STDERR] at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
16:39:03,413 ERROR [STDERR] at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
16:39:03,413 ERROR [STDERR] at org.jboss.system.ServiceDynamicMBeanSupport.invoke(ServiceDynamicMBeanSupport.java:124)
16:39:03,414 ERROR [STDERR] at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
16:39:03,414 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:39:03,414 ERROR [STDERR] at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
16:39:03,414 ERROR [STDERR] at $Proxy0.start(Unknown Source)
16:39:03,414 ERROR [STDERR] at org.jboss.system.ServiceController.start(ServiceController.java:417)
16:39:03,414 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
16:39:03,414 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:39:03,414 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
16:39:03,415 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:39:03,415 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:39:03,415 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
16:39:03,416 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:39:03,416 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:39:03,416 ERROR [STDERR] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
16:39:03,416 ERROR [STDERR] at $Proxy123.start(Unknown Source)
16:39:03,416 ERROR [STDERR] at org.jboss.deployment.SimpleSubDeployerSupport.startService(SimpleSubDeployerSupport.java:345)
16:39:03,416 ERROR [STDERR] at org.jboss.deployment.SimpleSubDeployerSupport.start(SimpleSubDeployerSupport.java:127)
16:39:03,416 ERROR [STDERR] at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
16:39:03,416 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
16:39:03,416 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
16:39:03,417 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
16:39:03,417 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:39:03,417 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
16:39:03,417 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:39:03,417 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:39:03,417 ERROR [STDERR] at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
16:39:03,417 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
16:39:03,418 ERROR [STDERR] at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
16:39:03,418 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
16:39:03,418 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:39:03,418 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:39:03,418 ERROR [STDERR] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
16:39:03,418 ERROR [STDERR] at $Proxy8.deploy(Unknown Source)
16:39:03,418 ERROR [STDERR] at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
16:39:03,418 ERROR [STDERR] at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
16:39:03,418 ERROR [STDERR] at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
16:39:03,419 ERROR [STDERR] at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
16:39:03,419 ERROR [STDERR] at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
16:39:03,419 ERROR [STDERR] at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
16:39:03,419 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
16:39:03,419 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:39:03,419 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
16:39:03,419 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:39:03,419 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:39:03,420 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
16:39:03,420 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:39:03,420 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:39:03,420 ERROR [STDERR] at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
16:39:03,420 ERROR [STDERR] at $Proxy0.start(Unknown Source)
16:39:03,420 ERROR [STDERR] at org.jboss.system.ServiceController.start(ServiceController.java:417)
16:39:03,420 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
16:39:03,420 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:39:03,421 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
16:39:03,421 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:39:03,421 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:39:03,421 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
16:39:03,421 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:39:03,421 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:39:03,421 ERROR [STDERR] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
16:39:03,421 ERROR [STDERR] at $Proxy4.start(Unknown Source)
16:39:03,421 ERROR [STDERR] at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
16:39:03,422 ERROR [STDERR] at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
16:39:03,422 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
16:39:03,422 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
16:39:03,422 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
16:39:03,422 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
16:39:03,422 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
16:39:03,422 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
16:39:03,422 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
16:39:03,422 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
16:39:03,423 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
16:39:03,423 ERROR [STDERR] at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
16:39:03,423 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
16:39:03,423 ERROR [STDERR] at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
16:39:03,423 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
16:39:03,423 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
16:39:03,423 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
16:39:03,423 ERROR [STDERR] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
16:39:03,424 ERROR [STDERR] at $Proxy5.deploy(Unknown Source)
16:39:03,424 ERROR [STDERR] at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
16:39:03,424 ERROR [STDERR] at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
16:39:03,424 ERROR [STDERR] at org.jboss.Main.boot(Main.java:200)
16:39:03,424 ERROR [STDERR] at org.jboss.Main$1.run(Main.java:464)
16:39:03,424 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595)
16:39:06,357 INFO [SimpleThreadPool] Job execution threads will use class loader of thread: main
16:39:07,167 INFO [QuartzScheduler] Quartz Scheduler v.1.5.2 created.
16:39:07,730 INFO [RAMJobStore] RAMJobStore initialized.
16:39:07,731 INFO [StdSchedulerFactory] Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties'
16:39:07,731 INFO [StdSchedulerFactory] Quartz scheduler version: 1.5.2
16:39:07,732 INFO [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
16:39:09,487 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=LabsDS' to JNDI name 'java:LabsDS'
16:39:33,617 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
16:40:07,877 ERROR [STDERR] [warn] AOP Instrumentor failed to transform org.hsqldb.persist.NIOScaledRAFile
16:40:07,877 ERROR [STDERR] java.lang.OutOfMemoryError: Java heap space

*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at ../../../src/share/instrument/JPLISAgent.c line: 801
16:41:58,836 WARN [ServiceController] Problem starting service jboss.mq:service=DestinationManager
java.lang.OutOfMemoryError: Java heap space
16:42:11,338 ERROR [BasicMBeanRegistry] Cannot register MBean
java.lang.OutOfMemoryError: Java heap space
16:42:24,420 ERROR [BasicMBeanRegistry] Cannot register MBean
java.lang.OutOfMemoryError: Java heap space
16:42:27,280 ERROR [BasicMBeanRegistry] Cannot register MBean
java.lang.OutOfMemoryError: Java heap space
16:42:40,520 ERROR [MainDeployer] Could not initialise deployment: file:/usr/local/portal/server/all/deploy/jms/hajndi-jms-ds.xml
java.lang.OutOfMemoryError: Java heap space 

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

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



From do-not-reply at jboss.com  Fri Jan  5 12:32:19 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Fri, 5 Jan 2007 12:32:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: SELECT FOR UPDATE
	semantics
Message-ID: <22313458.1168018339418.JavaMail.jboss@colo-br-02.atl.jboss.com>

Geez, my search skills need a serious upgrade. :(

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

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


From do-not-reply at jboss.com  Fri Jan  5 13:15:14 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Fri, 5 Jan 2007 13:15:14 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - remoting various
	services
Message-ID: <33350152.1168020914544.JavaMail.jboss@colo-br-02.atl.jboss.com>

What are we using to remote services deployed?  I want to refactor JNDI so that it uses AOP Remoting (what EJB3 uses).  Since JBoss Remoting is URL based, there is no need for two sockets now for JNDI (stub/rmi). Also if the service is layered.


But... is there a different plan to remote services?


thx

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

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


From do-not-reply at jboss.com  Fri Jan  5 13:24:38 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 5 Jan 2007 13:24:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Aspect integration to bootstrap classes
Message-ID: <3759852.1168021478265.JavaMail.jboss@colo-br-02.atl.jboss.com>

The question is should be drop the jboss-aop-mc-int-boot.jar and
allow for use of aspects in the bootstrap-beans.xml. What I'm needing to
do is the equivalent of adding these aspects/pointcuts:


  |    <aspect name="persist"
  | class="org.jboss.profileservice.aop.PersistAdvice"/>
  |    <aspect name="mainDeployer"
  | class="org.jboss.profileservice.aop.MainDeployerAdvice"/>
  |    <bind pointcut="execution(*
  | $instanceof{org.jboss.deployers.spi.deployment.MainDeployer}->process(..))">
  |       <advice name="process" aspect="mainDeployer"/>
  |    </bind>
  |    <bind pointcut="execution(*
  | $instanceof{org.jboss.managed.api.ManagedProperty}->setValue(..))">
  |       <advice name="setValue" aspect="persist"/>
  |    </bind>
  | 

Are there aop/mc integration constructs that already allow for this?


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

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


From do-not-reply at jboss.com  Fri Jan  5 13:28:34 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 5 Jan 2007 13:28:34 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: remoting various
	services
Message-ID: <15165500.1168021714301.JavaMail.jboss@colo-br-02.atl.jboss.com>

The basic plan was to align all transports on remoting 2.0:
http://jira.jboss.com/jira/browse/JBAS-3925

which includes updating the NamingService.
http://jira.jboss.com/jira/browse/JBAS-3927


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

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


From do-not-reply at jboss.com  Fri Jan  5 13:38:15 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Fri, 5 Jan 2007 13:38:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: remoting various
	services
Message-ID: <32736835.1168022295270.JavaMail.jboss@colo-br-02.atl.jboss.com>

Well, AOPRemoting sits on top of JBoss Remoting...If we use AOP Remoting we will be able to cluster(request failover) and secure JNDI fairly easily.

The question is, what module should this code live?

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

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


From do-not-reply at jboss.com  Fri Jan  5 14:36:24 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Fri, 5 Jan 2007 14:36:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - PojoCache uses a
	special node factory
Message-ID: <10805346.1168025784550.JavaMail.jboss@colo-br-02.atl.jboss.com>

Quick brain dump...

I think PojoCache has some issue with its _JBossInternal_ node(s) -- things like data versioning changes with optimistic locking, potential lock contention due to the large number of child nodes, etc.

One thing I noticed is the Configuration.getRuntimeConfig() object now exposes the NodeFactory as a property.  This means PojoCache can set the NodeFactory to something specific to PojoCache.  This opens up the possibility of having a specialized factory create specialized nodes for _JBossInternal_.  For example, one whose data version is always 0, or that has a more complex structure for holding child nodes to avoid lock conflicts, etc.


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

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


From do-not-reply at jboss.com  Fri Jan  5 14:58:15 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Fri, 5 Jan 2007 14:58:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Problem deploying
	a -beans.xml in a SAR
Message-ID: <10959730.1168027095596.JavaMail.jboss@colo-br-02.atl.jboss.com>

I get the same error when hot-deploying a .jar with a META-INF/beans.xml from the aop testsuite. (In case you wonder I commented out the aspect from the test):

19:56:12,593 ERROR [BeanMetaDataDeployer] Error during deployment: jboss:id=aop-mc-defaultannotationtest.jar,service=jacc
  | org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=Bean
  |         at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
  |         at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:71)
  |         at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42)
  |         at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:53)
  |         at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52)
  |         at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:145)
  |         at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:440)
  |         at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:451)
  |         at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:451)
  |         at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:381)
  |         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:795)
  |         at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:570)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  |         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  |         at java.lang.reflect.Method.invoke(Method.java:585)
  |         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
  |         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
  |         at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
  |         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
  |         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  |         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  |         at java.lang.reflect.Method.invoke(Method.java:585)
  |         at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  |         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  |         at java.lang.reflect.Method.invoke(Method.java:585)
  |         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
  |         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
  |         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
  |         at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
  |         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
  |         at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
  |         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
  |         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
  |         at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  |         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  |         at java.lang.reflect.Method.invoke(Method.java:585)
  |         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
  |         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
  |         at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
  |         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
  |         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
  |         at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:816)
  |         at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:417)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  |         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  |         at java.lang.reflect.Method.invoke(Method.java:585)
  |         at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
  |         at sun.rmi.transport.Transport$1.run(Transport.java:153)
  |         at java.security.AccessController.doPrivileged(Native Method)
  |         at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
  |         at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
  |         at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
  |         at java.lang.Thread.run(Thread.java:595)
  | Caused by: java.lang.IllegalStateException: jboss.aop:name=Bean is already installed.
  |         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:249)
  |         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:177)
  |         at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:67)
  |         ... 59 more
  | 

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

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


From do-not-reply at jboss.com  Fri Jan  5 15:02:11 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Fri, 5 Jan 2007 15:02:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Metadata merged in head
Message-ID: <4525856.1168027331423.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have commited Adrian's work on the metadata to head:

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=85442&start=10

You will need to update the aop and microcontainer (aop-mc-int, container and kernel) jars




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

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


From do-not-reply at jboss.com  Fri Jan  5 15:08:07 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Fri, 5 Jan 2007 15:08:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	Metadata rewrite
Message-ID: <30932582.1168027687812.JavaMail.jboss@colo-br-02.atl.jboss.com>

This has been commited to head.

The only reason I added the KCCA to AOPConstructorJoinPoint was to allow the insertion of the ControllerContext - I'll see if I can do the required work in another place. If not, I need some interface to inject it, but don't particularly care what it is called

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

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


From do-not-reply at jboss.com  Fri Jan  5 15:21:11 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Fri, 5 Jan 2007 15:21:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: remove context
	sensitive menus
Message-ID: <21921666.1168028471252.JavaMail.jboss@colo-br-02.atl.jboss.com>

I agree with Tom. I had problems understanding the left-hand side context menus:

No Task Available

No Process Available

In particular, a submenu says No Definitions, yet I know I have process definitions deployed. 

I also have a comment on Terminology. We seem to be equating Processes with ProcessDefinitions. This is okay, most users don't like to say processdefinitions, but we must always be clear when dealing with instances that we say ProcessInstances, so that the difference is clear.

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

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


From do-not-reply at jboss.com  Fri Jan  5 15:34:48 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Fri, 5 Jan 2007 15:34:48 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <12483316.1168029288264.JavaMail.jboss@colo-br-02.atl.jboss.com>

I agree with Tom with a few comments / additions:

On Task list: a common term for "take" is "acquire". So you might name the button that performs this operation "acquire". In some applications users will acquire the task from the tasklist, and the act of acquiring will navigate to the TaskInstance page. On the other hand, you could let the user navigate to the TaskInstance page and then acquire (but this would be a less common way of designing this).

When the user acquires a task, you should set the actorId (this is probably obvious), and also start it (this is good for reporting purposes). Having acquired a task from the group task list, the user should be able to release it (set ActorId back to null) on the TaskInstance page, and close the page.

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

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


From do-not-reply at jboss.com  Fri Jan  5 15:39:49 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Fri, 5 Jan 2007 15:39:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: simplified task
	instance view
Message-ID: <17118038.1168029589879.JavaMail.jboss@colo-br-02.atl.jboss.com>

I agree with Tom. I would also like to add that I don't like End Task for the name of the button. Even though the API is end, users would be more comforatable with "Complete", as it signifies that they have completed the task.

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

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


From do-not-reply at jboss.com  Fri Jan  5 15:45:28 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Fri, 5 Jan 2007 15:45:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: simplified process
	instance view
Message-ID: <25480793.1168029928684.JavaMail.jboss@colo-br-02.atl.jboss.com>

I agree with Tom.

Just want to mention that the navigation from Processes (i.e., ProcessDefinitions) to ProcessInstances to single ProcessInstance makes sense, and don't want to lose that (don't think that is anyone's intention, but it has not been mentioned in any of Tom's comments).

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

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


From do-not-reply at jboss.com  Fri Jan  5 15:51:08 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 5 Jan 2007 15:51:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: remoting various
	services
Message-ID: <1905172.1168030268754.JavaMail.jboss@colo-br-02.atl.jboss.com>

the transport integration is currently in the server module around the NamingService and detached invoker stuff. Just refactor it there under org.jboss.naming for now.

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

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


From do-not-reply at jboss.com  Fri Jan  5 15:57:19 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Fri, 5 Jan 2007 15:57:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: direct navigation
	when starting a new process instance
Message-ID: <18793262.1168030639889.JavaMail.jboss@colo-br-02.atl.jboss.com>

This is a bit tricky, because these are really two different scenarios here.

1) if Start-task - then user should be navigated to the page to perform the task, i.e. fill in the form.

2) no Start-task - typically the user that started the process will not perform the first task in the process (otherwise we could have modelled their task at the start). So they should not navigate to a task-related page. Question is where to take them. What they would probably most like to see is the list of started processInstances, and see the one they just started in that list, or the ProcessInstance View for that particular instance that they just started.

By the way, with the websale process I get an exception from the TaskInstance page when i hit the End task button:

javax.el.PropertyNotFoundException: /main/task/new_tasks.xhtml @41,57 value="#{entry.taskInstance.id}": Property 'taskInstance' is not found on type: java.lang.String


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

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


From do-not-reply at jboss.com  Fri Jan  5 16:02:46 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Fri, 5 Jan 2007 16:02:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: replace separate
	managers task list view with generic se
Message-ID: <31688503.1168030966526.JavaMail.jboss@colo-br-02.atl.jboss.com>

I don't see how we can show this without sample identity data that provides a manager / subordinate relationship. So I agree with Tom that it should be deferred.

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

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


From do-not-reply at jboss.com  Fri Jan  5 16:03:16 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Fri, 5 Jan 2007 16:03:16 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: replace sources
	tabs with links
Message-ID: <7395672.1168030996960.JavaMail.jboss@colo-br-02.atl.jboss.com>

Agreed

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

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


From do-not-reply at jboss.com  Fri Jan  5 16:07:11 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Fri, 5 Jan 2007 16:07:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Console performance
Message-ID: <30796357.1168031231374.JavaMail.jboss@colo-br-02.atl.jboss.com>

It is not clear if we intend the web console as just an example to get started with, or do we think users will use it in production, in particular for view processinstances, etc.

If the later, we should test the performance at some point. In particular the response time for task list and processinstance list when there are hundreds or thousands of instance in either list.

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

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


From do-not-reply at jboss.com  Fri Jan  5 19:46:11 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Fri, 5 Jan 2007 19:46:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - AOP
	Tests
Message-ID: <27624539.1168044371492.JavaMail.jboss@colo-br-02.atl.jboss.com>

I've got most of the tests passing again with jdk 5 now, apart from the following two.

1) org.jboss.test.aop.bridgemethodnotwoven.BridgeMethodTestCase(jdk50)

This is due to a fix that was put into JavassistMethodHashing, which in turn broke the MethodHashingTestCase (which was disabled for a while, waiting for a release of MC). I've fixed JavassistMethodHashing so that MethodHashingTestCase, which is the acid test runs again. BridgeMethodTestCase needs to be looked at again though.

The other failing test on jdk 5 is 
2)org.jboss.test.aop.regression.jbaop248annotationoverride.AnnotationOverrideTestCase(javaagent-genadvisor-tests), which passes in all the other modes it is run.

Most of the failures were fixed using privileged blocks, it seems that later updates of JDK 5 are more strict when it comes to security?!

We need to look at the JDK 1.4 tests as well, for them to pass we need a retroed version of the mc/container project, and iirc there were some problems with that due to some new features in the codebase not supported in jboss retro :-(



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

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


From do-not-reply at jboss.com  Sat Jan  6 05:41:40 2007
From: do-not-reply at jboss.com (bazoo)
Date: Sat, 6 Jan 2007 05:41:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <10008064.1168080100128.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi all, great work on the console. A few questions/suggestions from a BA point of view:

General comment is that I think the navigation could be simplified without affecting functionality. 

The Process menu shows "No Instance" and "No Definition", when I first start the server, even though I definitely do have a process definition in there. 

I don't really understand the point of the Task menu, given that you can navigate to the task through the user task list, which is a more natural way to get to the screen.

I would suggest that "Start new instance" should be more easy to find. It takes a bit of hunting around before you can work out how to start a new instance. If anything it should be a sub-menu item underneath Process.

Responding to Jeff's suggestion, I would suggest that "acquire" has a slightly different meaning to "take". Semantics I know, but what is wrong with "Take" anyway?

I would not incorporate the "Search for instance" row in the task list, at least not at the top. For someone new to the app, you don't immediately notice that you have a task in the task list because it is hidden in small text underneath the big search boxes. You immediately think you have to perform a search, even though you may not have to.

Why doesn't the Task Instance and Definition view become active until I have "Viewed" the task in the User Task List? Surely it should become active as soon as there is a task. 

Why can any old user re-assign a task? I would have thought that given we have assigned a task to a particular swimlane in the process definition then that swimlane should do the task, unless there is some exceptional reason. I would have thought this functionality should be restricted to "managers". Otherwise people will not do any work and will just re-assign tasks to other people all the time!

I don't understand what the "Task Definition View" is really. 

I don't think the Summary page should be the first page you see when you click Task Instance View. I think it should be the Task Form to minimize clicking.

Instead of "End Task", I would suggest "Proceed", to reinforce the idea that the user is moving through a process.

I get the following exception when I click "End task" or "More info needed", although the transition does happen: javax.el.PropertyNotFoundException: /main/task/new_tasks.xhtml @41,57 value="#{entry.taskInstance.id}": Property 'taskInstance' is not found on type: java.lang.String

I would suggest that "User Task List" should be at the top of the navigation menu, especially as it is the view you go to first when you log in.

When you start a new instance of a process, the console has a "show details" link. If I click it it just comes back telling me the task instance ID. I don't think that's really worth hiding!

Cheers
Matt

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

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


From do-not-reply at jboss.com  Sat Jan  6 07:17:41 2007
From: do-not-reply at jboss.com (timfox)
Date: Sat, 6 Jan 2007 07:17:41 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- JBM and JBossMQ destroQueue/Topic
Message-ID: <26415784.1168085861133.JavaMail.jboss@colo-br-02.atl.jboss.com>

The JBossMQ destroyQueue/Topic JMX method actually deletes all messages from the destination then undeploys it.

Our version just undeploys the destination - was this intentional?

I would have thought we want to do the same as JBoss MQ?

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

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


From do-not-reply at jboss.com  Sat Jan  6 07:25:54 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Sat, 6 Jan 2007 07:25:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBM and JBossMQ destroQueue/Topic
Message-ID: <21964032.1168086354920.JavaMail.jboss@colo-br-02.atl.jboss.com>

Tim wrote : Our version just undeploys the destination - was this intentional? 
No

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

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


From do-not-reply at jboss.com  Sat Jan  6 08:28:05 2007
From: do-not-reply at jboss.com (mig)
Date: Sat, 6 Jan 2007 08:28:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Problem with deploying EJB
	2.1 with EJB3Deployer
Message-ID: <29219554.1168090085867.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hey there. I've been given a task to analyze the possibility of deploying EJB 2.1 along with EJB 3.0. I am trying to deploy Stateless session beans only... both 2.1 and 3.0. However, after installing EJB 3.0 RC9 Patch 1 on JBoss 4.0.5 GA I failed to deploy the application. Along other exceptions, when deploying the beans I get following exception from the EJB3Deployer:

13:59:59,273 WARN  [ServiceController] Problem creating service jboss.j2ee:service=EJB3,module=test-ejb.jar
java.lang.NoSuchMethodException: sk.test.IndexBean.create()
        at java.lang.Class.getMethod(Class.java:1581)
        at org.jboss.ejb3.Ejb3DescriptorHandler.addAnnotations(Ejb3DescriptorHandler.java:1800)
        at org.jboss.ejb3.Ejb3DescriptorHandler.addSecurityAnnotations(Ejb3DescriptorHandler.java:759)
        at org.jboss.ejb3.Ejb3DescriptorHandler.addDescriptorAnnotations(Ejb3DescriptorHandler.java:613)
        at org.jboss.ejb3.Ejb3DescriptorHandler.getStatelessContainer(Ejb3DescriptorHandler.java:309)
        at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:130)
        at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:409)
        at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:397)
        at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:378)
        at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:350)
        at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:305)
        at org.jboss.ejb3.Ejb3Module.createService(Ejb3Module.java:77)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:260)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:243)
        at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
        at $Proxy0.create(Unknown Source)
        at org.jboss.system.ServiceController.create(ServiceController.java:330)
        at org.jboss.system.ServiceController.create(ServiceController.java:273)
        at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy29.create(Unknown Source)
        at org.jboss.ejb3.EJB3Deployer.create(EJB3Deployer.java:429)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
        at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
        at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
        at org.jboss.ws.integration.jboss.DeployerInterceptor.create(DeployerInterceptor.java:74)
        at org.jboss.ws.integration.jboss.DeployerInterceptorEJB.create(DeployerInterceptorEJB.java:44)
        at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
        at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy30.create(Unknown Source)
        at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
        at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy8.deploy(Unknown Source)
        at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
        at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
        at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
        at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
        at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
        at $Proxy0.start(Unknown Source)
        at org.jboss.system.ServiceController.start(ServiceController.java:417)
        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy4.start(Unknown Source)
        at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
        at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy5.deploy(Unknown Source)
        at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
        at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
        at org.jboss.Main.boot(Main.java:200)
        at org.jboss.Main$1.run(Main.java:490)


The mentioned IndexBean extends SessionBean and hence really does not contain the lifecycle create() method, which resides in IndexHome extends EJBHome. Any ideas why does this not work? Thanks.

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

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


From do-not-reply at jboss.com  Sat Jan  6 10:09:29 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Sat, 6 Jan 2007 10:09:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <14621385.1168096169184.JavaMail.jboss@colo-br-02.atl.jboss.com>

take vs acquire:  +1 for 'take' for non english people it is more 'natural'. The translations to dutch for take and acquire also favour take.



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

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


From do-not-reply at jboss.com  Sat Jan  6 10:10:57 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Sat, 6 Jan 2007 10:10:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: simplified task
	instance view
Message-ID: <31963537.1168096257795.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes, complete sounds better.

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

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


From do-not-reply at jboss.com  Sat Jan  6 10:15:27 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Sat, 6 Jan 2007 10:15:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: replace sources
	tabs with links
Message-ID: <17262801.1168096528009.JavaMail.jboss@colo-br-02.atl.jboss.com>

I do not fully agree, how do they open then? In a new page? Or inline in a 'stack panel' instead of a tabpanel? If it is in a new page, how do I navigate back? I do not want to use the menu for that (my opinion) Tabs can be made hidden as well, so I'm in favour of keeping them on the tabs

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

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


From do-not-reply at jboss.com  Sat Jan  6 12:20:18 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Sat, 6 Jan 2007 12:20:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: user based process
	versioning ?
Message-ID: <13703455.1168104018271.JavaMail.jboss@colo-br-02.atl.jboss.com>

Since 3.1.2 (and correct in 3.1.3) the processdefinition is stored in the database as plain xml as well. Generating (and comparing) a hash for both the latest pd in the DB and the pd that is provided is fairly simple. It's none intrusive, backwards compatible etc..etc.. 

Normalization should take place to prevent reformatting leading to a new deployment. Maybe even a "reordering"   kind of normalization since switching two nodes in jbpm does not lead to a different executional process. So start task first, then all generic nodes, task nodes etc..etc..etc... Or a reordering based on node name is another option (but what about the elements/attributs IN nodes.. hmmm...

comments?

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

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


From do-not-reply at jboss.com  Sat Jan  6 13:16:33 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Sat, 6 Jan 2007 13:16:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <6481417.1168107393323.JavaMail.jboss@colo-br-02.atl.jboss.com>

Take vs. Acquire: How about "Assign to me".  We don't need to create new terminology for this function in my opinion.

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

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


From do-not-reply at jboss.com  Sat Jan  6 13:23:47 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Sat, 6 Jan 2007 13:23:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: direct navigation
	when starting a new process instance
Message-ID: <30857191.1168107827026.JavaMail.jboss@colo-br-02.atl.jboss.com>

"jeffdelong" wrote : By the way, with the websale process I get an exception from the TaskInstance page when i hit the End task button:
  | 
  | javax.el.PropertyNotFoundException: /main/task/new_tasks.xhtml @41,57 value="#{entry.taskInstance.id}": Property 'taskInstance' is not found on type: java.lang.String
  | 

This was a typo... it should be fixed now, sorry.

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

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


From do-not-reply at jboss.com  Sat Jan  6 14:12:01 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Sat, 6 Jan 2007 14:12:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <20987956.1168110721877.JavaMail.jboss@colo-br-02.atl.jboss.com>

even better, but in a link form then or a (rather large) button?

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

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


From do-not-reply at jboss.com  Sat Jan  6 14:13:16 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Sat, 6 Jan 2007 14:13:16 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <990192.1168110796911.JavaMail.jboss@colo-br-02.atl.jboss.com>

I  mean... if it is in a datatable, 'assign to me' in a button form would make the form rather crowded

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

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


From do-not-reply at jboss.com  Sat Jan  6 16:11:21 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Sat, 6 Jan 2007 16:11:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - When should the
	webconsole mark tasks as started?
Message-ID: <32822892.1168117881306.JavaMail.jboss@colo-br-02.atl.jboss.com>

This topic is part of the web console feedback: http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback 

Currently the tasks are never marked 'started'. There are several options
- once the task form is opened
- once the task is saved the first time (but what if not saved at all)
- ....

I think it should be marked started when the taskform is opened

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

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


From do-not-reply at jboss.com  Sat Jan  6 16:21:39 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Sat, 6 Jan 2007 16:21:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - comment is confusing in
	the websale example
Message-ID: <33413574.1168118499563.JavaMail.jboss@colo-br-02.atl.jboss.com>

Since jBPM has the notion of generic comments (on the task level) it is very confusing that the "create websale order" task has a generic comment field  but the "evaluate websale order" has a comment field belonging to the taskform itself. The first comment shows up on the comment tab, but the second is in the form for the third (fix...) task. Maybe the label on the form should change

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

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


From do-not-reply at jboss.com  Sun Jan  7 09:22:44 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Sun, 7 Jan 2007 09:22:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: PojoCache uses a
	special node factory
Message-ID: <21023194.1168179764876.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | 
  | One thing I noticed is the Configuration.getRuntimeConfig() object now exposes the NodeFactory as a property.
  | 
  | 

I added this so that the NodeFactory is constructed and registered when the Cache is created, and gets a reference to CacheImpl when constructed such that methods that call createNode() need not worry about passing in details such as node type (as this is gleaned from the configuration attached to the cache) or bother passing in a cache reference.

anonymous wrote : 
  | This opens up the possibility of having a specialized factory create specialized nodes for _JBossInternal_. For example, one whose data version is always 0, or that has a more complex structure for holding child nodes to avoid lock conflicts, etc. 
  | 

This possibility always was there, even the way the NodeFactory was used before - and still is in JBC 1.x.y -  as a Singleton.  That's the whole purpose of a factory.

The first step would be to identify how a _JBossInternal_ node would differ from normal nodes, wrt. concurrency with optimistic and pessimistic locking, data versioning and BR as well.

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

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


From do-not-reply at jboss.com  Sun Jan  7 09:42:00 2007
From: do-not-reply at jboss.com (timfox)
Date: Sun, 7 Jan 2007 09:42:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - JBoss
	TS JTA - unsetting current transaction association
Message-ID: <9562896.1168180920278.JavaMail.jboss@colo-br-02.atl.jboss.com>

If I do the following:


  | 
  | txMgr.begin();
  | 
  | Transaction tx = txMgr.getTransaction();
  | 
  | tx.commit();
  | 
  | tx = txMgr.getTransaction();
  | 
  | assertNull(tx);
  | 
  | 

The assertion fails (I would expect the tx.commit() to cause the association between the current thread and transaction to be broken).

But the following passes:


  | 
  | txMgr.begin();
  | 
  | Transaction tx = txMgr.getTransaction();
  | 
  | txMgr.commit();
  | 
  | tx = txMgr.getTransaction();
  | 
  | assertNull(tx);
  | 
  | 

Is this behaviour by design? With the old JBoss JTA implementation both the above cases would pass

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

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


From do-not-reply at jboss.com  Sun Jan  7 09:45:07 2007
From: do-not-reply at jboss.com (mark.little@jboss.com)
Date: Sun, 7 Jan 2007 09:45:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	JBoss TS JTA - unsetting current transaction association
Message-ID: <9832437.1168181107107.JavaMail.jboss@colo-br-02.atl.jboss.com>

It is bad/broken design. Only going through TransactionManager/UserTransaction do you get thread-to-transaction association/disassociation. (Same as using Current in OTS). If you terminate the transaction directly through Transaction (equivalent to using the Terminator in OTS) then you the thread-to-transaction association is not modified. You'll need to either use TM/UT or do an explicit suspend afterwards on the calling thread.

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

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


From do-not-reply at jboss.com  Sun Jan  7 10:21:00 2007
From: do-not-reply at jboss.com (timfox)
Date: Sun, 7 Jan 2007 10:21:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Bug in transactional delivery in an MDB
Message-ID: <15020367.1168183260186.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have been looking at http://jira.jboss.com/jira/browse/JBMESSAGING-721 and have uncovered a bug in transactional message delivery with MDBs.

A message is received transactionally in the onMessage method of a MDB and  the tx is marked rollback only, but the message is not redelivered.

What is happening is this:

1. JBoss Messaging receives message from destination (no tx at this point)

2. JBM calls onMessage on the MDB container

3. MDB container starts a global tx and enlists the session's xaresoource

4. The user's onMessage executes

5. The user set's rollback only

6. The MDB container rolls back the transaction

7. There is no redelivery since the message was received by JBM *before* the mdb container starts the transaction.

This is a very well known issue and a result of a design flaw in the original JMS connection consumer design.

It is well documented in Weston's favourite book ;), Mark Little's "Java Transaction processing, Chapter 5, section "applications server integration".

Different app servers solve the problem in different ways.

JBoss MQ, JBoss Messaging work by acting as a local transacted session when not in xa begin..end boundaries and then when XAResource.start is called, the work done in the local tx is converted into the work done in the new transaction (See MessagingXAResource.start)

I have fixed this and added tests, however the above behaviour is incompatible with fixes Ovidiu did for:

http://jira.jboss.com/jira/browse/JBMESSAGING-410

(
      // leave the session in a 'clean' state, the currentTxId will be set when the XAResource will
      // be enrolled with a new transaction.

      setCurrentTransactionId(null);
)

Branch_1_0 revision 1317 (19/09/06) by Ovidiu which basically sets the current transaction id to null after a commit or rollback

This breaks the MDB transactional delivery since because the current transaction id is set to null, there is nothing to convert.

The problem here is that the desired behaviour for http://jira.jboss.com/jira/browse/JBMESSAGING-410 and for correct transactional delivery in MDBs seem to be fundamentally incompatible.

For JBMessaging-410 - it wants an XASession to behave as non transacted when it is not enlisted in a global tx - but for correct MDB message delivery we want it to behave as a local session.

My question is, is the requirement for JBMessaging-410 real?

Weston - what should the correct JCA behaviour be here? Is JBMessaging-410 real or bogus and any ideas on how we can reconcile the two?

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

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


From do-not-reply at jboss.com  Sun Jan  7 10:41:21 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Sun, 7 Jan 2007 10:41:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Aspect integration to bootstrap classes
Message-ID: <10244475.1168184481721.JavaMail.jboss@colo-br-02.atl.jboss.com>

I think this would have to involve moving aop into the bootstrap, I will take a look first thing tomorrow

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

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


From do-not-reply at jboss.com  Sun Jan  7 11:25:35 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Sun, 7 Jan 2007 11:25:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Bug in transactional delivery in an MDB
Message-ID: <9305586.1168187135011.JavaMail.jboss@colo-br-02.atl.jboss.com>

I will take a look. Chances are one of us (either JCA or JBM) is getting in the way of each other. 



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

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


From do-not-reply at jboss.com  Sun Jan  7 13:07:31 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Sun, 7 Jan 2007 13:07:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: When should the
	webconsole mark tasks as started?
Message-ID: <7057393.1168193251450.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'd love to be able to show "new" tasks differently from "started" tasks on the task list (much like how many email clients show a new message in boldface).

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

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


From do-not-reply at jboss.com  Sun Jan  7 13:11:36 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Sun, 7 Jan 2007 13:11:36 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: comment is
	confusing in the websale example
Message-ID: <27021654.1168193496164.JavaMail.jboss@colo-br-02.atl.jboss.com>

I agree.  Under Tom's proposed change for the task screen, the task form will appear in addition to a generic comment box.  Perhaps in this case, the task form need not have a comment field at all.

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

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


From do-not-reply at jboss.com  Sun Jan  7 14:52:14 2007
From: do-not-reply at jboss.com (leosimoesp@yahoo.com.br)
Date: Sun, 7 Jan 2007 14:52:14 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Reporting] - BIRT ENGINE
	UGHUUUUH!!!!!
Message-ID: <23920925.1168199534332.JavaMail.jboss@colo-br-02.atl.jboss.com>

  I believe definitly that BIRT dosen't work with jboss. The error is follow:

eclipse.buildId=unknown
java.version=1.5.0_06
java.vendor=BEA Systems, Inc.
BootLoader constants: OS=linux, ARCH=x86, WS=motif, NL=en_US
Command-line arguments:  -clean

!ENTRY org.eclipse.osgi 4 0 2007-01-07 17:17:56.704
!MESSAGE Bundle org.eclipse.equinox.common at 2:start not found.

it occurs in org.eclipse.osgi.framework.internal.core.Framework. (URLStreamHandlerFactory stepping on previously installed)
it  always seems when I redeploy my .ear application. 
 I don't known how to solve this. Anyone have any idea? 





Thanks, 

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

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


From do-not-reply at jboss.com  Sun Jan  7 23:20:29 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Sun, 7 Jan 2007 23:20:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Bug in transactional delivery in an MDB
Message-ID: <25147376.1168230029299.JavaMail.jboss@colo-br-02.atl.jboss.com>

http://jira.jboss.com/jira/browse/JBMESSAGING-410 was reported by Elias after he noticed an incompatibility between the way JBossMQ and Messaging behave relative to a situation that is insufficiently specified. I took the decision to restore compatibility with JBossMQ, and with something that, personally, I believe it is the most intuitive behavior.

I need to analyze the case you're talking about here a little bit better before coming up with a definitive(?) conclusion ...

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

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


From do-not-reply at jboss.com  Mon Jan  8 02:40:44 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Mon, 8 Jan 2007 02:40:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Failover analysis
Message-ID: <15611323.1168242044661.JavaMail.jboss@colo-br-02.atl.jboss.com>

http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingClientSideFailoverOverview

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

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


From do-not-reply at jboss.com  Mon Jan  8 03:38:09 2007
From: do-not-reply at jboss.com (thomas.diesler@jboss.com)
Date: Mon, 8 Jan 2007 03:38:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Using
	jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.5
Message-ID: <29520227.1168245489798.JavaMail.jboss@colo-br-02.atl.jboss.com>

Folks,

last week I succeded to implement porting layers for jboss50, jboss42, jboss40 on a common jbossws code base. This means that from now on we can work on jbossws/trunk again, which should reduce code maintenance significantly (branch/jbossws-1.0. is dead)

jbossws-1.2.0.CR2 was release over the weekend and I updated 

http://wiki.jboss.org/wiki/Wiki.jsp?page=JBWSFAQBuildAndInstall

to describe the new deployment procedure.

In JIRA I moved all 1.0.5 and 2.0.0.CR3 issues to 1.2.0, which is due 1-Feb-2007. 
I will send a more detailed mail related to the 1.2.0 release later today.

cheers

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

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


From do-not-reply at jboss.com  Mon Jan  8 03:50:29 2007
From: do-not-reply at jboss.com (thomas.diesler@jboss.com)
Date: Mon, 8 Jan 2007 03:50:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Support JAXWS
	on EJB2.1
Message-ID: <13235965.1168246229841.JavaMail.jboss@colo-br-02.atl.jboss.com>

Folks, 

should we continue to support JAXWS, JSR181 annotations on EJB-2.1?
Please keep in mind that we can now use the trunk code base in jboss-4.2, jboss-4.0

Comments?

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

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


From do-not-reply at jboss.com  Mon Jan  8 04:54:06 2007
From: do-not-reply at jboss.com (thomas.heute@jboss.com)
Date: Mon, 8 Jan 2007 04:54:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: securing portlets
	fails on redeploy
Message-ID: <18028939.1168250046388.JavaMail.jboss@colo-br-02.atl.jboss.com>

Please use the User forum (As stated in the READ FIRST topic)

I'm moving the topic.

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

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


From do-not-reply at jboss.com  Mon Jan  8 04:55:01 2007
From: do-not-reply at jboss.com (thomas.heute@jboss.com)
Date: Mon, 8 Jan 2007 04:55:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Does JBoss Portal
	2.4 support reconfiguring portlet inst
Message-ID: <13874121.1168250101458.JavaMail.jboss@colo-br-02.atl.jboss.com>

Please use the User forum (As stated in the READ FIRST topic)

I'm moving the topic.

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

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


From do-not-reply at jboss.com  Mon Jan  8 04:55:55 2007
From: do-not-reply at jboss.com (thomas.heute@jboss.com)
Date: Mon, 8 Jan 2007 04:55:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: How do you a
	forum and a wiki to a jportal
Message-ID: <10776612.1168250155450.JavaMail.jboss@colo-br-02.atl.jboss.com>

(Moving the topic)

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

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


From do-not-reply at jboss.com  Mon Jan  8 04:58:14 2007
From: do-not-reply at jboss.com (thomas.heute@jboss.com)
Date: Mon, 8 Jan 2007 04:58:14 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Using Portlet to
	.NET Environment?
Message-ID: <17841081.1168250294242.JavaMail.jboss@colo-br-02.atl.jboss.com>

Please use the User forum (As stated in the READ FIRST topic http://www.jboss.com/index.html?module=bb&op=viewtopic&t=75280)

I'm moving the topic.

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

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


From do-not-reply at jboss.com  Mon Jan  8 04:59:16 2007
From: do-not-reply at jboss.com (thomas.heute@jboss.com)
Date: Mon, 8 Jan 2007 04:59:16 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Portlet states
	strategy
Message-ID: <14554152.1168250356848.JavaMail.jboss@colo-br-02.atl.jboss.com>

Please use the User forum (As stated in the READ FIRST topic http://www.jboss.com/index.html?module=bb&op=viewtopic&t=75280)

I'm moving the topic.

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

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


From do-not-reply at jboss.com  Mon Jan  8 05:00:20 2007
From: do-not-reply at jboss.com (thomas.heute@jboss.com)
Date: Mon, 8 Jan 2007 05:00:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Integration of
	third party CMS with JBoss portal
Message-ID: <1861743.1168250420921.JavaMail.jboss@colo-br-02.atl.jboss.com>

Please use the User forum (As stated in the READ FIRST topic http://www.jboss.com/index.html?module=bb&op=viewtopic&t=75280)

I'm moving the topic.

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

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


From do-not-reply at jboss.com  Mon Jan  8 05:04:38 2007
From: do-not-reply at jboss.com (timfox)
Date: Mon, 8 Jan 2007 05:04:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Bug in transactional delivery in an MDB
Message-ID: <25116305.1168250678681.JavaMail.jboss@colo-br-02.atl.jboss.com>

Weston - what is the correct behaviour of the JCA JMS managed connection factory here?

Just to recap:

If I obtain a session from a connection created from the JCA JMS managed cf (i.e. the one normally at java:/jmsXA), and there is *no* JTA transaction associated with the current thread, and I receive a message, should the session act like a non transacted session and the message get acknowledged immediately, OR should it act like a transacted session? This is the key question.

If it should act like a non transacted session, how can we reconcile this with transactional message receipt for MDBs?

In a MDB the message is received *before* the MDB container has a chance to start a global tx, therefore it is received in a session where no JTA tx is associated with the current thread. In this case we must *not* ack it immediately, but we must let the session behave as a transacted session and later when the MDB container starts a JTA tx and enlists it, we can transfer the work done in the local tx into the global tx.

Funnily enough - transferring the work into the JTA tx is exactly how JBoss MQ does it too, so I am puzzled as to how this behaviour is consistent with the behaviour of JCA without a JTA tx as Ovidiu reports. This is why I am trying to find out whether the supposed JCA behaviour is real or bogus.

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

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


From do-not-reply at jboss.com  Mon Jan  8 05:11:23 2007
From: do-not-reply at jboss.com (timfox)
Date: Mon, 8 Jan 2007 05:11:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Bug in transactional delivery in an MDB
Message-ID: <9355790.1168251083135.JavaMail.jboss@colo-br-02.atl.jboss.com>

http://jira.jboss.com/jira/browse/JBMESSAGING-721

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

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


From do-not-reply at jboss.com  Mon Jan  8 05:22:16 2007
From: do-not-reply at jboss.com (Gurdipe)
Date: Mon, 8 Jan 2007 05:22:16 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Wiki] - Re: [[/wiki]] Exception
	starting filter wikiFileAccessFilter
Message-ID: <28594945.1168251736728.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi All,

I am having the exactly the same problem when I try to delay and use the wiki ear file.  Does anyone know if this problem has been resolved or when it will be resolved?

Kind Regards

Gurdipe


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

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


From do-not-reply at jboss.com  Mon Jan  8 05:52:49 2007
From: do-not-reply at jboss.com (szimano)
Date: Mon, 8 Jan 2007 05:52:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Wiki] - Re: [[/wiki]] Exception
	starting filter wikiFileAccessFilter
Message-ID: <23327341.1168253569367.JavaMail.jboss@colo-br-02.atl.jboss.com>

Gurdipe,

What ersion of AS you're using and what version of wiki you're trying to deploy ?

Cheers,
Tomek

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

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


From do-not-reply at jboss.com  Mon Jan  8 06:52:06 2007
From: do-not-reply at jboss.com (SpockX)
Date: Mon, 8 Jan 2007 06:52:06 -0500 (EST)
Subject: [jboss-dev-forums] [Other JBoss Development Design] - JBoss
	Developer CERTIFICATION exam. What JBOSS VERSION?
Message-ID: <27614823.1168257126017.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have completed all the prerequisites for the Jboss Developer Certification exam and have received an invite to take the exam. 
I am wondering what version of Jboss is covered in the current exam? Is EJB3 covered for example? Any other information on topic's covered.


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

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


From do-not-reply at jboss.com  Mon Jan  8 06:56:35 2007
From: do-not-reply at jboss.com (radzish)
Date: Mon, 8 Jan 2007 06:56:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - LayouStrategy and
	StrategyResponse API
Message-ID: <30311636.1168257395500.JavaMail.jboss@colo-br-02.atl.jboss.com>

I am using JBoss Portal 2.4.0.
I consider my question not of 'user' category, because it is related to Portal Theme API, so I am posting it here, not into user forum.

I was trying to write my own strategy implementation for specific layout behaviour and was disapointed of useless of this API. It seems like LayoutStrategy was designed only for MaximizingStrategyImpl implementation.

The problem is in following:
We have method StrategyResponse.addWindowStateChange(WindowContext portlet, WindowState state), which takes a WindowContext instance as parameter. In the same time only WindowLocations are available from StrategyContext.
The only way of using it is for updating state of the target window, which context is available from StrategyEvent, but it would be really nice to update states of other windows.

At the same time we have StrategyResponse.addNoRender(WindowLocation portlet) method that takes WindowLocation as parameter (that was actually needed for MaximizingStrategyImpl implementation).

It would be really nice to have StrategyResponse.addWindowStateChange(WindowLocation location, WindowState state).

The same applies to StrategyResponse.addPortletModeChange() method

For now, I have to use reflection in order to get WindowContext from WindowLocation and use StrategyResponse.addWindowStateChange(WindowContext portlet, WindowState state) method, which is not proper sollution, though it works

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

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


From do-not-reply at jboss.com  Mon Jan  8 06:59:19 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Mon, 8 Jan 2007 06:59:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Using
	jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
Message-ID: <2240090.1168257559533.JavaMail.jboss@colo-br-02.atl.jboss.com>

I can get JBossWS to deploy to JBoss 5 and JBoss 4.2 and run the testsuite with a high test success rate but for JBoss 4.0 I am getting a lot of failures.  

I am using the JBoss 4.0.5 release and I am getting this error logged for a lot of the tests: -

anonymous wrote : 2007-01-08 12:13:21,026 ERROR [org.jboss.ws.core.soap.SOAPMessageUnMarshaller:80] Cannot unmarshall SOAPMessage
  | javax.xml.soap.SOAPException: Cannot find SOAPFactory implementation
  | 	at javax.xml.soap.SOAPFactory.newInstance(SOAPFactory.java:96)
  | 	at org.jboss.ws.core.soap.SOAPFactoryImpl.createElement(SOAPFactoryImpl.java:113)
  | 	at org.jboss.ws.core.soap.SAAJPayloadBuilderDOM.build(SAAJPayloadBuilderDOM.java:86)
  | 	at org.jboss.ws.core.soap.MessageFactoryImpl.createMessageInternal(MessageFactoryImpl.java:254)
  | 	at org.jboss.ws.core.soap.SOAPMessageUnMarshaller.read(SOAPMessageUnMarshaller.java:75)
  | 	at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:175)
  | 	at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:81)
  | 	at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
  | 	at org.jboss.remoting.Client.invoke(Client.java:525)
  | 	at org.jboss.remoting.Client.invoke(Client.java:488)

It looks like an old version of 'javax.xml.soap.SOAPFactory' is being used from the JBoss jars instead of the latest version from JBossWS.


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

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


From do-not-reply at jboss.com  Mon Jan  8 07:13:27 2007
From: do-not-reply at jboss.com (tabbe)
Date: Mon, 8 Jan 2007 07:13:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Profiler] - Internal Error in
	Webinterface
Message-ID: <664280.1168258407049.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hello all,

after having profiled my webapplication, I wanted to view the results in the webinterface. I got the page with the selection of the process id etc but in the next step the webinterface crashes with the following message:

org.apache.jasper.JasperException: Exception in JSP: /internalMenu.inc:6

3:  * Distributable under LGPL license.
4:  * See terms of license at gnu.org.
5:  
6:  * This file belongs to a simple implementation of a web interface for the "disconnectedProfiler".
7: */
8: %>
9: 


Stacktrace:

anonymous wrote : 
  | org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:504)
  | 	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375)
  | 	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
  | 	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
  | 	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  | 	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
  | 
  | root cause
  | 
  | javax.servlet.ServletException: Cannot find bean filterForm in scope null
  | 	org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:858)
  | 	org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:791)
  | 	org.apache.jsp.mainMenu_jsp._jspService(mainMenu_jsp.java:172)
  | 	org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
  | 	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  | 	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
  | 	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
  | 	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
  | 	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  | 	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
  | 
  | root cause
  | 
  | javax.servlet.jsp.JspException: Cannot find bean filterForm in scope null
  | 	org.apache.struts.util.RequestUtils.lookup(RequestUtils.java:493)
  | 	org.apache.struts.taglib.bean.DefineTag.doStartTag(DefineTag.java:200)
  | 	org.apache.jsp.mainMenu_jsp._jspService(mainMenu_jsp.java:92)
  | 	org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
  | 	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  | 	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
  | 	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
  | 	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
  | 	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  | 	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
  | 

server.log:

anonymous wrote : 
  | javax.servlet.jsp.JspException: Cannot find bean filterForm in scope null
  | 	at org.apache.struts.util.RequestUtils.lookup(RequestUtils.java:493)
  | 	at org.apache.struts.taglib.bean.DefineTag.doStartTag(DefineTag.java:200)
  | 	at org.apache.jsp.mainMenu_jsp._jspService(mainMenu_jsp.java:92)
  | 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
  | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  | 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
  | 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
  | 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
  | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  | 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
  | 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  | 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
  | 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  | 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  | 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
  | 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
  | 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
  | 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
  | 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
  | 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
  | 	at org.apache.catalina.valves.RequestDumperValve.invoke(RequestDumperValve.java:150)
  | 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
  | 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
  | 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
  | 	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
  | 	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
  | 	at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
  | 	at java.lang.Thread.run(Thread.java:595)
  | 

I'm using JBoss AS 4.0.4.GA on WinXP, Java 5 and the latest JBossProfiler CR4

Does anyone have an idea?
Thanks in advance

Tom



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

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


From do-not-reply at jboss.com  Mon Jan  8 07:17:32 2007
From: do-not-reply at jboss.com (tabbe)
Date: Mon, 8 Jan 2007 07:17:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Profiler] - Re: Internal Error
	in Webinterface
Message-ID: <21674306.1168258652858.JavaMail.jboss@colo-br-02.atl.jboss.com>

I've noted that it only crashes with Firefox.
Under Internet Explorer it works...

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

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


From do-not-reply at jboss.com  Mon Jan  8 07:17:33 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Mon, 8 Jan 2007 07:17:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: LayouStrategy and
	StrategyResponse API
Message-ID: <13512812.1168258653925.JavaMail.jboss@colo-br-02.atl.jboss.com>

I agree with you.

This api has been simplified in 2.6 (for debugging and support purpose, the current code was very tangled an complex) and we removed everything that was not used. So your customization may break (sorry for that).

We encourage you to test it against the upcoming alpha release.


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

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


From do-not-reply at jboss.com  Mon Jan  8 07:32:31 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 8 Jan 2007 07:32:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: remove context
	sensitive menus
Message-ID: <33371412.1168259551505.JavaMail.jboss@colo-br-02.atl.jboss.com>

"jeffdelong" wrote : I also have a comment on Terminology. We seem to be equating Processes with ProcessDefinitions. This is okay, most users don't like to say processdefinitions, but we must always be clear when dealing with instances that we say ProcessInstances, so that the difference is clear.

in the new core prototype, i use the following terminology

ProcessDefinition --> Process
ProcessInstance and Token --> Execution

Maybe that could already be adopted into the web console for 3.2.  But probably that would cause more confusion then it solves, no ?

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

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


From do-not-reply at jboss.com  Mon Jan  8 07:59:23 2007
From: do-not-reply at jboss.com (thomas.diesler@jboss.com)
Date: Mon, 8 Jan 2007 07:59:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Using
	jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
Message-ID: <25015399.1168261163750.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes, jbossall-client.jar is the culprit. Please try this


  |     <!-- The test client classpath -->
  |     <path id="test.client.classpath">
  |       <path refid="jbossws.client.classpath"/>
  |       <pathelement location="${jboss.client}/jbossall-client.jar"/>
  | 

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

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


From do-not-reply at jboss.com  Mon Jan  8 08:04:42 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 8 Jan 2007 08:04:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <10486430.1168261482715.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bazoo" wrote : I would not incorporate the "Search for instance" row in the task list, at least not at the top. For someone new to the app, you don't immediately notice that you have a task in the task list because it is hidden in small text underneath the big search boxes. You immediately think you have to perform a search, even though you may not have to.
  | 

i'll take this to a separate thread.

"bazoo" wrote : I don't understand what the "Task Definition View" is really. 

I also think that should be left out.  At task-instance-creation-time, the task definition data is copied into the task instance data.  After that, the task instance data might be updated (e.g. description or name).  I don't think that showing the task definition information is relevant.

"bazoo" wrote : I don't think the Summary page should be the first page you see when you click Task Instance View. I think it should be the Task Form to minimize clicking.
  | 

+1

"bazoo" wrote : Instead of "End Task", I would suggest "Proceed", to reinforce the idea that the user is moving through a process.
  | 

The good thing about 'End Task' is that it's from the perspective of the task performer.  'Proceed' has more meaning in the context of the larger business process.  But the task performer does not HAVE to be aware of that.  I was thinking of 'Finish' or 'Complete'  but none of those really hits it for me.

"bazoo" wrote : I get the following exception when I click "End task" or "More info needed", although the transition does happen: javax.el.PropertyNotFoundException: /main/task/new_tasks.xhtml @41,57 value="#{entry.taskInstance.id}": Property 'taskInstance' is not found on type: java.lang.String
  | 

David, are you onto this one ?  Can you reproduce ?

"bazoo" wrote : I would suggest that "User Task List" should be at the top of the navigation menu, especially as it is the view you go to first when you log in.
  | 

+1


Thanks Matt !

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

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


From do-not-reply at jboss.com  Mon Jan  8 08:06:38 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 8 Jan 2007 08:06:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <1394395.1168261598291.JavaMail.jboss@colo-br-02.atl.jboss.com>

"kukeltje" wrote : I  mean... if it is in a datatable, 'assign to me' in a button form would make the form rather crowded

'Assign to me' as a link would be good as well.  As long as that is the only way people can start working on this task.  This is important as the webapp has to make sure that there is no multiple people start working on this task concurrently.

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

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


From do-not-reply at jboss.com  Mon Jan  8 08:08:20 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Mon, 8 Jan 2007 08:08:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Using
	jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
Message-ID: <32893388.1168261700532.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes that fixes it, thanks.

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

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


From do-not-reply at jboss.com  Mon Jan  8 08:15:47 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 8 Jan 2007 08:15:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - one central search page
Message-ID: <3515372.1168262147105.JavaMail.jboss@colo-br-02.atl.jboss.com>

I would like one central search page that can be used to search for 
* Process definitions
* Process instances
* Task instances

I think it would make sense to have this as one page cause various links could navigate to this page with prefilled criteria:
    * process instances for a process definition
    * task instances for a process instance
    * task instances for a task
    * task instances for a process definition

i think that would be a concept that people quickly start to grasp: if they click a link 'process instances' in a process definition page that they are navigated to the search results screen.  

that also gives them easy ways of starting to tweak and change the search criteria to refine their search.


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

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


From do-not-reply at jboss.com  Mon Jan  8 08:19:36 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 8 Jan 2007 08:19:36 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: simplified process
	instance view
Message-ID: <23567819.1168262376345.JavaMail.jboss@colo-br-02.atl.jboss.com>

"jeffdelong" wrote : Just want to mention that the navigation from Processes (i.e., ProcessDefinitions) to ProcessInstances to single ProcessInstance makes sense, and don't want to lose that (don't think that is anyone's intention, but it has not been mentioned in any of Tom's comments).

good point.  this is related to the single central search page idea that i just described: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3998991

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

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


From do-not-reply at jboss.com  Mon Jan  8 08:23:07 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 8 Jan 2007 08:23:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: direct navigation
	when starting a new process instance
Message-ID: <32360034.1168262587541.JavaMail.jboss@colo-br-02.atl.jboss.com>

"jeffdelong" wrote : This is a bit tricky, because these are really two different scenarios here.
  | 
  | 1) if Start-task - then user should be navigated to the page to perform the task, i.e. fill in the form.
  | 

+1

"jeffdelong" wrote : 
  | 2) no Start-task - typically the user that started the process will not perform the first task in the process (otherwise we could have modelled their task at the start). So they should not navigate to a task-related page. Question is where to take them. What they would probably most like to see is the list of started processInstances, and see the one they just started in that list, or the ProcessInstance View for that particular instance that they just started.
  | 

i would guess they most likely want to see the ProcessInstance View.



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

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


From do-not-reply at jboss.com  Mon Jan  8 08:27:43 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 8 Jan 2007 08:27:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: replace sources
	tabs with links
Message-ID: <3425470.1168262863534.JavaMail.jboss@colo-br-02.atl.jboss.com>

I think these should be links with a back navigation option.  Because this is a developer/demo/evaluation version only type of features that you don't want in your production system.

A link will minimize the difference between the evaluation version and the 'real' version.

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

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


From do-not-reply at jboss.com  Mon Jan  8 08:31:14 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 8 Jan 2007 08:31:14 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Console performance
Message-ID: <7445830.1168263074852.JavaMail.jboss@colo-br-02.atl.jboss.com>

The current form of the web console is definitely not intended as an example to get started with.

This will grow out to become a fully fledged console, too complex for people to start using it as a JSF example.

Of course, we should keep it as easy as possible for developers to tweak it, but including more functionality has priority.

Indeed performance and stress tests are going to be needed.  I would leverage the community to do the initial pinpointing of problems and only spend our own resournces on it after a potential SEAM refactoring.

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

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


From do-not-reply at jboss.com  Mon Jan  8 08:33:06 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 8 Jan 2007 08:33:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: When should the
	webconsole mark tasks as started?
Message-ID: <33028383.1168263186548.JavaMail.jboss@colo-br-02.atl.jboss.com>

i like the idea.  good suggestion.

the start field can be used for this... if a task instance is opened in the task form view and the task start is null, then put the current date in there.

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

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


From do-not-reply at jboss.com  Mon Jan  8 08:39:25 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Mon, 8 Jan 2007 08:39:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: When should the
	webconsole mark tasks as started?
Message-ID: <32502976.1168263565769.JavaMail.jboss@colo-br-02.atl.jboss.com>

This can be used to create reports with info on how long a task is in a 'queue' before acted upon. Very useful info for managers.  oh and I like the 'bold' to, but maybe there should also be a column for this.

Now I should (according to the feedback wiki page) make a jira issue and move it down on the list right... ok.. i'll do that. 

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

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


From do-not-reply at jboss.com  Mon Jan  8 08:42:00 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Mon, 8 Jan 2007 08:42:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: replace sources
	tabs with links
Message-ID: <27107890.1168263720185.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | A link will minimize the difference between the evaluation version and the 'real' version.
  | anonymous wrote : 
  |   | 
  |   | Why? It will either be 'links not visible in production' or 'tabs not visible in production' 
  |   | 
  |   | but I go with the majority ;-)

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

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


From do-not-reply at jboss.com  Mon Jan  8 08:45:34 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Mon, 8 Jan 2007 08:45:34 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: one central search
	page
Message-ID: <12297143.1168263934988.JavaMail.jboss@colo-br-02.atl.jboss.com>

But I wold certainly not ditch the filtering at the top of the lists. Maybe they should be invisible at first and have an magnifying glass to open it. An 'advanced' button could take you to the generic search page with things on it like 'search processinstances with a variable y and value x'

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

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


From do-not-reply at jboss.com  Mon Jan  8 09:03:15 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Mon, 8 Jan 2007 09:03:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <20291662.1168264995597.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : 
  | "bazoo" wrote : I get the following exception when I click "End task" or "More info needed", although the transition does happen: javax.el.PropertyNotFoundException: /main/task/new_tasks.xhtml @41,57 value="#{entry.taskInstance.id}": Property 'taskInstance' is not found on type: java.lang.String
  |   | 
  | 
  | David, are you onto this one ?  Can you reproduce ?
  | 

I could reproduce this, but David already fixed it in cvs. 

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

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


From do-not-reply at jboss.com  Mon Jan  8 09:19:16 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Mon, 8 Jan 2007 09:19:16 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Support
	JAXWS on EJB2.1
Message-ID: <1247078.1168265956675.JavaMail.jboss@colo-br-02.atl.jboss.com>

I don't think anyone is using it, or at least I have never seen a question relating to it.

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

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


From do-not-reply at jboss.com  Mon Jan  8 09:37:12 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 8 Jan 2007 09:37:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: remove context
	sensitive menus
Message-ID: <25670986.1168267032156.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : ProcessDefinition --> Process
  | ProcessInstance and Token --> Execution
  | 
  | Maybe that could already be adopted into the web console for 3.2.  But probably that would cause more confusion then it solves, no ?

I like the new terminology a lot better, but I think that changing to "Execution" now would just be confusing.  Changing "Process Definition" to "Process" is perfectly reasonable though, in my opinion.

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

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


From do-not-reply at jboss.com  Mon Jan  8 09:41:45 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 8 Jan 2007 09:41:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: simplified process
	instance view
Message-ID: <3363306.1168267305865.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : I would like to have one central screen that combines all the process instance information : 
  | * general process instance properties (aka summary)
  | * open tasks
  | * variables
  | * comments
  | * tokens

Sounds good to me.

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

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


From do-not-reply at jboss.com  Mon Jan  8 09:51:38 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 8 Jan 2007 09:51:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: direct navigation
	when starting a new process instance
Message-ID: <19334632.1168267898240.JavaMail.jboss@colo-br-02.atl.jboss.com>

It can be slightly more complicated than this.

Starting a process instance may result in the creation of multiple tasks assigned to the person starting the task, or it may result in one or more group tasks being created, or some combination therein.  If we want to shortcut the single-task case, that's fine, but if there are multiple tasks that are relevant to that user, we should go to an intermediate screen to allow the user to choose the task.

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

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


From do-not-reply at jboss.com  Mon Jan  8 09:57:57 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Mon, 8 Jan 2007 09:57:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Aspect integration to bootstrap classes
Message-ID: <18444544.1168268277248.JavaMail.jboss@colo-br-02.atl.jboss.com>

I am looking at moving the AOP into bootstrap-beans.xml, I will allow for some "initial" XML to be passed in to the aspectmanager bean, which should make possible

  |    <aspect name="mainDeployer"
  | class="org.jboss.profileservice.aop.MainDeployerAdvice"/>
  |    <bind pointcut="execution(*
  | $instanceof{org.jboss.deployers.spi.deployment.MainDeployer}->process(..))">
  |       <advice name="process" aspect="mainDeployer"/>
  |    </bind>
  | 

However, since AFAICT ManagedProperty is not a bean, in order to be able to do:

  |    <aspect name="persist"
  | class="org.jboss.profileservice.aop.PersistAdvice"/>
  |    <bind pointcut="execution(*
  | $instanceof{org.jboss.deployers.spi.deployment.MainDeployer}->process(..))">
  |       <advice name="process" aspect="mainDeployer"/>
  |    </bind>
  | 

We have the following choices:
1) Require jboss to be run with a custom loader for loadtime weaving to be enabled, which might be overkill?
2) Weave/Prepare ManagedProperty at compiletime, so that it has the AOP hooks in place, and pick up the aspects to be applied to these joinpoints at runtime from the "initial" xml


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

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


From do-not-reply at jboss.com  Mon Jan  8 10:14:36 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Mon, 8 Jan 2007 10:14:36 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1260 -
	Sequence containing 2 elements
Message-ID: <31845017.1168269276368.JavaMail.jboss@colo-br-02.atl.jboss.com>

Right, a simple type is not a valid wrapper type, so if it is used only the bare parameter style can be used.

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

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


From do-not-reply at jboss.com  Mon Jan  8 10:22:41 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 8 Jan 2007 10:22:41 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: one central search
	page
Message-ID: <5054905.1168269761932.JavaMail.jboss@colo-br-02.atl.jboss.com>

The problems I see with this are as follows:

* Having one single set of search criteria is more complicated than having separate searches.  Initially I did do this.  I tried to simplify it by having a select list where you'd select the type of search you wanted to do, and it would update the search criteria for the new search type, but this was much more complicated than the final search mechanism that i ended up with.  By complicated, I mean complicated to implement AND confusing for the end-user.

* We will need to keep track of where the user came from so they can easily return.  Again this is doable in a couple of ways, but I think an overriding priority is bookmarkable URLs for pages, and this might compromise that.  A bookmarkable URL implies statelessness, which would be complicated if we must track where a user navigated from at run time.  For example, if I went from the Process page to find Process Instances, I'd want a link back to that process page to be right at the top.  But if I bookmarked that URL, now that URL should contain something that indicates that you navigated to that search results page from the Process page.

I think having a single search page is too confusing, unless you have an idea for how it can be laid out.

We could however do (for example) one search page per result type, or use tabs to separate searches.  The latter is tougher (but possible) to bookmark though.

* 

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

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


From do-not-reply at jboss.com  Mon Jan  8 10:23:45 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Mon, 8 Jan 2007 10:23:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: PojoCache uses a
	special node factory
Message-ID: <24040294.1168269825166.JavaMail.jboss@colo-br-02.atl.jboss.com>

"manik.surtani at jboss.com" wrote : 
  | This possibility always was there, even the way the NodeFactory was used before - and still is in JBC 1.x.y -  as a Singleton.  That's the whole purpose of a factory.

I'm not sure how it can be done in 1.x, as NodeFactory doesn't expose any way to change the singleton.

anonymous wrote : The first step would be to identify how a _JBossInternal_ node would differ from normal nodes, wrt. concurrency with optimistic and pessimistic locking, data versioning and BR as well.

Yep. Assuming Ben finds the concept useful :-)

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

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


From do-not-reply at jboss.com  Mon Jan  8 10:28:51 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 8 Jan 2007 10:28:51 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <19610839.1168270131287.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : Processes : Should display a list of processes similar to the current Find Processes menu screen.  By default, this screen shows only the latest versions of the processes in alphabetical order.

For the new prototype, there should be two tables for Processes.  One table should have a row for each unique process name, and it should contain any information that is shared between all versions of a process (even if it is just the name).  The other will be a child table of the main Process table and should contain per-version information.  The main process table should have link to the Process Version table representing the current "active" version.  This way, the latest version of a process can be found without having to using grouping SQL operations, and also the user can easily revert to an earlier version of a process if they need to by changing a simple link.

This normalization will greatly simplify the querying of process information.

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

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


From do-not-reply at jboss.com  Mon Jan  8 10:28:58 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Mon, 8 Jan 2007 10:28:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: direct navigation
	when starting a new process instance
Message-ID: <8272621.1168270138877.JavaMail.jboss@colo-br-02.atl.jboss.com>

Sounds reasnoable, but I think in most cases there will be one task, so we should focus on that situation. The other usecases could be done at a later moment... (imo)

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

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


From do-not-reply at jboss.com  Mon Jan  8 10:30:19 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Mon, 8 Jan 2007 10:30:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: simplified process
	instance view
Message-ID: <23048843.1168270219059.JavaMail.jboss@colo-br-02.atl.jboss.com>

hmmmm won't this screen be cluttered with info? You know, all tasks have had their own variables, comments etc... or just the processlevel comments (where do we enter those?) and processlevel variables?

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

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


From do-not-reply at jboss.com  Mon Jan  8 10:31:42 2007
From: do-not-reply at jboss.com (brittm)
Date: Mon, 8 Jan 2007 10:31:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: user based process
	versioning ?
Message-ID: <17408125.1168270302262.JavaMail.jboss@colo-br-02.atl.jboss.com>

Being able to normalize two Process Definitions could be a nice feature, but it also looks to me like a whole lot of trouble.  Also, it seems more like a developer's "Oops, I didn't record what I was doing, so now I don't know what I have," kind of feature, rather than a solid business function.

I do think that carrying a settable version number in addition to the current incremented one could be a good idea--sort of like the difference between a business key and a primary key.  This way the developer could specify a version number that could be kept in sync with CVS and other deployables.

-Britt

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

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


From do-not-reply at jboss.com  Mon Jan  8 10:34:17 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 8 Jan 2007 10:34:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <12145518.1168270457715.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bazoo" wrote : Instead of "End Task", I would suggest "Proceed", to reinforce the idea that the user is moving through a process.

The "End Task" is not terminology that is defined by the web console.  The caption of each of the transition buttons is determined by the name of the corresponding transition.  In this case, the "websale" example process happens to have transitions named "End Task".

To demonstrate this, you can run the websale process to this point in its execution, and go to the process instance view.  From here go to the Tokens tab and choose to signal the token that is waiting on that task.  You will see a listing of all the possible transitions.

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

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


From do-not-reply at jboss.com  Mon Jan  8 10:41:56 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Mon, 8 Jan 2007 10:41:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: one central search
	page
Message-ID: <26487592.1168270917000.JavaMail.jboss@colo-br-02.atl.jboss.com>

I think there should be two search pages: one to support process management (processdefinitions and processInstances), one one to support task management (for taskInstances). 

ProcessInstances: search criteria to include processdefinition, start date, status /state (i.e., active, completed, suspended)

TasksInstance: search criteria to include taskname, create date, start date, end date, status / state, processinstance, actorId, pooledActorId


Having said this I again raise the concern about performance. Is the database schema and gui architecture able to handle these types of queries when there are 20,000 processInstances and 100,000 taskInstances in the db, and the query results in 2000 hits?

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

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


From do-not-reply at jboss.com  Mon Jan  8 10:44:20 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Mon, 8 Jan 2007 10:44:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover analysis
Message-ID: <5854028.1168271060785.JavaMail.jboss@colo-br-02.atl.jboss.com>

My comments regarding the WIKI page:

>>2. Failure detected when sending a new invocation into the server

For new connections, Remoting will mask any IOException as org.jboss.remoting.somewhere.CannotConnectException.

>>3. Failure detected during an in-flight invocation

On this case you get an IOException indeed.


>> Failure Handling

"Ovidiu on Wiki Page" wrote : If there are active threads traversing the valve at the moment when "close" command arrives, those threads must be interrupted and put to wait until the valve opens again

There is no way to interrupt those threads, but on the event of a failure, all of the inflight invocations are going to fail at the same time, and all of them will capture the failure trying to close the valve at the same time.


This scenario is already implemented on Clebert_Third_Failover Branch.

The is a slightly differences on the way implemented:

- I only have one valve, so there is no recursivety on closing the valve.
- There is no need for the "command center" I guess, since a call on performFailover on ConnectionDelegate is already equivalent to "a failure has happened".



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

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


From do-not-reply at jboss.com  Mon Jan  8 10:50:19 2007
From: do-not-reply at jboss.com (shawdav1)
Date: Mon, 8 Jan 2007 10:50:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Wiki] - wiki won't deploy in
	jboss-portal-2.4.1-bundled (SP1)
Message-ID: <9914705.1168271419525.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi:

Is jbosswiki-beta2-2.4-bin.tgz supposed to be compatible with jboss-portal-2.4.1-bundled (SP1)? It fails to deploy.

I can post details if desired.

Thanks

David

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

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


From do-not-reply at jboss.com  Mon Jan  8 10:51:18 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 8 Jan 2007 10:51:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: user based process
	versioning ?
Message-ID: <4067254.1168271478982.JavaMail.jboss@colo-br-02.atl.jboss.com>

In my opinion the new prototype would work like this:

All process information is stored in the process definition archive (not in the database).  The database has a row for the process, and a row for the specific version; this allows executions to link back to their owning process.  These rows need not use system-maintained versioning, and in fact probably should not.

A process definition archive contains the name and version of the process, as well as any associated information (process diagram, forms, etc).  A variation on the standard file deployer is used to add a process definition to the container.

A jBPM instance can execute any process that is currently deployed.  An attempt to execute a process that is not deployed in the current container will result in an exception.

Deploying processes in this way has several advantages:

* We no longer have to deal with BLOBs, as we are not storing large chunks of binary data in the database.  The process definition archives and their associated metadata are deployed much like any other javaee component.
* We support two models of versioning.  The first allows the user to deploy a new, independent version of their process by specifying a new version number, allowing the old version to continue to exist.  The second allows the user to easily *replace* the definition of an existing version, in the case where they have (for example) a critical bug in their process definition and they want to get a quick fix out there, without having to execute a potentially complicated data update as well.
* Table normalization.  This should always be a goal in my opinion.  We should never require grouping or distinct operations for a query of a simple domain object, as we do today for distinct process definitions.
* Reusing standard javaee deployment mechanism.  This is the standard way of performing a javaee deployment.  By way of comparison, EJB authors do not deploy their code into the database; and they are used to the idea of doing a new file deployment for new versions of their applications.


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

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


From do-not-reply at jboss.com  Mon Jan  8 10:56:26 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Mon, 8 Jan 2007 10:56:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Component Proposal -
	Configurable Service Locator
Message-ID: <7033882.1168271786573.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : From your point of view is what I am doing wrong or is it just another way to do the same things ? 

IMO, there is rarely a right/wrong way just better ways.  For client configuration your way is better.  The Java EE Client container can provide the same funtionality for you though in most cases (minus interceptors and XML reloading).  The JBoss equivalent to Spring container is JBoss Microcontainer i fyou want to try that out.

anonymous wrote : JNDI parameters are in XMLs, they can be changed easily.
  | Moving services from one EAR to another does not have impact on client source code but only on XMLs. 

Don't bash annotations.  Using annotations are great for fast prototyping or generally providing default values for your injections.  What I'm saying is that even if you use annotations, you can still override them in XML (web.xml, ejb-jar.xml, etc...) to provide the JNDI mappings you desire.  The specifications also support partial XML deployment descriptors so it is real easy to override one env/ entry.

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

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


From do-not-reply at jboss.com  Mon Jan  8 11:02:29 2007
From: do-not-reply at jboss.com (szimano)
Date: Mon, 8 Jan 2007 11:02:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Wiki] - Re: wiki won't deploy
	in jboss-portal-2.4.1-bundled (SP1)
Message-ID: <15195341.1168272149274.JavaMail.jboss@colo-br-02.atl.jboss.com>

AFAIK bundled version of portal doesn't have EJB3 included. Please install portal from JEMS installer 1.2.0.CR1 http://labs.jboss.com/portal/jemsinstaller/downloads

Cheers,
Tomek

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

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


From do-not-reply at jboss.com  Mon Jan  8 11:06:56 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 8 Jan 2007 11:06:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: one central search
	page
Message-ID: <33432186.1168272416045.JavaMail.jboss@colo-br-02.atl.jboss.com>

"jeffdelong" wrote : Having said this I again raise the concern about performance. Is the database schema and gui architecture able to handle these types of queries when there are 20,000 processInstances and 100,000 taskInstances in the db, and the query results in 2000 hits?

In a word: Yes. :-)  Well, subject to testing anyway.

Well, at least for the two types of data you've mentioned (process instances and task instances).

Process Definitions are a problem.  If we had 100,000 processes each with 100 versions it would be slow (to get a list of the 100,000 processes, we can't use things like limit/offset because it's a grouping operation, meaning that the server would [in this contrived case] have to accumulate 10,000,000 rows before it could return even the first 10).  I'd like to see this addressed at least for the new prototype as I've outlined in other posts.

The other queries (in the GUI) are designed right now to impose a hard limit of 100 pages, under the rationale that more than 100 pages is not useful to the user and that they should reduce the search.  This number is configurable as well.  The advantage to this approach is that the database does not need to be hit to fetch each page, which avoids a race condition where the result set changes between pages causing rows to appear to vanish (where in actuality they have simply moved from the page you are on to a prior page).  The disadvantage is that the search can result in a fairly good-sized chunk of data coming from the database (though in my actual experience it takes more than about 5k rows to start slowing things down; after all, we're only displaying one page at a time, and in most cases the real bandwidth bottleneck is between the web server and the end user, not between the web server and the database).

At some point we should be able to add well-performing sorting to this model as well, assuming judicious use of indexes.

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

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


From do-not-reply at jboss.com  Mon Jan  8 11:08:06 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 8 Jan 2007 11:08:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: simplified process
	instance view
Message-ID: <30092420.1168272486854.JavaMail.jboss@colo-br-02.atl.jboss.com>

"kukeltje" wrote : hmmmm won't this screen be cluttered with info?

Well yes, but this is to me the classic webapp tradeoff: Either you get few complex screens, or many simple screens.  It's a lose-lose situation. :-)

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

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


From do-not-reply at jboss.com  Mon Jan  8 11:12:25 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 8 Jan 2007 11:12:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: free choice of
	initial node
Message-ID: <25604764.1168272745354.JavaMail.jboss@colo-br-02.atl.jboss.com>

I agree 100%

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

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


From do-not-reply at jboss.com  Mon Jan  8 11:31:14 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 8 Jan 2007 11:31:14 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: simplified task
	instance view
Message-ID: <24973460.1168273874490.JavaMail.jboss@colo-br-02.atl.jboss.com>

"jeffdelong" wrote : I agree with Tom. I would also like to add that I don't like End Task for the name of the button. Even though the API is end, users would be more comforatable with "Complete", as it signifies that they have completed the task.

As I commented before, "End Task" is not based on the API; it's just the name of the transition in the websale example.

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

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


From do-not-reply at jboss.com  Mon Jan  8 11:34:05 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 8 Jan 2007 11:34:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: replace separate
	managers task list view with generic se
Message-ID: <20675111.1168274045402.JavaMail.jboss@colo-br-02.atl.jboss.com>

There's also the question of whether a regular user should be allowed to see other users' tasks.  If not, then even having the Actor ID column be visible and searchable is unnecessary for these users, and the column should not be visible.

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

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


From do-not-reply at jboss.com  Mon Jan  8 11:35:21 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Mon, 8 Jan 2007 11:35:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: simplified process
	instance view
Message-ID: <17110372.1168274121622.JavaMail.jboss@colo-br-02.atl.jboss.com>

it is a tradeoff, but since when is 4 many? You aren't a monkey are you? The just seam to be able to count to 4... 1,2,3,4,many.... :-)

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

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


From do-not-reply at jboss.com  Mon Jan  8 12:27:25 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Mon, 8 Jan 2007 12:27:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: PojoCache uses a
	special node factory
Message-ID: <18378961.1168277246016.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bstansberry at jboss.com" wrote : "manik.surtani at jboss.com" wrote : 
  |   | This possibility always was there, even the way the NodeFactory was used before - and still is in JBC 1.x.y -  as a Singleton.  That's the whole purpose of a factory.
  | 
  | I'm not sure how it can be done in 1.x, as NodeFactory doesn't expose any way to change the singleton.

You'd have to:

1)  Subclass Node to add more specialised behaviour, maps, locks, etc. tuned for this (InternalNode?)  Perhaps even add more specialised checks that "user" methods like get() and put() from the Node interface throw exceptions so end-users don't mess with these regions?

2)  The factory would have to instantiate the appropriate class, based on the Fqn requested.  

Changing the NodeFactory wouldn't help anyway, without 1) and 2) above, and wouldn't really add much specific benefit given how few InternalNodes would ever be created (just /_JBoss_Internal_ and /_BuddyBackup_?  I don't think sub-nodes under /_JBoss_Internal_ and /_BuddyBackup_ needs any further special behaviour?)

  

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

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


From do-not-reply at jboss.com  Mon Jan  8 12:32:12 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Mon, 8 Jan 2007 12:32:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: simplified process
	instance view
Message-ID: <2658705.1168277532070.JavaMail.jboss@colo-br-02.atl.jboss.com>


The = they

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

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


From do-not-reply at jboss.com  Mon Jan  8 12:50:43 2007
From: do-not-reply at jboss.com (dimitris@jboss.org)
Date: Mon, 8 Jan 2007 12:50:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] -
	ObjectStoreDir location
Message-ID: <33433723.1168278643574.JavaMail.jboss@colo-br-02.atl.jboss.com>

I've notice JBossTS when used in JBossAS, by default, uses:

JBOSS_HOME/bin/PutObjectStoreDirHere

to store tx recovery info.

We don't store data in the bin dir. Actually, I would expect the correct location to be inside every particular server config directory, because you can use the same bin to run multiple server configurations, so use something like:

JBOSS_HOME/server/default/data/object-store

I see this entry in conf/jbossjta-properties.xml:


In jboss xml config files we would normally use a syntax like
 ... ${jboss.server.data.dir}/object-store

Can we do something similar with the jbossjta-properties.xml configuration? Do it substitute system properties?

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

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


From do-not-reply at jboss.com  Mon Jan  8 12:53:46 2007
From: do-not-reply at jboss.com (dimitris@jboss.org)
Date: Mon, 8 Jan 2007 12:53:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <8465176.1168278826432.JavaMail.jboss@colo-br-02.atl.jboss.com>

The xml bit was trancated:

  | <property name="com.arjuna.ats.arjuna.objectstore.objectStoreDir" value="PutObjectStoreDirHere"/>
  | 

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

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


From do-not-reply at jboss.com  Mon Jan  8 12:55:48 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Mon, 8 Jan 2007 12:55:48 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Aspect integration to bootstrap classes
Message-ID: <4865249.1168278948727.JavaMail.jboss@colo-br-02.atl.jboss.com>

Or do what Adrian did in the org.jboss.test.managed.mock.MockTest of the managed project:


  |    public void testMock() throws Exception
  |    {
  |       MockDataSourceManagedObject mock = new MockDataSourceManagedObject();
  | 
  |       ManagedObject mo = WrapperAdvice.wrapManagedObject(mock);
  | ...
  | 
  | package org.jboss.managed.plugins.advice;
  | 
  | import java.util.Set;
  | 
  | import org.jboss.aop.joinpoint.Invocation;
  | import org.jboss.aop.proxy.container.AOPProxyFactoryParameters;
  | import org.jboss.aop.proxy.container.GeneratedAOPProxyFactory;
  | import org.jboss.logging.Logger;
  | import org.jboss.managed.api.Fields;
  | import org.jboss.managed.api.ManagedObject;
  | import org.jboss.managed.api.ManagedProperty;
  | 
  | /**
  |  * WrapperAdvice, intercepts methods that produce objects
  |  * that require proxies.
  |  * 
  |  * @author <a href="adrian at jboss.com">Adrian Brock</a>
  |  * @version $Revision: 59258 $
  |  */
  | public class WrapperAdvice
  | {
  |    private static Logger log = Logger.getLogger(WrapperAdvice.class);
  | 
  |    /**
  |     * Wrap a managed object
  |     * 
  |     * @param managedObject the managed object
  |     * @return the managed object wrapper
  |     */
  |    public static ManagedObject wrapManagedObject(ManagedObject managedObject)
  |    {
  |       return createProxy(managedObject, ManagedObject.class);
  |    }
  |    
  |    /**
  |     * Wrap a managed property
  |     * 
  |     * @param managedProperty the managed property
  |     * @return the managed property wrapper
  |     */
  |    public static ManagedProperty wrapManagedProperty(ManagedProperty managedProperty)
  |    {
  |       return createProxy(managedProperty, ManagedProperty.class);
  |    }
  |    
  |    /**
  |     * Wrap fields
  |     * 
  |     * @param fields the fields
  |     * @return the fields wrapper
  |     */
  |    public static Fields wrapFields(Fields fields)
  |    {
  |       return createProxy(fields, Fields.class);
  |    }
  | 
  |    /**
  |     * Wrap a returned managed object
  |     * 
  |     * @param invocation the invocation
  |     * @return the wrapped managed object
  |     * @throws Throwable for any error
  |     */
  |    public ManagedObject wrapManagedObject(Invocation invocation) throws Throwable
  |    {
  |       ManagedObject result = (ManagedObject) invocation.invokeNext();
  |       return wrapManagedObject(result);
  |    }
  | 
  |    /**
  |     * Wrap a returned managed property
  |     * 
  |     * @param invocation the invocation
  |     * @return the wrapped managed property
  |     * @throws Throwable for any error
  |     */
  |    public ManagedProperty wrapManagedProperty(Invocation invocation) throws Throwable
  |    {
  |       ManagedProperty result = (ManagedProperty) invocation.invokeNext();
  |       return wrapManagedProperty(result);
  |    }
  | 
  |    /**
  |     * Wrap a returned managed property set
  |     * 
  |     * @param invocation the invocation
  |     * @return the wrapped managed property set
  |     * @throws Throwable for any error
  |     */
  |    @SuppressWarnings("unchecked")
  |    public Set<ManagedProperty> wrapManagedPropertySet(Invocation invocation) throws Throwable
  |    {
  |       Set<ManagedProperty> result = (Set<ManagedProperty>) invocation.invokeNext();
  |       return new WrapperSet<ManagedProperty>(result, ManagedProperty.class);
  |    }
  | 
  |    /**
  |     * Wrap fields
  |     * 
  |     * @param invocation the invocation
  |     * @return the wrapped managed property
  |     * @throws Throwable for any error
  |     */
  |    public Fields wrapFields(Invocation invocation) throws Throwable
  |    {
  |       Fields result = (Fields) invocation.invokeNext();
  |       return wrapFields(result);
  |    }
  |    
  |    /**
  |     * Create a proxy 
  |     * 
  |     * @param <T> the expected type
  |     * @param target the target
  |     * @param interfaceClass the interface class
  |     * @return the proxy
  |     */
  |    static <T> T createProxy(T target, Class<T> interfaceClass)
  |    {
  |       if (target == null)
  |          return null;
  | 
  |       GeneratedAOPProxyFactory proxyFactory = new GeneratedAOPProxyFactory();
  |       AOPProxyFactoryParameters params = new AOPProxyFactoryParameters();
  |       params.setInterfaces(new Class[] { interfaceClass });
  |       params.setObjectAsSuperClass(true);
  |       params.setTarget(target);
  |       Object proxy = proxyFactory.createAdvisedProxy(params);
  |       if( log.isTraceEnabled() )
  |          log.trace("Created proxy: "+proxy.getClass()+"@"+System.identityHashCode(proxy)+" target: "+target.getClass());
  |       return interfaceClass.cast(proxy);
  |    }
  | }
  | 
  | 

which uses the WrapperAdvice to bootstrap a aop proxy so that subsequent access to the ManagedProperty are proxied. This is what I was planning on using in the ManagedObjectBuilder that created the top-level MnagedObject of a deployment.

This works right?


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

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


From do-not-reply at jboss.com  Mon Jan  8 12:56:48 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Mon, 8 Jan 2007 12:56:48 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <14406797.1168279008676.JavaMail.jboss@colo-br-02.atl.jboss.com>

can we also change the location of this jbossjta-properties.xml file?

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

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


From do-not-reply at jboss.com  Mon Jan  8 13:00:18 2007
From: do-not-reply at jboss.com (jthorn)
Date: Mon, 8 Jan 2007 13:00:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Classpath Problem
Message-ID: <16323659.1168279218895.JavaMail.jboss@colo-br-02.atl.jboss.com>

After checking out and compiling jboss labs when I execute run.sh -c all I get several classpath errors.  Has anybody else seen this and know of a solution?  

11:28:49,510 ERROR [STDERR] org.jboss.aop.instrument.TransformationException: Failed to aspectize class org.jboss.forge.common.projects.Projects.  Could not find class it references org.jboss.forge.common.projects.ProjectDescriptor  It may not be in your classpath and you may not be getting field and constructor weaving for this class.
11:29:12,609 ERROR [STDERR] [warn] Could not find class org.jboss.shotoku.exceptions.RepositoryException that org.jboss.forge.portal.TitleChangeFilter references.  It may not be in your classpath and you may not be getting field and constructor weaving for this class.
11:29:12,612 ERROR [STDERR] [warn] Could not find class org.jboss.shotoku.Node that org.jboss.forge.portal.TitleChangeFilter references.  It may not be in your classpath and you may not be getting field and constructor weaving for this class.
11:29:12,618 ERROR [STDERR] [warn] Could not find class org.jboss.shotoku.exceptions.ResourceDoesNotExist that org.jboss.forge.portal.TitleChangeFilter references.  It may not be in your classpath and you may not be getting field and constructor weaving for this class.
11:29:12,620 ERROR [STDERR] [warn] Could not find class org.jboss.shotoku.ContentManager that org.jboss.forge.portal.TitleChangeFilter references.  It may not be in your classpath and you may not be getting field and constructor weaving for this class.
11:29:36,483 ERROR [STDERR] org.jboss.aop.instrument.TransformationException: Failed to aspectize class org.quartz.impl.StdSchedulerFactory.  Could not find class it references org.quartz.utils.PoolingConnectionProvider  It may not be in your classpath and you may not be getting field and constructor weaving for this class.
11:30:19,902 ERROR [STDERR] org.jboss.aop.instrument.TransformationException: Failed to aspectize class org.jbosslabs.portlets.primates.service.PrimatesServiceImpl.  Could not find class it references org.jbosslabs.portlets.primates.PrimatesTools  It may not be in your classpath and you may not be getting field and constructor weaving for this class.
11:30:27,738 ERROR [STDERR] org.jboss.aop.instrument.TransformationException: Failed to aspectize class org.springframework.aop.support.RegexpMethodPointcutAdvisor.  Could not find class it references org.springframework.aop.support.Perl5RegexpMethodPointcut  It may not be in your classpath and you may not be getting field and constructor weaving for this class.
11:30:30,046 ERROR [STDERR] [warn] Could not find class net.sf.cglib.asm.util.TraceClassVisitor that net.sf.cglib.core.DebuggingClassWriter$1 references.  It may not be in your classpath and you may not be getting field and constructor weaving for this class.
11:30:31,778 ERROR [STDERR] org.jboss.aop.instrument.TransformationException: Failed to aspectize class org.quartz.impl.StdSchedulerFactory.  Could not find class it references org.quartz.utils.PoolingConnectionProvider  It may not be in your classpath and you may not be getting field and constructor weaving for this class.


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

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


From do-not-reply at jboss.com  Mon Jan  8 13:04:18 2007
From: do-not-reply at jboss.com (Kevin.Conner@jboss.com)
Date: Mon, 8 Jan 2007 13:04:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <20428867.1168279458150.JavaMail.jboss@colo-br-02.atl.jboss.com>

"dimitris at jboss.org" wrote : JBOSS_HOME/bin/PutObjectStoreDirHere
This is an entry that is supposed to be changed during installation.

JBossTS has no direct knowledge of the app server nor of any app server specific processing used in the config.  Having said that it should be possible to modify the integration code to use the data directory as a default.

Kev


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

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


From do-not-reply at jboss.com  Mon Jan  8 13:05:53 2007
From: do-not-reply at jboss.com (Kevin.Conner@jboss.com)
Date: Mon, 8 Jan 2007 13:05:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <33025746.1168279553809.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bill.burke at jboss.com" wrote : can we also change the location of this jbossjta-properties.xml file?
Our only requirement at present is that it should be found on the classpath.  Where would you prefer it to be picked up from?  Why is conf inappropriate?

Kev

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

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


From do-not-reply at jboss.com  Mon Jan  8 13:16:04 2007
From: do-not-reply at jboss.com (unibrew)
Date: Mon, 8 Jan 2007 13:16:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Classpath Problem
Message-ID: <30543701.1168280164399.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hello

We are not getting those warnings. I wouldn't worry if Labs are working, are they? If not, are you using our JBossAS installed by "maven install" ? And did you set properly all values in all property files as described in "maven help"? Please also check whether those missing classes are deployed into your "all" instance of JBossAS.

Regards
----------------------
Ryszard Kozmik
JBoss Forums Lead
JBoss Labs Team

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

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


From do-not-reply at jboss.com  Mon Jan  8 13:18:03 2007
From: do-not-reply at jboss.com (dimitris@jboss.org)
Date: Mon, 8 Jan 2007 13:18:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <19329448.1168280283441.JavaMail.jboss@colo-br-02.atl.jboss.com>

If you can just introduce property substitution that would be great.

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

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


From do-not-reply at jboss.com  Mon Jan  8 13:19:20 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Mon, 8 Jan 2007 13:19:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <5805088.1168280360505.JavaMail.jboss@colo-br-02.atl.jboss.com>

I would like to be able to configure the classpath resource it is found from.  The reason for this is that I'm implementing JBoss Embedded at them moment and I need a configurable, base resource path so that it is easy, for instance, to install embedded JBoss onto Tomcat.

Why not just extend the MBean that is used and override settings from there?


Then again....


Are all the properties in jbossjta-properties.xml overrideable from System properties?

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

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


From do-not-reply at jboss.com  Mon Jan  8 13:21:07 2007
From: do-not-reply at jboss.com (mark.little@jboss.com)
Date: Mon, 8 Jan 2007 13:21:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <127265.1168280467178.JavaMail.jboss@colo-br-02.atl.jboss.com>

Every property can be overridden via System.

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

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


From do-not-reply at jboss.com  Mon Jan  8 13:22:23 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Mon, 8 Jan 2007 13:22:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <33120389.1168280543921.JavaMail.jboss@colo-br-02.atl.jboss.com>

...adding to this...

Can the classpath resource of jbossjta-properties.xml be configurable as a System Property?  Or even the file or URL location of it?

THanks

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

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


From do-not-reply at jboss.com  Mon Jan  8 13:24:32 2007
From: do-not-reply at jboss.com (mark.little@jboss.com)
Date: Mon, 8 Jan 2007 13:24:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <16428313.1168280672622.JavaMail.jboss@colo-br-02.atl.jboss.com>

"dimitris at jboss.org" wrote : I've notice JBossTS when used in JBossAS, by default, uses:
  | 
  | JBOSS_HOME/bin/PutObjectStoreDirHere
  | 
  | to store tx recovery info.
  | 
  | We don't store data in the bin dir. Actually, I would expect the correct location to be inside every particular server config directory, because you can use the same bin to run multiple server configurations, so use something like:
  | 
  | JBOSS_HOME/server/default/data/object-store
  | 
  | I see this entry in conf/jbossjta-properties.xml:
  | 
  | 
  | In jboss xml config files we would normally use a syntax like
  |  ... ${jboss.server.data.dir}/object-store
  | 
  | Can we do something similar with the jbossjta-properties.xml configuration? Do it substitute system properties?

We've always encouraged users to change that setting when installing into JBoss. Putting it within the JBossAS install wasn't always guaranteed to work because, certainly back in the 3.2.x days, people would often install JBossAS into read-only directories. The object store dir must be writeable.

Do we assume that the JBossAS directory is always writeable?

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

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


From do-not-reply at jboss.com  Mon Jan  8 13:25:40 2007
From: do-not-reply at jboss.com (Kevin.Conner@jboss.com)
Date: Mon, 8 Jan 2007 13:25:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <6785921.1168280740938.JavaMail.jboss@colo-br-02.atl.jboss.com>

"dimitris at jboss.org" wrote : If you can just introduce property substitution that would be great.
JBossTS is a standalone transaction manager and does not currently support this.  Overriding the default value in the integration layer would, however, allow you to configure it via the mbean and therefore take advantage of the substitution support in the app server.

Kev


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

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


From do-not-reply at jboss.com  Mon Jan  8 13:26:07 2007
From: do-not-reply at jboss.com (mark.little@jboss.com)
Date: Mon, 8 Jan 2007 13:26:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <5234675.1168280767573.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bill.burke at jboss.com" wrote : ...adding to this...
  | 
  | Can the classpath resource of jbossjta-properties.xml be configurable as a System Property?  Or even the file or URL location of it?
  | 
  | THanks

Yes, you can always specify the location of the property file explicitly via System. If it's not located there, then it starts to search the classpath and other places (e.g., cwd).

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

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


From do-not-reply at jboss.com  Mon Jan  8 13:26:45 2007
From: do-not-reply at jboss.com (Kevin.Conner@jboss.com)
Date: Mon, 8 Jan 2007 13:26:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <7284477.1168280805555.JavaMail.jboss@colo-br-02.atl.jboss.com>

"mark.little at jboss.com" wrote : Do we assume that the JBossAS directory is always writeable?
The data directory is :-)

Kev


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

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


From do-not-reply at jboss.com  Mon Jan  8 13:27:22 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Mon, 8 Jan 2007 13:27:22 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <22428415.1168280842567.JavaMail.jboss@colo-br-02.atl.jboss.com>

And the config file location System Property is?  (Thanks for being my manual)

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

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


From do-not-reply at jboss.com  Mon Jan  8 13:30:55 2007
From: do-not-reply at jboss.com (mark.little@jboss.com)
Date: Mon, 8 Jan 2007 13:30:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <16561031.1168281055821.JavaMail.jboss@colo-br-02.atl.jboss.com>

"Kevin.Conner at jboss.com" wrote : "mark.little at jboss.com" wrote : Do we assume that the JBossAS directory is always writeable?
  | The data directory is :-)
  | 
  | Kev
  | 

Good ;-)

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

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


From do-not-reply at jboss.com  Mon Jan  8 13:42:46 2007
From: do-not-reply at jboss.com (mark.little@jboss.com)
Date: Mon, 8 Jan 2007 13:42:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <20228663.1168281766433.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bill.burke at jboss.com" wrote : And the config file location System Property is?  (Thanks for being my manual)

I suppose you're just lucky Adrian isn't watching ;-)

com.arjuna.ats.arjuna.common.propertiesFile is used to set the file name. If not passed an absolute filename (starting with the string abs://), then the system searches for the file in the order:
 *   current working directory
 *   in the directory specified by the system property user.dir
 *   in the directory specified by the system property user.home
 *   in the directory specified by the system property java.home
 *   using the getResource() method

Hope that helps.


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

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


From do-not-reply at jboss.com  Mon Jan  8 13:52:09 2007
From: do-not-reply at jboss.com (koen.aers@jboss.com)
Date: Mon, 8 Jan 2007 13:52:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: user based process
	versioning ?
Message-ID: <30313151.1168282329251.JavaMail.jboss@colo-br-02.atl.jboss.com>

"david" wrote : A process definition archive contains the name and version of the process, as well as any associated information (process diagram, forms, etc).  A variation on the standard file deployer is used to add a process definition to the container.
Hm, does this not imply that you are forced to use Java EE? I think that much of the elegance of the current system comes from its lightweightness and its ability to embed itself in whatever system. It would be a pity to lose that IMO. Or is there something I am not getting?

I like the option of a 'settable version number', much like manifest information that you can add to any archive.

Regards,
Koen

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

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


From do-not-reply at jboss.com  Mon Jan  8 13:52:59 2007
From: do-not-reply at jboss.com (dimitris@jboss.org)
Date: Mon, 8 Jan 2007 13:52:59 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <6284333.1168282379672.JavaMail.jboss@colo-br-02.atl.jboss.com>

"Kevin.Conner at jboss.com" wrote : "dimitris at jboss.org" wrote : If you can just introduce property substitution that would be great.
  | JBossTS is a standalone transaction manager and does not currently support this.  Overriding the default value in the integration layer would, however, allow you to configure it via the mbean and therefore take advantage of the substitution support in the app server.
  | Kev
  | 
You mean add it to the com.arjuna.ats.jbossatx.jta.TransactionManagerService mbean?

Maybe this integrating mbean should live in the jboss codebase, that would make thinks a lot easier when applying small changes like this.


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

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


From do-not-reply at jboss.com  Mon Jan  8 14:01:12 2007
From: do-not-reply at jboss.com (mark.little@jboss.com)
Date: Mon, 8 Jan 2007 14:01:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <29452842.1168282873000.JavaMail.jboss@colo-br-02.atl.jboss.com>

There's a separate integration module in the TS code, where integration code for application servers exists. These days it only has AS code in there, but over the years the amount of code there has grown and shrunk. I prefer the current approach because then there's a single location for all integration code related to TS and supported platforms.

Kev will know for sure, but I suspect this code lives in its own jar. If that's the case then rebuilding that shouldn't ever require a re-QA of the stand-alone TS: just re-QA for the integration.

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

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


From do-not-reply at jboss.com  Mon Jan  8 14:10:41 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 8 Jan 2007 14:10:41 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: user based process
	versioning ?
Message-ID: <24527718.1168283441500.JavaMail.jboss@colo-br-02.atl.jboss.com>

"koen.aers at jboss.com" wrote : Hm, does this not imply that you are forced to use Java EE? I think that much of the elegance of the current system comes from its lightweightness and its ability to embed itself in whatever system. It would be a pity to lose that IMO.

Well, storing the archive data inside the database isn't exactly lightweight. :-)

I don't think you'd have to use java ee deployers if you didn't want to, I'm just using that as an example.  As long as the engine knows where to pick up process definitions it should work.  This is (I think) actually a simpler use-case of javaee deployers, since there's no special startup or shutdown action to be taken; it just has to store the process information in a Map.  Likewise the standalone version can just read the process definitions from the filesystem; it already has the plumbing to do this today as far as I can see.

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

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


From do-not-reply at jboss.com  Mon Jan  8 14:21:02 2007
From: do-not-reply at jboss.com (Kevin.Conner@jboss.com)
Date: Mon, 8 Jan 2007 14:21:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] - Re:
	ObjectStoreDir location
Message-ID: <16645605.1168284062159.JavaMail.jboss@colo-br-02.atl.jboss.com>

"mark.little at jboss.com" wrote : There's a separate integration module in the TS code, where integration code for application servers exists. These days it only has AS code in there, but over the years the amount of code there has grown and shrunk. I prefer the current approach because then there's a single location for all integration code related to TS and supported platforms.
This would also be my preference as we would normally only change it if there was a change in the associated core libraries.

"mark.little at jboss.com" wrote : Kev will know for sure, but I suspect this code lives in its own jar. If that's the case then rebuilding that shouldn't ever require a re-QA of the stand-alone TS: just re-QA for the integration.
Yes, that is correct.  This has no bearing on our standalone QA run and is tested using the AS testsuite.

Kev


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

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


From do-not-reply at jboss.com  Mon Jan  8 14:41:51 2007
From: do-not-reply at jboss.com (akostadinov)
Date: Mon, 8 Jan 2007 14:41:51 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: ejb3-head testsuite
Message-ID: <17027069.1168285311429.JavaMail.jboss@colo-br-02.atl.jboss.com>

It now fails to stop the server and build fails. I tried jdk1.5.0_10 also with no success. Any suggestions? See http://cruisecontrol.jboss.com/cc/artifacts/ejb3-head-testsuite/20070107164943/tests.log

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

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


From do-not-reply at jboss.com  Mon Jan  8 15:01:23 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Mon, 8 Jan 2007 15:01:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: ejb3-head testsuite
Message-ID: <28716719.1168286483758.JavaMail.jboss@colo-br-02.atl.jboss.com>

Not really, other than looking in the server.log from the all config to see if it reveals anything.

Last week I was testing with the clustering configs (called node0 and node1) and ant didn't have any problems stopping them on my dev machine.  They're stripped down versions of 'all'.

Only tangentially related, but the AS testsuite adds xmlns:server="http://jboss.org/ns/test/ant/server" to the "project" tag in its build xml and thereafter uses the server:start and server:stop macros to start/stop servers.  This is instead of the start-jboss and stop-jboss macros that EJB3 is pulling in from testsuite/imports/server-config.xml.  Should we look at doing the same in EJB3?  Having 2 ways of starting/stopping the AS seems unnecessary and a possible source of problems.  Also, using the server:start/stop approach helps decouple EJB3 from the testuite module.

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

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


From do-not-reply at jboss.com  Mon Jan  8 15:10:51 2007
From: do-not-reply at jboss.com (krishna_mv)
Date: Mon, 8 Jan 2007 15:10:51 -0500 (EST)
Subject: [jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] -
	JBOSS4.0 - Startup Class in Ear - Urgent HELP
Message-ID: <18972494.1168287051399.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi friends,

I have the following issue.

I have a custom startup class which is supposed to run when we start the server. I have a message in the class which should print just before "Started in 29s:750ms (which is the last line when u start the server)".

I can handle this with Mbean and jboss-service.xml. But I have some dependency classes in ear file which talks to this startup class.

So, the issue is - is it possible to put the startup class in EAR and configure somewhere so that my message gets printed when I just start the server.

Appreciate you suggestion.

Thanks

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

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


From do-not-reply at jboss.com  Mon Jan  8 15:45:50 2007
From: do-not-reply at jboss.com (jthorn)
Date: Mon, 8 Jan 2007 15:45:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Classpath Problem
Message-ID: <17339021.1168289150032.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm also seeing some errors about the content manager which suggests to me the shotoku might not be configured right.  Here is the shotoku.properties that we used to build.  I know several of these properties arent set, is it ok to leave them blank or can anybody give me an idea what to put in them?  

#
# Content managers configuration
# ------------------------------
#

# Default content manager id
shotoku.id.default = default

# All ids that will be available for use
shotoku.ids = default

# Definitions of content managers
shotoku.default.implementation = org.jboss.shotoku.svn.SvnContentManager
shotoku.default.url = 
shotoku.default.username = 
shotoku.default.password =
shotoku.default.localpath =
shotoku.default.fullupdate = 1
# Should externals be checked out during an update of the WC.
shotoku.default.externals = true

# shotoku.file.implementation = org.jboss.shotoku.files.FileContentManager
# shotoku.file.localpath =

# shotoku.jcr.implementation = org.jboss.shotoku.jcr.JcrContentManager
# shotoku.jcr.connector = org.jboss.shotoku.jcr.JackrabbitJcrConnector
# shotoku.jcr.configfile =
# shotoku.jcr.username =
# shotoku.jcr.password =
# shotoku.jcr.localpath =

#
# General configuration
# ---------------------
#

# Embedded/ application server mode
shotoku.embedded = false

# Size of a byte array that is allocated when transferring files to/from
# the client
shotoku.transfer.buffer.size = 1024

# Interval between service (and cache) updates, in milliseconds
shotoku.service.interval = 10000

# Number of created update threads (used for updating cache items)
shotoku.updatethread.count = 10

#
# Feeds configuration
# -------------------
#

# Content manager and directory in which feeds.properties is placed in shotoku
shotoku.internal.feeds.configcmid =
shotoku.internal.feeds.configdir =

# Interval between feed updates, in milliseconds
shotoku.internal.feeds.service.interval = 10000

#
# Tags configuration
# ------------------
#

# Should synchronization of tags be done
shotoku.internal.tags.synchronization = 1

# Content manager and base directory with which synchronization of Shotoku tags
# will be done
shotoku.internal.tags.cmid =
shotoku.internal.tags.cmdir =

# Interval between tag synchronization updates, in milliseconds
shotoku.internal.tags.service.interval = 10000

#
# Tests configuration
# -------------------
#

# Content manager and base directory in which tests will be done
shotoku.internal.tests.id = default
shotoku.internal.tests.dir = shotoku-test

#
# SVN content manager service configuration
# -----------------------------------------

# Interval between working copy updates, in milliseconds
shotoku.internal.svn.service.interval = 5000

# A debugging property which, when set to 0, will cause repositories not to be
# updated for the first time when being registered.


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

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


From do-not-reply at jboss.com  Mon Jan  8 16:03:22 2007
From: do-not-reply at jboss.com (szimano)
Date: Mon, 8 Jan 2007 16:03:22 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Classpath Problem
Message-ID: <13675883.1168290202093.JavaMail.jboss@colo-br-02.atl.jboss.com>

Key properties are:

shotoku.default.url = 
shotoku.default.username = 
shotoku.default.password = 
shotoku.default.localpath = 

You have to fill them in with your repository credentials, where your CMS template should be uploaded.

Tomek

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

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


From do-not-reply at jboss.com  Mon Jan  8 16:25:12 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Mon, 8 Jan 2007 16:25:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Aspect integration to bootstrap classes
Message-ID: <23939755.1168291512714.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ah yes, how could I forget about the proxies I helped implement :-) I'll have a look at where the managed object are created and try to fit them in

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

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


From do-not-reply at jboss.com  Mon Jan  8 16:39:37 2007
From: do-not-reply at jboss.com (Cyberax)
Date: Mon, 8 Jan 2007 16:39:37 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Re: Exception propagation
	using HTTP servlet transport on 1.
Message-ID: <8065363.1168292377574.JavaMail.jboss@colo-br-02.atl.jboss.com>

I was not able to test it, because JBoss 4.0.5 doesn't support Remoting2 yet.

BTW, it's not clear from documentation: does Remoting2 preserve exception type thrown from server?

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

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


From do-not-reply at jboss.com  Mon Jan  8 16:41:11 2007
From: do-not-reply at jboss.com (longfangq@hotmail.com)
Date: Mon, 8 Jan 2007 16:41:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Redelivery caused by System.exit()?
Message-ID: <13447014.1168292471191.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi,

When our program receives a JMS message which instructs it to shut down, it calls System.exit(0). It works well with another application server. When we try to migrate to JBoss, we found that JMS message will not be consumed, which means the program does receive the message and exit but when it restarts, that JMS message will be redelievered and cause it to exit again and therefor an infinite loop. 

We use non-transactional messaging and auto acknolowledge:
        QueueSession qSession = qCon.createQueueSession(false,
            Session.AUTO_ACKNOWLEDGE);

Can anyone kindly help? many thanks!

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

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


From do-not-reply at jboss.com  Mon Jan  8 17:44:47 2007
From: do-not-reply at jboss.com (jthorn)
Date: Mon, 8 Jan 2007 17:44:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Classpath Problem
Message-ID: <22187453.1168296287456.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, after we put something in those properties it starts up with only a few classpath erros but when we try to hit the page we are now getting a null pointer exception and this shows up on the console:

Caused by: org.apache.jasper.JasperException: Exception in JSP: /layouts/jbossForge.jsp:15

12: <%
13:     if (!response.isCommitted()) {
14: %>
15: <jsp:forward page="/repo-access/default/theme/jsp/jbossForge.jsp" />
16: <%
17:     }
18: %>


Stacktrace:
        at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:504)
        at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375)
        at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
        at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.jboss.portal.theme.LayoutDispatcher.execute(LayoutDispatcher.java:109)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.portal.server.servlet.CommandFilter.doFilter(CommandFilter.java:65)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
        at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
        at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
        at org.jboss.portal.theme.LayoutDispatcher.include(LayoutDispatcher.java:139)
        at org.jboss.portal.theme.impl.JSPLayout.assembleResponse(JSPLayout.java:34)
        at org.jboss.portal.core.command.MarkupCommand.execute(MarkupCommand.java:360)
        ... 97 more
Caused by: javax.servlet.ServletException: /default/theme/jsp/jbossForge.jsp
        at org.jboss.forge.common.FilesFromRepoFilter.doFilter(FilesFromRepoFilter.java:110)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
        at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
        at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398)
        at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
        at org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java:703)
        at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:670)
        at org.apache.jsp.layouts.jbossForge_jsp._jspService(jbossForge_jsp.java:64)
        at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
        at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
        ... 116 more
16:22:24,165 ERROR [[PortalServletWithPathMapping]] Servlet.service() for servlet PortalServletWithPathMapping threw exception
org.jboss.shotoku.exceptions.ResourceDoesNotExist: /default/theme/jsp/jbossForge.jsp


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

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


From do-not-reply at jboss.com  Mon Jan  8 17:58:40 2007
From: do-not-reply at jboss.com (szimano)
Date: Mon, 8 Jan 2007 17:58:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Classpath Problem
Message-ID: <23570437.1168297120762.JavaMail.jboss@colo-br-02.atl.jboss.com>

It only means you haven't uploaded CMS to your repo.

Here's the cms template that you have to upload to you repository that you've set up in shotoku.properties

http://anonsvn.labs.jboss.com/labs/jbosslabs/trunk/cms-template/

Cheers,
Tomek

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

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


From do-not-reply at jboss.com  Mon Jan  8 18:36:29 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Mon, 8 Jan 2007 18:36:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- JBMESSAGING-674 - Propagation of server List to client
Message-ID: <11041602.1168299389256.JavaMail.jboss@colo-br-02.atl.jboss.com>

This is a discussion of http://jira.jboss.com/jira/browse/JBMESSAGING-674

Is it okay if I add these fields to ServerConnectionFactoryEndpoint?  :

   protected int viewId;
  |    private ClientConnectionFactoryDelegate[] delegates;
  | 
  |    // Map <Integer(nodeID)->Integer(failoverNodeID)>
  |    private Map failoverMap;
  | 

I want to update viewId and these other fields on ServerConnectionFactoryEndpoint every time the Replicator fires a change, and every time we need Connections I will be comparing clientSide viewId with server's side on ClusteredConnectionFactory.

Of course these fields will be 0 or Null in case of NonClusteredConnections.

Any objections?


Clebert

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

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


From do-not-reply at jboss.com  Mon Jan  8 19:31:22 2007
From: do-not-reply at jboss.com (bnoll)
Date: Mon, 8 Jan 2007 19:31:22 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Persistence on JBoss] - Fix for
	org.jboss.util.file.ArchiveBrowser
Message-ID: <27599574.1168302682787.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm not sure that this is the best place to post this, but I ran into the problem when doing JPA stuff, so this is where I came.  If it needs to be moved, please do so.

The class org.jboss.util.file.ArchiveBrowser in jboss-archive-browsing-5.0.0alpha-200607201-119.jar seems to puke when the 'getBrowser' method encounters whitespace.  It looks like this was a bug once upon a time (as per http://jira.jboss.com/jira/browse/JBCOMMON-1) that has resurfaced.

The offending lines are:

  |             File file = null;
  |             try
  |             {
  |                 file = new File(new URI(url.toString()));
  |             }
  |             catch(URISyntaxException urisyntaxexception)
  |             {
  |                 throw new RuntimeException("Not a valid URL: " + url, urisyntaxexception);
  |             }

The change should be as easy as saying...

  | file = new File (new URI(url.toString().replace(" ", "+")));
  | 

There may be some utility down in the jboss common code or other open source library that I'm not aware of that encapsulates this functionality.  

This is occurring when trying to run tests in a maven 2 project, and those tests depend on and refer to a jar in my local repo that contains the annotated persistent entities.  I'm working on a Windows machine, so unfortunately, that jar lives in 'C:\Documents and Settings', which is causing the problem.  I tried it on a mac, where my m2 repo doesn't contain a space, and it works just fine.

Here is a portion of the stack trace:

Caused by: java.lang.RuntimeException: Not a valid URL: file:/C:/Documents and Settings/bnoll/.m2/repository/org/appfuse/appfuse-jpa-common-working/2.0-SNAPSHOT/appfuse-jpa-common-working-2.0-SNAPSHOT.jar
	at org.jboss.util.file.ArchiveBrowser.getBrowser(Unknown Source)
	at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:610)
	... 38 more



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

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


From do-not-reply at jboss.com  Mon Jan  8 19:47:35 2007
From: do-not-reply at jboss.com (genman)
Date: Mon, 8 Jan 2007 19:47:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBossMQ delayed redelivery implementation
Message-ID: <11569773.1168303655233.JavaMail.jboss@colo-br-02.atl.jboss.com>


I came up with this feature. It is an oversight. The feature I did not need to have work with session recovery, just with transactions.

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

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


From do-not-reply at jboss.com  Mon Jan  8 19:53:06 2007
From: do-not-reply at jboss.com (genman)
Date: Mon, 8 Jan 2007 19:53:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Expiring/DLQ same message from multiple subscriptions
Message-ID: <12152414.1168303986250.JavaMail.jboss@colo-br-02.atl.jboss.com>

"timfox" wrote : If I send a message to a topic, and it ends up being delivered to n subscriptions on that topic, then the message expires, should the message be added to the expiry queue n times, one for each subscription, or only once?
  | 

JBossMQ creates an expired message for every subscription.

anonymous wrote : 
  | A more complex but related situation is for messages that have exceeded max delivery attempts.
  | 
  | If a message is sent to a topic with n subscriptions. Then depending on how many times the client calls recover() or rollback() for one or more of the subscriptions, then the message could have exceeded max delivery attempts for some of the subscriptions but not with others.
  | 
  | So the message needs to be added to the DLQ for some of the subscriptions, but not for others - how does this effect the subscriptions who have not exceeded max delivery attempts?
  | 
  | Can we end up with a situation where the same message (same message id) is in the queue (dlq or expiry queue) multiple times? Would we get primary key violations in the database?
  | 

How I did it was to basically create a new message, which is mostly a copy of the original message, with additional headers indicating the original message ID, queue or topic name, and time of expiry. Then, JBossMQ would remove the old message and store the new message as a single DB operation.

You don't really need to worry about ID conflicts therefore.

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

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


From do-not-reply at jboss.com  Mon Jan  8 19:54:42 2007
From: do-not-reply at jboss.com (genman)
Date: Mon, 8 Jan 2007 19:54:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Tests for JBoss MQ message counter functionality
Message-ID: <9515135.1168304082500.JavaMail.jboss@colo-br-02.atl.jboss.com>

There aren't any tests I know of. The counter functionality is really bad (the JMX methods return HTML blocks which would have to be parsed) and Adrian continues to threaten to remove it.

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

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


From do-not-reply at jboss.com  Mon Jan  8 19:59:12 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Mon, 8 Jan 2007 19:59:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagation of server List to client
Message-ID: <31524365.1168304352826.JavaMail.jboss@colo-br-02.atl.jboss.com>

Instead of updating failoverMap on every communication we will be doing activelly when server's view (failoverMap and connectionDelegate) has changed.

We will have a static list somewhere on the client, and update that list when new nodes are joining the cluster. I will have to think of something, as right now I don't have many details about how this will be implemented.

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

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


From do-not-reply at jboss.com  Mon Jan  8 20:32:58 2007
From: do-not-reply at jboss.com (Cyberax)
Date: Mon, 8 Jan 2007 20:32:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Leasing is br0ken in servlet transport.
Message-ID: <4974645.1168306378237.JavaMail.jboss@colo-br-02.atl.jboss.com>

Servlet transport doesn't process lease request messages, so it doesn't work.

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

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


From do-not-reply at jboss.com  Mon Jan  8 20:58:37 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Mon, 8 Jan 2007 20:58:37 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover analysis
Message-ID: <2867792.1168307917492.JavaMail.jboss@colo-br-02.atl.jboss.com>

Clebert wrote : 
  | Ovidiu on Wiki Page wrote : If there are active threads traversing the valve at the moment when "close" command arrives, those threads must be interrupted and put to wait until the valve opens again
  | 
  | 
  | There is no way to interrupt those threads, but on the event of a failure, all of the inflight invocations are going to fail at the same time, and all of them will capture the failure trying to close the valve at the same time.
  | 

Not in a portable way, I agree. But then I said that a possibility would be to close the valve regardless of any active thread, since the active threads will have no choice but fail anyway shortly. 

For that, we need to make sure that:
1. We can close a valve with active threads traversing it
2. Once a valve is closed, it still handles correctly a downstream failure.


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

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


From do-not-reply at jboss.com  Mon Jan  8 21:08:59 2007
From: do-not-reply at jboss.com (Cyberax)
Date: Mon, 8 Jan 2007 21:08:59 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Servlet transport is completely broken.
Message-ID: <32516680.1168308539337.JavaMail.jboss@colo-br-02.atl.jboss.com>

Servlet transport (in Remoting 2.0) is broken in sooooo many ways....

1) There can't be two servlet invokers (it's necessary, for example, if you want to use them for JBoss Messagning and for EJBs - they require separate connectors) because ObjectName is hard-coded in ServletServerInvoker.java
2) Null returns from invokers are sent to client as empty 204 responses and custom marshallers have no change to process return value. This breaks JBoss Messaging which expects that EVERY message contains at least two bytes (version tag and format tag). 
3) No support for PINGS.
4) etc.

I've fixed all of them :) Now I can use JBoss Messaging using servlet connector. Should I send patch version?

BTW, probably some of these bugs are present in other invokers (HTTP invoker, in particular).

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

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


From do-not-reply at jboss.com  Mon Jan  8 21:26:46 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Mon, 8 Jan 2007 21:26:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover analysis
Message-ID: <13957189.1168309606584.JavaMail.jboss@colo-br-02.atl.jboss.com>

Keeping a single centralized valve per connection gives a single point of bottleneck. All threads invoking into any delegate will have to acquire/release the synchronization element of that valve. This will lead to a lot of contention.

Distributing the load across different valve instances will relieve some of this pressure, with no apparent drawback.


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

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


From do-not-reply at jboss.com  Mon Jan  8 21:33:25 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Mon, 8 Jan 2007 21:33:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover analysis
Message-ID: <5507485.1168310005492.JavaMail.jboss@colo-br-02.atl.jboss.com>

Even if we keep a single valve instance per connection, I see no reason to involve remotingConnection at such low level, as you do in


  | JMSRemotingConnection remotingConnection = null;
  | 
  |       try
  |       {
  |          valve.enter();
  | 
  |          // it's important to only retrieve the remotingConnection while inside the Valve, as we
  |          // guarantee that no failover has happened yet
  |          remotingConnection = connectionState.getRemotingConnection();
  |          return invocation.invokeNext();
  |       }
  |       catch (CannotConnectException e)
  |       {
  |          log.warn("We got a CannotConnectionException and we are trying a failover", e);
  |          ((ConnectionDelegate)connectionState.getDelegate()).performFailover(remotingConnection);
  |          return invocation.invokeNext();
  | 
  |       }
  |       catch (IOException e)
  |       {
  |          log.warn("We got an IOException and we are trying a failover", e);
  |          ((ConnectionDelegate)connectionState.getDelegate()).performFailover(remotingConnection);
  |          return invocation.invokeNext();
  |       }

Why don't we just message the connection: "there's failure, deal with it!". 

The connection has access to the proper remoting connection instance, why does it need to receive as an argument of the call?

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

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


From do-not-reply at jboss.com  Mon Jan  8 21:47:17 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Mon, 8 Jan 2007 21:47:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover analysis
Message-ID: <21926541.1168310837962.JavaMail.jboss@colo-br-02.atl.jboss.com>

What's the use case for an re-entrant lock? If the valve is distributed among delegates, you probably don't need that, hence reduced complexity ...

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

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


From do-not-reply at jboss.com  Tue Jan  9 03:29:03 2007
From: do-not-reply at jboss.com (ben.wang@jboss.com)
Date: Tue, 9 Jan 2007 03:29:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: PojoCache uses a
	special node factory
Message-ID: <25672020.1168331343964.JavaMail.jboss@colo-br-02.atl.jboss.com>

This is interesting proposal, Brian. :-)

But I am still pondering will it really help. I have been grapling with this problem for a while now since I encountered this in the "stress" test env.

Basically, in release 2.0, since we move to the flat-space approach as all the real POJO attachment happens at "__JBossInternal__" node. E.g., we will store the real POJO under, say, "__JBossInterna__/e4xx99ssjswi" node.

This imposes the fqn "__JBossInternal__" as the bottleneck as whenever I need to map another POJO, I will need to obtain a WL on "__JBossInternal__" first. And note that WL is needed for both attach and detach (a la, remove) as well.

So question is what options that we have to improve the concurrency while maintaining the correctness? I am finding not a lot, other than using the Region concept to improve it somewhat.

Can a specialized Node for "__JBossInternal__" help? During the creation and removal of child node, actually I can forgo the interceptor chain and just rely on the Node ConcurrentHashMap to provide synchonization. But I will run into problem when I need to rollback either attach or detach operations (unless I still go thru the interceptor stack).

Any thought?


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

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


From do-not-reply at jboss.com  Tue Jan  9 03:54:52 2007
From: do-not-reply at jboss.com (timfox)
Date: Tue, 9 Jan 2007 03:54:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover analysis
Message-ID: <16641802.1168332892732.JavaMail.jboss@colo-br-02.atl.jboss.com>

"ovidiu.feodorov at jboss.com" wrote : Keeping a single centralized valve per connection gives a single point of bottleneck. All threads invoking into any delegate will have to acquire/release the synchronization element of that valve. This will lead to a lot of contention.
  | 
  | Distributing the load across different valve instances will relieve some of this pressure, with no apparent drawback.
  | 

I don't really agree with this. You would only get a lot of contention if the threads were all attempting to get the same write lock, but in the normal case they would be getting the read lock, and multiple read locks can obtained at any one time - this is kind of the whole point of read locks.

There may be a very small synchronized region in actually executing the call to get the read lock but this is probably insignificant.

If we can reduce the scope for deadlock and make the code simpler by using a single pair of locks I would prefer that solution.

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

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


From do-not-reply at jboss.com  Tue Jan  9 04:05:45 2007
From: do-not-reply at jboss.com (timfox)
Date: Tue, 9 Jan 2007 04:05:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Tests for JBoss MQ message counter functionality
Message-ID: <32784370.1168333545400.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have ported it anyway.

I have made a few changes along the way. There was one biggie where the counters are updated as every message arrives at a destination. *slow*.

I have changed this so instead the counter queries (samples) the queues every x milliseconds and updates itself appropriate - so it shouldn't be a bottleneck.

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

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


From do-not-reply at jboss.com  Tue Jan  9 04:09:14 2007
From: do-not-reply at jboss.com (timfox)
Date: Tue, 9 Jan 2007 04:09:14 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBossMQ delayed redelivery implementation
Message-ID: <4734253.1168333754534.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hmm, ok.

But even with transaction rollback, local tx rollback just causes session recovery anyway, so the same applies.

The only time the messages would get nacked back to the queue would be if the orginal local consumer that originally got the message had closed, otherwise it is just recovered directly to the local consumers.

anonymous wrote : 
  |    (JMS1.1 4.4.7). 
  |     * "If a transaction rollback is done, its produced messages are destroyed and its consumed
  |     * messages are automatically recovered. For more information on session recovery, see Section
  |     * 4.4.11 'Message Acknowledgment.'"
  | 



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

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


From do-not-reply at jboss.com  Tue Jan  9 04:10:36 2007
From: do-not-reply at jboss.com (timfox)
Date: Tue, 9 Jan 2007 04:10:36 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Expiring/DLQ same message from multiple subscriptions
Message-ID: <5831689.1168333836526.JavaMail.jboss@colo-br-02.atl.jboss.com>

That makes sense.

I suggest we do the same for JBM

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

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


From do-not-reply at jboss.com  Tue Jan  9 04:39:22 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Tue, 9 Jan 2007 04:39:22 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover analysis
Message-ID: <26606156.1168335562746.JavaMail.jboss@colo-br-02.atl.jboss.com>

OK. 

One pair of locks shared by all delegates belonging to one connection.

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

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


From do-not-reply at jboss.com  Tue Jan  9 05:14:08 2007
From: do-not-reply at jboss.com (alesj)
Date: Tue, 9 Jan 2007 05:14:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - DeclaredStructure
	ThreadLocal field
Message-ID: <23245170.1168337648056.JavaMail.jboss@colo-br-02.atl.jboss.com>

What's the usage of activeMetaData field in DeclaredStructure class (part of structured deployers)?

It is private and never unset.

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

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


From do-not-reply at jboss.com  Tue Jan  9 06:54:49 2007
From: do-not-reply at jboss.com (dimitris@jboss.org)
Date: Tue, 9 Jan 2007 06:54:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Strategy for supporting NonSerializable data
Message-ID: <25865847.1168343689307.JavaMail.jboss@colo-br-02.atl.jboss.com>

With the switch to JDK5, accessing remotely the MBeanServer over the legacy JMXAdaptor and getting back MBeanInfo is problematic, due to non-serializable objects stored in the MBeanInfo Descriptors.

We could deal with this under jdk1.4 by controling the javax.management.modelmbean.DescriptorSupport, but not when using jdk5.

A possible short-term solution is to create an interceptor that filters out non-serializable stuff:
http://jira.jboss.com/jira/browse/JBAS-1955

Is there any other strategy or plan dealing with this problem, by the Remoting and Serialization projects?

I see org.jboss.invocation.MarshalledInvocation can delegate to Cleberts plugable Serialization - could this be used?

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

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


From do-not-reply at jboss.com  Tue Jan  9 08:05:05 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 9 Jan 2007 08:05:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: one central search
	page
Message-ID: <28065869.1168347905588.JavaMail.jboss@colo-br-02.atl.jboss.com>

can i conclude that there is concensus to have 2 separate search pages: one for task instances and one for process instances ?

open questions:
* will both of these have a menu item ?
* will there be a process definition search as well ?
* if not, what will be the way to start a new process instance of a process definition ?

Maybe we should have following menu items: 'Tasks', 'Processes' (process definitions) and 'Executions' (process instances) 

Just a suggestion:

Tasks: shows the user task list by default.  I would put the search criteria form below the user task list.  By default, the current actor criteria field is set to the authenticated user...

Processes: shows the list of processes.  By default the list will filter out all processes that are not the highest version for a given process name.   Also here below the list, we could have the search criteria that can be refined by the user.

Executions: shows the process instances sorted by start date descending by default.  Also here i would put the dearch criteria form below the actual list.

On performance: I would not be bothered by performance now.  The architecture is build for scalability.  Fixing issues will be dealt with later.  Functionality, navigation and ease of use are more important for now.

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

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


From do-not-reply at jboss.com  Tue Jan  9 08:07:51 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 9 Jan 2007 08:07:51 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <16681591.1168348071788.JavaMail.jboss@colo-br-02.atl.jboss.com>

"david.lloyd at jboss.com" wrote : "tom.baeyens at jboss.com" wrote : Processes : Should display a list of processes similar to the current Find Processes menu screen.  By default, this screen shows only the latest versions of the processes in alphabetical order.
  | 
  | For the new prototype, there should be two tables for Processes.  One table should have a row for each unique process name, and it should contain any information that is shared between all versions of a process (even if it is just the name).  The other will be a child table of the main Process table and should contain per-version information.  The main process table should have link to the Process Version table representing the current "active" version.  This way, the latest version of a process can be found without having to using grouping SQL operations, and also the user can easily revert to an earlier version of a process if they need to by changing a simple link.
  | 
  | This normalization will greatly simplify the querying of process information.

Wouldn't this be nicer solved by a checkbox in the search criteria "Show all versions" which by default is unchecked ?

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

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


From do-not-reply at jboss.com  Tue Jan  9 08:11:25 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 9 Jan 2007 08:11:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <31316199.1168348285820.JavaMail.jboss@colo-br-02.atl.jboss.com>

"david.lloyd at jboss.com" wrote : "bazoo" wrote : Instead of "End Task", I would suggest "Proceed", to reinforce the idea that the user is moving through a process.
  | 
  | The "End Task" is not terminology that is defined by the web console.  The caption of each of the transition buttons is determined by the name of the corresponding transition.  In this case, the "websale" example process happens to have transitions named "End Task".
  | 

if there are multiple leaving transitions, the transition names should be shown.  but the web app also must have a default name in case there is 1 single anonymous transition.  From the proposals that i have seen so far, i like 'Complete' or 'Finish' the most

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

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


From do-not-reply at jboss.com  Tue Jan  9 08:17:44 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Tue, 9 Jan 2007 08:17:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <30424269.1168348664026.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : Wouldn't this be nicer solved by a checkbox in the search criteria "Show all versions" which by default is unchecked ?

The problem isn't the UI.  We can do a checkbox, that's no problem.  The problem is that the query cannot be made efficient, because it is not possible to know the latest version of a process without reading all rows of the process definition table with that process' name.  That's why I recommend that the tables be normalized, with one table for Processes and one for ProcessVersions.

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

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


From do-not-reply at jboss.com  Tue Jan  9 08:19:53 2007
From: do-not-reply at jboss.com (bazoo)
Date: Tue, 9 Jan 2007 08:19:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: one central search
	page
Message-ID: <23728209.1168348793917.JavaMail.jboss@colo-br-02.atl.jboss.com>

Sounds good to me. One small point - personally I would prefer the menu item to be entitled "Instances" rather than "Executions". The word is slightly less technical and therefore more instantly understandable to the end user.

Regarding the two separate search pages. To keep navigation simple, how about having one menu item "Search" then two tabs, one "Tasks" another "Processes"?

Regarding starting a new process. To me that is an important operation, and deserves its own place in the main menu structure. Perhaps you would click the "Start process" menu item, which would result in a page listing all the process definitions available to be started. The user would then click a button "Start" next to the one they want. Just an idea.

Cheers

Matt

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

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


From do-not-reply at jboss.com  Tue Jan  9 08:31:55 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 9 Jan 2007 08:31:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: direct navigation
	when starting a new process instance
Message-ID: <26304029.1168349515979.JavaMail.jboss@colo-br-02.atl.jboss.com>

yes.  i agree with ronald.  

if there is one or more tasks created assigned to the authenticated user, select an arbitrary one from that list and navigate to that task form.  otherwise, navigate to the task list home page.

i don't think it's necessary to do anything specific for pooled actors.  cause after starting a process instance and if there is no task assigned to the authenticated user, the user should navigate to the task list home page.  If there are group tasks, he/she'll see them instantly in the group task list (which i think should be on that same page) and the user can instantly perform the 'take' operation on that task.

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

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


From do-not-reply at jboss.com  Tue Jan  9 08:32:46 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Tue, 9 Jan 2007 08:32:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: one central search
	page
Message-ID: <3420418.1168349566953.JavaMail.jboss@colo-br-02.atl.jboss.com>

Sounds OK... are you sure you want to use "Executions" though?

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

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


From do-not-reply at jboss.com  Tue Jan  9 08:37:12 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 9 Jan 2007 08:37:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: simplified process
	instance view
Message-ID: <4163768.1168349832497.JavaMail.jboss@colo-br-02.atl.jboss.com>

I intended that for tasks, variables, tokens, there would only be one line of information.  Optionally with a link to a more detailed information page.

So as far as i can see we are all in agreement here.

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

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


From do-not-reply at jboss.com  Tue Jan  9 08:51:42 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Tue, 9 Jan 2007 08:51:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: direct navigation
	when starting a new process instance
Message-ID: <31866644.1168350702084.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : if there is one or more tasks created assigned to the authenticated user, select an arbitrary one from that list and navigate to that task form.  otherwise, navigate to the task list home page.

People aren't going to like that, I'm sure.  The rule should at least be predictable so that process designers (the people) can have some idea of what will happen.  If you're dead-set against a created task list like we have now, what about just always choosing the first task.  That will at least be predictable.

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

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


From do-not-reply at jboss.com  Tue Jan  9 09:28:13 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 9 Jan 2007 09:28:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: user based process
	versioning ?
Message-ID: <25293080.1168352893783.JavaMail.jboss@colo-br-02.atl.jboss.com>

we shouldn't rely on enterprise java. 

the more i think about it, the more i'm convinced that we cannot put the users in charge of versioning.

so if we want an auto-deploy directory, full copies of the process archive files will have to be stored for comparison upon next directory scan.  This full copy could potentially be stored on the filesystem or in the database.  that doesn't really matter.  but since jbpm already depends on a db in most deployments, this would be the first thing i implement. 

david, i don't yet see the point of having a table separation for process definition versions and process definitions.    now there is only a process definition version table and the name and version are columns. 



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

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


From do-not-reply at jboss.com  Tue Jan  9 09:49:26 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Tue, 9 Jan 2007 09:49:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: PojoCache uses a
	special node factory
Message-ID: <16624411.1168354166133.JavaMail.jboss@colo-br-02.atl.jboss.com>

Just a thought, a hash bucket approach (that I suggested to Hibernate some while back) to reduce contention on a parent node may help here as well.  This may be encapsulated into an 'InternalNode' or wired manually in PojoCache code (for now, maybe).

The basic idea is that when you need to create 
/_JBossInternal_/Node1
/_JBossInternal_/Node2
/_JBossInternal_/Node10
/_JBossInternal_/Node11

you actually create:

/_JBossInternal_/Bucket0-9/Node1
/_JBossInternal_/Bucket0-9/Node2
/_JBossInternal_/Bucket10-19/Node10
/_JBossInternal_/Bucket10-19/Node11

which will reduce the contention on _JBossInternal_ as a direct parent.  Perhaps this is behaviour we could add (in the 3.0 timeframe?) to JBoss Cache's core Node impls, so all user data gets to benefit from this as well?

Cheers,
Manik


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

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


From do-not-reply at jboss.com  Tue Jan  9 09:50:32 2007
From: do-not-reply at jboss.com (longfangq@hotmail.com)
Date: Tue, 9 Jan 2007 09:50:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Redelivery caused by System.exit()? urgent!!!!
Message-ID: <5780795.1168354232703.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi,

When our program receives a JMS message which instructs it to shut down, it calls System.exit(0). It works well with another application server. When we try to migrate to JBoss, we found that JMS message will not be consumed, which means the program does receive the message and exit but when it restarts, that JMS message will be redelievered and cause it to exit again and therefor an infinite loop. 

We use non-transactional messaging and auto acknolowledge:
        QueueSession qSession = qCon.createQueueSession(false,
            Session.AUTO_ACKNOWLEDGE);

Can anyone kindly help? many thanks!


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

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


From do-not-reply at jboss.com  Tue Jan  9 09:59:38 2007
From: do-not-reply at jboss.com (timfox)
Date: Tue, 9 Jan 2007 09:59:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Redelivery caused by System.exit()? urgent!!!!
Message-ID: <8959809.1168354778798.JavaMail.jboss@colo-br-02.atl.jboss.com>

You are in the wrong forum.

Please post in the messaging user forum (I already had to move your last message).

This is a forum for design discussions

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

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


From do-not-reply at jboss.com  Tue Jan  9 10:02:31 2007
From: do-not-reply at jboss.com (timfox)
Date: Tue, 9 Jan 2007 10:02:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Redelivery caused by System.exit()? urgent!!!!
Message-ID: <18304361.1168354951170.JavaMail.jboss@colo-br-02.atl.jboss.com>

longfangq-

A word of advice:

If you want someone to look at your issue, then a) posting in the wrong forum b) posting multiple times and c) "urgent!!!!" is not the best way to go about it.

Heed my words, there are much grumpier people than me lurking around ;)

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

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


From do-not-reply at jboss.com  Tue Jan  9 10:21:39 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Tue, 9 Jan 2007 10:21:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: user based process
	versioning ?
Message-ID: <25611095.1168356099186.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : david, i don't yet see the point of having a table separation for process definition versions and process definitions.    now there is only a process definition version table and the name and version are columns. 

Yes, which means that in order to determine the latest version of a process, the generated SQL must select all rows for a process to know what the latest version is.

If we have a separate version table, then only one row from each table need be selected to determine the latest version.  This is just one benefit of having normalized database tables.  All the tables in jBPM should be normalized unless there is a very good reason not to (which there usually isn't).

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

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


From do-not-reply at jboss.com  Tue Jan  9 10:22:31 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Tue, 9 Jan 2007 10:22:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Bug in transactional delivery in an MDB
Message-ID: <14456933.1168356151893.JavaMail.jboss@colo-br-02.atl.jboss.com>

In the latest version of the adapter (HEAD), the non-transactional context is handled by the JCA adapter using Local JMS transactions which was added to support the case where a Bean managed or CMT Not Supported MDB throws a Runtime Exception. Here the JMS and EJB specs differ as to how this should be treated. We had a long thread about this awhile ago when we were trying to address issues with the JBoss beta we were trying to get out the door. 

Unfortunately, for this case (and many others) there is no 'correct' behavior as the spec is silent in this regard. 

Note the behavior in HEAD is a complete rewrite from the way we originally handled this. 

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

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


From do-not-reply at jboss.com  Tue Jan  9 10:29:51 2007
From: do-not-reply at jboss.com (timfox)
Date: Tue, 9 Jan 2007 10:29:51 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Bug in transactional delivery in an MDB
Message-ID: <31512405.1168356591013.JavaMail.jboss@colo-br-02.atl.jboss.com>

"weston.price at jboss.com" wrote : In the latest version of the adapter (HEAD), the non-transactional context is handled by the JCA adapter using Local JMS transactions  

Ok good, this is what I would expect, and is consistent with how transactional message delivery with MDBs works (convertion of work done outside the global tx into work done inside the global tx).

This means the behaviour expected in http://jira.jboss.com/jira/browse/JBMESSAGING-410 is not going to happen in HEAD anyway.

So I think we are safe to revert the changes in JBMESSAGING-410 and I can get the patch out ASAP.

Everyone agreed?

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

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


From do-not-reply at jboss.com  Tue Jan  9 10:32:30 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Tue, 9 Jan 2007 10:32:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Plan to improve CMS
	integration
Message-ID: <25400821.1168356750802.JavaMail.jboss@colo-br-02.atl.jboss.com>

In order to improve the CMS integration on the following points :

1/ more decouple the CMS from the portal
2/ improve the integration of content into portal pages

We should handle content at the portal object level. Today a portal window is implicitely a window that points to a portlet.

It is possible to make the Window agnostic of portlets and introduce to sub interfaces PortletWindow and ContentWindow.

PortletWindow would contain the String reference to the portlet instance and ContentWindow would contain an URI that would point to the CMS content.

This way admins would not have to configure the CMS portlet that points to the appropriate content.

I would like to perform that change for the beta release.

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

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


From do-not-reply at jboss.com  Tue Jan  9 10:42:35 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Tue, 9 Jan 2007 10:42:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: one central search
	page
Message-ID: <22821660.1168357355585.JavaMail.jboss@colo-br-02.atl.jboss.com>

I prefer ProcessInstances over Executions. Not only more understandable to the user, but consistent with the jBPM object model / API.

In general I would try not to re-invent terms if jBPM already has a good term for something. ProcessDefinitions and ProcessInstances are not only jBPM terms, but are pretty much "industry standard" (as much as there are standards in the BPM market).

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

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


From do-not-reply at jboss.com  Tue Jan  9 10:44:43 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 9 Jan 2007 10:44:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: free choice of
	initial node
Message-ID: <14687774.1168357483064.JavaMail.jboss@colo-br-02.atl.jboss.com>

http://jira.jboss.com/jira/browse/JBPM-820

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

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


From do-not-reply at jboss.com  Tue Jan  9 10:48:01 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 9 Jan 2007 10:48:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: replace separate
	managers task list view with generic se
Message-ID: <25933079.1168357681476.JavaMail.jboss@colo-br-02.atl.jboss.com>

i would leave fine grained authorization out of the current 3.2 release and postpone it to one of the later releases. 

this requires special care as that might make it much harder to rip out the default jbpm identity component.  great care has to be taken with the defaults so that the authorization is natural, but not fine grained if you replace or remove your identity component.

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

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


From do-not-reply at jboss.com  Tue Jan  9 10:52:03 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 9 Jan 2007 10:52:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <5097297.1168357923269.JavaMail.jboss@colo-br-02.atl.jboss.com>

changing the db schema to split the jbpm_processdefinition table in 2 is too complicated, i think.

but we could add a column ISLATEST_ to the process definition table that we maintain manually during deployment.

is that a good idea ?

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

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


From do-not-reply at jboss.com  Tue Jan  9 10:53:03 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Tue, 9 Jan 2007 10:53:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <32498978.1168357983440.JavaMail.jboss@colo-br-02.atl.jboss.com>

Another objective is to allow to split the core module into several sub modules (base services / UI / CMS integration) in order to increase the flexibility and ease the development made on that module.

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

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


From do-not-reply at jboss.com  Tue Jan  9 10:56:32 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 9 Jan 2007 10:56:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: one central search
	page
Message-ID: <6931006.1168358192556.JavaMail.jboss@colo-br-02.atl.jboss.com>

"david.lloyd at jboss.com" wrote : Sounds OK... are you sure you want to use "Executions" though?

no.  i'm not sure :-)

take whatever you think is best from all the suggestions in these threads.

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

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


From do-not-reply at jboss.com  Tue Jan  9 10:58:29 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 9 Jan 2007 10:58:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: direct navigation
	when starting a new process instance
Message-ID: <1750257.1168358309165.JavaMail.jboss@colo-br-02.atl.jboss.com>

always choosing the first task is definitely good for me.

as long as we try to minimize the user navigation by autonavigating the user to the page that the user is most likely to visit after a command operation.

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

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


From do-not-reply at jboss.com  Tue Jan  9 11:02:27 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 9 Jan 2007 11:02:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: one central search
	page
Message-ID: <4105536.1168358547222.JavaMail.jboss@colo-br-02.atl.jboss.com>

forgot to add:  jeff also makes good sense:

"jeff" wrote : In general I would try not to re-invent terms if jBPM already has a good term for something. ProcessDefinitions and ProcessInstances are not only jBPM terms, but are pretty much "industry standard" (as much as there are standards in the BPM market).

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

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


From do-not-reply at jboss.com  Tue Jan  9 11:03:24 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Tue, 9 Jan 2007 11:03:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Bug in transactional delivery in an MDB
Message-ID: <28533011.1168358604266.JavaMail.jboss@colo-br-02.atl.jboss.com>

Lock and load.

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

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


From do-not-reply at jboss.com  Tue Jan  9 11:04:28 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Tue, 9 Jan 2007 11:04:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <11760643.1168358668582.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : changing the db schema to split the jbpm_processdefinition table in 2 is too complicated, i think.
  | 
  | but we could add a column ISLATEST_ to the process definition table that we maintain manually during deployment.
  | 
  | is that a good idea ?

Yes that would work around the problem for now.  When I speak of changing the DB schema to split the tables, I'm suggesting that as something to do in 4.x.

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

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


From do-not-reply at jboss.com  Tue Jan  9 11:04:42 2007
From: do-not-reply at jboss.com (thomas.heute@jboss.com)
Date: Tue, 9 Jan 2007 11:04:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <12380880.1168358682990.JavaMail.jboss@colo-br-02.atl.jboss.com>

+1
Let's kill the portlet requirement for windows since it's not always really necessary.

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

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


From do-not-reply at jboss.com  Tue Jan  9 11:10:31 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Tue, 9 Jan 2007 11:10:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Bug in transactional delivery in an MDB
Message-ID: <7605526.1168359031946.JavaMail.jboss@colo-br-02.atl.jboss.com>

Thinking about it, wouldn't be more logical the other way around: load and lock? 

Now, it what transactional behavior is concerned, would you guys please hold any major reverting decision for just a little bit, until I get to the problem (today or tomorrow)?



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

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


From do-not-reply at jboss.com  Tue Jan  9 13:18:55 2007
From: do-not-reply at jboss.com (timfox)
Date: Tue, 9 Jan 2007 13:18:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Scheduled delivery and redelivery delay
Message-ID: <6480509.1168366735234.JavaMail.jboss@colo-br-02.atl.jboss.com>

Scheduled delivery and redelivery delay are now implemented in TRUNK.

Scheduled delivery:

Before sending a message you can set a JBoss specific property - this is the same property name used by JBoss MQ:


  | message.setLongProperty("JMS_JBOSS_SCHEDULED_DELIVERY", System.currentTimeMillis() + 30000);
  | 

Then after the message has successfully reached the queue, delivery will not occur until the specified future time. This could be milliseconds, seconds or months
in the future. If the message is persistent and the message is in a jms queue or durable subscription, then the scheduled delivery will survive a restart.

Clearly scheduled message deliveries do not respect normal message orderings in queues.


Delayed redelivery:

Often it is useful to introduce a delay before redelivery of a message. E.g. if a consumer fails often it may not be desirable to have a message redelivered in quick
succession due to the extra network traffic that might give.

A redelivery delay can be specified for the server which would apply to all destinations. Specific delays can also be specified on a per destination basis which
overrides any value specified at the server level.

Internally, both scheduled delivery and redelivery delay use the same mechanism to delay deliveries.



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

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


From do-not-reply at jboss.com  Tue Jan  9 13:19:34 2007
From: do-not-reply at jboss.com (timfox)
Date: Tue, 9 Jan 2007 13:19:34 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- MessageCounter and message counter history functionality
Message-ID: <860191.1168366774257.JavaMail.jboss@colo-br-02.atl.jboss.com>

Now implemented in TRUNK.

This is pretty much a port of the funtionality from JBossMQ with a few improvements, e.g. the counter now samples the queues at intervals to avoid
a bottleneck which would occur if they were updated every time a message was added

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

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


From do-not-reply at jboss.com  Tue Jan  9 13:20:39 2007
From: do-not-reply at jboss.com (timfox)
Date: Tue, 9 Jan 2007 13:20:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Full JMX functionality
Message-ID: <3816483.1168366839685.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have fleshed out the ServerPeer, Queue and Topic MBean interfaces so now we have complete equivalent JMX functionality to JBossMQ.

I also sorted out the mess that was the Queue/Topic mbean interface

There's basically a whole stack of new stuff in here:


  | public interface ServerPeerMBean
  | {
  |    // JMX attributes
  |    
  |    int getServerPeerID();
  |    
  |    String getJMSVersion();
  | 
  |    int getJMSMajorVersion();
  | 
  |    int getJMSMinorVersion();
  | 
  |    String getJMSProviderName();
  | 
  |    String getProviderVersion();
  | 
  |    int getProviderMajorVersion();
  | 
  |    int getProviderMinorVersion();
  | 
  |    String getDefaultQueueJNDIContext();
  | 
  |    String getDefaultTopicJNDIContext();
  |    
  |    void setSecurityDomain(String securityDomain) throws Exception;
  | 
  |    String getSecurityDomain();
  | 
  |    void setDefaultSecurityConfig(Element conf) throws Exception;
  | 
  |    Element getDefaultSecurityConfig();
  |    
  |    ObjectName getPersistenceManager();
  | 
  |    void setPersistenceManager(ObjectName on);
  | 
  |    ObjectName getPostOffice();
  | 
  |    void setPostOffice(ObjectName on);
  | 
  |    ObjectName getJmsUserManager();
  | 
  |    void setJMSUserManager(ObjectName on);
  |    
  |    ObjectName getDefaultDLQ();
  | 
  |    void setDefaultDLQ(ObjectName on);
  |    
  |    ObjectName getDefaultExpiryQueue();
  | 
  |    void setDefaultExpiryQueue(ObjectName on);
  |       
  |           
  |    int getQueuedExecutorPoolSize();
  | 
  |    void setQueuedExecutorPoolSize(int poolSize);
  |    
  |    long getFailoverStartTimeout();
  |    
  |    void setFailoverStartTimeout(long timeout);
  |    
  |    long getFailoverCompleteTimeout();
  |    
  |    void setFailoverCompleteTimeout(long timeout);
  |    
  |    int getDefaultMaxDeliveryAttempts();
  | 
  |    void setDefaultMaxDeliveryAttempts(int attempts);   
  |    
  |    long getQueueStatsSamplePeriod();
  | 
  |    void setQueueStatsSamplePeriod(long newPeriod);
  |    
  |    long getDefaultRedeliveryDelay();
  |    
  |    void setDefaultRedeliveryDelay(long delay);
  |    
  |    int getDefaultMessageCounterHistoryDayLimit();
  |    
  |    void setDefaultMessageCounterHistoryDayLimit(int limit);
  |    
  |    // JMX operations
  |    
  |    String createQueue(String name, String jndiName) throws Exception;
  | 
  |    String createQueue(String name, String jndiName, int fullSize, int pageSize, int downCacheSize) throws Exception;
  | 
  |    boolean destroyQueue(String name) throws Exception;
  | 
  |    String createTopic(String name, String jndiName) throws Exception;
  | 
  |    String createTopic(String name, String jndiName, int fullSize, int pageSize, int downCacheSize) throws Exception;  
  | 
  |    boolean destroyTopic(String name) throws Exception;
  | 
  |    Set getDestinations() throws Exception;
  |    
  |    List getMessageCounters() throws Exception;
  | 
  |    List getMessageStatistics() throws Exception;
  | 
  |    String listMessageCountersAsHTML() throws Exception;
  |    
  |    void resetAllMessageCounters();
  |    
  |    void resetAllMessageCounterHistories();
  |    
  |    List retrievePreparedTransactions();
  | 
  |    String showPreparedTransactionsAsHTML();
  | }
  | 
  | public interface DestinationMBean
  | {
  |    // JMX attributes
  |    
  |    String getName();
  | 
  |    String getJNDIName();
  | 
  |    void setJNDIName(String jndiName) throws Exception;
  | 
  |    ObjectName getServerPeer();
  |       
  |    void setServerPeer(ObjectName on);
  | 
  |    ObjectName getDLQ();
  |    
  |    void setDLQ(ObjectName on) throws Exception;
  |      
  |    ObjectName getExpiryQueue();   
  |    
  |    void setExpiryQueue(ObjectName on) throws Exception;
  |    
  |    long getRedeliveryDelay();
  |    
  |    void setRedeliveryDelay(long delay);
  |    
  |    int getMaxSize();
  |    
  |    void setMaxSize(int maxSize) throws Exception;
  |    
  |    Element getSecurityConfig();
  |    
  |    void setSecurityConfig(Element securityConfig) throws Exception;
  | 
  |    int getFullSize();
  | 
  |    void setFullSize(int fullSize);
  | 
  |    int getPageSize();
  | 
  |    void setPageSize(int pageSize);
  | 
  |    int getDownCacheSize();
  | 
  |    void setDownCacheSize(int downCacheSize);
  |    
  |    boolean isClustered();
  |    
  |    void setClustered(boolean clustered);
  |    
  |    boolean isCreatedProgrammatically();
  |    
  |    int getMessageCounterHistoryDayLimit();
  |    
  |    void setMessageCounterHistoryDayLimit(int limit) throws Exception;
  |    
  |    // JMX operations
  |    
  |    void removeAllMessages() throws Exception;
  |    
  | }
  | 
  | ublic interface QueueMBean
  | {
  |    // JMX attributes
  |    
  |    int getMessageCount() throws Exception;
  |    
  |    int getScheduledMessageCount() throws Exception;
  |                
  |    MessageCounter getMessageCounter();
  |    
  |    MessageStatistics getMessageStatistics() throws Exception;
  |    
  |    int getConsumerCount() throws Exception;
  |    
  |    // JMX operations
  |    
  |    void resetMessageCounter();
  |    
  |    void resetMessageCounterHistory();
  |       
  |    List listAllMessages() throws Exception;
  |    
  |    List listAllMessages(String selector) throws Exception;
  |    
  |    List listDurableMessages() throws Exception;
  |    
  |    List listDurableMessages(String selector) throws Exception;
  |    
  |    List listNonDurableMessages() throws Exception;
  |    
  |    List listNonDurableMessages(String selector) throws Exception;
  |    
  |    String getMessageCounterAsHTML();
  |    
  |    String getMessageCounterHistoryAsHTML();
  | }
  | 
  | public interface TopicMBean
  | {
  |    //JMX attributes
  |     
  |    int getAllMessageCount() throws Exception;
  |       
  |    int getDurableMessageCount() throws Exception;
  |       
  |    int getNonDurableMessageCount() throws Exception;
  |    
  |    int getAllSubscriptionsCount() throws Exception;
  | 
  |    int getDurableSubscriptionsCount() throws Exception;
  |    
  |    int getNonDurableSubscriptionsCount() throws Exception;
  |    
  |    // JMX operations
  |    
  |    void removeAllMessages() throws Exception;
  |       
  |    List listAllSubscriptions() throws Exception;
  |    
  |    List listDurableSubscriptions() throws Exception;
  |    
  |    List listNonDurableSubscriptions() throws Exception;
  |    
  |    String listAllSubscriptionsAsHTML() throws Exception;
  |    
  |    String listDurableSubscriptionsAsHTML() throws Exception;
  |    
  |    String listNonDurableSubscriptionsAsHTML() throws Exception;
  |    
  |    List listAllMessages(String subscriptionId) throws Exception;
  |    
  |    List listAllMessages(String subscriptionId, String selector) throws Exception;
  |    
  |    List listDurableMessages(String subscriptionId) throws Exception;
  |    
  |    List listDurableMessages(String subscriptionId, String selector) throws Exception;
  |    
  |    List listNonDurableMessages(String subscriptionId) throws Exception;
  |    
  |    List listNonDurableMessages(String subscriptionId, String selector) throws Exception;
  |    
  |    List getMessageCounters() throws Exception;      
  | }
  | 
  | 


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

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


From do-not-reply at jboss.com  Tue Jan  9 13:21:27 2007
From: do-not-reply at jboss.com (timfox)
Date: Tue, 9 Jan 2007 13:21:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Expiring/DLQ same message from multiple subscriptions
Message-ID: <25760874.1168366887913.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, this is done, tested and committed in TRUNK.

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

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


From do-not-reply at jboss.com  Tue Jan  9 13:47:26 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 9 Jan 2007 13:47:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: DeclaredStructure
	ThreadLocal field
Message-ID: <4104313.1168368446308.JavaMail.jboss@colo-br-02.atl.jboss.com>

Its an obsolete leftover from a previous version. It should be removed.

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

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


From do-not-reply at jboss.com  Tue Jan  9 14:31:13 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 9 Jan 2007 14:31:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Re: Strategy for supporting NonSerializable data
Message-ID: <12000185.1168371073909.JavaMail.jboss@colo-br-02.atl.jboss.com>

A custom jsr160 connector that allows for control of serialization of types that are not Serializable is the proper solution. The default implementation could use the jboss serialization capabilities.

The 1955 short term solution seems like the best immeadiate approach.


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

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


From do-not-reply at jboss.com  Tue Jan  9 14:39:18 2007
From: do-not-reply at jboss.com (kbarfield)
Date: Tue, 9 Jan 2007 14:39:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Change user names in
	console
Message-ID: <15865307.1168371558839.JavaMail.jboss@colo-br-02.atl.jboss.com>

This topic is part of the web console feedback: 

http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback

The user names should be changed to be more business-related.  Examples:  Joe User, Scott Shipper, Bill Buyer, etc.[/url]

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

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


From do-not-reply at jboss.com  Tue Jan  9 14:44:41 2007
From: do-not-reply at jboss.com (kbarfield)
Date: Tue, 9 Jan 2007 14:44:41 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Simplified end user
	functionality
Message-ID: <26267066.1168371881319.JavaMail.jboss@colo-br-02.atl.jboss.com>

This topic is part of the web console feedback: http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback

As mentioned in other threads, the end user functionality needs to be simplified.  End users should be able to work tasks with the fewest clicks possible and with only the information they need to see on the page.  Remove all menu functionality that end users don't have access to.  Remove source code tabs (end users don't need to see source code).  Remove or rename fields that end users don't need to see Examples: ID, Instance ID, PooledActors, Task Priority.  Task list should go straight to the form, and submitting the form should go back to the task list.

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

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


From do-not-reply at jboss.com  Tue Jan  9 14:46:03 2007
From: do-not-reply at jboss.com (kbarfield)
Date: Tue, 9 Jan 2007 14:46:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Remove menu options for
	functionality that is not built yet
Message-ID: <18587159.1168371963117.JavaMail.jboss@colo-br-02.atl.jboss.com>

This topic is part of the web console feedback:  http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback


If a menu option is not built out yet, remove it (unless it will be there by 3.2 GA)

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

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


From do-not-reply at jboss.com  Tue Jan  9 14:46:57 2007
From: do-not-reply at jboss.com (kbarfield)
Date: Tue, 9 Jan 2007 14:46:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Move search filter
Message-ID: <6210965.1168372017288.JavaMail.jboss@colo-br-02.atl.jboss.com>

This topic is part of the web console feedback: http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback 

The search filter is currently confusing.  Move it away from the list and mention that it is a filter

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

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


From do-not-reply at jboss.com  Tue Jan  9 14:55:27 2007
From: do-not-reply at jboss.com (kbarfield)
Date: Tue, 9 Jan 2007 14:55:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Suspended instances?
Message-ID: <21452973.1168372527437.JavaMail.jboss@colo-br-02.atl.jboss.com>

This topic is part of the web console feedback: http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback

What are suspended instances?  How do you suspend or un-suspend?



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

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


From do-not-reply at jboss.com  Tue Jan  9 14:56:29 2007
From: do-not-reply at jboss.com (kbarfield)
Date: Tue, 9 Jan 2007 14:56:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Return to process
	instance after change
Message-ID: <6499322.1168372589837.JavaMail.jboss@colo-br-02.atl.jboss.com>

This topic is part of the web console feedback: http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback 

I moved a token, and did not return to the process instance I was dealing with.  The process instance tabs should return after I make a change.

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

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


From do-not-reply at jboss.com  Tue Jan  9 14:57:02 2007
From: do-not-reply at jboss.com (admin)
Date: Tue, 9 Jan 2007 14:57:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Change user names
	in console
Message-ID: <4825796.1168372622998.JavaMail.jboss@colo-br-02.atl.jboss.com>

+1

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

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


From do-not-reply at jboss.com  Tue Jan  9 14:58:04 2007
From: do-not-reply at jboss.com (kbarfield)
Date: Tue, 9 Jan 2007 14:58:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Modify process variables
Message-ID: <32709514.1168372684170.JavaMail.jboss@colo-br-02.atl.jboss.com>

This topic is part of the web console feedback: http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback 


There doesn't appear to be any way to update process variables.  This was in the previous version of the console and needs to be here.

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

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


From do-not-reply at jboss.com  Tue Jan  9 14:58:51 2007
From: do-not-reply at jboss.com (kbarfield)
Date: Tue, 9 Jan 2007 14:58:51 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - View timers in console
Message-ID: <228125.1168372731952.JavaMail.jboss@colo-br-02.atl.jboss.com>

This topic is part of the web console feedback: http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback 

Can we view active timers with due dates either associated to an process instance or in general

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

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


From do-not-reply at jboss.com  Tue Jan  9 14:59:12 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 9 Jan 2007 14:59:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Serialization] - Cleanup of
	project, move to maven, svn?
Message-ID: <21417560.1168372752837.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm looking at supporting pluggable serizliation of the server deployment metadata and want to be able to use jboss serialization as well as a new xml output stream format of jboss serialization. Looking at the jboss-serialiation project in cvs, its not in good shape in terms of having local dependencies on other jboss projects.

I would say this needs to be moved into svn and refactored to use maven and better isolate the dependencies. Unless there are objections I would start doing this at the end of this week.


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

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


From do-not-reply at jboss.com  Tue Jan  9 14:59:45 2007
From: do-not-reply at jboss.com (kbarfield)
Date: Tue, 9 Jan 2007 14:59:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Add/Modify/List users
	in console
Message-ID: <27100268.1168372785836.JavaMail.jboss@colo-br-02.atl.jboss.com>

This topic is part of the web console feedback: http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback 

Add functionality to list users, add users, and modify users.


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

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


From do-not-reply at jboss.com  Tue Jan  9 15:03:15 2007
From: do-not-reply at jboss.com (admin)
Date: Tue, 9 Jan 2007 15:03:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Simplified end user
	functionality
Message-ID: <18009706.1168372995994.JavaMail.jboss@colo-br-02.atl.jboss.com>

let me try and list the points with which i agree

* minimize number of clicks needed for basic tasks such as starting a new process and performing a task.   navigation straight from the task list to the task form and back

* remove unnecessary fields like id's (i do think that priority is an end user field, though)

* the source code tabs should not be there in the real app.  but in the suite download, i would also like to target evaluation features.  so that is why i thought that based on a configuration property (david, let me know if you want me to add that) the web console could display source links.  This was especially insteresting in the SEAM example apps and i think it would be nice to have in the jbpm examples that ship in the suite download.

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

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


From do-not-reply at jboss.com  Tue Jan  9 15:04:41 2007
From: do-not-reply at jboss.com (admin)
Date: Tue, 9 Jan 2007 15:04:41 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Move search filter
Message-ID: <17700610.1168373081609.JavaMail.jboss@colo-br-02.atl.jboss.com>

i would always put the filters at the bottom, under the tables.

would that qualify as 'move it away' ?

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

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


From do-not-reply at jboss.com  Tue Jan  9 15:06:41 2007
From: do-not-reply at jboss.com (admin)
Date: Tue, 9 Jan 2007 15:06:41 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Suspended instances?
Message-ID: <32100833.1168373201135.JavaMail.jboss@colo-br-02.atl.jboss.com>

it means that any tasks for suspended process instances (or tokens) will not show up in the task lists.  also messages and timers will not fire on suspended process instances (or tokens).

there is only API level support for suspension and resuming of process instances or tokens

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

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


From do-not-reply at jboss.com  Tue Jan  9 15:09:36 2007
From: do-not-reply at jboss.com (admin)
Date: Tue, 9 Jan 2007 15:09:36 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Modify process
	variables
Message-ID: <24002847.1168373376994.JavaMail.jboss@colo-br-02.atl.jboss.com>

yes i think that is an important feature, but i don't want to block a 3.2 release because of this feature.  since it is not yet implemented, i suggest we focus on the features we have, fix and stabilize those and add this in one of the 3.2.x releases.

regards, tom.

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

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


From do-not-reply at jboss.com  Tue Jan  9 15:11:28 2007
From: do-not-reply at jboss.com (admin)
Date: Tue, 9 Jan 2007 15:11:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: View timers in
	console
Message-ID: <5305604.1168373488278.JavaMail.jboss@colo-br-02.atl.jboss.com>

+1.  again with the remark that this doesn't need to be in the 3.2 release.  it can wait till some subsequent 3.2.x release

regards, tom. (for some reason i seem to be auto-logged-in as admin and i don't know how to change this)

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

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


From do-not-reply at jboss.com  Tue Jan  9 15:12:12 2007
From: do-not-reply at jboss.com (krishna_mv)
Date: Tue, 9 Jan 2007 15:12:12 -0500 (EST)
Subject: [jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - How to
	configure Startup class in JBOSS4.x
Message-ID: <32837470.1168373532863.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi friends,

I have the following issue in JBoss 4.x.

I have a custom startup class which is supposed to run when we start the server. I have a message in the class which should print just before Started in 29s:750ms (This is the last line when u start the server).

I can handle this with Mbean and jboss-service.xml. But I have some dependency classes in my ear file which talks to this startup class. So, I had to put in EAR.

So, the issue is - is it possible to put the startup class in EAR and configure somewhere so that the server reads my custom class and prints the message when I just start the server.

(Note: If I configure the startup class name in jboss-service.xml by placing my class in EAR file, it does not work. Because, jboss-service.xml deploys first then the EAR file as soon as I start the server)

Thanks in advance.

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

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


From do-not-reply at jboss.com  Tue Jan  9 17:00:58 2007
From: do-not-reply at jboss.com (genman)
Date: Tue, 9 Jan 2007 17:00:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: PojoCache uses a
	special node factory
Message-ID: <30710538.1168380058592.JavaMail.jboss@colo-br-02.atl.jboss.com>

One thing that I took a look at was the GUID used for some Pojo node data. The GUID itself can be divided into  two parts. One is the machine/VM instance ID and the other is the per machine unique ID. Admittedly, this wouldn't help contention...

NodeFactory should probably come from the RegionManager.

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

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


From do-not-reply at jboss.com  Tue Jan  9 17:01:25 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Tue, 9 Jan 2007 17:01:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Channel creation - mux
	vs. old style
Message-ID: <732954.1168380085694.JavaMail.jboss@colo-br-02.atl.jboss.com>

I think we are trying too hard not to fail in startService() if there is an issue with the mux configuration.  

We do this:

1) If a JChannelFactory has been injected into the config, use it and propagate any exception.
2) If no JChannelFactory is injected, but there is a mux service ObjectName in the config, try to find a mux service in JMX and use it to create the channel.
3) If there is an error in #2, but there is an old-style channel config, use that to create the channel
4) If there is no old-style config, use the default properties to create the channel.

Three points:

1) #4 above is bogus.  If they configured for mux and didn't specify an old-style config, failure to find the mux service should lead to an exception, not to a fallback on some default.  The default properties should only be used if nothing else is configured. I'm going to change that.

2) Trying to find the channel in JMX is suspect, at least in JBoss AS where it can be dependency injected (even in 4.x).  Manik put a comment in CacheImpl about that.

3) If we decide to keep the JMX lookup, if it fails, should we log a warn and fall back to the old style config, as in step 3 above, or rather throw an exception? (This is an irrelevant issue if we get rid of the JMX lookup).

(NOTE: please don't get rid of the JMX lookup yet, as I still need it in the AS integration.  Want to get rid of the need for it, but haven't yet.)

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

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


From do-not-reply at jboss.com  Tue Jan  9 17:07:44 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Tue, 9 Jan 2007 17:07:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Channel creation -
	mux vs. old style
Message-ID: <8445150.1168380464928.JavaMail.jboss@colo-br-02.atl.jboss.com>

Worse than I thought.  Even if there is a exception in step 1 above, we catch the exception and try to create a channel from an old style config.  If the JChannelFactory has been injected into the config, that's a clear sign it's meant to be used, so any failure should propagate.

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

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


From do-not-reply at jboss.com  Tue Jan  9 17:15:29 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Tue, 9 Jan 2007 17:15:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Serialization] - Re: Cleanup of
	project, move to maven, svn?
Message-ID: <21913072.1168380929640.JavaMail.jboss@colo-br-02.atl.jboss.com>

I don't have any objections... I just didn't have time to do it before.

Ruel had created a Maven build for jboss-serialization when he was working on maven scripts. It should be in good shape but I haven't tested it recently.

.. talking about this new xml output stream... you are considering using jboss-serialization to serialize objects into XML format? Did I understand that correctly?

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

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


From do-not-reply at jboss.com  Tue Jan  9 17:25:05 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Tue, 9 Jan 2007 17:25:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Serialization] - Re:
	resolveClass and annotateClass
Message-ID: <32716085.1168381505121.JavaMail.jboss@colo-br-02.atl.jboss.com>

I will verify about the annotateClass calls.

Sorry about the delay answering this...  I got messed up with my mail box.. probably didn't see the notification.


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

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


From do-not-reply at jboss.com  Tue Jan  9 18:10:20 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Tue, 9 Jan 2007 18:10:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Change user names
	in console
Message-ID: <24665549.1168384220782.JavaMail.jboss@colo-br-02.atl.jboss.com>

+1

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

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


From do-not-reply at jboss.com  Tue Jan  9 18:12:01 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Tue, 9 Jan 2007 18:12:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Add/Modify/List
	users in console
Message-ID: <17407651.1168384321888.JavaMail.jboss@colo-br-02.atl.jboss.com>

this is already in a jira issue

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

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


From do-not-reply at jboss.com  Tue Jan  9 18:15:28 2007
From: do-not-reply at jboss.com (genman)
Date: Tue, 9 Jan 2007 18:15:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Last chance for any
	changes to the 2.0.0 API
Message-ID: <14927819.1168384528353.JavaMail.jboss@colo-br-02.atl.jboss.com>


A few last minute comments:

1. putIfNull -> putIfAbsent, See http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ConcurrentMap.html . People might get confused with "null" versus absent.

2. Remove the print* methods in NodeSPI. Or at least document them. Consider creating a separate util class to print a node.

3. removeChildDirect(Fqn) and removeChildDirect(Object) is a little confusing, since Fqn is a subtype of Object. I would probably suggest just having one or the other.

4. Some of the NodeSPI data methods appear to be just convenience methods and aren't strictly necessary given that getDataDirect() returns an externally modifiable map. For instance, clearDataDirect() really just is the same as NodeSPI.getDataDirect().clear(). So, it would be nice to understand the reason for these extra methods.

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

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


From do-not-reply at jboss.com  Tue Jan  9 18:16:45 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Tue, 9 Jan 2007 18:16:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Move search filter
Message-ID: <14996750.1168384605607.JavaMail.jboss@colo-br-02.atl.jboss.com>

I disagree (as stated before), but a hide/show button is prefered (would that qualify as move them away ;-))

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

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


From do-not-reply at jboss.com  Tue Jan  9 18:29:05 2007
From: do-not-reply at jboss.com (genman)
Date: Tue, 9 Jan 2007 18:29:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Tests for JBoss MQ message counter functionality
Message-ID: <9763817.1168385346008.JavaMail.jboss@colo-br-02.atl.jboss.com>

Actually, I shouldn't have said it was very bad, as an HTML table is pretty nice for say, an operations team to view from the JMX console, but it doesn't really work in any other context, namely for machine parsing or putting it in a spreadsheet. It would be much more useful to have something like an XML element that could be more easily transformed.

Something that should be fixed is that historical continues to accumulate in memory, and older data should be removed after some time (say, a month). And I believe the default configuration should have this set to a reasonable default.

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

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


From do-not-reply at jboss.com  Tue Jan  9 18:31:32 2007
From: do-not-reply at jboss.com (genman)
Date: Tue, 9 Jan 2007 18:31:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Full JMX functionality
Message-ID: <4229610.1168385492640.JavaMail.jboss@colo-br-02.atl.jboss.com>

What are the types for the List objects? If JBM requires JDK 1.5 it would be good to include them in the interface file.

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

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


From do-not-reply at jboss.com  Tue Jan  9 19:05:09 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 9 Jan 2007 19:05:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Serialization] - Re: Cleanup of
	project, move to maven, svn?
Message-ID: <1141624.1168387509621.JavaMail.jboss@colo-br-02.atl.jboss.com>

"clebert.suconic at jboss.com" wrote : I don't have any objections... I just didn't have time to do it before.
  | 
  | Ruel had created a Maven build for jboss-serialization when he was working on maven scripts. It should be in good shape but I haven't tested it recently.
  | 
I don't see it under https://svn.jboss.org/repos/ so what is the repo for this?

"clebert.suconic at jboss.com" wrote : 
  | .. talking about this new xml output stream... you are considering using jboss-serialization to serialize objects into XML format? Did I understand that correctly?
Yes.


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

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


From do-not-reply at jboss.com  Tue Jan  9 19:17:22 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Tue, 9 Jan 2007 19:17:22 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Serialization] - Re: Cleanup of
	project, move to maven, svn?
Message-ID: <29833564.1168388242836.JavaMail.jboss@colo-br-02.atl.jboss.com>


"Scott" wrote : I don't see it under https://svn.jboss.org/repos/ so what is the repo for this? 

still on old CVS

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

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


From do-not-reply at jboss.com  Tue Jan  9 19:33:29 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Tue, 9 Jan 2007 19:33:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: PojoCache uses a
	special node factory
Message-ID: <30463447.1168389209874.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | NodeFactory should probably come from the RegionManager.
  | 

This only makes sense post-3.0, when we regionalise the entire cache.  At the moment it won't make much sense.

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

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


From do-not-reply at jboss.com  Tue Jan  9 19:41:40 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Tue, 9 Jan 2007 19:41:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Last chance for any
	changes to the 2.0.0 API
Message-ID: <24278464.1168389700851.JavaMail.jboss@colo-br-02.atl.jboss.com>

Good comments.

"genman" wrote : 
  | 1. putIfNull -> putIfAbsent, See http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ConcurrentMap.html . People might get confused with "null" versus absent.
  | 

Agreed.

"genman" wrote : 
  | 2. Remove the print* methods in NodeSPI. Or at least document them. Consider creating a separate util class to print a node.
  | 

My issue with a separate util class is that it will mean maintaining yet another public interface/class.  

+1 to documenting them better.

"genman" wrote : 
  | 3. removeChildDirect(Fqn) and removeChildDirect(Object) is a little confusing, since Fqn is a subtype of Object. I would probably suggest just having one or the other.
  | 

It does look confusing, but for the sake of convenience - and a lot of unnecessary Fqn creation - it makes sense having the 'Object' version.  Helps avoid a lot of unnecessary stuff like 
node.getChildDirect(new Fqn(childName))
which in turn simply does
if (fqn.size() == 1) return children.get(fqn.getLastElement());

Justifying the Fqn version, it cleans up unnecessary and repeated looping in interceptors and CacheImpl searching for a child node several nodes deep.

"genman" wrote : 
  | 4. Some of the NodeSPI data methods appear to be just convenience methods and aren't strictly necessary given that getDataDirect() returns an externally modifiable map. For instance, clearDataDirect() really just is the same as NodeSPI.getDataDirect().clear(). So, it would be nice to understand the reason for these extra methods.

This is a good point.  Will revisit thise.  Their Node interface counterparts that went up the interceptor stack made sense, but the 'direct' versions do not.

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

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


From do-not-reply at jboss.com  Tue Jan  9 19:44:39 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 9 Jan 2007 19:44:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Serialization] - Re: Cleanup of
	project, move to maven, svn?
Message-ID: <4570363.1168389879195.JavaMail.jboss@colo-br-02.atl.jboss.com>

I had a dyslexia attack as I was thinking of svn when you said maven. I see the maven pom.xml in the current cvs jboss-serialization project.


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

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


From do-not-reply at jboss.com  Tue Jan  9 19:56:11 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Tue, 9 Jan 2007 19:56:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Aspect integration to bootstrap classes
Message-ID: <7866892.1168390571210.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have completed the first part of this, so that we get a proxy created for the MainDeployer. The AspectManager and AspectDeployer are now created in bootstrap-beans.xml, and I have moved these to the jboss/lib directory:
-jboss-aop-jdk50.jar
-jboss-aop-mc-int.jar
-trove.jar
-javassist.jar (was there already)
-jboss-aop-deployer-jdk50.jar (The parts of the jboss-aspect-library.jar relating to deployment, i.e. org.jboss.aop.deployers and org.jboss.aop.deployment)

The bootstrap-beans.xml initialises the AspectManager with the necessary aop.xml so that this is available when the MainDeployer is instantiated, so that we get a proxy created for that.

I have kept the jboss-aop-jboss5.deployer, it now contains a bean called "AspectLibrary" whose job is to deploy the base-aspects.xml (containing the @SecurityDomain, @Tx etc. interceptors) and the old aspect library (minus the stuff that now lives in jboss-aop-deployer-jdk50.jar). Services that previously depended on the AspectDeployer, and which need the aspect library aspects, should now depend on the "AspectLibrary", I have updated EJB 3 to do this.

I have created some stupid implementations of org.jboss.profileservice.aop.MainDeployerAspect and org.jboss.profileservice.aop.PersistAspect in the system module to verify that things work. MainDeployerAspect is functional, and I will look at the PersistAspect/ManagedProperty part tomorrow.

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

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


From do-not-reply at jboss.com  Tue Jan  9 20:18:05 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Tue, 9 Jan 2007 20:18:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Last chance for any
	changes to the 2.0.0 API
Message-ID: <25782727.1168391885233.JavaMail.jboss@colo-br-02.atl.jboss.com>

"manik.surtani at jboss.com" wrote : 
  | "genman" wrote : 
  |   | 4. Some of the NodeSPI data methods appear to be just convenience methods and aren't strictly necessary given that getDataDirect() returns an externally modifiable map. For instance, clearDataDirect() really just is the same as NodeSPI.getDataDirect().clear(). So, it would be nice to understand the reason for these extra methods.
  | 
  | This is a good point.  Will revisit thise.  Their Node interface counterparts that went up the interceptor stack made sense, but the 'direct' versions do not.

Actually, there is a good reason to still maintain these methods.  At some point I plan to do away with synchronizing these methods, and have my own lock checks to ensure the caller has appropriate locks.  And to do this, I need to make sure the Map returned to getDataDirect() is an unmodifiableMap.  

In fact, all read calls would return unmodifiableMap/Sets, and the only way to write in to them would be to use the write methods.

Read and Write methods would then impose a check on the caller to see if appropriate locks are available, e.g., 


  | pubic Map<Object, Object> getDataDirect()
  | {
  |       if (!getLock().getReaderOwners().contains(Thread.currentThread())) 
  |          throw new LockingException();
  |  
  |       // defensive copy + unmodifiable
  |       return Collections.unmodifiableMap(new HashMap(data));
  | }
  | 

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

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


From do-not-reply at jboss.com  Tue Jan  9 21:55:43 2007
From: do-not-reply at jboss.com (ben.wang@jboss.com)
Date: Tue, 9 Jan 2007 21:55:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: PojoCache uses a
	special node factory
Message-ID: <29024076.1168397743719.JavaMail.jboss@colo-br-02.atl.jboss.com>

"manik.surtani at jboss.com" wrote : you actually create:
  | 
  | /_JBossInternal_/Bucket0-9/Node1
  | /_JBossInternal_/Bucket0-9/Node2
  | /_JBossInternal_/Bucket10-19/Node10
  | /_JBossInternal_/Bucket10-19/Node11
  | 
  | which will reduce the contention on _JBossInternal_ as a direct parent.  

This will certainly help. Like you mentioned, this is problem more to the Cache usage itself. But it still will create contention though, and worse still can cause some lock timeout, say, when "/_JBossInternal_/Bucket0-9/Node1" tries to create another sub-node at "/_JBossInternal_/Bucket10-19/Node10", and meanwhile "/_JBossInternal_/Bucket10-19/Node11" tries to create a sub-node at "/_JBossInternal_/Bucket0-9/Node2" within the same transaction.

I am thinking another solution (in addition to the above option) is to allow user-specified bucket. For example, if you are using the core Cache, and you want to reduce lock contention and have the freedom to organize your fqn, then, the following will have high concurrency,


  | // pre-create the node "/a", and "/b" first.
  | 
  | // From thread 1
  | loop(i=1:100)
  | {
  | cache.put("/a/1", k1, o1);
  | }
  | 
  | 
  | // From thread 2
  | loop(i=1:100)
  | {
  | cache.put("/b/1", k1, o1);
  | }
  | 

Granted not all use case can have this leeway to specify fqn like this. But when you can, this solution can perform well. So in similar token, I am thinking to allow an option for PojoCache user to pre-create the sub-tree in "__JBossInternal__". Let's take an example,


  | pojoCache.attach("hr/joe", joe);
  | pojoCache.attach("eng/ben", ben);
  | 
  | //from thread 1
  | loop(i=0:100)
  | {
  |   pojoCache.attach("hr/joe", joe);
  | }
  | 
  | //from thread 2
  | loop(i=0:100)
  | {
  |   pojoCache.attach("eng/ben", ben);
  | }
  | 

Now, when we map them into "__JBossInternal__", we will map as:

  | cache.put("/__JBossInternal__/hr/joe, xxx)
  | 
and

  | cache.put("/__JBossInternal__/eng/ben, xxx)
  | 
respectively. That is we will add the prefix such as "hr/joe" and "eng/ben" under the internal fqn. In this case, except during the pre-creation stage, there won't be write lock contention. Of course, we pay the penalty of creating extra fqn hierarchy.

Thought?


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

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


From do-not-reply at jboss.com  Wed Jan 10 00:05:59 2007
From: do-not-reply at jboss.com (anil.saldhana@jboss.com)
Date: Wed, 10 Jan 2007 00:05:59 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Serialization] - Re: Cleanup of
	project, move to maven, svn?
Message-ID: <8783371.1168405559529.JavaMail.jboss@colo-br-02.atl.jboss.com>

"scott.stark at jboss.org" wrote : I had a dyslexia attack as I was thinking of svn when you said maven. I see the maven pom.xml in the current cvs jboss-serialization project.
  | 
Skiing is the long-tested remedy for dyslexia.

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

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


From do-not-reply at jboss.com  Wed Jan 10 05:25:30 2007
From: do-not-reply at jboss.com (Glooper)
Date: Wed, 10 Jan 2007 05:25:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Serialization] - Re:
	resolveClass and annotateClass
Message-ID: <29999604.1168424730926.JavaMail.jboss@colo-br-02.atl.jboss.com>

Thankyou... I will look forward to your findings.

Ben

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

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


From do-not-reply at jboss.com  Wed Jan 10 05:29:51 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 10 Jan 2007 05:29:51 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Full JMX functionality
Message-ID: <17564132.1168424991888.JavaMail.jboss@colo-br-02.atl.jboss.com>

For listing subscriptions it returns a list of SubscriptionInfo objects, which are basically value objects holding subscription related data.

For listing messages, it currently just returns the actual message objects. I was thinking whether to create value objects for the messages too, but I'm not sure.

Currently the caller will have to include the JBM jar on the caller side - not sure how putting in the interface file would help - can you elucidate?

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

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


From do-not-reply at jboss.com  Wed Jan 10 05:37:23 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 10 Jan 2007 05:37:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Tests for JBoss MQ message counter functionality
Message-ID: <31990119.1168425443500.JavaMail.jboss@colo-br-02.atl.jboss.com>

http://jira.jboss.com/jira/browse/JBMESSAGING-732

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

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


From do-not-reply at jboss.com  Wed Jan 10 06:04:04 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Wed, 10 Jan 2007 06:04:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Channel creation -
	mux vs. old style
Message-ID: <7845868.1168427044069.JavaMail.jboss@colo-br-02.atl.jboss.com>

I agree with all of the above.  This should be a lot more intelligent in understanding user intention and act accordingly.

1) If JChannelFactory is injected, ONLY attempt to use this or FAIL.
2) If an ObjectName is specified, ONLY attempt to use this or FAIL.
3) If an old-style config is provided, use this or FAIL.
4) ONLY use the default if nothing else is PROVIDED, not if nothing else WORKS.

I presume you'd need this in 1.4.x for AS 4.2?  :/



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

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


From do-not-reply at jboss.com  Wed Jan 10 06:06:39 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Wed, 10 Jan 2007 06:06:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: PojoCache uses a
	special node factory
Message-ID: <24206133.1168427199351.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | 
  | This will certainly help. Like you mentioned, this is problem more to the Cache usage itself. But it still will create contention though, and worse still can cause some lock timeout, say, when "/_JBossInternal_/Bucket0-9/Node1" tries to create another sub-node at "/_JBossInternal_/Bucket10-19/Node10", and meanwhile "/_JBossInternal_/Bucket10-19/Node11" tries to create a sub-node at "/_JBossInternal_/Bucket0-9/Node2" within the same transaction. 
  | 
  | 

This same deadlock can occur without buckets, even if nodes 1, 2, 10 and 11 had the same direct parent.

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

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


From do-not-reply at jboss.com  Wed Jan 10 06:10:33 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Wed, 10 Jan 2007 06:10:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: PojoCache uses a
	special node factory
Message-ID: <5382649.1168427433416.JavaMail.jboss@colo-br-02.atl.jboss.com>

Rather than allowing users to pre-create buckets in an internal node (makes me shudder!) how about doing something like allowing users to somehow provide information on the bucket a node should belong to, a bit like Object.hashCode()?

We would probably want to use hashCode() on the Fqn as the primary way of determining which bucket the node goes in, but perhaps a mechanism of allowing the user to add a 'hint' to this would help.  


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

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


From do-not-reply at jboss.com  Wed Jan 10 06:40:28 2007
From: do-not-reply at jboss.com (ben.wang@jboss.com)
Date: Wed, 10 Jan 2007 06:40:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: PojoCache uses a
	special node factory
Message-ID: <16998665.1168429228497.JavaMail.jboss@colo-br-02.atl.jboss.com>

"manik.surtani at jboss.com" wrote : anonymous wrote : 
  |   | This same deadlock can occur without buckets, even if nodes 1, 2, 10 and 11 had the same direct parent.
  | 
  | Sorry, but don't get it here. The first to access would have the WL on the parent and therefore creating a subsequent child node will go ahead becuase of the same transaction context. So only the other thread will block untill the first transaction is completed. Where is the deadlock here?
  | 

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

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


From do-not-reply at jboss.com  Wed Jan 10 06:45:05 2007
From: do-not-reply at jboss.com (ben.wang@jboss.com)
Date: Wed, 10 Jan 2007 06:45:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: PojoCache uses a
	special node factory
Message-ID: <14534669.1168429505272.JavaMail.jboss@colo-br-02.atl.jboss.com>

"manik.surtani at jboss.com" wrote : Rather than allowing users to pre-create buckets in an internal node (makes me shudder!) how about doing something like allowing users to somehow provide information on the bucket a node should belong to, a bit like Object.hashCode()?
  | 
  | We would probably want to use hashCode() on the Fqn as the primary way of determining which bucket the node goes in, but perhaps a mechanism of allowing the user to add a 'hint' to this would help.  
  | 

Relaxed. I am not saying user will create internal node directly. If you read my post, I was suggesting to have a flag to use the id field as a prefix under "__JBossInternal__". :-)

Hashcode is fine but that belongs to the Cache layer again of distributing them into hashed bucket.

Two different ways of optimizing the node creation for user to pick.


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

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


From do-not-reply at jboss.com  Wed Jan 10 06:48:04 2007
From: do-not-reply at jboss.com (ricardojbdias)
Date: Wed, 10 Jan 2007 06:48:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Variable instance
	(changing values)
Message-ID: <16396356.1168429684398.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi there,

I'm new to the forum.

I am trying to use jBPM, but I do not want to use the variables that we can define on the modeler. I want to associate each activity or process state, in this case, its form, with some variables I have defined in a xml. 
How can this be done in a simple way?

Thanks in advance.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999875#3999875

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999875


From do-not-reply at jboss.com  Wed Jan 10 07:36:42 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Wed, 10 Jan 2007 07:36:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: PojoCache uses a
	special node factory
Message-ID: <32824639.1168432602218.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | 
  | Sorry, but don't get it here. The first to access would have the WL on the parent and therefore creating a subsequent child node will go ahead becuase of the same transaction context. So only the other thread will block untill the first transaction is completed. Where is the deadlock here? 
  | 
  | 

Ok, I was assuming Nodes 1 and 2 were being read, not written.  E.g., 

Tx1
___
Read Node1
Write Node10

Tx2
___
Read Node2
Write Node11

That would deadlock.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999902#3999902

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999902


From do-not-reply at jboss.com  Wed Jan 10 10:04:42 2007
From: do-not-reply at jboss.com (kbarfield)
Date: Wed, 10 Jan 2007 10:04:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Suspended instances?
Message-ID: <28509499.1168441482111.JavaMail.jboss@colo-br-02.atl.jboss.com>

Give me a real world example of how this would get set.  If it is something that is not really used, then let's take it out of the console.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999973#3999973

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999973


From do-not-reply at jboss.com  Wed Jan 10 10:06:27 2007
From: do-not-reply at jboss.com (kbarfield)
Date: Wed, 10 Jan 2007 10:06:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Simplified end user
	functionality
Message-ID: <13708664.1168441587849.JavaMail.jboss@colo-br-02.atl.jboss.com>

I don't have a problem with the source tab showing up for adminstrators, but there is no need for end users (participant role) of the process to even know this functionality exists.  We need to be targeting Joe Corporate User with the Participant functionality.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999974#3999974

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999974


From do-not-reply at jboss.com  Wed Jan 10 10:08:01 2007
From: do-not-reply at jboss.com (kbarfield)
Date: Wed, 10 Jan 2007 10:08:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Modify process
	variables
Message-ID: <21658864.1168441681622.JavaMail.jboss@colo-br-02.atl.jboss.com>

Its going to be very hard to justify removing functionality from the console going from 3.1 to 3.2.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999976#3999976

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999976


From do-not-reply at jboss.com  Wed Jan 10 10:12:25 2007
From: do-not-reply at jboss.com (kbarfield)
Date: Wed, 10 Jan 2007 10:12:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Move search filter
Message-ID: <33348354.1168441945740.JavaMail.jboss@colo-br-02.atl.jboss.com>

My vote would be to have a "Filter Search Results" link that would take you to a filter form.  Submit the form, get the list with links "Reset Search Filter" and "Update Search Filter".

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999981#3999981

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999981


From do-not-reply at jboss.com  Wed Jan 10 10:17:53 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Wed, 10 Jan 2007 10:17:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Channel creation -
	mux vs. old style
Message-ID: <18411818.1168442273089.JavaMail.jboss@colo-br-02.atl.jboss.com>

Not critical, although it would be good.

Take that back - it's a pretty big deal -- at least the bit about not using the default properties.  I came across this yesterday when the RuntimeConfig.reset() issue prevented use of the multiplexer.  So 4 different AS services all opened channels using the default properties.  All of which then began spewing log messages complaining about getting messages with a different channel name. Not good at all.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999985#3999985

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999985


From do-not-reply at jboss.com  Wed Jan 10 10:36:55 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Wed, 10 Jan 2007 10:36:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - build updates on HEAD
Message-ID: <8569573.1168443415768.JavaMail.jboss@colo-br-02.atl.jboss.com>

i'm starting another round of build updates on head.  hopefully the last :-)

goals:

- automatic dependency fetching
- easier versioning of jbpm artifacts
- build profiles for targetting different environments (e.g. different jboss versions)
- maybe better release support repository and sf.net uploads

we'll see where we end up.

Alex, I believe that you are the only one that will be affected.  When would be a good time for you to spend 1 hour on synchronizing to the new build ?  I will wait with checking in till that time and take you through the necessary updates.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999993#3999993

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999993


From do-not-reply at jboss.com  Wed Jan 10 10:38:00 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 10 Jan 2007 10:38:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Move search filter
Message-ID: <9335229.1168443480447.JavaMail.jboss@colo-br-02.atl.jboss.com>

Everybody has a different opinion on this.  What is wrong with how it is now?  Is it really that confusing?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999995#3999995

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999995


From do-not-reply at jboss.com  Wed Jan 10 11:13:30 2007
From: do-not-reply at jboss.com (kbarfield)
Date: Wed, 10 Jan 2007 11:13:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Move search filter
Message-ID: <17556813.1168445610829.JavaMail.jboss@colo-br-02.atl.jboss.com>

I feel it is in the way and confusing right now, especially when there are no results in the list.  So, we show headers for the list, a bunch of text boxes, and no data.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000014#4000014

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000014


From do-not-reply at jboss.com  Wed Jan 10 11:16:13 2007
From: do-not-reply at jboss.com (phillips4jc)
Date: Wed, 10 Jan 2007 11:16:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Classpath Problem
Message-ID: <10937317.1168445773412.JavaMail.jboss@colo-br-02.atl.jboss.com>

We are still seeing problems with our Labs installation.  Here are the values that we used in the shotoku.properties file.

shotoku.default.url =http://B-0359/svn
shotoku.default.username = jboss
shotoku.default.password =jboss
shotoku.default.localpath =/cms-template

On startup we get the following MBEAN errors and Stack traces.  After this listing, there is another stack trace generated when you try to access the page.

09:17:28,228 INFO  [TomcatDeployer] deploy, ctxPath=/feeds, warUrl=.../tmp/deploy/tmp64391shotoku-feeds-exp.war/
09:17:28,712 ERROR [FeedsDescriptor] View feed getter class not found.
javax.ejb.EJBException: java.lang.NullPointerException
        at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:69)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:197)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:199)
        at org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:167)
        at org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:168)
        at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy186.getProperty(Unknown Source)
        at org.jboss.shotoku.feeds.portlet.FeedsViewPortlet.init(FeedsViewPortlet.java:95)
        at org.jboss.portal.portlet.container.PortletContainer.initPortlet(PortletContainer.java:391)
        at org.jboss.portal.portlet.container.PortletContainer.start(PortletContainer.java:251)
        at org.jboss.portal.portlet.container.PortletContainerAdapter.start(PortletContainerAdapter.java:74)
        at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.joinpoint.plugins.reflect.ReflectMethodJoinPoint.dispatch(ReflectMethodJoinPoint.java:72)
        at org.jboss.kernel.plugins.dependency.KernelControllerContextActions.dispatchJoinPoint(KernelControllerContextActions.java:92)
        at org.jboss.kernel.plugins.dependency.KernelControllerContextActions$LifecycleAction.installAction(KernelControllerContextActions.java:452)
        at org.jboss.kernel.plugins.dependency.KernelControllerContextActions$KernelControllerContextAction.install(KernelControllerContextActions.java:147)
        at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
        at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:226)
        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:593)
        at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:346)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:438)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:379)
        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:225)
        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:151)
        at org.jboss.kernel.plugins.dependency.AbstractKernelController.install(AbstractKernelController.java:74)
        at org.jboss.portal.portlet.deployment.jboss.PortletAppDeployment.start(PortletAppDeployment.java:232)
        at org.jboss.portal.core.deployment.jboss.PortletAppDeployment.start(PortletAppDeployment.java:79)
        at org.jboss.portal.server.deployment.jboss.PortalDeploymentInfo$DeploymentContext.start(PortalDeploymentInfo.java:211)
        at org.jboss.portal.server.deployment.jboss.ServerDeployer.start(ServerDeployer.java:242)
        at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
        at sun.reflect.GeneratedMethodAccessor188.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy138.deploy(Unknown Source)
        at org.jboss.portal.server.deployment.jboss.ServerDeployer.deploy(ServerDeployer.java:296)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy94.deploy(Unknown Source)
        at org.jboss.portal.server.deployment.WebAppAdapter.deploy(WebAppAdapter.java:54)
        at org.jboss.portal.server.deployment.WebAppIntercepter.handleNotification(WebAppIntercepter.java:133)
        at sun.reflect.GeneratedMethodAccessor117.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.notification.NotificationListenerProxy.invoke(NotificationListenerProxy.java:153)
        at $Proxy139.handleNotification(Unknown Source)
        at org.jboss.mx.util.JBossNotificationBroadcasterSupport.handleNotification(JBossNotificationBroadcasterSupport.java:127)
        at org.jboss.mx.util.JBossNotificationBroadcasterSupport.sendNotification(JBossNotificationBroadcasterSupport.java:108)
        at org.jboss.deployment.SubDeployerSupport.emitNotification(SubDeployerSupport.java:340)
        at org.jboss.deployment.SubDeployerSupport.start(SubDeployerSupport.java:308)
        at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:482)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
        at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
        at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
        at org.jboss.ws.server.WebServiceDeployer.start(WebServiceDeployer.java:117)
        at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
        at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy114.start(Unknown Source)
        at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
        at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy8.deploy(Unknown Source)
        at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
        at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
        at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
        at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
        at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
        at $Proxy0.start(Unknown Source)
        at org.jboss.system.ServiceController.start(ServiceController.java:417)
        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy4.start(Unknown Source)
        at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
        at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy5.deploy(Unknown Source)
        at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
        at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
        at org.jboss.Main.boot(Main.java:200)
        at org.jboss.Main$1.run(Main.java:464)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NullPointerException
        at org.jboss.shotoku.feeds.FeedsDescriptor.getProperties(FeedsDescriptor.java:154)
        at org.jboss.shotoku.feeds.FeedsDescriptor.getProperty(FeedsDescriptor.java:158)
        at org.jboss.shotoku.feeds.FeedsDescriptor.(FeedsDescriptor.java:117)
        at org.jboss.shotoku.feeds.service.FeedsServiceImpl.getFeedsDescriptor(FeedsServiceImpl.java:48)
        at org.jboss.shotoku.feeds.service.FeedsServiceImpl.getProperty(FeedsServiceImpl.java:55)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
        at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
        at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        ... 166 more
09:17:29,141 INFO  [TomcatDeployer] deploy, ctxPath=/file-access, warUrl=.../tmp/deploy/tmp64392shotoku-file-access-exp.war/
09:17:29,527 INFO  [TomcatDeployer] deploy, ctxPath=/shotoku-tags, warUrl=.../tmp/deploy/tmp64393shotoku-tags-exp.war/
09:17:29,890 INFO  [TomcatDeployer] deploy, ctxPath=/shotoku-test, warUrl=.../tmp/deploy/tmp64394shotoku-test-exp.war/
09:17:30,222 INFO  [TomcatDeployer] deploy, ctxPath=/speller, warUrl=.../tmp/deploy/tmp64395speller-exp.war/
09:17:30,651 ERROR [URLDeploymentScanner] Incomplete Deployment listing:

--- MBeans waiting for other MBeans ---
ObjectName: persistence.units:jar=polls-commons.jar,unitName=polls
  State: NOTYETINSTALLED
  I Depend On:
    jboss.jca:name=LabsDS,service=ManagedConnectionFactory
  Depends On Me:
    jboss.j2ee:jar=polls-commons.jar,name=PollsServiceImpl,service=EJB3

ObjectName: jboss.j2ee:jar=polls-commons.jar,name=PollsServiceImpl,service=EJB3
  State: NOTYETINSTALLED
  I Depend On:
    persistence.units:jar=polls-commons.jar,unitName=polls

ObjectName: persistence.units:jar=forge-common-1.0.ejb3.jar,unitName=property_persistance
  State: NOTYETINSTALLED
  I Depend On:
    jboss.jca:name=LabsDS,service=ManagedConnectionFactory
  Depends On Me:
    jboss.j2ee:jar=forge-common-1.0.ejb3,name=PropertyServiceBean,service=EJB3

ObjectName: jboss.j2ee:jar=forge-common-1.0.ejb3,name=PropertyServiceBean,service=EJB3
  State: NOTYETINSTALLED
  I Depend On:
    persistence.units:jar=forge-common-1.0.ejb3.jar,unitName=property_persistance

ObjectName: persistence.units:jar=shotoku-feeds.ejb3.jar,unitName=feeds
  State: NOTYETINSTALLED
  I Depend On:
    jboss.jca:name=LabsDS,service=ManagedConnectionFactory
  Depends On Me:
    jboss.j2ee:jar=shotoku-feeds.ejb3,name=CommentsServiceImpl,service=EJB3

ObjectName: jboss.j2ee:jar=shotoku-feeds.ejb3,name=CommentsServiceImpl,service=EJB3
  State: NOTYETINSTALLED
  I Depend On:
    shotoku:service=user
    persistence.units:jar=shotoku-feeds.ejb3.jar,unitName=feeds
    shotoku:service=shotoku
    shotoku:service=feeds

ObjectName: persistence.units:jar=shotoku-tags.ejb3.jar,unitName=tags
  State: NOTYETINSTALLED
  I Depend On:
    jboss.jca:name=LabsDS,service=ManagedConnectionFactory
  Depends On Me:
    jboss.j2ee:jar=shotoku-tags.ejb3,name=TagServiceImpl,service=EJB3

ObjectName: jboss.j2ee:jar=shotoku-tags.ejb3,name=TagServiceImpl,service=EJB3
  State: NOTYETINSTALLED
  I Depend On:
    shotoku:service=shotoku
    persistence.units:jar=shotoku-tags.ejb3.jar,unitName=tags

--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.jca:name=LabsDS,service=ManagedConnectionFactory
  State: NOTYETINSTALLED
  Depends On Me:
    persistence.units:jar=polls-commons.jar,unitName=polls
    persistence.units:jar=forge-common-1.0.ejb3.jar,unitName=property_persistance
    persistence.units:jar=shotoku-feeds.ejb3.jar,unitName=feeds
    persistence.units:jar=shotoku-tags.ejb3.jar,unitName=tags


09:17:30,848 INFO  [Http11BaseProtocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080
09:17:31,959 INFO  [ChannelSocket] JK: ajp13 listening on /0.0.0.0:8009
09:17:31,978 INFO  [JkMain] Jk running ID=0 time=0/68  config=null
09:17:31,996 INFO  [Server] JBoss (MX MicroKernel) [4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000)] Started in 1m:58s:798ms
*************************************************************
Only copied a portion of the stack trace generated by accessing the page, as it was over 1000 lines long.

s_4_0_4_GA date=200605151000)] Started in 1m:58s:798ms
09:47:29,505 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception java.lang.NullPointerException
        at org.jboss.forge.common.FilesFromRepoFilter.doFilter(FilesFromRepoFilter.java:108)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
        at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
        at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398)
        at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
        at org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java:703)
        at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:670)
        at org.apache.jsp.layouts.jbossForge_jsp._jspService(jbossForge_jsp.java:64)
        at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
        at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
        at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
        at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.jboss.portal.theme.LayoutDispatcher.execute(LayoutDispatcher.java:109)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.portal.server.servlet.CommandFilter.doFilter(CommandFilter.java:65)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
        at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
        at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
        at org.jboss.portal.theme.LayoutDispatcher.include(LayoutDispatcher.java:139)
        at org.jboss.portal.theme.impl.JSPLayout.assembleResponse(JSPLayout.java:34)
        at org.jboss.portal.core.command.MarkupCommand.execute(MarkupCommand.java:360)
        at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
        at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:171)
        at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
        at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationInterceptor.java:80)
        at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:79)
        at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
        at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:59)

[/img]

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000015#4000015

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000015


From do-not-reply at jboss.com  Wed Jan 10 11:18:27 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 10 Jan 2007 11:18:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: comment is
	confusing in the websale example
Message-ID: <2216845.1168445907854.JavaMail.jboss@colo-br-02.atl.jboss.com>

Barring further comment, the action I will take here is to remove the comment process variable and the comment text box from the websale example.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000016#4000016

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000016


From do-not-reply at jboss.com  Wed Jan 10 11:19:39 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 10 Jan 2007 11:19:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: When should the
	webconsole mark tasks as started?
Message-ID: <29354910.1168445979524.JavaMail.jboss@colo-br-02.atl.jboss.com>

The action I will take here is to update the task start date as soon as the assignee views the task.  Also, I will take the further action of listing new (unstarted) tasks in boldface in the user task list.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000018#4000018

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000018


From do-not-reply at jboss.com  Wed Jan 10 11:22:19 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Wed, 10 Jan 2007 11:22:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Virtual hosts and
	multiple portal server instances
Message-ID: <31453855.1168446139017.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi Sverker,

I have added the portalHost idea from your patch to the codebase.

That way it gives to ppl that integrates using command factories the capability to leverage that information to return the appropriate command (like a specific portal for a specific virtual host).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000020#4000020

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000020


From do-not-reply at jboss.com  Wed Jan 10 11:25:36 2007
From: do-not-reply at jboss.com (koen.aers@jboss.com)
Date: Wed, 10 Jan 2007 11:25:36 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Move search filter
Message-ID: <14307601.1168446336463.JavaMail.jboss@colo-br-02.atl.jboss.com>

In the meantime I also had a look at this... (well, Tom forced me to look at it to be honest ;-) )
I think that the criteria filter should appear as a block of controls at the bottom of the screen *if it is visible at all*. I would make it unvisible by default and provide a link that can toggle the visibility of this block, also at the bottom of the screen.

Regards,
Koen

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000023#4000023

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000023


From do-not-reply at jboss.com  Wed Jan 10 11:26:03 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 10 Jan 2007 11:26:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: replace sources
	tabs with links
Message-ID: <11097875.1168446363360.JavaMail.jboss@colo-br-02.atl.jboss.com>

The action I will take here is to create a separate page for viewing source code, with a "Back" link.  There will be a link from the process instance view for process source, and a link from the task instance view for task form source.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000024#4000024

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000024


From do-not-reply at jboss.com  Wed Jan 10 11:32:24 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 10 Jan 2007 11:32:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: remove context
	sensitive menus
Message-ID: <14650099.1168446744444.JavaMail.jboss@colo-br-02.atl.jboss.com>

The action here is: Context menus are toast.  I'm not going to change to "Execution" for 3.x.  But I think that we should work to make "Execution" be the standard term for a process instance+token in 4.x.  "Process" will refer to the definition, and "Process Instance" will refer to the instance (for now).  Task definitions and instances will continue to be referred to as "Task Definitions" and "Tasks", respectively.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000026#4000026

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000026


From do-not-reply at jboss.com  Wed Jan 10 11:36:56 2007
From: do-not-reply at jboss.com (unibrew)
Date: Wed, 10 Jan 2007 11:36:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Classpath Problem
Message-ID: <30213555.1168447016670.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi

I wouldn't care about this NPE from Feeds, I also have it ;-). The most important issue visible in your log is lack or wrongly configured datasource. --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
  | ObjectName: jboss.jca:name=LabsDS,service=ManagedConnectionFactory
  |   State: NOTYETINSTALLED
  |   Depends On Me:
  |     persistence.units:jar=polls-commons.jar,unitName=polls
  |     persistence.units:jar=forge-common-1.0.ejb3.jar,unitName=property_persistance
  |     persistence.units:jar=shotoku-feeds.ejb3.jar,unitName=feeds
  |     persistence.units:jar=shotoku-tags.ejb3.jar,unitName=tags
Look into sources and in directory configuration/to-copy/server/all/deploy you should find JBLab-ds.xml.sample, portal-mysql-ds.xml.sample and portal-login-ds.xml.sample. Fill those files with proper information about your database and copy to files without "sample" extension.

Regards
----------------------
Ryszard Kozmik
JBoss Forums Lead
JBoss Labs Team

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000027#4000027

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000027


From do-not-reply at jboss.com  Wed Jan 10 11:37:53 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 10 Jan 2007 11:37:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: simplified task
	instance view
Message-ID: <6312748.1168447073531.JavaMail.jboss@colo-br-02.atl.jboss.com>

Action items: Remove comment fields from websale example; consolidate task view into one screen (including adding an "add comment" area that is always visible); rename the controversial "End Task" transition inside the websale example.  If a task form isn't available, that part won't be rendered.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000028#4000028

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000028


From do-not-reply at jboss.com  Wed Jan 10 11:39:34 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 10 Jan 2007 11:39:34 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: simplified process
	instance view
Message-ID: <32752846.1168447174635.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'll consolidate this screen as described, maybe not exactly in all respects but I don't see any reason to deviate wildly from what's been described here.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000030#4000030

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000030


From do-not-reply at jboss.com  Wed Jan 10 11:43:19 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 10 Jan 2007 11:43:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: direct navigation
	when starting a new process instance
Message-ID: <12660691.1168447399375.JavaMail.jboss@colo-br-02.atl.jboss.com>

Action: I will redirect the user to the first newly created task if there is one; if not, I will redirect the user to the process instance if it is still open; if not, I will redirect the user back to their task list.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000034#4000034

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000034


From do-not-reply at jboss.com  Wed Jan 10 12:04:27 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 10 Jan 2007 12:04:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: one central search
	page
Message-ID: <2223645.1168448667443.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, I'm going with three different search pages:  Process, Process Instance, and Task.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000046#4000046

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000046


From do-not-reply at jboss.com  Wed Jan 10 12:10:56 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Wed, 10 Jan 2007 12:10:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Channel creation -
	mux vs. old style
Message-ID: <12222620.1168449056532.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yuck.

Next 1.4.1 SP, I suppose?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000053#4000053

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000053


From do-not-reply at jboss.com  Wed Jan 10 12:16:02 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Wed, 10 Jan 2007 12:16:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Move search filter
Message-ID: <32760723.1168449362038.JavaMail.jboss@colo-br-02.atl.jboss.com>

toggle: +1

bottom of screen: Only if the toggle is visible without scrolling. (top still prefered, as did, for a different app, a whole bunch of our customters (3:1 ratio in favour of filters at the top WITH a toggle)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000059#4000059

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000059


From do-not-reply at jboss.com  Wed Jan 10 12:16:58 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Wed, 10 Jan 2007 12:16:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Channel creation -
	mux vs. old style
Message-ID: <10522995.1168449418817.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yeah, that should be OK.  Retagging 1.4.1.GA seems like overkill.  The fundamental problem yesterday was the reset() thing; the fact that it then opened channels with a default config and had a really exciting breakdown was more of a distraction than anything.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000062#4000062

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000062


From do-not-reply at jboss.com  Wed Jan 10 12:23:29 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 10 Jan 2007 12:23:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Move search filter
Message-ID: <1109390.1168449809484.JavaMail.jboss@colo-br-02.atl.jboss.com>

"kukeltje" wrote : toggle: +1
  | 
  | bottom of screen: Only if the toggle is visible without scrolling. (top still prefered, as did, for a different app, a whole bunch of our customters (3:1 ratio in favour of filters at the top WITH a toggle)

Real(ish) data++

Here's what I'm going to do.  I'm going to keep the filters right where they are, but I'm going to have a link to show/hide the filters.  Case closed, end of story. :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000068#4000068

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000068


From do-not-reply at jboss.com  Wed Jan 10 12:48:29 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Wed, 10 Jan 2007 12:48:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: SELECT FOR UPDATE
	semantics
Message-ID: <23687593.1168451309383.JavaMail.jboss@colo-br-02.atl.jboss.com>

Fixed in CVS HEAD, will be in BETA1.

See o.j.c.options.ForceWriteLockTest for usage details.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000075#4000075

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000075


From do-not-reply at jboss.com  Wed Jan 10 13:59:08 2007
From: do-not-reply at jboss.com (samljones)
Date: Wed, 10 Jan 2007 13:59:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Classpath Problem
Message-ID: <32284969.1168455548512.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi,

Been working with jthorn and phillips4jc.

Those files are present (non-sample versions). The portal-login-ds.xml had no connection url, however. I modified that to match the url in the other two xml files (jdbc:mysql://localhost:3306/jbossportal?useServerPrepStmts=false); is this appropriate? They are supposed to be  in the same database, correct?

Also verified  that  the user/password in the files has  access to that database.

Is the default driver (org.gjt.mm.mysql.Driver) included as part of  the JBoss source code, or do we need to manually acquire a jar for that?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000101#4000101

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000101


From do-not-reply at jboss.com  Wed Jan 10 14:02:05 2007
From: do-not-reply at jboss.com (samljones)
Date: Wed, 10 Jan 2007 14:02:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Classpath Problem
Message-ID: <20503850.1168455725205.JavaMail.jboss@colo-br-02.atl.jboss.com>

Forgot to add, thanks for all the attention and help you all are giving us. We really appreciate it.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000103#4000103

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000103


From do-not-reply at jboss.com  Wed Jan 10 14:29:30 2007
From: do-not-reply at jboss.com (dwin)
Date: Wed, 10 Jan 2007 14:29:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Using
	jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
Message-ID: <25159281.1168457370688.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hey guys

I am following exactly step by step as described in the FAQ, except I use anonymous access to SVN as opposed to the committer access to SVN

I get the following build errors, I don't really want to mess with the class path build paths because it obviously worked for some people.   I am obviously missing some jars in my classpath or I have an outdated build.xml file (I checked out the code about two days ago)


  | Buildfile: build.xml
  | 
  | prepare:
  |      [echo] jboss50.home = ${jboss50.home}
  |      [echo] jboss42.home = C:\examples\jboss-4.2.x\build\output\jboss-4.2.0.CR1-ejb3
  |      [echo] jboss40.home = C:\examples\jboss-4.0.5\build\output\jboss-4.0.5.GA-ejb3
  |      [echo] tomcat.home  = ${tomcat.home}
  | 
  | 
  | thirdparty-get:
  | 
  | thirdparty-classpath:
  | 
  | thirdparty:
  | 
  | init:
  | 
  | core-init:
  | 
  | core-compile-classes:
  |     [javac] Compiling 77 source files to C:\examples\jbossws\jbossws-core\output\classes14
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\JAXRPCException.java:24: package org.jboss.util.id does not exist
  |     [javac] import org.jboss.util.id.SerialVersion;
  |     [javac]                          ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\ServiceException.java:24: package org.jboss.util.id does not exist
  |     [javac] import org.jboss.util.id.SerialVersion;
  |     [javac]                          ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\ServiceFactory.java:31: package org.jboss.logging does not exist
  |     [javac] import org.jboss.logging.Logger;
  |     [javac]                          ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\ServiceFactory.java:49: cannot find symbol
  |     [javac] symbol  : class Logger
  |     [javac] location: class javax.xml.rpc.ServiceFactory
  |     [javac]    private static Logger log = Logger.getLogger(ServiceFactory.class);
  |     [javac]                   ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\soap\SOAPFaultException.java:33: package org.jboss.logging does not exist
  |     [javac] import org.jboss.logging.Logger;
  |     [javac]                          ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\soap\SOAPFaultException.java:34: package org.jboss.util.id does not exist
  |     [javac] import org.jboss.util.id.SerialVersion;
  |     [javac]                          ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\soap\SOAPFaultException.java:57: cannot find symbol
  |     [javac] symbol  : class Logger
  |     [javac] location: class javax.xml.rpc.soap.SOAPFaultException
  |     [javac]    private static Logger log = Logger.getLogger(SOAPFaultException.class);
  |     [javac]                   ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\soap\SOAPException.java:24: package org.jboss.util.id does not exist
  |     [javac] import org.jboss.util.id.SerialVersion;
  |     [javac]                          ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\soap\SOAPMessage.java:29: package javax.activation does not exist
  |     [javac] import javax.activation.DataHandler;
  |     [javac]                         ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\soap\AttachmentPart.java:27: package javax.activation does not exist
  |     [javac] import javax.activation.DataHandler;
  |     [javac]                         ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\soap\SOAPMessage.java:108: cannot find symbol
  |     [javac] symbol  : class DataHandler
  |     [javac] location: class javax.xml.soap.SOAPMessage
  |     [javac]    public AttachmentPart createAttachmentPart(DataHandler datahandler)
  |     [javac]                                               ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\soap\AttachmentPart.java:182: cannot find symbol
  |     [javac] symbol  : class DataHandler
  |     [javac] location: class javax.xml.soap.AttachmentPart
  |     [javac]    public abstract DataHandler getDataHandler() throws SOAPException;
  |     [javac]                    ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\soap\AttachmentPart.java:284: cannot find symbol
  |     [javac] symbol  : class DataHandler
  |     [javac] location: class javax.xml.soap.AttachmentPart
  |     [javac]    public abstract void setDataHandler(DataHandler dataHandler);
  |     [javac]                                        ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\server\ServletEndpointContext.java:26: package javax.servlet does not exist
  |     [javac] import javax.servlet.ServletContext;
  |     [javac]                      ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\server\ServletEndpointContext.java:27: package javax.servlet.http does not exist
  |     [javac] import javax.servlet.http.HttpSession;
  |     [javac]                           ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\server\ServletEndpointContext.java:60: cannot find symbol
  |     [javac] symbol  : class HttpSession
  |     [javac] location: interface javax.xml.rpc.server.ServletEndpointContext
  |     [javac]    public HttpSession getHttpSession();
  |     [javac]           ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\server\ServletEndpointContext.java:78: cannot find symbol
  |     [javac] symbol  : class ServletContext
  |     [javac] location: interface javax.xml.rpc.server.ServletEndpointContext
  |     [javac]    public ServletContext getServletContext();
  |     [javac]           ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\soap\FactoryLoader.java:34: package org.jboss.logging does not exist
  |     [javac] import org.jboss.logging.Logger;
  |     [javac]                          ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\soap\FactoryLoader.java:47: cannot find symbol
  |     [javac] symbol  : class Logger
  |     [javac] location: class javax.xml.soap.FactoryLoader
  |     [javac]    private static Logger log = Logger.getLogger(MessageFactory.class);
  |     [javac]                   ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\soap\SOAPConnection.java:24: package org.jboss.util does not exist
  |     [javac] import org.jboss.util.NotImplementedException;
  |     [javac]                       ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\soap\SOAPConnectionFactory.java:27: package org.jboss.logging does not exist
  |     [javac] import org.jboss.logging.Logger;
  |     [javac]                          ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\soap\SOAPConnectionFactory.java:43: cannot find symbol
  |     [javac] symbol  : class Logger
  |     [javac] location: class javax.xml.soap.SOAPConnectionFactory
  |     [javac]    private static Logger log = Logger.getLogger(SOAPConnectionFactory.class);
  |     [javac]                   ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\JAXRPCException.java:36: cannot find symbol
  |     [javac] symbol  : variable SerialVersion
  |     [javac] location: class javax.xml.rpc.JAXRPCException
  |     [javac]       if (SerialVersion.version == SerialVersion.LEGACY)
  |     [javac]           ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\JAXRPCException.java:36: cannot find symbol
  |     [javac] symbol  : variable SerialVersion
  |     [javac] location: class javax.xml.rpc.JAXRPCException
  |     [javac]       if (SerialVersion.version == SerialVersion.LEGACY)
  |     [javac]                                    ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\ServiceException.java:36: cannot find symbol
  |     [javac] symbol  : variable SerialVersion
  |     [javac] location: class javax.xml.rpc.ServiceException
  |     [javac]       if (SerialVersion.version == SerialVersion.LEGACY)
  |     [javac]           ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\ServiceException.java:36: cannot find symbol
  |     [javac] symbol  : variable SerialVersion
  |     [javac] location: class javax.xml.rpc.ServiceException
  |     [javac]       if (SerialVersion.version == SerialVersion.LEGACY)
  |     [javac]                                    ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\ServiceFactory.java:49: cannot find symbol
  |     [javac] symbol  : variable Logger
  |     [javac] location: class javax.xml.rpc.ServiceFactory
  |     [javac]    private static Logger log = Logger.getLogger(ServiceFactory.class);
  |     [javac]                                ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\soap\SOAPFaultException.java:57: cannot find symbol
  |     [javac] symbol  : variable Logger
  |     [javac] location: class javax.xml.rpc.soap.SOAPFaultException
  |     [javac]    private static Logger log = Logger.getLogger(SOAPFaultException.class);
  |     [javac]                                ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\soap\SOAPFaultException.java:68: cannot find symbol
  |     [javac] symbol  : variable SerialVersion
  |     [javac] location: class javax.xml.rpc.soap.SOAPFaultException
  |     [javac]       if (SerialVersion.version == SerialVersion.LEGACY)
  |     [javac]           ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\rpc\soap\SOAPFaultException.java:68: cannot find symbol
  |     [javac] symbol  : variable SerialVersion
  |     [javac] location: class javax.xml.rpc.soap.SOAPFaultException
  |     [javac]       if (SerialVersion.version == SerialVersion.LEGACY)
  |     [javac]                                    ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\soap\SOAPException.java:36: cannot find symbol
  |     [javac] symbol  : variable SerialVersion
  |     [javac] location: class javax.xml.soap.SOAPException
  |     [javac]       if (SerialVersion.version == SerialVersion.LEGACY)
  |     [javac]           ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\soap\SOAPException.java:36: cannot find symbol
  |     [javac] symbol  : variable SerialVersion
  |     [javac] location: class javax.xml.soap.SOAPException
  |     [javac]       if (SerialVersion.version == SerialVersion.LEGACY)
  |     [javac]                                    ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\soap\FactoryLoader.java:47: cannot find symbol
  |     [javac] symbol  : variable Logger
  |     [javac] location: class javax.xml.soap.FactoryLoader
  |     [javac]    private static Logger log = Logger.getLogger(MessageFactory.class);
  |     [javac]                                ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\soap\SOAPConnection.java:69: cannot find symbol
  |     [javac] symbol  : class NotImplementedException
  |     [javac] location: class javax.xml.soap.SOAPConnection
  |     [javac]       throw new NotImplementedException();
  |     [javac]                 ^
  |     [javac] C:\examples\jbossws\jbossws-core\src\main\java\javax\xml\soap\SOAPConnectionFactory.java:43: cannot find symbol
  |     [javac] symbol  : variable Logger
  |     [javac] location: class javax.xml.soap.SOAPConnectionFactory
  |     [javac]    private static Logger log = Logger.getLogger(SOAPConnectionFactory.class);
  |     [javac]                                ^
  |     [javac] 35 errors
  | 

Here is my ant.properties file

  | jboss42.home=C:\\examples\\jboss-4.2.x\\build\\output\\jboss-4.2.0.CR1-ejb3
  | jboss40.home=C:\\examples\\jboss-4.0.5\\build\\output\\jboss-4.0.5.GA-ejb3
  | 
  | # The JBoss server under test. This can be [jboss50|jboss42|jboss40|tomcat]
  | jbossws.integration.target=jboss42

I am running under Windows XP 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000109#4000109

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000109


From do-not-reply at jboss.com  Wed Jan 10 14:33:25 2007
From: do-not-reply at jboss.com (dwin)
Date: Wed, 10 Jan 2007 14:33:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Using
	jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
Message-ID: <24883337.1168457605981.JavaMail.jboss@colo-br-02.atl.jboss.com>

I am trying to run on Jboss 4.0

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000110#4000110

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000110


From do-not-reply at jboss.com  Wed Jan 10 14:38:30 2007
From: do-not-reply at jboss.com (dwin)
Date: Wed, 10 Jan 2007 14:38:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Using
	jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
Message-ID: <13818779.1168457910137.JavaMail.jboss@colo-br-02.atl.jboss.com>

This is the setup, I am trying to run:

jboss-4.0.5, jaxws, jaxrpc, ejb3, jsr181, jdk-1.5

Instructions found here: 

http://wiki.jboss.org/wiki/Wiki.jsp?page=JBWSFAQBuildAndInstallJBoss40xEJB3

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000116#4000116

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000116


From do-not-reply at jboss.com  Wed Jan 10 14:44:15 2007
From: do-not-reply at jboss.com (samljones)
Date: Wed, 10 Jan 2007 14:44:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Classpath Problem
Message-ID: <18770978.1168458255731.JavaMail.jboss@colo-br-02.atl.jboss.com>

Also, on doing a locate of *.sample, there are many more  in the jboss source code, at least some of which have not been un-sample-ified. Is there a way to tell which are required for basic usage? I don't  want to add  values to a bunch of files and break jboss.

Thanks
-Sam

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000119#4000119

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000119


From do-not-reply at jboss.com  Wed Jan 10 14:46:20 2007
From: do-not-reply at jboss.com (prassib)
Date: Wed, 10 Jan 2007 14:46:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Whats the easiest way
	to access JBPM data outside of the JBP
Message-ID: <31713411.1168458380352.JavaMail.jboss@colo-br-02.atl.jboss.com>

I need to see some data from the JBPM tables just for lookup purposes & I am trying to avoid creating a JBPM context.

I used the JBPM hibernate mapping files & wrote my DAO with lookup methods. I can lookup the ProcessInstance object by its ID but I get a Hibernate LazyInitiliazationException when invoke method getRootToken().getNode()

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000120#4000120

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000120


From do-not-reply at jboss.com  Wed Jan 10 15:09:01 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 10 Jan 2007 15:09:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - What is the base entry
	point for aop remoting?
Message-ID: <12316516.1168459741170.JavaMail.jboss@colo-br-02.atl.jboss.com>

I see there are utility classes in the aspects project under org.jboss.aspects.remoting that provide some remoting setup and ejb3 has its own layer. The org.jboss.aspects.remoting.Remoting.makeRemotable has a hard-coded interceptor stack. Is there an aop equivalent of the org.jboss.proxy.GenericProxyFactory for detached invokers?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000130#4000130

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000130


From do-not-reply at jboss.com  Wed Jan 10 15:14:24 2007
From: do-not-reply at jboss.com (unibrew)
Date: Wed, 10 Jan 2007 15:14:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Classpath Problem
Message-ID: <11331413.1168460064975.JavaMail.jboss@colo-br-02.atl.jboss.com>

"samljones" wrote : Forgot to add, thanks for all the attention and help you all are giving us. We really appreciate it.No problem. I hope, you will show us your portal based on Labs after you finish it.

I think that everything needed is displayed by executing "maven help" in root directory of sources. There are some info after doing "maven install". You can see both of those in maven.xml file.

Cheers
----------------------
Ryszard Kozmik
JBoss Forums Lead
JBoss Labs Team

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000132#4000132

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000132


From do-not-reply at jboss.com  Wed Jan 10 15:19:56 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 10 Jan 2007 15:19:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] -
	org.jboss.aop.Dispatcher error?
Message-ID: <15713793.1168460396110.JavaMail.jboss@colo-br-02.atl.jboss.com>

As far as I can see this code in the org.jboss.aop.Dispatcher.invoke is a copy/paste error that should be using Proxy in place of ClassProxy:


  | ...
  |       else if (target instanceof Proxy)
  |       {
  |          ClassProxy proxy = (ClassProxy) target;
  |          return proxy._dynamicInvoke(invocation);
  |       }
  | 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000133#4000133

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000133


From do-not-reply at jboss.com  Wed Jan 10 16:06:32 2007
From: do-not-reply at jboss.com (thomas.diesler@jboss.com)
Date: Wed, 10 Jan 2007 16:06:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Using
	jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
Message-ID: <24714939.1168463192057.JavaMail.jboss@colo-br-02.atl.jboss.com>

The classes that are missing in your build should come from build/thirdparty. You can delete that dir to trigger a fetch

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000145#4000145

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000145


From do-not-reply at jboss.com  Wed Jan 10 16:11:11 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 10 Jan 2007 16:11:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - bean/mbean integration
	issue
Message-ID: <25562794.1168463471225.JavaMail.jboss@colo-br-02.atl.jboss.com>

I was hoping to be able to reference the jboss-service.xml mbean for the socket remoting transport to register a handler for the ProfileService with it similar to how deployers register with the MainDeployer:


  | ...
  |     <!--
  |         Add a ProfileService handler to the remoting socket connector
  |     -->
  |     <bean name="ProfileServiceInvocationHandler"
  |         class="org.jboss.aspects.remoting.AOPRemotingInvocationHandler">
  |         <install bean="jboss.remoting:service=Connector,transport=socket" method="addInvocationHandler">
  |             <parameter>ProfileService</parameter>
  |             <parameter><this/></parameter>
  |         </install>
  |         <uninstall bean="jboss.remoting:service=Connector,transport=socket" method="removeInvocationHandler">
  |             <parameter>ProfileService</parameter>
  |         </uninstall>
  |     </bean>
  | 

however, there is a type conflict showing up:

  | 12:56:19,930 ERROR [AbstractKernelController] Error installing to Installed: name=ProfileServiceInvocationHandler state=Start
  | java.lang.ClassCastException: org.jboss.system.microcontainer.ServiceControllerContext
  |         at org.jboss.kernel.plugins.dependency.InstallAction.installActionInternal(InstallAction.java:67)
  |         at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:187)
  |         at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:126)
  |         at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
  |         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
  |         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709)
  |         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:430)
  |         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:540)
  |         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:474)
  |         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:274)
  |         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:177)
  |         at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:67)
  |         at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42)
  |         at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:53)
  |         at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52)
  |         at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:156)
  |         at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:523)
  |         at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:534)
  |         at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:461)
  |         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:372)
  | ...
  | 

To allow for such an interaction, the mbean needs to have a mapping of its ServiceControllerContext to a KernelControllerContext, or ServiceControllerContext and KernelControllerContext need a shared base class that adds a common DispatchJoinPoint notion.

I can workaround this by moving the legacy remoting mbean to a mc bean (hopefully).


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000149#4000149

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000149


From do-not-reply at jboss.com  Wed Jan 10 16:35:01 2007
From: do-not-reply at jboss.com (dwin)
Date: Wed, 10 Jan 2007 16:35:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Using
	jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
Message-ID: <16831143.1168464901053.JavaMail.jboss@colo-br-02.atl.jboss.com>

In the words of Borat: Nice!

Also, just a heads up...

the property jboss.repository=http://repository.jboss.com 

needs to be there, in order to get a fetch of the latest jars.  

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000158#4000158

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000158


From do-not-reply at jboss.com  Wed Jan 10 17:16:44 2007
From: do-not-reply at jboss.com (adamw)
Date: Wed, 10 Jan 2007 17:16:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Classpath Problem
Message-ID: <17185691.1168467404658.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hello,
you should fillin/create all files listed by "maven help" and create non-sample versions of all .sample files found in the configuration directory.

The mysql driver is in the server/all/lib directory, included with the AS in our repository.

-- 
Adam

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000173#4000173

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000173


From do-not-reply at jboss.com  Wed Jan 10 17:31:56 2007
From: do-not-reply at jboss.com (dwin)
Date: Wed, 10 Jan 2007 17:31:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Using
	jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
Message-ID: <13698552.1168468316903.JavaMail.jboss@colo-br-02.atl.jboss.com>

Sorry to be a newbie about this, I am not too familiar with the build environment of JBossWS

The tests fail for me, it doesn't compile.  It seems to be another class path issue where Junit.jar cannot be found (the only instance of junit.jar is in jbossws/build/thirdparty).  I even put a force get in my ant.properties in the build folder.  

I get the following output, it appears to fail at the "main" task.  It all fails on Junit classes but it stops at 100 errors.   I am guessing even if I do manually junit.jar to the classpath, there will be other dependency errors to deal with.  I am guessing there is something wrong with my ant.properties or something did not check out right (via SVN).  

 
  | Buildfile: build.xml
  | 
  | prepare:
  |      [echo] -----------------------------------------------
  |      [echo] jboss.home    = C:\examples\jboss-4.2.x\build\output\jboss-4.2.0.CR1-ejb3
  |      [echo] tomcat.home   = ${tomcat.home}
  |      [echo] java.home     = C:\Sun\AppServer\jdk\jre
  |      [echo] endorsed.dirs = C:\examples\jboss-4.2.x\build\output\jboss-4.2.0.CR1-ejb3/lib/endorsed
  |      [echo] -----------------------------------------------
  | .
  | .
  | .
  | .
  | . (taken out for the sake of keeping the post short)
  | 
  |     [unzip] Expanding: C:\examples\jbossws\build\thirdparty\ejb3.deployer.zip into C:\examples\jbossws\build\thirdparty
  | 
  | thirdparty-classpath:
  | 
  | thirdparty:
  | 
  | init:
  |      [echo] excludefile = tests-jboss42-excludes.txt
  | 
  | compile14:
  | 
  | compile15:
  |     [javac] Compiling 1006 source files to C:\examples\jbossws\jbossws-tests\output\classes
  |     [javac] C:\examples\jbossws\jbossws-tests\src\main\java\org\jboss\test\ws\JBossWSTest.java:34: package junit.framework does not exist
  |     [javac] import junit.framework.TestCase;
  |     [javac]                        ^
  |     [javac] C:\examples\jbossws\jbossws-tests\src\main\java\org\jboss\test\ws\JBossWSTest.java:48: cannot find symbol
  |     [javac] symbol: class TestCase
  |     [javac] public abstract class JBossWSTest extends TestCase
  |     [javac]                                           ^
  |     [javac] C:\examples\jbossws\jbossws-tests\src\main\java\org\jboss\test\ws\JBossWSTestSetup.java:24: package junit.extensions does not exist
  |     [javac] import junit.extensions.TestSetup;
  |     [javac]                         ^
  |     [javac] C:\examples\jbossws\jbossws-tests\src\main\java\org\jboss\test\ws\JBossWSTestSetup.java:25: package junit.framework does not exist
  |     [javac] import junit.framework.TestSuite;
  |     [javac]                        ^
  |     [javac] 
  | .
  | .
  | .
  | .
  | .
  | .(taken out for the sake of keeping the post short)
  | 
  |     [javac] 100 errors
  | 
  | compile:
  | 
  | copy-resources:
  | 
  | generate-sources:
  |   [wstools] log4j:ERROR setFile(null,false) call failed.
  |   [wstools] java.io.FileNotFoundException: \test.log (Access is denied)
  |   [wstools] 	at java.io.FileOutputStream.open(Native Method)
  |   [wstools] 	at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
  |   [wstools] 	at java.io.FileOutputStream.<init>(FileOutputStream.java:102)
  |   [wstools] 	at org.apache.log4j.FileAppender.setFile(FileAppender.java:272)
  |   [wstools] 	at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:151)
  |   [wstools] 	at org.apache.log4j.DailyRollingFileAppender.activateOptions(DailyRollingFileAppender.java:206)
  |   [wstools] 	at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:247)
  |   [wstools] 	at org.apache.log4j.xml.DOMConfigurator.parseAppender(DOMConfigurator.java:210)
  |   [wstools] 	at org.apache.log4j.xml.DOMConfigurator.findAppenderByName(DOMConfigurator.java:140)
  |   [wstools] 	at org.apache.log4j.xml.DOMConfigurator.findAppenderByReference(DOMConfigurator.java:153)
  |   [wstools] 	at org.apache.log4j.xml.DOMConfigurator.parseChildrenOfLoggerElement(DOMConfigurator.java:415)
  |   [wstools] 	at org.apache.log4j.xml.DOMConfigurator.parseRoot(DOMConfigurator.java:384)
  |   [wstools] 	at org.apache.log4j.xml.DOMConfigurator.parse(DOMConfigurator.java:783)
  |   [wstools] 	at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:666)
  |   [wstools] 	at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:616)
  |   [wstools] 	at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:602)
  |   [wstools] 	at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:460)
  |   [wstools] 	at org.apache.log4j.LogManager.<clinit>(LogManager.java:113)
  |   [wstools] 	at org.jboss.logging.log4j.Log4jLoggerPlugin.init(Log4jLoggerPlugin.java:80)
  |   [wstools] 	at org.jboss.logging.Logger.getDelegatePlugin(Logger.java:393)
  |   [wstools] 	at org.jboss.logging.Logger.<init>(Logger.java:119)
  |   [wstools] 	at org.jboss.logging.Logger.getLogger(Logger.java:357)
  |   [wstools] 	at org.jboss.ws.tools.WSTools.<clinit>(Unknown Source)
  |   [wstools] 	at org.jboss.ws.tools.ant.wstools.execute(Unknown Source)
  |   [wstools] 	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
  |   [wstools] 	at org.apache.tools.ant.Task.perform(Task.java:364)
  |   [wstools] 	at org.apache.tools.ant.Target.execute(Target.java:341)
  |   [wstools] 	at org.apache.tools.ant.Target.performTasks(Target.java:369)
  |   [wstools] 	at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
  |   [wstools] 	at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
  |   [wstools] 	at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
  |   [wstools] 	at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
  |   [wstools] 	at org.apache.tools.ant.Main.runBuild(Main.java:668)
  |   [wstools] 	at org.apache.tools.ant.Main.startAnt(Main.java:187)
  |   [wstools] 	at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
  |   [wstools] 	at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
  |   [wstools] log4j:ERROR Either File or DatePattern options are not set for appender [FILE].
  |   [wstools] java.lang.NullPointerException
  |   [wstools] 	at java.lang.System.arraycopy(Native Method)
  |   [wstools] 	at org.apache.xerces.impl.xs.XSModelImpl.getAnnotations(Unknown Source)
  |   [wstools] 	at org.jboss.ws.metadata.wsdl.xmlschema.WSSchemaUtils.copyXSModel(Unknown Source)
  |   [wstools] 	at org.jboss.ws.tools.JavaToXSD.parseSchema(Unknown Source)
  |   [wstools] 	at org.jboss.ws.tools.wsdl.WSDL11Reader.processTypes(Unknown Source)
  |   [wstools] 	at org.jboss.ws.tools.wsdl.WSDL11Reader.processDefinition(Unknown Source)
  |   [wstools] 	at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.parse(Unknown Source)
  |   [wstools] 	at org.jboss.ws.tools.WSDLToJava.convertWSDL2Java(Unknown Source)
  |   [wstools] 	at org.jboss.ws.tools.helpers.ToolsHelper.handleWSDLToJavaGeneration(Unknown Source)
  |   [wstools] 	at org.jboss.ws.tools.WSTools.process(Unknown Source)
  |   [wstools] 	at org.jboss.ws.tools.WSTools.generate(Unknown Source)
  |   [wstools] 	at org.jboss.ws.tools.ant.wstools.execute(Unknown Source)
  |   [wstools] 	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
  |   [wstools] 	at org.apache.tools.ant.Task.perform(Task.java:364)
  |   [wstools] 	at org.apache.tools.ant.Target.execute(Target.java:341)
  |   [wstools] 	at org.apache.tools.ant.Target.performTasks(Target.java:369)
  |   [wstools] 	at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
  |   [wstools] 	at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
  |   [wstools] 	at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
  |   [wstools] 	at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
  |   [wstools] 	at org.apache.tools.ant.Main.runBuild(Main.java:668)
  |   [wstools] 	at org.apache.tools.ant.Main.startAnt(Main.java:187)
  |   [wstools] 	at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
  |   [wstools] 	at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
  | 
  | 

Any help would be much apperciated. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000180#4000180

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000180


From do-not-reply at jboss.com  Wed Jan 10 17:45:17 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Wed, 10 Jan 2007 17:45:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - 2.6 alpha release
Message-ID: <31675560.1168469117948.JavaMail.jboss@colo-br-02.atl.jboss.com>

I worked today to cleanup tests for the 2.6 release :

- I had to fix the CMS tests that were not able to run because it was relying on the UserModule from JNDI which was not available in the test environment. I fixed it by making the IdentityServiceController injected in the JCRCMS service instead

- commented out the 2 portlet test cases that cannot technically pass

- commented out one theme test that does not seem to exist anymore

- fixed the portal object and instance test cases that were broken due to my refactorings (I had to update the jboss-aop.xml and change the pointcuts, I can't wait to have Java 5 and annotations...)

- I updated the test framework to handle multi node testing (that was disabled after the refactorings done to handle test parameterization).

- I ported the 2.4 slight changes to portlet session replication to trunk.

All tests in the testsuite are passing for me now.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000184#4000184

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000184


From do-not-reply at jboss.com  Wed Jan 10 17:58:58 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Wed, 10 Jan 2007 17:58:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	org.jboss.aop.Dispatcher error?
Message-ID: <8633740.1168469938138.JavaMail.jboss@colo-br-02.atl.jboss.com>

Thanks, I've fixed this

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000189#4000189

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000189


From do-not-reply at jboss.com  Wed Jan 10 18:03:52 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Wed, 10 Jan 2007 18:03:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] -
	Retrowoven container project
Message-ID: <28394214.1168470232195.JavaMail.jboss@colo-br-02.atl.jboss.com>

A few of the JDK 1.4 tests in AOP are failing due to java.lang.reflect.ParameterizedType being used by the container project. while not supported in JBoss Retro. I tried adding that to Retro, but it now falls over on things like:

java.lang.reflect.Constructor.getGenericParameterTypes()[Lorg/jboss/lang/reflect/Type;
java.lang.NoSuchMethodError: java.lang.reflect.Constructor.getGenericParameterTypes()[Lorg/jboss/lang/reflect/Type;
	at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getConstructors(IntrospectionTypeInfoFactoryImpl.java:143)
	at org.jboss.reflect.plugins.ClassInfoImpl.getDeclaredConstructors(ClassInfoImpl.java:400)
	at org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getConstructors(AbstractBeanInfoFactory.java:177)
	at org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getBeanInfo(AbstractBeanInfoFactory.java:138)
	at org.jboss.config.plugins.AbstractConfiguration.getBeanInfo(AbstractConfiguration.java:75)
	at org.jboss.test.beaninfo.test.AbstractBeanInfoTest.getBeanInfo(AbstractBeanInfoTest.java:349)
	at org.jboss.test.beaninfo.test.BeanInfoUnitTestCase.testBean(BeanInfoUnitTestCase.java:153)
	at org.jboss.test.beaninfo.test.BeanInfoUnitTestCase.testBeanConstructors(BeanInfoUnitTestCase.java:73)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

So support for this needs implementing

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000190#4000190

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000190


From do-not-reply at jboss.com  Wed Jan 10 18:09:28 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Wed, 10 Jan 2007 18:09:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: What is the base
	entry point for aop remoting?
Message-ID: <33225783.1168470568118.JavaMail.jboss@colo-br-02.atl.jboss.com>

No AFAIK.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000191#4000191

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000191


From do-not-reply at jboss.com  Wed Jan 10 18:21:00 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 10 Jan 2007 18:21:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <8094415.1168471260309.JavaMail.jboss@colo-br-02.atl.jboss.com>

The remoting connector could not simply be ported to a mc bean as it does not support its configuration as a pojo. The workaround I came up with was to introduce an mc bean proxy for the connector mbean using factoryClass attribute and the existing org.jboss.mx.util.MBeanTyper factory type class:


  |      <bean name="ConnectorMBean">
  |         <!-- MBeanTyper.typeMBean(MBeanServer, ObjectName, Class iface) -->
  |         <constructor factoryClass="org.jboss.mx.util.MBeanTyper" factoryMethod="typeMBean">
  |            <parameter><inject bean="JMXKernel" property="mbeanServer"/></parameter>
  |            <parameter>jboss.remoting:service=Connector,transport=socket</parameter>
  |            <parameter>org.jboss.remoting.transport.ConnectorMBean</parameter>
  |         </constructor>
  |      </bean>
  |     <!--
  |         Add a ProfileService handler to the remoting socket connector
  |     -->
  |     <bean name="ProfileServiceInvocationHandler"
  |         class="org.jboss.aspects.remoting.AOPRemotingInvocationHandler">
  |         <install bean="ConnectorMBean" method="addInvocationHandler">
  |             <parameter>ProfileService</parameter>
  |             <parameter><this/></parameter>
  |         </install>
  |         <uninstall bean="ConnectorMBean" method="removeInvocationHandler">
  |             <parameter>ProfileService</parameter>
  |         </uninstall>
  |     </bean>
  | 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000198#4000198

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000198


From do-not-reply at jboss.com  Wed Jan 10 18:32:41 2007
From: do-not-reply at jboss.com (prassib)
Date: Wed, 10 Jan 2007 18:32:41 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Whats the easiest
	way to access JBPM data outside of the
Message-ID: <16363193.1168471961495.JavaMail.jboss@colo-br-02.atl.jboss.com>

so I figured out that jbpm-3.1.1.jar has turned on the lazy initialization in all the hibernate configs. In the old jbpm-3.0.4.jar, the lazy initialization was false in most of the hibernate configs.

I updated the HBM configs & created my modified version of jbpm-3.1.1.jar & now my DAO can successfully fetch data from the JBPM database.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000200#4000200

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000200


From do-not-reply at jboss.com  Wed Jan 10 19:56:39 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Wed, 10 Jan 2007 19:56:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: What is the base
	entry point for aop remoting?
Message-ID: <18922800.1168476999082.JavaMail.jboss@colo-br-02.atl.jboss.com>

It could be easily created and is something I want to do anyways for JNDI refactoring when I get to it.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000219#4000219

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000219


From do-not-reply at jboss.com  Wed Jan 10 23:01:42 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Wed, 10 Jan 2007 23:01:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Using
	jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
Message-ID: <10813402.1168488102046.JavaMail.jboss@colo-br-02.atl.jboss.com>

It's failing because of a known Xerces bug:

http://wiki.jboss.org/wiki/Wiki.jsp?page=JBWSFAQXercesNPE


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000250#4000250

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000250


From do-not-reply at jboss.com  Wed Jan 10 23:09:01 2007
From: do-not-reply at jboss.com (eliotmoss)
Date: Wed, 10 Jan 2007 23:09:01 -0500 (EST)
Subject: [jboss-dev-forums] [Javassist development Forum] - Re: Array access
Message-ID: <4251883.1168488541477.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have implemented an Editor for the array fetch and store bytescodes.

There is one, possibly significant, limitation at present. For object arrays,
it does not know the type. The reason is that this is not trivially
apparent from the bytecodes (unlike calls, for example, where you a
signature, and fields give their declared type).

I have begun writing the code necessary to propagate type information
(similar to what is needed in a bytecode verifier, but limited just to this
purpose), but won't have the chance to finish it for a while.

Note that this just intercepts every usage at a particular code point.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000251#4000251

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000251


From do-not-reply at jboss.com  Wed Jan 10 23:14:32 2007
From: do-not-reply at jboss.com (eliotmoss)
Date: Wed, 10 Jan 2007 23:14:32 -0500 (EST)
Subject: [jboss-dev-forums] [Javassist development Forum] - Re: insertBefore
	and replacing support for throw.
Message-ID: <29998704.1168488872512.JavaMail.jboss@colo-br-02.atl.jboss.com>

I think what you'd need is an ExprEditor for athrow
bytecodes. If done at that level, the exception object
will already have been constructed, but not yet thrown.
Presumably you could modify or replace it, or do
something else. But you'd need either to return from
the method or throw something that it either handles
locally or that is legal to throw from the method.
Easiest and safest might be to restrict it either to return
(a type-safe value) or throw an object of the original
exception class.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000254#4000254

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000254


From do-not-reply at jboss.com  Wed Jan 10 23:17:11 2007
From: do-not-reply at jboss.com (eliotmoss)
Date: Wed, 10 Jan 2007 23:17:11 -0500 (EST)
Subject: [jboss-dev-forums] [Javassist development Forum] - Re: Question
	about instrumentation with javassis
Message-ID: <17313685.1168489031565.JavaMail.jboss@colo-br-02.atl.jboss.com>

That would require a new ExprEditor, I think, one
based on line numbers. An interesting concept, and
since there is not something to replace (i.e., you
can think of it as a _point_ in code that you pass, not
one (or more) bytecodes to edit), it's would be fairly
easy to implement!

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000255#4000255

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000255


From do-not-reply at jboss.com  Thu Jan 11 00:47:38 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Thu, 11 Jan 2007 00:47:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: What is the base
	entry point for aop remoting?
Message-ID: <15003754.1168494458638.JavaMail.jboss@colo-br-02.atl.jboss.com>

I added some methods to org.jboss.aspects.remoting.Remoting to support the basics of interface based proxies, as well as externalization of the interceptors and subsystem name. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000265#4000265

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000265


From do-not-reply at jboss.com  Thu Jan 11 00:50:01 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Thu, 11 Jan 2007 00:50:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Retrowoven container project
Message-ID: <27943031.1168494601017.JavaMail.jboss@colo-br-02.atl.jboss.com>

Can you create a test for this and add a jira issue to http://jira.jboss.com/jira/browse/JBBUILD under the JBossRetro component so it does not get lost.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000269#4000269

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000269


From do-not-reply at jboss.com  Thu Jan 11 03:34:25 2007
From: do-not-reply at jboss.com (hussain_rangwala)
Date: Thu, 11 Jan 2007 03:34:25 -0500 (EST)
Subject: [jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Help
	needed on How to deploy a struts application as a portl
Message-ID: <8796990.1168504465168.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi
  I am trying to deploy a struts application as a portlet on JBoss portal 2.4.0.GA.However i m facing the following issues
1)I am not able to see my Portlet on the Jboss Portal.
2)I get the following error on the console

  | Incomplete Deployment listing:
  | 
  | --- Incompletely deployed packages ---
  | org.jboss.deployment.DeploymentInfo at b2ae7ddb { url=file:/D:/JBoss/jboss-portal-2.4.0/server/default/deploy/jboss-portal.sar/portal-wsrp.sar/portal-wsrp.jse }
  |   deployer: org.jboss.ws.server.WebServiceDeployerNestedJSE at 4a2dd4
  |   status: Deployment FAILED reason: Could not create deployment: file:/D:/JBoss/jboss-portal-2.4.0/server/default/tmp/deploy/portal-wsrp.war; - nested throwable: (org.jboss.ws.metadata.wsdl.WSDLException: WSDLException (at /wsdl:definitions/import/wsdl:definitions/import/wsdl:definitions/wsdl:types/schema/schema): faultCode=OTHER_ERROR: An error occurred trying to resolve schema referenced at 'http://www.w3.org/2001/xml.xsd', relative to 'file:/D:/JBoss/jboss-portal-2.4.0/server/default/tmp/deploy/portal-wsrp-exp.war/WEB-INF/wsdl/wsrp_v1_types.xsd'.: Cannot access imported wsdl [http://www.w3.org/2001/xml.xsd], www.w3.org: java.lang.RuntimeException: Cannot access imported wsdl [http://www.w3.org/2001/xml.xsd], www.w3.org
  | 	at org.jboss.ws.metadata.wsdl.WSDLDefinitionsFactory$WSDLLocatorImpl.getImportInputSource(WSDLDefinitionsFactory.java:310)
  | 	at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(WSDLReaderImpl.java:740)
  | 	at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(WSDLReaderImpl.java:830)
  | 	at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(WSDLReaderImpl.java:620)
  | 	at com.ibm.wsdl.xml.WSDLReaderImpl.parseTypes(WSDLReaderImpl.java:583)
  | 	at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(WSDLReaderImpl.java:302)
  | 	at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2133)
  | 	at com.ibm.wsdl.xml.WSDLReaderImpl.parseImport(WSDLReaderImpl.java:450)
  | 	at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(WSDLReaderImpl.java:294)
  | 	at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2133)
  | 	at com.ibm.wsdl.xml.WSDLReaderImpl.parseImport(WSDLReaderImpl.java:450)
  | 	at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(WSDLReaderImpl.java:294)
  | 	at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2133)
  | 	at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2125)
  | 	at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2150)
  | 	at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2171)
  | 	at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2201)
  | 	at org.jboss.ws.metadata.wsdl.WSDLDefinitionsFactory.parse(WSDLDefinitionsFactory.java:144)
  | 	at org.jboss.ws.metadata.ServiceMetaData.getWsdlDefinitions(ServiceMetaData.java:273)
  | 	at org.jboss.ws.metadata.JSR109ServerMetaDataBuilder.buildMetaData(JSR109ServerMetaDataBuilder.java:111)
  | 	at org.jboss.ws.server.WebServiceDeployerJSE.createWebServicesMetaData(WebServiceDeployerJSE.java:189)
  | 	at org.jboss.ws.server.WebServiceDeployer.create(WebServiceDeployer.java:103)
  | 	at org.jboss.ws.server.WebServiceDeployerJSE.create(WebServiceDeployerJSE.java:66)
  | 	at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
  | 	at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
  | 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
  | 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
  | 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
  | 	at $Proxy93.create(Unknown Source)
  | 	at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
  | 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
  | 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:585)
  | 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
  | 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
  | 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
  | 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
  | 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
  | 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
  | 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
  | 	at $Proxy95.deploy(Unknown Source)
  | 	at org.jboss.ws.server.WebServiceDeployerNestedJSE.create(WebServiceDeployerNestedJSE.java:102)
  | 	at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
  | 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
  | 	at org.jboss.deployment.MainDeployer.addDeployer(MainDeployer.java:368)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:585)
  | 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
  | 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
  | 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
  | 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
  | 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
  | 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
  | 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
  | 	at $Proxy98.addDeployer(Unknown Source)
  | 	at org.jboss.deployment.SubDeployerSupport.startService(SubDeployerSupport.java:124)
  | 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
  | 	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
  | 	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:585)
  | 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
  | 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
  | 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
  | 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
  | 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
  | 	at $Proxy0.start(Unknown Source)
  | 	at org.jboss.system.ServiceController.start(ServiceController.java:417)
  | 	at org.jboss.system.ServiceController.start(ServiceController.java:435)
  | 	at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:585)
  | 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
  | 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
  | 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
  | 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
  | 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
  | 	at $Proxy4.start(Unknown Source)
  | 	at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
  | 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
  | 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
  | 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:585)
  | 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
  | 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
  | 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
  | 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
  | 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
  | 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
  | 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
  | 	at $Proxy8.deploy(Unknown Source)
  | 	at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
  | 	at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
  | 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
  | 	at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
  | 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
  | 	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
  | 	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:585)
  | 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
  | 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
  | 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
  | 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
  | 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
  | 	at $Proxy0.start(Unknown Source)
  | 	at org.jboss.system.ServiceController.start(ServiceController.java:417)
  | 	at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:585)
  | 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
  | 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
  | 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
  | 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
  | 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
  | 	at $Proxy4.start(Unknown Source)
  | 	at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
  | 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
  | 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
  | 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
  | 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:585)
  | 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
  | 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
  | 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
  | 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
  | 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
  | 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
  | 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
  | 	at $Proxy5.deploy(Unknown Source)
  | 	at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
  | 	at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
  | 	at org.jboss.Main.boot(Main.java:200)
  | 	at org.jboss.Main$1.run(Main.java:464)
  | 	at java.lang.Thread.run(Thread.java:595)
  | )
  |   state: FAILED
  |   watch: file:/D:/JBoss/jboss-portal-2.4.0/server/default/deploy/jboss-portal.sar/portal-wsrp.sar/portal-wsrp.jse
  |   altDD: null
  |   lastDeployed: 1168504020879
  |   lastModified: 1168504012000
  |   mbeans:
  | 
  | org.jboss.deployment.DeploymentInfo at d5daf42b { url=file:/D:/JBoss/jboss-portal-2.4.0/server/default/deploy/SETLAppName.war }
  |   deployer: MBeanProxyExt[jboss.web:service=WebServer]
  |   status: Deployment FAILED reason: Error during deploy; - nested throwable: (javax.naming.NamingException: ejb-local-ref: 'ejb/AccountDetailsEJB', with web.xml ejb-link: 'AccountDetails' failed to resolve to an ejb with a LocalHome)
  |   state: FAILED
  |   watch: file:/D:/JBoss/jboss-portal-2.4.0/server/default/deploy/SETLAppName.war
  |   altDD: null
  |   lastDeployed: 1168504069715
  |   lastModified: 1168504070000
  |   mbeans:
  | 
  | --- MBeans waiting for other MBeans ---
  | ObjectName: jboss.web.deployment:war=SETLAppName.war,id=-707070933
  |   State: FAILED
  |   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NamingException: ejb-local-ref: 'ejb/AccountDetailsEJB', with web.xml ejb-link: 'AccountDetails' failed to resolve to an ejb with a LocalHome)
  | 
  | --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
  | ObjectName: jboss.web.deployment:war=SETLAppName.war,id=-707070933
  |   State: FAILED
  |   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NamingException: ejb-local-ref: 'ejb/AccountDetailsEJB', with web.xml ejb-link: 'AccountDetails' failed to resolve to an ejb with a LocalHome)
  | 
  | 
  | 2007-01-11 13:57:54,071 DEBUG [org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread] Notified that enabled: true
  | 2007-01-11 13:57:54,071 DEBUG [org.jboss.deployment.scanner.URLDeploymentScanner] Started jboss.deployment:type=DeploymentScanner,flavor=URL
  | 2007-01-11 13:57:54,071 DEBUG [org.jboss.system.ServiceController] Starting dependent components for: jboss.deployment:type=DeploymentScanner,flavor=URL dependent components: []
  | 2007-01-11 13:57:54,196 DEBUG [org.jboss.deployment.MainDeployer] End deployment start on package: jboss-service.xml
  | 2007-01-11 13:57:54,196 DEBUG [org.jboss.deployment.MainDeployer] Deployed package: file:/D:/JBoss/jboss-portal-2.4.0/server/default/conf/jboss-service.xml
  | 2007-01-11 13:57:54,211 DEBUG [org.jboss.web.tomcat.tc5.Tomcat5] Saw org.jboss.system.server.started notification, starting connectors
  | 2007-01-11 13:57:54,367 INFO  [org.apache.coyote.http11.Http11BaseProtocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080
  | 2007-01-11 13:57:54,460 INFO  [org.apache.jk.common.ChannelSocket] JK: ajp13 listening on /0.0.0.0:8009
  | 2007-01-11 13:57:54,476 INFO  [org.apache.jk.server.JkMain] Jk running ID=0 time=0/63  config=null
  | 2007-01-11 13:57:54,491 INFO  [org.jboss.system.server.Server] JBoss (MX MicroKernel) [4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000)] Started in 1m:12s:258ms
  | 
  | 

3)I had downloaded JBossAS+JBoss Portal (bundled version).

Kindly help me out.Thanks for your replies and ideas
Thanks & regards
Hussain


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000300#4000300

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000300


From do-not-reply at jboss.com  Thu Jan 11 04:14:57 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Thu, 11 Jan 2007 04:14:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: remove context
	sensitive menus
Message-ID: <3636593.1168506897309.JavaMail.jboss@colo-br-02.atl.jboss.com>

"david.lloyd at jboss.com" wrote : The action here is: Context menus are toast.  I'm not going to change to "Execution" for 3.x.  But I think that we should work to make "Execution" be the standard term for a process instance+token in 4.x.  
  | 

good conclusion


"david.lloyd at jboss.com" wrote : 
  | "Process" will refer to the definition, and "Process Instance" will refer to the instance (for now).  Task definitions and instances will continue to be referred to as "Task Definitions" and "Tasks", respectively.

I don't think that task definitions need to be referred to in the web console.  Or do you see a reason that i'm overlooking ?

Using the name "Task" for TaskInstance's is good, i think.  (as long as there is no reference to a task definition somewhere, which i don't think is necessary)

But taking into account all the feedback and consistency, i would keep the complete names of "Process Definition" and "Process Instance".

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000306#4000306

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000306


From do-not-reply at jboss.com  Thu Jan 11 04:22:48 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Thu, 11 Jan 2007 04:22:48 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: one central search
	page
Message-ID: <25440058.1168507368815.JavaMail.jboss@colo-br-02.atl.jboss.com>

"david.lloyd at jboss.com" wrote : Ok, I'm going with three different search pages:  Process, Process Instance, and Task.

good conclusion.

the only thing i'm still in doubt about is wether all three search pages should show up as separate items in the (fixed) menu.   currently, i'm inclined to go for 3 separate menu item links.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000307#4000307

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000307


From do-not-reply at jboss.com  Thu Jan 11 04:34:38 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Thu, 11 Jan 2007 04:34:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Move search filter
Message-ID: <11792359.1168508078309.JavaMail.jboss@colo-br-02.atl.jboss.com>

looking over all the comments i see a different conclusion:

a separate search criteria form at the top of the page.  that form should be toggelable and it should be collapsed by default so that only a link with search criteria is visible at the top of the table.

from the comments i distill two main advantages for a separate search criteria form:
1) a separate form shows its purpose better.  with the current inline search criteria fields it might not be clear to a user why these fields are their.
2) flexibility: a separate search form might give you more filter options then just text per column.  e.g. a checkbox to filter out all but the latest versions of a process definition.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000310#4000310

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000310


From do-not-reply at jboss.com  Thu Jan 11 05:10:38 2007
From: do-not-reply at jboss.com (timfox)
Date: Thu, 11 Jan 2007 05:10:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Channels no longer manage deliveries
Message-ID: <14307031.1168510238435.JavaMail.jboss@colo-br-02.atl.jboss.com>

Just a few notes on the recent changes I made.

Previously the channel itself managed the set of deliveries (i.e. refs in the process of being delivered) internally.

There is an argument that this was good from the point of view of browsing (although that is contentious) since both undelivered and delivering messages can be browsed, but it created a synchronization bottleneck on a primary execution path (acknowledgment of messages) - since on acking they had to be removed from the channel, and it also introduced a set of fiddly race conditions that we've been battling with for some considerable time - i.e. messages getting acked or cancelled before the call to handle had returned making the decision of whether to add the delivery to the list more complex and requiring further expensive synchronization.

The realisation was that, apart from maintaining the old queue browsing semantics there is no need to keep the deliveries in the channel.

In the primary use case of delivering then acking a message, the message just needs to be removed from the queue, delivered, then when it is acked, if it is non persistent it just can be forgotten about, or if it is persistent it needs to be removed from persistent storage. Nothing in the ack process requires access to the channel if the deliveries are not store in the channel. This allows acking to proceed without any channel synchronization.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000320#4000320

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000320


From do-not-reply at jboss.com  Thu Jan 11 05:21:54 2007
From: do-not-reply at jboss.com (Gurdipe)
Date: Thu, 11 Jan 2007 05:21:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Wiki] - Re: [[/wiki]] Exception
	starting filter wikiFileAccessFilter
Message-ID: <5473175.1168510914858.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi Tomek,

Sorry for the delay in getting back to you

I downloaded and installed the jportal bundle version jboss-portal-2.4.0.  When I run the run.bat command it says that I am using jboss version:

12:14:12,318 INFO  [Server] Release ID: JBoss [Zion] 4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000)

And the portal version I am using is 2.4.0

The wiki version I am using is jbosswiki-beta2-2.4-bin

PS I haven?t configured the database yet for the for jportal could that have an impact as to why I?m getting this error message.

Kind Regards

Gurdipe


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000325#4000325

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000325


From do-not-reply at jboss.com  Thu Jan 11 05:34:26 2007
From: do-not-reply at jboss.com (thomas.diesler@jboss.com)
Date: Thu, 11 Jan 2007 05:34:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Using
	jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
Message-ID: <16183083.1168511666778.JavaMail.jboss@colo-br-02.atl.jboss.com>

Put junit jar in ant/lib

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000331#4000331

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000331


From do-not-reply at jboss.com  Thu Jan 11 05:35:31 2007
From: do-not-reply at jboss.com (szimano)
Date: Thu, 11 Jan 2007 05:35:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Wiki] - Re: [[/wiki]] Exception
	starting filter wikiFileAccessFilter
Message-ID: <1025655.1168511731936.JavaMail.jboss@colo-br-02.atl.jboss.com>

You should use JEMS installer (CR1 works for sure) - bundled version of portal doesn't have EJB3.

Tomek

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000332#4000332

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000332


From do-not-reply at jboss.com  Thu Jan 11 05:49:48 2007
From: do-not-reply at jboss.com (heiko.braun@jboss.com)
Date: Thu, 11 Jan 2007 05:49:48 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Migrating the
	eventing codebase to JAX-WS
Message-ID: <8396904.1168512588643.JavaMail.jboss@colo-br-02.atl.jboss.com>

Our eventing impl. ships with prebuild endpoint implementations. Currently it uses JAXRPC deployments. We are facing a requirement to upgrade the associated WS-Addressing schema to the latest version, which would break the eventing impl. because JBossXB still lacks full wildcard support. 

IMO Investing more time in the  old binding layer is a waste of time, so i am planning to migrate the eventing codebase to leverage JAX-WS deployments beginning with JBossWS 1.2.0. 

This means that old JAXRPC deployments would'nt work anymore and need to be migrated as well. But since JAX-WS simplifies things a lot i don't see a big problem with that.

Any thoughts? Alessio? Stefano?



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000338#4000338

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000338


From do-not-reply at jboss.com  Thu Jan 11 06:05:11 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Thu, 11 Jan 2007 06:05:11 -0500 (EST)
Subject: [jboss-dev-forums] [Javassist development Forum] - Re: Array access
Message-ID: <16854005.1168513511734.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi,

I've already implemented this http://www.jboss.com/index.html?module=bb&op=viewtopic&t=98175

but would be curious to see your approach

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000355#4000355

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000355


From do-not-reply at jboss.com  Thu Jan 11 06:26:40 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Thu, 11 Jan 2007 06:26:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Whats the easiest
	way to access JBPM data outside of the
Message-ID: <25511805.1168514800343.JavaMail.jboss@colo-br-02.atl.jboss.com>

Wrong forum, use the user forum for this

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000359#4000359

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000359


From do-not-reply at jboss.com  Thu Jan 11 06:27:23 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Thu, 11 Jan 2007 06:27:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Whats the easiest
	way to access JBPM data outside of the
Message-ID: <14792364.1168514843926.JavaMail.jboss@colo-br-02.atl.jboss.com>

but thanks for adding the solution anyway :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000360#4000360

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000360


From do-not-reply at jboss.com  Thu Jan 11 06:32:54 2007
From: do-not-reply at jboss.com (heiko.braun@jboss.com)
Date: Thu, 11 Jan 2007 06:32:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Test post
Message-ID: <10860291.1168515174249.JavaMail.jboss@colo-br-02.atl.jboss.com>

Please delete

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000364#4000364

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000364


From do-not-reply at jboss.com  Thu Jan 11 08:48:26 2007
From: do-not-reply at jboss.com (anudeep20)
Date: Thu, 11 Jan 2007 08:48:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - Related to
	JBossIDE 2.0.0 EJB 3.0 Plugin
Message-ID: <12494122.1168523306126.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi,

I have written a Web Service (stateless session bean) using EJB 3.0 (using JBoss 4.0.5) using JBoss IDE release 2.0.0.
I want to view the SOAP messages using TCP/IP Monitor which are sent/received by client.

Please let me know if it possible to view SOAP messages, if yes, how do I view them.

I am not sure whether this is right forum to ask this query.

Thanks,
Deepak

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000427#4000427

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000427


From do-not-reply at jboss.com  Thu Jan 11 09:04:02 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Thu, 11 Jan 2007 09:04:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Retrowoven container project
Message-ID: <28985440.1168524242461.JavaMail.jboss@colo-br-02.atl.jboss.com>

This also needs linking with this:
http://jira.jboss.com/jira/browse/JBMICROCONT-129
I'm not sure what support Javassist has for the Java5 types?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000438#4000438

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000438


From do-not-reply at jboss.com  Thu Jan 11 09:06:43 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Thu, 11 Jan 2007 09:06:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <17349354.1168524403825.JavaMail.jboss@colo-br-02.atl.jboss.com>

This was the original intention of the KernelBus notion,
but the Service model doesn't currently have a "Joinpoint" abstraction.

I have already asked Ales to go through these actions classes to remove
the "logic" into delegate classes. I think this falls under that work?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000440#4000440

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000440


From do-not-reply at jboss.com  Thu Jan 11 09:14:00 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Thu, 11 Jan 2007 09:14:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Recent
	changes Microcontainer
Message-ID: <29006231.1168524840635.JavaMail.jboss@colo-br-02.atl.jboss.com>

isAssignable/Progression

This logic needs moving into the TypeInfo abstraction, see the TODO
I added to the code. isProgression is just a special form isAssignable.

For now I've fixed the failing tests (that don't provide a classloader)
by stealing it from the bean's class.

Builder

I've refactored the builder so the main entry point is part of the spi.
I moved the implementation into its own package so it doesn't get confused
as implementation of the metadata itself.

I also removed the use of reflection and made the impl type safe.
We have to use reflection sometimes because we don't know the types
or "joinpoints" at compile time, but using reflection bypasses compiler checks
which means you only find out it is broken at runtime, so we should avoid it
where it is possible.

Finally, the builder needs some tests. One of my "laws of programming"
is "If it isn't tested, it doesn't work" :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000445#4000445

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000445


From do-not-reply at jboss.com  Thu Jan 11 09:39:34 2007
From: do-not-reply at jboss.com (alesj)
Date: Thu, 11 Jan 2007 09:39:34 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <12753676.1168526374558.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : 
  | This was the original intention of the KernelBus notion,
  | but the Service model doesn't currently have a "Joinpoint" abstraction. 
  | 
How did you envision KernelBus notion with this issue?

"adrian at jboss.org" wrote : 
  | I have already asked Ales to go through these actions classes to remove
  | the "logic" into delegate classes. I think this falls under that work?

You mean plugable 'joinpoint' delegate, regarding what the Context is - KernelControllerC, ServiceControllerC, ...

Can you create a JIRA task for this issue with some info (assigning it to me)?

What about http://jira.jboss.com/jira/browse/JBMICROCONT-135?
This was my first understanding about Service to Kernel abstraction that we talked about. Probably not much to do in this area? I'll still take a look what else can we port to Services.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000463#4000463

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000463


From do-not-reply at jboss.com  Thu Jan 11 09:55:40 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Thu, 11 Jan 2007 09:55:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - JBWS-1259 -
	element ref and type qnames
Message-ID: <30982770.1168527340497.JavaMail.jboss@colo-br-02.atl.jboss.com>

>From the following schema: -

  |   <schema targetNamespace='http://test.jboss.org/ws/jbws1259/types' xmlns='http://www.w3.org/2001/XMLSchema' xmlns:soap11-enc='http://schemas.xmlsoap.org/soap/encoding/' xmlns:tns='http://test.jboss.org/ws/jbws1259/types' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
  | 
  |    <complexType name='Person'>
  |     <sequence>
  |      <element name='firstName' nillable='true' type='string'/>
  |      <element name='surname' nillable='true' type='string'/>
  |      <element ref='tns:comment'/>  
  |     </sequence>
  |    </complexType>
  | 
  |    <complexType name='TelephoneNumber'>
  |     <sequence>
  |      <element name='areaCode' nillable='true' type='string'/>
  |      <element name='number' nillable='true' type='string'/>
  |      <element ref='tns:comment'/>  
  |     </sequence>
  |    </complexType>
  |    
  |    <element name='comment'>
  |     <complexType>
  |      <sequence>
  |        <element name='test' type='string' />
  |        <element ref='tns:comment' />       
  |      </sequence>
  |     </complexType>
  |    </element>
  |        
  |    <element name='lookup' type='tns:Person' />    
  |    <element name='lookupResponse' type='tns:TelephoneNumber'/>
  |   </schema>

wscompile generates the following mapping for comment: -

  | <java-xml-type-mapping>
  |   <java-type>org.jboss.test.ws.jbws1259.Comment</java-type>
  |   <anonymous-type-qname xmlns:typeNS='http://test.jboss.org/ws/jbws1259/types'>typeNS:>Person>comment</anonymous-type-qname>
  |   <qname-scope>complexType</qname-scope>
  |   <variable-mapping>
  |    <java-variable-name>test</java-variable-name>
  |    <xml-element-name>test</xml-element-name>
  |   </variable-mapping>
  |   <variable-mapping>
  |    <java-variable-name>comment</java-variable-name>
  |    <xml-element-name>comment</xml-element-name>
  |   </variable-mapping>
  |  </java-xml-type-mapping>

We generate the following mapping (different qname because of the order we create the mappings): -


  |   <java-xml-type-mapping>
  |     <java-type>org.jboss.test.ws.jbws1259.Comment</java-type>
  | <anonymous-type-qname>http://test.jboss.org/ws/jbws1259/types:>TelephoneNumber>comment</anonymous-type-qname>
  |     <qname-scope>complexType</qname-scope>
  |     <variable-mapping>
  |       <java-variable-name>test</java-variable-name>
  |       <xml-element-name>test</xml-element-name>
  |     </variable-mapping>
  |     <variable-mapping>
  |       <java-variable-name>comment</java-variable-name>
  |       <xml-element-name>comment</xml-element-name>
  |     </variable-mapping>
  |   </java-xml-type-mapping>

Looking at the Web Services for J2EE specification section 7.3.2.2 I think both of these are wrong, shouldn't this be mapped according to use case 4? e.g.

<anonymous-type-qname>http://test.jboss.org/ws/jbws1259/types:>comment</anonymous-type-qname>

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000475#4000475

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000475


From do-not-reply at jboss.com  Thu Jan 11 10:12:06 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Thu, 11 Jan 2007 10:12:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <24357230.1168528326506.JavaMail.jboss@colo-br-02.atl.jboss.com>

The kernel bus hasn't really had any work done on it.

The original idea was that it would provide a generic entry point for invocations
on different contexts, e.g. Properyt/MethodJoinpoints for POJOs 
Attributre/OperationJoinpoints for JMX.

Its main use would be to replace the Dispatcher (AOP remoting) and
org.jboss.system.Registry (JBossAS's detyped invokers)
as a common entry point for named based invocations.

However, I agreed with Bill about 2 years ago that rewriting AOP and JMX
to support a common Joinpoint abstraction would be a lot of work.
If it is to be done at all it would left to a later iteration.

Scott's idea of adding a "dispatch" abstract to the context api
would work. In fact, I really want to change the BeanInfo api to support
this notion like the ClassInfo api already does (i.e. there get/set methods
on fields and invoke on methods).

The api would be more like the DynamicMBean api
where there are methods to get/set Properties/Attributes and invoke on
methods/operations with each context knowing how to do this, e.g.
ServiceControllerContext -> MBeanServer
KernelControllerContext -> Configurator (or in future as I said above BeanInfo)

This later approach essentially moves the implementation of the Bus from
a joinpoint based abstraction to a context based abstract.

The main downside is that the Bus can in principle invoke on things
that are registered directly (or indirectly via a KernelRegistryPlugin)
that don't have a context in the controller per-se, but there is already
"a hack" in the controller that knows how to make it seem these
have a context.

P.S. It is better to create JIRA issues when we have discussed the issue
and agreed what we want to do.
Forums == dicussions
JIRA == what we decided needs doing

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000485#4000485

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000485


From do-not-reply at jboss.com  Thu Jan 11 10:15:04 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Thu, 11 Jan 2007 10:15:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <19701002.1168528504442.JavaMail.jboss@colo-br-02.atl.jboss.com>

The issue you mentioned above is a holder issue for these type of issues.
i.e. in this case the missing feature is being able to "install" MBeans into POJOs
and vice-versa.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000486#4000486

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000486


From do-not-reply at jboss.com  Thu Jan 11 10:17:04 2007
From: do-not-reply at jboss.com (gregora)
Date: Thu, 11 Jan 2007 10:17:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Reporting] - BIRTIntegration
	question
Message-ID: <31258763.1168528624145.JavaMail.jboss@colo-br-02.atl.jboss.com>

i am trying to follow the instructions at http://labs.jboss.com/wiki/BIRTIntegration to include BIRT sar file in jBoss deploy directory.

the instructions say i have to:
"Download engine-BIRT-xxx.sar , where xxx is the latest version number ( At the time of this writing , it is 0.2-SNAPSHOT )"

where can i download this file from (URL would be nice)?

thank you

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000487#4000487

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000487


From do-not-reply at jboss.com  Thu Jan 11 10:56:36 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Thu, 11 Jan 2007 10:56:36 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Retrowoven container project
Message-ID: <4972415.1168530996643.JavaMail.jboss@colo-br-02.atl.jboss.com>

http://jira.jboss.com/jira/browse/JBBUILD-333

Javassist doesn't seem to have any built in support for the types, but they seem to be tied in somehow with the Signature attribute.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000499#4000499

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000499


From do-not-reply at jboss.com  Thu Jan 11 10:58:29 2007
From: do-not-reply at jboss.com (alesj)
Date: Thu, 11 Jan 2007 10:58:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <18194498.1168531109485.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | The main downside is that the Bus can in principle invoke on things
  | that are registered directly (or indirectly via a KernelRegistryPlugin)
  | that don't have a context in the controller per-se, but there is already
  | "a hack" in the controller that knows how to make it seem these
  | have a context. 
  | 
What's the 'hack'?

anonymous wrote : 
  | Forums == dicussions
  | JIRA == what we decided needs doing
  | 
;-)

"adrian at jboss.org" wrote : The issue you mentioned above is a holder issue for these type of issues.
  | i.e. in this case the missing feature is being able to "install" MBeans into POJOs
  | and vice-versa.

Yes.
I'll just change the issue Summary then.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000503#4000503

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000503


From do-not-reply at jboss.com  Thu Jan 11 12:33:15 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Thu, 11 Jan 2007 12:33:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Channels no longer manage deliveries
Message-ID: <30194587.1168536795576.JavaMail.jboss@colo-br-02.atl.jboss.com>

Thanks for the note.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000552#4000552

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000552


From do-not-reply at jboss.com  Thu Jan 11 12:54:27 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Thu, 11 Jan 2007 12:54:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Bug in transactional delivery in an MDB
Message-ID: <18889448.1168538067011.JavaMail.jboss@colo-br-02.atl.jboss.com>

:-) 

Yeah, I guess you are right...doesn't sound as cool though. 

Guys, let me know if there is anything on the JCA side that I can clarify. Sounds like we are on the right track. Now, if we can just put a muzzle on Tim, we should be all set. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000557#4000557

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000557


From do-not-reply at jboss.com  Thu Jan 11 13:27:17 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Thu, 11 Jan 2007 13:27:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Bug in transactional delivery in an MDB
Message-ID: <22181274.1168540037527.JavaMail.jboss@colo-br-02.atl.jboss.com>

Counterintuitive as it sounds, "lock and load" it is actually technically correct:

On page 21 of the "M1 Garand Manual" the procedure for preparing the M1 Garand for firing is to "pull the operating rod handle to the rear until the bolt is securely LOCKED open". Then you load the clip. This indicates that first lock and then load is indeed the order of inserting a cartridge clip into the M1.

http://en.wikipedia.org/wiki/Lock_and_load

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000565#4000565

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000565


From do-not-reply at jboss.com  Thu Jan 11 13:31:09 2007
From: do-not-reply at jboss.com (timfox)
Date: Thu, 11 Jan 2007 13:31:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Bug in transactional delivery in an MDB
Message-ID: <27831120.1168540269402.JavaMail.jboss@colo-br-02.atl.jboss.com>

"ovidiu.feodorov at jboss.com" wrote : Counterintuitive as it sounds, "lock and load" it is actually technically correct:
  | 
  | On page 21 of the "M1 Garand Manual" the procedure for preparing the M1 Garand for firing is to "pull the operating rod handle to the rear until the bolt is securely LOCKED open". Then you load the clip. This indicates that first lock and then load is indeed the order of inserting a cartridge clip into the M1.
  | 
  | http://en.wikipedia.org/wiki/Lock_and_load

Thanks for that.

Any chance of commenting on the transaction problem? ;)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000566#4000566

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000566


From do-not-reply at jboss.com  Thu Jan 11 13:35:55 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Thu, 11 Jan 2007 13:35:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Bug in transactional delivery in an MDB
Message-ID: <11769234.1168540555965.JavaMail.jboss@colo-br-02.atl.jboss.com>

Coming.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000570#4000570

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000570


From do-not-reply at jboss.com  Thu Jan 11 14:20:17 2007
From: do-not-reply at jboss.com (dwin)
Date: Thu, 11 Jan 2007 14:20:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Using
	jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
Message-ID: <26097923.1168543217317.JavaMail.jboss@colo-br-02.atl.jboss.com>

hey guys 

thanks for the help, adding junit.jar to the ant/lib fixed it (although ant already has an ant-junir.jar in its classpath already) and upgrading to ant 1.7 fixed the xerces bug.  Perhaps, you guys could put ant 1.7 as a requirement for building JBossWS on the Wiki to avoid future confusion with other developers. 

However, the tests are failing for me.

On the server side, I am regularly getting these exceptions which all basically relate to the "setProperty must be overridden by all subclasses of SOAPMessage" message.  Every test seems to fail because of these exceptions.  


  | 14:10:57,445 ERROR [SOAPFaultHelperJAXRPC] SOAP request exception
  | java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage
  |         at javax.xml.soap.SOAPMessage.setProperty(SOAPMessage.java:424)
  |         at org.jboss.ws.core.soap.SOAPMessageImpl.<init>(Unknown Source)
  |         at org.jboss.ws.core.soap.MessageFactoryImpl.createMessageInternal(Unknown Source)
  |         at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(Unknown Source)
  |         at org.jboss.ws.core.server.ServiceEndpoint.handleRequest(Unknown Source)
  |         at org.jboss.ws.core.server.ServiceEndpointManager.processSOAPRequest(Unknown Source)
  |         at org.jboss.ws.core.server.AbstractServiceEndpointServlet.doPost(Unknown Source)
  |         at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
  |         at org.jboss.ws.core.server.AbstractServiceEndpointServlet.service(Unknown Source)
  |         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  |         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
  |         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  |         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
  |         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  |         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  |         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
  |         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
  |         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
  |         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
  |         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
  |         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
  |         at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
  |         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
  |         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
  |         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
  |         at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
  |         at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
  |         at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
  |         at java.lang.Thread.run(Thread.java:619)
  | 14:10:57,477 ERROR [AbstractServiceEndpointServlet] Error processing web service request
  | java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage
  |         at javax.xml.soap.SOAPMessage.setProperty(SOAPMessage.java:424)
  |         at org.jboss.ws.core.soap.SOAPMessageImpl.<init>(Unknown Source)
  |         at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(Unknown Source)
  |         at org.jboss.ws.core.jaxrpc.SOAPFaultHelperJAXRPC.toSOAPMessage(Unknown Source)
  |         at org.jboss.ws.core.jaxrpc.SOAPFaultHelperJAXRPC.exceptionToFaultMessage(Unknown Source)
  |         at org.jboss.ws.core.jaxrpc.SOAP11BindingJAXRPC.createFaultMessageFromException(Unknown Source)
  |         at org.jboss.ws.core.CommonSOAPBinding.bindFaultMessage(Unknown Source)
  |         at org.jboss.ws.core.server.ServiceEndpoint.handleRequest(Unknown Source)
  |         at org.jboss.ws.core.server.ServiceEndpointManager.processSOAPRequest(Unknown Source)
  |         at org.jboss.ws.core.server.AbstractServiceEndpointServlet.doPost(Unknown Source)
  |         at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
  |         at org.jboss.ws.core.server.AbstractServiceEndpointServlet.service(Unknown Source)
  |         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  |         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
  |         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  |         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
  |         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  |         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  |         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
  |         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
  |         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
  |         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
  |         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
  |         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
  |         at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
  |         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
  |         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
  |         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
  |         at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
  |         at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
  |         at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
  | 

The vast majority of my unit tests fail (but not all fail, a minute portion of them do pass).  

I am guessing that my environment is not setup as the rest of the JBoss team.  

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000580#4000580

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000580


From do-not-reply at jboss.com  Thu Jan 11 15:52:07 2007
From: do-not-reply at jboss.com (batter)
Date: Thu, 11 Jan 2007 15:52:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)]
	- Re: Another way to write clustered singletons
Message-ID: <12028524.1168548727373.JavaMail.jboss@colo-br-02.atl.jboss.com>

Is there a list of jmx notifications emitted by services?  At one blog I read something like org.jboss.system.server.stopped that will tell you that the jboss kernel stopped; what are the jmx message emitted f.e. by mq and other services ?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000607#4000607

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000607


From do-not-reply at jboss.com  Thu Jan 11 17:04:08 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Thu, 11 Jan 2007 17:04:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	JBoss AOP standalone build
Message-ID: <19599431.1168553048702.JavaMail.jboss@colo-br-02.atl.jboss.com>

Done. Is there a JIRA issue I should close

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000616#4000616

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000616


From do-not-reply at jboss.com  Thu Jan 11 17:55:39 2007
From: do-not-reply at jboss.com (alesj)
Date: Thu, 11 Jan 2007 17:55:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <5257044.1168556139795.JavaMail.jboss@colo-br-02.atl.jboss.com>

I added DispatchContext interface.

  | public interface DispatchContext
  | {
  |    /**
  |     * Getter property / attribute
  |     *
  |     * @param name
  |     * @return
  |     * @throws Throwable
  |     */
  |    Object get(String name) throws Throwable;
  | 
  |    /**
  |     * Setter property / attribute
  |     *
  |     * @param property
  |     * @throws Throwable
  |     */
  |    void set(PropertyMetaData property) throws Throwable;
  | 
  |    /**
  |     * Invoke method / opration
  |     *
  |     * @param name
  |     * @param parameters
  |     * @return
  |     * @throws Throwable
  |     */
  |    Object invoke(String name, List<ParameterMetaData> parameters) throws Throwable;
  | }
  | 

This solves the issue above - should ServiceControllerContext implement it (on top of MBeanServer).

I'll go further with this abstraction.

When are we going to update the MC libs for JBoss5?
So that I update the Service --> MC part, with this and all other issues that I might resolve.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000632#4000632

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000632


From do-not-reply at jboss.com  Thu Jan 11 18:10:52 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Thu, 11 Jan 2007 18:10:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - What does
	this mean?
Message-ID: <11613049.1168557052858.JavaMail.jboss@colo-br-02.atl.jboss.com>

WARN  11-01 18:03:08,890 (AbstractTypeMetaData.java:preinstantiatedLookup:152)  -Exception in preinstantiated lookup: java.lang.NullPointerException




View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000636#4000636

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000636


From do-not-reply at jboss.com  Thu Jan 11 19:29:53 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Thu, 11 Jan 2007 19:29:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <9734904.1168561793687.JavaMail.jboss@colo-br-02.atl.jboss.com>

"alesj" wrote : 
  | When are we going to update the MC libs for JBoss5?
  | So that I update the Service --> MC part, with this and all other issues that I might resolve.
trunk is back to pulling in the mc snapshot so any working build of the mc could be pushed out as snapshot update. I'll probably do one tonight to synch up to the snapshot I'm testing the profile service with.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000651#4000651

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000651


From do-not-reply at jboss.com  Thu Jan 11 19:33:18 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Thu, 11 Jan 2007 19:33:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: What
	does this mean?
Message-ID: <11564725.1168561998314.JavaMail.jboss@colo-br-02.atl.jboss.com>

Some property get is throwing an NPE. I aded the full trace to show what the cause is.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000652#4000652

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000652


From do-not-reply at jboss.com  Thu Jan 11 21:30:09 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Thu, 11 Jan 2007 21:30:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: What
	does this mean?
Message-ID: <1053003.1168569009711.JavaMail.jboss@colo-br-02.atl.jboss.com>

do you have to have a corresponding get() method?  That could be the problem.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000677#4000677

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000677


From do-not-reply at jboss.com  Thu Jan 11 21:41:45 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Thu, 11 Jan 2007 21:41:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <2734033.1168569705906.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have started the work on that.

One neat advantage is the cms window declaration now looks like :


  | <window>
  |    <window-name>CMSWindow</window-name>
  |    <content-type>cms</content-type>
  |    <region>center</region>
  |    <height>0</height>
  |    <uri>/default/index.html</uri>
  | </window>
  | 

My first idea on the implementation was to introduce sub interfaces like


  | interface PortletWindow extends Window { ... }
  | 

But it turns out that it does not cope well with hibernate system and does not allow plugability of content very well. Also one of my initial idea is to leverage the generic portal object properties to store the window content type (portlet or cms for now).

So finally I chosed to delegate content handling to a WindowContent interface which has sub interfaces.


  | public interface Window extends PortalObject
  | {
  |    ContentType getContentType();
  |    WindowContent getContent();
  | }
  | 
  | public interface WindowContent
  | {
  | }
  | 
  | public interface PortletContent extends WindowContent
  | {
  |    String getInstanceRef();
  |    void setInstanceRef(String instanceRef);
  | }
  | 
  | public interface CMSContent extends WindowContent
  | {
  |    String getURI();
  |    void setURI(String uri);
  | }
  | 

The plug is done in the impl package which supports content handler that are responsible to create the WindowContent interfaces. The portal object container uses that to create the right WindowContent impl when it retrieves objects from the database.

At runtime now, I have extended the RenderWindowCommand in order to handle the different content types differently.

The portlet one, is mostly like the current one. The cms one extends the portlet one and changes several things :

1/ always retrieve the CMSPortletInstance instance


  |       InstanceContainer container = getControllerContext().getController().getInstanceContainer();
  |       return container.getDefinition("CMSPortletInstance");
  | 

2/ if no navigational state exists, create it and initialize it with the URI provided by the CMSContent interface


  |       //
  |       CMSContent content = (CMSContent)window.getContent();
  |       String uri = content.getURI();
  | 
  |       // Initialize the navigational state with the URI when needed
  |       PortletParametersStateString navigationalState = (PortletParametersStateString)getAttribute(NAVIGATIONAL_STATE_SCOPE, windowId);
  |       if (navigationalState == null)
  |       {
  |          navigationalState = new PortletParametersStateString();
  |          navigationalState.setValue("path", uri);
  |          setAttribute(NAVIGATIONAL_STATE_SCOPE, windowId, navigationalState);
  |       }
  | 

3/ modify the results in order to add the properties that force no decoration of the window


  |       if (o instanceof WindowResult)
  |       {
  |          WindowResult result = (WindowResult)o;
  | 
  |          //
  |          Map props = new HashMap(result.getWindowProperties());
  |          props.put("theme.windowRendererId", "emptyRenderer");
  |          props.put("theme.decorationRendererId", "emptyRenderer");
  |          props.put("theme.portletRendererId", "emptyRenderer");
  | 
  |          //
  |          result.setWindowProperties(props);
  |       }
  | 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000678#4000678

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000678


From do-not-reply at jboss.com  Thu Jan 11 21:51:28 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Thu, 11 Jan 2007 21:51:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: What
	does this mean?
Message-ID: <13675391.1168570288749.JavaMail.jboss@colo-br-02.atl.jboss.com>

Its the SecurityDeployer having a write-only ignoreSuffixes property:

AbstractBeanMetaData at 7ba65cf7{name=SecurityDeployer bean=org.jboss.deployment.security.SecurityDeployer properties=[ignoreSuffixes] constructor=null installs=[MainDeployer.addDeployer] uninstalls=[MainDeployer.removeDeployer]}
...
AbstractPropertyInfo at 1943b93b{name=ignoreSuffixes getter=null setter=ReflectMethodInfoImpl at 2b5d7e8e{name=setIgnoreSuffixes[ParameterizedClassInfo at 71fb2e0{java.util.HashSet<java.lang.String>}] return=void}}

The problem occurs at the Configurator.getPropertyGetterJoinPoint 

  | 18:49:29,115 WARN  [AbstractSetMetaData] Exception in preinstantiated lookup:
  | java.lang.NullPointerException
  |         at org.jboss.kernel.plugins.config.Configurator.getPropertyGetterJoinPoint(Configurator.java:381)
  |         at org.jboss.kernel.plugins.config.Configurator.getPropertyGetterJoinPoint(Configurator.java:360)
  |         at org.jboss.kernel.plugins.config.AbstractKernelConfigurator.getPropertyGetterJoinPoint(AbstractKernelConfigurator.java:115)
  |         at org.jboss.beans.metadata.plugins.AbstractTypeMetaData.preinstantiatedLookup(AbstractTypeMetaData.java:150)
  |         at org.jboss.beans.metadata.plugins.AbstractCollectionMetaData.getCollectionInstance(AbstractCollectionMetaData.java:208)
  |         at org.jboss.beans.metadata.plugins.AbstractCollectionMetaData.getValue(AbstractCollectionMetaData.java:85)
  |         at org.jboss.kernel.plugins.config.Configurator.getPropertySetterJoinPoint(Configurator.java:502)
  |         at org.jboss.kernel.plugins.config.Configurator.getPropertySetterJoinPoint(Configurator.java:446)
  |         at org.jboss.kernel.plugins.config.Configurator.getPropertySetterJoinPoints(Configurator.java:410)
  |         at org.jboss.kernel.plugins.config.AbstractKernelConfigurator.getPropertySetterJoinPoints(AbstractKernelConfigurator.java:120)
  |         at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:54)
  | 

Either this code or the caller needs to validate that a getter exists.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000681#4000681

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000681


From do-not-reply at jboss.com  Thu Jan 11 22:01:51 2007
From: do-not-reply at jboss.com (roy.russo@jboss.com)
Date: Thu, 11 Jan 2007 22:01:51 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <18815036.1168570911985.JavaMail.jboss@colo-br-02.atl.jboss.com>

Does this mean that the CMSPortletWindow can now display in pages other than default.default?

Can we get this done without modifying the -object.xml... or at least make it so its backward compatible?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000686#4000686

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000686


From do-not-reply at jboss.com  Fri Jan 12 01:10:31 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Fri, 12 Jan 2007 01:10:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Design of
	wsimport
Message-ID: <9669551.1168582231979.JavaMail.jboss@colo-br-02.atl.jboss.com>

I thought I would outline the plan for the JAX-WS wsdl->java tool (wsimport).

API Dependencies

Unlike the java to wsdl processing, wsimport is more isolated and has minimal API requirements from core:

  | * WSDLDefinitions - Our WSDL API is the main source, as this tool largely has 1 input, the WSDL file.
  | *  JAXB XJC API - This will be needed to generate Java types for all schema types contained in the WSDL. 
  | *  JAXB Code Model API - Since the XJC API returns instances of JCodeModel, we might as well use it for generating the remaining Java artifacts.
  | *  JDK Compiler or Javassist - We will either need to invoke the JDK compiler or build a JCodeModel to bytecode translator using javassit
  | 

Key Tasks

The following are the major tasks for implementing this tool:

  | *  Enhance WSDLDefinitions - The WSDLDefinitions API needs to be enhanced to handle the custom jaxws binding extension elements. Also WSDL11Reader needs to be enhanced to take a DOM view of all schema elements and make them available as a DOMTypes object (already exists for generation now).
  | *  Implement Binding File Processing - A JAX-WS binding file parser needs to be implemented. This binding file allows you to specify customizations that apply to the WSDL file, but without having to modify the WSDL file.
  | *  WSDL XPath Modifcation Phase - Since the binding file uses xpath expressions, we must first read the WSDL file into a DOM tree, then perform the XPath modifications to obtain the inlined version. After this the WSDL11Reader will produce a WSDLDefinitions model that contains the additional JAX-WS metadata.
  | *  Implement Core Processing Engine - This component will be responsible for interpreting the resulting metadata, and generating artifacts through JAXB XJC and the JAXB Code Model API that conform to the WSDL to Java portion of the specification. 
  | *  Implement Source and Bytecode generation - At the end of the processing phase, bytecode and optionally source will need to be written to disk. The code model API has the capability to generate the source; however, it has no direct bytecode generation capability. This would have to be implemented by us, or we could just invoke the compiler and delete the source files if they aren't desired by the user.
  | *  API - A simple API will need to be developed that takes the input options, and returns the list of artifacts generated, as well as any error or warning conditions that occurred.
  | *  Command line tool - This will be a simple command line tool that uses the above API to perform the required processing.
  | *  ANT Task - A simple ant task that offers the same options needs to be developed. As in the command line tool, it should use the above API. 
  | 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000708#4000708

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000708


From do-not-reply at jboss.com  Fri Jan 12 01:28:15 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Fri, 12 Jan 2007 01:28:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1259 -
	element ref and type qnames
Message-ID: <33293215.1168583295784.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes, you are correct, that's how it should be.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000712#4000712

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000712


From do-not-reply at jboss.com  Fri Jan 12 01:56:15 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 12 Jan 2007 01:56:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] -
	ServiceMetaData parsing needs to be pulled out of
Message-ID: <23381354.1168584975990.JavaMail.jboss@colo-br-02.atl.jboss.com>

An issue I have run into with testing deployment and editing of data sources via the profile service is that the metadata attachments associated with a service deployment is not getting parsed unti the real deployer is run during the component traversal. The ServiceDeployment attachment services is not being populated until here:


  | Thread [main] (Suspended (breakpoint at line 98 in ServiceDeploymentDeployer$ServiceDeploymentVisitor))	
  | 	ServiceDeploymentDeployer$ServiceDeploymentVisitor.deploy(DeploymentUnit, ServiceDeployment) line: 98	
  | 	ServiceDeploymentDeployer$ServiceDeploymentVisitor.deploy(DeploymentUnit, Object) line: 75	
  | 	ServiceDeploymentDeployer(AbstractRealDeployer<T>).deploy(DeploymentUnit) line: 89	
  | 	ServiceDeploymentDeployer(AbstractComponentDeployer<D,C>).deploy(DeploymentUnit) line: 72	
  | 	ServiceDeploymentDeployer(AbstractSimpleDeployer).commitDeploy(DeploymentUnit) line: 52	
  | 	DeployerWrapper.commitDeploy(DeploymentUnit) line: 165	
  | 	MainDeployerImpl.commitDeploy(Deployer, DeploymentContext, Set<DeploymentContext>) line: 557	
  | 	MainDeployerImpl.process(int, int) line: 495	
  | 	ProfileServiceBootstrap.loadProfile(String) line: 352	
  | 	ProfileServiceBootstrap.bootstrap() line: 248	
  | 	ProfileServiceBootstrap(AbstractBootstrap).run() line: 89	
  | 	ServerImpl.doStart() line: 403	
  | 	ServerImpl.start() line: 342	
  | 	Main.boot(String[]) line: 210	
  | 	Main$1.run() line: 508	
  | 	Thread.run() line: 595	
  | 

In order for the profile service to be able to build a pojo metadata model of a deployment that can be overriden by tool edits, all metadata that is subject to admin edits needs to be available before the Deployer.CLASSLOADER_DEPLOYER level of deployers have processed the deployment. The basic logic is:


  |       // Associate the raw deployment with the profile
  |       VirtualFile deployment = (raw deployment pushed by the user)
  |       AbstractDeploymentContext ctx = new AbstractDeploymentContext(deployment);
  |       profile.addDeployment(ctx, phase);
  | 
  |       // Process the base deployment to obtain the pojo metadata view
  |       mainDeployer.addDeploymentContext(ctx);
  |       Collection<DeploymentContext> ctxs = mainDeployer.process(-1, Deployer.CLASSLOADER_DEPLOYER);
  |       checkIncomplete();
  |       for (DeploymentContext d : ctxs)
  |       {
  |          // Save the pojo metadata view of the raw deployment in the profile
  |          profile.updateDeployment(d, phase);
  |       }
  | 
  |       // Determine the pojo metadata properties that can be edited
  |       Map<String, ManagedObject> mos = mainDeployer.getManagedObjects(ctx);
  |       // ManagedObject edits map an override set of pojo metadata stored in the profile via an update interceptor aspect
  | 

Subsequent deployment of deployment with edits starts at the Deployer.CLASSLOADER_DEPLOYER level of deployers, bypassing all of the metadata processing deployer as the associated DeploymentContext.getPredeterminedManagedObjects() has been populated from the admin edits store in the profile.

There is also another issue with the granularity of the Map<String, ManagedObject> for a deployment like a service descriptor. For this you have a single attachment of type ServiceDeployment which contains the ServiceMetaData for the mbeans, which contains the attributes that correspond to the ManagedProperty objects one would edit. The simplest view of a datasource would just have the jndi name and jdbc url as ManagedPropertys. What the admin tool needs to see is an inverted view where it gets a set of ManagedPropertys to edit, and these changes get mapped onto the attachment settings. While this can be setup inside the server via aspects, when a remote tool queries the properties and edits them, the aspects are lost. Essentially the same issue as entity beans becoming detached. Either I need to leverage logic similar to what hibernate does, or have an xpath like attribute in a ManagedProperty that allows the tool to submit a set of changed ManagedPropertys that can be applied to the deployment attachment attribute by navigating from the attachment root to the correct attachment property.

For now I'm going to create a fake datasource deployer to allow all of the profile service usecases to be fleshed out to finalize the apis.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000718#4000718

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000718



From do-not-reply at jboss.com  Fri Jan 12 02:30:02 2007
From: do-not-reply at jboss.com (hussain_rangwala)
Date: Fri, 12 Jan 2007 02:30:02 -0500 (EST)
Subject: [jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Help
	needed on Deploying a Struts Application as a portlet o
Message-ID: <18098338.1168587002752.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi
   I am trying to deploy a struts application as a portlet on JBoss portal 2.4.0.GA...I get this error while deploying...Any suggestions will be appreciated

  | [org.jboss.portal.core.impl.model.instance.PersistentInstanceContainer] Creating instance SETLInstanceName of portlet local.SETLAppName.SETLPortletName
  | 2007-01-12 12:40:37,426 WARN  [org.jboss.portal.core.deployment.jboss.PortletAppDeployment] Failed to create instance SETLInstanceName of portlet SETLAppName.SETLPortletName because portlet SETLAppName.SETLPortletName is not available
  | 


I have pasted the following deployment descriptors file ...
portlet.xml

  | <?xml version="1.0" encoding="UTF-8"?>
  | <portlet-app id="SETLAppName" version="1.0">
  | 
  |   <portlet id="SETLPortletName">
  |     <init-param>
  |       <name>ServletContextProvider</name>
  |       <value>org.jboss.portal.bridge.JBossServletContextProvider</value>
  |     </init-param>
  |     <init-param>
  |       <name>ViewPage</name>
  |       <value>/Login.do</value>
  |     </init-param>
  |     <init-param>
  |       <name>HelpPage</name>
  |       <value>/signIn.do</value>
  |     </init-param>
  |     <portlet-name>SETLPortletName</portlet-name>
  |     <display-name>SETL Display Name</display-name>
  |     <description>This is the SETLBAAAAAANK</description>
  |     <portlet-class>org.apache.portals.bridges.struts.StrutsPortlet</portlet-class>
  |     <expiration-cache>-1</expiration-cache>
  |     <supports>
  |       <mime-type>text/html</mime-type>
  |       <portlet-mode>VIEW</portlet-mode>
  |       <portlet-mode>HELP</portlet-mode>
  |     </supports>
  |     <portlet-info>
  |       <title>SETL Bank  Demo</title>
  |       <short-title>This is the short title</short-title>
  |       <keywords>Struts</keywords>
  |     </portlet-info>
  |   </portlet>
  | </portlet-app>
  | 

portlet-instances.xml

  | <?xml version="1.0" standalone="yes"?>
  |   <deployments>
  |   <deployment>
  |     	<instance>
  |                <instance-id>SETLInstanceName</instance-id>
  |                <portlet-ref>SETLPortletName</portlet-ref>
  |         </instance>
  |   </deployment>
  |   </deployments>
  | 

SETLAppName-object.xml

  | <?xml version="1.0" encoding="UTF-8"?>
  | <deployments>
  |    <deployment>
  |       <if-exists>overwrite</if-exists>
  |       <parent-ref>default</parent-ref>
  |       <page>
  |       <page-name>SETLAppName</page-name>
  |          <window>
  |             <window-name>SETLWindowName</window-name>
  |             <instance-ref>SETLInstanceName</instance-ref>
  |             <region>center</region>
  |             <height>1</height>
  |          </window>
  |        </page>
  |    </deployment>
  |       
  | </deployments>
  | 


struts-pages.xml

  | <pages>
  |    <portal-name>default</portal-name>
  |    <page>
  |       <page-name>SETLStruts</page-name>
  |       <window>
  |          <window-name>SETLBankWindowName</window-name>
  |          <instance-ref>/SETLAppName.SETLPortletName.SETLInstanceName</instance-ref>
  |          <region>center</region>
  |          <height>0</height>
  |       </window>
  |    </page>
  | </pages>
  | 
  | 

jboss-portlet.xml

  | <portlet-app>
  | 
  |    <portlet>
  |       <portlet-name>SETLPortletName</portlet-name>
  |       <!-- Use the specific struts container configuration -->
  |       <config-name>StrutsPortlet</config-name>
  |    </portlet>
  | </portlet-app>
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000725#4000725

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000725


From do-not-reply at jboss.com  Fri Jan 12 02:39:16 2007
From: do-not-reply at jboss.com (dimitris@jboss.org)
Date: Fri, 12 Jan 2007 02:39:16 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	JBoss AOP standalone build
Message-ID: <2971403.1168587556410.JavaMail.jboss@colo-br-02.atl.jboss.com>

No JIRA issue, thanks.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000727#4000727

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000727


From do-not-reply at jboss.com  Fri Jan 12 02:45:56 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 12 Jan 2007 02:45:56 -0500 (EST)
Subject: [jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re:
	Help needed on Deploying a Struts Application as a portl
Message-ID: <19327746.1168587956377.JavaMail.jboss@colo-br-02.atl.jboss.com>

Don't post user question in the design forums.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000730#4000730

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000730


From do-not-reply at jboss.com  Fri Jan 12 02:59:03 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Fri, 12 Jan 2007 02:59:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	Array interception needed for jboss cache
Message-ID: <23098364.1168588743664.JavaMail.jboss@colo-br-02.atl.jboss.com>

This looks great, however, it might be a good idea to detect local array references that are never passed outside of a method body.

Consider something like the following:

  | { 
  |   long[] hi = new long[n];
  |   long f = 0, g = 1;
  |   for (int i = 0; i < n; f += g, g = f - g, i++) hi = f;
  | }
  | 

Detecting this as local would prevent N method invocations and N memory barriers (potential cpu cache flushes). This would be slightly complicated to detect, but worth it IMO.

-Jason



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000733#4000733

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000733


From do-not-reply at jboss.com  Fri Jan 12 03:02:30 2007
From: do-not-reply at jboss.com (oglueck)
Date: Fri, 12 Jan 2007 03:02:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)]
	- Re: Another way to write clustered singletons
Message-ID: <1578579.1168588950525.JavaMail.jboss@colo-br-02.atl.jboss.com>

Not only such a list would be interesting. You also must filter them for instance with the DeploymentInfoNotificationFilterFactory. So one must know the possible filter cirteria.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000734#4000734

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000734


From do-not-reply at jboss.com  Fri Jan 12 03:41:43 2007
From: do-not-reply at jboss.com (dimitris@jboss.org)
Date: Fri, 12 Jan 2007 03:41:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)]
	- Re: Another way to write clustered singletons
Message-ID: <3406353.1168591303044.JavaMail.jboss@colo-br-02.atl.jboss.com>

I had made a start to document this list here:
http://wiki.jboss.org/wiki/Wiki.jsp?page=NotificationsEmittedByJBossMBeans
Obviously we need everyone to contribute to this page.

Another possibility is just configure a NotificationListener to listen for all notifications in the system, boot jboss, take the log and record what you see :)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000761#4000761

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000761


From do-not-reply at jboss.com  Fri Jan 12 03:43:42 2007
From: do-not-reply at jboss.com (thomas.diesler@jboss.com)
Date: Fri, 12 Jan 2007 03:43:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Using
	jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
Message-ID: <21284231.1168591422027.JavaMail.jboss@colo-br-02.atl.jboss.com>

You have the SUN jaxrpc impl on your classpath. Make sure javax.xml.soap.SOAPMessage is pulled from jboss-jaxrpc.jar

ant 1.6.5 works fine for us. We have however updated xerces,xalan with the versions from build/thirdparty

All tests should pass against jboss50

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000762#4000762

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000762


From do-not-reply at jboss.com  Fri Jan 12 03:46:40 2007
From: do-not-reply at jboss.com (dimitris@jboss.org)
Date: Fri, 12 Jan 2007 03:46:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)]
	- Re: Another way to write clustered singletons
Message-ID: <23208720.1168591600445.JavaMail.jboss@colo-br-02.atl.jboss.com>

And while here, I made this addition to the BarrierController:
http://jira.jboss.com/jira/browse/JBAS-3469
It could be used to control HASingletons that are fully destroyed/created when a node becomes master, rather than just started/stopped.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000766#4000766

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000766


From do-not-reply at jboss.com  Fri Jan 12 03:47:07 2007
From: do-not-reply at jboss.com (thomas.diesler@jboss.com)
Date: Fri, 12 Jan 2007 03:47:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Design of
	wsimport
Message-ID: <28671742.1168591627798.JavaMail.jboss@colo-br-02.atl.jboss.com>

Good work, thanks.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000767#4000767

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000767


From do-not-reply at jboss.com  Fri Jan 12 03:59:06 2007
From: do-not-reply at jboss.com (DivxYoda)
Date: Fri, 12 Jan 2007 03:59:06 -0500 (EST)
Subject: [jboss-dev-forums] [TODO - DEVELOPMENT] - Jboss 4.0.4RC1 and
	Multiple MySql Databases !
Message-ID: <33246245.1168592346862.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi guys,
i'd like you to help me on configuring JBOSS 4.0.4RC1 so that i can handle 2 databases. I mean : i have a Jboss Server and i want to deployed some jar for a Database 1 and others for the database 2.

Otherwise, for a single Jboss Server (4.0.4RC1), i have 2 MySql Databases : database1 and Database2.

I'd like to deploy 2 specific archives of entities ejb3. (example : jar1 and jar2).

jar1 to work with Database1, and jar2 with Database2.

Where and how should i configure my Jboss Server ?

PS : Jboss is already in use, but it has been configured for a single Database. Now i'd like to add another Database.

Thanks a lot for your help, guys.

Best Regards, Divx.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000785#4000785

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000785


From do-not-reply at jboss.com  Fri Jan 12 04:02:17 2007
From: do-not-reply at jboss.com (DivxYoda)
Date: Fri, 12 Jan 2007 04:02:17 -0500 (EST)
Subject: [jboss-dev-forums] [Other JBoss Development Design] - Jboss
	4.0.4RC1 and Multiple MySql Databases !
Message-ID: <10318650.1168592537919.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi guys,
i'd like you to help me on configuring JBOSS 4.0.4RC1 so that i can handle 2 databases. I mean : i have a Jboss Server and i want to deployed some jar for a Database 1 and others for the database 2.

Otherwise, for a single Jboss Server (4.0.4RC1), i have 2 MySql Databases : database1 and Database2.

I'd like to deploy 2 specific archives of entities ejb3. (example : jar1 and jar2).

jar1 to work with Database1, and jar2 with Database2.

Where and how should i configure my Jboss Server ?

PS : Jboss is already in use, but it has been configured for a single Database. Now i'd like to add another Database.

Thanks a lot for your help, guys.

Best Regards, Divx.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000787#4000787

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000787


From do-not-reply at jboss.com  Fri Jan 12 04:17:58 2007
From: do-not-reply at jboss.com (DivxYoda)
Date: Fri, 12 Jan 2007 04:17:58 -0500 (EST)
Subject: [jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Jboss
	4.0.4RC1 and Multiple MySql Databases !
Message-ID: <30138588.1168593478597.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi guys,
i'd like you to help me on configuring JBOSS 4.0.4RC1 so that i can handle 2 databases. I mean : i have a Jboss Server and i want to deployed some jar for a Database 1 and others for the database 2.

Otherwise, for a single Jboss Server (4.0.4RC1), i have 2 MySql Databases : database1 and Database2.

I'd like to deploy 2 specific archives of entities ejb3. (example : jar1 and jar2).

jar1 to work with Database1, and jar2 with Database2.

Where and how should i configure my Jboss Server ?

PS : Jboss is already in use, but it has been configured for a single Database. Now i'd like to add another Database.

Thanks a lot for your help, guys.

Best Regards, Divx.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000796#4000796

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000796


From do-not-reply at jboss.com  Fri Jan 12 04:19:10 2007
From: do-not-reply at jboss.com (DivxYoda)
Date: Fri, 12 Jan 2007 04:19:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of the JBoss EJB Container] - Jboss
	4.0.4RC1 and Multiple MySql Databases !
Message-ID: <7452431.1168593550066.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi guys,
i'd like you to help me on configuring JBOSS 4.0.4RC1 so that i can handle 2 databases. I mean : i have a Jboss Server and i want to deployed some jar for a Database 1 and others for the database 2.

Otherwise, for a single Jboss Server (4.0.4RC1), i have 2 MySql Databases : database1 and Database2.

I'd like to deploy 2 specific archives of entities ejb3. (example : jar1 and jar2).

jar1 to work with Database1, and jar2 with Database2.

Where and how should i configure my Jboss Server ?

PS : Jboss is already in use, but it has been configured for a single Database. Now i'd like to add another Database.

Thanks a lot for your help, guys.

Best Regards, Divx.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000798#4000798

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000798


From do-not-reply at jboss.com  Fri Jan 12 04:24:05 2007
From: do-not-reply at jboss.com (c.vidal)
Date: Fri, 12 Jan 2007 04:24:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Are you
	considering an OSGi based micro kernel ?
Message-ID: <30354315.1168593845769.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi Guys,

well sadly, I didn't have much feedback, and as I didn't have much time to work on it lately anyway, I didn't do much.

It looks like Alesj has taken the lead on the subject, that's great :)
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3997102

Regards,

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000801#4000801

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000801


From do-not-reply at jboss.com  Fri Jan 12 04:32:43 2007
From: do-not-reply at jboss.com (attonnnn)
Date: Fri, 12 Jan 2007 04:32:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - Server
	configuration not working ?
Message-ID: <28739055.1168594363041.JavaMail.jboss@colo-br-02.atl.jboss.com>

hi

i m developping on 
**
JBossIDE for Eclipse

Version: 2.0.0
Build id: 2.0.0.Beta2
**

and it seems the server launch configuration doesnt work.
I try to enable in the "JRE" tab the option "Workspace default JRE" but despite the fact i click on "apply > ok" this option is never saved.

Is there any problem with that option ? does anything else must be done before using it ? i need it to solve an "Error logged for Ant UI"...

Thanks

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000803#4000803

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000803


From do-not-reply at jboss.com  Fri Jan 12 04:47:28 2007
From: do-not-reply at jboss.com (thomas.diesler@jboss.com)
Date: Fri, 12 Jan 2007 04:47:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - doclit request
	message element name not equal to operation n
Message-ID: <13285744.1168595248814.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have 


  |   <types>
  |     <schema ...>
  |       <complexType name="paraListType">
  |         <sequence>
  |           <element name="username" type="string" nillable="true"/>
  |           <element name="password" type="string" nillable="true"/>
  |           <element name="operationName" type="string" nillable="true"/>
  |           <element name="inputXML" type="string" nillable="true"/>
  |         </sequence>
  |       </complexType>
  |       <complexType name="responseType">
  |         <sequence>
  |           <element name="result" type="string" nillable="true"/>
  |         </sequence>
  |       </complexType>
  |       <element name="paraList2" type="tns:paraListType"/>
  |       <element name="responseXML" type="tns:responseType"/>
  |     </schema>
  |   </types>
  |   <message name="attachRequest">
  |     <part name="parameters" element="ns2:paraList2"/>
  |     <part name="attachmentContents" type="xsd:string"/>
  |   </message>
  |   <message name="attachResponse">
  |     <part name="result" element="ns2:responseXML"/>
  |   </message>
  |   <portType name="TransmulatorInterface">
  |     <operation name="invokeAttach">
  |       <input message="tns:attachRequest"/>
  |       <output message="tns:attachResponse"/>
  |     </operation>
  |   </portType>
  | 

When running tools I get 


  | Exception in thread "main" org.jboss.ws.WSException: Unable to unwrap parameters, wrapper element name must match operation name. operationName=invokeAttach elementName=paraList2
  |         at org.jboss.ws.tools.WSDLToJava.appendParameters(WSDLToJava.java:421)
  |         at org.jboss.ws.tools.WSDLToJava.appendDocParameters(WSDLToJava.java:387)
  | 

Do we have a reference to the relevant part in a spec? 

Generally, we please document (read MUST) why we make assertions like this. A future version of the spec might invalidate the assertion.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000809#4000809

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000809


From do-not-reply at jboss.com  Fri Jan 12 04:55:43 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Fri, 12 Jan 2007 04:55:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: doclit
	request message element name not equal to operati
Message-ID: <1865028.1168595743180.JavaMail.jboss@colo-br-02.atl.jboss.com>

I will add the section number from the spec to the message, the following post is where I raised the actual validation requrements: -

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=97638

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000812#4000812

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000812


From do-not-reply at jboss.com  Fri Jan 12 05:41:07 2007
From: do-not-reply at jboss.com (DivxYoda)
Date: Fri, 12 Jan 2007 05:41:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Persistence on JBoss] - Jboss
	4.0.4RC1 and Multiple MySql Databases !
Message-ID: <28300795.1168598467274.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi guys,
i'd like you to help me on configuring JBOSS 4.0.4RC1 so that i can handle 2 databases. I mean : i have a Jboss Server and i want to deployed some jar for a Database 1 and others for the database 2.

Otherwise, for a single Jboss Server (4.0.4RC1), i have 2 MySql Databases : database1 and Database2.

I'd like to deploy 2 specific archives of entities ejb3. (example : jar1 and jar2).

jar1 to work with Database1, and jar2 with Database2.

Where and how should i configure my Jboss Server ?

PS : Jboss is already in use, but it has been configured for a single Database. Now i'd like to add another Database.

Thanks a lot for your help, guys.

Best Regards, Divx.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000837#4000837

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000837


From do-not-reply at jboss.com  Fri Jan 12 05:43:00 2007
From: do-not-reply at jboss.com (oglueck)
Date: Fri, 12 Jan 2007 05:43:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)]
	- Re: Another way to write clustered singletons
Message-ID: <20797790.1168598580641.JavaMail.jboss@colo-br-02.atl.jboss.com>

By the way, Dimitris, do you know how the deployment of a WAR file is notified? I must create a barrier so I can depend an MBean on it that uses a servlet deployed in that WAR file.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000838#4000838

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000838


From do-not-reply at jboss.com  Fri Jan 12 05:56:50 2007
From: do-not-reply at jboss.com (dimitris@jboss.org)
Date: Fri, 12 Jan 2007 05:56:50 -0500 (EST)
Subject: [jboss-dev-forums] [TODO - DEVELOPMENT] - Re: Jboss 4.0.4RC1 and
	Multiple MySql Databases !
Message-ID: <4086847.1168599410982.JavaMail.jboss@colo-br-02.atl.jboss.com>

You are spamming the developer forums with user questions.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000853#4000853

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000853


From do-not-reply at jboss.com  Fri Jan 12 06:35:27 2007
From: do-not-reply at jboss.com (thomas.diesler@jboss.com)
Date: Fri, 12 Jan 2007 06:35:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1260 -
	such a part must refer to an element named a
Message-ID: <28423562.1168601727681.JavaMail.jboss@colo-br-02.atl.jboss.com>

This also relates to 

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4000809#4000809

Is request message element to operation name equivalents a general requirement for doc/lit? Does the BP say anything about it?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000863#4000863

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000863


From do-not-reply at jboss.com  Fri Jan 12 07:15:31 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Fri, 12 Jan 2007 07:15:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1260 -
	such a part must refer to an element named a
Message-ID: <27860451.1168604131121.JavaMail.jboss@colo-br-02.atl.jboss.com>

BP only mentions a naming requirement for the wrappers for RPC, for document it just says that each operation must have a unique signature so that they can be identified.

It is the JAX-RPC spec and JAX-WS spec that specified requirements that must be met for an operation to be considered a wrapped operation.

>From JAX-RPC 6.4.1: -

anonymous wrote : In order to qualify as using the ?wrapper? style, an operation must fulfill the following
  | conditions:
  | ? its input and output messages (if present) must contain exactly one part;
  | ? such a part must refer to an element named after the operation;
  | ? such an element (a wrapper) must be of a complex type defined using the
  | xsd:sequence compositor and containing only elements declarations.

>From JAX-WS 2.3.1.2 this is refined slightly: -

anonymous wrote : A WSDL operation qualifies for wrapper style mapping only if the following criteria are met:
  | (i) The operation?s input and output messages (if present) each contain only a single part
  | (ii) The input message part refers to a global element declaration whose localname is equal to the operation
  | name
  | (iii) The output message part refers to a global element declaration
  | (iv) The elements referred to by the input and output message parts (henceforth referred to as wrapper
  | elements) are both complex types defined using the xsd:sequence compositor
  | (v) The wrapper elements only contain child elements, they must not contain other structures such as
  | wildcards (element or attribute), xsd:choice, substitution groups (element references are not permitted)
  | or attributes; furthermore, they must not be nillable.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000882#4000882

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000882


From do-not-reply at jboss.com  Fri Jan 12 07:31:54 2007
From: do-not-reply at jboss.com (thomas.diesler@jboss.com)
Date: Fri, 12 Jan 2007 07:31:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1260 -
	such a part must refer to an element named a
Message-ID: <18945482.1168605114760.JavaMail.jboss@colo-br-02.atl.jboss.com>

In that case a wsdl like this


  |   <types>
  |     <schema ...>
  |       <complexType name="paraListType">
  |         <sequence>
  |           <element name="username" type="string" nillable="true"/>
  |           <element name="password" type="string" nillable="true"/>
  |           <element name="operationName" type="string" nillable="true"/>
  |           <element name="inputXML" type="string" nillable="true"/>
  |         </sequence>
  |       </complexType>
  |       <complexType name="responseType">
  |         <sequence>
  |           <element name="result" type="string" nillable="true"/>
  |         </sequence>
  |       </complexType>
  |       <element name="paraList2" type="tns:paraListType"/>
  |       <element name="responseXML" type="tns:responseType"/>
  |     </schema>
  |   </types>
  |   <message name="attachRequest">
  |     <part name="parameters" element="ns2:paraList2"/>
  |     <part name="attachmentContents" type="xsd:string"/>
  |   </message>
  |   <message name="attachResponse">
  |     <part name="result" element="ns2:responseXML"/>
  |   </message>
  |   <portType name="TransmulatorInterface">
  |     <operation name="invokeAttach">
  |       <input message="tns:attachRequest"/>
  |       <output message="tns:attachResponse"/>
  |     </operation>
  |   </portType>
  | 

should work and the generated java method name should be paraList2 instead of invokeAttach.

AFAICS the requriment pertains only the the java realm and not to the abstract contract in wsdl.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000885#4000885

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000885


From do-not-reply at jboss.com  Fri Jan 12 08:09:18 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Fri, 12 Jan 2007 08:09:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1260 -
	such a part must refer to an element named a
Message-ID: <25333780.1168607358452.JavaMail.jboss@colo-br-02.atl.jboss.com>

I am not sure if that is the case, this requirement is described within chapter 2 of the JAX-RPC specification and the purpose of this chapter is to describe how to generate the service endpoint interface from the WSDL.

Also the terminology used is WSDL terminology, they are saying the element must be named after the operation not that the parameter must be named after the method.  When refering to java methods and parameters they do refer to them as methods and parameters.

So I am interpreting it as: -

When you are generating a SEI from a WSDL
 If the operation meets these requirements you can treat it as wrapped an unwrap it.

Having said that this check was one of the last checks I added just to be complete with the list of requirements in the spec so there shouldn't be a problem if it is removed.

Looking at your WSDL your message 'attachRequest' contains two message parts so based on the first requirement for a message to contain only a single part this should also be rejected so I am surprised you are not seeing that - I will have a look and see what happened to that check.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000916#4000916

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000916


From do-not-reply at jboss.com  Fri Jan 12 08:17:03 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Fri, 12 Jan 2007 08:17:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <31998062.1168607823924.JavaMail.jboss@colo-br-02.atl.jboss.com>

"alesj" wrote : 
  | What's the 'hack'?
  | 

If the controller doesn't find the context, it asks the registry if it knows the name.

Overridden method in the kernel controller:

  |    public ControllerContext getContext(Object name, ControllerState state)
  |    {
  |       ControllerContext context = super.getContext(name, state);
  |       if (context != null)
  |          return context;
  |       if (state == null || state == ControllerState.INSTALLED)
  |       {
  |          KernelRegistry registry = kernel.getRegistry();
  |          try
  |          {
  |             return registry.getEntry(name);
  |          }
  |          catch (Throwable ignored)
  |          {
  |          }
  |       }
  |       return null;
  |    }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000923#4000923

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000923


From do-not-reply at jboss.com  Fri Jan 12 08:29:52 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Fri, 12 Jan 2007 08:29:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <1717875.1168608592613.JavaMail.jboss@colo-br-02.atl.jboss.com>

"alesj" wrote : I added DispatchContext interface.
  | 

This interface is not correct.
PropertyMetaData and ParameterMetaData are POJO specific.

This interface belongs in the dependency module that knows nothing about
POJOs/services.

You need something like the DynamicMBean interface

  | Object get(String name) throws Throwable;
  | void set(String name, Object value) throws Throwable;
  | Object invoke(String name, String[] signature, Object[] parameters) throws Throwable;
  | 

The kernel/pojo context will turn this into joinpoint invocations on the context's target.

  | public Object get(String name) throws Throwable
  | {
  |       KernelController controller = (KernelController) getController();
  |       Kernel kernel = controller.getKernel();
  |       KernelConfigurator configurator = kernel.getConfigurator();
  | 
  |       Object object = getTarget();
  |       BeanInfo info = getBeanInfo();
  | 
  |       TargetttedJoinpoint joinpoint = configurator.getPropertyGetterJoinpoint(info, name);
  |       joinpoint.setTarget(object);
  |       return joinpoint.dispatch();
  | }
  | 

The service context will turn them into mbean invocations, e.g.

  | public Object get(String name) throws Throwable
  | {
  |    return serviceController.getMBeanServer().getAttribute(objectName, name);
  | }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000931#4000931

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000931


From do-not-reply at jboss.com  Fri Jan 12 08:33:59 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Fri, 12 Jan 2007 08:33:59 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <8849849.1168608839239.JavaMail.jboss@colo-br-02.atl.jboss.com>

If as I suggested before, the BeanInfo becomes the main entry point for these
operations the code would look something like:


  | public Object get(String name) throws Throwable
  | {
  |       Object object = getTarget();
  |       BeanInfo info = getBeanInfo();
  |       return info.getPropertyValue(name, object);
  | }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000933#4000933

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000933


From do-not-reply at jboss.com  Fri Jan 12 08:42:57 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Fri, 12 Jan 2007 08:42:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: What
	does this mean?
Message-ID: <10206340.1168609377241.JavaMail.jboss@colo-br-02.atl.jboss.com>

"scott.stark at jboss.org" wrote : 
  | Either this code or the caller needs to validate that a getter exists.
  | 

The code should be:

  |       JoinpointFactory jpf = info.getBeanInfo().getJoinpointFactory();
  |       MethodInfo minfo = info.getGetter();
  | +      if (minfo == null)
  | +         throw new IllegalArgumentException("Property is write only");
  |       return getMethodJoinpoint(null, jpf, minfo.getName(), null, null);
  | 

The preinstantiated lookup should be using a different mechanism
that first checks whether the property is readable
rather than logging a warning when it is not.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000939#4000939

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000939


From do-not-reply at jboss.com  Fri Jan 12 08:50:08 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Fri, 12 Jan 2007 08:50:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: What
	does this mean?
Message-ID: <16436014.1168609808076.JavaMail.jboss@colo-br-02.atl.jboss.com>

I raised the following issues:
http://jira.jboss.com/jira/browse/JBMICROCONT-140
http://jira.jboss.com/jira/browse/JBMICROCONT-141

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000942#4000942

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000942


From do-not-reply at jboss.com  Fri Jan 12 09:18:15 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Fri, 12 Jan 2007 09:18:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1260 -
	such a part must refer to an element named a
Message-ID: <31490963.1168611495219.JavaMail.jboss@colo-br-02.atl.jboss.com>

I can't reproduce the error you are seeing if my WSDL contains messages with 2 parts, instead I get the following error reported: -

anonymous wrote : 
  | [junit] org.jboss.ws.WSException: Only Request-Only and Request-Response MEPs are allowed
  |     [junit]     at org.jboss.ws.metadata.wsdl.WSDLUtils.getWsdl11Input(WSDLUtils.java:885)
  |     [junit]     at org.jboss.ws.tools.WSDLToJava.appendMethods(WSDLToJava.java:287)
  |     [junit]     at org.jboss.ws.tools.WSDLToJava.createSEIFile(WSDLToJava.java:588)
  |     [junit]     at org.jboss.ws.tools.WSDLToJava.createSEI(WSDLToJava.java:618)
  |     [junit]     at org.jboss.ws.tools.WSDLToJava.generateSEI(WSDLToJava.java:187)
  |     [junit]     at org.jboss.ws.tools.helpers.ToolsHelper.handleWSDLToJavaGeneration(ToolsHelper.java:304)
  |     [junit]     at org.jboss.ws.tools.WSTools.process(WSTools.java:138)
  | 

I think this check was part of some refactoring that happened on trunk.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000953#4000953

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000953


From do-not-reply at jboss.com  Fri Jan 12 10:41:56 2007
From: do-not-reply at jboss.com (timfox)
Date: Fri, 12 Jan 2007 10:41:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of the JBoss EJB Container] - Message
	redelivery from non transacted MDBs
Message-ID: <290488.1168616516505.JavaMail.jboss@colo-br-02.atl.jboss.com>

Using JBoss-4.0.5.GA.

If I throw a RuntimeException from inside the onMessage method of a MDB set to tx NotSupported, then redelivery does not occur.

The EJB2 spec is pretty silent about what should occur (17.6.3.1, 17.6.3.2) and only really says that redeliver should occur if the onMessage is running in a tx context.

For the analogous case of a RuntimeException thrown from a non MDB (straightforward jms MessageListener) onMessage method with ack mode of AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE, then the JMS 1.1 spec is pretty clear that redelivery should be immediately attempted.

It seems to me that the current MDB container behaviour is a bit weird, since you end up with messages remaining unacked in the connection consumers session until the mdb container is redeployed.

A better and more intuitive behaviour IMHO would be to attempt to redeliver the message x times then put it in the DLQ. Then at least the user can do something with it. Otherwise it is effectively lost.

I would have thought that if the EJB spec is silent about one aspect of MDB  delivery behaviour we should fall back to what's specified in the JMS spec, rather than do something completely different.

Or perhaps there's a good reason why redelivery isn't attempted in this situation that I haven't thought about.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001004#4001004

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001004


From do-not-reply at jboss.com  Fri Jan 12 10:52:29 2007
From: do-not-reply at jboss.com (timfox)
Date: Fri, 12 Jan 2007 10:52:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of the JBoss EJB Container] - Re:
	Message redelivery from non transacted MDBs
Message-ID: <24934262.1168617149608.JavaMail.jboss@colo-br-02.atl.jboss.com>

One other thing to note is that our redelivery behaviour differs from our competitors:
http://edocs.bea.com/wls/docs81/ejb/message_beans.html

The actual reason redelivery doesn't occur is that the MDB container which sits between the JMS provider and the customer provide onMessage implementation, catches the RuntimeException and wraps it in an EJBException.

So when it gets to the JMS provider it's no longer a RuntimeException and the JMS provider won't redeliver the message (JMS says any RuntimeExceptions should cause redelivery).



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001006#4001006

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001006


From do-not-reply at jboss.com  Fri Jan 12 11:55:54 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Fri, 12 Jan 2007 11:55:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of the JBoss EJB Container] - Re:
	Message redelivery from non transacted MDBs
Message-ID: <3776354.1168620954317.JavaMail.jboss@colo-br-02.atl.jboss.com>

Correct. 

Technically, there is nothing to *force* us to redeliver the message in the case of a non specified transaction context (ie BMT, CMT NotSupported). All specs are at best ambiguous, and at worst, completely ingnorant of this subject. However, a customer requirement (not supported by me mind you) came up and this *feature* was added to the JCA adapter. This change initially was added in HEAD and then aggressively, and stupidly might I add, backported to multiple branches on the 4.x line. 

After the dust cleared I went back in HEAD and reworked some of it to be more performant and easier to understand. I haven't backported these changes yet. 

So, the long and short of it:

If you want redelivery in the case of BMT, CMT NotSupported you 

a) Have to use JCA
b) Are encouraged, if at all possible, to use the current implementation in HEAD. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001033#4001033

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001033


From do-not-reply at jboss.com  Fri Jan 12 12:11:04 2007
From: do-not-reply at jboss.com (batter)
Date: Fri, 12 Jan 2007 12:11:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)]
	- Re: Another way to write clustered singletons
Message-ID: <26979630.1168621864496.JavaMail.jboss@colo-br-02.atl.jboss.com>

"oglueck" wrote : Not only such a list would be interesting. You also must filter them for instance with the DeploymentInfoNotificationFilterFactory. So one must know the possible filter cirteria.

Definitely; I am trying to add a dependency on the MQ service being started so I know f.e. that my queues and topics are deployed.  Finally ran into this barrier discussion and am now playing with using that and then filtering on 'some' mq notification.  For the time being I wrote my own bean and playing with it; if people leave me alone today I might do that NotificationListener thingy Dimitris suggested :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001038#4001038

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001038


From do-not-reply at jboss.com  Fri Jan 12 12:12:50 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Fri, 12 Jan 2007 12:12:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1260 -
	such a part must refer to an element named a
Message-ID: <11931040.1168621970883.JavaMail.jboss@colo-br-02.atl.jboss.com>

"thomas.diesler at jboss.com" wrote : In that case a wsdl like this
  | 
  | should work and the generated java method name should be paraList2 instead of invokeAttach.
  | 

Thats incorrect. The generated java method name (unless customized) always matches the operation name, it never matches the element name. Also it does not adhere to the wrapped convention so it must be treated as a bare parameter style service.

Also, this WSDL violates BP 1.0 because it uses "type" on the part definition for a document/literal web service. It must be element.


  | <part name="attachmentContents" type="xsd:string"/>
  | 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001040#4001040

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001040


From do-not-reply at jboss.com  Fri Jan 12 12:17:10 2007
From: do-not-reply at jboss.com (oglueck)
Date: Fri, 12 Jan 2007 12:17:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)]
	- Re: Another way to write clustered singletons
Message-ID: <31767995.1168622230673.JavaMail.jboss@colo-br-02.atl.jboss.com>

You can also try and filter with MBeanServerNotificationFilterFactory for MBean registration notifications. See
http://docs.jboss.org/jbossas/javadoc/4.0.5/system/org/jboss/system/filterfactory/MBeanServerNotificationFilterFactory.html

I am trying to figure out with that one when Axis has registered its JMX bean.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001042#4001042

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001042


From do-not-reply at jboss.com  Fri Jan 12 12:47:44 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Fri, 12 Jan 2007 12:47:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1260 -
	such a part must refer to an element named a
Message-ID: <22948922.1168624064799.JavaMail.jboss@colo-br-02.atl.jboss.com>

"thomas.diesler at jboss.com" wrote : In that case a wsdl like this
  | AFAICS the requriment pertains only the the java realm and not to the abstract contract in wsdl.

This is not in the BP since it only governs existing specifications namely WSDL 1.1, which does not have a mechanism to express this convention. 

The whole reason for the wrapped convention, is to fix the RPC style in WSDL 1.1 by overlaying the RPC requirements on top of a document/literal service. (This is the source of the operation name match requirement). So the intention is that a server component using the wrapped convention would provide hints to any client so that it would use this style as well. However since a WSDL extension was not introduced, the service still works with any thing that understands document/literal (since it is just a convention). So, by design, the wrapped convention is more restrictive than a normal document/literal bare service.

The problem was fully addressed in WSDL 2.0, where the wrapped convention became the new RPC style. So, in WSDL 2.0, all of these rules and restrictions you see are officially part of the spec. 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001051#4001051

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001051


From do-not-reply at jboss.com  Fri Jan 12 12:48:17 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 12 Jan 2007 12:48:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	ServiceMetaData parsing needs to be pulled out of Servic
Message-ID: <31727782.1168624097120.JavaMail.jboss@colo-br-02.atl.jboss.com>

After the mc call this morning I realize that the problem with building the stable metadata view that the ManagedObject view maps to is that the ServiceMetaData is not what should be used. Adrian pointed out that all we have today is the dom model of the *-ds.xml in terms of an implementation independent model of a datasource. I'll spend a litte time on trying to use that, otherwise I will create a fake datasource deployer with a simple pojo model.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001052#4001052

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001052


From do-not-reply at jboss.com  Fri Jan 12 12:52:53 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Fri, 12 Jan 2007 12:52:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1260 -
	such a part must refer to an element named a
Message-ID: <25252033.1168624373015.JavaMail.jboss@colo-br-02.atl.jboss.com>

"darran.lofthouse at jboss.com" wrote : I am not sure if that is the case, this at your WSDL your message 'attachRequest' contains two message parts so based on the first requirement for a message to contain only a single part this should also be rejected so I am surprised you are not seeing that - I will have a look and see what happened to that check.
  | 

The rule is that it must contain only one part that is bound to body of the message. The service can still contain additional parts if the extra parts are bound to an attachment or a header.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001054#4001054

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001054


From do-not-reply at jboss.com  Fri Jan 12 13:04:34 2007
From: do-not-reply at jboss.com (cococ)
Date: Fri, 12 Jan 2007 13:04:34 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss/Tomcat Integration] - Re:
	Webapp under root context eg. http://localhost/
Message-ID: <16491405.1168625074219.JavaMail.jboss@colo-br-02.atl.jboss.com>

There are several ways to do this.

If your webapp is part of an EAR file, then the webapp's context root can be defined in the EAR's META-INF/application.xml file (see: http://docs.jboss.org/jbossas/guides/webguide/r2/en/html_single/#d0e777).

<application>
  |   ...
  |   <module>
  |     <web>
  |      <web-uri>my.war</web-uri>
  |      <context-root>m</context-root>
  |     </web>
  |   </module>
  | </application>
  | 

If your webapp is not packaged in an EAR, but deployed as just a webapp, then the context-root can be defined in WEB-INF/jboss-web.xml of the webapp.

<jboss-web>
  |   <context-root>my</context-root>
  | </jboss-web>
  | 

You don't typically deploy a webapp inside of a SAR since this is a service archive (at least I'm not familiar with that practice), either wrap the webapp in an EAR, or deploy it singularly.


Christopher

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001059#4001059

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001059


From do-not-reply at jboss.com  Fri Jan 12 14:49:28 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Fri, 12 Jan 2007 14:49:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Future
	direction and state of the WSDLDefinitions API
Message-ID: <5043941.1168631368578.JavaMail.jboss@colo-br-02.atl.jboss.com>

Part of the JAX-WS work I did involved revamping the WSDLDefinitions API to be more accurate with WSDL 1.1 (there were many problems with the previous design that made it impossible to represent the mappings required by JAX-WS).  I also brought the API inline with the current version of the WSDL 2.0, as many elements are missing.  So basically the current version in trunk is highly focused towards WSDL 2.0.  The reason for this is that we now only have one component that generates the model (WSDLGenerator), and the resulting model is capable of serializing to both 1.1 and 2.0 (as soon as the 2.0 writer is fully implemented[further down the roadmap]). This allows for interesting applications. For example, it would theoretically be possible to provide a conversion utility that would read a WSDL 1.1 file, and produce a WSDL 2.0 file by just reading it using WSDL11Reader, and writing it using the final WSDL20Writer. There is only one major difference that has to be accounted for, and that is the change of the RPC style in WSDL 2.0 to be the document/literal wrapped style. So basically the difference here is that there is no equivalent of a message in WSDL 2.0, which means that everything has to be expressed using schema. Therefore anything that used the RPC style in WSDL 1.1 would have to have its parts converted to a schema complexType before it could be serialized correctly.

So when using this API, everything operates mainly from the 2.0 perspective. So I would recommend that anyone doing work on this API, or using it take a brief look at WSDL 2.0 spec to get an idea of how it should be used.  All of the metadata builders can be looked at for examples as well. 

There also is some information that is needed for WSDL 1.1 that can't be expressed in 2.0, so in order to have a model that is capable of being serialized to both, you need to provide the extra 1.1 information, which would be ignored when producing a WSDL 2.0 document. For example, since WSDL 2.0 does not have a message component, the message name, and the part names are not used.  So in this example, the WSDLInteraceMessageReference object (which is a WSDL 2.0 concept) contains additional properties for the WSDL 1.1 message name, and the part name. 

As mentioned above the RPC style in WSDL 2.0 is basically document/literal wrapped. This means there is conceptionally only once "part" as you think of it in WSDL 1.1 terms, and that one part maps to a complexType that contains the multiple "parameters". So to support serialization to 1.1 RPC style, there is the notion of a WSDLRPCPart. This is capable of being mapped to both. For WSDL 1.1 this would translate to a message part element, and for WSDL 2.0 this is just extra information about the schema element that represents the "part". 

Another difference is that headers were designed to be binding only, and are not part of the formal abstract contract which is represented in schema. So when using headers (or attachments) they must be represented directly on the binding API elements of WSDLDefinitions, and not the WSDLInterface. This is actually a loss of information in WSDL 2.0 that prevents determining whether a header is implicit or explicit. In WSDL 1.1 if the header was part of the message containing the body parts, it was assumed that the resulting java code should have this header bound to a parameter(explicit). If it was in a different message it was assumed to not be part of the main contract, and thus not bound to a java parameter, and instead up to a handler or the like to provide it. So in order to allow this information to be maintained when serializing/deserializing to WSDL 1.1 set/getIncludeInSignature is used on the WSDLSOAPHeader to indicate wheter or not it is implicit or explicit.

There are a couple of things that still need to be improved. Originally the WSDLDefinitions API was designed to represent a single WSDL 2.0 file, so everything used NCNames. It has since been update to be a final infoset, and uses QNames, but the NCNames are still used in some places. These should all be removed. Also the writers should be updated to use either DOM, JDOM or StAX for writing the document. Currently they serialize everything on their own, which is a potential problem with character escaping. Also the code would be simpler and more maintainable if it relied on a framework to do the heavy lifting. Also everything is ran through DOM to pretty print the output anyway, so this would eliminate an extra parse phase.

-Jason





View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001087#4001087

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001087



From do-not-reply at jboss.com  Fri Jan 12 14:58:40 2007
From: do-not-reply at jboss.com (alesj)
Date: Fri, 12 Jan 2007 14:58:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Are you
	considering an OSGi based micro kernel ?
Message-ID: <18240382.1168631920316.JavaMail.jboss@colo-br-02.atl.jboss.com>

"c.vidal" wrote : 
  | It looks like Alesj has taken the lead on the subject, that's great :)
  | 

You are always welcome to help:
 - http://anonsvn.jboss.org/repos/jbossas/projects/osgi/

It is still a work in progress, still a few things to figure out.
And the whole testing environment.

Rgds, Ales

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001089#4001089

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001089


From do-not-reply at jboss.com  Fri Jan 12 15:11:03 2007
From: do-not-reply at jboss.com (alesj)
Date: Fri, 12 Jan 2007 15:11:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <8153375.1168632663997.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : 
  | This interface is not correct.
  | PropertyMetaData and ParameterMetaData are POJO specific.
  | 
  | This interface belongs in the dependency module that knows nothing about
  | POJOs/services.
  | 
  | You need something like the DynamicMBean interface
  | 
  |   | Object get(String name) throws Throwable;
  |   | void set(String name, Object value) throws Throwable;
  |   | Object invoke(String name, String[] signature, Object[] parameters) throws Throwable;
  |   | 
  | 

Yes.
I tried with this sort of impl.
But I saw that in order to get the actual parameter values and their (String) types I needed a lot of target info - beanInfo, methodInfo, classloader, ... Which would bloat the interface.
Is the target (Service, ...) always availabe to me for this sort of info?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001096#4001096

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001096


From do-not-reply at jboss.com  Fri Jan 12 16:08:18 2007
From: do-not-reply at jboss.com (dwin)
Date: Fri, 12 Jan 2007 16:08:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Using
	jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
Message-ID: <32373967.1168636098720.JavaMail.jboss@colo-br-02.atl.jboss.com>

thanks, 

another issue that I had was a class not found exception of ParameterMode but that was fixed when I manually moved over the jboss-rpc.jar to the third party lib folder and the lib folder for the app server.

Not all tests passed but the vast majority of them did (99% to be exact) 

Just a question, when do you guys think there will be a stable binary release (beyond beta) for JBossWS (JAXWS) with JBoss 4.0.5? 

Also, there isn't much documentation for using JAXWS with wstools.   I am trying to decipher it whether wstool supports wsimport and wsgen (like the GlassFish implementation) but I am guessing its not entirely there yet.   

again, thanks for the help

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001108#4001108

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001108


From do-not-reply at jboss.com  Fri Jan 12 16:37:35 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Fri, 12 Jan 2007 16:37:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	ServiceMetaData parsing needs to be pulled out of Servic
Message-ID: <31536123.1168637855360.JavaMail.jboss@colo-br-02.atl.jboss.com>

           String securityDomain = 
NOT_SET"/>
         
     



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001117#4001117

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001117


From do-not-reply at jboss.com  Fri Jan 12 16:42:05 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Fri, 12 Jan 2007 16:42:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	ServiceMetaData parsing needs to be pulled out of Servic
Message-ID: <19697261.1168638125099.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : What the admin tool needs to see is an inverted view where it gets a set of ManagedPropertys to edit, and these changes get mapped onto the attachment settings. While this can be setup inside the server via aspects, when a remote tool queries the properties and edits them, the aspects are lost. Essentially the same issue as entity beans becoming detached. Either I need to leverage logic similar to what hibernate does, or have an xpath like attribute in a ManagedProperty that allows the tool to submit a set of changed ManagedPropertys that can be applied to the deployment attachment attribute by navigating from the attachment root to the correct attachment property. 

Ok.  I'm commenting based on reading just this thread and looking a bit at your code in org.jboss.test.profileservice.p0, so don't be too annoyed if I'm missing something....


IMO, an admin tool is going to need a complete structural view of  ManagedObjects/DeploymentContexts to be able to display a generic UI to the user.  For example, the UI might look like this:


  | <DeploymentContext name="MyApp.ear">
  |       <!-- default security domain for ear -->
  |       <ManagedObject name="Security">
  |           <ManagedProperty name="SecurityDomain" value="other"/>
  |       </ManagedObject>
  |       <DeploymentContext name="MyEjb.jar">
  |          <!-- default security domain for application -->
  |          <ManagedObject name="Security">
  |              <ManagedProperty name="SecurityDomain" value="UNMODIFIED"/>
  |          </ManagedObject>
  |          <DeploymentContext name="jboss.ejb:ejbName=BankDAOBean">
  |             <!-- default security domain for application -->
  |             <ManagedObject name="Security">
  |                 <ManagedProperty name="SecurityDomain" value="UNMODIFIED"/>
  |             </ManagedObject>
  |          </DeploymentContext>
  |       </DeploymentContext>
  | </DeploymentContext>
  | 

Since the admin tool would have knowledge of structure, why not have a set of management deployers or another specific management() callback on the Deployer SPI?  The admin tool would send back a list of ManagedProperties with structural information attached.

Lets use the modification of a security-domain of an EJB on the above as an example.  Admin tool would change the name of the ManagedProperty and send this back to the MainDeployer:


  |  
  | <DeploymentContext name="MyApp.ear">
  |       <DeploymentContext name="MyEjb.jar">
  |          <DeploymentContext name="jboss.ejb:ejbName=BankDAOBean">
  |             <ManagedObject name="Security">
  |                 <ManagedProperty name="SecurityDomain" value="CorporateDomain"/>
  |             </ManagedObject>
  |          </DeploymentContext>
  |       </DeploymentContext>
  | </DeploymentContext>
  | 
  | 

MainDeployer would navigate to the specific DeploymentContext and push the Update object to a set of deployers.  Each deployer decides what it wants to do with the update.  The EjbSecurityDeployer would be in this list.  It would take the change, lookup the specific SecurityDomain and reset it on the EJBContainer.  

The maindeployer would also attach the Update to the  DeploymentContext.  If an Update with the same ManagedObject and Property is there, the old one is removed.  If the UPdate is persistable, the mainDeployer adds it to the Profile.

At server restart, the EjbDeployer would merge any persisted Updates into its metamodel.

Now what if the admin tool updated the EAR's default security domain?


  |  
  | <DeploymentContext name="MyApp.ear">
  |    <ManagedObject name="Security">
  |       <ManagedProperty name="SecurityDomain" value="CorporateDomain"/>
  |    </ManagedObject>
  | </DeploymentContext>
  | 
  | 

The way this would work would be that the MainDeployer would see that there are child DeploymentContexts and try to "deploy" the change to each and every child context.  The EjbSecurityDeployer would do something like this:


  | {
  |    public void managementEvent(ManagedUpdate update, DeploymentContext context) {
  |       if (update.getName() != "Security) return;
  | 
  |       boolean isThisContextUpdated = update.getDeploymentContext == context;
  | 
  |       EJBDeployment deployment = context.getMetaData(EJBDeployment.class);
  |       if (deployment != null) 
  |       {
  |          // we are at the "ejb.jar" context deployment level.
  |          deployment.setSecurityDomain(update.getProperty("security-domain").getValue());
  |          return;
  |       }
  | 
  |       EJBContainer container = context.getMetaData(EJBContainer.class);
  |       if (container != null) {
  |         String newSecurityDomain = update.getProperty("security-domain").getValue();
  |         // we are at the EJBContainer level
  | 
  |         if (isThisContextUpdated)
  |         {
  |            // the admin tool has updated the same DeploymentContext as the EJBContainer
  |            container.updateSecurityDomain(newSecurityDomain);
  |         }
  |         else
  |         {
  |            // the admin tool has updated the ejb.jar context or the EAR's context, so only
  |            // set if our securitydomain is null
  |            if (container.getSecurityDomain() == null) container.updateSecurityDomain(newSecurityDomain);
  |         }
  |      }
  | }
  | 
 
 
        


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001119#4001119

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001119


From do-not-reply at jboss.com  Fri Jan 12 16:44:52 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Fri, 12 Jan 2007 16:44:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	ServiceMetaData parsing needs to be pulled out of Servic
Message-ID: <10599210.1168638292410.JavaMail.jboss@colo-br-02.atl.jboss.com>

What this model does is instead of trying to handle everything generically it pushes management to a set of pluggable "deployers" that can either be generic themselves, or be specific to a particular component type.  This gives the developer a lot of flexibility in handling ManagedObjects.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001121#4001121

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001121


From do-not-reply at jboss.com  Fri Jan 12 17:00:50 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 12 Jan 2007 17:00:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	ServiceMetaData parsing needs to be pulled out of Servic
Message-ID: <14232304.1168639250100.JavaMail.jboss@colo-br-02.atl.jboss.com>

We already have a set of pluggable deployers with a pojo view of the deployment model. The callback to deployers is the ManagedObjectBuilder that a deployer can implement to provide its ManagedObject view. 

This morning we talked about the need for a structural view of the deployment that the ManagementView needs to expose. With that the api is largely what you are talking about. We also need a deployment type view to query for the managed objects for deployments of a given type.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001127#4001127

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001127


From do-not-reply at jboss.com  Fri Jan 12 17:50:02 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Fri, 12 Jan 2007 17:50:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - JBWS-1452 -
	WSDL To Java, Array unwrapping.
Message-ID: <26289660.1168642202500.JavaMail.jboss@colo-br-02.atl.jboss.com>

Could someone please confirm for which WSDL styles we should be unwrapping arrays when an unbounded element is the only element in a complex type.

The code that handles the unwrapping is currently wrapped with this: -

if (! Constants.DOCUMENT_LITERAL.equals(style))
  | {
  |   ...
  | }

So perform the unwrapping for all styles except document/literal.  Shouldn't this be the other way round?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001137#4001137

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001137


From do-not-reply at jboss.com  Fri Jan 12 19:06:19 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Fri, 12 Jan 2007 19:06:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1452 -
	WSDL To Java, Array unwrapping.
Message-ID: <17403614.1168646780036.JavaMail.jboss@colo-br-02.atl.jboss.com>

This code only applies to the root level parameters on the SEI, unwrapping of arrays is also done in XSD processing. The reason it applies to rpc was to make arrays simpler from a client perspective. So the wsdl produced by java-wsdl for foo(String[] blah) would generate the same method signature on the client.

The reason its disabled for document/literal is because array unwrapping on the parameter level for a document/literal wrapped message is not needed. I'm not sure why bare was prevented as well, most likely was unintentional. I guess the reason no one complained is that using an array parameter for a bare service is probably rare.

-Jason

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001178#4001178

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001178


From do-not-reply at jboss.com  Sat Jan 13 06:10:42 2007
From: do-not-reply at jboss.com (timfox)
Date: Sat, 13 Jan 2007 06:10:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <6958923.1168686642453.JavaMail.jboss@colo-br-02.atl.jboss.com>

Weston - sorry to bug you again.

I'm using the JCA inflow invoker-proxy-binding in JBoss-4.0.5.GA for MDBs, and I'm using JBoss Messaging as the JMS provider.

I have the following trivial MDB:


  | public class MDBExample implements MessageDrivenBean, MessageListener
  | {
  |    public void onMessage(Message m)
  |    {	 
  |           System.out.println("got message " + m);      
  |    }
  | 
  |     public void ejbCreate()
  |     {
  |     }
  | 
  |     public void ejbRemove()
  |     {
  |     }
  | }
  | 
  | <ejb-jar>
  |     <enterprise-beans>
  |         <message-driven>
  |             <ejb-name>MDBExample</ejb-name>
  |             <ejb-class>org.jboss.example.jms.mdb.MDBExample</ejb-class>
  |             <transaction-type>Container</transaction-type>
  |             <message-driven-destination>
  |                <destination-type>javax.jms.Queue</destination-type>
  |             </message-driven-destination>
  |         </message-driven>
  |     </enterprise-beans>
  | 
  |  <assembly-descriptor>
  |         <container-transaction>
  |             <method>
  |                 <ejb-name>MDBExample</ejb-name>
  |                 <method-name>*</method-name>
  |             </method>
  |             <trans-attribute>Required</trans-attribute>
  |         </container-transaction>
  |     </assembly-descriptor>
  | </ejb-jar>
  | 

I sent a message, and it all works fine, the message gets consumed and acked.

I then change the trans-attribute to "NotSupported", so the onMessage should not be run in a tx context, and send a message again, and I get:


  | 10:59:37,437 ERROR [JmsServerSession] Failed to commit session transaction
  | javax.jms.TransactionInProgressException: Cannot call commit on an XA session
  |         at org.jboss.jms.client.container.TransactionAspect.handleCommit(TransactionAspect.java:97)
  |         at org.jboss.aop.advice.org.jboss.jms.client.container.TransactionAspect14.invoke(TransactionAspect14.java)
  |         at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.
  | java)
  |         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:182)
  |         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
  |         at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.
  | java)
  |         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
  |         at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.
  | java)
  |         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
  |         at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.
  | java)
  |         at org.jboss.jms.client.delegate.ClientSessionDelegate.commit(ClientSessionDelegate.java)
  |         at org.jboss.jms.client.JBossSession.commit(JBossSession.java:165)
  |         at org.jboss.resource.adapter.jms.inflow.JmsServerSession$LocalDemarcationStrategy.end(JmsServerSession.java:341)
  |         at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:260)
  |         at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
  |         at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
  |         at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
  |         at java.lang.Thread.run(Thread.java:534)
  | 

I.e. it fails.

A couple of things I don't understand:

Why is there a transaction in the first place? The onMessage is supposed to run without a transaction and should be using the ack mode specified on the ejb (either dups_ok or auto_ack)

Why is JCA attempting to call commit() on it? The session that the JCA layer creates is an XASession and calling commit() on an XASession is illegal.
(see http://java.sun.com/j2ee/1.4/docs/api/index.html)

For a "NotSupported" method, I would expect the session used to do the message consumption to be a standard non XA session obtained from a standard non XA JMS connection, and I wouldn't expect commit to be called on it.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001240#4001240

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001240


From do-not-reply at jboss.com  Sat Jan 13 08:23:19 2007
From: do-not-reply at jboss.com (timfox)
Date: Sat, 13 Jan 2007 08:23:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- AUTO_ACKNOWLEDGE weirdness
Message-ID: <32079517.1168694599961.JavaMail.jboss@colo-br-02.atl.jboss.com>

Something struck me as a bit strange with the AUTO_ACKNOWLEDGE and MessageListeners as defined in the JMS spec.

It has always been my understanding that using AUTO_ACKNOWLEDGE gives a "at most once" delivery guarantee.

You get a "at most once" guarantee because (with receive() at least) the message is acknowledged *before* the call to receive() has returned, so if failure occurs between acking and giving you the message it is effectively lost you - you didn't receive it, but you could never get it more than once.

However when using a MessageListener breaks this breaks down. For a MessageListener, according to the JMS spec, if you are using AUTO_ACKNOWLEDGE then the message should be acked *after* the onMessage has finished executing.

This means if a failure occurs right at the end of the onMessage but before the message is acked, it could be received again - i.e. you could get duplicates, and the "at most once" delivery guarantee is lost.

In order to maintain "at most once" semantics the message should be acked before onMessage is called.

Is this just a stupidity in the JMS spec or can you think of any reason it was done this way?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001281#4001281

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001281


From do-not-reply at jboss.com  Sat Jan 13 08:29:04 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Sat, 13 Jan 2007 08:29:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1452 -
	WSDL To Java, Array unwrapping.
Message-ID: <10275863.1168694944049.JavaMail.jboss@colo-br-02.atl.jboss.com>

Thanks for the information, I have been looking at the test case for http://jira.jboss.com/jira/browse/JBWS-732 to try and get a better understanding of the expected behaviour of array unwrapping.

I have the following defined in my WSDL: -

 <types>
  |   <schema targetNamespace='http://test.jboss.org/ws/jbws1452/types' xmlns='http://www.w3.org/2001/XMLSchema' xmlns:soap11-enc='http://schemas.xmlsoap.org/soap/encoding/' xmlns:tns='http://test.jboss.org/ws/jbws1452/types' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
  | 
  |    <complexType name='testMethod'>
  |     <sequence>
  |      <element name='request' nillable='true' type='tns:RequestStringArray'/>
  |     </sequence>
  |    </complexType>
  | 
  |    <complexType name='RequestStringArray'>
  |     <sequence>
  |      <element name='TheStrings' type='string' maxOccurs='unbounded'/>
  |     </sequence>
  |    </complexType>
  | 
  |    <complexType name='testMethodResponse'>
  |     <sequence>
  |      <element name='result' nillable='true' type='tns:ResponseStringArray'/>
  |     </sequence>
  |    </complexType>
  | 
  |    <complexType name='ResponseStringArray'>
  |     <sequence>
  |      <element name='TheStrings' type='string' maxOccurs='unbounded'/>
  |     </sequence>   
  |    </complexType>
  | 
  |    <element name='testMethod' type='tns:testMethod'/>
  |    <element name='testMethodResponse' type='tns:testMethodResponse'/>
  |   </schema>
  |  </types>
  |  <message name='TestEndpoint_testMethod'>
  |   <part element='ns1:testMethod' name='testMethod'/>
  |  </message>
  |  <message name='TestEndpoint_testMethodResponse'>
  |   <part element='ns1:testMethodResponse' name='testMethodResponse'/>
  |  </message>
  | 

I believe this matches the wrapped array example from the test case.  The complexType  'testMethod' contains a sequence with a single element which references a complexType 'RequestStringArray' which contains a sequence that just contains the array.  Using wstools the following method is generated on the SEI: -

(Packages removed for readability)

  | public ResponseStringArray testMethod(RequestStringArray request) 
  |              throws  RemoteException;
  | 

So the first stage of parameter unwrapping has occured but I don't think the array unwrapping has occured, I was expecting the method to look like: -


  | public String[] testMethod(String[] request) 
  |              throws  RemoteException;
  | 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001285#4001285

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001285


From do-not-reply at jboss.com  Sat Jan 13 08:43:11 2007
From: do-not-reply at jboss.com (timfox)
Date: Sat, 13 Jan 2007 08:43:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <20344369.1168695791342.JavaMail.jboss@colo-br-02.atl.jboss.com>

"timfox" wrote : 
  | For a "NotSupported" method, I would expect the session used to do the message consumption to be a standard non XA session obtained from a standard non XA JMS connection, and I wouldn't expect commit to be called on it.
  | 
  | 

I suppose for a CMT method in a "Non specified" tx context I guess it is legal to run it in a local tx (although I'm not sure why that was chosen rather than just having no tx).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001290#4001290

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001290


From do-not-reply at jboss.com  Sat Jan 13 09:02:49 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Sat, 13 Jan 2007 09:02:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <25727491.1168696969622.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | I suppose for a CMT method in a "Non specified" tx context I guess it is legal to run it in a local tx (although I'm not sure why that was chosen rather than just having no tx).
  | 

To support redelivery of a message for an MDB that throws a RuntimeException in a 'non specified transaction context'. 

Being that JCA has to be JMS provider agnostic if a listener throws a runtime exception and the transactional attribute is NotSupported (BMT or CMT) and the client wants the message to be redelivered, the only way to achieve this in a neutral manner is to use transactions. Note, neither the JMS or the EJB spec prohibit this being that the transactional handling of a receipt of a message in an unspecified context is left up to the vendor. 

Unfortunately, the 4.0.5 code base, as opposed to the refactoring in HEAD, uses a 1PC optimization on an XAResource which was not a good design to begin with. The latest code uses local JMS transactions both for performance reasons, as well as for clarity in the BMT/CMT NotSupported scenario. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001297#4001297

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001297


From do-not-reply at jboss.com  Sat Jan 13 09:14:28 2007
From: do-not-reply at jboss.com (timfox)
Date: Sat, 13 Jan 2007 09:14:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: AUTO_ACKNOWLEDGE weirdness
Message-ID: <15691907.1168697668273.JavaMail.jboss@colo-br-02.atl.jboss.com>

It gets even more confusing :)

For an MDB, using JMSContainerInvoker (I'm not sure if JCA 1.5 inflow shows the same behaviour) and with ack mode AUTO_ACKNOWLEDGE, the message is received by the connection consumer before handing off to to the MDB, therefore for an MDB and AUTO_ACKNOWLEDGE the message is acked *before* the MDB onMessage is executed, which is the opposite of what happens for a standard non MDB MessageListener.

Nice.

The more I delve into the MDB container, JCA 1.5 inflow, and JMS message delivery, the more I realise how full of contradictions, badly specced/unspecced areas and inconsistent behaviour this area is. :)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001298#4001298

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001298


From do-not-reply at jboss.com  Sat Jan 13 10:50:22 2007
From: do-not-reply at jboss.com (timfox)
Date: Sat, 13 Jan 2007 10:50:22 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <24070599.1168703422084.JavaMail.jboss@colo-br-02.atl.jboss.com>

There is still the problem that the JCA layer is calling commit() on an XASession which is an illegal JMS operation.

How can we fix this?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001319#4001319

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001319


From do-not-reply at jboss.com  Sat Jan 13 11:40:46 2007
From: do-not-reply at jboss.com (timfox)
Date: Sat, 13 Jan 2007 11:40:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <9760719.1168706446131.JavaMail.jboss@colo-br-02.atl.jboss.com>

Looking through the 4.0.5 JCA code I think I can see what is happening:

In the CMT case, the onMessage is marked as NotSupported so the JMSServerSession chooses a LocalDemarcationStrategy even though the connection is an XAConnection.

Then bang, 


  | javax.jms.TransactionInProgressException: Cannot call commit on an XA session
  | 	at org.jboss.jms.client.container.TransactionAspect.handleCommit(TransactionAspect.java:97)
  | 	at org.jboss.aop.advice.org.jboss.jms.client.container.TransactionAspect14.invoke(TransactionAspect14.java)
  | 	at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
  | 	at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:182)
  | 	at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
  | 	at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
  | 	at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
  | 	at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
  | 	at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
  | 	at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
  | 	at org.jboss.jms.client.delegate.ClientSessionDelegate.commit(ClientSessionDelegate.java)
  | 	at org.jboss.jms.client.JBossSession.commit(JBossSession.java:165)
  | 	at org.jboss.resource.adapter.jms.inflow.JmsServerSession$LocalDemarcationStrategy.end(JmsServerSession.java:341)
  | 	at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:260)
  | 	at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
  | 	at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
  | 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
  | 

as the ServerSession tries to 
call commit() which clearly will fail.

Interestingly the same problem occurs with BMT as well even though no transaction should have been started at all. BMT doesn't count as an "unspecified tx context" so the reasoning for starting a tx there shouldn't apply as it does for CMT.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001328#4001328

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001328


From do-not-reply at jboss.com  Sat Jan 13 11:57:44 2007
From: do-not-reply at jboss.com (timfox)
Date: Sat, 13 Jan 2007 11:57:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <22920942.1168707464133.JavaMail.jboss@colo-br-02.atl.jboss.com>

"timfox" wrote : 
  | Interestingly the same problem occurs with BMT as well even though no transaction should have been started at all. BMT doesn't count as an "unspecified tx context" so the reasoning for starting a tx there shouldn't apply as it does for CMT.

Hmmm, it seems that if I omit the acknowledge-mode from the MDB deployment descriptor when using BMT, then it defaults to transacted.

This seems to be in contravention to the EJB spec:

15.4.8
anonymous wrote : 
  | If the acknowledge-mode deployment
  | descriptor element is not specified, JMS AUTO_ACKNOWLEDGE semantics are assumed.
  | 

This would explain the above behaviour: The JCA adaptor is creating an xasession on the xaconnection even though it's BMT (and should be auto_ack since I haven't specified acknowledge-mode), then trying to call commit on it at the end.

Instead, it should be creating a non transacted session, on a non xa connection and not calling commit at the end since it's non transacted.




View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001333#4001333

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001333


From do-not-reply at jboss.com  Sat Jan 13 13:35:05 2007
From: do-not-reply at jboss.com (camunda)
Date: Sat, 13 Jan 2007 13:35:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - committing content from
	our
Message-ID: <26129763.1168713305315.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi everybody.

First of all I am very sorry I haven't done anything on that issue for the last 4 months, even if I have planned to do that! But I was very busy with other projects :-(

My plan is now to 

1.)  contribute some jbpm commands (because we had written some additional logic like updating a process version in special cricumstances) to get rid of our own service-classes.

2.)  Get the Swing AdminClient (Screenshots on http://www.camunda.com/toolkit_for_jbpm/tk-jbpm-screenshots.html) work with the default Command mechanism in jBPM

3.)  Extract the generic code we used for a Swing-Tasklist and opening tasks in Swing panels to form a generic framework for Swing applications working with jBPM

So I will start with the first issue the next time. 

One problem is maybe, that we have some very pragmatic commands in our toolkit (e.g. updating the process version of a running instance in the case, that there is a note with the same name in the new version), which we also want to contribute. Would that be OK for you? 

Maybe I can make a package org.jbpm.command.experimental for that?

A second thing is, that I need for Swing-applications some GetProcess/Task/.../Command's, because I need to preload some parts of the objects graph before give the result to the client. But the advantage is, we can get rid of any DataTransferObject's we currently use in the AdminClient. I will just add them to the core, ok?

Also I will not have a JUnit test for every command, even if they are  working in some real life applications... But I will work on that issue as soon there is time!

What do you mean on that plan?

Sorry for the long thread!

Bernd.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001352#4001352

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001352


From do-not-reply at jboss.com  Sat Jan 13 13:46:23 2007
From: do-not-reply at jboss.com (camunda)
Date: Sat, 13 Jan 2007 13:46:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: committing content
	from our
Message-ID: <13240442.1168713983504.JavaMail.jboss@colo-br-02.atl.jboss.com>

Sorry, seems the forum has cut of my nice subject :-(

And a second question: In JIRA the release for jbpm 3.2 is scheduled for the  02/Feb/07. Is that realy realistic and your plan right now?

Because for me it would be nice to integrate some of the stuff in the version 3.2 to develop the AdminClient and Swing-Client framework against that version...

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001356#4001356

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001356


From do-not-reply at jboss.com  Sat Jan 13 14:15:38 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Sat, 13 Jan 2007 14:15:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: committing content
	from our
Message-ID: <27258773.1168715738675.JavaMail.jboss@colo-br-02.atl.jboss.com>

since there seem to very few issues reported against 3.2, the february timeline seems resonable. I myself have some contributions pending (commands via webservices) that I did not keep up to date because of the either changing commands or build procedures. The latter are in their last fase now, so if you have some contributions as well as I, maybe the 3.3 release (which currently only has drools integration scheduled is a more realistinc timeline for both our cuntributuions

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001361#4001361

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001361


From do-not-reply at jboss.com  Sat Jan 13 17:25:15 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Sat, 13 Jan 2007 17:25:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <671771.1168727115803.JavaMail.jboss@colo-br-02.atl.jboss.com>

As I have said, I believe more than a few times now, the 4.0.5 code was backported randomly and really should never have been done (believe me, I yelled and screamed about this for quite awhile but to no avail). The code in HEAD should really be ported or installed as a patch. 

Please note, just because JCA starts/terminates a transaction does not mean that the onMessage method executes in this context. If NotSupported or BMT is used, the EJB container will suspend the transaction appropriately. 

anonymous wrote : 
  | Hmmm, it seems that if I omit the acknowledge-mode from the MDB deployment descriptor when using BMT, then it defaults to transacted. 
  | 

No, it's not. acknowledgement modes are used only in the case of a *non* tranascted session. The spec is merely saying that if the client is using a transacted session, then the ack mode is AUTO_ACKNOWLEDGE which is just simply a convention in this case as has no overall effect.

anonymous wrote : 
  | Instead, it should be creating a non transacted session, on a non xa connection and not calling commit at the end since it's non transacted. 
  | 

No, it doesn't. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001387#4001387

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001387


From do-not-reply at jboss.com  Sat Jan 13 17:25:49 2007
From: do-not-reply at jboss.com (alesj)
Date: Sat, 13 Jan 2007 17:25:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <23626824.1168727149444.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : This interface belongs in the dependency module that knows nothing about POJOs/services.
  | 

Where in the Context hierarchy should I put it?

Should KernelRegistryEntry extend it?
If so, how do we handle KernelRegistryPlugin entries?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001388#4001388

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001388


From do-not-reply at jboss.com  Sat Jan 13 22:48:33 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Sat, 13 Jan 2007 22:48:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover refactoring
Message-ID: <13146930.1168746513225.JavaMail.jboss@colo-br-02.atl.jboss.com>

I've added one: org.jboss.test.messaging.jms.clustering.DistributedQueueTest.testMessageRedistributionAmongNodes().  Of course we could add an infinite number of more sophisticated cases, but at least the basic functionality is tested.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001458#4001458

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001458


From do-not-reply at jboss.com  Sun Jan 14 06:39:19 2007
From: do-not-reply at jboss.com (timfox)
Date: Sun, 14 Jan 2007 06:39:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <16687154.1168774759285.JavaMail.jboss@colo-br-02.atl.jboss.com>

"weston.price at jboss.com" wrote : 
  | The spec is merely saying that if the client is using a transacted session, then the ack mode is AUTO_ACKNOWLEDGE which is just simply a convention in this case as has no overall effect. 

I realise that if the session is transacted, then the ack mode is ignored, but that's not what the spec is saying. Here it is in full:

EJB 2 spec 15.4.8:
anonymous wrote : 
  | If bean managed transaction demarcation is used, the message receipt cannot be
  | part of the bean-managed transaction, and, in this case, the receipt is acknowledged by the container. If
  | bean managed transaction demarcation is used, the Bean Provider can indicate in the
  | acknowedge-mode deployment descriptor element whether JMS AUTO_ACKNOWLEDGE semantics
  | or DUPS_OK_ACKNOWLEDGE semantics should apply. If the acknowledge-mode deployment
  | descriptor element is not specified, JMS AUTO_ACKNOWLEDGE semantics are assumed.
  | 

What the spec is saying, is that if you are using BMT then the message receipt will be acked using a local non transacted session, that is either AUTO_ACK or DUPS_OK, AND if the user omits to specify which ack mode in the deployment descriptor then it will use AUTO_ACK. This ack mode is *not* ignored, it used for the message receipt.

What I observe in practice, using JBM and the 4.0.5.GA JCA, is that if I specify the ackmode, then it all works fine (my trivial example), the message is received and acknowledged.

If I fail to specify the ack mode, I can see the JCA layer creating a *transacted* XA session, and trying to call commit on it.

Bottom line is JBM works with the JMSContainerInvoker but not with JCA inflow in 4.0.5, even for this most trivial example.

I'm not trying to attribute blame, just trying to work out what is going on, and find a solution. :)

This is either a problem in JBM or a problem with JCA. Right now I believe it is a bug in JCA because the JCA layer is trying to call commit on an XASession which seems clearly wrong to me. Although I am willing to accept there is a bug in JBM if you can come up with another explanation.

If you are saying that the 4.0.5.GA code is a bodged backport and basically doesn't work, and there's no chance of getting it fixed, then we can tell our customers not to use that and stick with the JMSContainerInvoker until JB5.

(What about AS4.2 - I would have thought we would want the good HEAD version in that?)

This isn't ideal but if that's the situation, then we have to live with that.

For JBM1.2, we need to make sure that all these cases work, so I am going to improve the MDB integration tests and make sure they run with both the JMSContainerInvoker and JCA1.5 inflow.

Right now the MDB test coverage is scrappy (no blame) to say the least which is why issues like this and others are slipping through the net.




View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001488#4001488

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001488


From do-not-reply at jboss.com  Sun Jan 14 06:42:39 2007
From: do-not-reply at jboss.com (alesj)
Date: Sun, 14 Jan 2007 06:42:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <3038873.1168774959973.JavaMail.jboss@colo-br-02.atl.jboss.com>

"scott.stark at jboss.org" wrote : 
  | trunk is back to pulling in the mc snapshot so any working build of the mc could be pushed out as snapshot update.
  | 

How do you do that?
Is there an Ant task in MC which does this?

Since I've re-written DispatchContext to plain Object notion and put it in dependency. So once I update MC snapshot, I can add DC logic to ServiceControllerContext.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001489#4001489

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001489


From do-not-reply at jboss.com  Sun Jan 14 09:14:57 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Sun, 14 Jan 2007 09:14:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <31872474.1168784097996.JavaMail.jboss@colo-br-02.atl.jboss.com>

The *easiest* thing to do would be to patch 4.0.5 and then make this patch available in the next cummulative patch release. The changes that made it in to 4.0.5 should simply be replaced with the new stuff. This will be the case with 4.2. Again, this is why I never wanted this backport to happen. 

anonymous wrote : 
  | I'm not trying to attribute blame, just trying to work out what is going on, and find a solution. :)
  | 

Your altruism is quite refreshing. 

anonymous wrote : 
  | If you are saying that the 4.0.5.GA code is a bodged backport and basically doesn't work, and there's no chance of getting it fixed, then we can tell our customers not to use that and stick with the JMSContainerInvoker until JB5.
  | 

That is not what I am saying. I am more that willing to address any issues you think might be occuring with JCA and JBM. Again, a patch release in our cummulative QA patch cycle is most likely the best approach. 

anonymous wrote : 
  | (What about AS4.2 - I would have thought we would want the good HEAD version in that?)
  | 

Yes, the code in HEAD will be in 4.2. 

anonymous wrote : 
  | For JBM1.2, we need to make sure that all these cases work, so I am going to improve the MDB integration tests and make sure they run with both the JMSContainerInvoker and JCA1.5 inflow. 
  | 

Yes, this is simply a matter of running the testsuite against HEAD really where JBM is the default. Unfortunately, I haven't paid much attention to this as most of us are working on getting the TCK issues resolved and finalized. 

anonymous wrote : 
  | Right now the MDB test coverage is scrappy (no blame) to say the least which is why issues like this and others are slipping through the net. 
  | 

Not really. There is a decent framework for testing both the JCA adapter and the container invoker. Again, I think this is simply a matter of dealing with JBM which up until recently I was aware had any issues. Since this is the first time I am hearing about this and 4.0.5 has been in the wild for a bit (at least enough time to accumulate a patch release), I am assuming that we are simply running into some scenarios with JCA/JBM that have not been accounted for at this point. 









View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001501#4001501

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001501


From do-not-reply at jboss.com  Sun Jan 14 09:28:25 2007
From: do-not-reply at jboss.com (timfox)
Date: Sun, 14 Jan 2007 09:28:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <33191041.1168784905457.JavaMail.jboss@colo-br-02.atl.jboss.com>

"weston.price at jboss.com" wrote : 
  | Yes, this is simply a matter of running the testsuite against HEAD really where JBM is the default. Unfortunately, I haven't paid much attention to this as most of us are working on getting the TCK issues resolved and finalized. 
  | 

Richard Achmatowicz is currently working on this. The end result is that both JBossMQ and JBM will run using the same set of integration tests.
 
anonymous wrote : 
  | Not really. There is a decent framework for testing both the JCA adapter and the container invoker. Again, I think this is simply a matter of dealing with JBM which up until recently I was aware had any issues. Since this is the first time I am hearing about this and 4.0.5 has been in the wild for a bit (at least enough time to accumulate a patch release), I am assuming that we are simply running into some scenarios with JCA/JBM that have not been accounted for at this point. 
  | 

I had a good look in the test suite for MDB integration tests yesterday.

I started a thread on the dev list yesterday about this - have you seen it?

Scott pointed me in the direction of where the tests are. I had a look and it seemed to me the coverage was poor.

If there is a decent framework I guess I must have been looking in the wrong place. Can you point me in the right direction?









View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001503#4001503

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001503


From do-not-reply at jboss.com  Sun Jan 14 10:08:08 2007
From: do-not-reply at jboss.com (chiba)
Date: Sun, 14 Jan 2007 10:08:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Retrowoven container project
Message-ID: <20169121.1168787288465.JavaMail.jboss@colo-br-02.atl.jboss.com>

OK, I will fix this problem.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001512#4001512

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001512


From do-not-reply at jboss.com  Sun Jan 14 10:14:52 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Sun, 14 Jan 2007 10:14:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Soap with
	Attachments and document/literal
Message-ID: <23734393.1168787692658.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have just been looking at http://jira.jboss.com/jira/browse/JBWS-269, I am trying to see how much work will be involved to add support for attachments to wstools. I just wanted to check that my understanding of the current status of the Swa implementation is correct.

>From what I can see support for mapping attachments to parameters is complete for RPC/literal.

For document/literal it is not possible to map the attachments to message parameters, the only way to handle attachments with document/literal is to use the 'org.jboss.ws.core.jaxrpc.StubExt' API on the client as shown in http://jira.jboss.org/jira/browse/JBWS-1384 and on the server side use the SOAPMessageContext to get the attachment.

Is this correct?  Do we plan to support mapping to parameters for document/literal endpoints?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001514#4001514

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001514


From do-not-reply at jboss.com  Sun Jan 14 18:41:07 2007
From: do-not-reply at jboss.com (alesj)
Date: Sun, 14 Jan 2007 18:41:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Recent changes Microcontainer
Message-ID: <33097643.1168818067831.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : isAssignable/Progression
  | 
  | This logic needs moving into the TypeInfo abstraction, see the TODO
  | I added to the code. isProgression is just a special form isAssignable.
  | 
  | For now I've fixed the failing tests (that don't provide a classloader)
  | by stealing it from the bean's class.
  | 

How do I get a TypeInfo from String typeName and ClassLoader in Configurator?


  | Configurator.isAssignable() ...
  | 
  | if (typeNames[j] != null)
  | {
  |    TypeInfo info = null; // TODO - use typeNames[j] and cl 
  |    if (typeInfos[j].isAssignableFrom(info) == false)
  |    {
  |       return false;
  |    }
  | }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001599#4001599

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001599


From do-not-reply at jboss.com  Sun Jan 14 18:59:54 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Sun, 14 Jan 2007 18:59:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <20720477.1168819194391.JavaMail.jboss@colo-br-02.atl.jboss.com>

"alesj" wrote : "scott.stark at jboss.org" wrote : 
  |   | trunk is back to pulling in the mc snapshot so any working build of the mc could be pushed out as snapshot update.
  |   | 
  | 
  | How do you do that?
  | Is there an Ant task in MC which does this?
  | 

The jbossmc/build/build.xml has an install target that copies the mc jars to your jbossbuild repo in preparation for checkin:

[starksm at succubus build]$ ant -projecthelp
Buildfile: build.xml

Main targets:

 clean    Cleans up most generated files.
 clobber  Cleans up all generated files.
 docs     Builds all documentation.
 help     Show this help message.
 install  Install the jars to the jbossbuild repository.
 main     Executes the default target (most).
 most     Executes all modules and builds most everything.

It depends on the jbossbuild.repository.dir and jbossbuild.repository.version props which you can set in a local.properties file as shown here for a snapshot release:

jbossbuild.repository=file:/usr/Repository/repository.jboss.com
jbossbuild.repository.dir=/usr/Repository/repository.jboss.com
jbossbuild.repository.version=snapshot


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001601#4001601

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001601


From do-not-reply at jboss.com  Sun Jan 14 20:58:03 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Sun, 14 Jan 2007 20:58:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Added a
	deployment/deployer type notion
Message-ID: <21592794.1168826283440.JavaMail.jboss@colo-br-02.atl.jboss.com>

Deployer, DeploymentUnit, and DeploymentContext have been updated with a deployment type notion coming from the Deployer.


  |    /**
  |     * Get the deployment types associated with this deployment.
  |     * @return set of deployment type names deployers have identified
  |     * in this deployment.
  |     */
  |    public Set<String> getTypes();
  | 

Its up to the deployers to populate this set. Right now we don't make effective use of the Deployer.isRelevant(DeploymentUnit unit) method. If this was implemented to reflect when a deployer would process a deployment the MainDeployerImpl could manage the set. For now, the Abstract* deployers that have a specific type that is seen will add their Deployer.getType value to the set. The type property needs to be set in the deployer configuration for this to have meaning, or its initialization updated. 

The standard known types are in a org.jboss.deployers.spi.deployer.StandardDeployerTypes interface:


  | public interface StandardDeployerTypes
  | {
  |    /** JavaEE enterprise application archive */
  |    public static final String EAR = "ear";
  |    /** JavaEE client application archive */
  |    public static final String CAR = "car";
  |    /** JavaEE ejb generic archive */
  |    public static final String EJB = "ejb";
  |    /** JavaEE ejb 2.1 and earlier archive */
  |    public static final String EJB2x = "ejb2x";
  |    /** JavaEE ejb 3x archive */
  |    public static final String EJB3x = "ejb3x";
  |    /** JavaEE JPA archive */
  |    public static final String JPA = "jpa";
  |    /** JavaEE resource adaptor archive */
  |    public static final String RAR = "rar";
  |    /** JBoss MC beans archive */
  |    public static final String MCBEANS = "beans";
  |    /** JBoss service archive */
  |    public static final String SAR = "sar";
  |    /** JBoss hibernate archive */
  |    public static final String HAR = "har";
  |    /** Spring archive */
  |    public static final String SPRING = "spring";
  |    /** An OSGi bundle */
  |    public static final String OSGI_BUNDLE = "osgi";
  |    /** The deployment type used if a deployer does not specify anything */
  |    public static final String UNSPECIFIED_TYPE = "unspecified";
  | }
  | 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001615#4001615

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001615


From do-not-reply at jboss.com  Sun Jan 14 21:06:45 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Sun, 14 Jan 2007 21:06:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <17244101.1168826805237.JavaMail.jboss@colo-br-02.atl.jboss.com>

I did update the mc snapshot with deployer changes and I did pickup the kernel and dependency changes as well.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001618#4001618

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001618


From do-not-reply at jboss.com  Mon Jan 15 01:02:05 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Mon, 15 Jan 2007 01:02:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Running with the full
	featured profile service
Message-ID: <32542193.1168840925861.JavaMail.jboss@colo-br-02.atl.jboss.com>

There profile service impl that is being done to support the full featured managed interface is not setup as the default currently. To test the new profile service you need to:

1. Make sure you have a recent trunk (at least as late as this msg).
2. Have an updated microcontainer snapshot from repository.jboss.com(at least as late as this msg). If you build with a local repository update its contents from the cvs repo.
3. Replace the conf/bootstrap-beans.xml with the server/src/etc/conf/default/bootstrap-repo-beans.xml version.
4. Copy the profileservice/src/resources/profileservice-beans.xml to the deployers dir.

with that you should be able to start the server and run the org.jboss.test.profileservice.test.ProfileServiceUnitTestCase and have at least two tests pass.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001655#4001655

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001655


From do-not-reply at jboss.com  Mon Jan 15 02:37:02 2007
From: do-not-reply at jboss.com (bettybop)
Date: Mon, 15 Jan 2007 02:37:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of the JBoss EJB Container] - Re:
	Support of J2EE 5.0 in JBoss 5.x
Message-ID: <7615415.1168846622108.JavaMail.jboss@colo-br-02.atl.jboss.com>

We have a project that will end in may. Are there any probability to have the final release before may even without certification? Is there a fixed date for 5.0.0 GA?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001678#4001678

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001678


From do-not-reply at jboss.com  Mon Jan 15 05:34:41 2007
From: do-not-reply at jboss.com (dimitris@jboss.org)
Date: Mon, 15 Jan 2007 05:34:41 -0500 (EST)
Subject: [jboss-dev-forums] [Design of the JBoss EJB Container] - Re:
	Support of J2EE 5.0 in JBoss 5.x
Message-ID: <31489209.1168857281686.JavaMail.jboss@colo-br-02.atl.jboss.com>

There cannot be a final release that is not certified and there is not a fixed date yet, sorry.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001721#4001721

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001721


From do-not-reply at jboss.com  Mon Jan 15 06:21:44 2007
From: do-not-reply at jboss.com (bettybop)
Date: Mon, 15 Jan 2007 06:21:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of the JBoss EJB Container] - Re:
	Support of J2EE 5.0 in JBoss 5.x
Message-ID: <1132037.1168860105009.JavaMail.jboss@colo-br-02.atl.jboss.com>

Thank you

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001732#4001732

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001732


From do-not-reply at jboss.com  Mon Jan 15 08:05:15 2007
From: do-not-reply at jboss.com (alesj)
Date: Mon, 15 Jan 2007 08:05:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <26038680.1168866315665.JavaMail.jboss@colo-br-02.atl.jboss.com>

I've added DispatchContext support to ServiceControllerContext.

Scott, can you please test this again:

  | <!--
  |         Add a ProfileService handler to the remoting socket connector
  |     -->
  |     <bean name="ProfileServiceInvocationHandler"
  |         class="org.jboss.aspects.remoting.AOPRemotingInvocationHandler">
  |         <install bean="jboss.remoting:service=Connector,transport=socket" method="addInvocationHandler">
  |             <parameter>ProfileService</parameter>
  |             <parameter><this/></parameter>
  |         </install>
  |         <uninstall bean="jboss.remoting:service=Connector,transport=socket" method="removeInvocationHandler">
  |             <parameter>ProfileService</parameter>
  |         </uninstall>
  |     </bean>

Maybe just adding additional class type info to parameters.

Let me know how it went. Or tell me where to look for the test case.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001768#4001768

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001768


From do-not-reply at jboss.com  Mon Jan 15 08:14:55 2007
From: do-not-reply at jboss.com (gastaldi)
Date: Mon, 15 Jan 2007 08:14:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Security on JBoss] - Re: Generalizing
	the JAAS and JACC service
Message-ID: <19095155.1168866895640.JavaMail.jboss@colo-br-02.atl.jboss.com>

Excelent !! This is exactly what I was looking for ! 
Enabling authorization on login-config.xml is the right choice to center security-related issues per-application.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001769#4001769

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001769


From do-not-reply at jboss.com  Mon Jan 15 10:21:53 2007
From: do-not-reply at jboss.com (alesj)
Date: Mon, 15 Jan 2007 10:21:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Recent changes Microcontainer
Message-ID: <1657659.1168874513715.JavaMail.jboss@colo-br-02.atl.jboss.com>

Using KernelConfigFactory to get KernelConfig (which  can provide this)?

Putting KernelConfig instance into Configurator?
It's a 'loop' usage. Looks wrong.

I see we are already using KernelConfig as a parameter.
Doing it the same here (adding it as a parameter in resolveProperty method)?
If I do this (just tried), then almost every method in Configurator needs it. Yuck.

Any other ways / ideas?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001816#4001816

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001816


From do-not-reply at jboss.com  Mon Jan 15 10:28:18 2007
From: do-not-reply at jboss.com (olivie34)
Date: Mon, 15 Jan 2007 10:28:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Upgrading
	Jackrabbit to 1.1 on Portal 2.6?
Message-ID: <8973457.1168874898993.JavaMail.jboss@colo-br-02.atl.jboss.com>

It would be fair that the official 2.6 release of JBoss Portal use the new official jackrabbit 1.1 release.

Olivier.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001818#4001818

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001818


From do-not-reply at jboss.com  Mon Jan 15 10:50:05 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Mon, 15 Jan 2007 10:50:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <12418534.1168876205577.JavaMail.jboss@colo-br-02.atl.jboss.com>

tell our customers not to use JCA is not an option for EJB3 users as we are only Inflow based.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001830#4001830

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001830


From do-not-reply at jboss.com  Mon Jan 15 11:04:50 2007
From: do-not-reply at jboss.com (shawdav1)
Date: Mon, 15 Jan 2007 11:04:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Wiki] - Re: [[/wiki]] Exception
	starting filter wikiFileAccessFilter
Message-ID: <4693775.1168877090028.JavaMail.jboss@colo-br-02.atl.jboss.com>

Installer CR1 and the recent GA both work with the wiki binary (Portal+EJB3 configuration, not the All).

But I can't add navigation to the wiki page with the wiki-object.xml or the portal jboss-portal.sar/conf/data/default-object.xml or the Admin management portlet.

It almost seems like the wiki page is hard-coded somewhere.

I couldn't find a current bug on this.

David

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001836#4001836

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001836


From do-not-reply at jboss.com  Mon Jan 15 12:20:12 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Mon, 15 Jan 2007 12:20:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Soap with
	Attachments and document/literal
Message-ID: <31875822.1168881612489.JavaMail.jboss@colo-br-02.atl.jboss.com>

There is support for document/literal attachments. You can have multiple parts as long as there is only one part bound to the soap body. So attachments and headers can also be included. The jaxrpc-mapping.xml file doesnt have a way to indicate attachments, so the way this is determined is by the binding section in the wsdl file.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001849#4001849

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001849


From do-not-reply at jboss.com  Mon Jan 15 12:59:47 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Mon, 15 Jan 2007 12:59:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- JBMESSAGING-674 - Propagating changes on ClusteredConnection
Message-ID: <32888298.1168883987670.JavaMail.jboss@colo-br-02.atl.jboss.com>

On the process of Updating ConnectionFactories (CF) I'm thinking about using the CallbackManager and update the ConnectionFactory for active connections only (as I have talked about this with Ovidiu).

The way it should work is during a Clustered::createConnection, ClusteredAspect will register the CF on the CallbackManager for the active connection. The server will callback on all active Connections when a CF was updated, sending also the uniqueId for the CF (configured on the CF Mbean). I will also add the uniqueID on CFs.

The side effect for this is case a ConnectionFactory has two ore more active connections, it will be updated several times (one per active connection). If we want to fix this we would need a singleton CallbackManager. (we could either refactor the CallbackManager to be singleton per VM or we could create an extra CallbackManager just to work on CFs).  I will start coding without change anything on CallbackManagers for now, and we could refactor this later if we require to.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001856#4001856

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001856


From do-not-reply at jboss.com  Mon Jan 15 13:00:22 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Mon, 15 Jan 2007 13:00:22 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <21596401.1168884022604.JavaMail.jboss@colo-br-02.atl.jboss.com>


Another discussed possibility would be to make delegates and failoverMaps static (somehow in a HashMap by uniqueId) and intercept serialization calls (like write/readExternal) to inject the CF in a CallbackManager but we would still need the singleton CallbackManager for this... so I'm not going to use this idea but i wanted to keep it registered here on the forum as a brain storm possibility.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001857#4001857

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001857


From do-not-reply at jboss.com  Mon Jan 15 13:08:25 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Mon, 15 Jan 2007 13:08:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <32999767.1168884505453.JavaMail.jboss@colo-br-02.atl.jboss.com>

Now, that is indeed an issue. There are some in org.jboss.test.messagedriven.test and some in the jca pacakges. I was planning on unifying these because I wrote a mock framework to make testing the adapter easier. I can bump this up the priority list and get it checked in. 

If you guys have anything similar in JBM let me know so we aren't duplicating efforts. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001862#4001862

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001862


From do-not-reply at jboss.com  Mon Jan 15 13:21:38 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Mon, 15 Jan 2007 13:21:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Soap with
	Attachments and document/literal
Message-ID: <525015.1168885298857.JavaMail.jboss@colo-br-02.atl.jboss.com>

How about the mapping of the attachment to the parameters of the method on the SEI?

At the moment on the server side the only way I see to get access to the attachment is to use the SOAPMessage class and call the getAttachments method.

On the client side it apears that the only way to send the attachments is to use the 'org.jboss.ws.core.jaxrpc.StubExt' interface as described in JBWS-1384.

At the moment in the class JAXRPCMetaDataBuilder there is a comment: -

anonymous wrote :       
  |       // we don't support swa binding parameters in document style 
  |       // http://jira.jboss.org/jira/browse/JBWS-1384
  | 

Is this something we will support?  At the moment deployments created using wscompile can not be deployed because we do not process the mapping defined.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001865#4001865

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001865


From do-not-reply at jboss.com  Mon Jan 15 14:09:54 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Mon, 15 Jan 2007 14:09:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <19496148.1168888194246.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'll create a testcase for this in the jbossas/system-jmx module.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001878#4001878

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001878


From do-not-reply at jboss.com  Mon Jan 15 15:52:50 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Mon, 15 Jan 2007 15:52:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Upgrading
	Jackrabbit to 1.1 on Portal 2.6?
Message-ID: <10094712.1168894371004.JavaMail.jboss@colo-br-02.atl.jboss.com>

I think we plan to upgrade it soon.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001933#4001933

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001933


From do-not-reply at jboss.com  Mon Jan 15 15:59:24 2007
From: do-not-reply at jboss.com (timfox)
Date: Mon, 15 Jan 2007 15:59:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <4352798.1168894764869.JavaMail.jboss@colo-br-02.atl.jboss.com>

Using a static map seems a lot simpler and clearer to me.

AFAIK this is how JBoss AS failover works too.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001934#4001934

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001934


From do-not-reply at jboss.com  Mon Jan 15 17:16:06 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Mon, 15 Jan 2007 17:16:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Soap with
	Attachments and document/literal
Message-ID: <17449094.1168899366653.JavaMail.jboss@colo-br-02.atl.jboss.com>

That's wrong. This has been supported before, it's supposed to work. 

I reopened the issue.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001970#4001970

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001970


From do-not-reply at jboss.com  Mon Jan 15 17:18:29 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Mon, 15 Jan 2007 17:18:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <1878225.1168899509234.JavaMail.jboss@colo-br-02.atl.jboss.com>

I added a org.jboss.test.system.controller.integration.test.InstallMCToJMXUnitTestCase and I'm still seeing a CCE in the test:


  | 647 DEBUG [SimpleSARDeployer] Deployed file:/home/svn/JBossHead/jboss-head/system-jmx/src/resources/tests/org/jboss/test/system/controller/integration/test/InstallMCToJMXUnitTestCase.xml took 146ms
  | 673 DEBUG [InstallMCToJMXUnitTestCase] Deploying file:/home/svn/JBossHead/jboss-head/system-jmx/src/resources/tests/org/jboss/test/system/controller/integration/test/InstallMCToJMXUnitTestCase-mc.xml
  | 1134 ERROR [AbstractKernelController] Error installing to Installed: name=Test state=Start
  | java.lang.ClassCastException: org.jboss.system.microcontainer.ServiceControllerContext
  | 	at org.jboss.kernel.plugins.dependency.InstallAction.installActionInternal(InstallAction.java:59)
  | 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:187)
  | 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:126)
  | 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
  | 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
  | 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709)
  | 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:430)
  | 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:540)
  | 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:474)
  | 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:274)
  | 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:177)
  | 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:302)
  | 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:272)
  | 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:119)
  | 	at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64)
  | 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)
  | 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:146)
  | 	at org.jboss.test.system.controller.integration.test.IntegrationTestDelegate.deployMC(IntegrationTestDelegate.java:219)
  | 	at org.jboss.test.system.controller.integration.test.IntegrationTestDelegate.deployMC(IntegrationTestDelegate.java:291)
  | 	at org.jboss.test.system.controller.integration.test.IntegrationTestDelegate.setUp(IntegrationTestDelegate.java:73)
  | 	at org.jboss.test.AbstractTestSetup.setUp(AbstractTestSetup.java:63)
  | 	at org.jboss.test.AbstractTestCaseWithSetup.setUp(AbstractTestCaseWithSetup.java:97)
  | 	at org.jboss.test.system.controller.AbstractControllerTest.setUp(AbstractControllerTest.java:77)
  | 	at junit.framework.TestCase.runBare(TestCase.java:125)
  | 	at junit.framework.TestResult$1.protect(TestResult.java:106)
  | 	at junit.framework.TestResult.runProtected(TestResult.java:124)
  | 	at junit.framework.TestResult.run(TestResult.java:109)
  | 	at junit.framework.TestCase.run(TestCase.java:118)
  | 

Can you validate that the mc snapshot includes your changes.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001971#4001971

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001971


From do-not-reply at jboss.com  Mon Jan 15 17:27:18 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Mon, 15 Jan 2007 17:27:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Soap with
	Attachments and document/literal
Message-ID: <31242695.1168900038705.JavaMail.jboss@colo-br-02.atl.jboss.com>

That's good, my understanding matches yours - I thought we had full support for attachments and it was just tools that needed enhancing then I found that comment.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001975#4001975

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001975


From do-not-reply at jboss.com  Mon Jan 15 17:35:40 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Mon, 15 Jan 2007 17:35:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <33414003.1168900540482.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm thinking about how to fix this racing condition:


I - ClientClusteredConnectionFactoryDelegate has this following failoverMap:

Server 1->Server2->Server3->Server 1

II - Server1 is killed

III - Now the CF::failoverMap is updated to:
Server2->Server3->Server2

IV - A failure happens on a connection directed on Server1. FailoverMap doesn't have the information about Server1 any more.


I will keep coding and maybe we will need to have the failoverMap on the Connection instead of ConnectionFactory, and having failover updating these fields on Connection only when a failure happens.

As I said I am thinking about how to fix this, and I'm almost sure how to fix this. I wanted to post this just to keep the team informed.




View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001983#4001983

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001983


From do-not-reply at jboss.com  Mon Jan 15 17:37:17 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Mon, 15 Jan 2007 17:37:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Soap with
	Attachments and document/literal
Message-ID: <25991892.1168900637218.JavaMail.jboss@colo-br-02.atl.jboss.com>

I will revert the patch that disabled this, and take a look and see if there are any bugs with doc/lit attachments, but the use case that that jira issue was testing was using an invalid WSDL file, so this may have been the real problem. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001985#4001985

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001985


From do-not-reply at jboss.com  Mon Jan 15 17:38:45 2007
From: do-not-reply at jboss.com (pgier)
Date: Mon, 15 Jan 2007 17:38:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Maven
	build scripts
Message-ID: <204201.1168900725228.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi Everyone,
I created some maven scripts for building the microcontainer project.  The scripts are organized the same way that the jboss common scripts are organized.  There is one main pom.xml in the build directory, and each subproject has its own pom.xml.  Each subproject can be built by itself (assuming it's not dependent on recent changes in another subproject) or by building the entire project.

Here is what the main pom.xml file looks like:


  | <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  |   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  |   <modelVersion>4.0.0</modelVersion>
  |   <groupId>jboss</groupId>
  |   <version>2.0.0.Beta</version>
  |   <artifactId>jboss-microcontainer</artifactId>
  |   <name>JBoss Microcontainer Build</name>
  |   <url>http://www.jboss.org</url>
  |   <description>Parent POM for the JBoss Microcontainer Projects</description>
  |   <licenses>
  |    <license>
  |       <name>lgpl</name>
  |       <url>http://repository.jboss.com/licenses/lgpl.txt</url>
  |    </license>
  |   </licenses>
  |   <organization>
  |     <name>JBoss Inc.</name>
  |     <url>http://www.jboss.org</url>
  |   </organization>
  | 
  |   <packaging>pom</packaging>
  |   <modules>
  |     <module>../container</module>
  |     <module>../dependency</module>
  |     <module>../metatype</module>
  |     <module>../kernel</module>
  |     <module>../managed</module>
  |     <module>../deployers</module>
  |     <module>../aop-mc-int</module>
  |     <module>../osgi-int</module>
  |     <module>../spring-int</module>
  |   </modules>
  |   <reporting>
  |     <plugins>
  |       <plugin>
  |         <groupId>org.apache.maven.plugins</groupId>
  |         <artifactId>maven-project-info-reports-plugin</artifactId>
  |         <reportSets>
  |           <reportSet>
  |             <reports>
  |               <report>dependencies</report>
  |               <report>issue-tracking</report>
  |               <report>license</report>
  |               <report>scm</report>
  |             </reports>
  |           </reportSet>
  |         </reportSets>
  |       </plugin>
  |     </plugins>
  |   </reporting>
  |   
  |   <distributionManagement>
  |     <repository>
  |       <id>cvs-file-repository</id>
  |       <url>file://${maven.cvs.root}</url>
  |     </repository>
  |   </distributionManagement>
  | 
  | </project>
  | 
  | 

And here is the one for the container subproject:


  | 
  | <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  |   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  |   <modelVersion>4.0.0</modelVersion>
  |   <groupId>jboss</groupId>
  |   <artifactId>jboss-container</artifactId>
  |   <packaging>jar</packaging>
  |   <version>2.0.0.Beta</version>
  |   <name>JBoss Microcontainer Container</name>
  |   <url>http://www.jboss.org</url>
  |   <description>JBoss Microcontainer Container</description>
  |   <licenses>
  |    <license>
  |       <name>lgpl</name>
  |       <url>http://repository.jboss.com/licenses/lgpl.txt</url>
  |    </license>
  |   </licenses>
  |   <organization>
  |     <name>JBoss Inc.</name>
  |     <url>http://www.jboss.org</url>
  |   </organization>
  |  
  |   <repositories>
  |     <repository>
  |       <id>jboss</id>
  |       <name>JBoss Inc. Repository</name>
  |       <layout>default</layout>
  |       <url>http://repository.jboss.com/maven2/</url>
  |       <snapshots>
  |         <enabled>true</enabled>
  |       </snapshots>
  |     </repository>
  |   </repositories>
  | 
  |   <pluginRepositories>
  |      <pluginRepository>
  |         <id>jbosspluginrepo</id>
  |         <name>jboss plugin repository</name>
  |         <url>http://repository.jboss.com/maven2</url>
  |         <layout>default</layout>
  |         <snapshots>
  |            <enabled>false</enabled>
  |            <updatePolicy>never</updatePolicy>
  |         </snapshots>
  |      </pluginRepository>
  |   </pluginRepositories>
  |   
  |   <build>
  |      <sourceDirectory>src/main</sourceDirectory>
  | 	 <testSourceDirectory>src/tests</testSourceDirectory>
  |      <finalName>${artifactId}</finalName>
  |      <plugins>
  |     
  |     <!-- define how we want compilation to take place
  |            here, we accept most of the defaults but say that we want the
  |            optimization flag set, and define the source and target to be 1.5,
  |            these setting will be inherited by child projects -->
  |       <plugin>
  |         <artifactId>maven-compiler-plugin</artifactId>
  |         <version>2.0</version>
  |           <configuration>
  |               <optimize>true</optimize>
  |               <source>1.5</source>
  |               <target>1.5</target>
  |           </configuration>
  |       </plugin>  
  | 
  |        <plugin>
  |          <groupId>org.apache.maven.plugins</groupId>
  |          <artifactId>maven-jar-plugin</artifactId>
  |          <configuration>
  |            <archive>
  |              <manifest>
  |                <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
  |                <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
  |              </manifest>
  |            </archive>
  |          </configuration>
  |        </plugin>
  | 	   
  |       <!-- define that we wish to create src jars -->
  |       <plugin>
  |         <artifactId>maven-source-plugin</artifactId>
  |         <inherited>true</inherited>
  |          <executions>
  |           <execution>
  |             <goals>
  |               <goal>jar</goal>
  |             </goals>
  |           </execution>
  |         </executions>
  |       </plugin>     
  |       <plugin>
  |         <groupId>org.apache.maven.plugins</groupId>
  |         <artifactId>maven-surefire-plugin</artifactId>
  |         <configuration>
  |           <skip>true</skip>
  |         </configuration>
  |       </plugin>
  |     
  |     </plugins>
  |   </build>
  |   <dependencies>
  |     <!-- Global dependencies -->
  |     <dependency>
  | 	  <groupId>javassist</groupId>
  | 	  <artifactId>javassist</artifactId>
  | 	  <version>3.4.GA</version>
  | 	</dependency>
  |     <dependency>
  | 	  <groupId>jboss</groupId>
  | 	  <artifactId>jboss-vfs</artifactId>
  | 	  <version>2.0.4.snapshot</version>
  | 	</dependency>
  | 	
  | 	<!-- Test dependencies -->
  |     <dependency>
  | 	  <groupId>jboss</groupId>
  | 	  <artifactId>jboss-test</artifactId>
  | 	  <version>1.0.1.GA</version>
  | 	  <scope>test</scope>
  | 	</dependency>
  |     <dependency>
  | 	  <groupId>junit</groupId>
  | 	  <artifactId>junit</artifactId>
  | 	  <version>3.8.1</version>
  | 	  <scope>test</scope>
  | 	</dependency>
  |     <dependency>
  | 	  <groupId>jboss.profiler.jvmti</groupId>
  | 	  <artifactId>jboss-profiler-jvmti</artifactId>
  | 	  <version>1.0.0.CR5</version>
  | 	  <scope>test</scope>
  | 	</dependency>
  |    </dependencies>
  | </project>
  | 
  | 

The other pom.xml files look pretty similar to the one for the container subproject, just with different dependency lists and a few other minor differences.  Let me know if you have any comments or questions about these files.  I'm planning to commit them to the repository next to the build.xml as long as no one has a problem with this.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001986#4001986

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001986


From do-not-reply at jboss.com  Mon Jan 15 17:50:37 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Mon, 15 Jan 2007 17:50:37 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1452 -
	WSDL To Java, Array unwrapping.
Message-ID: <29978918.1168901437563.JavaMail.jboss@colo-br-02.atl.jboss.com>

The case in 732 is a contrived example that was made to have good coverage of jbossxb's handling of nulls and arrays. 

In most cases, a document/literal wrapped wsdl will not wrap the array yet again in another element definition. Take a look at the wscompile output of testMethod(String[] request, int foo)

You should see something like this

  | <complexType name="testMethod">
  |     <sequence>
  |       <element name = "request" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
  |        <element name="foo" type="xsd:int"/>
  |     </sequence>
  | </complexType>
  | 

The only reason to create a wrapper element is to be able to have a distinction between a null array, and a null array element. Without the wrapper, as in above, this is not possible. Even so, for the purpose of simplifying the wsdl, most toolkits will make the sacrifice.

That said there is no reason to not do it for document/literal, so you can disable that check if you like.

-Jason

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001994#4001994

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001994


From do-not-reply at jboss.com  Mon Jan 15 17:54:12 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Mon, 15 Jan 2007 17:54:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Soap with
	Attachments and document/literal
Message-ID: <16720871.1168901652791.JavaMail.jboss@colo-br-02.atl.jboss.com>

I think the original WSDL at the top of the user post is correct, the basic profile only specifies that the part must reference elements if the part is referenced from a soapbind:body element, it doesn't specify a requirement for mime:content parts.

anonymous wrote :  R2204   A document-literal binding in a DESCRIPTION MUST refer, in each of its soapbind:body element(s), only to wsdl:part element(s) that have been defined using the element attribute.

The attachments profile also contains the following parts defined in a document/literal example: -


  | <wsdl:message name="ClaimIn">
  |   <wsdl:part name="body" element="types:ClaimDetail"/>
  |   <wsdl:part name="ClaimPhoto" type="xsd:base64Binary"/>
  | </wsdl:message>
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001996#4001996

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001996


From do-not-reply at jboss.com  Mon Jan 15 17:58:11 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Mon, 15 Jan 2007 17:58:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <22418169.1168901891183.JavaMail.jboss@colo-br-02.atl.jboss.com>

I wanted to have a static Collection/Map on server side for all active collections. I could navigate on JMSDispatcher for this but I wanted to capture ServerConnectionFactoryEndpoint::createConnection and ServerConnectionEndpoint::close to keep a list of these active connections.

This is to send the notification for all active connections on update their respective CFs. I was going to add this into JMSDispatcher but didn't se a proper place. 

Any ideas where I could put such static map?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001997#4001997

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001997


From do-not-reply at jboss.com  Mon Jan 15 18:02:39 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Mon, 15 Jan 2007 18:02:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <12360664.1168902159224.JavaMail.jboss@colo-br-02.atl.jboss.com>

Never mind my latest post... I will put this into ServerConnectionFactoryEndpoint... a ServerConnectionFactoryEndpoing will know the connection it has created.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001999#4001999

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001999


From do-not-reply at jboss.com  Mon Jan 15 18:06:07 2007
From: do-not-reply at jboss.com (charles.crouch@jboss.com)
Date: Mon, 15 Jan 2007 18:06:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Running with the
	full featured profile service
Message-ID: <15095511.1168902367642.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm getting exactly two tests passing, just not including the one I really want :-). FWIW BasicDeploymentTemplateInfo is in /trunk/profileservice and getting built.

Testcase: testProfileKeys took 2.653 sec
  | Testcase: testDataSourceType took 0.151 sec
  | Testcase: testAddDataSource took 0.06 sec
  | 	Caused an ERROR
  | org.jboss.profileservice.management.plugins.BasicDeploymentTemplateInfo
  | java.lang.ClassNotFoundException: org.jboss.profileservice.management.plugins.BasicDeploymentTemplateInfo
  | 	at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
  | 	at java.security.AccessController.doPrivileged(Native Method)
  | 	at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
  | 	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
  | 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
  | 	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
  | 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
  | 	at java.lang.Class.forName0(Native Method)
  | 	at java.lang.Class.forName(Class.java:242)
  | 	at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:50)
  | 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
  | 	at java.lang.Class.forName0(Native Method)
  | 	at java.lang.Class.forName(Class.java:242)
  | 	at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:139)
  | 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1543)
  | 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1465)
  | 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1698)
  | 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
  | 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
  | 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:122)
  | 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1758)
  | 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1716)
  | 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
  | 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1917)
  | 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1841)
  | 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1718)
  | 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
  | 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
  | 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:132)
  | 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66)
  | 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:48)
  | 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:485)
  | 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:356)
  | 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:125)
  | 	at org.jboss.remoting.Client.invoke(Client.java:589)
  | 	at org.jboss.remoting.Client.invoke(Client.java:581)
  | 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
  | 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
  | 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
  | 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
  | 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
  | 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
  | 	at AOPProxy$1.getTemplate(AOPProxy$1.java)
  | 	at org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.testAddDataSource(ProfileServiceUnitTestCase.java:91)
  | 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:74)
  | 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
  | 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
  | 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
  | 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
  | 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
  | 	at AOPProxy$1.getTemplate(AOPProxy$1.java)
  | 	at org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.testAddDataSource(ProfileServiceUnitTestCase.java:91)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002001#4002001

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002001


From do-not-reply at jboss.com  Mon Jan 15 18:13:46 2007
From: do-not-reply at jboss.com (charles.crouch@jboss.com)
Date: Mon, 15 Jan 2007 18:13:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Running with the
	full featured profile service
Message-ID: <22549424.1168902826209.JavaMail.jboss@colo-br-02.atl.jboss.com>

FWIW I'm seeing the following errors when booting the profileservice enabled version of the default config in /trunk:

16:48:41,197 ERROR [SerializableDeploymentRepository] Failed to load attachments, ignoringjava.lang.ClassNotFoundException: org.jboss.resource.metadata.ConnectorMetaData
  | 16:48:41,227 ERROR [SerializableDeploymentRepository] Failed to load attachments, ignoringjava.lang.ClassNotFoundException: org.jboss.resource.metadata.ConnectorMetaData
  | 16:48:41,247 ERROR [SerializableDeploymentRepository] Failed to load attachments, ignoringjava.lang.ClassNotFoundException: org.jboss.resource.metadata.ConnectorMetaData
  | 16:48:41,297 ERROR [SerializableDeploymentRepository] Failed to load attachments, ignoringjava.lang.ClassNotFoundException: org.jboss.resource.metadata.ConnectorMetaData
  | 16:48:41,528 ERROR [SerializableDeploymentRepository] Failed to load attachments, ignoringjava.lang.ClassNotFoundException: org.jboss.resource.metadata.ConnectorMetaData
  | 16:48:41,578 ERROR [SerializableDeploymentRepository] Failed to load attachments, ignoringjava.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.jbos
  | s.metadata.WebMetaData
  | 16:48:41,958 ERROR [SerializableDeploymentRepository] Failed to load attachments, ignoringjava.lang.ClassNotFoundException: org.jboss.resource.metadata.ConnectorMetaData
  | 16:48:42,169 ERROR [SerializableDeploymentRepository] Failed to load attachments, ignoringjava.lang.ClassNotFoundException: org.jboss.resource.metadata.ConnectorMetaData
  | 16:48:42,179 ERROR [SerializableDeploymentRepository] Failed to load attachments, ignoringjava.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.jbos
  | s.metadata.WebMetaData

and

16:49:09,388 ERROR [AbstractKernelController] Error installing to Start: name=jboss.jca:name='quartz-ra.rar',service=RARDeployment state=Create mode=Manual requiredState=Installed
  | java.lang.StackOverflowError
  |         at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:544)
  |         at java.lang.StringCoding$CharsetSD.decode(StringCoding.java:190)
  |         at java.lang.StringCoding.decode(StringCoding.java:228)
  |         at java.lang.String.<init>(String.java:405)
  |         at java.net.URLDecoder.decode(URLDecoder.java:171)
  |         at org.jboss.net.protocol.file.FileURLConnection.<init>(FileURLConnection.java:66)
  |         at org.jboss.net.protocol.file.Handler.openConnection(Handler.java:42)
  |         at java.net.URL.openConnection(URL.java:943)
  |         at org.jboss.virtual.plugins.context.AbstractURLHandler.initCacheLastModified(AbstractURLHandler.java:72)
  |         at org.jboss.virtual.plugins.context.AbstractURLHandler.<init>(AbstractURLHandler.java:65)
  |         at org.jboss.virtual.plugins.context.file.FileHandler.<init>(FileHandler.java:70)
  |         at org.jboss.virtual.plugins.context.file.FileHandler.<init>(FileHandler.java:89)
  |         at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:253)
  |         at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:186)
  |         at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHandler.java:171)
  |         at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:239)
  |         at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:186)
  |         at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHandler.java:171)
  |         at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:239)
  |         at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:186)
  |         at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHandler.java:171)
  |         at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:239)
  |         at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:186)
  |         at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHandler.java:171)
  | ...
  | 

and the very similar

16:49:14,635 ERROR [AbstractKernelController] Error installing to Start: name=jboss.jca:name='quartz-ra.rar#quartz-ra.rar',service=RARDeployment state=Create mode=Manual requiredSt
  | ate=Installed
  | java.lang.StackOverflowError
  |         at sun.nio.cs.UTF_8$Decoder.decodeLoop(UTF_8.java:416)
  |         at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:544)
  |         at java.lang.StringCoding$CharsetSD.decode(StringCoding.java:190)
  |         at java.lang.StringCoding.decode(StringCoding.java:228)
  |         at java.lang.String.<init>(String.java:405)
  |         at java.net.URLDecoder.decode(URLDecoder.java:171)
  |         at org.jboss.net.protocol.file.FileURLConnection.<init>(FileURLConnection.java:66)
  |         at org.jboss.net.protocol.file.Handler.openConnection(Handler.java:42)
  |         at java.net.URL.openConnection(URL.java:943)
  |         at org.jboss.virtual.plugins.context.AbstractURLHandler.initCacheLastModified(AbstractURLHandler.java:72)
  |         at org.jboss.virtual.plugins.context.AbstractURLHandler.<init>(AbstractURLHandler.java:65)
  |         at org.jboss.virtual.plugins.context.file.FileHandler.<init>(FileHandler.java:70)
  |         at org.jboss.virtual.plugins.context.file.FileHandler.<init>(FileHandler.java:89)
  |         at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:253)
  |         at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:186)
  |         at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHandler.java:171)
  |         at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:239)
  |         at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:186)
  |         at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHandler.java:171)
  |         at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:239)
  |         at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:186)
  |         at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHandler.java:171)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002004#4002004

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002004


From do-not-reply at jboss.com  Mon Jan 15 18:20:21 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Mon, 15 Jan 2007 18:20:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <16784236.1168903221612.JavaMail.jboss@colo-br-02.atl.jboss.com>

"roy.russo at jboss.com" wrote : Does this mean that the CMSPortletWindow can now display in pages other than default.default?

Yes it means that.

anonymous wrote : 
  | Can we get this done without modifying the -object.xml... or at least make it so its backward compatible?

no it is not really possible to do that because the window needs to have the proper content type in its properties.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002007#4002007

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002007


From do-not-reply at jboss.com  Mon Jan 15 18:25:35 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Mon, 15 Jan 2007 18:25:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <13390691.1168903535191.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have commited the code that allows the content to be pluggable. There is still a bit of work at the command level as for now the choice of the window rendering is hardcoded. I'll revisit that later.

My next step is to have the CMS stuff in a separate module (core-cms) that will create a sar file that will be nested in the jboss-portal.sar. So it allows a to use the portal core without the CMS things.

Then I'll do same with our UI portlets (core-ui).


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002009#4002009

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002009


From do-not-reply at jboss.com  Mon Jan 15 19:03:24 2007
From: do-not-reply at jboss.com (chiba)
Date: Mon, 15 Jan 2007 19:03:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Retrowoven container project
Message-ID: <6987704.1168905804705.JavaMail.jboss@colo-br-02.atl.jboss.com>

java.lang.reflect.Constructor.getGenericParameterTypes()[Lorg/jboss/lang/reflect/Type; 
  | java.lang.NoSuchMethodError: java.lang.reflect.Constructor.getGenericParameterTypes()[Lorg/jboss/lang/reflect/Type; 
  | at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getConstructors(IntrospectionTypeInfoFactoryImpl.java:143)
  | at org.jboss.reflect.plugins.ClassInfoImpl.getDeclaredConstructors(ClassInfoImpl.java:400) 

It seems that the underlying JVM is 1.4 and thus does not support getGenericParameterTypes().  Is this correct?
If yes, Javassist is not guilty of this problem.  (Of course, Javassist should
provide some support of generic types but I am now writing about this particular problem.)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002023#4002023

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002023


From do-not-reply at jboss.com  Mon Jan 15 19:14:58 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Mon, 15 Jan 2007 19:14:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Soap with
	Attachments and document/literal
Message-ID: <24200811.1168906498921.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes, you are right R2910 in AP 1.0 explicitly allows both. I was mixing swa ref requirements. Anyway I will make sure this is handled correctly.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002029#4002029

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002029


From do-not-reply at jboss.com  Mon Jan 15 21:13:54 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Mon, 15 Jan 2007 21:13:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Running with the
	full featured profile service
Message-ID: <16739245.1168913634938.JavaMail.jboss@colo-br-02.atl.jboss.com>

CNFE are expected and prevent updates from loading. I don't see any overflows though. What is the os and jdk in use?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002058#4002058

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002058


From do-not-reply at jboss.com  Mon Jan 15 21:28:54 2007
From: do-not-reply at jboss.com (charles.crouch@jboss.com)
Date: Mon, 15 Jan 2007 21:28:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Running with the
	full featured profile service
Message-ID: <5002966.1168914534506.JavaMail.jboss@colo-br-02.atl.jboss.com>

OS: Windows XP SP2

C:\usr\projects\current\jboss\trunk\build\output\jboss-5.0.0.Beta2\bin>java -version
java version "1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode)


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002068#4002068

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002068


From do-not-reply at jboss.com  Mon Jan 15 22:00:09 2007
From: do-not-reply at jboss.com (ryan.campbell@jboss.com)
Date: Mon, 15 Jan 2007 22:00:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] -
	Test suite classpath normalization
Message-ID: <31138785.1168916409689.JavaMail.jboss@colo-br-02.atl.jboss.com>

While the test suite allows you to test the server binaries available under jboss.dist, it does not allow you to test the client jars available under ${jboss.dist}/client.  Instead, the client classpath is essentially all the jars either:

1. Produced by the build under */output/lib
2. Downloaded in /thirdparty

This prevents you from testing the client jars under ${jboss.dist} and fully validating that image which is useful for many different applications including patch testing and the testing of various installation techniques.  Perhaps just as important, it will allow us to detect inadvertent omissions.

I have created http://jira.jboss.com/jira/browse/JBAS-3993 which suggest we should source the tests.classpath primarly from ${jboss.dist}/client/*.jar, and only supplement as needed for test cases which require additional jars.

I propose the following approach:

- rename the existing tests.classpath to tests.compile.classpath
- create a new tests.classpath which is intially only contains ${jboss.dist}/client/*.jar
- add additional jars as needed.  I would expect things like apache HTTPClient.  Each of these exceptions should be listed in this thread so we are aware of what they are.

This should first be implemented in Branch_4_0, then 4_2, then trunk.  Most of the task will be identifying which additional jars must be added to the classpath besides ${jboss.dist}/client/*.jar and verifying this work causes no regressions.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002077#4002077

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002077


From do-not-reply at jboss.com  Mon Jan 15 23:05:29 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Mon, 15 Jan 2007 23:05:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Running with the
	full featured profile service
Message-ID: <31632668.1168920329495.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, see this issue:
http://jira.jboss.com/jira/browse/JBMICROCONT-139

You need jdk1.5.0_09+ to fix the underlying jdk issue that is causing the recursion on win32.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002099#4002099

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002099


From do-not-reply at jboss.com  Mon Jan 15 23:16:26 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Mon, 15 Jan 2007 23:16:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Soap with
	Attachments and document/literal
Message-ID: <12911971.1168920986545.JavaMail.jboss@colo-br-02.atl.jboss.com>

I just fixed support for this in trunk. See the JBWS-1384 test case.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002103#4002103

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002103


From do-not-reply at jboss.com  Mon Jan 15 23:22:56 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Mon, 15 Jan 2007 23:22:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] -
	SerializableDeploymentRepository notions
Message-ID: <17167830.1168921376138.JavaMail.jboss@colo-br-02.atl.jboss.com>

So the majority of the repository based profile service is in the SerializableDeploymentRepository. This is an implementation of DeploymentRepository that relies on object serialization to store contents on the file system. The serialization is pluggable, so while today its simple java serialization, it could (and will be) jboss serization to an xml file to allow for a better long term storage format. It could be jdbc or something else as well if desired.

The repository uses the following locations under the {name} profile root:

root/{name}/bootstrap - the bootstrap beans
root/{name}/deployers - profile deployers
root/{name}/deploy - installed deployments
root/{name}/apps - post install deployments
root/{name}/attachments - pre-processed deployment metadata attachments
root/{name}/profile/edits - admin edits to deployments 

A DeploymentContext refers to the raw unedited deployment archive/directory, and when a DeploymentContext is processed through the MainDeployer.process(-1, Deployer.CLASSLOADER_DEPLOYER), the profile and by delegation the repository is updated with the parses metadata pojos. What needs to happen is that when a DeploymentContext is loaded from the repository and it has pre-parsed attachments, these are set as the getPredeterminedManagedObjects(). If there are admin edits then the attachments come from the profile/edits override of the attachments.

If a DeploymentContext has a non-empty getPredeterminedManagedObjects() attachments, processing should begin at the Deployer.CLASSLOADER_DEPLOYER and all attachment processing is skipped.

This check and deployer bypass logic should happen in the MainDeployerImpl. 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002106#4002106

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002106


From do-not-reply at jboss.com  Mon Jan 15 23:24:13 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Mon, 15 Jan 2007 23:24:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1260 -
	such a part must refer to an element named a
Message-ID: <1384056.1168921453040.JavaMail.jboss@colo-br-02.atl.jboss.com>

"jason.greene at jboss.com" wrote : "thomas.diesler at jboss.com" wrote : 
  |   | Also, this WSDL violates BP 1.0 because it uses "type" on the part definition for a document/literal web service. It must be element.
  |   | 
  |   | 
  |   |   | <part name="attachmentContents" type="xsd:string"/>
  |   |   | 
  |   | 
  | 
  | Note, this comment is wrong, the AP 1.0 spec allows type or element. BP 1.0 only governs the standard SOAP binding not the MIME binding.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002107#4002107

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002107


From do-not-reply at jboss.com  Mon Jan 15 23:31:16 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Mon, 15 Jan 2007 23:31:16 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	Test suite classpath normalization
Message-ID: <33435147.1168921876099.JavaMail.jboss@colo-br-02.atl.jboss.com>

This is needed, but we should be building more test group specific client classpaths to better track what tests require what jars from the client dir.

Note that some tests do rely on server jars at they try to tests implementation details. These tests should be moved into the corresponding module they are testing the implementation of.

We are starting to include more tests in modules, so we need a way to run these tests as part of the overall qa tests.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002108#4002108

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002108


From do-not-reply at jboss.com  Mon Jan 15 23:50:46 2007
From: do-not-reply at jboss.com (ryan.campbell@jboss.com)
Date: Mon, 15 Jan 2007 23:50:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	Test suite classpath normalization
Message-ID: <15644969.1168923046581.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, so it sounds like you want something like several of these:

<test-target>.classpath

where <test-target>.classpath is the ant target with dashes converted to dots.  So we would have:

jboss.all.config.tests.classpath
tests.security.manager.classpath
tomcat.ssl.tests.classpath
etc...

We will come up with estimates for the monolithic test classpath vs. group level classpaths.   The monolithic test classpath will meet our immediate needs, but I realize the group level classpaths provide better documentation and better analysis of depdencies.

Good point on the server jars, they could be included from ${jboss.dist} as well.

As for the tests in other modules, this goes back to isolating the test harness/refactoring the test suite.  This is in scope for the near future, but I'd like to keep that discussion separate.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002112#4002112

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002112


From do-not-reply at jboss.com  Tue Jan 16 00:08:10 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 00:08:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	Test suite classpath normalization
Message-ID: <27474636.1168924090856.JavaMail.jboss@colo-br-02.atl.jboss.com>

"ryan.campbell at jboss.com" wrote : Ok, so it sounds like you want something like several of these:
  | 
  | <test-target>.classpath
  | 
  | where <test-target>.classpath is the ant target with dashes converted to dots.  So we would have:
  | 
  | jboss.all.config.tests.classpath
  | tests.security.manager.classpath
  | tomcat.ssl.tests.classpath
  | etc...
  | 
  | We will come up with estimates for the monolithic test classpath vs. group level classpaths.   The monolithic test classpath will meet our immediate needs, but I realize the group level classpaths provide better documentation and better analysis of depdencies.
  | 
Sounds good.

"ryan.campbell at jboss.com" wrote : 
  | As for the tests in other modules, this goes back to isolating the test harness/refactoring the test suite.  This is in scope for the near future, but I'd like to keep that discussion separate.
Ok.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002117#4002117

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002117


From do-not-reply at jboss.com  Tue Jan 16 01:27:39 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Tue, 16 Jan 2007 01:27:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	SerializableDeploymentRepository notions
Message-ID: <19977937.1168928859838.JavaMail.jboss@colo-br-02.atl.jboss.com>

so how are the objects serialized up?  Do you precompile?  Or will it just do it?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002132#4002132

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002132


From do-not-reply at jboss.com  Tue Jan 16 02:11:52 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 02:11:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	SerializableDeploymentRepository notions
Message-ID: <9881673.1168931512192.JavaMail.jboss@colo-br-02.atl.jboss.com>

Its done dynamically as part of the deployment processing of the profile. If a DeploymentContext does not have predetermined managed objects its run through the MainDeployer.process to the CLASSLOADER_DEPLOYER and then the profile.updateDeployment so that the attachments can be saved. Its just object serialization of the context attachments object at that point using the serializer associated with the repository.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002139#4002139

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002139


From do-not-reply at jboss.com  Tue Jan 16 02:48:08 2007
From: do-not-reply at jboss.com (alesj)
Date: Tue, 16 Jan 2007 02:48:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Maven
	build scripts
Message-ID: <18231353.1168933688037.JavaMail.jboss@colo-br-02.atl.jboss.com>

Can I assign you this JIRA issue?
 - http://jira.jboss.com/jira/browse/JBMICROCONT-117

So that we can also bug you through JIRA if we have some Maven + MC  problems. ;-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002145#4002145

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002145


From do-not-reply at jboss.com  Tue Jan 16 04:16:22 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 16 Jan 2007 04:16:22 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: committing content
	from our
Message-ID: <9591939.1168938982530.JavaMail.jboss@colo-br-02.atl.jboss.com>

"camunda" wrote : 1.)  contribute some jbpm commands (because we had written some additional logic like updating a process version in special cricumstances) to get rid of our own service-classes.
  | 

great.  put them in org.jbpm.command package.  the good thing is that commands are isolated.  so you can't break any existing stuff.

"camunda" wrote : 3.)  Extract the generic code we used for a Swing-Tasklist and opening tasks in Swing panels to form a generic framework for Swing applications working with jBPM
  | 

a minimal working swing client would be nice.  even better would be a client based on eclipse rcp.  ever thought of doing that ?

"camunda" wrote : One problem is maybe, that we have some very pragmatic commands in our toolkit (e.g. updating the process version of a running instance in the case, that there is a note with the same name in the new version), which we also want to contribute. Would that be OK for you? 
  | 

process migration is a good command.    providing that functionality is on my todo list as well.  i want to do this as follows: input is a processInstance, a new processDefinition and a map of old node names to new node names.  any help in that is appreciated.  even if your code doesn't yet have the node map integrated.

"camunda" wrote : Maybe I can make a package org.jbpm.command.experimental for that?
  | 

no need for that.  put it in the org.jbpm.package.  if you can, such info should be in the documentation.  i guess the most practical place to start documenting commands is in the javadocs.

"camunda" wrote : A second thing is, that I need for Swing-applications some GetProcess/Task/.../Command's, because I need to preload some parts of the objects graph before give the result to the client. But the advantage is, we can get rid of any DataTransferObject's we currently use in the AdminClient. I will just add them to the core, ok?
  | 

yes, please add them.

"camunda" wrote : Also I will not have a JUnit test for every command, even if they are  working in some real life applications... But I will work on that issue as soon there is time!
  | 

as long as the average test coverage is ok, this is good.  but beware that writing a test also guards your code of being evicted if you can't maintain it any more.  if untested code starts producing problems and you're not around to fix it in a reasonable time, we might decide to evict that code...   With unit test we can fix it ourselves, even if you're not around.

great plan.  thanks.  sorry for late reply

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002180#4002180

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002180


From do-not-reply at jboss.com  Tue Jan 16 04:38:27 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 16 Jan 2007 04:38:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - remove .project and
	.classpath from bpel
Message-ID: <26734444.1168940307862.JavaMail.jboss@colo-br-02.atl.jboss.com>

alex, if you don't use the .project and .classpath in the bpel subproject, can you delete those files ?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002190#4002190

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002190


From do-not-reply at jboss.com  Tue Jan 16 04:40:32 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 04:40:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Management Features on JBoss] -
	Internalization of the management layer
Message-ID: <23073952.1168940432945.JavaMail.jboss@colo-br-02.atl.jboss.com>

So now that I'm starting to code exceptions and messages that will show up in management console tools, I need to start thinking about how this will be internationalized. We have a couple of starting points:

http://docs.jboss.org/process-guide/en/html/internationalization.html#d0e3916

and a project John mentioned and has written about:
http://www.onjava.com/pub/a/onjava/2006/12/06/i18n-messages-and-logging.html?page=2
http://i18nlog.sourceforge.net/doc/users-guide.html

I like the i18nlog annotations for handling the bundle keys, but the logging is a subset of the arjuna code. Maybe the best approach is just to update the arjuna javadoc to use annotations similar to i18nlog.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002192#4002192

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002192


From do-not-reply at jboss.com  Tue Jan 16 04:57:49 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Tue, 16 Jan 2007 04:57:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <18063000.1168941469574.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have decoupled the cms from the core yesterday. There may have minor issues to correct, but it looks like it went fine.

I'll take care of other modules later this week. I plan to detach ui, management and samples.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002206#4002206

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002206


From do-not-reply at jboss.com  Tue Jan 16 05:09:51 2007
From: do-not-reply at jboss.com (camunda)
Date: Tue, 16 Jan 2007 05:09:51 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: committing content
	from our
Message-ID: <3605600.1168942191607.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi tom,

anonymous wrote : sorry for late reply
no problem...

anonymous wrote : even better would be a client based on eclipse rcp. ever thought of doing that ? 
Sorry, I have no experience with RCP clients, and I think they are much different from Swing ones. Also I have only be in projects working with Swing, not RCP (I experienced in bigger companies the Webstart argument is very strong, so they do not go with RCP, but I will not start this discussion here :-))


anonymous wrote : process migration is a good command. providing that functionality is on my todo list as well. i want to do this as follows: input is a processInstance, a new processDefinition and a map of old node names to new node names. any help in that is appreciated. even if your code doesn't yet have the node map integrated.
  | 

Our code currently updates one processInstance if the node exists with the same name in the new definition. changing that to a node-name-map should not be a big deal....

How do you organize commits, can I add everything to the HEAD in cvs and commit then when I am ready?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002210#4002210

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002210


From do-not-reply at jboss.com  Tue Jan 16 05:18:26 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 16 Jan 2007 05:18:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: committing content
	from our
Message-ID: <14140727.1168942706635.JavaMail.jboss@colo-br-02.atl.jboss.com>

yes.  you can just commit when you're ready.  keep an eye on these forums.  as before and after a release, i might instruct here to keep your updates on HEAD for a short period (a few days).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002213#4002213

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002213


From do-not-reply at jboss.com  Tue Jan 16 05:19:27 2007
From: do-not-reply at jboss.com (djmacpac)
Date: Tue, 16 Jan 2007 05:19:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - MailModuleImpl
Message-ID: <13065197.1168942767610.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi,

I want to use the MailModuleImpl but I don't know how to.
I want to catch an exception and send the message to an eMail adress. But now i don't know how to use the MailModule.

I have this:

  | MailModuleImpl mail = new MailModuleImpl();
  | 

but i can't use methods like send or setGateway , what did I forget?
Please help me!

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002214#4002214

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002214


From do-not-reply at jboss.com  Tue Jan 16 05:20:17 2007
From: do-not-reply at jboss.com (djmacpac)
Date: Tue, 16 Jan 2007 05:20:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: MailModuleImpl
Message-ID: <24052630.1168942817919.JavaMail.jboss@colo-br-02.atl.jboss.com>

Sorry wrong Forum, wanted to post it in the User Forum, who can move this?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002216#4002216

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002216


From do-not-reply at jboss.com  Tue Jan 16 05:34:13 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 05:34:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Maven
	build scripts
Message-ID: <22968343.1168943653080.JavaMail.jboss@colo-br-02.atl.jboss.com>

That looks fine, but the osgi-int project has been moved out of the jbossmc root. Maybe Ales just started something new in its place, but osgi-int should be ignored for the maven build.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002223#4002223

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002223


From do-not-reply at jboss.com  Tue Jan 16 05:42:03 2007
From: do-not-reply at jboss.com (alesj)
Date: Tue, 16 Jan 2007 05:42:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Maven
	build scripts
Message-ID: <10856999.1168944123649.JavaMail.jboss@colo-br-02.atl.jboss.com>

"scott.stark at jboss.org" wrote : That looks fine, but the osgi-int project has been moved out of the jbossmc root.

If we could just ignore it at the moment.
We have a separate project, since at that time I thought we needed better modularization, but as the way things are implemented now - quite out-of-the-box with MC support - I'm not so sure any more. So I might put it back in - once it is finished and fully tested.

"scott.stark at jboss.org" wrote : Maybe Ales just started something new in its place, but osgi-int should be ignored for the maven build.

Nope. Nothing new from my side.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002225#4002225

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002225


From do-not-reply at jboss.com  Tue Jan 16 07:14:01 2007
From: do-not-reply at jboss.com (timfox)
Date: Tue, 16 Jan 2007 07:14:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <29667987.1168949641440.JavaMail.jboss@colo-br-02.atl.jboss.com>

The tests really shouldn't care if the underlying implementation is using JCA or  ASF.

We just need some tests that test every combination (there aren't that many), i.e.:

CMT:

tx Required:

test message receipt.
test message is not acked until onMessage returned
test throwing RuntimeException
test throwing Checked exception
test setRollbackOnly
etc

tx Not Supported

first define what the behaviour should be then do the same tests as tx required and check results conform to defined behaviour

BMT:

Check that message is acked according to ack mode specified in config, i.e. AUTO_ACK, DUPS_OK.

Check that defaults to AUTO_ACK if not specified.

use UT to being and commit /rollback tx. do some other transactional operation in the UT (e.g. send to another MDB)

Then repeat all the above using MDB on queue, topic with durable and non durable subscripton, selector etc.

So this isn't about testing the adapter, AFAIK the adapter tests look pretty thorough.

This is about testing MDB functionality, and should be agnostic of the implementation.

Then we just run the exact same of tests swapping out the invoker-proxy-binding for either JMSContainerInvoker or JCA inflow, and repeat again for JbossMQ and JBM.

Should pass all tests in all 4 configurations.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002238#4002238

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002238


From do-not-reply at jboss.com  Tue Jan 16 08:14:11 2007
From: do-not-reply at jboss.com (schoren)
Date: Tue, 16 Jan 2007 08:14:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - JBoss IDE
	doesn't show JBoss server in debugging options
Message-ID: <20496155.1168953251797.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi. I've been following the instructions on http://docs.jboss.com/jbosside/tutorial/build/en/html/, but when i get to debugging, there is no option called JBoss 2.4.x nor JBoss 3.0.x nor JBoss3.2.x nor JBoss 4.0. How can i do to debugg???

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002263#4002263

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002263


From do-not-reply at jboss.com  Tue Jan 16 09:35:24 2007
From: do-not-reply at jboss.com (heiko.braun@jboss.com)
Date: Tue, 16 Jan 2007 09:35:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - @PortComponent
	replacement
Message-ID: <6822877.1168958124585.JavaMail.jboss@colo-br-02.atl.jboss.com>

While working on config issues i realized that  the PortComponentAnnotation needed refactoring. It's now split into @WebContext and @EndpointConfig. 
The main reason for this was the distinction between client and server side annotations. 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002291#4002291

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002291


From do-not-reply at jboss.com  Tue Jan 16 09:39:46 2007
From: do-not-reply at jboss.com (pgier)
Date: Tue, 16 Jan 2007 09:39:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Maven
	build scripts
Message-ID: <30795981.1168958386781.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | Can I assign you this JIRA issue?
  | - http://jira.jboss.com/jira/browse/JBMICROCONT-117 
  | 

Yes, please do.


anonymous wrote : 
  | That looks fine, but the osgi-int project has been moved out of the jbossmc root. Maybe Ales just started something new in its place, but osgi-int should be ignored for the maven build.
  | 

If I just comment it out or remove that line from the build/pom.xml, then the main build won't pick it up.  Then I can still put the osgi-int pom into that project subdirectory, in case you want to build it by itself, or you want to use it later.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002294#4002294

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002294


From do-not-reply at jboss.com  Tue Jan 16 09:40:13 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Tue, 16 Jan 2007 09:40:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	SerializableDeploymentRepository notions
Message-ID: <27822742.1168958413209.JavaMail.jboss@colo-br-02.atl.jboss.com>

So does a specific deployer need to change to take advantage of this?  I'm thinking yes, because the XML or other source of metadata may have been updated in the meantime.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002295#4002295

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002295


From do-not-reply at jboss.com  Tue Jan 16 09:48:12 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Tue, 16 Jan 2007 09:48:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <1896791.1168958892996.JavaMail.jboss@colo-br-02.atl.jboss.com>

This is effectively what the framework does, both for ASF and for JCA. I will verify this, but I am  sure a majority of those cases are covered. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002297#4002297

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002297


From do-not-reply at jboss.com  Tue Jan 16 09:51:39 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Tue, 16 Jan 2007 09:51:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Retrowoven container project
Message-ID: <20325026.1168959099078.JavaMail.jboss@colo-br-02.atl.jboss.com>

When used with JBoss Retro, we will replace access to Constructor.getGenericParameterTypes() with a call to some other class that does this. We will also replace all occurrences of java.lang.reflect.Type with org.jboss.lang.reflect.Type etc.

The "some other class that does this" will need to use javassist to get hold of the generic info, similarly to how the JBoss Retro AnnotationHelper uses javassist to get hold of the annotations from the bytecode attributes.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002298#4002298

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002298


From do-not-reply at jboss.com  Tue Jan 16 09:53:55 2007
From: do-not-reply at jboss.com (roy.russo@jboss.com)
Date: Tue, 16 Jan 2007 09:53:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <1300793.1168959235683.JavaMail.jboss@colo-br-02.atl.jboss.com>

There are problem with the core-cms:

1. You *must* deploy the jboss-portal.sar first, and then the portal-cms.sar. If you do not, the cms will not deploy at all, due to some issues with security/identity.

2. If you deploy the portal-cms.sar in a running instance of AS, it will create all the resources. 
   a. File creation is sloooooow. 
   b. Also, when you log in to the cmsAdminPortlet, it doesn't show the root directory so you can't do anything. I wouldn't be surprised if this is also related to identity integration.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002301#4002301

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002301


From do-not-reply at jboss.com  Tue Jan 16 09:54:42 2007
From: do-not-reply at jboss.com (pavel.tsekov@redhat.com)
Date: Tue, 16 Jan 2007 09:54:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	Test suite classpath normalization
Message-ID: <23787999.1168959282688.JavaMail.jboss@colo-br-02.atl.jboss.com>

Are there any tests in the testsuite that require .jar libraries from ${jboss.dist}/client ?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002303#4002303

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002303


From do-not-reply at jboss.com  Tue Jan 16 09:56:33 2007
From: do-not-reply at jboss.com (alesj)
Date: Tue, 16 Jan 2007 09:56:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Maven
	build scripts
Message-ID: <18005893.1168959393605.JavaMail.jboss@colo-br-02.atl.jboss.com>

"pgier" wrote : anonymous wrote : 
  |   | Can I assign you this JIRA issue?
  |   | - http://jira.jboss.com/jira/browse/JBMICROCONT-117 
  |   | 
  | Yes, please do.
  | 

Sorry, but I don't know your real name. :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002304#4002304

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002304


From do-not-reply at jboss.com  Tue Jan 16 10:20:47 2007
From: do-not-reply at jboss.com (pgier)
Date: Tue, 16 Jan 2007 10:20:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Maven
	build scripts
Message-ID: <5513275.1168960847997.JavaMail.jboss@colo-br-02.atl.jboss.com>

"alesj" wrote : 
  | 
  | Sorry, but I don't know your real name. :-)
  | 

Paul Gier  :)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002312#4002312

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002312


From do-not-reply at jboss.com  Tue Jan 16 10:40:11 2007
From: do-not-reply at jboss.com (alesj)
Date: Tue, 16 Jan 2007 10:40:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Maven
	build scripts
Message-ID: <17883191.1168962011131.JavaMail.jboss@colo-br-02.atl.jboss.com>

"pgier" wrote : Paul Gier  :)

Hmm ... yes, I did look at the P and G first letters to assign you the task.
But you are not on the JBoss JIRA assignies, or I can't assign it to you?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002317#4002317

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002317


From do-not-reply at jboss.com  Tue Jan 16 11:00:40 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Tue, 16 Jan 2007 11:00:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss ESB] - Simple Orchestration
	Quickstart
Message-ID: <4254658.1168963240435.JavaMail.jboss@colo-br-02.atl.jboss.com>

The intent of this quickstart is to show simple service orchestration using jBPM  (jpdl) and the ESB. It is planned to consist of a simple jBPM process (similar to what Burr demo'd in Berlin). This process would be started by receipt of a JMS message from an ESB Action, then would send a JMS message to the ESB to perform a transformation and perhaps send another message. Another ESB action would signal the process to continue.

The quickstart would be in examples/quickstart/simple_orchestation, would "borrow" code from a few of the other quickstarts, and include a process definition and three new classes:

	ESB Action to initiate a process
	ESB Action to signal a process
	jBPM ActionHandler to send JMS message

The ESB Actions will use the the jBPM 3.2 Command interface to communicate with jBPM. jBPM 3.2 is still beta, but should release early February, and the command interface is stable at this point.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002331#4002331

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002331


From do-not-reply at jboss.com  Tue Jan 16 11:26:13 2007
From: do-not-reply at jboss.com (charles.crouch@jboss.com)
Date: Tue, 16 Jan 2007 11:26:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Running with the
	full featured profile service
Message-ID: <14307591.1168964773718.JavaMail.jboss@colo-br-02.atl.jboss.com>

"scott.stark at jboss.org" wrote : CNFE are expected and prevent updates from loading.

So the testAddDataSource is expected to fail? What needs to be in place for it to succeed?

"scott.stark at jboss.org" wrote : I don't see any overflows though. What is the os and jdk in use?

Ok, I will try a new JDK.

Thanks

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002333#4002333

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002333


From do-not-reply at jboss.com  Tue Jan 16 11:45:28 2007
From: do-not-reply at jboss.com (timfox)
Date: Tue, 16 Jan 2007 11:45:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Transaction Services] -
	XAResourceRecovery close?
Message-ID: <1704282.1168965928875.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm implementing an XAResourceRecovery class which creates an XAConnection to the jms server, gets the XAResource and returns that in the getXAResource() method.

This is all fine, but I can't find any lifecycle methods that get called on the XAResourceRecovery() when the recovery manager is done with it, so we can close any underlying resources.

At some point we need to close the connection. Without such a lifecycle method how can I know when it is safe to close the underlying connection?

I can use a finalizer, but I'd rather not.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002343#4002343

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002343


From do-not-reply at jboss.com  Tue Jan 16 11:53:23 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Tue, 16 Jan 2007 11:53:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Fine
	grained action aware interfaces (JBMICROCONT-134)
Message-ID: <16374041.1168966403304.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have updated the lifecycle stuff to use the more specific lifecycle KernelControllerContextAware interfaces.

As part of this I have changed the <aop:lifcycle> xml to 


  | <aop:lifecycle-configure/>
  | <aop:lifecycle-create/>
  | <aop:lifecycle-describe/>
  | <aop:lifecycle-install/>
  | <aop:lifecycle-instantiate/>
  | <aop:lifecycle-start/>
  | 

This will need updating in A/S trunk when the microcontainer snapshot is updated (affected modules are aop-mc-int and kernel). I modified kernel to not invoke the ConfigureKernelControllerContextAware twice, by checking that if the interface is EXACTLY KernelControllerContextAware, it will invoke that as part of the ConfigureAction. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002348#4002348

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002348


From do-not-reply at jboss.com  Tue Jan 16 13:31:03 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 13:31:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	SerializableDeploymentRepository notions
Message-ID: <16344213.1168972263721.JavaMail.jboss@colo-br-02.atl.jboss.com>

The deployers need to have a stable api relative to the serialization format. That can be based on a stable pojo object model that is binary compatible as it evolves, or a serializer that deals with evolution. Right now the serialization is not a function of the attachment type, but that is what I want to support.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002379#4002379

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002379


From do-not-reply at jboss.com  Tue Jan 16 13:33:16 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 13:33:16 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	Test suite classpath normalization
Message-ID: <25403024.1168972396869.JavaMail.jboss@colo-br-02.atl.jboss.com>

Not currently as the testsuite classpath is built from the jbossas module classpaths.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002383#4002383

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002383


From do-not-reply at jboss.com  Tue Jan 16 13:36:52 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 13:36:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Running with the
	full featured profile service
Message-ID: <10565445.1168972612307.JavaMail.jboss@colo-br-02.atl.jboss.com>

"charles.crouch at jboss.com" wrote : "scott.stark at jboss.org" wrote : CNFE are expected and prevent updates from loading.
  | 
  | So the testAddDataSource is expected to fail? What needs to be in place for it to succeed?
  | 
No, that works for me. I'm running from within eclipse though so most likely a classpath is missing from the ant scripts that cause the problem when running from the command line.

The update loading is a startup problem.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002386#4002386

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002386


From do-not-reply at jboss.com  Tue Jan 16 14:00:17 2007
From: do-not-reply at jboss.com (ryan.campbell@jboss.com)
Date: Tue, 16 Jan 2007 14:00:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	Test suite classpath normalization
Message-ID: <21305940.1168974017254.JavaMail.jboss@colo-br-02.atl.jboss.com>

Right, so instead of building the classpath from jbossas module classpaths, we want to build it primarily from ${jboss.dist}/client.  All tests will then require .jar libraries from ${jboss.dist}/client.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002396#4002396

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002396


From do-not-reply at jboss.com  Tue Jan 16 14:12:47 2007
From: do-not-reply at jboss.com (sohil.shah@jboss.com)
Date: Tue, 16 Jan 2007 14:12:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <24719097.1168974767227.JavaMail.jboss@colo-br-02.atl.jboss.com>

looking into this.

my guess is that when it loads and tries to create resources, its not being allowed to due to permission issues.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002399#4002399

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002399


From do-not-reply at jboss.com  Tue Jan 16 16:10:46 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Tue, 16 Jan 2007 16:10:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	SerializableDeploymentRepository notions
Message-ID: <10128525.1168981846755.JavaMail.jboss@colo-br-02.atl.jboss.com>

"scott.stark at jboss.org" wrote : The deployers need to have a stable api relative to the serialization format. That can be based on a stable pojo object model that is binary compatible as it evolves, or a serializer that deals with evolution. Right now the serialization is not a function of the attachment type, but that is what I want to support.
  | 
  | 

im not thinking of evolution, more of that the app developer has updated an XML file/annotation in their application/deployment

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002442#4002442

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002442


From do-not-reply at jboss.com  Tue Jan 16 16:17:02 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 16:17:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] -
	ManagedProperty changes
Message-ID: <13120207.1168982222339.JavaMail.jboss@colo-br-02.atl.jboss.com>

Two changes I need to allow for better use of ManagedProperty are to change the ManagedPropertyImpl managedObject field to be of type ManagedObject rather than ManagedObjectImpl (this is done and in the current snapshot), and also to allow a ManagedProperty to be disconnected from its ManagedObject as in not requiring this to be non-null.

This is needed for deployment templates that just want to expose a set of properties that need to be applied to a template. The ManagedProperty are simple value type objects used to convey the required properties in order to populate the template.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002444#4002444

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002444


From do-not-reply at jboss.com  Tue Jan 16 16:18:02 2007
From: do-not-reply at jboss.com (kbjorndahl)
Date: Tue, 16 Jan 2007 16:18:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - CMS "Select Action"
	DropDown broken in IE6
Message-ID: <4581964.1168982282801.JavaMail.jboss@colo-br-02.atl.jboss.com>

Works good in FireFox, but the drop down doesn't see to drop down in IE6

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002445#4002445

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002445


From do-not-reply at jboss.com  Tue Jan 16 16:20:09 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 16:20:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	SerializableDeploymentRepository notions
Message-ID: <21301996.1168982409338.JavaMail.jboss@colo-br-02.atl.jboss.com>

If that happens then the pre-processed attachments need to be thrown away. This is a check that needs to be added to the loadAttachments logic. If a raw deployment is newer than the attachments the are thrown away.

Now if there are also admin edits, whether or not they can be reapplied will depend on the change and how the edits are stored.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002446#4002446

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002446


From do-not-reply at jboss.com  Tue Jan 16 16:22:13 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 16:22:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Running with the
	full featured profile service
Message-ID: <3137021.1168982533099.JavaMail.jboss@colo-br-02.atl.jboss.com>

"scott.stark at jboss.org" wrote : "charles.crouch at jboss.com" wrote : "scott.stark at jboss.org" wrote : CNFE are expected and prevent updates from loading.
  |   | 
  |   | So the testAddDataSource is expected to fail? What needs to be in place for it to succeed?
  |   | 
  | No, that works for me. 
  | 
Ok, I was lying. A previous simple deployment creation was working, but applying changes to the template properties as is currently done in the test is not. This should be working by tonight's checkin.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002448#4002448

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002448


From do-not-reply at jboss.com  Tue Jan 16 16:38:23 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 16:38:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Fine
	grained action aware interfaces (JBMICROCONT-134)
Message-ID: <29414670.1168983503210.JavaMail.jboss@colo-br-02.atl.jboss.com>

I pulled in your changes and will test them in my local snapshot update. I'll be pushing out a new snapshot tonight that includes these along with management changes I'm working on.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002456#4002456

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002456


From do-not-reply at jboss.com  Tue Jan 16 17:05:40 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Tue, 16 Jan 2007 17:05:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	SerializableDeploymentRepository notions
Message-ID: <22489468.1168985140501.JavaMail.jboss@colo-br-02.atl.jboss.com>

Don't see how the current logic could work with exploded archive.  You have the "WATCH FILE" problem all over again.  A deploymentContext could have a number of attachments associated with it that are loaded from different deployers and multiple files.  One attachment could even be loaded from multiple files.  This logic is going to need callbacks to the deployer that needs the attachment so that the deployer can identify timestamps to check the serialization event against.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002462#4002462

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002462


From do-not-reply at jboss.com  Tue Jan 16 17:09:04 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 17:09:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	SerializableDeploymentRepository notions
Message-ID: <5543559.1168985344298.JavaMail.jboss@colo-br-02.atl.jboss.com>

That really should be an optional development type feature where a vfs visitor provides the deployment timestamp. If the visitor is configured then edits made outside of the profile service can be identified. The simplest initial implementation is to simply touch the top level deployment anytime content is changed. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002464#4002464

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002464


From do-not-reply at jboss.com  Tue Jan 16 17:15:55 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Tue, 16 Jan 2007 17:15:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - shutdown vs. undeploy
	with serialized attachments
Message-ID: <13872559.1168985755571.JavaMail.jboss@colo-br-02.atl.jboss.com>

Does the kernel make a distinction between undeploy and shutdown with serialized attachments?  IMO, undeploy deletes the DeploymentContext's serialized attachments, while shutdown does not.

We really need this distinction for unit testing where the same jar name might be deployed numerous times and yet be entirely different internally.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002468#4002468

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002468


From do-not-reply at jboss.com  Tue Jan 16 17:31:40 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 17:31:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Bean
	definition as value add problem (JBMICROCONT-28)
Message-ID: <3501245.1168986700539.JavaMail.jboss@colo-br-02.atl.jboss.com>

So did we end up supporting this anonymous inner bean syntax? Its a bit tedious to have to reference another bean when the bean really is a contained entity with a lifecycle bound to the bean into which its being injected.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002474#4002474

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002474


From do-not-reply at jboss.com  Tue Jan 16 17:37:52 2007
From: do-not-reply at jboss.com (SmokingAPipe)
Date: Tue, 16 Jan 2007 17:37:52 -0500 (EST)
Subject: [jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Tracing
	what happens before EARDeployer starts
Message-ID: <23052757.1168987072545.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm new to JBoss internals.  I'm having a very strange problem: I have two applications in EAR files.  When I deploy them on my desktop machine here (localhost) I get normal log messages.  When I set up a virtual-host entry in jboss-web.xml, and the corresponding Host entries in jbossweb/server.xml, I get no log messages, or System.out, or anything from the web apps.

In a normal situation, the first log message I see is the EARDeployer message.  When it is on the real server with virtual hosts, the EARs do in fact deploy, but there is no EARDeployer message on console, or any other message from these EARs, no matter what logging method I use, even System.out.println().  Of course exceptions don't show up, so this whole system is almost useless in production because I can only guess at where problems are.

I have spent about three days working on this and am not getting anywyere.  My next step is to go through the JBoss source code to figure out where these log messages are being dropped.  It looks like EARDeployer is the first thing that's missing so maybe I should start there.

Can anyone suggest how I get started in the JBoss source to trace this?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002479#4002479

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002479


From do-not-reply at jboss.com  Tue Jan 16 17:37:56 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 17:37:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: shutdown vs.
	undeploy with serialized attachments
Message-ID: <3905759.1168987076955.JavaMail.jboss@colo-br-02.atl.jboss.com>

Its not a kernel notion. Its a combined usage of the MainDeployer and ProfileService. shutdown is MainDeployer.removeDeploymentContext(DeploymentContext). Undeployming is Profile.removeDeployment().

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002480#4002480

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002480


From do-not-reply at jboss.com  Tue Jan 16 18:36:46 2007
From: do-not-reply at jboss.com (adamw)
Date: Tue, 16 Jan 2007 18:36:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Navigation in Labs 2.0
Message-ID: <6047848.1168990606186.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hello,
as I'm starting to change the project pages behavior, I guess it's good time to decide how navigation will look like :)

As I suppose everybody already knows that each project will have the ability to compose its page out of a set of available portlets (via a GUI that Rysiek&Pawe? are writing). They will also be able to add additional pages with other portlets. So I think a first navigational portlet will be "Project Pages" which will simply list the pages defined for a project and enable to switch between them (of course, a project would have to add this portlet to their pages; it would be only usable when a project is selected).

Also, projects much be chosen somehow. So on the main page we would have a "Project List" portlet (or "Software Map" portlet)? That would be a second navigational portlet. How this portlet would be accessed? As I have seen on the mockups, there is no "navigation" on the left side.

A third navigational portlet would be needed for navigating between "global" Labs pages, like architects library/ wiki/ contributors/ jmm/ etc. But I think that we can do this by re-using the first one, that is, having a special "default" project, which would be hold the global content.

Waiting for your opinions :)

-- 
Adam

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002513#4002513

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002513


From do-not-reply at jboss.com  Tue Jan 16 18:43:03 2007
From: do-not-reply at jboss.com (alesj)
Date: Tue, 16 Jan 2007 18:43:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Bean
	definition as value add problem (JBMICROCONT-28)
Message-ID: <9075433.1168990983103.JavaMail.jboss@colo-br-02.atl.jboss.com>

This is done half way.
No cloning at the moment.
But you can define inner beans, with a full bean name.
And they can be referenced from other beans.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002517#4002517

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002517


From do-not-reply at jboss.com  Tue Jan 16 19:06:49 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Tue, 16 Jan 2007 19:06:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <1662983.1168992409640.JavaMail.jboss@colo-br-02.atl.jboss.com>

The way I found to skip the race condition was to guess the failoverId based on the order on the failoverMap.

So, in case we can't find the nodeID on failoverMap (meaning the CF was already updated) I will use a method that I'm calling guessFailoverId:

  
  | 
  | class ClusteringAspect...
  | 
  | 
  |  public static Integer guessFailoverID(Map failoverMap, Integer nodeID)
  |    {
  |       Integer failoverNodeID = null;
  |       Integer[] nodes = (Integer[])failoverMap.keySet().toArray(new Integer[failoverMap.size()]);
  |       // We need to sort the array first
  |       Arrays.sort(nodes);
  |       for (int i = 0; i < nodes.length; i++)
  |       {
  |          if (nodeID.intValue() < nodes.intValue())
  |          {
  |             failoverNodeID = nodes;
  |             break;
  |          }
  |       }
  |       // if still null use the first node...
  |       if (failoverNodeID==null)
  |       {
  |          failoverNodeID = nodes[0];
  |       }
  |       return failoverNodeID;
  |    }
  | 
  | 


I want to keep this method as public static just because on the process of writing it I wrote a testcase for it...  I haven't committed it yet:

org.jboss.test.messaging.jms.clustering.ClusteringAspectInternalTest


Any objections on a test for internal methods (not part of the API)?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002524#4002524

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002524


From do-not-reply at jboss.com  Tue Jan 16 19:10:56 2007
From: do-not-reply at jboss.com (timfox)
Date: Tue, 16 Jan 2007 19:10:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <9287962.1168992656775.JavaMail.jboss@colo-br-02.atl.jboss.com>

"clebert.suconic at jboss.com" wrote : I'm thinking about how to fix this race condition:
  | 
  | 
  | I - ClientClusteredConnectionFactoryDelegate has this following failoverMap:
  | 
  | Server 1->Server2->Server3->Server 1
  | 
  | II - Server1 is killed
  | 
  | III - Now the CF::failoverMap is updated to:
  | Server2->Server3->Server2
  | 
  | 

I can't see how this would happen.

When a server dies, the new failover map is created on the server according to the algorithm.

The algorithm would never create such a mapping.

So this is a non problem AFAICT.

Am I missing something?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002526#4002526

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002526


From do-not-reply at jboss.com  Tue Jan 16 19:13:52 2007
From: do-not-reply at jboss.com (timfox)
Date: Tue, 16 Jan 2007 19:13:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <10859067.1168992832386.JavaMail.jboss@colo-br-02.atl.jboss.com>

Also remember that the failover map on the client is never guaranteed to exactly mirror the server side map.

This is why we built in "server hopping", where if the client got the wrong server it wouuld just redirect to the correct server.

In the most degenerate case, even if you choos a random server it would still redirect to the corrects server, so even if slightly inefficient would end up on the correct failover server eventually.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002528#4002528

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002528


From do-not-reply at jboss.com  Tue Jan 16 19:14:28 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Tue, 16 Jan 2007 19:14:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <29029390.1168992868945.JavaMail.jboss@colo-br-02.atl.jboss.com>

Well.. I could replicate this in a testcase.. so it is a problem.


You have Server1, Server2, and Server3

Then you have a map:

1->2
2->3
3->1

Now you kill server1:

Map now is:

2->3
3>2

You don't have 1 on the MAP.

When a connection on server1 fails.. it won't find an ID on failoverMAP. I could replicate this on a testcase.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002529#4002529

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002529


From do-not-reply at jboss.com  Tue Jan 16 19:16:43 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Tue, 16 Jan 2007 19:16:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <9255102.1168993003934.JavaMail.jboss@colo-br-02.atl.jboss.com>

Also.. that's why I called this a race condition.

Case the failure is captured after the ConnectionFactory is updated for some reason...  you would have a NullPointerException.

This is not a problem on the hopping... it's a matter of not finding anything on failoverMap what would cause a NPE. That's why I introduced the guessing routine and I will trust on the Hopping case the guess didn't find the right server.  (unlikely to happen.. the guessRoutine seemed to be pretty good to me)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002531#4002531

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002531


From do-not-reply at jboss.com  Tue Jan 16 19:39:52 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Tue, 16 Jan 2007 19:39:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	SerializableDeploymentRepository notions
Message-ID: <29725085.1168994393000.JavaMail.jboss@colo-br-02.atl.jboss.com>

So, you're going to have a generic service check every timestamp of, of every file in the deployment context?  Still think it would be much simpler if the deployers control this as they know exactly what files to look for and what timestamps of what files to store in the attachment serialization.  They would even be able to control whether or not serialization is allowed for that type of deployment.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002533#4002533

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002533


From do-not-reply at jboss.com  Tue Jan 16 19:48:44 2007
From: do-not-reply at jboss.com (jazir1979)
Date: Tue, 16 Jan 2007 19:48:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: EJBTHREE-615 still
	present in Embedded-ALPHA9
Message-ID: <29461062.1168994924382.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi folks,

I just posted about this to the user forum as well, but that was before I noticed this thread.

EJBTHREE-615 is causing problems for me too.  I'd be willing to debug into it further but had similar problems to Bill when trying to find the correct source.  I couldn't even find the correct starting point for the embedded stuff...

Any pointers, or ideas when this Jira issue would be assigned to a developer?

cheers,
Daniel.

"hennejg" wrote : Bill,
  | 
  | thanks. I tried 2006-9-14 (the timestamp of the release on sf and inside the archive) but the line numbers for jbosssx (the starting point for me) just don't match with the ones from the code's debug information.
  | In fact, I'm even confused about which repository is the correct one. The version I mentioned above is from CVS. SVN also has a JBossAuthorizationManager in /repos/jbossas/projects/security et al. However, those versions lack the updateCache method.
  | 
  | Thanks!

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002535#4002535

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002535


From do-not-reply at jboss.com  Tue Jan 16 20:03:49 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 20:03:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	SerializableDeploymentRepository notions
Message-ID: <25489224.1168995829190.JavaMail.jboss@colo-br-02.atl.jboss.com>

It should be a pluggable visitor implementation. How much you want to check is up to you. Having the deployers check is essentially is a structural scan with a list of files to check. It would be better to have deployers expose the metadata vfs paths that should go into timestamp verification and feed them into a simple vfs visitor that can return the most recently modified file amongh the patterns. This is bolierplate code that every deployer should not be repeating mister monolithic deployer writer.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002539#4002539

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002539


From do-not-reply at jboss.com  Tue Jan 16 20:22:35 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 20:22:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] -
	Extracting mc base test classes into a jboss-mctest.jar
Message-ID: <17253446.1168996955494.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm wanting to run mc based tests in other projects outside of the mc and would like to leverage the abstract classes that are setting up test structures similar to what tests in the mc are doing. Can we look at what classes would go into this and pull these into a separate jbossmc/test project so we can make that a separate artifact that can be used elsewhere.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002541#4002541

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002541


From do-not-reply at jboss.com  Tue Jan 16 20:56:19 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 20:56:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Bean
	definition as value add problem (JBMICROCONT-28)
Message-ID: <23076372.1168998979411.JavaMail.jboss@colo-br-02.atl.jboss.com>

I could actually use the wildcard support to use the javabean schema if the javabean schema supported non-default constructors like this:


  |    <bean name="DsXmlDataSourceTemplateInfo"
  |       class="org.jboss.profileservice.management.plugins.BasicDeploymentTemplateInfo">
  |         <constructor>
  |            <parameter>DsXmlDataSourceTemplate</parameter>
  |            <parameter>A template for *-ds.xml deployments</parameter>
  |         </constructor>
  |         <property name="properties">
  |          <set>
  |             <javabean xmlns="urn:jboss:javabean:1.0"
  |                class="org.jboss.test.javabean.support.SimpleBean">
  |               <constructor>
  |                  <property>jndi-name</property>
  |                  <property>the jndi name to bind the DataSource under</parameter>
  |               </constructor>
  |               <property name="manadatory">true</property>
  |             </javabean>
  |          </set>
  |         </property>
  |    </bean>
  | 

I'm going to take a look at adding that support. I'll make this a urn:jboss:javabean:2.0 version schema.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002549#4002549

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002549


From do-not-reply at jboss.com  Tue Jan 16 22:02:00 2007
From: do-not-reply at jboss.com (brc135)
Date: Tue, 16 Jan 2007 22:02:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Profiler] - Profiler work for
	realtime time-series data?
Message-ID: <6838036.1169002920313.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi, I'm currently working on a research project involving JBoss where we want to monitor time-series data from JBoss.  Ideally it would be nice to monitor a bunch of different set of objects (EJBs, Servlets, methods) and some attributes on those objects (CPU, # active, etc.)

Would it be possible to read the log data while it is being created -- online?  Or does all data need to be analyzed in an offline fashion with the web app?

It would also help me in evaluation is anyone had some sample logs they could share. 

Thanks very much for help. 
Brian

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002556#4002556

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002556


From do-not-reply at jboss.com  Tue Jan 16 22:30:57 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 22:30:57 -0500 (EST)
Subject: [jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re:
	Tracing what happens before EARDeployer starts
Message-ID: <32971155.1169004657936.JavaMail.jboss@colo-br-02.atl.jboss.com>

Its a pure logging issue. You will have to start with debugging the org.jboss.logging.Logger calls. None of the deployers have dropped messages. Something has screwed up where the Logger plugin.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002564#4002564

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002564


From do-not-reply at jboss.com  Tue Jan 16 22:43:02 2007
From: do-not-reply at jboss.com (SmokingAPipe)
Date: Tue, 16 Jan 2007 22:43:02 -0500 (EST)
Subject: [jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re:
	Tracing what happens before EARDeployer starts
Message-ID: <2529897.1169005382078.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, I need to start tracing on the org.jboss.logging.Logger.  The one way to always get a message to the console, regardless of how (mis) configured loggers and System.out can be, is (thanks to Java 6) System.console.printf() so I can make an instrumented version of the org.jboss.logging.Logger.  Time for me to learn how to build JBoss parts and get them installed.  I will post what I find.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002568#4002568

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002568


From do-not-reply at jboss.com  Tue Jan 16 22:48:18 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 16 Jan 2007 22:48:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Why
	SingletonSchemaResolverFactory?
Message-ID: <6626140.1169005698563.JavaMail.jboss@colo-br-02.atl.jboss.com>

Why is the BasicXMLDeployer using the SingletonSchemaResolverFactory? This cannot be extended and does not allow one to add new schemas without modifying the existing private ctor, which mean modifying the jbossxb release:


  |    private SingletonSchemaResolverFactory()
  |    {
  |       addSchema("urn:jboss:aop-beans:1.0", "org.jboss.aop.microcontainer.beans.xml.AOPBeansSchemaInitializer", Boolean.FALSE);
  |       addSchema("urn:jboss:bean-deployer", "org.jboss.kernel.plugins.deployment.xml.BeanSchemaInitializer", Boolean.FALSE);
  |       addSchema("urn:jboss:bean-deployer:2.0", "org.jboss.kernel.plugins.deployment.xml.BeanSchemaInitializer20", Boolean.FALSE);
  |       addSchema("urn:jboss:javabean:1.0", "org.jboss.kernel.plugins.config.xml.JavaBeanSchemaInitializer", Boolean.FALSE);
  |    }
  | 

Either this should be subclassable, the mutator methods public, or BasicXMLDeployer using a different resolver factory.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002570#4002570

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002570


From do-not-reply at jboss.com  Wed Jan 17 00:07:25 2007
From: do-not-reply at jboss.com (alex.pinkin@jboss.com)
Date: Wed, 17 Jan 2007 00:07:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Maven
	build scripts
Message-ID: <5827614.1169010485626.JavaMail.jboss@colo-br-02.atl.jboss.com>

i've just added Paul to Committer group in Jira, so you should be able to assign tasks to him

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002580#4002580

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002580


From do-not-reply at jboss.com  Wed Jan 17 01:06:03 2007
From: do-not-reply at jboss.com (alesj)
Date: Wed, 17 Jan 2007 01:06:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Why
	SingletonSchemaResolverFactory?
Message-ID: <17234721.1169013963820.JavaMail.jboss@colo-br-02.atl.jboss.com>

 I used this 'hack' to temp add new Spring schema:

  |    public void setUp() throws Exception
  |    {
  |       SchemaBindingResolver resolver = SingletonSchemaResolverFactory.getInstance().getSchemaBindingResolver();
  |       DefaultSchemaResolver defaultSchemaResolver = (DefaultSchemaResolver) resolver;
  |       defaultSchemaResolver.addSchemaInitializer("urn:jboss:spring-beans:2.0", new SpringSchemaInitializer());
  |       defaultSchemaResolver.addSchemaLocation("urn:jboss:spring-beans:2.0", "mc-spring-beans_2_0.xsd");
  |       super.setUp();
  |    }
  | 

But I agree with you.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002601#4002601

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002601


From do-not-reply at jboss.com  Wed Jan 17 01:14:12 2007
From: do-not-reply at jboss.com (alesj)
Date: Wed, 17 Jan 2007 01:14:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Maven
	build scripts
Message-ID: <28198482.1169014452544.JavaMail.jboss@colo-br-02.atl.jboss.com>

Thanks Alex.
I've re-assigned the task to Paul.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002606#4002606

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002606


From do-not-reply at jboss.com  Wed Jan 17 01:22:23 2007
From: do-not-reply at jboss.com (SmokingAPipe)
Date: Wed, 17 Jan 2007 01:22:23 -0500 (EST)
Subject: [jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re:
	Tracing what happens before EARDeployer starts
Message-ID: <713394.1169014943388.JavaMail.jboss@colo-br-02.atl.jboss.com>

And the problem is solved.  One of the applications on the server was misbehaving and somehow disabling the entire logging system and System.out globally.  It would be nice if JBoss would somehow block that from happening or at least intercept it and log a warning, but anyway, it's the fault of the web app.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002609#4002609

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002609


From do-not-reply at jboss.com  Wed Jan 17 01:40:27 2007
From: do-not-reply at jboss.com (ron.sigal@jboss.com)
Date: Wed, 17 Jan 2007 01:40:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Re: Detached invokers are
	too detached from the transport
Message-ID: <16053240.1169016027418.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have implemented a version of the solution I suggested above and checked it in to the Remoting HEAD and remoting_2_x branches.

1. There are a couple of changes.  First, the listener interface, org.jboss.remoting.socketfactory.SocketCreationListener, is


  | public interface SocketCreationListener
  | {
  |    /**
  |     * Called when a socket has been created.
  |     * 
  |     * @param socket socket that has been created
  |     * @param source SocketFactory or ServerSocket that created the socket
  |     * @throws IOException
  |     */
  |    void socketCreated(Socket socket, Object source) throws IOException;
  | }
  | 

and there are two distinct configuration keys for incorporating listeners into socket factories and server sockets:

org.jboss.Remoting.SOCKET_CREATION_CLIENT_LISTENER (with value "socketCreationClientListener")

and

org.jboss.Remoting.SOCKET_CREATION_SERVER_LISTENER (with value "socketCreationServerListener")

The reason for distinguishing these is that the same configuration Map can get passed to both a server and a client.  For example, it could be passed to a Connector and then later to a Client used by the Connector to push callbacks.  Finally, to support configuration by InvokerLocator or xml, the value of the listener parameter can be the name of a class that implements SocketCreationListener and has a default constructor.

2. The solution works for the following transports:  bisocket, sslbisocket, https, multiplex, sslmultiplex, rmi, sslrmi, socket, and sslsocket.  It does not work for the http transport and for the server side of the servlet transport.  The reason it doesn't work for http is that HttpURLConnection does not expose its socket factory (though HttpsURLConnection does).  It should be possible to write a custom http protocol handler for this purpose, but I won't unless is there is a specific request.  And invocations with the servlet transport go through a servlet container, which is outside the scope of Remoting.

3. The implementation is based on the classes: CreationListenerSocketFactory, CreationListenerServerSocketFactory, and
CreationListenerServerSocket in the package org.jboss.remoting.socketfactory.  CreationListenerSocketFactory wraps the SocketFactory that would otherwise be used, and calls the listener whenever a socket is created.  CreationListenerServerSocketFactory wraps the ServerSocketFactory that would otherwise be used, and whenever a ServerSocket is created, it wraps that ServerSocket in a CreationListenerServerSocket, which calls the listener whenever it creates a socket.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002613#4002613

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002613


From do-not-reply at jboss.com  Wed Jan 17 04:25:39 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 17 Jan 2007 04:25:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <1548794.1169025939987.JavaMail.jboss@colo-br-02.atl.jboss.com>

Clebert - I am somewhat baffled about the approach you are taking here.

Can you try and describe it clearly (and slowly) so I can understand it?

Thanks.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002655#4002655

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002655


From do-not-reply at jboss.com  Wed Jan 17 04:40:09 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 17 Jan 2007 04:40:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <16492159.1169026810004.JavaMail.jboss@colo-br-02.atl.jboss.com>

"clebert.suconic at jboss.com" wrote : Well.. I could replicate this in a testcase.. so it is a problem.
  | 
  | 
  | You have Server1, Server2, and Server3
  | 
  | Then you have a map:
  | 
  | 1->2
  | 2->3
  | 3->1
  | 
  | Now you kill server1:
  | 
  | Map now is:
  | 
  | 2->3
  | 3>2
  | 
  | You don't have 1 on the MAP.
  | 
  | When a connection on server1 fails.. it won't find an ID on failoverMAP. I could replicate this on a testcase.

Surely you shouldn't update the failover map after node failure until all connections have failed over from the old server?

Then you can prevent this "race condition" from happening in the first place?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002660#4002660

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002660


From do-not-reply at jboss.com  Wed Jan 17 04:57:42 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 17 Jan 2007 04:57:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Bean
	definition as value add problem (JBMICROCONT-28)
Message-ID: <29986661.1169027862151.JavaMail.jboss@colo-br-02.atl.jboss.com>

support for javabean ctors is working:


  | <javabean xmlns="urn:jboss:javabean:2.0"
  |    class="org.jboss.test.javabean.support.SimpleBean">
  |    <!--
  |       public SimpleBean(Object anObject, String string, Byte byte1,
  |       Boolean boolean1, Character character, Short short1,
  |       Integer anInt, Long long1, Float float1, Double double1,
  |       Date date, BigDecimal bigDecimal, BigInteger bigInteger,
  |       byte abyte, boolean aboolean, char achar, short ashort,
  |       int anint2, long along, float afloat, double adouble,
  |       Number number, String overloadedProperty, String xyz, String abc)      
  |    -->
  |    <constructor>
  |       <!-- The name is not used for parameter matching, its just for info -->
  |       <property name="anObject">anObjectValue</property>
  |       <property name="AString">StringValue</property>
  |       <property name="AByte">12</property>
  |       <property name="ABoolean">true</property>
  |       <property name="ACharacter">x</property>      
  |       <property name="AShort">123</property>
  |       <property name="anInt">1234</property>
  |       <property name="ALong">12345</property>
  |       <property name="AFloat">3.14</property>
  |       <property name="ADouble">3.14e12</property>
  |       <property name="ADate">Jan 01 00:00:00 CET 2001</property>
  |       <property name="ABigDecimal">12e4</property>
  |       <property name="ABigInteger">123456</property>
  |       <property name="abyte">12</property>
  |       <property name="aboolean">true</property>
  |       <property name="achar">y</property>
  |       <property name="ashort">123</property>
  |       <property name="anint">1234</property>
  |       <property name="along">12345</property>
  |       <property name="afloat">3.14</property>
  |       <property name="adouble">3.14e12</property>
  |       <property name="ANumber" class="java.lang.Long">12345</property>
  |       <property name="overloadedProperty">StringValue</property>
  |       <property name="XYZ">XYZ</property>
  |       <property name="abc">abc</property>
  |    </constructor>
  | </javabean>
  | 

I'm not able to check these changes in currently though as svn seems to still be down from the upgrade effort.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002672#4002672

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002672


From do-not-reply at jboss.com  Wed Jan 17 08:54:25 2007
From: do-not-reply at jboss.com (bkeh12)
Date: Wed, 17 Jan 2007 08:54:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Fine
	grained action aware interfaces (JBMICROCONT-134)
Message-ID: <19985866.1169042065653.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi,adrian
Where are you ? 
alesj wrote : Currently all interfaces extend KernelControllerContextAware, which is convenient for simple awareness, but might not be that useful in all cases. 
Do you agree this!
Can talk to us, please.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002778#4002778

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002778


From do-not-reply at jboss.com  Wed Jan 17 09:07:29 2007
From: do-not-reply at jboss.com (alesj)
Date: Wed, 17 Jan 2007 09:07:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Fine
	grained action aware interfaces (JBMICROCONT-134)
Message-ID: <27114439.1169042849974.JavaMail.jboss@colo-br-02.atl.jboss.com>

Where do you see the problem?

What I meant was that if you need to be notified of the exact state (implementing multiple KCCAware interfaces) when the awareness happens, the same method is always called, and you must look into the context to figure out what the current state is.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002791#4002791

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002791


From do-not-reply at jboss.com  Wed Jan 17 09:14:05 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Wed, 17 Jan 2007 09:14:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <7190727.1169043245605.JavaMail.jboss@colo-br-02.atl.jboss.com>

normally, the portal-cms.sar will be nested in jboss-portal.sar so the problem will not exist (coordinated by the build system once all artifacts have been created)

I agree that for development we have to find a way to make it more usable.

"roy.russo at jboss.com" wrote : There are problem with the core-cms:
  | 
  | 1. You *must* deploy the jboss-portal.sar first, and then the portal-cms.sar. If you do not, the cms will not deploy at all, due to some issues with security/identity.
  | 
  | 2. If you deploy the portal-cms.sar in a running instance of AS, it will create all the resources. 
  |    a. File creation is sloooooow. 
  |    b. Also, when you log in to the cmsAdminPortlet, it doesn't show the root directory so you can't do anything. I wouldn't be surprised if this is also related to identity integration.
  | 
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002794#4002794

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002794


From do-not-reply at jboss.com  Wed Jan 17 09:55:43 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 17 Jan 2007 09:55:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <15750310.1169045743376.JavaMail.jboss@colo-br-02.atl.jboss.com>

"alesj" wrote : "adrian at jboss.org" wrote : This interface belongs in the dependency module that knows nothing about POJOs/services.
  |   | 
  | 
  | Where in the Context hierarchy should I put it?
  | 

It's upto each implementation whether it implements it.

anonymous wrote : 
  | Should KernelRegistryEntry extend it?
  | If so, how do we handle KernelRegistryPlugin entries?

You could make BasicKernelRegistryEntry implement it.
But you'd need a mechanism to get the BeanInfo for the target object of the entry.
I'm not sure it is worth the effort?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002826#4002826

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002826


From do-not-reply at jboss.com  Wed Jan 17 10:03:58 2007
From: do-not-reply at jboss.com (alesj)
Date: Wed, 17 Jan 2007 10:03:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <4753967.1169046238526.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : "alesj" wrote : "adrian at jboss.org" wrote : This interface belongs in the dependency module that knows nothing about POJOs/services.
  |   |   | 
  |   | Where in the Context hierarchy should I put it?
  |   | 
  | 
  | It's upto each implementation whether it implements it.
  | 

I did make it to extend ControllerContext. I need the target and I thought I needed name. Should I make it plain 'standalone'?

I also added getClassLoader() method - to help me with getting the param TypeInfos.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002836#4002836

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002836


From do-not-reply at jboss.com  Wed Jan 17 10:06:54 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Wed, 17 Jan 2007 10:06:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - JMS Example in 3.2 Beta
Message-ID: <6087672.1169046414426.JavaMail.jboss@colo-br-02.atl.jboss.com>

There is a JMS Example (examples/jms) in the 3.2 Beta, however it does not appear to be complete. Can anyone provide more information on this example, as I am looking to do something very similar for the ESB project.

Thanks,

Jeff

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002838#4002838

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002838


From do-not-reply at jboss.com  Wed Jan 17 10:12:32 2007
From: do-not-reply at jboss.com (roy.russo@jboss.com)
Date: Wed, 17 Jan 2007 10:12:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <2588221.1169046752151.JavaMail.jboss@colo-br-02.atl.jboss.com>

Nexting fixes the slowness and identity problems, but the CMSAdmin still doesn't show any directories.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002842#4002842

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002842


From do-not-reply at jboss.com  Wed Jan 17 10:13:22 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 17 Jan 2007 10:13:22 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Recent changes Microcontainer
Message-ID: <10100951.1169046802443.JavaMail.jboss@colo-br-02.atl.jboss.com>

"alesj" wrote : Using KernelConfigFactory to get KernelConfig (which  can provide this)?
  | 
  | Putting KernelConfig instance into Configurator?
  | It's a 'loop' usage. Looks wrong.
  | 
  | I see we are already using KernelConfig as a parameter.
  | Doing it the same here (adding it as a parameter in resolveProperty method)?
  | If I do this (just tried), then almost every method in Configurator needs it. Yuck.
  | 
  | Any other ways / ideas?
  | 

It is the KernelConfigurator that has this information.

The problem is that the current code uses a static singleton as a delegate
AbstractKernelConfigurator -> Configurator
so one way to fix would be to move the code to the AbstractKernelConfigurator
that needs kernel specific config.

Perhaps a simpler solution is to expose the TypeInfoFactory on the TypeInfo interface.

You would then be able to do

  | TypeInfoFactory typeInfoFactory = beanInfo.getClassInfo().getTypeInfoFactory();
  | TypeInfo typeInfo = typeInfoFactory.getTypeInfo(name, classLoader);
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002844#4002844

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002844


From do-not-reply at jboss.com  Wed Jan 17 10:27:44 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 17 Jan 2007 10:27:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	ManagedProperty changes
Message-ID: <11077083.1169047664391.JavaMail.jboss@colo-br-02.atl.jboss.com>

Fair enough. The only reason for requiring a ManagedObject was that
I thought the ManagedObject would be part of the identity.
i.e. two properties with the same values but belonging to different managed objects
would be different.

See the "equals" implementation.

It is generally desirable to have an immutable identity, i.e. no setManagedObject()

If the properties are going to have a standalone identity then it is not an issue.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002858#4002858

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002858


From do-not-reply at jboss.com  Wed Jan 17 10:33:53 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Wed, 17 Jan 2007 10:33:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: EJBTHREE-615 still
	present in Embedded-ALPHA9
Message-ID: <29787894.1169048033535.JavaMail.jboss@colo-br-02.atl.jboss.com>

We've totally scrapped Embedded EJB3 and started the Embedded JBoss project based on JBoss 5 kernel.  New Embedded JBoss will be full featured.  Most features of regular jboss should be available in embedded.

If you want to testdrive, checkout head SVN.  its in the jboss-head/embedded directory.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002867#4002867

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002867


From do-not-reply at jboss.com  Wed Jan 17 10:40:50 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Wed, 17 Jan 2007 10:40:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <2349770.1169048450509.JavaMail.jboss@colo-br-02.atl.jboss.com>

"roy.russo at jboss.com" wrote : Nesting fixes the slowness and identity problems, but the CMSAdmin still doesn't show any directories.

ok, I'll look into that tonight.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002870#4002870

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002870


From do-not-reply at jboss.com  Wed Jan 17 10:43:39 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Wed, 17 Jan 2007 10:43:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	SerializableDeploymentRepository notions
Message-ID: <13601873.1169048619139.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm thinking of:


  | DeploymentContext.getAttachments().addAttachment(key, value, List<VirtualFile> metaSources);
  | 

Then, when getAttachment() is called, DC scans and checks to see if that attachment should be killed.

Also, there should be additional methods on DeploymentContext:


  | 
  | getAttachments();
  | getManagedObjects();
  | 
  | 

These attachments would actually be serialized with the profile while getTransientAttachments() would not.

If i'm being too obvious, then apologies.




 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002873#4002873

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002873


From do-not-reply at jboss.com  Wed Jan 17 10:44:26 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 17 Jan 2007 10:44:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Why
	SingletonSchemaResolverFactory?
Message-ID: <32335280.1169048666051.JavaMail.jboss@colo-br-02.atl.jboss.com>

There is an MBean/POJO that can be deployed to add schemas at runtime.

The singleton is just a mechanism to setup "known ones" automatically.
i.e. factory settings.

There is a post about it somewhere in the JBossXB forum.
If search worked I could find it for you. :-)

e.g.


  | <bean name="Schemas" class="org.jboss.xb.binding.sunday.unmarshalling.SchemaResolverConfig">
  |    
  |    <!-- The initializer classes -->
  |    <property name="SchemaInitializers">
  |    urn:somenamespace=some.class.name
  |    </property>
  | 
  |    <!-- The locations these are added to JBossEntityResolver -->
  |    <property name="SchemaLocations">
  |    urn:somenamespace=schema/some.xsd
  |    </property>
  | 
  |    <!-- Only for performance if your schema is annotated, but only with coments -->
  |    <property name="ParseAnnotations">
  |    urn:somenamespace=false
  |    </property>
  | </bean>
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002874#4002874

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002874


From do-not-reply at jboss.com  Wed Jan 17 10:46:42 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 17 Jan 2007 10:46:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Why
	SingletonSchemaResolverFactory?
Message-ID: <856543.1169048802194.JavaMail.jboss@colo-br-02.atl.jboss.com>

"alesj" wrote :  I used this 'hack' to temp add new Spring schema:
  | 
  |   |    public void setUp() throws Exception
  |   |    {
  |   |       SchemaBindingResolver resolver = SingletonSchemaResolverFactory.getInstance().getSchemaBindingResolver();
  |   |       DefaultSchemaResolver defaultSchemaResolver = (DefaultSchemaResolver) resolver;
  |   |       defaultSchemaResolver.addSchemaInitializer("urn:jboss:spring-beans:2.0", new SpringSchemaInitializer());
  |   |       defaultSchemaResolver.addSchemaLocation("urn:jboss:spring-beans:2.0", "mc-spring-beans_2_0.xsd");
  |   |       super.setUp();
  |   |    }
  |   | 
  | 
  | But I agree with you.

The Spring one (and other known ones) should be added to the singleton.
If the initializer class is not in the classpath, it will ignore it.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002875#4002875

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002875


From do-not-reply at jboss.com  Wed Jan 17 10:59:59 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 17 Jan 2007 10:59:59 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Fine
	grained action aware interfaces (JBMICROCONT-134)
Message-ID: <29813672.1169049599631.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bkeh12" wrote : Hi,adrian
  | Where are you ? 
  | alesj wrote : Currently all interfaces extend KernelControllerContextAware, which is convenient for simple awareness, but might not be that useful in all cases. 
  | Do you agree this!
  | Can talk to us, please.

Personally, I have little interest in this feature. :-)
I think it is an anti-pattern of IOC for the "POJO" to implement container interfaces.

I understand that sometimes it is useful, but only for people that are trying to
"extend" the container without modifying the container itself, 
e.g. using AOP to add the interface as a mixin so you can pick and choose
which beans get certain processing.

Without more concrete usecases of these features it is difficult to come to
any conclusion on what this api should really look like.

The only reason I added it in the first place was because it mirrored the
MBeanRegistration interface from JMX.

The whole question then became more complicated when the 
"JMX Introduction" aspect couldn't decide whether it wanted be invoked
at construction or configuration. :-)

So we extended the api such that you could get a callback on any of the state transitions.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002883#4002883

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002883


From do-not-reply at jboss.com  Wed Jan 17 11:05:51 2007
From: do-not-reply at jboss.com (alesj)
Date: Wed, 17 Jan 2007 11:05:51 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Why
	SingletonSchemaResolverFactory?
Message-ID: <6424420.1169049951283.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : There is an MBean/POJO that can be deployed to add schemas at runtime.
  | 
  |   | <bean name="Schemas" class="org.jboss.xb.binding.sunday.unmarshalling.SchemaResolverConfig">
  |   | ...
  |   | 

And this beans should be installed before any other with new schema usage.
Meaning that the order matters - since those beans cannot depend on this one.
Right?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002889#4002889

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002889


From do-not-reply at jboss.com  Wed Jan 17 11:09:12 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 17 Jan 2007 11:09:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <4266932.1169050152947.JavaMail.jboss@colo-br-02.atl.jboss.com>

"alesj" wrote : 
  | I did make it to extend ControllerContext. I need the target and I thought I needed name. Should I make it plain 'standalone'?
  | 

It should be a seperate optional interface that a context can implement.
Not all contexts will have/need a notion of "dispatch".

anonymous wrote : 
  | I also added getClassLoader() method - to help me with getting the param TypeInfos.

To what? Again this should probably be a seperate interface that can be
optionally implemented.

That a context has an associated classloader is true for JMX
and sort of true for POJO (there is no first class support like the MBeanServer methods)
but is this really true of all contexts of a state machine?

Remember the dependency project is intended to be just a model
of state transitions governed by their dependencies.
The other part, i.e. what those transitions means and additional state/methods
is a property of the implementation projects.

But, that doesn't mean that the dependency project can't define optional
interfaces to allow contexts to provide add-on behaviour that
cross cuts the different implementations.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002891#4002891

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002891


From do-not-reply at jboss.com  Wed Jan 17 11:09:48 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Wed, 17 Jan 2007 11:09:48 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: JMS Example in 3.2
	Beta
Message-ID: <23003866.1169050188160.JavaMail.jboss@colo-br-02.atl.jboss.com>

i think that originated from an initial attempt to implement the jms based message service that someoen contributed.  because i didn't want to throw it away, i moved it to the examples.

i don't think we need it any more

can be removed, i think.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002893#4002893

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002893


From do-not-reply at jboss.com  Wed Jan 17 11:11:39 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 17 Jan 2007 11:11:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <3942829.1169050299461.JavaMail.jboss@colo-br-02.atl.jboss.com>

More concretely, for the case in hand - invoking a method on another context
during the install phase...

The code should be something like:

  | if (context instanceof DispatchContext)
  | {
  |    DispatchContext dc = (DispatchContext) context;
  |    dc.dispatch(...);
  | }
  | else
  | {
  |    throw new IllegalArgumentException("Cannot install, context " + context + " does not implement DispatchContext");
  | }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002896#4002896

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002896


From do-not-reply at jboss.com  Wed Jan 17 11:22:02 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Wed, 17 Jan 2007 11:22:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: JMS Example in 3.2
	Beta
Message-ID: <32756420.1169050922271.JavaMail.jboss@colo-br-02.atl.jboss.com>

Actually this looks more like a usage example - i.e., start a process vis tha command listener. I think it would be good to have such an example. This one could probably be fixed up to work.

By the way, in looking at CommandListenerBean, it looks for a jobId, which it does not appear to use except to log. What should a client starting a process via the command listener set the jobId to be (since it not really a Job)? Set it to zero?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002900#4002900

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002900


From do-not-reply at jboss.com  Wed Jan 17 11:24:40 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 17 Jan 2007 11:24:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <14208231.1169051080724.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : 
  | But, that doesn't mean that the dependency project can't define optional
  | interfaces to allow contexts to provide add-on behaviour that
  | cross cuts the different implementations.

I would also put these optional interfaces in different packages
to signify that they are not a part of the main api.
e.g. rather than org.jboss.dependency.spi.DispatchContext
something like org.jboss.depedendcy.spi.dispatch.DispatchContext

As you can probably tell, I'm a big fan of keeping packges small and to the point! ;-)

This sort of thing might look impression, but it makes it difficult to see the
wood for the trees. :-)
http://java.sun.com/javase/6/docs/api/javax/swing/package-summary.html
I'd have split the frames, widgets, layouts, etc. into different packages

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002903#4002903

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002903


From do-not-reply at jboss.com  Wed Jan 17 11:28:08 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 17 Jan 2007 11:28:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Why
	SingletonSchemaResolverFactory?
Message-ID: <17979891.1169051288572.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes, obviously it can't read minds.

Also without the MC (Spring) xsd in the bootstrap/singleton, you couldn't use
MC (Spring) xml to define this POJO either. :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002904#4002904

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002904


From do-not-reply at jboss.com  Wed Jan 17 11:32:10 2007
From: do-not-reply at jboss.com (charles.crouch@jboss.com)
Date: Wed, 17 Jan 2007 11:32:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Running with the
	full featured profile service
Message-ID: <423947.1169051530854.JavaMail.jboss@colo-br-02.atl.jboss.com>

"scott.stark at jboss.org" wrote : 
  | Ok, I was lying. A previous simple deployment creation was working, but applying changes to the template properties as is currently done in the test is not. This should be working by tonight's checkin.
  | 

I'm watching the rss feeds from fisheye for checkin's and haven't seen anything. However these are definitely behind real time so I was wondering if this checkin happened?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002907#4002907

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002907


From do-not-reply at jboss.com  Wed Jan 17 11:33:57 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 17 Jan 2007 11:33:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Why
	SingletonSchemaResolverFactory?
Message-ID: <23890226.1169051637871.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : Yes, obviously it can't read minds.
  | 
  | Also without the MC (Spring) xsd in the bootstrap/singleton, you couldn't use
  | MC (Spring) xml to define this POJO either. :-)

Well actually you could if you know the system location of the xsd.

But that isn't very nice.

Which is better, having to know the schema that is going to be used and its location


  | <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  |             xsi:schemaLocation="urn:jboss:bean-deployer bean-deployer_1_0.xsd"
  |             xmlns="urn:jboss:bean-deployer">
  | 

or just specifying the namespace?


  | <deployment xmlns="urn:jboss:bean-deployer">
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002908#4002908

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002908


From do-not-reply at jboss.com  Wed Jan 17 11:37:49 2007
From: do-not-reply at jboss.com (alesj)
Date: Wed, 17 Jan 2007 11:37:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <12413501.1169051869368.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : 
  | To what? Again this should probably be a seperate interface that can be
  | optionally implemented.
  | 
  | That a context has an associated classloader is true for JMX
  | and sort of true for POJO (there is no first class support like the MBeanServer methods)
  | But is this really true of all contexts of a state machine?
  | 

So we should split DispatchContext into simple get/set interface and 'advanced' interface with invoke, target, classloader.

Since how else would you get the parameters and signatures?


  |    protected Object invoke(KernelConfigurator configurator, DispatchContext context, String name, List<ParameterMetaData> params) throws Throwable
  |    {
  |       String[] signature;
  |       Object[] parameters;
  |       if (params == null || params.isEmpty())
  |       {
  |          signature = new String[0];
  |          parameters = new Object[0];
  |       }
  |       else
  |       {
  |          int size = params.size();
  |          signature = Configurator.getParameterTypes(log.isTraceEnabled(), params);
  |          Object target = context.getTarget();
  |          // TODO - is this ok for non-POJO targets?
  |          if (target != null)
  |          {
  |             MethodInfo methodInfo = Configurator.findMethodInfo(configurator.getClassInfo(target.getClass()), name, signature);
  |             parameters = Configurator.getParameters(log.isTraceEnabled(), context.getClassLoader(), methodInfo.getParameterTypes(), params);
  |             // add some more info, if not yet set
  |             for(int j = 0; j < size; j++)
  |             {
  |                if (signature[j] == null)
  |                {
  |                   signature[j] = methodInfo.getParameterTypes()[j].getName();
  |                }
  |             }
  |          }
  |          else
  |          {
  |             parameters = new Object[size];
  |             ClassLoader classLoader = context.getClassLoader();
  |             for (int i = 0; i < size; i++)
  |             {
  |                ParameterMetaData pmd = params.get(i);
  |                TypeInfo typeInfo = null;
  |                if (signature[j] != null)
  |                {
  |                   typeInfo = configurator.getClassInfo(signature[j], classLoader);
  |                }
  |                // typeInfo might be null, but we can still get value in some cases
  |                parameters[j] = pmd.getValue().getValue(typeInfo, classLoader);
  |             }
  | 
  |          }
  |       }
  |       return context.invoke(name, parameters, signature);
  |    }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002911#4002911

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002911


From do-not-reply at jboss.com  Wed Jan 17 11:46:58 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Wed, 17 Jan 2007 11:46:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - new build script
	updates committed
Message-ID: <31915258.1169052418668.JavaMail.jboss@colo-br-02.atl.jboss.com>

let me know if you have a problem with them

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002916#4002916

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002916


From do-not-reply at jboss.com  Wed Jan 17 11:47:45 2007
From: do-not-reply at jboss.com (alesj)
Date: Wed, 17 Jan 2007 11:47:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: bean/mbean
	integration issue
Message-ID: <14564647.1169052465805.JavaMail.jboss@colo-br-02.atl.jboss.com>

I separated the DispatchContext into two interfaces = AttributeDispatchContext and InvokeDispatchContext:


  | public interface AttributeDispatchContext
  | {
  |    /**
  |     * Getter property / attribute
  |     *
  |     * @param name
  |     * @return target's property / attribute instance
  |     * @throws Throwable
  |     */
  |    Object get(String name) throws Throwable;
  | 
  |    /**
  |     * Setter property / attribute
  |     *
  |     * @param name
  |     * @param value set target's property / attribute instance
  |     * @throws Throwable
  |     */
  |    void set(String name, Object value) throws Throwable;
  | }
  | 
  | public interface InvokeDispatchContext extends AttributeDispatchContext
  | {
  |    /**
  |     * Invoke method / operation
  |     *
  |     * @param name
  |     * @param parameters
  |     * @param signature
  |     * @return inovocation's return object
  |     * @throws Throwable
  |     */
  |    Object invoke(String name, Object parameters[], String[] signature) throws Throwable;
  | 
  |    /**
  |     * Get any target
  |     *
  |     * @return the target
  |     */
  |    Object getTarget();
  | 
  |    /**
  |     * Get context's classloader.
  |     * Used when determining type info for parameter and
  |     * getting the parameter actual value.
  |     *
  |     * @return context's classloader
  |     * @throws Throwable
  |     */
  |    ClassLoader getClassLoader() throws Throwable;
  | }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002917#4002917

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002917


From do-not-reply at jboss.com  Wed Jan 17 11:57:03 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Wed, 17 Jan 2007 11:57:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: JMS Example in 3.2
	Beta
Message-ID: <30678998.1169053023306.JavaMail.jboss@colo-br-02.atl.jboss.com>

I see another issue with using the CommandListenerInterface to start a process: the NewProcessInstanceCommand does not automatically signal the processInstance to advance the token. Thus, a second JMS message is required to signal the processInstance, but since the original message has no way to return a processInstanceId, there is no way to know which processInstance to signal. Also, the SignalCommand has a tokenId, but no processInstanceId (even if there were a way to return the processInstanceId).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002928#4002928

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002928


From do-not-reply at jboss.com  Wed Jan 17 11:59:30 2007
From: do-not-reply at jboss.com (pgier)
Date: Wed, 17 Jan 2007 11:59:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] -
	Update to maven pom.xml
Message-ID: <29250517.1169053170186.JavaMail.jboss@colo-br-02.atl.jboss.com>

I updated the maven build script (pom.xml) because I noticed a couple things weren't working (missing dependencies, some files not compiling).
A couple things to note: the JRockit source files are skipped because they are dependent on a file not in the maven repo.  And the JUnit tests are skipped for now.  But the project builds ok, and I put a snapshot version in the maven repository.


  | <project xmlns="http://maven.apache.org/POM/4.0.0"
  | 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  | 	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  | 	<modelVersion>4.0.0</modelVersion>
  | 	<groupId>jboss</groupId>
  | 	<artifactId>jboss-aop</artifactId>
  | 	<packaging>jar</packaging>
  | 	<version>snapshot</version>
  | 	<name>Maven Quick Start Archetype</name>
  | 	<url>http://maven.apache.org</url>
  | 
  |       <repositories>
  |         <repository>
  |           <id>jboss</id>
  |           <name>JBoss Inc. Repository</name>
  |           <layout>default</layout>
  |           <url>http://repository.jboss.com/maven2/</url>
  |           <snapshots>
  |             <enabled>true</enabled>
  |           </snapshots>
  |         </repository>
  |       </repositories>
  |   
  | 	<build>
  | 		<sourceDirectory>src/main/</sourceDirectory>
  | 		<testSourceDirectory>src/test/</testSourceDirectory>
  | 		<plugins>
  | 			<plugin>
  | 				<groupId>org.apache.maven.plugins</groupId>
  | 				<artifactId>maven-compiler-plugin</artifactId>
  | 				<configuration>
  | 					<source>1.5</source>
  | 					<target>1.5</target>
  |                     <excludes>
  |                         <exclude>org/jboss/aop/hook/JRockit*</exclude>
  |                     </excludes>
  | 				</configuration>
  | 			</plugin>
  |             <plugin>
  |                 <groupId>org.apache.maven.plugins</groupId>
  |                 <artifactId>maven-surefire-plugin</artifactId>
  |                 <configuration>
  |                     <skip>true</skip>
  |                 </configuration>
  |             </plugin>
  | 		</plugins>
  | 	</build>
  | 
  | 	<dependencies>
  | 		<dependency>
  | 			<groupId>ant</groupId>
  | 			<artifactId>ant</artifactId>
  | 			<version>1.6.5</version>
  | 		</dependency>
  | 		<dependency>
  | 			<groupId>javassist</groupId>
  | 			<artifactId>javassist</artifactId>
  | 			<version>3.4.GA</version>
  | 		</dependency>
  | 		<dependency>
  | 			<groupId>jboss</groupId>
  | 			<artifactId>jboss-dependency</artifactId>
  | 			<version>2.0.0.Beta</version>
  | 		</dependency>
  | 		<dependency>
  | 			<groupId>jboss</groupId>
  | 			<artifactId>jboss-container</artifactId>
  | 			<version>2.0.0.Beta</version>
  | 		</dependency>
  |         <dependency>
  |             <groupId>jboss</groupId>
  |             <artifactId>jboss-test</artifactId>
  |             <version>1.0.1.GA</version>
  |             <scope>test</scope>
  |         </dependency>
  |         <dependency>
  |             <groupId>jboss.profiler.jvmti</groupId>
  |             <artifactId>jboss-profiler-jvmti</artifactId>
  |             <version>1.0.0.CR5</version>
  |             <scope>test</scope>
  |         </dependency>
  | 		<dependency>
  | 			<groupId>junit</groupId>
  | 			<artifactId>junit</artifactId>
  | 			<version>3.8.1</version>
  | 			<scope>test</scope>
  | 		</dependency>
  | 		<dependency>
  | 			<groupId>oswego-concurrent</groupId>
  | 			<artifactId>concurrent</artifactId>
  | 			<version>1.3.4</version>
  | 		</dependency>
  | 		<dependency>
  | 			<groupId>qdox</groupId>
  | 			<artifactId>qdox</artifactId>
  | 			<version>1.6</version>
  | 		</dependency>
  | 		<dependency>
  | 			<groupId>trove</groupId>
  | 			<artifactId>trove</artifactId>
  | 			<version>2.1.1</version>
  | 		</dependency>
  | 	</dependencies>
  |     
  |     <distributionManagement>
  |         <repository>
  |             <id>cvs-file-repository</id>
  |             <!-- Set maven.cvs.root in your maven/conf/settings.xml
  |             See http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCommonProject
  |             -->
  |         <url>file://${maven.cvs.root}</url>
  |         </repository>
  |     </distributionManagement>
  | 
  | </project>
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002930#4002930

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002930


From do-not-reply at jboss.com  Wed Jan 17 12:15:02 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Wed, 17 Jan 2007 12:15:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re:
	Update to maven pom.xml
Message-ID: <7424037.1169054102718.JavaMail.jboss@colo-br-02.atl.jboss.com>

Thank you. I've been burying my head in the sand and still know nothing about maven. Do you have commit access, or is there something I need to do?  :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002941#4002941

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002941


From do-not-reply at jboss.com  Wed Jan 17 12:18:24 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 17 Jan 2007 12:18:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: Running with the
	full featured profile service
Message-ID: <2623555.1169054304594.JavaMail.jboss@colo-br-02.atl.jboss.com>

No as svn was down past 2am. It won't be until latter today now.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002942#4002942

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002942


From do-not-reply at jboss.com  Wed Jan 17 12:32:15 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 17 Jan 2007 12:32:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	SerializableDeploymentRepository notions
Message-ID: <5022889.1169055135663.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bill.burke at jboss.com" wrote : I'm thinking of:
  | 
  | 
  |   | DeploymentContext.getAttachments().addAttachment(key, value, List<VirtualFile> metaSources);
  |   | 
  | 
  | Then, when getAttachment() is called, DC scans and checks to see if that attachment should be killed.
  | 
It should be the repository that scans the deployment and throws aways preprocessed content, not the DC. The repository could already have an index of metadata files, etc. I would rather have the api just provide the DC relative metadata file path than the full VirtualFile.

"bill.burke at jboss.com" wrote : 
  | Also, there should be additional methods on DeploymentContext:
  | 
  | 
  |   | getAttachments();
  |   | getManagedObjects();
  |   | 
  | 
  | These attachments would actually be serialized with the profile while getTransientAttachments() would not.
  | 
  | If i'm being too obvious, then apologies.
  |  
There is no difference between getAttachments() and getManagedObjects(). Both are attachments, or are you saying you want to express a DC ManagedObject at that level rather than use the ManagedObjectBuilder:

  | public interface ManagedObjectBuilder
  | {
  |    /**
  |     * Build managed objects for this deployment context
  |     * 
  |     * @param unit the deployment unit
  |     * @param managedObjects the managed objects
  |     * @throws DeploymentException
  |     */
  |    void build(DeploymentUnit unit, Map<String, ManagedObject> managedObjects) throws DeploymentException;
  | }
  | 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002948#4002948

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002948


From do-not-reply at jboss.com  Wed Jan 17 12:43:15 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Wed, 17 Jan 2007 12:43:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <11787848.1169055795152.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : Then you can prevent this "race condition" from happening in the first place?

The server side doesn't know about failed Connections... it will send the callback as soon as the view was changed. 

To replicate this race condition I had to disable Lease on the client side. And have connections opened on different servers.

Maybe it wouldn't occur in regular circunstances, but I wanted to prevent such behavior. 

The guess routine could find the right failoverServer fixing the race condition.

Holding the update somewhere waiting failover to perform on all connections would require a lot of coding... while the simple guess routine could fix the problem.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002952#4002952

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002952


From do-not-reply at jboss.com  Wed Jan 17 13:00:18 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 17 Jan 2007 13:00:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <17607473.1169056818453.JavaMail.jboss@colo-br-02.atl.jboss.com>

No need to guess, just choose a random server and hopping will take care of the rest.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002960#4002960

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002960


From do-not-reply at jboss.com  Wed Jan 17 13:04:04 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Wed, 17 Jan 2007 13:04:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <23744978.1169057044103.JavaMail.jboss@colo-br-02.atl.jboss.com>

Is there a problem on the guess be the random server?

That would diminish the probability of a hopping to happen.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002961#4002961

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002961


From do-not-reply at jboss.com  Wed Jan 17 13:05:21 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 17 Jan 2007 13:05:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <24963035.1169057121219.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes fine, but let's not overcomplicate things :)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002962#4002962

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002962


From do-not-reply at jboss.com  Wed Jan 17 13:23:21 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Wed, 17 Jan 2007 13:23:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Problem logging onto
	3.2 web console in jboss4.0.5 - user.pr
Message-ID: <19685794.1169058201857.JavaMail.jboss@colo-br-02.atl.jboss.com>

I dropped the jbpm-enterprise.ear and jbpm-ds into jBoss-4.0.5.GA default/deploy directory and started up. However, I have a problem logging onto web console - exception says:

[User/RolesLoginModule] Failed to load users/passwords/roles fails
java.io.IOException: No properties files: user.properties or defaults: default.Users.properties found

Turns out jbpm-jpdl-3.2.Beta1/server/jbpm/conf/login-config has it's application-policy "other" modified to use the jbpm identity tables. Having added this, I still can't login, but the exception has gone away.

I think it would be better to create a jbpm application-policy rather than changing other, reference this is the console's web.xml, and document the need to add it to the standard login-config.

 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002967#4002967

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002967


From do-not-reply at jboss.com  Wed Jan 17 13:32:51 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Wed, 17 Jan 2007 13:32:51 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	SerializableDeploymentRepository notions
Message-ID: <11532679.1169058771429.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : There is no difference between getAttachments() and getManagedObjects(). Both are attachments, or are you saying you want to express a DC ManagedObject at that level rather than use the ManagedObjectBuilder: ]
  | 
  | Im saying that I want to be able to control which attachments get serialized and which dont (like our Payload shit in INvocation)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002971#4002971

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002971


From do-not-reply at jboss.com  Wed Jan 17 13:42:02 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Wed, 17 Jan 2007 13:42:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Can't deploy
	processdefinition from GPD into jBPM 3.2 - tran
Message-ID: <6979187.1169059322388.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have jbpm-enterprise deployed into jboss-4.0.5.GA. When I try to deploy a processdefinition from the jbpm examples directory, I get an exception:

org.hibernate.HibernateException: Unable to locate current JTA transaction

What transaction behavior is the console expecting? The hibernate.cfg.xml file in the web-inf/classes directory has the transaction-related properties commented out.

How does the console application configure itself for enterprise vs non-enterprise deployment with regard to transaction behavior? In the enterprise case, transactions should be managed by the container (and set to false in jbpm.cfg.xml isTransactionEnabled), and in the non-enterprise case, jbpm transaction must be enabled.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002972#4002972

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002972


From do-not-reply at jboss.com  Wed Jan 17 14:12:20 2007
From: do-not-reply at jboss.com (dwin)
Date: Wed, 17 Jan 2007 14:12:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Design of
	wsimport
Message-ID: <7027760.1169061140827.JavaMail.jboss@colo-br-02.atl.jboss.com>

Just curious, when do you guys think this will be released?  

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002981#4002981

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002981


From do-not-reply at jboss.com  Wed Jan 17 14:14:33 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Wed, 17 Jan 2007 14:14:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Soap with
	Attachments and document/literal
Message-ID: <31994621.1169061273385.JavaMail.jboss@colo-br-02.atl.jboss.com>

I am just trying to deploy another example I was looking at based on the original test for JBWS-1384.  My WSDL defines the attachment but it is not mapped to any parameters on the SEI - The endpoint accesses the attachment through the SOAPMessage class.

However deployment now fails with the following error: -

anonymous wrote : 20:07:03,480 ERROR [ServiceEndpointDeployer] Cannot create service endpoint
  | org.jboss.ws.WSException: Cannot obtain method parameter mapping for message part 'mimepart' in wsdl operation: publishPhoto
  |         at org.jboss.ws.metadata.builder.jaxrpc.JAXRPCMetaDataBuilder.buildInputParameter(JAXRPCMetaDataBuilder.java:245)
  |         at org.jboss.ws.metadata.builder.jaxrpc.JAXRPCMetaDataBuilder.processBindingParameters(JAXRPCMetaDataBuilder.java:395)
  |         at org.jboss.ws.metadata.builder.jaxrpc.JAXRPCMetaDataBuilder.buildParameterMetaDataDoc(JAXRPCMetaDataBuilder.java:867)
  |         at org.jboss.ws.metadata.builder.jaxrpc.JAXRPCMetaDataBuilder.setupOperationsFromWSDL(JAXRPCMetaDataBuilder.java:215)
  |         at org.jboss.ws.metadata.builder.jaxrpc.JAXRPCServerMetaDataBuilder.buildMetaData(JAXRPCServerMetaDataBuilder.java:219)
  |         at org.jboss.ws.core.server.ServiceEndpointDeployer.create(ServiceEndpointDeployer.java:81)
  |         at org.jboss.ws.integration.jboss42.DeployerInterceptor.createServiceEndpoint(DeployerInterceptor.java:127)
  |         at org.jboss.ws.integration.jboss42.DeployerInterceptorJSE.createServiceEndpoint(DeployerInterceptorJSE.java:130)
  |         at org.jboss.ws.integration.jboss42.DeployerInterceptor.create(DeployerInterceptor.java:78)
  |         at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
  |         at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
  |         at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
  |         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
  |         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
  |         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
  | 

Does this now mean that all attachments need to be mapped or should we be allowing them to be unmapped so if no mapping is found the attachment can just be retrieved using the SOAPMessage class?  I can take a look if it is the latter, I am just really trying to build up a picture of all the ways attachments can be mapped so I can this into account in wstools.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002982#4002982

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002982


From do-not-reply at jboss.com  Wed Jan 17 14:26:56 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Wed, 17 Jan 2007 14:26:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <3028353.1169062016977.JavaMail.jboss@colo-br-02.atl.jboss.com>

"timfox" wrote : Clebert - I am somewhat baffled about the approach you are taking here.
  | 
  | Can you try and describe it clearly (and slowly) so I can understand it?
  | 
  | Thanks.

I just realized this message on the forum... So here is what I'm doing:

I - I am modifying CallbackManager to also receive a new message object, that will contain information about the update ClusteredConnectionFactories.

II - Every time ConnectionFactoryJNDIMapper is updated, it will send the update message on all active connections. I will be using the ConnectionManager on ServerPeer to navigate on existent connections.

III - On the client side, when the connection receives the update message, it will update its ClusteredConnectionFactory.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002985#4002985

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002985


From do-not-reply at jboss.com  Wed Jan 17 14:26:59 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Wed, 17 Jan 2007 14:26:59 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Problem logging
	onto 3.2 web console in jboss4.0.5 - use
Message-ID: <2873229.1169062019538.JavaMail.jboss@colo-br-02.atl.jboss.com>

i didn't test with 4.0.5 yet.  only 4.0.4.

i'll try and see if i can get it running on 4.0.5 tomorrow.

today i also created a jbpm security domain and a JbpmDS and a jbpm hsqldb.  This to make jbpm default deployments decoupled from any other things deployed.

so that might already be fixed.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002986#4002986

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002986


From do-not-reply at jboss.com  Wed Jan 17 14:34:53 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Wed, 17 Jan 2007 14:34:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <30728531.1169062493441.JavaMail.jboss@colo-br-02.atl.jboss.com>

ah yes.  i'll check tomorrow on how fast we can fix this.

the only way that i could configure hibernate with jta was if i address it from inside an ejb and use cmt (bmt should also be possible).

the idea was that the web app console would talk to jbpm by means of the command pattern.  then the console has to be configured with a command service implementation that takes commands and executes them.  So the command service is pluggable.  The POJO implementation would just create a jbpm context and execute the command.  The enterprise version of the command service delegates to the command service SLSB.  That SLSB demarcates the transaction.

this is all implemented except for the webconsole using the command pattern.    I don't know where we stand on that.  David, can you comment.   I know this has not been in the priorities for you in the 3.2 release.  So no problem if it's not done.  Just curious on how difficult you think this would be.  I might do this myself.

Alternatively, we could consider introducing configurable BMT in the webconsole (with a filter?)

I'll have a closer look tomorrow morning.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002987#4002987

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002987


From do-not-reply at jboss.com  Wed Jan 17 14:41:54 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Wed, 17 Jan 2007 14:41:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: JMS Example in 3.2
	Beta
Message-ID: <586036.1169062914957.JavaMail.jboss@colo-br-02.atl.jboss.com>

there is a composite command.  so you can chain commands.  commands can pass a return value to the next command in the chain.

that way it should be possible to combine the commands (even in one tx)

but double check what i'm saying cause it was a long time ago and i might not remember correctly

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002992#4002992

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002992


From do-not-reply at jboss.com  Wed Jan 17 14:50:04 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Wed, 17 Jan 2007 14:50:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: JMS Example in 3.2
	Beta
Message-ID: <29269859.1169063404965.JavaMail.jboss@colo-br-02.atl.jboss.com>

The problem here is that the second command (SignalCommand) needs the tokenId created from executing the first command (NewProcessInstanceCommand).

Another approach would be to hace the NewProcessInstanceCommand signal when there are no start tasks. It is hard to imagine any other situation where the user would want to create a processInstance and not signal it.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003002#4003002

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003002


From do-not-reply at jboss.com  Wed Jan 17 15:10:29 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 17 Jan 2007 15:10:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <5658763.1169064629138.JavaMail.jboss@colo-br-02.atl.jboss.com>

What benefit does using an ejb for this purpose provide, apart from transaction management?

I think making transaction handling configurable is more appropriate.  The web application should be able to use the jbpm api without adding a layer of abstraction upon it.  The only difference in an enterprise environment should be how jbpm manages the transaction internally.  In the standalone case it would use hibernate directly (for example); in the enterprise case it would use JTA to locate/create and manage the transaction.  But it should all happen behind the scenes; the jbpm txn management api should handle this transparently.

I'm not sure I like the idea of redoing the web application actions in terms of the command pattern,  because I wouldn't expect users to have to think in those terms; in many ways this application is a definitive jbpm example application.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003017#4003017

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003017


From do-not-reply at jboss.com  Wed Jan 17 15:14:19 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 17 Jan 2007 15:14:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <12813465.1169064859243.JavaMail.jboss@colo-br-02.atl.jboss.com>

Amendment: I should say, I wouldn't want to put this kind of implementation inside of the web application.

If you think the jbpm core api should have a (replacement or supplemental) command pattern-based interface, that would work.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003018#4003018

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003018


From do-not-reply at jboss.com  Wed Jan 17 15:17:45 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 17 Jan 2007 15:17:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <25541427.1169065065086.JavaMail.jboss@colo-br-02.atl.jboss.com>

Looking around *yet more*, it looks like there is at least a partial command api in there... I dunno, I guess I'll do whatever you'd like :-)



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003020#4003020

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003020


From do-not-reply at jboss.com  Wed Jan 17 15:19:50 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Wed, 17 Jan 2007 15:19:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <22892957.1169065190896.JavaMail.jboss@colo-br-02.atl.jboss.com>

So what you need to do to make it configurable is in two files:

1) hibernate.cfg.xml needs to be transaction enabled - see the one in jbpm-configs (or perhaps remove your copy from classes when deployed as part of the ear ? will you find it on the application classpath - I think so?) 

By the way, I think this file should use JTA not CMT. CMT assume the container has always started a transaction, and hibernate will never attempt to. If JTA, then hibernate will start one if none exists. If you are not using the CommandInterface, you need Hibernate to start one.

2) jbpm.cfg.xml - need to specify isTransactionEnabled to false. Again see the one in jbpm-configs.

I will remove the versions of these files from the web-console.war, change CMT to JTA, and see if the correct ones are picked up.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003021#4003021

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003021


From do-not-reply at jboss.com  Wed Jan 17 15:22:45 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Wed, 17 Jan 2007 15:22:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <19843447.1169065365024.JavaMail.jboss@colo-br-02.atl.jboss.com>

Also, I don't think the console should use the Command interface at this point in the 3.2 lifecycle. I don't think the Command interface has been tested thoroughly, and though it's meant to be extensible, you might wind up have to create several new commands to do what you need (which could be time consuming).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003022#4003022

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003022


From do-not-reply at jboss.com  Wed Jan 17 15:26:12 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Wed, 17 Jan 2007 15:26:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <23825457.1169065572594.JavaMail.jboss@colo-br-02.atl.jboss.com>

Actually, I see that the jbpm-console.war that is inside the jbpm-enterprise ear is different and DOES NOT contain the hibernate and jbpm.cfg.xml files.

So I think the problem is the CMT vs JTA, and will make this change and re-test.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003025#4003025

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003025


From do-not-reply at jboss.com  Wed Jan 17 15:56:00 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Wed, 17 Jan 2007 15:56:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <30806066.1169067360655.JavaMail.jboss@colo-br-02.atl.jboss.com>

It is fixed.

Actually it was the fact that the User/CMS security integration was not enabled (I was planning to do that tonight according to my migration plan).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003030#4003030

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003030


From do-not-reply at jboss.com  Wed Jan 17 16:11:35 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Wed, 17 Jan 2007 16:11:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Soap with
	Attachments and document/literal
Message-ID: <31371250.1169068295711.JavaMail.jboss@colo-br-02.atl.jboss.com>

Related to my last post should we be able to support complex types that contain elements of type swaRef?

Taking the following extract from my WSDL: -


  |   <schema targetNamespace='http://www.jboss.org/support/photoalbum/types' 
  |           xmlns='http://www.w3.org/2001/XMLSchema' 
  |           xmlns:soap11-enc='http://schemas.xmlsoap.org/soap/encoding/' 
  |           xmlns:tns='http://www.jboss.org/support/photoalbum/types' 
  |           xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
  |    <complexType name='Photo'>
  |     <sequence>
  |      <element name='caption' nillable='true' type='string'/>
  |      <element name='image' nillable='true' type='string'/>
  |     </sequence>
  |    </complexType>
  |    <element name='publishPhoto' type='tns:Photo'/>
  |    <element name='publishPhotoResponse' type='int'/>
  |   </schema>
  |  </types>
  | 
  |  <message name='AlbumEndpoint_publishPhoto'>
  |   <part element='ns1:publishPhoto' name='publishPhoto'/>
  |   <part name='mimepart' type='xsd:hexBinary'/>    
  |  </message>

If swaRef is supported I would have though that mapping the attachment to a parameter on the SEI should be mandatory as in this case the swaRef can reference the attachment instead.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003036#4003036

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003036


From do-not-reply at jboss.com  Wed Jan 17 16:12:35 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Wed, 17 Jan 2007 16:12:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Soap with
	Attachments and document/literal
Message-ID: <30962243.1169068355948.JavaMail.jboss@colo-br-02.atl.jboss.com>

Forget that, that is the wrong WSDL extract.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003039#4003039

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003039


From do-not-reply at jboss.com  Wed Jan 17 16:14:28 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Wed, 17 Jan 2007 16:14:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Soap with
	Attachments and document/literal
Message-ID: <32475239.1169068468377.JavaMail.jboss@colo-br-02.atl.jboss.com>

Here is the correct extract: -

  <schema targetNamespace='http://www.jboss.org/support/photoalbum/types' 
  |           xmlns='http://www.w3.org/2001/XMLSchema' 
  |           xmlns:soap11-enc='http://schemas.xmlsoap.org/soap/encoding/' 
  |           xmlns:tns='http://www.jboss.org/support/photoalbum/types' 
  |           xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
  |           xmlns:ref='http://ws-i.org/profiles/basic/1.1/xsd'>
  |    <complexType name='Photo'>
  |     <sequence>
  |      <element name='caption' nillable='true' type='string'/>
  |      <element name='image' type='ref:swaRef'/>
  |     </sequence>
  |    </complexType>
  |    <element name='publishPhoto' type='tns:Photo'/>
  |    <element name='publishPhotoResponse' type='int'/>
  |   </schema>
  |  </types>
  | 
  |  <message name='AlbumEndpoint_publishPhoto'>
  |   <part element='ns1:publishPhoto' name='publishPhoto'/>
  |   <part name='mimepart' type='xsd:hexBinary'/>    
  |  </message>

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003040#4003040

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003040


From do-not-reply at jboss.com  Wed Jan 17 16:25:03 2007
From: do-not-reply at jboss.com (genman)
Date: Wed, 17 Jan 2007 16:25:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] -
	markNodeCurrentlyInUse() - race condition
Message-ID: <3605401.1169069103064.JavaMail.jboss@colo-br-02.atl.jboss.com>

It seems to me that Region#markNodeCurrentlyInUse() does not really do what it is supposed to do.

Basically, it adds an event to the queue. And what can happen is that 4 seconds later (say, if event queue processing is every 4 seconds), is that the node can disappear after this method is called.

Doesn't this make this method fairly useless?

Shouldn't there just be a method on a Node to prevent eviction?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003044#4003044

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003044


From do-not-reply at jboss.com  Wed Jan 17 16:25:30 2007
From: do-not-reply at jboss.com (jazir1979)
Date: Wed, 17 Jan 2007 16:25:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: EJBTHREE-615 still
	present in Embedded-ALPHA9
Message-ID: <9800771.1169069130818.JavaMail.jboss@colo-br-02.atl.jboss.com>


oh, i see!! thanks for the info..

"bill.burke at jboss.com" wrote : We've totally scrapped Embedded EJB3 and started the Embedded JBoss project based on JBoss 5 kernel.  New Embedded JBoss will be full featured.  Most features of regular jboss should be available in embedded.
  | 
  | If you want to testdrive, checkout head SVN.  its in the jboss-head/embedded directory.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003045#4003045

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003045


From do-not-reply at jboss.com  Wed Jan 17 17:19:11 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Wed, 17 Jan 2007 17:19:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <1916473.1169072351585.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have modularized management integration into core as well.

Thomas can you check it ?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003061#4003061

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003061


From do-not-reply at jboss.com  Wed Jan 17 17:46:44 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 17 Jan 2007 17:46:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Message bridge committed
Message-ID: <33080287.1169074004585.JavaMail.jboss@colo-br-02.atl.jboss.com>

The new message bridge has been committed in TRUNK. http://jira.jboss.com/jira/browse/JBMESSAGING-264

The message bridge is a component which forwards messages from one destination to another. The source and target destinations can be one the same server
or on different remote servers.

The bridge should work with any JMS 1.1 compliant JMS server, although has only been tested with JBM.

The bridge comes as a non MBean class, and also has an MBean wrapper so can be deployed on the JBoss AS JMS spine.

When using the bridge you specify a desired quality of service, this can be one of:

QOS_AT_MOST_ONCE

With this QoS mode messages will reach the destination from the source at most once.
The messages are consumed from the source and acknowledged
before sending to the destination. Therefore there is a possibility that if failure occurs between removing them from the source and them arriving at the destination they could be lost. Hence delivery will occur at most once.
This mode is avilable for both persistent and non persistent messages.

QOS_DUPLICATES_OK

With this QoS mode, the messages are consumed from the source and then acknowledged after they have been successfully sent to the destination. Therefore there is a possibility that if failure occurs after sending to the destination but before acknowledging them, they could be sent again
when the system recovers. I.e. the destination might receive duplicates after a failure.
This mode is available for both persistent and non persistent messages.
    
QOS_ONCE_AND_ONLY_ONCE

This QoS mode ensures messages will reach the destination from the source once and only once.
(Sometimes this mode is known as "exactly once").
If both the source and the destination are on the same JBoss Messaging server instance (same resource manager) then this can be achieved by simply sending and acknowledging the messages in the same local transaction. The bridge will automatically detect this and use a local tx as appropriate.
If the source and destination are on different servers (different resource managers) this is achieved by enlisting the sending and consuming sessions in a JTA transaction. The JTA transaction is controlled by JBoss Transactions JTA implementation thus providing a very high degree of durability.
If JTA is required then both supplied connection factories need to be XAConnectionFactory implementations.
This mode is only available for persistent messages.
This is likely to be the slowest mode since it requires extra persistence for the transaction logging.
     
One thing to note:
For a specific application it may possible to provide once and only once semantics without using the
QOS_ONCE_AND_ONLY_ONCE QoS level. This can be done by using the QOS_DUPLICATES_OK mode and then checking for duplicates at the destination and discarding them. Some JMS servers provide automatic duplicate message detection functionality, or this may be possible to implement on the application level by maintaining a cache of received
message ids on disk and comparing received messages to them. The cache would only be valid for a certain period of time so this approach is not as watertight as using QOS_ONCE_AND_ONLY_ONCE but may be a good choice depending on your specific application but it less general than using JTA.

Other stuff:

The bridge can be started and stopped, or temporarily paused and resumed.

A maximum message batch size can be specified for the bridge, the bridge will then consume and forward messags in batches of this size.
This is likely to be more performant then consuming / sending one by one.

A maximum batch time can also be configured. If so, then if less than maxBatchSize messages have been consumed then the batch will be sent if the maxBatchTime
is exceeded. This allows messages to be sent sooner if there are long delays between messages.

The bridge can consume from a queue, or a durable or non durable subscription, and a forward to a queue or a topic.

A JMS selector can be specified for the bridge so it will only forward messages that match the selector criteria.

If the connection to the source or target destination is lost, then the bridge can be configured to retry at configurable intervals, and a configurable
number of times. This allows it to be more resilient to temporary network loss, especially useful for forwarding from one LAN to another across a brittle WAN.

There is a minor issue to resolve with transaction recovery but this is all pretty much done.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003072#4003072

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003072


From do-not-reply at jboss.com  Wed Jan 17 17:50:24 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 17 Jan 2007 17:50:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Message bridge committed
Message-ID: <6527165.1169074224312.JavaMail.jboss@colo-br-02.atl.jboss.com>

Forgot to say: For QOS_ONCE_AND_ONLY_ONCE with source and destination having different resource managers, then both source and destination need to provide fully functioning XA resource implementations.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003076#4003076

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003076


From do-not-reply at jboss.com  Wed Jan 17 18:26:33 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Wed, 17 Jan 2007 18:26:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <28411965.1169076393471.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hum, changing the TransactionFactory from CMT to JTA did not solve the problem, but setting 

isCurrentSessionEnabled to false in jbpm.cfg.xml did !!!!!

Tom, you probably want to check with the Hibernate guys on this; my understanding is that if you invoked getCurrentSession and there was none, hibernate would create a session for you. Somehow if it is creating it, it is not creating a transaction along with it.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003085#4003085

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003085


From do-not-reply at jboss.com  Wed Jan 17 18:57:16 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Wed, 17 Jan 2007 18:57:16 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Message bridge committed
Message-ID: <3274059.1169078236604.JavaMail.jboss@colo-br-02.atl.jboss.com>

Fantastic! This is a nice chunk of work ... We're getting closer to code completeness for 1.2.

For all who are interested, we're very well positioned to reach our Feb target. We might even deliver 1.2.GA sooner.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003090#4003090

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003090


From do-not-reply at jboss.com  Wed Jan 17 20:51:09 2007
From: do-not-reply at jboss.com (tom.elrod@jboss.com)
Date: Wed, 17 Jan 2007 20:51:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Re: Exception propagation
	using HTTP servlet transport on 1.
Message-ID: <24296151.1169085069957.JavaMail.jboss@colo-br-02.atl.jboss.com>

Just ran the org.jboss.test.remoting.transport.servlet.ServletInvokerTestClient test (which extends org.jboss.test.remoting.transport.web.WebInvokerTestClient) with latest JBossAS 4.2.0 code base and remoting code base (see src/test/org/jboss/test/remoting/transport/servlet/readme.txt for instructions how to setup test).

The code within WebInvokerTestClient that tests exception handling looks like:


  |       Object response = null;
  |       try
  |       {
  |          response = remotingClient.invoke(WebInvocationHandler.THROW_EXCEPTION_PARAM, metadata);
  |          assertTrue("Should have thrown WebServerError and not made it to here.", false);
  |       }
  |       catch (IOException error)
  |       {
  |          // having to check class name instead of just catching type WebServerError so
  |          // can use for backwards compatibility tests since WebServerError is new since 2.0.0.CR1.
  |          if (error.getClass().getName().endsWith("WebServerError"))
  |          {
  |             assertTrue(true);
  |          }
  |          else
  |          {
  |             assertTrue("Did not get WebServerError thrown as expected", false);
  |          }
  |       }
  |       metadata.put(HTTPMetadataConstants.NO_THROW_ON_ERROR, "true");
  |       response = remotingClient.invoke(WebInvocationHandler.THROW_EXCEPTION_PARAM, metadata);
  |       if (response instanceof Exception)
  |       {
  |          System.out.println("Return from invocation is of type Exception as expected.");
  |          assertTrue("Received exception return as expected.", true);
  |       }
  |       else
  |       {
  |          System.out.println("Did not get Exception type returned as expected.");
  |          assertTrue("Should have received Exception as return.", false);
  |       }
  | 

This test passes when running with the servlet invoker.

In the case of servlet invoker, org.jboss.remoting.transport.http.WebServerError is thrown (or returned for the second invocation), so the original exception thrown on the server side is not the one thrown on the client side.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003122#4003122

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003122


From do-not-reply at jboss.com  Thu Jan 18 02:26:46 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Thu, 18 Jan 2007 02:26:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Bug in transactional delivery in an MDB
Message-ID: <25626576.1169105206715.JavaMail.jboss@colo-br-02.atl.jboss.com>

I spend a good part of the day today analyzing http://jira.jboss.com/jira/browse/JBMESSAGING-721
and its implications (which include http://jira.jboss.org/jira/browse/JBMESSAGING-410
and  http://jira.jboss.org/jira/browse/JBMESSAGING-520)

On one hand, the fixes for JBMESSAGING-410 and JBMESSAGING-520 insure that a JMS session created using a JMS connection produced by the JCA connection factory behaves as NON-TRANSACTED in absence of a global JTA transaction. 

This is an intuitive behavior, users rely on it, JBossMQ behaves similarly, and reportedly, other JMS providers as well.

Unfortunately, the fix caused http://jira.jboss.com/jira/browse/JBMESSAGING-721. Reverting it would fix MDB redelivery problem, but it will break JBMESSAGING-410 and JBMESSAGING-520 again.

At this moment, I am tempted to blame JCA and say that the fix for JBMESSAGING-410 and JBMESSAGING-520 belongs to the JCA layer. However, users don't see JCA, they see JBoss Messaging not working as expected. I haven't reached a definitive conclusion yet, I will continue thinking about this issue tomorrow.

In the mean time, the fix for http://jira.jboss.org/jira/browse/JBMESSAGING-748 is badly needed at some production sites, so I will release a partial service pack (1.0.1.SP3) but not make it available for public consumption, pending a resolution on JBMESSAGING-721, which will be incorporated in 1.0.1.SP4.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003163#4003163

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003163


From do-not-reply at jboss.com  Thu Jan 18 02:33:00 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Thu, 18 Jan 2007 02:33:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new build script
	updates committed
Message-ID: <3643761.1169105580512.JavaMail.jboss@colo-br-02.atl.jboss.com>

updates:

* now you don't have to run the get dependencies separate any more. if your build needs the libraries, it will check if they are up to date.  if not the build/build.xml is called with one of the targets get.libs.dependencies, get.jboss.dependencies or get.eclipse.dependencies.  

* the version.properties files have been removed.  instead, the build/build.properties contains the version properties.  

* some targets were moved from the project.base.build.xml to the project specific build file.  like package, jpdl, create.manifest and all those.  the original mechanism was too complex and not realizing a lot of reuse.  there seem to be always little differences between the same targets in different subprojects.  the old targets in the project.base.build.xml are still on top of that file in comments in case you want to have a look.

next i'm going to try to easy release tasks such as uploading to sf.net, uploading the docs and publishing jbpm artifacts to the remote repository.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003164#4003164

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003164


From do-not-reply at jboss.com  Thu Jan 18 02:40:56 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Thu, 18 Jan 2007 02:40:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <22006039.1169106056207.JavaMail.jboss@colo-br-02.atl.jboss.com>

in the enterprise.ear, the configurations are packaged in a separate jar file called jbpm-configs.jar

these are the relevant properties in the hibernate.cfg.xml

  <property name="hibernate.dialect">org.hibernate.dialect.HSQLDialect</property> 
  |   <property name="hibernate.cache.provider_class">org.hibernate.cache.HashtableCacheProvider</property> 
  |   <property name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.JBossTransactionManagerLookup</property> 
  |   <property name="hibernate.connection.datasource">java:/JbpmDS</property> 
  |   <property name="hibernate.transaction.factory_class">org.hibernate.transaction.CMTTransactionFactory</property> 
  |   <property name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.JBossTransactionManagerLookup</property> 
  | 

and this is the jbpm.cfg.xml part of the persistence/tx configs

<service name="persistence">
  |   <factory>
  |     <bean class="org.jbpm.persistence.db.DbPersistenceServiceFactory">
  |       <field name="isCurrentSessionEnabled">
  |         <true /> 
  |       </field>
  |       <field name="isTransactionEnabled">
  |         <false /> 
  |       </field>
  |     </bean>
  |   </factory>
  | </service>
  | 

if you change to JTA, you might need to set the isTransactionEnabled property to true.  i don't know these configs at all.  i'll check the docs and get back if i find anything there.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003167#4003167

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003167


From do-not-reply at jboss.com  Thu Jan 18 02:41:20 2007
From: do-not-reply at jboss.com (tom.elrod@jboss.com)
Date: Thu, 18 Jan 2007 02:41:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Re: Leasing is br0ken in servlet transport.
Message-ID: <26488397.1169106080879.JavaMail.jboss@colo-br-02.atl.jboss.com>

You are correct.  This was actually broken a while back when doing refactoring.  It is fixed now.  See http://jira.jboss.com/jira/browse/JBREM-671 for details (inluding testcase which shows how to setup).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003168#4003168

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003168


From do-not-reply at jboss.com  Thu Jan 18 02:45:13 2007
From: do-not-reply at jboss.com (tom.elrod@jboss.com)
Date: Thu, 18 Jan 2007 02:45:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Re: Servlet transport is completely broken.
Message-ID: <22320703.1169106313916.JavaMail.jboss@colo-br-02.atl.jboss.com>

Can you open a jira issue and attach the patch version?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003169#4003169

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003169


From do-not-reply at jboss.com  Thu Jan 18 02:47:57 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Thu, 18 Jan 2007 02:47:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <23849439.1169106477198.JavaMail.jboss@colo-br-02.atl.jboss.com>

>From the hibernate docs:

anonymous wrote : 3.8.3. Current Session context management with JTA
  | 
  | The easiest way to handle Sessions and transactions is Hibernates automatic "current" Session management. See the discussion of Section 2.5, ?Contextual Sessions?. Using the "jta" session context, if there is no Hibernate Session associated with the current JTA transaction, one will be started and associated with that JTA transaction the first time you call sessionFactory.getCurrentSession(). The Sessions retrieved via getCurrentSession() in "jta" context will be set to automatically flush before the transaction completes, close after the transaction completes, and aggressively release JDBC connections after each statement. This allows the Sessions to be managed by the lifecycle of the JTA transaction to which it is associated, keeping user code clean of such management concerns. Your code can either use JTA programmatically through UserTransaction, or (recommended for portable code) use the Hibernate Transaction API to set transaction boundaries. If you run in an EJB container, declarative transaction demarcation with CMT is preferred. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003170#4003170

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003170



From do-not-reply at jboss.com  Thu Jan 18 05:45:39 2007
From: do-not-reply at jboss.com (thanvi)
Date: Thu, 18 Jan 2007 05:45:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Setting content
	type for the whole portal : ContentTypeI
Message-ID: <17376047.1169117139143.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi 

It's a very interting forum. I am tryign to set the content type to mulitpart/form-data.

I did the changes in the xml file as mentiond by Shaun.

But i got the following exception

15:53:41,991 ERROR [ObjectModelBuilder] Failed to invoke method public java.lang.Object org.jboss.portal.theme.deployment.jboss.LayoutStategyMetaDataFactory.newChild(java.util.ArrayList,org.jboss.xb.binding.UnmarshallingContext,java.lang.String,java.lang.String,org.xml.sax.Attributes) throws javax.activation.MimeTypeParseException, factory=org.jboss.portal.theme.deployment.jboss.LayoutStategyMetaDataFactory at 4b0cbc
  | javax.activation.MimeTypeParseException: Type [multipart/form-data] not supported
  | 	at org.jboss.portal.common.MediaType.parseMimeType(MediaType.java:214)
  | 	at org.jboss.portal.theme.deployment.jboss.LayoutStategyMetaDataFactory.newChild(LayoutStategyMetaDataFactory.java:63)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:585)
  | 	at org.jboss.xb.binding.ObjectModelBuilder.invokeFactory(ObjectModelBuilder.java:435)
  | 	at org.jboss.xb.binding.DelegatingObjectModelFactory.newChild(DelegatingObjectModelFactory.java:93)
  | 	at org.jboss.xb.binding.ObjectModelBuilder.startElement(ObjectModelBuilder.java:337)
  | 	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:299)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003229#4003229

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003229


From do-not-reply at jboss.com  Thu Jan 18 05:56:13 2007
From: do-not-reply at jboss.com (thanvi)
Date: Thu, 18 Jan 2007 05:56:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Setting content
	type for the whole portal : ContentTypeI
Message-ID: <12467938.1169117773987.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi

I just checked with the MediaType.java The MediaTypes allowed doesnt include the MimeType multipart/form-data..

Can some help me proceed further.

I looking to attach a file in my page and store in the server.

The contentType is there till the actionRequest.. once its moved to view the renderRequest doesn't have the contentType and the mime type is set to text.

Please Help

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003243#4003243

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003243


From do-not-reply at jboss.com  Thu Jan 18 06:27:28 2007
From: do-not-reply at jboss.com (timfox)
Date: Thu, 18 Jan 2007 06:27:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <11355750.1169119648350.JavaMail.jboss@colo-br-02.atl.jboss.com>

Weston-

Have you worked out why the JCA layer is calling commit on a transacted session?

I am assuming this is a JCA bug, is there a JIRA task for it?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003251#4003251

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003251


From do-not-reply at jboss.com  Thu Jan 18 06:33:42 2007
From: do-not-reply at jboss.com (timfox)
Date: Thu, 18 Jan 2007 06:33:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <21330854.1169120022607.JavaMail.jboss@colo-br-02.atl.jboss.com>

Sorry I meant "calling commit on an XASession" (which is illegal)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003255#4003255

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003255


From do-not-reply at jboss.com  Thu Jan 18 07:54:09 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Thu, 18 Jan 2007 07:54:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Upgrading
	Jackrabbit to 1.1 on Portal 2.6?
Message-ID: <10852408.1169124849929.JavaMail.jboss@colo-br-02.atl.jboss.com>

It has been upgraded in the trunk to version 1.1.1


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003282#4003282

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003282


From do-not-reply at jboss.com  Thu Jan 18 07:55:50 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Thu, 18 Jan 2007 07:55:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <17348322.1169124950319.JavaMail.jboss@colo-br-02.atl.jboss.com>

Can you confirm your simple JBM/jPBM test works with the adapter in HEAD? It should be a simple drop in replacement. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003283#4003283

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003283


From do-not-reply at jboss.com  Thu Jan 18 08:39:18 2007
From: do-not-reply at jboss.com (joanesilviyaj)
Date: Thu, 18 Jan 2007 08:39:18 -0500 (EST)
Subject: [jboss-dev-forums] [Javassist development Forum] -
	jbossclient-all.jar
Message-ID: <17529112.1169127558557.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi all :

Could anybody tell me the link for downloading  jbossall-client.jar.

thanks in advance
silviya


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003300#4003300

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003300


From do-not-reply at jboss.com  Thu Jan 18 09:27:03 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Thu, 18 Jan 2007 09:27:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - JBAS-3997
Message-ID: <4820263.1169130423138.JavaMail.jboss@colo-br-02.atl.jboss.com>

I am hesitant to see this as being required. ResourceExceptions are not, by nature, transient. We already cover the case of a connection attempt failing for validation or other reasons. The ResourceException itself is only thrown during catastrophic failure from which there is probably no possiblity of recovery. Could you please comment on what you believe to be a recoverable in this case. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003330#4003330

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003330


From do-not-reply at jboss.com  Thu Jan 18 09:33:57 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Thu, 18 Jan 2007 09:33:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re:
	markNodeCurrentlyInUse() - race condition
Message-ID: <25839859.1169130837561.JavaMail.jboss@colo-br-02.atl.jboss.com>

I agree that it is ugly and placing a marker directly on the node makes more sense.

I also agree that using the event queue for this kind of data is pretty hacky, but let's revisit the purpose of this method (and Brian will probably have stuff to add here)

markNodeCurrentlyInUse() does (should) not prevent node removal by calling one of the remove methods.  All it should do is prevent the node from being evicted.  And if this is the case, then a marked in the event queue should be sufficient since the event processor thread would find the in-use marker before any eviction markers.

I guess where this can be a problem is if a node is marked for eviction first, and then is marked as in-use, and then the event processor thread starts.  

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003336#4003336

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003336


From do-not-reply at jboss.com  Thu Jan 18 10:27:27 2007
From: do-not-reply at jboss.com (bkeh12)
Date: Thu, 18 Jan 2007 10:27:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Fine
	grained action aware interfaces (JBMICROCONT-134)
Message-ID: <17041323.1169134047574.JavaMail.jboss@colo-br-02.atl.jboss.com>

Thank you very much... :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003357#4003357

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003357


From do-not-reply at jboss.com  Thu Jan 18 10:30:28 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Thu, 18 Jan 2007 10:30:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <8430338.1169134228409.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes, I made the changes I described in jbpm-configs.jar. isTransactionEnabled should not be set to true; if it is not only would jBPM try to demarcate the transactions, but my understaning is jBPM would also close the hibernate session, wchich should foul everything up.

You see from the the description of CMT why it is not a fit for jBPM. The web console (as currently implemented / deployed), does NOT run in / use the EJB container. Not can we guarantee that other user applications would just because they deployed jbpm-enterprise.ear (although you would expect them to). JTA is flexible because it allows for both EJB and non-EJB applications.

If the jbpm-console were to be modified to only use the Command SLSB interface, then CMT might be a better fit for jBPM enterprise.

As far as the documentation on getCurrentSession, in the past (in another project) it appeared to work that way. However in testing with jBPM the process deployment did not work until I set isCurrentSessionEnabled to false. You might want to test this out and see if you get the same result.

 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003360#4003360

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003360


From do-not-reply at jboss.com  Thu Jan 18 10:34:47 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Thu, 18 Jan 2007 10:34:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: JMS Example in 3.2
	Beta
Message-ID: <9399090.1169134487910.JavaMail.jboss@colo-br-02.atl.jboss.com>

So what do you think, can we modify the NewProcessInstanceCommand to signal when there are no start tasks?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003362#4003362

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003362


From achaiah at gmail.com  Thu Jan 18 10:54:06 2007
From: achaiah at gmail.com (Achaiah)
Date: Thu, 18 Jan 2007 10:54:06 -0500
Subject: [jboss-dev-forums] Extending jBPM Visual Designer
Message-ID: <d61f1b860701180754s26d1ee94ub80dfd4a78ab3740@mail.gmail.com>

My appologies ahead of time if I am sending this to the wrong mailing list
or if this question has been asked before.  I am wondering if someone knows
if it is possible to extend the jBPM Visual Designer with a custom set of
Nodes.  The current jBPM configuration is not enough for our purposes and
while we can extend the Node class we have not found any documentation on
how to reflect custom nodes in the graphical UI of jBPM designer.  Please
help.

Secondly, has anyone else encountered the problem that the jBPM Visual
Designer guide does not correspond to the latest version of the eclipse
plugin?  The current plugin does not even create a
websomething.sardirectory like the guide states.  The diagrams seem to
be out of date as
well.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20070118/19be7df1/attachment.html 

From do-not-reply at jboss.com  Thu Jan 18 11:18:43 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Thu, 18 Jan 2007 11:18:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <3809110.1169137123830.JavaMail.jboss@colo-br-02.atl.jboss.com>

No need to deploy portal first anymore, I fixed the problem by adding a dependence of ACL interceptor over its session factory binder service.

"roy.russo at jboss.com" wrote : There are problem with the core-cms:
  | 
  | 1. You *must* deploy the jboss-portal.sar first, and then the portal-cms.sar. If you do not, the cms will not deploy at all, due to some issues with security/identity.
  | 
  | 2. If you deploy the portal-cms.sar in a running instance of AS, it will create all the resources. 
  |    a. File creation is sloooooow. 
  |    b. Also, when you log in to the cmsAdminPortlet, it doesn't show the root directory so you can't do anything. I wouldn't be surprised if this is also related to identity integration.
  | 
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003388#4003388

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003388


From do-not-reply at jboss.com  Thu Jan 18 13:07:05 2007
From: do-not-reply at jboss.com (genman)
Date: Thu, 18 Jan 2007 13:07:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re:
	markNodeCurrentlyInUse() - race condition
Message-ID: <16374287.1169143625644.JavaMail.jboss@colo-br-02.atl.jboss.com>

Example situation which demonstrates a race condition. The following situation happens, say if 2 nodes are allowed, 3 nodes are created, and LRU policy is applied.

Visit A - B - C
Mark Node A in use
-- event processing occurs --
Node A evicted ...


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003447#4003447

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003447


From do-not-reply at jboss.com  Thu Jan 18 13:16:39 2007
From: do-not-reply at jboss.com (Cyberax)
Date: Thu, 18 Jan 2007 13:16:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Re: Exception propagation
	using HTTP servlet transport on 1.
Message-ID: <18803084.1169144199889.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : In the case of servlet invoker, org.jboss.remoting.transport.http.WebServerError is thrown (or returned for the second invocation), so the original exception thrown on the server side is not the one thrown on the client side.
Yes, that was my problem - my code relies on exceptions for creating user-friendly error messages.

For now, I just modified servlet transport to preserve exception type.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003449#4003449

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003449


From do-not-reply at jboss.com  Thu Jan 18 13:23:49 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Thu, 18 Jan 2007 13:23:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re:
	markNodeCurrentlyInUse() - race condition
Message-ID: <3627658.1169144629868.JavaMail.jboss@colo-br-02.atl.jboss.com>

>From an earlier jbosscache-dev conversation:

"Manik Surtani" wrote : 
  | On 15 Nov 2006, at 14:51, Brian Stansberry wrote:
  | 
  | > The purpose of this method is to allow an application to signal the
  | > eviction policy to not evict a particular node who's data it's using.
  | > Needed in situations where the app doesn't hold a lock on the node  
  | > *and*
  | > where evicting the node will cause a problem.
  | >
  | > AFAICT, this use case is really just for EJB3 SFSBs, where the problem
  | > is that evicting an "in-use" node forces the container to call
  | > prePassivate() on the in-use EJB. This is done from a CacheListener.
  | >
  | > This is all a bit funky.  Adding methods to the API to deal with a  
  | > very
  | > specific use case.  It also has a small race condition, which I won't
  | > get into here.
  | >
  | > Here's a different (but still funky) approach:
  | >
  | > Add a new exception class o.j.c.eviction.NodeInUseException extends
  | > RuntimeException.
  | >
  | > The application implements CacheListener. When it gets a
  | > nodePassivated(pre=true) event, if it doesn't want the passivation, it
  | > throws the NodeInUseException.  This will abort the eviction and
  | > propagate back to the eviction policy.  Eviction policies are already
  | > written such that they catch all exceptions, and then throw the node
  | > into a retry queue (see BaseEvictionAlgorithm.evictCacheNode()). If we
  | > wanted to get fancy, we could specifically catch NodeInUseException  
  | > and
  | > decide from there whether to add it to the retry queue.
  | >
  | > I don't think we should try to change this this week; more of a short
  | > term future thing.
  | >
  | > Thoughts?
  | 
  | Your second (and still funky) approach does seem a lot cleaner than  
  | hacking in stuff into the API for a very specific use case.  So  
  | certainly my preferred option.  But from a performance standpoint, is  
  | this really an "exceptional" circumstance?


The above is hacky.  Concern I have about adding a field to the node is it forces a read of each node as part of the eviction. IIRC that's not needed now, except in CacheImpl itself as part of the remove. Don't want to add overhead. (I'm in a class now so can't look at code, so please forgive if that's an easily addressable concern.)

I believe the race condition is because eviction is a two step process with 2 queues -- policy reads off all the eviction events off the event queue and  uses that to build its eviction queue.  Then it goes through the eviction queue and decides whether to evict the nodes.  Race can happen if the markNodeCurrentlyInUse() call happens after event queue has been read but before the policy has dealt with the relevant node.  This race is really a general problem that could throw off accurate working off any eviction algorithm (e.g. a get() that occurs after the event queue is read doesn't prevent eviction by the LRUPolicy).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003454#4003454

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003454


From do-not-reply at jboss.com  Thu Jan 18 13:34:47 2007
From: do-not-reply at jboss.com (hendra_netm)
Date: Thu, 18 Jan 2007 13:34:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Fail-over design questions
Message-ID: <19576789.1169145287611.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hello JBoss Messaging Developers,
I have a question about what will happen to the crashed server when I bring it back again? 

For example, I have two servers Server0 and Server1. Server0 is crash. All connections and messages in Server0 will be failed over to Server1. 
When I bring server0 back, I think server0 wil have no client connections, and this will lead to imbalance load between server. Is this correct?

I also want to ask why fail-over action is only trigerred by crashed condition? 
I have a case where I need to shut down JBoss Messaging Server for operational thing. I want when I shut down one server, the connection will be failed over to another node, and when I put the server back, that server will share again the load of messages delivery with other servers. Is this scenario possible?

Thank you in advance,
Hendra

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003456#4003456

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003456


From do-not-reply at jboss.com  Thu Jan 18 13:38:57 2007
From: do-not-reply at jboss.com (Cyberax)
Date: Thu, 18 Jan 2007 13:38:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Re: Servlet transport is completely broken.
Message-ID: <12474541.1169145537832.JavaMail.jboss@colo-br-02.atl.jboss.com>

I can't figure out how to create a new issue in Jira. So I uploaded a fixed version here: https://sdmain.staffdirector.net/jboss/ServletServerInvoker.java

It needs a major code cleanup.

In particular: parser of invoker URLs in Remoting 1.4.4 had a problem with parsing URLs with colons so I only added support for customization of invoker name prefix.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003460#4003460

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003460


From do-not-reply at jboss.com  Thu Jan 18 13:42:21 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Thu, 18 Jan 2007 13:42:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: JMS Example in 3.2
	Beta
Message-ID: <10363629.1169145741575.JavaMail.jboss@colo-br-02.atl.jboss.com>

My understanding is that the CommandListenerBean and CommandServiceBean are designed to handle any Command (that has a class defined that implements the Command interface), not just Job Commands. However, it appears the CommandListenerBean always creates a ExecuteJobCommand, which tries to load a job using the jobId..

I think CommandListernerBean should check for the presence of a JobId (or non 0 jobId), and if not present, then not create a ExecuteJobCommand, but instead get the command from the message and execute it. Currently, the code does not even look in the message for a command, but always assumes its a job and gets it from the Job table.  

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003461#4003461

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003461


From do-not-reply at jboss.com  Thu Jan 18 13:48:06 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Thu, 18 Jan 2007 13:48:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Fail-over design questions
Message-ID: <9858772.1169146086643.JavaMail.jboss@colo-br-02.atl.jboss.com>

I guess we should consider an option where we can shutdown and failover clients.

anonymous wrote : When I bring server0 back, I think server0 wil have no client connections, and this will lead to imbalance load between server. Is this correct? 

This is correct at this point. 

Server0 will assume new connections.. .but we don't have a recover of the failover at this point. This is something we have discussed... and it might be scheduled for future releases.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003464#4003464

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003464


From do-not-reply at jboss.com  Thu Jan 18 13:52:00 2007
From: do-not-reply at jboss.com (timfox)
Date: Thu, 18 Jan 2007 13:52:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Fail-over design questions
Message-ID: <8983056.1169146320117.JavaMail.jboss@colo-br-02.atl.jboss.com>

"hendra_netm" wrote : Hello JBoss Messaging Developers,
  | I have a question about what will happen to the crashed server when I bring it back again? 
  | 
  | For example, I have two servers Server0 and Server1. Server0 is crash. All connections and messages in Server0 will be failed over to Server1. 
  | When I bring server0 back, I think server0 wil have no client connections, and this will lead to imbalance load between server. Is this correct?
  | 
  | I also want to ask why fail-over action is only trigerred by crashed condition? 
  | I have a case where I need to shut down JBoss Messaging Server for operational thing. I want when I shut down one server, the connection will be failed over to another node, and when I put the server back, that server will share again the load of messages delivery with other servers. Is this scenario possible?

When you failover, non persistent messages would be lost. Therefore we can't just fail over to redistribute load, since people would get upset if suddenly their non persistent messages disappeared.

There are certain situations where it is possible to redistribute a connection, like, if there are no unacked messages in the session, but this gets complex.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003467#4003467

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003467


From do-not-reply at jboss.com  Thu Jan 18 14:05:30 2007
From: do-not-reply at jboss.com (hendra_netm)
Date: Thu, 18 Jan 2007 14:05:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Fail-over design questions
Message-ID: <17329292.1169147130889.JavaMail.jboss@colo-br-02.atl.jboss.com>

"timfox" wrote : 
  | When you failover, non persistent messages would be lost. Therefore we can't just fail over to redistribute load, since people would get upset if suddenly their non persistent messages disappeared.
  | 
  | There are certain situations where it is possible to redistribute a connection, like, if there are no unacked messages in the session, but this gets complex.

Sorry for unclear question. I mean, when I shut down the server the messages and the connection will be not failed over to another node. The fail-over policy is only triggered by crashed condition not normal shut down condition, isn't it?

If a server is shut down, because for example I want to add some components in my server, the messages and connections will not be failed over. Why does shut down not get the same policy like when the server is crashed? Is there any problem that make you differ the crashed and shut down situation?

Thank you for your respond.

Regards,
Hendra

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003475#4003475

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003475


From do-not-reply at jboss.com  Thu Jan 18 14:07:47 2007
From: do-not-reply at jboss.com (timfox)
Date: Thu, 18 Jan 2007 14:07:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Fail-over design questions
Message-ID: <13647681.1169147267772.JavaMail.jboss@colo-br-02.atl.jboss.com>

"hendra_netm" wrote : "timfox" wrote : 
  |   | 
  |   | If a server is shut down, because for example I want to add some components in my server, the messages and connections will not be failed over. Why does shut down not get the same policy like when the server is crashed? Is there any problem that make you differ the crashed and shut down situation?
  |   | 
  | 
  | As I said in my previous reply, we cannot do this because you would lose non persistent messages, and customers would not be very happy.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003477#4003477

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003477


From do-not-reply at jboss.com  Thu Jan 18 14:09:37 2007
From: do-not-reply at jboss.com (damon.sicore@jboss.com)
Date: Thu, 18 Jan 2007 14:09:37 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Out of Memory Error
	when Deploying JBoss Labs
Message-ID: <25673073.1169147377258.JavaMail.jboss@colo-br-02.atl.jboss.com>

Up your memory settings in the JAVA_OPTS to use more than the standard 128M.  We deploy a lot of stuff, and the default setting is insufficient.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003480#4003480

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003480


From do-not-reply at jboss.com  Thu Jan 18 14:19:54 2007
From: do-not-reply at jboss.com (hendra_netm)
Date: Thu, 18 Jan 2007 14:19:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Fail-over design questions
Message-ID: <18469413.1169147994346.JavaMail.jboss@colo-br-02.atl.jboss.com>

"timfox" wrote : 
  | As I said in my previous reply, we cannot do this because you would lose non persistent messages, and customers would not be very happy.

I thought that JBoss messaging will use replication for that case. "Persistent level reliability guarantee without persistence" feature means that I can use non-persistent message and still get no message loss, doesn't it?

Anyway, you would lose non-persistent messages as well in crashed situation. Or not?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003485#4003485

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003485


From do-not-reply at jboss.com  Thu Jan 18 14:26:14 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Thu, 18 Jan 2007 14:26:14 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re:
	markNodeCurrentlyInUse() - race condition
Message-ID: <6903667.1169148374390.JavaMail.jboss@colo-br-02.atl.jboss.com>

This is where placing markers (both "marked for eviction" as well as "mark as in use") on the node could help.

The eviction interceptor places events in the queue as well as marks the node for eviction; on subsequent gets (before the eviction happens) the eviction interceptor could *remove* the "marked for eviction" marker (according to policy) on the node.

When the eviction thread kicks in, it processes the eviction queue and before attempting to evict a node, tests the "marked for eviction" flag on the node as well as the "mark as in use" flag.  

Since these flags reside in the node, dealing with concurrency and race conditions become much easier.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003487#4003487

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003487


From do-not-reply at jboss.com  Thu Jan 18 14:27:33 2007
From: do-not-reply at jboss.com (timfox)
Date: Thu, 18 Jan 2007 14:27:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Fail-over design questions
Message-ID: <32761449.1169148453712.JavaMail.jboss@colo-br-02.atl.jboss.com>

In memory persistent message replication is not implemented yet, but when it does it would be used for persistent messages not non persistent messages.

Yes, you might lose np messages in crash, but you don't want to just randomly lose them at other non crash times, just because the server wants to move the connection.

I don't think that would be acceptable to the majority of users.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003489#4003489

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003489


From do-not-reply at jboss.com  Thu Jan 18 14:29:10 2007
From: do-not-reply at jboss.com (timfox)
Date: Thu, 18 Jan 2007 14:29:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Fail-over design questions
Message-ID: <6177659.1169148550084.JavaMail.jboss@colo-br-02.atl.jboss.com>

Although the JMS spec technically allows non persistent messages to be lost at any time, we try and make a "best effort", i.e. we try not to lose them unless failure occurs.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003491#4003491

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003491


From do-not-reply at jboss.com  Thu Jan 18 14:56:27 2007
From: do-not-reply at jboss.com (hendra_netm)
Date: Thu, 18 Jan 2007 14:56:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Fail-over design questions
Message-ID: <4546478.1169150187062.JavaMail.jboss@colo-br-02.atl.jboss.com>

"timfox" wrote : In memory persistent message replication is not implemented yet, but when it does it would be used for persistent messages not non persistent messages.
  | 
  | Yes, you might lose np messages in crash, but you don't want to just randomly lose them at other non crash times, just because the server wants to move the connection.
  | 
  | I don't think that would be acceptable to the majority of users.

I see. Then how are users able to maintenance their server without disturbing the service?

For example, I need to maintenance my server without disturbing my services. So I need to shut down the server but I don't want any message loss.

In normal situation (without clustering), I would stop the producer and let the consumer get all messages before shutting down the server. With clustering, I don't know which clients connect to one specific server that I want to shut down due to HA-JNDI.

Is there possible that clients check which server node that they connect to?

Regards,
Hendra

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003504#4003504

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003504


From do-not-reply at jboss.com  Thu Jan 18 15:17:10 2007
From: do-not-reply at jboss.com (hendra_netm)
Date: Thu, 18 Jan 2007 15:17:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Fail-over design questions
Message-ID: <25733006.1169151430048.JavaMail.jboss@colo-br-02.atl.jboss.com>

I prefer that failover in shut down condition can become option. So when I want to do maintenance, I only need to use persistent messages and shut it down.

I think it is better than simulate crash condition in server to trigger the failover

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003512#4003512

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003512


From do-not-reply at jboss.com  Thu Jan 18 15:42:11 2007
From: do-not-reply at jboss.com (falazar)
Date: Thu, 18 Jan 2007 15:42:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Web Console:
	Context Menus and Navigation
Message-ID: <28685217.1169152931366.JavaMail.jboss@colo-br-02.atl.jboss.com>

Correct, we go directly to the task form as well, without the summary form, 
and as a whole it feels a little more complicated than necessary, I'm not sure if there are parts that will be removed for the low end user or not, we went with giving them few options as top level, only Inbox (personal and group tasks in two tabs)
Open Processes and Past Processes.  Then the Manager pages and Admin pages would have other options available.
   I posted a PDF presentation we gave, that had some of the screen shots in another topic if anyone would like to comment.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003521#4003521

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003521


From do-not-reply at jboss.com  Thu Jan 18 15:53:03 2007
From: do-not-reply at jboss.com (falazar)
Date: Thu, 18 Jan 2007 15:53:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Web Console:
	Context Menus and Navigation
Message-ID: <1349684.1169153583770.JavaMail.jboss@colo-br-02.atl.jboss.com>

"kukeltje" wrote:
The opening page is the user tasklist. That is (obivious) the most important one. I therefor would make it, the user part of the menu, the top one in the menu. (the username and logout are probably out of place then... hmmmmm)

David:
Yeah, this occured to me too, but I didn't have a quick answer so I just tabled the thought. One thing that has occured to me in the past is that the view that is currently presented (of the user task list) is more of a managerial view. I think I will ultimately end up making another user task list which is only the current user, and renaming the current one to be "All Tasks" or something to that effect. 

Falazar:
  Yeah right now the first thing on the menu is inactive most of the time, and jumps around, I would rather see the main (bottom) stuff up top, and we made and All Tasks page like that, and a Users task page as well, that are seperate.

Also we are working now on a scheme that would allow a special "filtered" view for process lists or task lists, that would show certain process varaibles, that are deemed "important" this was suggested for several things like "Purchase Requests" where the Amount was wanted to be seen in the list view.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003522#4003522

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003522


From do-not-reply at jboss.com  Thu Jan 18 16:13:52 2007
From: do-not-reply at jboss.com (falazar)
Date: Thu, 18 Jan 2007 16:13:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: remove context
	sensitive menus
Message-ID: <21452629.1169154832751.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | Using the name "Task" for TaskInstance's is good, i think. (as long as there is no reference to a task definition somewhere, which i don't think is necessary)
  | 
  | But taking into account all the feedback and consistency, i would keep the complete names of "Process Definition" and "Process Instance".

Correct, keep Process Instance or Process for this, that is the simplest short definition, 
and matches the Task Instance, Tasks, Task Definition style.

Execution is really more of an action term, and not appropriate.

Under the Process Definition page, it is not intuitive that all of the stuff is there, 
"Start" should be moved to another area, and the Process List on the end seems to warrant its only top level listing or something.

We currently have a Processes page which just lists all the processes and a filter to easily select if you need to see only one type of processes, lets them easily navigate, 
you have a similar search in yours.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003533#4003533

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003533


From do-not-reply at jboss.com  Thu Jan 18 16:32:35 2007
From: do-not-reply at jboss.com (james.cobb@jboss.com)
Date: Thu, 18 Jan 2007 16:32:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Navigation in Labs
	2.0
Message-ID: <31633316.1169155955491.JavaMail.jboss@colo-br-02.atl.jboss.com>

1. Global Navigation:
A new navigation structure has been designed to help the user access various portions of the site. These common elements will be accessible from every page.

 The content would be broken into:
Home | Knowledge Base | JBoss Projects | Contribute | My.ORG

2. Projects Navigation:
The "JBoss Projects" page will be a common landing page where the user can access all jboss projects. We'll remove the old groups of "JEMS" and "Community projects" from the site. The new design will categorize the projects by function.  

3. Individual Project Navigation: The project leads should have the ability to add additional pages to their project sites. The project pages portlet would have to be on each page and it's ui design would be important to show the connection of the navigation to the pages.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003537#4003537

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003537


From do-not-reply at jboss.com  Thu Jan 18 16:59:05 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Thu, 18 Jan 2007 16:59:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Non connected remoting clients throwing java.lang.Exception
Message-ID: <25462937.1169157545885.JavaMail.jboss@colo-br-02.atl.jboss.com>

I guess we have changed remoting to disconnect clients when ConnectionValidator fails, and I have seen situations where invocations are failing on the testsuite.

FailoverTest(Clustering)::testFailoverMessageOnServer2 is an example of such behavior.

I guess we should change (or ask remoting team to do it), in such way We should not disconnect remoting clients... or at least throw a meaninful Exception we could catch on FailoverValveInterceptor.

This is the exception we are catching now:

anonymous wrote : java.lang.Exception: Can not make remoting client invocation due to not being connected to server.
  |         at org.jboss.remoting.Client.invoke(Client.java:639)
  |         at org.jboss.remoting.Client.invoke(Client.java:627)
  |         at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:118)
  |         at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_N5002091796089334799.invokeNext(ClientSessionDelegate$createConsumerDelegate_N5002091796089334799.java)
  |         at org.jboss.jms.client.container.StateCreationAspect.handleCreateConsumerDelegate(StateCreationAspect.java:153)
  |         at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect17.invoke(StateCreationAspect17.java)
  |         at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_N5002091796089334799.invokeNext(ClientSessionDelegate$createConsumerDelegate_N5002091796089334799.java)
  |         at org.jboss.jms.client.container.ConsumerAspect.handleCreateConsumerDelegate(ConsumerAspect.java:67)
  |         at org.jboss.aop.advice.org.jboss.jms.client.container.ConsumerAspect16.invoke(ConsumerAspect16.java)
  |         at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_N5002091796089334799.invokeNext(ClientSessionDelegate$createConsumerDelegate_N5002091796089334799.java)
  |         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:177)
  |         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
  |         at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_N5002091796089334799.invokeNext(ClientSessionDelegate$createConsumerDelegate_N5002091796089334799.java)
  |         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:71)
  |         at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_N5002091796089334799.invokeNext(ClientSessionDelegate$createConsumerDelegate_N5002091796089334799.java)
  |         at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:112)
  |         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
  |         at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_N5002091796089334799.invokeNext(ClientSessionDelegate$createConsumerDelegate_N5002091796089334799.java)
  |         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
  |         at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_N5002091796089334799.invokeNext(ClientSessionDelegate$createConsumerDelegate_N5002091796089334799.java)
  |         at org.jboss.jms.client.delegate.ClientSessionDelegate.createConsumerDelegate(ClientSessionDelegate.java)
  |         at org.jboss.jms.client.JBossSession.createConsumer(JBossSession.java:254)
  |         at org.jboss.jms.client.JBossSession.createConsumer(JBossSession.java:226)
  |         at org.jboss.test.messaging.jms.clustering.FailoverTest.testFailoverMessageOnServer2(FailoverTest.java:1483)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  |         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  |         at java.lang.reflect.Method.invoke(Method.java:585)
  |         at junit.framework.TestCase.runTest(TestCase.java:154)
  |         at junit.framework.TestCase.runBare(TestCase.java:127)
  |         at junit.framework.TestResult$1.protect(TestResult.java:106)
  |         at junit.framework.TestResult.runProtected(TestResult.java:124)
  |         at junit.framework.TestResult.run(TestResult.java:109)
  |         at junit.framework.TestCase.run(TestCase.java:118)
  |         at junit.framework.TestSuite.runTest(TestSuite.java:208)
  |         at junit.framework.TestSuite.run(TestSuite.java:203)
  |         at junit.textui.TestRunner.doRun(TestRunner.java:116)
  |         at junit.textui.TestRunner.start(TestRunner.java:172)
  |         at org.jboss.test.messaging.tools.junit.SelectiveTestRunner.main(SelectiveTestRunner.java:58)
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003543#4003543

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003543


From do-not-reply at jboss.com  Thu Jan 18 17:00:48 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Thu, 18 Jan 2007 17:00:48 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Non connected remoting clients throwing java.lang.Except
Message-ID: <229696.1169157648932.JavaMail.jboss@colo-br-02.atl.jboss.com>

There is a remoting JIRA task for this:

http://jira.jboss.org/jira/browse/JBREM-657

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003545#4003545

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003545


From do-not-reply at jboss.com  Thu Jan 18 17:05:12 2007
From: do-not-reply at jboss.com (jval)
Date: Thu, 18 Jan 2007 17:05:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss ESB] - ESB security features
Message-ID: <3693574.1169157912835.JavaMail.jboss@colo-br-02.atl.jboss.com>

Are the ESB security features based on the AS security?? The AS security is implemented by the JBoss Security project??

Help please, resourcfes, links, docs, anything!

Thank you very much.

Javier

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003546#4003546

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003546


From do-not-reply at jboss.com  Thu Jan 18 17:39:28 2007
From: do-not-reply at jboss.com (falazar)
Date: Thu, 18 Jan 2007 17:39:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <5575145.1169159968314.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | The "End Task" is not terminology that is defined by the web console. The caption of each of the transition buttons is determined by the name of the corresponding transition. In this case, the "websale" example process happens to have transitions named "End Task". 

The "End" "Cancel" and "Save" are rather confusing, we changed those to be specfic action names so users would know what they were doing, like "Submit Request" and such.

And the "Cancel" does not actually cancel the task or the process, so it is very ambigously named, we changed it to "Go back to inbox" and added a Cancel Request transition button.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003551#4003551

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003551


From do-not-reply at jboss.com  Thu Jan 18 17:47:40 2007
From: do-not-reply at jboss.com (epbernard)
Date: Thu, 18 Jan 2007 17:47:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)]
	- Distributed Lock Mechanism
Message-ID: <11791225.1169160460353.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi guys,
For Hibernate Search, I'm in need for a DLM (Distributed Lock Mechanism). Basically a way to acquire a lock, do some stuff and release a lock clusterwise.

This is something that can be available and built on top of JGroups.

I've talked to a RH instructor and we discussed the DLM available in GFS (Global file System).
To summarize:
  - there is a quorum (each node having a weight)
  - a subset of the cluster is considered free to work if it has quorum/2+1 
  - when a node ask for a lock, it informs everybody, and everybody has to agree on the lock acquisition
  - if a lock is acquired the demanding node is responsible for managing the lock
  - if a node is playing the bad guy or has been cut from the majority, it reboots itself or is made rebooted hoping for a recovery

This implementation is not really fully self configurable (entering and leaving the quorum part might have to be manual)

Do you think we can build something similar as a common project for JBoss, I need it but most likely, some other projects need that too.
I'm pretty open to the feature support as well.
There may be something available already?

Thoughts?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003554#4003554

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003554


From do-not-reply at jboss.com  Thu Jan 18 18:10:33 2007
From: do-not-reply at jboss.com (mark.little@jboss.com)
Date: Thu, 18 Jan 2007 18:10:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss ESB] - Re: ESB security features
Message-ID: <17865708.1169161833682.JavaMail.jboss@colo-br-02.atl.jboss.com>

The ESB security will certainly support AS security.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003560#4003560

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003560


From do-not-reply at jboss.com  Thu Jan 18 18:25:55 2007
From: do-not-reply at jboss.com (szimano)
Date: Thu, 18 Jan 2007 18:25:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - Re: Out of Memory Error
	when Deploying JBoss Labs
Message-ID: <10275297.1169162755162.JavaMail.jboss@colo-br-02.atl.jboss.com>

wow damon. you're alive even here

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003563#4003563

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003563


From do-not-reply at jboss.com  Thu Jan 18 18:30:47 2007
From: do-not-reply at jboss.com (jval)
Date: Thu, 18 Jan 2007 18:30:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss ESB] - Re: ESB security features
Message-ID: <3589025.1169163047915.JavaMail.jboss@colo-br-02.atl.jboss.com>

Are there any other capabilities than the existing ones in the AS?

What's the relationship between de AS security and the JBoss security project??

Thank you very much Mark.

Javier.

P.S.: excuse my english.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003565#4003565

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003565


From do-not-reply at jboss.com  Thu Jan 18 18:35:14 2007
From: do-not-reply at jboss.com (mark.little@jboss.com)
Date: Thu, 18 Jan 2007 18:35:14 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss ESB] - Re: ESB security features
Message-ID: <24575392.1169163314828.JavaMail.jboss@colo-br-02.atl.jboss.com>

There are other security specifications and standards that we will support. For example, OASIS WS-SX will be the standard for Web Services and we will try to leverage that within the ESB, even when you're not using SOAP and WSDL.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003566#4003566

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003566


From do-not-reply at jboss.com  Thu Jan 18 19:11:40 2007
From: do-not-reply at jboss.com (genman)
Date: Thu, 18 Jan 2007 19:11:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Last minute 2.0 API
	suggestions
Message-ID: <8597823.1169165500097.JavaMail.jboss@colo-br-02.atl.jboss.com>


1. Have Node.removeChild() return true if the node was removed
2. Add a Node.size() or Node.dataSize() to count basically getData().size(). The problem (in terms of efficiency) is that getData() makes a copy.
3. Node.putIfAbsent() should be consistent with ConcurrentMap, and return Object. Consider adding other methods of ConcurrentMap.
4. Change Node.put to Node.putAll to be consistent with Map.putAll().

I'm working on a Node -> Map adaptor, sort of a poor man's PojoCache, and find these basic methods missing.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003572#4003572

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003572


From do-not-reply at jboss.com  Thu Jan 18 19:35:37 2007
From: do-not-reply at jboss.com (evk)
Date: Thu, 18 Jan 2007 19:35:37 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)]
	- JBoss and NLB
Message-ID: <9605088.1169166937885.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi, does Windows NLB (Network Load Balancing) just not interact well with JBoss clustering, or have other people gotten it to work?

I'm trying to set up a set of machines as a JBoss cluster but also set them up as an NLB cluster, to take care of load balancing. JBoss seems to hang and lock up on startup when I try this.

Any help appreciated. Has this been tried before?



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003573#4003573

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003573


From do-not-reply at jboss.com  Thu Jan 18 20:14:29 2007
From: do-not-reply at jboss.com (ron.sigal@jboss.com)
Date: Thu, 18 Jan 2007 20:14:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Non connected remoting clients throwing java.lang.Except
Message-ID: <26424402.1169169269874.JavaMail.jboss@colo-br-02.atl.jboss.com>

I started working on http://jira.jboss.org/jira/browse/JBREM-657 yesterday.  What I've been doing is adding a Client.quickDisconnect() and a Client.quickRemoveListener() that parallel Client.disconnect() and Client.removeListener() but don't attempt to communicate with the server.  Of course, they should be used only when it is clear that there is a problem communicating with the server.

Does that work for Messaging?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003577#4003577

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003577


From do-not-reply at jboss.com  Thu Jan 18 20:35:59 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Thu, 18 Jan 2007 20:35:59 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Non connected remoting clients throwing java.lang.Except
Message-ID: <4889478.1169170559309.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes... but what about this throw new Exception when a client is disconnected... and what situation the client gets disconnected on leasing?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003587#4003587

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003587


From do-not-reply at jboss.com  Thu Jan 18 20:37:56 2007
From: do-not-reply at jboss.com (brc135)
Date: Thu, 18 Jan 2007 20:37:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Profiler] - Re: Profiler work
	for realtime time-series data?
Message-ID: <8179225.1169170676262.JavaMail.jboss@colo-br-02.atl.jboss.com>

I got it up and working (I think)...

My next question is, is there a way to look / analyze the logs files without the webapp?  If so, how do you get at the data, it seems to be a binary file...

And can this be done while the profiler is still logging?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003588#4003588

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003588


From do-not-reply at jboss.com  Thu Jan 18 20:42:45 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Thu, 18 Jan 2007 20:42:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Non connected remoting clients throwing java.lang.Except
Message-ID: <16030545.1169170965505.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ron... this is just personal preference...

but do you have a better name than quickRemove... quickWhatever?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003591#4003591

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003591


From do-not-reply at jboss.com  Fri Jan 19 00:06:07 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Fri, 19 Jan 2007 00:06:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <15100441.1169183167444.JavaMail.jboss@colo-br-02.atl.jboss.com>

Clebert,

I've just taken a look at your check in. Here are several questions:

1. ServerConnectionFactoryEndpoint sends a view update to ALL active connections returned by the ConnectionManager instance. Why does it send it to all? Didn't you mention that this has to be sent on a "filtered" list of connections? This JIRA issue (http://jira.jboss.com/jira/browse/JBMESSAGING-759) is about this.

2. Why the code that sends the view update (currently hosted by ServerConnectionFactoryEndpoint) is not located at ConnectionManager level? Seems more appropriate to be there...

3. Why do you keep a different "activeConnections" set at ConnectionManger level? Speed reasons? You got all the information you need in the "endpoints" map already. Keep in mind that cluster view update events are very rare events, considering the time scale at which messaging operates. Why would you need to optimize that, risking cache desynchronization?

4. What's the difference between a LoadBalancingPolicy and a LoadBalancingFactory? Why do you configure a ConnectionFactory service with the latter instead of the former?

5. What is this:
            // FailoverNodeID is not on the map, that means the ConnectionFactory was updated
  |             // by another connection in another server.. So we will have to guess the failoverID
  |             // by numeric order. Case we guessed the new server wrongly we will have to rely on
  |             // redirect from failover
  |       
      (ClusteringAspect.java line 211).
      Why do we need to guess the failover ID?

6. ClusterViewUpdateTest.testUpdateConnectionFactory() fails.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003637#4003637

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003637


From do-not-reply at jboss.com  Fri Jan 19 00:24:35 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Fri, 19 Jan 2007 00:24:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- New Rule: each thirdparty dependency bug should have a test
Message-ID: <7127092.1169184275147.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have added a new org.jboss.test.thirdparty package for all tests related to bugs caused by thirdparty dependencies. 

If a bug is reported for a thirdparty dependency, a functional test must be added here. The associated JIRA issue shouldn't be closed until we make sure there is a test for it, and the test passes.

I started with Remoting (org.jboss.test.thirdparty.remoting).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003642#4003642

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003642


From do-not-reply at jboss.com  Fri Jan 19 01:07:21 2007
From: do-not-reply at jboss.com (tom.elrod@jboss.com)
Date: Fri, 19 Jan 2007 01:07:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Re: Strategy for supporting NonSerializable data
Message-ID: <2169854.1169186841831.JavaMail.jboss@colo-br-02.atl.jboss.com>

JBoss Serialization will allow serialization of classes not implementing Serializable interface, but requires jdk 1.5 (no problem) and the class have a void constructor (which can be private).  Don't know if this has changed, but might be too limiting?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003656#4003656

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003656


From do-not-reply at jboss.com  Fri Jan 19 01:17:11 2007
From: do-not-reply at jboss.com (tom.elrod@jboss.com)
Date: Fri, 19 Jan 2007 01:17:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Re: Exception propagation
	using HTTP servlet transport on 1.
Message-ID: <9470764.1169187431641.JavaMail.jboss@colo-br-02.atl.jboss.com>

Mind posting (or sending me) that modification?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003660#4003660

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003660


From do-not-reply at jboss.com  Fri Jan 19 01:21:27 2007
From: do-not-reply at jboss.com (tom.elrod@jboss.com)
Date: Fri, 19 Jan 2007 01:21:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Re: Servlet transport is completely broken.
Message-ID: <15108692.1169187687836.JavaMail.jboss@colo-br-02.atl.jboss.com>

Great.  Thanks.  I have created jira issue - http://jira.jboss.com/jira/browse/JBREM-675.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003661#4003661

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003661


From do-not-reply at jboss.com  Fri Jan 19 02:50:57 2007
From: do-not-reply at jboss.com (bela@jboss.com)
Date: Fri, 19 Jan 2007 02:50:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)]
	- Re: Distributed Lock Mechanism
Message-ID: <2530073.1169193057283.JavaMail.jboss@colo-br-02.atl.jboss.com>

There is a DLM that's part of JGroups but it is somewhat unsupported (I didn't write it and the guy who did is too busy to support it): http://www.koders.com/java/fidC73888EED1C2ECCDD56AF33274914F9AB36641F7.aspx?s=DistributedLockManager

The existing DLM is also a bit costly, as it does a 2-phase lock acquisition phase. Also, IIRC it requires total consensus, not majority-based consensus as you described above.
You also have to solve the issue where a member which is currently holding the lock crashes. In this case, you have to release all the locks held by a crashed member.

If you submit a concise spec then something like what you described could be implemented in a few days...

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003677#4003677

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003677


From do-not-reply at jboss.com  Fri Jan 19 03:15:53 2007
From: do-not-reply at jboss.com (joe.marques@jboss.com)
Date: Fri, 19 Jan 2007 03:15:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - ManyToMany enhancement?
Message-ID: <15718378.1169194553793.JavaMail.jboss@colo-br-02.atl.jboss.com>

Given this object model:


  | Object_A    LinkT    Object_B
  |    Aid  ---  Aid
  |              Bid  ---  Bid   
  |             Stuff
  | 

I would like to use the following ManyToMany style on classes A & B:


  | @Entity
  | @Table(name = "Object_A")
  | class A {
  |    @ManyToMany
  |    @JoinTable(name="LinkT",
  |       joinColumns={@JoinColumn(name="Aid")},
  |       inverseJoinColumns={@JoinColumn(name="BiD")})
  |    List<B> Bs = new ArrayList<B>();
  | }
  | 
  | @Entity
  | @Table(name = "Object_B")
  | class B {
  |    @ManyToMany(mappedBy="Bs")
  |    List<A> As = new ArrayList<A>();
  | }
  | 

But I also want to be able to access the linking table directly, because it has extra metadata called "stuff" that I insert directly into it with a different Entity mapped directly on top of it:


  | @Entity
  | @Table(name = "LinkT")
  | class Link {
  |    // Aid, Bid, and Stuff
  | }
  | 

Thus, I can do one of two things right now:

1) Use the @ManyToMany annotations to construct the relationships.  This allows me to navigate via getAs() and getBs() to the other side of the relationship and back again.  However, doing it this way prevents me from inserting the additional "stuff" qualifier, which can only be calculated at insertion-time.

2) I can use a slightly more obtuse procedure to insert data into the linking table via the Link entity.  Here, I've ensured that the data in all three tables is correct, and that the relational part is identical to what is persisted in the above scenario.  This method affords me the additional opportunity to insert this qualifying "stuff" into the linking table.  Unfortunately, when I go to access the relationships - getAs() and getBs() - they always return empty sets.

Now, I went into all of this presuming that this was most likely a limitation of the current JBoss ejb3 implementation (inserting data through a direct map on top of the linking table, and selecting from the @ManyToMany context), but it would sure be nice if this was a JBoss extension.

After the data is inserted into the linking table with the additional "stuff" attached to it, then you could choose the complexity of your JPQL according to the needs in your calling context:

A simple condition:

  | SELECT someA FROM A someA, IN (someA.Bs) someB
  | WHERE someB.property=<value>
  | 

A complex condition, requiring the use of "stuff":

  | SELECT someA FROM A someA, LinkT link
  | WHERE someA.Aid = link.Aid
  | AND link.stuff=<value>
  | 

Thoughts on this?

-joseph

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003685#4003685

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003685


From do-not-reply at jboss.com  Fri Jan 19 03:35:02 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Fri, 19 Jan 2007 03:35:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)]
	- Re: Distributed Lock Mechanism
Message-ID: <9684727.1169195702422.JavaMail.jboss@colo-br-02.atl.jboss.com>

Perhaps something similar to the DLM in JGroups could be implemented as a part of a common clustering library, as I think it takes away from JGroups' core focus to have it reside in JGroups.  (IMO)

Re: the problem of the lock owner crashing, surely JGroups FD can kick in, and when a new view is issued, locks held by missing members can be automatically released?

Further, timeouts can be applied to ensure locks cannot be held forever, although this may undermine the purpose of the lock in the first place.  Replicated deadlock, anyone?  :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003697#4003697

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003697


From do-not-reply at jboss.com  Fri Jan 19 04:16:05 2007
From: do-not-reply at jboss.com (bela@jboss.com)
Date: Fri, 19 Jan 2007 04:16:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)]
	- Re: Distributed Lock Mechanism
Message-ID: <11920741.1169198165576.JavaMail.jboss@colo-br-02.atl.jboss.com>

The issue of releasing locks from crashed members has already been solved and is part of the current DLM, I just mentioned it as one of the issues for a potential re-implementation.
Yes, leasing of locks could help preventing distributed deadlocks, this could be part of a new implementation.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003709#4003709

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003709


From do-not-reply at jboss.com  Fri Jan 19 05:16:50 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Fri, 19 Jan 2007 05:16:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Last minute 2.0 API
	suggestions
Message-ID: <21469680.1169201810561.JavaMail.jboss@colo-br-02.atl.jboss.com>

"genman" wrote : 
  | 1. Have Node.removeChild() return true if the node was removed
  | 

Need to think about how big an impact this will have on the interceptor chain since this calls remove(Fqn).

"genman" wrote : 
  | 2. Add a Node.size() or Node.dataSize() to count basically getData().size(). The problem (in terms of efficiency) is that getData() makes a copy.
  | 3. Node.putIfAbsent() should be consistent with ConcurrentMap, and return Object. Consider adding other methods of ConcurrentMap.
  | 4. Change Node.put to Node.putAll to be consistent with Map.putAll().
  | 

Makes sense.  I've added the APIs and basic impl's, which we can revise/refactor over time.
"genman" wrote : 
  | I'm working on a Node -> Map adaptor, sort of a poor man's PojoCache, and find these basic methods missing.

An interesting idea; I'd like to see a separate thread on this though so we can discuss

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003733#4003733

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003733


From do-not-reply at jboss.com  Fri Jan 19 05:50:08 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Fri, 19 Jan 2007 05:50:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Last minute 2.0 API
	suggestions
Message-ID: <27987249.1169203808469.JavaMail.jboss@colo-br-02.atl.jboss.com>

"manik.surtani at jboss.com" wrote : "genman" wrote : 
  |   | 1. Have Node.removeChild() return true if the node was removed
  |   | 
  | 
  | Need to think about how big an impact this will have on the interceptor chain since this calls remove(Fqn).
  | 

This is actually not a good idea - the whole concept of Nodes are Nodes that are attached to a tree.  If a node has been removed, a reference to it will not be of much use at all.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003746#4003746

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003746


From do-not-reply at jboss.com  Fri Jan 19 06:29:54 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Fri, 19 Jan 2007 06:29:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <17812365.1169206194913.JavaMail.jboss@colo-br-02.atl.jboss.com>

"falazar" wrote : anonymous wrote : 
  |   | The "End Task" is not terminology that is defined by the web console. The caption of each of the transition buttons is determined by the name of the corresponding transition. In this case, the "websale" example process happens to have transitions named "End Task". 
  | 
  | The "End" "Cancel" and "Save" are rather confusing, we changed those to be specfic action names so users would know what they were doing, like "Submit Request" and such.
  | 

+1.  So we should give some thought on how the user can specify button names and link them to transition names.  By default, the transition names are chosen, but the user should be able to override these.   If no transition name is specified and no button name is given, we can't do anything else except come up with a silly generic name.

"falazar" wrote : And the "Cancel" does not actually cancel the task or the process, so it is very ambigously named, we changed it to "Go back to inbox" and added a Cancel Request transition button.

good point.  that button got me fooled too.   since there is a task.cancel method, i thougt it was cancelling the task.  "Back to Inbox" is indeed better

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003766#4003766

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003766


From do-not-reply at jboss.com  Fri Jan 19 06:32:57 2007
From: do-not-reply at jboss.com (hendra_netm)
Date: Fri, 19 Jan 2007 06:32:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Fail-over design questions
Message-ID: <30733250.1169206377468.JavaMail.jboss@colo-br-02.atl.jboss.com>

"timfox" wrote : When you failover, non persistent messages would be lost. Therefore we can't just fail over to redistribute load, since people would get upset if suddenly their non persistent messages disappeared.

Sorry, I still don't get your answer.

The intention of failover over shutdown is not to redistristibute load. It is done to keep the service available. So users still can send messages without knowing that there is a maintenance take place.

Shut down is done by administrators/operators. They know what will happen to non persistent messages when they shut down the server. I think it is unlikely that they will be surprised on their own action.

Anyway, with or without failover, shut down a server will make non persistent messages dissapeared. Why is this failover going to make them upset?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003768#4003768

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003768


From do-not-reply at jboss.com  Fri Jan 19 06:40:23 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Fri, 19 Jan 2007 06:40:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - added profiles to the
	build
Message-ID: <18893594.1169206823499.JavaMail.jboss@colo-br-02.atl.jboss.com>

in order to add profiles capabilities to the build, i have added 

<property file="${jbpm.root}/build/profiles/${profile}.profile.properties" />

to all the build files that import the base.project.build.xml

that way, you can specify profile=jboss5 in your ${user.home}/jbpm/build.properties and then these profile properties will get loaded before the build/build.properties

that way you can create profiles with different sets of libraries to test with.

i don't have any specific profiles defined yet.  there is just an example that contains the same library versions as the main properties file.

note that i also have removed the 

<property file="build.properties" />

since it was not used

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003770#4003770

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003770


From do-not-reply at jboss.com  Fri Jan 19 06:41:33 2007
From: do-not-reply at jboss.com (timfox)
Date: Fri, 19 Jan 2007 06:41:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Fail-over design questions
Message-ID: <16686540.1169206893753.JavaMail.jboss@colo-br-02.atl.jboss.com>

If you want to do this, just shutdown the server.

The client connections will then break, and they'll failover to another node, no extra code is necessary.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003772#4003772

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003772


From do-not-reply at jboss.com  Fri Jan 19 06:50:04 2007
From: do-not-reply at jboss.com (timfox)
Date: Fri, 19 Jan 2007 06:50:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Fail-over design questions
Message-ID: <21813069.1169207404662.JavaMail.jboss@colo-br-02.atl.jboss.com>

As long as your clients are ok with losing np messages then this should work, but in the general case I don't think is acceptable.

I would prefer a situation where you can flick a switch on the jmx console to prevent any new connections being created on a node, then query the console to find out who (ip address? client id? machine name?) the clients are, then the sys admin can kindly find those clients and cleanly shut them down.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003776#4003776

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003776


From do-not-reply at jboss.com  Fri Jan 19 06:51:33 2007
From: do-not-reply at jboss.com (timfox)
Date: Fri, 19 Jan 2007 06:51:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Fail-over design questions
Message-ID: <9206611.1169207493447.JavaMail.jboss@colo-br-02.atl.jboss.com>

"hendra_netm" wrote : 
  | Anyway, with or without failover, shut down a server will make non persistent messages dissapeared. 

Not necessarily, as mentioned in my last post, there are other ways to do it that don't involve the loss of np messages.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003777#4003777

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003777


From do-not-reply at jboss.com  Fri Jan 19 07:51:49 2007
From: do-not-reply at jboss.com (hendra_netm)
Date: Fri, 19 Jan 2007 07:51:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Fail-over design questions
Message-ID: <31880190.1169211109780.JavaMail.jboss@colo-br-02.atl.jboss.com>

"timfox" wrote : As long as your clients are ok with losing np messages then this should work, but in the general case I don't think is acceptable.
  | 
  | I would prefer a situation where you can flick a switch on the jmx console to prevent any new connections being created on a node, then query the console to find out who (ip address? client id? machine name?) the clients are, then the sys admin can kindly find those clients and cleanly shut them down.

Well, that will be very great if that can be done. Actually that is the perfect solution of my problem. I just know that jmx console can do those.

I will take a look on how this can work.

Thank you very much for your time.

Regards,
Hendra


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003805#4003805

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003805


From do-not-reply at jboss.com  Fri Jan 19 08:19:06 2007
From: do-not-reply at jboss.com (timfox)
Date: Fri, 19 Jan 2007 08:19:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Fail-over design questions
Message-ID: <25695076.1169212746400.JavaMail.jboss@colo-br-02.atl.jboss.com>

"hendra_netm" wrote : 
  | I will take a look on how this can work.
  | 

Great.

anonymous wrote : 
  | Thank you very much for your time.
  | 

You're welcome.

I have created a JIRA task for this:

http://jira.jboss.com/jira/browse/JBMESSAGING-761

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003811#4003811

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003811


From do-not-reply at jboss.com  Fri Jan 19 08:35:16 2007
From: do-not-reply at jboss.com (stevehalsey)
Date: Fri, 19 Jan 2007 08:35:16 -0500 (EST)
Subject: [jboss-dev-forums] [Nukes Development] - Re: URIencoding is not
	working... Not able to save the Germa
Message-ID: <23433756.1169213716841.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi,

You say using JBoss you managed to get GETs to process the UTF-8 correctly, but not the POSTs.  I found your article because I had the opposite problem!  

I had read http://java.sun.com/developer/technicalArticles/Intl/HTTPCharset/ and managed to get POSTs to correctly be decoded by puttting the following call to httpServletRequest.setCharacterEncoding("UTF-8") in your servlet processRequest or doGet or doPut methods:-


    protected void processRequest(HttpServletRequest httpServletRequest,
			HttpServletResponse httpServletResponse) 
    throws ServletException, IOException {
		LOG.debug("ENTERING processRequest method.");
    	//As this is the UTF-8 servlet then the assumption is that all params are UTF-8 encoded.
    	//If we didn't do this then the Servlet Engine would assume ISO-8859-1 or use the
    	//charset header if it was sent (most browsers don't seem to ever send this though)
   
		//If you uncomment these two test lines below it will cause the setCharacterEncoding
		//command to have no effect and your parameters will be MANGLED.
    	//LOG.debug("Testing calling getParameter before setCharacterEncoding, this should screw things up...");
		//String thisShouldScrewThingsUp = httpServletRequest.getParameter("thisShouldScrewThingsUp");
		
		//This servlet expects ALL parameters to be UTF-8 encoded and so the 
		//following setCharacterEncoding MUST be called before ANY reading of parameters
		//from the HttpServletRequest object or it will be too late and the default of
		//ISO-8859-1 will have been used to decode the parameters and so they will be 
		//mangled.
    	LOG.debug("in TestUtfEightParamServlet.processRequest calling httpServletRequest.setCharacterEncoding(\"UTF-8\");");
    	httpServletRequest.setCharacterEncoding("UTF-8");

I then POSTed the following char ? to the server and it correctly recognises it as unicode character U+920d, but then if I uncomment the line that gets the parameter thisShouldScrewThingsUp then it does, as expected, screw up, interpretting the character as characters with Unicode code points \ue9 \u88 \u8d.

So with the above code, POST worked but GET still didn't.

As it says in your post and at:-
http://java.sun.com/developer/technicalArticles/Intl/HTTPCharset/
you can fix this by setting URIencoding = UTF-8 in the server.xml file, but this then means all your apps on that server will have their URIs interpreted as UTF-8 which you may well not want (I don't, since one app on the server still needs to work with ISO-8859-1 encoded URIs).  So I found a way round this is to set useBodyEncodingForURI="true" as follows in server.xml:-

      <!-- A HTTP/1.1 Connector on port 8080 -->
      

After restarting JBoss the above code now works for both POSTs and GETs, but any programs which still work with ISO-8859-1 as the default for decoding their GETs and POSTs should still work OK I think.

Its all very messy and hard to find in the documentation.  It would be good to have a page in the Jboss documentation that explains this kind of thing, maybe there is one but I can't find it?



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003821#4003821

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003821


From do-not-reply at jboss.com  Fri Jan 19 08:44:22 2007
From: do-not-reply at jboss.com (stevehalsey)
Date: Fri, 19 Jan 2007 08:44:22 -0500 (EST)
Subject: [jboss-dev-forums] [Nukes Development] - Re: URIencoding is not
	working... Not able to save the Germa
Message-ID: <32886178.1169214262197.JavaMail.jboss@colo-br-02.atl.jboss.com>

In my last post I tried to display the following char:-

?

but it came up as a question mark.  So if you want to see this character for testing go to:-

http://demo.icu-project.org/icu-bin/convexp?conv=windows-950-2000&b=B6&s=ALL#layout

and its the one in the 07 column and 70 row marked ? 920D

cheers

steve.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003823#4003823

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003823


From do-not-reply at jboss.com  Fri Jan 19 09:14:45 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Fri, 19 Jan 2007 09:14:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] -
	serializable KernelDeployment
Message-ID: <6705592.1169216085462.JavaMail.jboss@colo-br-02.atl.jboss.com>

I was experimenting with serializing a KernelDeployment, unserializing it and trying to deploy it.  I have been unsuccessful so far and would like some hints.  Here's what i do right now:


  |          AbstractKernelDeployer deployer = new AbstractKernelDeployer(kernel);
  |          ObjectInputStream ois = new ObjectInputStream(url.openStream());
  |          KernelDeployment deployment = (KernelDeployment)ois.readObject();
  |          Field field = AbstractKernelDeployment.class.getDeclaredField("installedContexts");
  |          field.setAccessible(true);
  |          field.set(deployment, new CopyOnWriteArrayList<KernelControllerContext>());
  |          ois.close();
  |          deployer.deploy(deployment);
  | 

The "installedContexts" field of AbstractKernelDeployment is transient so I had to instantiate a new one and set the field or otherwise I would get an NPE.  Now, I'm finding that most of the beans, but not all, are NOT getting installed.  They are getting processed, but the state is ERROR condition.  The weird thing is that some of the beans are being installed correctly.  Any hints?



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003837#4003837

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003837


From do-not-reply at jboss.com  Fri Jan 19 10:49:58 2007
From: do-not-reply at jboss.com (joe.marques@jboss.com)
Date: Fri, 19 Jan 2007 10:49:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: ManyToMany enhancement?
Message-ID: <13798160.1169221798333.JavaMail.jboss@colo-br-02.atl.jboss.com>

Even cooler would be to support an extended JPQL syntax that had the best of both worlds.  So, something like:


  | SELECT someA FROM A someA, IN (someA.Bs) someB WHERE someB.stuff=<value>
  | 

Thus, by traversing a ManyToMany you somehow get auto-magical access to the additional qualifiers in the linking table through the relation.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003875#4003875

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003875


From do-not-reply at jboss.com  Fri Jan 19 11:15:36 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Fri, 19 Jan 2007 11:15:36 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: New Rule: each thirdparty dependency bug should have a t
Message-ID: <27725235.1169223336690.JavaMail.jboss@colo-br-02.atl.jboss.com>

So that means we could use thirdparty's API to such tests, or we have to exercize onlye Messaging API?

Suppose  a BUG requires a lot of work to be reproduced under Messaging API (due to load or whatever) but it's easily replicated while using Remoting API. Could we make usage of Remoting API on these tests?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003896#4003896

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003896


From do-not-reply at jboss.com  Fri Jan 19 11:43:54 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Fri, 19 Jan 2007 11:43:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <1339109.1169225034411.JavaMail.jboss@colo-br-02.atl.jboss.com>


anonymous wrote : 
  | 1. ServerConnectionFactoryEndpoint sends a view update to ALL active connections returned by the ConnectionManager instance. Why does it send it to all? Didn't you mention that this has to be sent on a "filtered" list of connections? This JIRA issue (http://jira.jboss.com/jira/browse/JBMESSAGING-759 ) is about this.

oops... fixing it... easy fix.

We need a testcase that uses two connectionFactory though.

anonymous wrote : 2. Why the code that sends the view update (currently hosted by ServerConnectionFactoryEndpoint) is not located at ConnectionManager level? Seems more appropriate to be there...
  | 

I was wondering if we should lock the factory while updating the clients or not. Since there is that possibility we would require a ReadWriteLock on the CFEndpoint. Since there is a possibility of locking the CF that was an indication for me the right place for the update would be the CFEndpoint itself.

anonymous wrote : 3. Why do you keep a different "activeConnections" set at ConnectionManger level? Speed reasons? You got all the information you need in the "endpoints" map already. Keep in mind that cluster view update events are very rare events, considering the time scale at which messaging operates. Why would you need to optimize that, risking cache desynchronization?
  | 

The active connection list is on a three levels HashMap list VMId->ClientId->Connection.  It seemed simpler to have a simple HashSet, managed by the very same routines. I can change that if you like.

anonymous wrote : 4. What's the difference between a LoadBalancingPolicy and a LoadBalancingFactory? Why do you configure a ConnectionFactory service with the latter instead of the former?

The LoadBalancingPolicy is not static any more.. you need a Policy per Connection created. This was working before because Serialization was creating new instances for you... and besides you had a comment about not making it static any more.

anonymous wrote : 5. What is this:
  | Code:
  | 
  |             // FailoverNodeID is not on the map, that means the ConnectionFactory was updated
  |             // by another connection in another server.. So we will have to guess the failoverID
  |             // by numeric order. Case we guessed the new server wrongly we will have to rely on
  |             // redirect from failover
  | 	
  | 
  | 
  | (ClusteringAspect.java line 211).
  | Why do we need to guess the failover ID?
  | 

Take a look on the 4th message at this thread (Posted: Mon Jan 15, 2007 17:35 PM) and some others after that.

Case the Factory is updated before failover happens, there is a change the failoverID is not on the MAP any more.
On that case we would require a random node to try a hopping. Instead of a random node I'm guessing the node... and if it fails hopping will take care of it.



anonymous wrote : 6. ClusterViewUpdateTest.testUpdateConnectionFactory() fails. 

I executed the whole testsuite about two times between yesterday and today.. and didn't get any failures. Maybe you have a local problem?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003910#4003910

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003910


From do-not-reply at jboss.com  Fri Jan 19 11:46:49 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Fri, 19 Jan 2007 11:46:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <13472797.1169225209994.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | 6. ClusterViewUpdateTest.testUpdateConnectionFactory() fails.
  | 
  | 
  | I executed the whole testsuite about two times between yesterday and today.. and didn't get any failures. Maybe you have a local problem?

I thought you meant the testupdate I wrote... I will take a look

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003912#4003912

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003912


From do-not-reply at jboss.com  Fri Jan 19 11:52:56 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Fri, 19 Jan 2007 11:52:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	serializable KernelDeployment
Message-ID: <29611191.1169225576186.JavaMail.jboss@colo-br-02.atl.jboss.com>

Very simple testcase to reproduce:


  | <deployment xmlns="urn:jboss:bean-deployer:2.0">
  |    <bean name="Two" class="org.jboss.embedded.test.SimpleBean">
  |       <property name="kernel">
  |          <inject bean="jboss.kernel:service=Kernel"/>
  |       </property>
  |    </bean>
  | </deployment>
  | 
  | 

Upon validation I get:


  | Exception in thread "main" java.lang.IllegalStateException: Incompletely deployed:
  | 
  | *** DEPLOYMENTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
  | Two -> jboss.kernel:service=Kernel{Configured:**ERROR**}
  | 
  |         at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.internalValidate(AbstractKernelDeployer.java:252)
  |         at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.validate(AbstractKernelDeployer.java:163)
  |         at org.jboss.embedded.test.BeanCompilerTester.deploy(BeanCompilerTester.java:65)
  |         at org.jboss.embedded.test.BeanCompilerTester.main(BeanCompilerTester.java:101)
  | 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003915#4003915

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003915


From do-not-reply at jboss.com  Fri Jan 19 12:22:37 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Fri, 19 Jan 2007 12:22:37 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: New Rule: each thirdparty dependency bug should have a t
Message-ID: <5594185.1169227357953.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes. 

All I want to make sure is that after they fix a bug that affects Messaging, they don't break that code again. 

Normally, it is the thirdparty module's responsibility to add functional tests after a bug is identified and fixed, but recent events taught us that this is something cannot be relied upon.

I am not happy about it, I know it's a pain in the rear end.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003925#4003925

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003925


From do-not-reply at jboss.com  Fri Jan 19 12:32:30 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Fri, 19 Jan 2007 12:32:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	serializable KernelDeployment
Message-ID: <12049375.1169227950415.JavaMail.jboss@colo-br-02.atl.jboss.com>

Well, I found one problem.   org.jboss.dependency.spi.ControllerState is being compared with identity ==.  When it is deserialized, you a readResolve isn't done.

Lets see if this fixes the problem.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003928#4003928

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003928


From do-not-reply at jboss.com  Fri Jan 19 12:48:53 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Fri, 19 Jan 2007 12:48:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Non connected remoting clients throwing java.lang.Except
Message-ID: <33074677.1169228933572.JavaMail.jboss@colo-br-02.atl.jboss.com>

Another place where remoting is throwing java.lang.Exception:

java.lang.Exception: Error setting up client lease.
  |         at org.jboss.remoting.MicroRemoteClientInvoker.establishLease(MicroRemoteClientInvoker.java:388)
  |         at org.jboss.remoting.Client.setupClientLease(Client.java:521)
  |         at org.jboss.remoting.Client.connect(Client.java:430)
  |         at org.jboss.remoting.Client.connect(Client.java:420)
  |         at org.jboss.jms.client.remoting.JMSRemotingConnection.start(JMSRemotingConnection.java:99)
  |         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.invoke(ClientConnectionFactoryDelegate.java:200)
  |         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java)
  |         at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:86)
  |         at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java)
  |         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java)
  |         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:71)
  |         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java)
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003941#4003941

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003941


From do-not-reply at jboss.com  Fri Jan 19 12:52:56 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Fri, 19 Jan 2007 12:52:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Non connected remoting clients throwing java.lang.Except
Message-ID: <20445121.1169229176886.JavaMail.jboss@colo-br-02.atl.jboss.com>

"clebert.suconic at jboss.com" wrote : Ron... this is just personal preference...
  | 
  | but do you have a better name than quickRemove... quickWhatever?

What about cancelConnection, cancelLease..... ???

Or... 

clearConnection... clearLease...


The idea would be to disable the socket (or clearing it... cancelling it) without performing a server communication.


And... just to reinforce... can you guys remove those throw java.lang.Exception from the code?




View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003946#4003946

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003946


From do-not-reply at jboss.com  Fri Jan 19 12:53:31 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Fri, 19 Jan 2007 12:53:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Non connected remoting clients throwing java.lang.Except
Message-ID: <5452415.1169229211796.JavaMail.jboss@colo-br-02.atl.jboss.com>

Clebert: Please create a JIRA issue about this, schedule it with Beta2 and assign it to me, as I want to clear all Remoting issues by the end of this week.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003947#4003947

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003947


From do-not-reply at jboss.com  Fri Jan 19 13:05:01 2007
From: do-not-reply at jboss.com (genman)
Date: Fri, 19 Jan 2007 13:05:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Last minute 2.0 API
	suggestions
Message-ID: <2234234.1169229901908.JavaMail.jboss@colo-br-02.atl.jboss.com>

1. It would be nice if it returned a boolean not a Node
2. Actually, I'm not sure "size" is a good idea. It still has to hit the interceptor chain to return the correct value, and for this I assume requires some non-trivial thought.

I'm creating a thread for the Cache->Map thing

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003956#4003956

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003956


From do-not-reply at jboss.com  Fri Jan 19 13:11:43 2007
From: do-not-reply at jboss.com (genman)
Date: Fri, 19 Jan 2007 13:11:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - JBCACHE-941 discussion
Message-ID: <6180612.1169230303052.JavaMail.jboss@colo-br-02.atl.jboss.com>

http://jira.jboss.com/jira/browse/JBCACHE-941

>From the issue:
anonymous wrote : The java.util.Collections utility class supplies useful methods for dealing with legacy interfaces and wrapping collection classes for concurrency, type safety, read-only, etc.
  | 
  | In a simiilar vein, I wrote a "Caches" class that returns java.util.Map instances for a Node, which allow data to be modified through the standard Map interface.
  | 
  | This I expect to be extremely useful for allowing uses to integrate their existing application with JBoss Cache, and will eliminate some of the confusion of using a new API and they can use the API they know best. Users also often demand an API which is "generic" so that their code is not tied to a particular vendor.
  | 
  | There are basically two methods in Caches, one looks like this:
  | 
  | Cache cache = DefaultCacheFactory.getInstance().createCache();
  | Map m = Caches.asMap(cache);
  | m.put("foo", "bar");
  | 
  | The API and examples explain themselves.
  | 
  | "Caches" could also include other useful methods for printing or reporting.
  | 
  | Note that this functionality could be considered duplicated from PojoCache...
  | 

Here is one method:
   /**
  |     * Returns a {@link Map}, where map keys are named children of the given Node,
  |     * and values are kept under a single key for this node.
  |     * The map may be safely concurrently modified through this Map or externally,
  |     * and its contents reflect the cache state and
  |     * existing data of the Node.
  |     * This means that {@link ConcurrentModificationException} is never thrown
  |     * and all methods are thread safe.
  |     * <p/>
  |     * The map is not serializable.
  |     * <p/>
  |     * Usage note:  As a single node is used for every key, it is most efficient to store
  |     * data for a single entity (e.g. Person) in a single object.
  |     * <p/>
  |     * Also, when using a {@link CacheLoader} for storage, keys used must be valid as
  |     * part of the {@link Fqn} used in calls. Generally speaking, simple string values are
  |     * preferred. 
  |     */

Manik suggests also an adaptor for JCache (JSR-107).

Actually, it might also be nifty if JBoss Cache could supply adaptors for competing Cache APIs. I'm not sure of the legality of this for commercially published interfaces.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003959#4003959

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003959


From do-not-reply at jboss.com  Fri Jan 19 13:30:57 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Fri, 19 Jan 2007 13:30:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Non connected remoting clients throwing java.lang.Except
Message-ID: <31590373.1169231457399.JavaMail.jboss@colo-br-02.atl.jboss.com>

http://jira.jboss.org/jira/browse/JBMESSAGING-762

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003971#4003971

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003971


From do-not-reply at jboss.com  Fri Jan 19 14:16:44 2007
From: do-not-reply at jboss.com (dwin)
Date: Fri, 19 Jan 2007 14:16:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Design of
	wsimport
Message-ID: <28364962.1169234204060.JavaMail.jboss@colo-br-02.atl.jboss.com>

Just a neat feature to include,

it'd be nice if xs:annotation <xs: documentation> gets translated into java docs.  

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003989#4003989

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003989


From do-not-reply at jboss.com  Fri Jan 19 14:22:45 2007
From: do-not-reply at jboss.com (Glooper)
Date: Fri, 19 Jan 2007 14:22:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Serialization] - Re:
	resolveClass and annotateClass
Message-ID: <1198867.1169234565074.JavaMail.jboss@colo-br-02.atl.jboss.com>

I had a few hours today to have a look at this so was examining your code to see how I would solve my problem. Please correct me if I'm wrong! 

I can't see how you could ever call annotateClass as class information is persisted on the stream seperately to the objects. You are using the ClassMetaData class to describe a class, and you persisting that information using the StreamingClass class.

I'm guessing that to change jboss serialization such that different class loaders can be used for different serialized objects, I would have to include the relevant information within the ClassMetaData... and change StreamingClass such that it can store the classloader information in saveStream and read the class loader information at the beginning of the readStream method. Does this make sense? 

Ben

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003991#4003991

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003991


From do-not-reply at jboss.com  Fri Jan 19 14:27:01 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Fri, 19 Jan 2007 14:27:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Design of
	wsimport
Message-ID: <21143689.1169234821827.JavaMail.jboss@colo-br-02.atl.jboss.com>

The JAXB XJC api does this, so it will be there ;)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003992#4003992

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003992


From do-not-reply at jboss.com  Fri Jan 19 14:30:29 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Fri, 19 Jan 2007 14:30:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Serialization] - Re:
	resolveClass and annotateClass
Message-ID: <29209035.1169235029239.JavaMail.jboss@colo-br-02.atl.jboss.com>

Would you happen to have an usecase for where annotateClass/annotateProxyClass would be useful?

A testcase would be even better.


I will have to change where I'm writing the classNames, probably using some delegation to JBossObjectInputStream/JBossObjectOutputStream. I will have to take a look.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003993#4003993

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003993


From do-not-reply at jboss.com  Fri Jan 19 14:31:20 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Fri, 19 Jan 2007 14:31:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Serialization] - Re:
	resolveClass and annotateClass
Message-ID: <28598720.1169235080656.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : I will have

I mean... we... case you want to contribute a fix.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003995#4003995

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003995


From do-not-reply at jboss.com  Fri Jan 19 14:34:46 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Fri, 19 Jan 2007 14:34:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <4383435.1169235286728.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : +1.  So we should give some thought on how the user can specify button names and link them to transition names.  By default, the transition names are chosen, but the user should be able to override these.   If no transition name is specified and no button name is given, we can't do anything else except come up with a silly generic name.

I can add an attribute to the transitionButton component for an optional caption.  If the caption is not present, use the transition name.  If the transition is unnamed, then I guess just "Transition ID 1234" is the best we can do...

"tom.baeyens at jboss.com" wrote : "falazar" wrote : And the "Cancel" does not actually cancel the task or the process, so it is very ambigously named, we changed it to "Go back to inbox" and added a Cancel Request transition button.
  | 
  | good point.  that button got me fooled too.   since there is a task.cancel method, i thougt it was cancelling the task.  "Back to Inbox" is indeed better

Hmmm, upon reflection I think that a cancel task button is a lot more useful than the current cancel button is - what if I change this button to "Cancel Task" which calls the .cancel() method on the task instance, and just drop the idea of the original cancel button?  Especially in light of the new navigation structure.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003997#4003997

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003997


From do-not-reply at jboss.com  Fri Jan 19 14:38:54 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Fri, 19 Jan 2007 14:38:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	serializable KernelDeployment
Message-ID: <28725403.1169235534725.JavaMail.jboss@colo-br-02.atl.jboss.com>

That fixed the problem.  I updated ControllerState with the change.  The final problem I have is that SystemProperty substitution doesn't happen after serialization (or before depending how you look at it).  Looking into this now.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004002#4004002

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004002


From do-not-reply at jboss.com  Fri Jan 19 14:43:16 2007
From: do-not-reply at jboss.com (graj)
Date: Fri, 19 Jan 2007 14:43:16 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Profiler] - unable to use jboss
	Profiler
Message-ID: <12976659.1169235796737.JavaMail.jboss@colo-br-02.atl.jboss.com>

I wrote a simple method (in a seperate public class) that prints the number 1 to 20 to the console with a delay of 5 sec. This method was called from a Servlet.

Steps to recreate my scenario:
1. start JBoss App Server
2. Activate the profiler using the MBean
3. invoke my Servlet and wait for the 20 numbers to be printed on the console
4. stop the profiler by stoping it using the MBean. At this point I see the .gz files getting updated with data.
5. Now open the Profiler's Web Application and enter the directory where the log entrries are made.

My Problem:
I see the method I wrote listed in the memory section of the process view and not in the 'methods' section of the Process View in the resulting analysis data.

Since my method is not listed in the 'methods section' of the process view, I am unable to analyze the response time for invoking the method. Can you please help me.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004004#4004004

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004004


From do-not-reply at jboss.com  Fri Jan 19 14:45:08 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Fri, 19 Jan 2007 14:45:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - JBWS-1464
	Clarification of the MTOM related specifications.
Message-ID: <5467151.1169235908246.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have been looking at the following specification to try and get a better understanding of how the mime type for binary content is specified in the schema and in the actual document transmitted: -

http://www.w3.org/TR/xml-media-types/

My interpretation is that the 'expectedContentTypes' attribute is an annotation which is added to the XML schema to list the mime types that can be represented by the binary content.

My interpretation of the 'contentType' is that this is used on the document instance itself (not the schema) to specify what is the actual mime type of the binary data being transmitted.

So in the schema 'expectedContentTypes' can be used to list a set of mime types and then in the document 'contentType' is used to specify what is being transmitted in this document instance.

However in the user guide and in some test cases we seem to be using 'contentType' in the place of 'expectedContentTypes' or in addition to 'expectedContentTypes' in the schema.  

This seems incorrect to me, should it really be possible to use 'contentType' in the schema?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004005#4004005

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004005


From do-not-reply at jboss.com  Fri Jan 19 14:47:45 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Fri, 19 Jan 2007 14:47:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Profiler] - Re: unable to use
	jboss Profiler
Message-ID: <12498357.1169236065412.JavaMail.jboss@colo-br-02.atl.jboss.com>

You probably started capturing after the method was invoked.

On that case I never got any ENTER_METHOD event for the method you were analyzing. You would have to start capturing before your method is called.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004008#4004008

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004008


From do-not-reply at jboss.com  Fri Jan 19 14:50:22 2007
From: do-not-reply at jboss.com (Glooper)
Date: Fri, 19 Jan 2007 14:50:22 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Serialization] - Re:
	resolveClass and annotateClass
Message-ID: <30160390.1169236222737.JavaMail.jboss@colo-br-02.atl.jboss.com>

We write a container and as such have different classloaders throughout the system for the various the applications. To perform HA we sometimes replicate state across many applications... this is done by serializing the object hierarchy... but different objects in this hierarchy can have come from different applications and thus may have different ClassLoaders.
We currently annote information about the classloader in the annotateClass and annotateProxyClass methods by writing the classloader information as a String on the stream... thus when resolveClass or resolveProxyClass is called we can read the classloader information from the stream and use it to lookup the relevant class loader to load the class.

I hope that makes sense! :)

Ben
  

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004010#4004010

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004010


From do-not-reply at jboss.com  Fri Jan 19 14:54:10 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Fri, 19 Jan 2007 14:54:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1464
	Clarification of the MTOM related specificatio
Message-ID: <22664336.1169236450256.JavaMail.jboss@colo-br-02.atl.jboss.com>

You are correct. Also the expectedContentType value, if present is ignored, since the xerces schema API can't represent it.

-Jason

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004013#4004013

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004013


From do-not-reply at jboss.com  Fri Jan 19 15:05:30 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Fri, 19 Jan 2007 15:05:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <6233997.1169237130261.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm not in favour of end-users being able to realy cancel the task. An admin/manager might and even then only if the process is not hindered/disrupted in any way.

Regarding the name issue... I'm still in favour of requireing the name to be filled in the pd.....

besides that I also have an interesting one ;-) : use the description from the jpdl file as a tooltip

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004016#4004016

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004016


From do-not-reply at jboss.com  Fri Jan 19 15:21:23 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Fri, 19 Jan 2007 15:21:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <15441774.1169238083240.JavaMail.jboss@colo-br-02.atl.jboss.com>

"kukeltje" wrote : I'm not in favour of end-users being able to realy cancel the task. An admin/manager might and even then only if the process is not hindered/disrupted in any way.

Point taken - however, consider this.  The task form designer (person) may elect to simply leave that button off of the task forms.  Or, he/she may put the button on, but use rendered="#{some custom EL}" to make it only visible to certain classes of users (admins for example).  If the component exists, it can be used or not used.  If it doesn't exist, it may only be not used. :-)

"kukeltje" wrote : Regarding the name issue... I'm still in favour of requireing the name to be filled in the pd.....
  | 
  | besides that I also have an interesting one ;-) : use the description from the jpdl file as a tooltip

Good idea - I can use the description by default, or allow the designer to override it in the standard JSF way using the title attribute.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004025#4004025

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004025


From do-not-reply at jboss.com  Fri Jan 19 15:37:04 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Fri, 19 Jan 2007 15:37:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <27684904.1169239024948.JavaMail.jboss@colo-br-02.atl.jboss.com>

"Ovidiu" wrote : 6. ClusterViewUpdateTest.testUpdateConnectionFactory() fails.

I have fixed this... The problem was ConnectionFactoryCallbackHandler::getState was removed.

When the Callback instance is created, state still null as its set later in the AOP stack. I had it set on the constructor but it was not actually being set. My fault was not to document this properly I guess.

I have fixed this by placing getState back to the code.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004031#4004031

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004031


From do-not-reply at jboss.com  Fri Jan 19 15:40:58 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Fri, 19 Jan 2007 15:40:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Profiler] - Re: Profiler work
	for realtime time-series data?
Message-ID: <23628337.1169239258794.JavaMail.jboss@colo-br-02.atl.jboss.com>

There is no way to analyze the data while the profiler still capturing data. I need the logs closed before analyzing the data.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004032#4004032

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004032


From do-not-reply at jboss.com  Fri Jan 19 16:33:10 2007
From: do-not-reply at jboss.com (gideonraj)
Date: Fri, 19 Jan 2007 16:33:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Profiler] - Re: unable to use
	jboss Profiler
Message-ID: <21649572.1169242390049.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi Clebert,
Thanks for your response. I tried again by starting the profiler capture before invoking my method. The result is the same (my method is not listed in the 'methods section' of the Process View)...

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004049#4004049

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004049


From do-not-reply at jboss.com  Fri Jan 19 17:36:13 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Fri, 19 Jan 2007 17:36:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <27100437.1169246173335.JavaMail.jboss@colo-br-02.atl.jboss.com>

Well the transaction issues have gone away with the changes I described, however I updated with the latest from CVS to test out some other changes and now when I deploy from the GPD I get the message: 

FileUploadExcepption: the request was rejected because no multi-part boundary was found

This is the same processdefinition that uploaded successfully yesterday.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004054#4004054

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004054


From do-not-reply at jboss.com  Fri Jan 19 17:47:05 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Fri, 19 Jan 2007 17:47:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <27227800.1169246825796.JavaMail.jboss@colo-br-02.atl.jboss.com>

Make sure you've got the new commons-fileupload jar.  If not you'll have to rebuild the web console with it.  There was a JIRA issue about this - http://jira.jboss.com/jira/browse/JBPM-698.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004055#4004055

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004055


From do-not-reply at jboss.com  Fri Jan 19 18:05:09 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Fri, 19 Jan 2007 18:05:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <17514434.1169247909278.JavaMail.jboss@colo-br-02.atl.jboss.com>

The console appears to have the latest commons-fileupload.jar. However I am using the 3.0.12 GPD that is installed in JBoss-IDE. 

Hum.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004065#4004065

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004065


From do-not-reply at jboss.com  Fri Jan 19 19:07:37 2007
From: do-not-reply at jboss.com (RajaniKanth)
Date: Fri, 19 Jan 2007 19:07:37 -0500 (EST)
Subject: [jboss-dev-forums] [Nukes Development] - Re: URIencoding is not
	working... Not able to save the Germa
Message-ID: <28867736.1169251657637.JavaMail.jboss@colo-br-02.atl.jboss.com>

I selected a hardway to resolve the issue by writing a filter to our application which will set the URLencoding for the application. That worked but that shoun't be the way I thought.

>From the start I thought there should be some property using which we should be able to set the encoding.

Anyway thanks for giving me the answer I am expecting.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004081#4004081

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004081


From do-not-reply at jboss.com  Fri Jan 19 19:23:04 2007
From: do-not-reply at jboss.com (bhar99328)
Date: Fri, 19 Jan 2007 19:23:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: libraries in an
	.ear file
Message-ID: <27787043.1169252584754.JavaMail.jboss@colo-br-02.atl.jboss.com>

I apologize if I've missed the answer to this question elsewhere, but does JBoss-5.0.0-Beta1 support the JEE 5 /lib directory in the root of ear file? 

I have a JEE 5 application that I've been using on glassfish, with shared library jars in the /lib folder of the ear file, but I am unable to deploy this application on JBoss 5... I get a NoClassDefFound exception for each class in the shared library jars (during deployment of EJBs).

I'd just like to know if I still have to do the ear's manifest Class-Path thing...

... And I'd much rather be using JBoss...

Thanks in advance!

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004091#4004091

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004091


From do-not-reply at jboss.com  Fri Jan 19 20:08:20 2007
From: do-not-reply at jboss.com (ron.sigal@jboss.com)
Date: Fri, 19 Jan 2007 20:08:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Non connected remoting clients throwing java.lang.Except
Message-ID: <21133192.1169255300807.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi Clebert,

I'm a little confused:

"clebert" wrote : 
  | at least throw a meaninful Exception
  | 

"clebert" wrote : 
  | can you guys remove those throw java.lang.Exception from the code?
  | 

If I understand, you want something like ClientDisconnectedException instead of a plain Exception?  You're not saying we shouldn't throw an exception at all, right?

"clebert" wrote : 
  | Ron... this is just personal preference...
  | 
  | but do you have a better name than quickRemove... quickWhatever?
  | 

disconnectALaGrandeVitesse()? :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004094#4004094

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004094


From do-not-reply at jboss.com  Fri Jan 19 23:56:45 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Fri, 19 Jan 2007 23:56:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <9915831.1169269005990.JavaMail.jboss@colo-br-02.atl.jboss.com>

Well since I don't have a latest GPD, I tweaked the UploadServlet to not check for multipart and use the older commons-fileupload.jar.

This change makes jbpm3.2 not compatible with earlier versions of the GPD. Is this something we really want?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004143#4004143

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004143


From do-not-reply at jboss.com  Sat Jan 20 00:13:45 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Sat, 20 Jan 2007 00:13:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new build script
	updates committed
Message-ID: <712164.1169270025777.JavaMail.jboss@colo-br-02.atl.jboss.com>

When I run build it takes 5 minutes checking that each dependencies is upto date (which is is). Nothing is downloading, but the check takes a long time. I can't seem to figure out how to avoid the check.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004148#4004148

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004148


From do-not-reply at jboss.com  Sat Jan 20 00:24:11 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Sat, 20 Jan 2007 00:24:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: JMS Example in 3.2
	Beta
Message-ID: <1531720.1169270651978.JavaMail.jboss@colo-br-02.atl.jboss.com>

Tom addressed these issues through:

http://jira.jboss.com/jira/browse/JBPM-824
http://jira.jboss.com/jira/browse/JBPM-825

However,

1) The JMSMessage Service is getting a ClassCastException when casting the lookup of java:/JmsXa to an XAConnectionFactory which should work and did work previously.

2) The NewProcessInstance command needs to set the variablesMap contained with the command.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004158#4004158

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004158


From do-not-reply at jboss.com  Sat Jan 20 01:53:54 2007
From: do-not-reply at jboss.com (Cyberax)
Date: Sat, 20 Jan 2007 01:53:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Re: Exception propagation
	using HTTP servlet transport on 1.
Message-ID: <5033200.1169276034648.JavaMail.jboss@colo-br-02.atl.jboss.com>

It's in the code of the ServletServerInvoker which I uploaded:


  |          try
  |          {
  |             // call transport on the subclass, get the result to handback
  |             invocationResponse = invoke(invocationRequest);
  |          }
  |          catch(Throwable ex)
  |          {
  |             log.debug("Error thrown calling invoke on server invoker.", ex);
  |             invocationResponse = ex;
  | 
  | 	        String sessionId=null;
  | 	        if (invocationRequest instanceof InvocationRequest)
  | 	           sessionId=((InvocationRequest)invocationRequest).getSessionId();
  |             invocationResponse=new InvocationResponse(sessionId,ex,true,null);
  |             //isError = true;
  |          }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004164#4004164

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004164


From do-not-reply at jboss.com  Sat Jan 20 02:21:20 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Sat, 20 Jan 2007 02:21:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <21991890.1169277680402.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, so here it is in JIRA:

http://jira.jboss.org/jira/browse/JBAS-4001

I have backported the changes to 4.2.x. I will get it into a CP release for 4.0.5 once I figure out the new process. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004172#4004172

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004172


From do-not-reply at jboss.com  Sat Jan 20 06:53:35 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Sat, 20 Jan 2007 06:53:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: new simplified menu
	structure
Message-ID: <1173132.1169294015556.JavaMail.jboss@colo-br-02.atl.jboss.com>

+1 on  the rendering (or not) of the cancel button. But still... if a task has to be cancelled, in many case this should influence the flow and I therefor would model this into the workflow and have a 'cancel' transition etc... sometimes only for admins or so. Realy cancelling the task could lead to missing information or so... 

All these consequences have to be documented realy good.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004218#4004218

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004218


From do-not-reply at jboss.com  Sat Jan 20 07:03:05 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Sat, 20 Jan 2007 07:03:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: libraries in an
	.ear file
Message-ID: <7591737.1169294585265.JavaMail.jboss@colo-br-02.atl.jboss.com>

wrong forum.. use the jboss AS forum for this.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004219#4004219

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004219


From do-not-reply at jboss.com  Sat Jan 20 07:24:19 2007
From: do-not-reply at jboss.com (timfox)
Date: Sat, 20 Jan 2007 07:24:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <10779057.1169295859449.JavaMail.jboss@colo-br-02.atl.jboss.com>

"weston.price at jboss.com" wrote : Can you confirm your simple JBM/jPBM test works with the adapter in HEAD? It should be a simple drop in replacement. 

Certainly. I am a bit rushed right now, but will get around to this sometime early next week.

http://jira.jboss.com/jira/browse/JBMESSAGING-763

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004228#4004228

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004228


From do-not-reply at jboss.com  Sat Jan 20 07:25:56 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Sat, 20 Jan 2007 07:25:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <5490354.1169295956658.JavaMail.jboss@colo-br-02.atl.jboss.com>

Not a problem. Again, it is already backported to 4.2. 4.0.5 is next, however, I am not sure if I have to do anything special for the new cummulative patch cycle stuff. The changes to the adapter need to go in regardless of JBM, they offer improvements all around. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004229#4004229

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004229


From do-not-reply at jboss.com  Sat Jan 20 07:36:32 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Sat, 20 Jan 2007 07:36:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <17740155.1169296592239.JavaMail.jboss@colo-br-02.atl.jboss.com>

CRAP...now I remember the issue. The problem you were seeing was that in the old code (now 4.0.5) support for handling a RuntimeException in an non specified transaction context had to be done via a SystemProperty. Being that you had not set this, it didn't work. However, I was never happy about having to set something like that to get that behavior. This requirement is removed in the latest code so it's best to go with that anyway. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004233#4004233

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004233


From do-not-reply at jboss.com  Sat Jan 20 07:45:58 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Sat, 20 Jan 2007 07:45:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re:
	URLSelectorStrategy
Message-ID: <1163309.1169297158771.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hey genman,
  What are your plans for this? Do you still want to handle this? If so, where are you on it? 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004236#4004236

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004236


From do-not-reply at jboss.com  Sat Jan 20 07:53:04 2007
From: do-not-reply at jboss.com (timfox)
Date: Sat, 20 Jan 2007 07:53:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <32009373.1169297584936.JavaMail.jboss@colo-br-02.atl.jboss.com>

I've finally managed to look at the new code.

A few questions:

1. The update information is sent from server to client in a ConnectionFactoryUpdateMessage instance. This needs to be wrapped in a MessagingMarshallable, otherwise we can't version it.

2. ServerConnectionFactoryEndpoint::updateclusteredClients() is currently only called when a connection factory is deployed / undeployed. It is not called when a node joins or leaves the cluster. It needs to be called in this case too.
Also you need to add tests to check that the update occurs in this situation.

3. Why have you made MessageCallbackHandler and ConnetionFactoryCallbackHandler implement the same (new) interface (CallbackHandler) ? This seems redundant since they are never called polymorphically anyway.

4. I was unsure why init() was being called on the ClientClusteredConnectionFactoryDelegate every time a failover view change occurred...

Cheers


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004237#4004237

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004237


From do-not-reply at jboss.com  Sat Jan 20 10:16:43 2007
From: do-not-reply at jboss.com (radzish)
Date: Sat, 20 Jan 2007 10:16:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: LayouStrategy and
	StrategyResponse API
Message-ID: <2231140.1169306203663.JavaMail.jboss@colo-br-02.atl.jboss.com>

I installed JBoss Alpha1 and it seems like layout strateries are not invoked at all any more.

Is that true?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004273#4004273

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004273


From do-not-reply at jboss.com  Sat Jan 20 10:38:33 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Sat, 20 Jan 2007 10:38:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: LayouStrategy and
	StrategyResponse API
Message-ID: <8562924.1169307513135.JavaMail.jboss@colo-br-02.atl.jboss.com>

it is true.

We can certainly help you to achieve the customization you are wanting to do in another manner.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004280#4004280

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004280


From do-not-reply at jboss.com  Sat Jan 20 10:51:30 2007
From: do-not-reply at jboss.com (radzish)
Date: Sat, 20 Jan 2007 10:51:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: LayouStrategy and
	StrategyResponse API
Message-ID: <13954009.1169308290143.JavaMail.jboss@colo-br-02.atl.jboss.com>

In what way? ;)

Should I describe my goal/task?

Or you probably preparing another way to provide "pluggable API that allows the layout developer to influence the content of the page that is
about to be rendered" (it is from JBossReferenceGuide).?

You know, it is probably the most important phrase from guide that had a great impact on my decision to use JBoss Portal and not some other Portal Framework.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004289#4004289

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004289


From do-not-reply at jboss.com  Sat Jan 20 12:14:26 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Sat, 20 Jan 2007 12:14:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: LayouStrategy and
	StrategyResponse API
Message-ID: <15385158.1169313266402.JavaMail.jboss@colo-br-02.atl.jboss.com>

If think that using JBoss Portal internals would be a better thing as it is going to remain the same for the 2.x branch.

We are not saying there should not be entry points for such customizations by removing them. We wanted to remove something that is flawed by design rather than providing something that half works.

You should describe your use case and we can work together to make it work. The rendering process can still be improved to fit your use case and I would be glad to help you there.


"radzish" wrote : In what way? ;)
  | 
  | Should I describe my goal/task?
  | 
  | Or you probably preparing another way to provide "pluggable API that allows the layout developer to influence the content of the page that is
  | about to be rendered" (it is from JBossReferenceGuide).?
  | 
  | You know, it is probably the most important phrase from guide that had a great impact on my decision to use JBoss Portal and not some other Portal Framework.
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004322#4004322

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004322


From do-not-reply at jboss.com  Sat Jan 20 12:15:00 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Sat, 20 Jan 2007 12:15:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - JBWS-1464 -
	Adding MTOM support to WSDL To Java - Design
Message-ID: <5161585.1169313300115.JavaMail.jboss@colo-br-02.atl.jboss.com>

This thread is to discuss the options for adding MTOM support to WSDL To Java.

There are a number of options for how this can be implemented and a number of obstacles to overcome for the more advanced implementations.  The main obstacle is that it is not possible to get access to the expectedContentTypes attribute using the xerces schema API.

On the plus side there currently does not apear to be any work required on generating the JAX RPC mapping file, this just requires a variable mapping (which does not contain type information) in the corresponding java-xml-type-mapping.  This mapping is already correctly generation.

At the moment I see the following options for how this could be implemented: -

1 - Map all binary types to javax.activation.DataHandler

A global configuration option can be set to switch on MTOM mapping and all types that are based on xs:base64Binary or xs:hexBinary can be mapped to javax.activation.DataHandler.

2 - Global configuration to specify what binary types should be mapped to.

A global configuration option can be added to specify what the binary types should be mapped to.  This would assume all binary types can be mapped to the same type.

3 - Allow configuration to map XML types to specific Java types.

This would mean if the schema contains different types based off the binary types then it will be possible for each to be mapped to a different Java type.

This would however not work when the binary types are mapped as follows as it will not be possible to differentiate between them: -

<element name="legacyData" 
  |          xmime:expectedContentTypes="text/xml" 
  |          type="xmime:base64Binary"/>
  | 

4 - A more advanced configuration to allow the specific elements to be identified.


  |   <complexType name='Employee'>
  |      <sequence>
  |         <element name="firstname" type="xsd:string"/>
  |         <element name="lastname" type="xsd:string"/>
  |         <element name="legacyData" xmime:expectedContentTypes="text/xml" 
  |            type="xmime:base64Binary"/>
  |      </sequence>
  |   </complexType>
  | 

So for this example the configuration would allow the user to specify that the element legacyData of the type Employee should be mapped to a specific Java type.

5 - Switch on generation of synthetic annotations.

The xerces implementation has a feature that can be enabled to generate a synthetic annotation when a schema component has non-schema attributes.  This annotation could then be parsed to extract the expectedContentTypes.  This of course would be xerces implementation specific.

An appropriate Java type can then be selected based on the list of content types.

6 - Add a pre-generation step to read mime information from the WSDL

Add a step before generation to read all expectedContentTypes from the schema (Possibly using the synthetic annotations approach), this will store the data in a model - as part of the main generation step this model can be read if a binary type is found to check if mime types have been specified.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004323#4004323

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004323


From do-not-reply at jboss.com  Sat Jan 20 12:56:02 2007
From: do-not-reply at jboss.com (radzish)
Date: Sat, 20 Jan 2007 12:56:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: LayouStrategy and
	StrategyResponse API
Message-ID: <25474181.1169315762273.JavaMail.jboss@colo-br-02.atl.jboss.com>

First of all thank you for quick responses and for your help!

I need to implement the following layout strategy:
Assume we have some region, containing several portlets with different orders.
Portlets can be only of 2 states: "minimized" and "normal";
Only 1 portlet in reagion can be in "normal" state at a time;
If portlet with order X becomes minimized, portlet with order X+1 must be "normilized"; if X = N; then first-order portlet must be normilized;
If portlet with order X becomes normal, previous normal portlet must be minimized;
By default, portlet with order 0 must be in normal state;

thanks in advance!


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004335#4004335

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004335


From do-not-reply at jboss.com  Sat Jan 20 13:41:46 2007
From: do-not-reply at jboss.com (timfox)
Date: Sat, 20 Jan 2007 13:41:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <28503571.1169318506425.JavaMail.jboss@colo-br-02.atl.jboss.com>

Clebert-

I just tried to deploy the scoped sar in JBAS and it fails, complaining that it cannot find a property editor for ConnectionFactory::setLoadBalancingFactory.

Looking at the code, the method setLoadBalancingFactory() takes a LoadBalancingFactory, but the MBean method takes a String.

I have fixed this, so I can get on with my work. You may want to review my fix since it was very quick.

This tells me one thing, you added an MBean attribute without adding a corresponding test for it.

All new functionality needs to have unit tests, so please could you add a test.

Cheers.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004347#4004347

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004347


From do-not-reply at jboss.com  Sat Jan 20 13:55:33 2007
From: do-not-reply at jboss.com (timfox)
Date: Sat, 20 Jan 2007 13:55:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <6223328.1169319333068.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have done an initial check, and it seems the problem I had is resolved when using JCA from head :)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004349#4004349

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004349


From do-not-reply at jboss.com  Sat Jan 20 13:58:27 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Sat, 20 Jan 2007 13:58:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Problems JCA JMS
	inflow issue and tx NotSupported
Message-ID: <7787794.1169319507182.JavaMail.jboss@colo-br-02.atl.jboss.com>

Cool. Again, you can set that system property to get the desired behavior in the 4.0.5 stuff, but I think the approach is at best pretty weak, and downright f*!@ed up at the worst. If you wanted to do this, you would have to add the following to your run.sh or run.conf script

-Dorg.jboss.asf.jms.useold=true

Again, not the best approach and it was added in haste. I would prefer that it died a quick and swift death. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004352#4004352

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004352


From do-not-reply at jboss.com  Sat Jan 20 13:59:19 2007
From: do-not-reply at jboss.com (brc135)
Date: Sat, 20 Jan 2007 13:59:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Profiler] - Re: Profiler work
	for realtime time-series data?
Message-ID: <17018415.1169319559582.JavaMail.jboss@colo-br-02.atl.jboss.com>

Thanks for the reply,  do you know of any other tools / programs that might work for us?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004353#4004353

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004353


From do-not-reply at jboss.com  Sat Jan 20 14:13:47 2007
From: do-not-reply at jboss.com (timfox)
Date: Sat, 20 Jan 2007 14:13:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Non connected remoting clients throwing java.lang.Except
Message-ID: <17008523.1169320427271.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hmmm, this:


  | Can not make remoting client invocation due to not being connected to server.
  | at org.jboss.remoting.Client.invoke(Client.java:639)
  | at org.jboss.remoting.Client.invoke(Client.java:627)
  | at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:118)
  | at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_N5002091796089334799.invokeNext(ClientSessionDelegate$createConsumerDelegate_N5002091796089334799.java)
  | at org.jboss.jms.client.container.StateCreationAspect.handleCreateConsumerDelegate(StateCreationAspect.java:153)
  | at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect17.invoke(StateCreationAspect17.java)
  | at
  | 

Looks very much like another remoting bug I have replicated here:

http://jira.jboss.com/jira/browse/JBMESSAGING-765

I believe it is a bug in the way remoting handles reference counts for invokers.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004356#4004356

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004356


From do-not-reply at jboss.com  Sat Jan 20 15:15:32 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Sat, 20 Jan 2007 15:15:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - JBAS-3815 -- Fast
	Fail on Connection Pool
Message-ID: <30718659.1169324132598.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have added a feature to 4.2 whereby if the first attempt to acquire a connection fails, no more attempts will be made, that particular connection destroyed and a new one created right away. This is to address complaints in regards to how we handle validation wherein a large pool with lots of connections will take substantial time to fail through the entire pool before a new connection created. 

While timeouts and background validation may help, this option seems to be a decent feature request. This behavior can be turned on/off and is off by default. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004375#4004375

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004375


From do-not-reply at jboss.com  Sat Jan 20 17:25:05 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Sat, 20 Jan 2007 17:25:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-696 - Reference counting on Lease during fai
Message-ID: <24303574.1169331905300.JavaMail.jboss@colo-br-02.atl.jboss.com>

The test passes with the remoting head as per Jan 20 2007, so I am closing the issue.  For the future, when adding tests directly related to remoting, put them under tests/src/org/jboss/test/thirdparty/remoting

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004393#4004393

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004393


From do-not-reply at jboss.com  Sat Jan 20 20:20:46 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Sat, 20 Jan 2007 20:20:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <26873818.1169342446035.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have finished the modifs and the basic impl of the cms content editor.

Now in dbd configuration, it is possible to swith the default editor (portlet) to cms which present the top files in the cms (index, project and support). Then it is possible to add those files to regions using the arrow buttons.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004438#4004438

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004438


From do-not-reply at jboss.com  Sat Jan 20 21:07:47 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Sat, 20 Jan 2007 21:07:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Non connected remoting clients throwing java.lang.Except
Message-ID: <930666.1169345267647.JavaMail.jboss@colo-br-02.atl.jboss.com>

"ron.sigal at jboss.com" wrote : Hi Clebert,
  | 
  | I'm a little confused:
  | 
  | "clebert" wrote : 
  |   | at least throw a meaninful Exception
  |   | 
  | 
  | "clebert" wrote : 
  |   | can you guys remove those throw java.lang.Exception from the code?
  |   | 
  | 
  | If I understand, you want something like ClientDisconnectedException instead of a plain Exception?  You're not saying we shouldn't throw an exception at all, right?
  | 

This will clear any confusion: http://jira.jboss.org/jira/browse/JBREM-680

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004443#4004443

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004443


From do-not-reply at jboss.com  Sat Jan 20 21:19:42 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Sat, 20 Jan 2007 21:19:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Non connected remoting clients throwing java.lang.Except
Message-ID: <883057.1169345982130.JavaMail.jboss@colo-br-02.atl.jboss.com>

We'll use remoting's CannotConnectException. According their documentation: "Clustering layers can rely this exception to failover."

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004444#4004444

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004444


From m.heidari at armanpaya.com  Sun Jan 21 02:05:17 2007
From: m.heidari at armanpaya.com (m.heidari)
Date: Sun, 21 Jan 2007 10:35:17 +0330
Subject: [jboss-dev-forums] portlet with ajax
Message-ID: <200701210702.l0L72xr1001102@chief.prod.atl2.jboss.com>

Hi,

I want to write a portlet by ajax technology but I don't know how can I do
this. if any one have an example please help me.

Thanks in advance

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20070121/c0b58797/attachment.html 

From do-not-reply at jboss.com  Sun Jan 21 04:58:20 2007
From: do-not-reply at jboss.com (noel.rocher@jboss.com)
Date: Sun, 21 Jan 2007 04:58:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1464 -
	Adding MTOM support to WSDL To Java - Design
Message-ID: <9092028.1169373500032.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 1 - Map all binary types to javax.activation.DataHandler
  | 
  | A global configuration option can be set to switch on MTOM mapping and all types that are based on xs:base64Binary or xs:hexBinary can be mapped to javax.activation.DataHandler. 

I see base64Binary data that should not be considered as attachment. It's a type that is often used for IDs. For exemple, you can have an operation with an ID as argument and an attachment as a result.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004492#4004492

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004492


From do-not-reply at jboss.com  Sun Jan 21 05:12:43 2007
From: do-not-reply at jboss.com (noel.rocher@jboss.com)
Date: Sun, 21 Jan 2007 05:12:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1464 -
	Adding MTOM support to WSDL To Java - Design
Message-ID: <25190959.1169374363646.JavaMail.jboss@colo-br-02.atl.jboss.com>

In practice, we should make simple for users to generate a wsdl. What they are used to do today when the wsdl is not trivial :

- write a java interface that is a copy of the SEI but with all attachment params replaced with String params.
- generate the wsdl with wtools from this interface
- make simple  changes to wsdl to replace string type by what is required for wstools to detect attachments
- test if client side is correctly generated from this wsdl
- test if the server side is working with this stubs calls



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004500#4004500

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004500


From do-not-reply at jboss.com  Sun Jan 21 06:14:42 2007
From: do-not-reply at jboss.com (darran.lofthouse@jboss.com)
Date: Sun, 21 Jan 2007 06:14:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1464 -
	Adding MTOM support to WSDL To Java - Design
Message-ID: <15406000.1169378082048.JavaMail.jboss@colo-br-02.atl.jboss.com>

The process of generating the WSDL from the SEI is covered by a separate Jira task: -
[url]
http://jira.jboss.com/jira/browse/JBWS-1466[/url]

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004514#4004514

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004514


From do-not-reply at jboss.com  Sun Jan 21 12:04:57 2007
From: do-not-reply at jboss.com (smil)
Date: Sun, 21 Jan 2007 12:04:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss/Tomcat Integration] - Need the
	context classloader after create
Message-ID: <9474249.1169399097921.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi,

I've tried to create an easy per deployment logging possibility without many fuss with package prefixes / repository selectors / TCLFilter etc.
This service will look for a log4j.xml or .prop in the META-INF directory of all deployments, and create and register the logger for the deployment.

I'm almost finished, but one part is missing: Web deployments does not publish the context loader before 'start' step, but the classes (and loggers) are created in the 'create' step. 

Basically this means I cannot identify the deploymentinfo from the thread's classloader. Is there a reason why the context loader only set at the end of create into the webmetadata?
Or is it a way around this 'limitation'?

You can have a look at my code at: hxxp://212.52.164.42/jboss/

Any help welcome!

Cheers,

Tamas

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004568#4004568

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004568


From do-not-reply at jboss.com  Sun Jan 21 14:38:56 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Sun, 21 Jan 2007 14:38:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <23878374.1169408336811.JavaMail.jboss@colo-br-02.atl.jboss.com>

"timfox" wrote : 
  | 1. The update information is sent from server to client in a ConnectionFactoryUpdateMessage instance. This needs to be wrapped in a MessagingMarshallable, otherwise we can't version it.
  | 


Ok... I will change this.


"timfox" wrote : 
  | 2. ServerConnectionFactoryEndpoint::updateclusteredClients() is currently only called when a connection factory is deployed / undeployed. It is not called when a node joins or leaves the cluster. It needs to be called in this case too.
  | Also you need to add tests to check that the update occurs in this situation.
  | 


Are you sure about this? I have testcases about this... a testcase that gets the ConnectionFactory updated when a new server joins / leaves the cluster.


"timfox" wrote : 
  | 3. Why have you made MessageCallbackHandler and ConnetionFactoryCallbackHandler implement the same (new) interface (CallbackHandler) ? This seems redundant since they are never called polymorphically anyway.
  | 


I didn't want MessageCallbackHandler to also take care of ConnectionFactories... I thought the dependency would be wrong.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004607#4004607

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004607


From do-not-reply at jboss.com  Sun Jan 21 14:44:04 2007
From: do-not-reply at jboss.com (timfox)
Date: Sun, 21 Jan 2007 14:44:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <29214540.1169408644467.JavaMail.jboss@colo-br-02.atl.jboss.com>

"clebert.suconic at jboss.com" wrote : 
  | 
  | 
  | Are you sure about this? I have testcases about this... a testcase that gets the ConnectionFactory updated when a new server joins / leaves the cluster.
  | 
  | 

Yep.

You need to test when a node crashes (not leaves cleanly), when it crashes it will not undeploy the connection factories first, unlike a clean exit. So if you do not update the failover maps on node join leave you have a problem.


anonymous wrote : 
  | I didn't want MessageCallbackHandler to also take care of ConnectionFactories... I thought the dependency would be wrong.

I don't understand what you're saying. Could you please elucidate?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004608#4004608

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004608


From do-not-reply at jboss.com  Sun Jan 21 15:01:13 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Sun, 21 Jan 2007 15:01:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <11961522.1169409673124.JavaMail.jboss@colo-br-02.atl.jboss.com>

ConnectionFactoryJNDIMapper::onReplicationChange is calling updating ServerCFEndpoing::updateClusteredClients...

onReplicateChange is also setting the new LoadBalancing when the data is being changed.

ClusterViewUpdateTest::testUpdateConnectionFactory is testing updates on CFs... it kills the server and verifies if the connectinFactory was changed.

Test was passing for me on Friday.


anonymous wrote : Quote:
  | 
  | I didn't want MessageCallbackHandler to also take care of ConnectionFactories... I thought the dependency would be wrong.
  | 
  | 
  | I don't understand what you're saying. Could you please elucidate?

I understood you were discussing the idea of the new Callback interface. 

I didn't want to treat ConnectionFactoryUpdates and MessageReceiving on the same classes. that's all.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004610#4004610

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004610


From do-not-reply at jboss.com  Sun Jan 21 15:54:58 2007
From: do-not-reply at jboss.com (timfox)
Date: Sun, 21 Jan 2007 15:54:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <30704727.1169412898848.JavaMail.jboss@colo-br-02.atl.jboss.com>

"clebert.suconic at jboss.com" wrote : ConnectionFactoryJNDIMapper::onReplicationChange is calling updating ServerCFEndpoing::updateClusteredClients...
  | 
  | onReplicateChange is also setting the new LoadBalancing when the data is being changed.
  | 
  | ClusterViewUpdateTest::testUpdateConnectionFactory is testing updates on CFs... it kills the server and verifies if the connectinFactory was changed.
  | 
  | Test was passing for me on Friday.
  | 

I don't see how this could be the case.

Think about it, if a server crashes then the connection factories will not get undeployed.

If you are only updating the view when connection factory is deployed / undeployed then how can the client update be happening?

What am I missing?


anonymous wrote : 
  | 
  | I didn't want MessageCallbackHandler to also take care of ConnectionFactories... I thought the dependency would be wrong.
  | 
  | 

This is fine, but has nothing to do with the point I am making.

I am just saying that creating a new interface is redundant since you are not calling the methods polymorphically.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004614#4004614

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004614


From do-not-reply at jboss.com  Sun Jan 21 16:02:48 2007
From: do-not-reply at jboss.com (timfox)
Date: Sun, 21 Jan 2007 16:02:48 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <8195644.1169413368151.JavaMail.jboss@colo-br-02.atl.jboss.com>

If the client view is being updated, as you say, when a node crashes, then the only other possibility AFAICT is that the connection factory deploy/undeploy even is being triggered when a node crashes.

Can you explain how this happens?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004618#4004618

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004618


From do-not-reply at jboss.com  Mon Jan 22 04:01:58 2007
From: do-not-reply at jboss.com (smil)
Date: Mon, 22 Jan 2007 04:01:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss/Tomcat Integration] - Re: Need
	the context classloader after create
Message-ID: <28744055.1169456518643.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi,

I think I was too quick posting my quertion. I've found a workaround to the problem, since the UCL (which is the parent of the web classloader) is known at that time, so I could identify the web classloader with it.

Cheers,

Tamas

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004735#4004735

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004735


From do-not-reply at jboss.com  Mon Jan 22 06:15:27 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Mon, 22 Jan 2007 06:15:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Bug in transactional delivery in an MDB
Message-ID: <7981194.1169464527493.JavaMail.jboss@colo-br-02.atl.jboss.com>

"ovidiu.feodorov at jboss.com" wrote : 
  | On one hand, the fixes for JBMESSAGING-410 and JBMESSAGING-520 insure that a JMS session created using a JMS connection produced by the JCA connection factory behaves as NON-TRANSACTED in absence of a global JTA transaction. 
  | 
  | This is an intuitive behavior, users rely on it, JBossMQ behaves similarly, and reportedly, other JMS providers as well.
  | 

There is actually nothing in the spec about this behaviour.
The XA stuff is massively underspecified in the JMS spec.
And of course it is optional whether a JMS impl supports XA.

The JBossMQ behaviour is to assume that an XASession behaves like
AUTO_ACKNOWLEDGE when the XASession is not enlisted in a JTA transaction.
(Some JMS implements throw an exception in this case).

There is one exception to this. When the XASession is being used as part of
a ServerSessionPool, the semantics need to be receive then enlist.
So for this, the XASession behaves like there is a transaction, it will be told
later what XID to use for the 2PC protocol.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004783#4004783

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004783


From do-not-reply at jboss.com  Mon Jan 22 07:57:09 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Mon, 22 Jan 2007 07:57:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBAS-3997
Message-ID: <19439509.1169470629958.JavaMail.jboss@colo-br-02.atl.jboss.com>

We only currently cover the case where a previous connection in the pool is invalid.

We don't cover the following cases:

* Somebody bounces the database server (or whatever the backend is)
making it unavailable for a few seconds, the pool will be drained of previous
connections (they are invalid) but then fail immediately to create a new one.

* The error is not raised by the pooling but by something in front of it
i.e. something in the connection manager causes the transient failure

e.g.
1) The original example is where the pool is flushed which causes a small
"window of opportunity" where a request is going through to the old subpool
that is being shutdown, rather than to the new subpool.
2) Other things in the connection manager like a transient failure in the
security login module that creates the subject

If you are really worried about only doing this for transient failures
we could create a subclass of ResourceException, e.g. TransientResourceException 
and then have the places we think can be retried throw this exception,
* pool exhausted
* subpool shutdown
* etc.

We would then only do the retries for a TransientResourceException

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004801#4004801

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004801


From do-not-reply at jboss.com  Mon Jan 22 08:14:41 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Mon, 22 Jan 2007 08:14:41 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	serializable KernelDeployment
Message-ID: <1490591.1169471681156.JavaMail.jboss@colo-br-02.atl.jboss.com>

There are currenly no tests of the MetaData serialization, I've raised a JIRA issue:
http://jira.jboss.com/jira/browse/JBMICROCONT-142

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004806#4004806

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004806


From do-not-reply at jboss.com  Mon Jan 22 08:20:03 2007
From: do-not-reply at jboss.com (hem571)
Date: Mon, 22 Jan 2007 08:20:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Failed to deployed a
	IPC portlet with .sar extension on Jbos
Message-ID: <21967435.1169472003101.JavaMail.jboss@colo-br-02.atl.jboss.com>

I had tried to deploy a .sar extension InterPortlet Communation Portlet onto Jboss Portal 2.6 without success. Has anyone tried this before ??

Also until now we have deployed .war extension files(portlets) on Jboss portal. Hence can we deploy also the .sar file. If yes where(folder) should i deploy it.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004807#4004807

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004807


From do-not-reply at jboss.com  Mon Jan 22 08:50:36 2007
From: do-not-reply at jboss.com (heiko.braun@jboss.com)
Date: Mon, 22 Jan 2007 08:50:36 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1464 -
	Adding MTOM support to WSDL To Java - Design
Message-ID: <30712071.1169473836078.JavaMail.jboss@colo-br-02.atl.jboss.com>

I would favour point (1). This is what i communicated to the users already. It's simple and fits the overall problem the best. There is many cases where

a) you dont know the exact mimetype
b) data is send inlined
c) you need to  pass the content type along

DataHandler is the best chioce IMO.

Regarding Noel's considerations:


anonymous wrote : 
  | I see base64Binary data that should not be considered as attachment. It's a type that is often used for IDs. For exemple, you can have an operation with an ID as argument and an attachment as a result. 
  | 

It's right what you are saying, but in the only (rare) case this becomes a problem is when users types contain base64 types that should be optimized and others that shouldnt at the same time. If this doesnt occur on the same payload then you easily turn off MTOM for that port.

On the otherhand, if you want to meet that rare case a treshold switch should be used to decide at runtime wether or not optimization should be done.

This is a good idea in many cases, because MTOM optimization does pay off only when data reaches several kb. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004817#4004817

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004817


From do-not-reply at jboss.com  Mon Jan 22 09:28:54 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Mon, 22 Jan 2007 09:28:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: LayouStrategy and
	StrategyResponse API
Message-ID: <23603417.1169476134819.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have added in the actual trunk an attempt to match the explanations. It is done by coding an interceptor that goes on the command stack of the portal. 

For now the code can be found in org.jboss.portal.core.WindowInterceptor, but it's likely that it will be removed (because it is not very useful for the actual portal). For now it is here as an attempt to show how to code that kind of stuff.

Later we will see if we can introduce an API that provides those semantics wrapping the internal of portals (but doing a good API is hard...). It could be part of the actual IPC API if we introduce a PageEvent but note sure of that.

To activate it you need to modify in jboss-portal.sar/META-INF/jboss-service.xml

Add in the section <!-- Command stack --> the mbean :

  |    <mbean
  |       code="org.jboss.portal.core.WindowInterceptor"
  |       name="portal:service=Interceptor,type=Command,name=Window"
  |       xmbean-dd=""
  |       xmbean-code="org.jboss.portal.jems.as.system.JBossServiceModelMBean">
  |       <xmbean/>
  |    </mbean>
  | 

and modify the portal:service=InterceptorStackFactory,type=Command mbean to add a dependency :


  | <depends-list-element>portal:service=Interceptor,type=Command,name=Window</depends-list-element>




View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004821#4004821

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004821


From do-not-reply at jboss.com  Mon Jan 22 09:33:19 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Mon, 22 Jan 2007 09:33:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Last minute 2.0 API
	suggestions
Message-ID: <1935765.1169476400006.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | 1. It would be nice if it returned a boolean not a Node 
  | 

is this specifically useful though? 

anonymous wrote : 
  | 2. Actually, I'm not sure "size" is a good idea. It still has to hit the interceptor chain to return the correct value, and for this I assume requires some non-trivial thought. 
  | 

Well, retrieving the data or keys would also involve the interceptor stack and this is just a convenience atop that.  But more than that, I'm doing it to get it in to the API.  We can optimise and improve on this later, but at worst it will have the same overhead as doing getKeys().size()




View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004822#4004822

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004822


From do-not-reply at jboss.com  Mon Jan 22 09:40:17 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Mon, 22 Jan 2007 09:40:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: JBCACHE-941
	discussion
Message-ID: <29373611.1169476817526.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | 
  | Manik suggests also an adaptor for JCache (JSR-107). 
  | 
  | 

Just that JCACHE uses a Map interface rather than a tree structured one.

In general, I think this is a good idea as there are many use cases (Hibernate, among others) where a tree structure is too complex and unnecessary from an API perspective (but necessary from a performance/efficiency perspective).

E.g., Coherence offers a Map interface, but internally key/value pairs are broken up into buckets for finer grained concurrency and replication.

anonymous wrote : 
  | Actually, it might also be nifty if JBoss Cache could supply adaptors for competing Cache APIs. I'm not sure of the legality of this for commercially published interfaces.
  | 

Hmm, this would mean shipping with those interfaces though.  Perhaps these could be additional downloads?  Like you said, we'd need to research legality anyway.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004827#4004827

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004827


From do-not-reply at jboss.com  Mon Jan 22 10:07:40 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Mon, 22 Jan 2007 10:07:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <280080.1169478460339.JavaMail.jboss@colo-br-02.atl.jboss.com>

"timfox" wrote : If the client view is being updated, as you say, when a node crashes, then the only other possibility AFAICT is that the connection factory deploy/undeploy even is being triggered when a node crashes.
  | 
  | Can you explain how this happens?

The update is happening on ConnectionFactoryJNDIMapper::onReplicationChange..


Look at the method's implementation, you will see a call to updateClusteredClients:


  | line 359:            endpoint.updateClusteredClients(delArr, failoverMap);
  | 


And the LoadBalancingPolicy is being updated at

anonymous wrote : 
  | line 348:            del.setDelegates(delArr);
  | 

This is the very same routine we were using to rebing the ConnectionFactory when the ViewChanged, fired by the ClusteredPostOffice's replicator. We don't undeploy/deploy when a node crashes... we rebing the ConnectionFActory and the place I was telling you.

anonymous wrote : I am just saying that creating a new interface is redundant since you are not calling the methods polymorphically. 

Ah... I see what you mean.... I wanted to do more refactoring on it and have it totally poliymorphically as you were saying but I would need to move some stuff for that.  I will take a look if would be possible to refactor it a little bit more.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004840#4004840

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004840


From do-not-reply at jboss.com  Mon Jan 22 10:15:20 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Mon, 22 Jan 2007 10:15:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <15745143.1169478921010.JavaMail.jboss@colo-br-02.atl.jboss.com>

"timfox" wrote : Clebert-
  | 
  | I just tried to deploy the scoped sar in JBAS and it fails, complaining that it cannot find a property editor for ConnectionFactory::setLoadBalancingFactory.
  | 
  | Looking at the code, the method setLoadBalancingFactory() takes a LoadBalancingFactory, but the MBean method takes a String.
  | 
  | I have fixed this, so I can get on with my work. You may want to review my fix since it was very quick.
  | 
  | This tells me one thing, you added an MBean attribute without adding a corresponding test for it.
  | 
  | All new functionality needs to have unit tests, so please could you add a test.
  | 
  | Cheers.

I just changed this in top of what Ovidiu had before... Ovidiu had a LoadBalancingPolicy and I placed a LoadBalancingFactory in replacement.

I actually started doing this by using a String the same way you changed... but then I realized what Ovidiu had before and I used the same thing.  By looking at his code I thought MBeans would take care of it on the XML description (using a default's constructor)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004843#4004843

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004843


From do-not-reply at jboss.com  Mon Jan 22 10:20:20 2007
From: do-not-reply at jboss.com (fmarchioni)
Date: Mon, 22 Jan 2007 10:20:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Porting a large project
	from Oracle WorkFlow to JBoss BPM
Message-ID: <2822092.1169479220843.JavaMail.jboss@colo-br-02.atl.jboss.com>

Dear jBoss users,
I have to design a new architecture for a large system. At the moment this system is developed using Oracle Application server and Oracle Workflow 2.6 for BPM.

Since the number of BPM is huge I'm planning for the first phase of the porting to keep together Oracle for the old BPM and jBoss for the new BPM that will be written.

But in the future all BPM must be ported to the new architecture.
Anybody has experience with this porting  ? And is JBoss BPM tested with a very large number of processes ? 

Thanks in advance
Francesco

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004849#4004849

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004849


From do-not-reply at jboss.com  Mon Jan 22 10:34:29 2007
From: do-not-reply at jboss.com (timfox)
Date: Mon, 22 Jan 2007 10:34:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <2154072.1169480069910.JavaMail.jboss@colo-br-02.atl.jboss.com>

"clebert.suconic at jboss.com" wrote : 
  | 
  | The update is happening on ConnectionFactoryJNDIMapper::onReplicationChange..
  | 
  | 
  | Look at the method's implementation, you will see a call to updateClusteredClients:
  | 
  | 
  |   | line 359:            endpoint.updateClusteredClients(delArr, failoverMap);
  |   | 
  | 

Sigh... You're still missing the point :)

This line of code is only called when the replication change is a deploy/undeploy of a connection factory:


  | else if (sKey.startsWith(CF_PREFIX) && originatorNodeID != serverPeer.getServerPeerID())
  |          {
  | 

My question was, can you explain to me how this is called when a node crashes?

When a node crashes it won't have the courtesy to undeploy its connection factories first.

So how would this get called?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004852#4004852

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004852


From do-not-reply at jboss.com  Mon Jan 22 10:46:58 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Mon, 22 Jan 2007 10:46:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <31437023.1169480818531.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : Sigh... You're still missing the point :)
  | 
  | This line of code is only called when the replication change is a deploy/undeploy of a connection factory: 

Nope... this place is called also when a node leaves/joins the cluster. Replicator is re-sending the lists when a node leaves...  (crash).

This is exactly the place where we were doing rebinds before.


I just executed  ClusterViewUpdate Test, using run test... and I could see the event fired on logs.

ClusterViewUpdate would fail if the Connection Factory was not updated after a crash.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004858#4004858

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004858


From do-not-reply at jboss.com  Mon Jan 22 10:50:46 2007
From: do-not-reply at jboss.com (timfox)
Date: Mon, 22 Jan 2007 10:50:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <13975564.1169481046496.JavaMail.jboss@colo-br-02.atl.jboss.com>

line of code please?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004860#4004860

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004860


From do-not-reply at jboss.com  Mon Jan 22 10:52:59 2007
From: do-not-reply at jboss.com (timfox)
Date: Mon, 22 Jan 2007 10:52:59 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <8363790.1169481179209.JavaMail.jboss@colo-br-02.atl.jboss.com>

CF_PREFIX is used when a connection factory is deployed/undeployed.

ADDRESS_INFO_KEY is used when a node joins/leaves

What you are now saying is that we make a change with prefix CF_PREFIX when a node joins leaves?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004862#4004862

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004862


From do-not-reply at jboss.com  Mon Jan 22 10:55:07 2007
From: do-not-reply at jboss.com (timfox)
Date: Mon, 22 Jan 2007 10:55:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <6903049.1169481307846.JavaMail.jboss@colo-br-02.atl.jboss.com>

Looking through the code, the only place where a replication change with prefix CF_PREFIX = "CF_" is sent is when a connection factory is deployed or undeployed, i.e. in registerConnectionFactory() and unregisterConnectionFactory().

There is no where else in the code where such a replication change is propagated.

So you still haven't explained how such a replication event gets propagated when a node crashes.....

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004864#4004864

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004864


From do-not-reply at jboss.com  Mon Jan 22 11:00:15 2007
From: do-not-reply at jboss.com (noel.rocher@jboss.com)
Date: Mon, 22 Jan 2007 11:00:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1464 -
	Adding MTOM support to WSDL To Java - Design
Message-ID: <24623053.1169481615776.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : It's right what you are saying, but in the only (rare) case this becomes a problem is when users types contain base64 types that should be optimized and others that shouldnt at the same time. If this doesnt occur on the same payload then you easily turn off MTOM for that port.
  | 

I don't see it as "rare" if you consider that customers are using it as an ID type. 

I'm talking about big WS users with a lot of webservices (several hundreds) where using attachment or not is an implementation detail (in fact, it's an optimisation required to have decent response times). What they need is to a  natural set of functional operations. It's not a good practice to break this for technical reason.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004866#4004866

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004866


From do-not-reply at jboss.com  Mon Jan 22 11:52:15 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Mon, 22 Jan 2007 11:52:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)]
	- Use of JGroups Multiplexer in AS 4.2.0
Message-ID: <14418068.1169484735898.JavaMail.jboss@colo-br-02.atl.jboss.com>

Bela, Vladimir and I had a discussion this AM and decided to defer integration of the JGroups multiplexer into AS 4.2.0.  Primarily this because we want to ensure the issues discussed in http://jira.jboss.com/jira/browse/JGRP-415 are properly handled before we use the multiplexer in a supported AS release.

I will probably add the code hooks to ClusterPartition to support use of the multiplexer (they are already there in JBC 1.4.1), but 4.2.0 will not ship with the multiplexer sar.  This approach will leave the potential for 4.2.0 installs to configure the multiplexer once all issues like JGRP-415 are resolved.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004882#4004882

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004882


From do-not-reply at jboss.com  Mon Jan 22 12:12:21 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Mon, 22 Jan 2007 12:12:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	serializable KernelDeployment
Message-ID: <7943655.1169485941077.JavaMail.jboss@colo-br-02.atl.jboss.com>

I guess SystemProperty substitution happens at XML parsing?  Shouldn't SystemProperty substitution happen when the actual injection happens instead?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004889#4004889

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004889


From do-not-reply at jboss.com  Mon Jan 22 12:14:47 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Mon, 22 Jan 2007 12:14:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
Message-ID: <32246627.1169486087719.JavaMail.jboss@colo-br-02.atl.jboss.com>

- DefaultClusteredPostOffice::nodeLeft  will call cleanLocalDataForNode.

cleanLocalDataForNode will resubmit all the listeners as the CF was being redeployed. This logic was written long time ago.. I didn't change anything on the rebinds logics.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004891#4004891

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004891


From do-not-reply at jboss.com  Mon Jan 22 12:36:02 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Mon, 22 Jan 2007 12:36:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Porting a large
	project from Oracle WorkFlow to JBoss BP
Message-ID: <32926370.1169487362239.JavaMail.jboss@colo-br-02.atl.jboss.com>

wrong forum.. use the user forum for this.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004900#4004900

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004900


From do-not-reply at jboss.com  Mon Jan 22 13:24:49 2007
From: do-not-reply at jboss.com (thomas.diesler@jboss.com)
Date: Mon, 22 Jan 2007 13:24:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Support
	JAXWS on EJB2.1
Message-ID: <5496857.1169490289381.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, I don't think it makes sence either. We remove support for JSR181 annotated EJB2.1 endpoints

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004927#4004927

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004927


From do-not-reply at jboss.com  Mon Jan 22 13:35:57 2007
From: do-not-reply at jboss.com (graj)
Date: Mon, 22 Jan 2007 13:35:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Profiler] - could not find
	agent library on the library path or in the l
Message-ID: <28697505.1169490957764.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi,
I get the could not find following message when I try to run my JbOss server. Any idea why?

'agent library on the library path or in the local directory:jbossInspector"

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004936#4004936

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004936


From do-not-reply at jboss.com  Mon Jan 22 13:53:00 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Mon, 22 Jan 2007 13:53:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Case
	sensitivity in injecting a bean's property
Message-ID: <25632622.1169491980257.JavaMail.jboss@colo-br-02.atl.jboss.com>

There seems to have been a recent change that affects the handling of property injection.

I want to inject the value of the naming service port into another bean.  Previously this worked:

<property name="namingServicePort"><inject bean="jboss:service=Naming" property="port"/></property>

Now it doesn't. I have to use 'property="Port"' with a capital P on Port. Otherwise I get:

javax.management.AttributeNotFoundException: not found: port
  |         at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanIn
  | voker.java:335)
  |         at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java
  | :565)
  |         at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceC
  | ontrollerContext.java:129)
  |         at org.jboss.beans.metadata.plugins.AbstractDependencyValueMetaData.getV
  | alue(AbstractDependencyValueMetaData.java:150)
  | ....

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004942#4004942

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004942


From do-not-reply at jboss.com  Mon Jan 22 13:55:08 2007
From: do-not-reply at jboss.com (genman)
Date: Mon, 22 Jan 2007 13:55:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Last minute 2.0 API
	suggestions
Message-ID: <13574713.1169492108341.JavaMail.jboss@colo-br-02.atl.jboss.com>

The Collection interface has a "boolean remove(Object k)", and it's nice (when writing adaptors, see that other thread) to see if the remove operation actually worked.

One good thing about the Collection interfaces is that they always return information. This suggests that all Node methods should return something. Some thoughts:


  | NodeSPI -
  | void setVersion(DataVersion version); - Return replaced version?
  | void removeChildrenDirect(); - Return count of children removed?
  | void removeChildDirect(Fqn fqn); - boolean true if removed?
  | void removeChildDirect(Object childName); - ""
  | Cache -
  | void removeNode(Fqn fqn); - boolean true if removed
  | void evict(Fqn fqn, boolean recursive); - ""
  | 

I also wonder if Cache.getVersion() shouldn't return a Version (not String) object instead? Version might implement a "before" method as well. It'd be nice for people writing something like this:

Cache c;
if (c.getVersion().before(Version.XYZ))
  throw new Exception("Cache not >= Version XYZ");

I'm not sure how often this use case comes up, though.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004944#4004944

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004944


From do-not-reply at jboss.com  Mon Jan 22 14:32:52 2007
From: do-not-reply at jboss.com (alesj)
Date: Mon, 22 Jan 2007 14:32:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Case
	sensitivity in injecting a bean's property
Message-ID: <15067060.1169494372465.JavaMail.jboss@colo-br-02.atl.jboss.com>

We added direct MBeanServer lookup via attribute for MBeans.

Look-up behaves differently for ServiceControllerContext then for KernelControllerContext.

Look at: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=98875


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004961#4004961

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004961


From do-not-reply at jboss.com  Mon Jan 22 14:33:33 2007
From: do-not-reply at jboss.com (timfox)
Date: Mon, 22 Jan 2007 14:33:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)]
	- Re: Use of JGroups Multiplexer in AS 4.2.0
Message-ID: <27253950.1169494413627.JavaMail.jboss@colo-br-02.atl.jboss.com>

JBoss Messaging relies on the multiplexer to provide channels.

We're due to go GA at end of Feb, when this will be supported with platinum support.

Your point worried me a bit... are you saying that it's not ready/trusted for primetime yet?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004962#4004962

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004962


From do-not-reply at jboss.com  Mon Jan 22 14:35:12 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Mon, 22 Jan 2007 14:35:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Case
	sensitivity in injecting a bean's property
Message-ID: <1205960.1169494512540.JavaMail.jboss@colo-br-02.atl.jboss.com>

I noted the issue between bean and mbean property case a while ago:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=92469

so I'm surprised this is a regression. I don't know why it would have worked because even though the correct case ala java beans for a setPort/getPort is port (based on java.beans.Introspector behavior/javadoc), jmx 1.2, page 40 states:
anonymous wrote : 
  | Case Sensitivity
  | All attribute and operation names derived from these design patterns are casesensitive.
  | For example, this means that the methods getstate and setState
  | define two attributes, one called state that is read-only, and one called State that
  | is write-only.
  | 
  | While case sensitivity applies directly to component names of standard MBeans, it is
  | also applicable to all component names of all types of MBeans, standard or dynamic.
  | In general, all names of classes, attributes, operations, methods, and internal
  | elements defined in the JMX specification are case sensitive, whether they appear as
  | data or as functional code when they are manipulated by management operations.
  | 

so there are conflicting naming conventions. All I can see that we do is to allow a property matching strictness setting that can be specified when referencing a bean property that would relax the case sensitivity issue.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004963#4004963

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004963


From do-not-reply at jboss.com  Mon Jan 22 14:38:56 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Mon, 22 Jan 2007 14:38:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Case
	sensitivity in injecting a bean's property
Message-ID: <21227784.1169494736947.JavaMail.jboss@colo-br-02.atl.jboss.com>

"alesj" wrote : We added direct MBeanServer lookup via attribute for MBeans.
  | 
  | Look-up behaves differently for ServiceControllerContext then for KernelControllerContext.
  | 
  | Look at: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=98875
  | 

Injection of mbean properties had been working before this change though. How was the mbean property name being resolved previously?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004966#4004966

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004966


From do-not-reply at jboss.com  Mon Jan 22 14:44:18 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Mon, 22 Jan 2007 14:44:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	serializable KernelDeployment
Message-ID: <31731274.1169495058200.JavaMail.jboss@colo-br-02.atl.jboss.com>

It would have to be changed at the existing xml processing layers to avoid duplicate substituion issues like we have seen when property replacement was introduced to Properties editor. I would agree that property substitution should be an aspect of setters rather than a paticular property data path.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004969#4004969

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004969


From do-not-reply at jboss.com  Mon Jan 22 15:09:21 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Mon, 22 Jan 2007 15:09:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)]
	- Re: Use of JGroups Multiplexer in AS 4.2.0
Message-ID: <25086596.1169496561966.JavaMail.jboss@colo-br-02.atl.jboss.com>

Thanks for that reminder, Tim! I've got EJBs and web sessions on the brain this week.

The JGRP-415 issue means problems on one service can too easily affect another service.

I'll ping Bela to see how quickly this can be resolved.  The code cutoff for AS 4.2 is meant to be Jan 31, so we didn't want to rush something in for that -- too close. What are your deadlines for when you'd want this in a JGroups

1) beta/CR release for testing.
2) GA

?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004973#4004973

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004973


From do-not-reply at jboss.com  Mon Jan 22 15:09:44 2007
From: do-not-reply at jboss.com (alesj)
Date: Mon, 22 Jan 2007 15:09:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Case
	sensitivity in injecting a bean's property
Message-ID: <26771836.1169496584199.JavaMail.jboss@colo-br-02.atl.jboss.com>

"scott.stark at jboss.org" wrote : How was the mbean property name being resolved previously?
  | 

Simple POJO property look-up - via Configurator.

Looks like it worked since there was already a pojo target underlying in ControllerContext. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004974#4004974

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004974


From do-not-reply at jboss.com  Mon Jan 22 15:17:09 2007
From: do-not-reply at jboss.com (alesj)
Date: Mon, 22 Jan 2007 15:17:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Case
	sensitivity in injecting a bean's property
Message-ID: <23055957.1169497029480.JavaMail.jboss@colo-br-02.atl.jboss.com>

Before:

  |       Object result = context.getTarget();
  |       if (result != null && property != null)
  |       {
  |          KernelConfigurator configurator = controller.getKernel().getConfigurator();
  |          BeanInfo beanInfo = configurator.getBeanInfo(result.getClass());
  |          TargettedJoinpoint joinpoint = configurator.getPropertyGetterJoinPoint(beanInfo, property);
  |          joinpoint.setTarget(result);
  |          result = joinpoint.dispatch();
  |       }
  | 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004977#4004977

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004977


From do-not-reply at jboss.com  Mon Jan 22 15:31:40 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Mon, 22 Jan 2007 15:31:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Case
	sensitivity in injecting a bean's property
Message-ID: <22482250.1169497900093.JavaMail.jboss@colo-br-02.atl.jboss.com>

Then we need to look at how the kernel behaves with beans like:


  | public class BeanWithStates
  | {
  |    public String getstate()
  |    {
  |       return "state";
  |    }
  |    public void setstate(String s)
  |    {
  |    }
  | 
  |    public int getState()
  |    {
  |       return 0;
  |    }
  |    public void setState(int s)
  |    {
  |    }
  | }
  | 

The java.beans.Introspector does not pickup different properties state and State for this:

  | package javabean;
  | 
  | import java.beans.BeanInfo;
  | import java.beans.Introspector;
  | import java.beans.PropertyDescriptor;
  | 
  | import org.junit.Test;
  | 
  | public class TestIntrospector
  | {
  |    @Test
  |    public void testBeanPropertyCase()
  |       throws Exception
  |    {
  |       BeanInfo beanWithStatesInfo = Introspector.getBeanInfo(BeanWithStates.class);
  |       PropertyDescriptor[] props = beanWithStatesInfo.getPropertyDescriptors();
  |       System.out.println("BeanWithStates properties:");
  |       for(PropertyDescriptor p : props)
  |       {
  |          System.out.println(p.getName()+", read: "+p.getReadMethod()+", write: "+p.getWriteMethod());
  |       }
  |    }
  | }
  | 
  | BeanWithStates properties:
  | class, read: public final native java.lang.Class java.lang.Object.getClass(), write: null
  | state, read: public java.lang.String javabean.BeanWithStates.getstate(), write: public void javabean.BeanWithStates.setstate(java.lang.String)
  | 

Instead, it only finds state, but does use the setter/getter that is consistent with the mbean naming conventions. I guess one would have to supply a class level java.beans.BeanInfo to have access to both state and State as properties.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004985#4004985

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004985


From do-not-reply at jboss.com  Mon Jan 22 15:59:00 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Mon, 22 Jan 2007 15:59:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: LayouStrategy and
	StrategyResponse API
Message-ID: <27594061.1169499540202.JavaMail.jboss@colo-br-02.atl.jboss.com>

So actually I transformed that into portal eventing object. Now there are :

base page event :


  | public abstract class PageEvent extends PortalNodeEvent
  | {
  |    ...
  | }
  | 

page render event


  | public class PageRenderEvent extends PageEvent
  | {
  |    ...
  | }
  | 

provide access to a portion of the navigational state managed by the portal :


  | public interface NavigationalStateContext
  | {
  |    WindowState getWindowState(PortalNode window) throws IllegalArgumentException;
  |    void setWindowState(PortalNode window, WindowState windowState) throws IllegalArgumentException;
  |    Mode getMode(PortalNode window) throws IllegalArgumentException;
  |    void setMode(PortalNode window, Mode mode) throws IllegalArgumentException;
  | }
  | 

I have recoded the previous interceptor I did (and removed it) using the public API (so it can be considered as a supported feature and will not break in the future with the 2.x versions).

The example has been commited as org.jboss.portal.core.portlet.test.event.WindowConstraintEventListener and is a little bit complex (because your use case is very special) so I will not list it here.

You can find it in the core-samples module in trunk.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004991#4004991

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004991


From do-not-reply at jboss.com  Mon Jan 22 15:59:53 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Mon, 22 Jan 2007 15:59:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: Plan to improve
	CMS integration
Message-ID: <4207195.1169499593312.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have extracted the samples as core-samples.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004992#4004992

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004992


From do-not-reply at jboss.com  Mon Jan 22 16:02:02 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Mon, 22 Jan 2007 16:02:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: JBWS-1464 -
	Adding MTOM support to WSDL To Java - Design
Message-ID: <14989211.1169499722636.JavaMail.jboss@colo-br-02.atl.jboss.com>

The other problem is that even if the correct type is chosen by tools (say Image), the runtime also needs to know, so JBossXB needs to see the schema annotation as well. JBossXB currently uses xerces as well (although it has an intermediary model) so whatever mechanism would have to be aplied there.

It might make more sense to keep partial support, and assume certain mime types, and encourage people that need more to upgrade to JAX-WS, or use AP 1.0 instead of MTOM (which doesnt have this problem since it's in the WSDL).

-Jason 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004993#4004993

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4004993


From do-not-reply at jboss.com  Mon Jan 22 16:47:33 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Mon, 22 Jan 2007 16:47:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Portal public API
	updates
Message-ID: <30265283.1169502453629.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have updated the org.jboss.portal.api package with a new kind of event and an interface which expose a part of the navigational state managed by the portal.

The event is RenderPageEvent and it allows listeners to be aware of when a page is rendered by the portal.

The interface for navigational state is NavigationalStateContext and is available from the PortalNodeEventContext provided in the listener callback


  | public interface PortalNodeEventListener
  | {
  |    PortalNodeEvent onEvent(PortalNodeEventContext context, PortalNodeEvent event);
  | }
  | 


  | public interface PortalNodeEventContext
  | {
  |    ...
  |    NavigationalStateContext getNavigationalStateContext();
  |    ...
  | }
  | 


  | public interface NavigationalStateContext
  | {
  |    WindowState getWindowState(PortalNode window) throws IllegalArgumentException;
  |    void setWindowState(PortalNode window, WindowState windowState) throws IllegalArgumentException;
  |    Mode getMode(PortalNode window) throws IllegalArgumentException;
  |    void setMode(PortalNode window, Mode mode) throws IllegalArgumentException;
  | }
  | 

This allows for example to read or update the different window state when rendering a page :


  | if (event instanceof RenderPageEvent)
  | {
  |    NavigationalStateContext nsctx = context.get NavigationalStateContext();
  |    PortalNode pageNode = event.getNode();
  |    for (Iterator i = pageNode.getChildren().iterator();i.hasNext();)
  |    {
  |       PortalNode child = (PortalNode)i.next();
  |       if (child.getType() == PortalNode.TYPE_WINDOW)
  |       {
  |          nsctx.setWindowState(child, WindowState.NORMAL);
  |       }
  |    }
  | }
  | 

There is a more complete example in the core-samples module which implement a complex set of constraint on the page.

Please look at the API and look if nothing look fundamentally wrong because this is going to become part of the supported API.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005010#4005010

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005010


From do-not-reply at jboss.com  Mon Jan 22 18:07:42 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Mon, 22 Jan 2007 18:07:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] -
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <1988427.1169507262762.JavaMail.jboss@colo-br-02.atl.jboss.com>

A problem I ran into while trying to implement the CRUD usecases for *-ds.xml deployments is that the metadata representation of a datasource deployment should be a ServiceDeployment with a xml dom representation of the *-ds.xml deployment. It currently is a ServiceDeployment with a xml dom representation of the transformed *-service.xml containing the jca mbeans.

The two problems that exist are:
1. the profile service only wants to rerun the deployment processing from the Deployer.CLASSLOADER_DEPLOYER on to avoid duplicate metadata parsing and overwriting of the overriden attachment metadata coming from the ManagedObject updates. However, for a datasource deployment, the xsl transform occurrs during the parsing phase. The datasource deployment therefore would need to be run through the parsing deployers. 
2. the datasource deployment does not have a valid representation of the *-ds.xml metadata. There is no xml dom view of the original *-ds.xml that can be updated via ManagedObject/ManagedProperty bindings. The xsl transform always goes to the *-ds.xml VirtualFile and applies the transform to the dom that results from parsing it.

The general issues are deployers not having overridable metadata representations, and not knowing where to start the parsing. The latter issue is really more of not being able to simply rerun all deployers and only have those which have work to do function. I view this is an issue with not having the DeploymentUnit attachments api sufficiently well defined. As a review, here is the current state of the attachments api and its meaning.

Deployers deal with DeploymentUnits as the view on a deployable unit of work. There are two types of DeploymentUnits, containers which can top-level deployments (ears, ejb-jars, wars, sars, -beans.xml, ...), and components which belong to a container deployment (ejbs, mbeans, mc beans, servlets, ...). Components are associated with their container via DeploymentUnit.addComponent(String). Container type deployment can be nested structurally as well, but the DeploymentUnit does not currently expose an api for accessing this. Its a todo.

Metadata can be associated with a DeploymentUnit. This is done using the Attachments api. There are a few different levels of Attachments. A DeploymentUnit is an extension of the Attachments api. A DeploymentUnit also has an Attachments accessed via getTransientManagedObjects(). Adding an attachment via addAttachment adds a transient attachment. To add a transient managed object attachment, call getTransientManagedObjects().addAttachment.

The difference between a transient attachment and transient managed object attachment is that transient managed object attachments are overrides to transient attachments. When you call the DeploymentUnit.getAttachment(), the implementation first looks for a transient managed object attachment override. If that is not found, then the transient attachments are consulted. Deployers should only populate the transient attachments while admin interfaces like the profile service populate the transient managed object attachments.

One should be able to run a deployment trough the deployers, and then re-run the resulting DeploymentUnit through again and have this essentially be a noop in terms of the creation of metadata attachments as a Deployer should look for an existing attachment and avoid recreating it from the deployment content. One area which this is broken is when more than one parsing deployer populates the same metadata model from multiple sources. This happens for standard descriptors/annotations that can be augmented/overriden by jboss descriptors/annotations. With the addition of the DeploymentUnit Set getTypes(), the check for whether parsing should be done in the case of shared metadata attachments could be whether the attachments exist, and the DeploymentUnit has been marked as being of the curent Deployer.getType().

For the datasource deployment issue, the XSL deployers still need to support a dom attachment that represents the pre-transformed xml model so that it can be overriden.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005030#4005030

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005030


From do-not-reply at jboss.com  Mon Jan 22 18:27:10 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Mon, 22 Jan 2007 18:27:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <1422570.1169508430227.JavaMail.jboss@colo-br-02.atl.jboss.com>

Two related issues in terms of the profile service being able to run a deployment through all deployers to avoid having to make assumptions about at what level the metadata that can be edited is available.

The first is that the kernel lifecycle actions need to be stubbed out to be noops to avoid any actual beans being created. When the profile service is in the server, how can this be done?

This also requires separate notions of transient attachments as already requested by Bill. There should be attachments that are candiates for overrides and saving/serialization and those that are not. I think we need a terminology reorg so that:

- transient attachments are metadata that are not serialized or candiates for overriding by admin ManagedObjects.
- attachments are metadata that can be serialized and overriden by admin ManagedObjects.
- managed objects are metadata overrides of the attachments metadata.

A Deployer that uses transient attachments would need to check for these and recreate these from the attachment and other input as needed.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005038#4005038

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005038


From do-not-reply at jboss.com  Mon Jan 22 18:36:35 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Mon, 22 Jan 2007 18:36:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <10488489.1169508995311.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yeah, so I guess you indirectly understand what I was trying to tell you about 2 months ago ;-)



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005042#4005042

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005042


From do-not-reply at jboss.com  Mon Jan 22 18:49:30 2007
From: do-not-reply at jboss.com (jazir1979)
Date: Mon, 22 Jan 2007 18:49:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: EJBTHREE-615 still
	present in Embedded-ALPHA9
Message-ID: <5397985.1169509770504.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi Bill,

We've gone and checked out the latest embedded stuff and built it from SVN.  FYI, it worked well and was not very hard to convert our tests over to use the new Bootstrap class.

However, we are getting exactly the same security problem still.  Instead of a NullPointerException in Util.getSubjectRoles(), we get the IllegalArgumentException because this class has been updated to check for null.

Here is our stacktrace:

  | java.lang.IllegalArgumentException: Subject is null
  | 	at org.jboss.security.Util.getSubjectRoles(Util.java:632)
  | 	at org.jboss.security.plugins.JBossAuthorizationManager.getCurrentRoles(JBossAuthorizationManager.java:302)
  | 	at org.jboss.security.plugins.JBossAuthorizationManager.doesUserHaveRole(JBossAuthorizationManager.java:126)
  | 	at org.jboss.security.plugins.JaasSecurityManager.doesUserHaveRole(JaasSecurityManager.java:401)
  | 	at org.jboss.ejb3.BaseSessionContext.isCallerInRole(BaseSessionContext.java:233)
  | .....
  | 


Would you like me to update JIRA to show that this bug is also present in the latest code based on JBoss5?

thanks,
daniel.

"bill.burke at jboss.com" wrote : We've totally scrapped Embedded EJB3 and started the Embedded JBoss project based on JBoss 5 kernel.  New Embedded JBoss will be full featured.  Most features of regular jboss should be available in embedded.
  | 
  | If you want to testdrive, checkout head SVN.  its in the jboss-head/embedded directory.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005051#4005051

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005051


From do-not-reply at jboss.com  Mon Jan 22 20:03:28 2007
From: do-not-reply at jboss.com (akrishmohan)
Date: Mon, 22 Jan 2007 20:03:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Remoting,
	Unified Invokers] - Atomic Operations
Message-ID: <20660193.1169514208644.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi I have a scenario in which I need to treat DB commit of 2 rows as one atomic operation. How do I achieve this using CMT?

Any tips would be useful.

Basically I have something like this.

public class TestMDBean implements MessageListener {

@PersistenceContext
private EntityManagerFactory emf;

@UserTransaction utx;
private UserTransaction utx;

private void updateLog() {
//populate a pojo entity here in a collection. The collection has 2 objects corresponding to the two rows in the table. Roll back if a single commit fails.

}

I am not sure what kind of transaction strategy I need to use here.

Let me know
Cheers
K

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005072#4005072

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005072


From do-not-reply at jboss.com  Mon Jan 22 20:19:44 2007
From: do-not-reply at jboss.com (dustismo)
Date: Mon, 22 Jan 2007 20:19:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Serialization] - Re: Debug
	support for Serialization
Message-ID: <19323874.1169515184710.JavaMail.jboss@colo-br-02.atl.jboss.com>

Has anyone found a solution to this problem?  I am getting the same exceptions and haven't found a solution.  Every class in my app is serializable and has a default constructor. 

using jboss 4.0.5.GA and seam 1.1.1

thanks
Dustin

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005079#4005079

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005079


From do-not-reply at jboss.com  Tue Jan 23 04:10:26 2007
From: do-not-reply at jboss.com (civimagr)
Date: Tue, 23 Jan 2007 04:10:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss/Tomcat Integration] - Re: Where
	can I find a list of what OS tomcat works whit?
Message-ID: <15060631.1169543426914.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm interested too. Have you get it something?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005215#4005215

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005215


From do-not-reply at jboss.com  Tue Jan 23 04:51:10 2007
From: do-not-reply at jboss.com (jfrederic.clere@jboss.com)
Date: Tue, 23 Jan 2007 04:51:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss/Tomcat Integration] - Re: Where
	can I find a list of what OS tomcat works whit?
Message-ID: <6493153.1169545870460.JavaMail.jboss@colo-br-02.atl.jboss.com>

Tomcat uses JAVA so it needs a JVM and it runs on any OS that has a decent JVM.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005221#4005221

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005221


From do-not-reply at jboss.com  Tue Jan 23 04:51:52 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 23 Jan 2007 04:51:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	serializable KernelDeployment
Message-ID: <30830330.1169545912689.JavaMail.jboss@colo-br-02.atl.jboss.com>

The property replacement during the parsing is coming from JBossXB.

This is redundant since the microcontainer does do property replacement during
the setter, see ValueConvertor.convertValue() invoked indirectly from the
StringValueMetaData.

To turn off the JBossXB processing we need to change the schema bindings:
e.g. in BeanSchemaBinding20

   public static void init(SchemaBinding schemaBinding)
   {
+      schemaBinding.setReplacePropertyRefs(false);
      initDeployment(schemaBinding);
      initBean(schemaBinding);
      initBeanFactory(schemaBinding);
      initArtifacts(schemaBinding);
   }


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005222#4005222

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005222


From do-not-reply at jboss.com  Tue Jan 23 04:55:40 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 23 Jan 2007 04:55:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	serializable KernelDeployment
Message-ID: <19365264.1169546140545.JavaMail.jboss@colo-br-02.atl.jboss.com>

Jira issue for property replacement:
http://jira.jboss.com/jira/browse/JBMICROCONT-143

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005224#4005224

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005224


From do-not-reply at jboss.com  Tue Jan 23 05:12:57 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 23 Jan 2007 05:12:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Case
	sensitivity in injecting a bean's property
Message-ID: <6706224.1169547177675.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, so first of all, we need a test for this in system-jmx.

The only test for cross injection just uses the object, it does not test
accessing a "property" of an MBean.

org.jboss.test.system.controller.integration.test.ConfigureMCFromJMXTestCase-mc.xml


  | <deployment xmlns="urn:jboss:bean-deployer:2.0">
  |    <bean name="Test" class="org.jboss.test.system.controller.integration.support.SimpleBean">
  |       <property name="simple"><inject bean="jboss.test:type=test"/></property>
  |    </bean>
  | </deployment>
  | 

Previously, this just treated the MBean like a javabean
(i.e. the property name was port)
looking directly at the MBean object.

But now it has been changed to go through the JMX api
(so it needs to use the JMX attribute name Port).

Alternatively, we could do as Scott says and try both in ServiceControllerContext

  |    public Object get(String name) throws Throwable
  |    {
  |       try
  |       {
  |           return getMBeanServer().getAttribute(objectName, name);
  |       }
  |       catch (AttributeNotFoundException orignal)
  |       {
  |          try
  |          {
  |              name = switchToUpperOrLowerCase(name);
  |              return getMBeanServer().getAttribute(objectName, name);
  |          }
  |          catch (AttributeNotFoundException e)
  |          {
  |             throw original;
  |          }
  |       }
  |    }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005232#4005232

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005232


From do-not-reply at jboss.com  Tue Jan 23 05:30:55 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 23 Jan 2007 05:30:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <30064466.1169548255031.JavaMail.jboss@colo-br-02.atl.jboss.com>

This seems to be getting very confused?

ATTACHMENTS

The original design was the following:

You have two types of attachment:
1) Transient - these are created by the parsing deployers from the raw xml
inside the deployments
2) Predetermined - these are what the profile service (or some other invoker of the
deployers) passes in to override what is in the deployment.

The Predetermined attachments are a sort of alt-dd but done programmatically.

I can see an argument for having a third type of attachment which is internal state
related to the deployment but it is stuff that we don't want the profile service/management
layer to override. It will always be constructed at runtime.

However, this can also be trivially dealt with by the ManagedObjectBuilder
NOT creating a ManagedObject for that attachment type.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005239#4005239

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005239


From do-not-reply at jboss.com  Tue Jan 23 05:36:26 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 23 Jan 2007 05:36:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <20904388.1169548586270.JavaMail.jboss@colo-br-02.atl.jboss.com>

DEPLOYMENT PROTOCOL

This is something that is not a part of the original prototype but it is a part of the
original design.

The basic idea is that the deployers can be run in two modes.
1) Runtime - this is what is implemented, it is the full deployment
2) Profile Service - in this case, the "real deployers" create contexts that have
stubbed out actions for the MC and JMX layers.

That is when it runs in Profile Service mode, it still goes through the full
deployment process, creates all the contexts and tries to resolve dependencies,
but it doesn't create any objects or invoke any setters or lifecycle methods.

NOTE: This is only for the deployments. It does need to do the full work
for the deployers and classloaders otherwise they wouldn't be able to do anything. :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005241#4005241

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005241


From do-not-reply at jboss.com  Tue Jan 23 05:41:03 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 23 Jan 2007 05:41:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <19442811.1169548863426.JavaMail.jboss@colo-br-02.atl.jboss.com>

RUNTIME MODE AND PREDETERMINED ATTACHMENTS

The parsing deployers are still invoked for these.
But they should be written in such a way that if there is a predetermined
attachment they don't do the parsing.

They still might do other work after the parse!

There are complications like the XSL deployer which needs to be changed
so you can pass in some form of DOM representation as the predetermined
attachment and still do the XSL transform on it, but this is an exceptional case
caused by badly written deployers that don't have a proper metadata model.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005242#4005242

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005242


From do-not-reply at jboss.com  Tue Jan 23 05:43:23 2007
From: do-not-reply at jboss.com (alesj)
Date: Tue, 23 Jan 2007 05:43:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	serializable KernelDeployment
Message-ID: <11681665.1169549003093.JavaMail.jboss@colo-br-02.atl.jboss.com>

serialize method in AbstractTestCase class only takes Serializable as parameter.
So if our returned MetaData is non-Serializable, we should throw exception (since we want all our MD to be serializable, right?)?

ps: this thread was hijacked with property replacement :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005243#4005243

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005243


From do-not-reply at jboss.com  Tue Jan 23 05:44:44 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 23 Jan 2007 05:44:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <29244899.1169549084728.JavaMail.jboss@colo-br-02.atl.jboss.com>

COMPONENTS

This is very much a prototype. When I wrote this it was just to get something
working and express the idea. Like I said before, this needs revisiting and
doing properly.

But what I will say is that components are an implementation detail.
The profile service should not be interested in the components directly,
it is not going to touch their attachments.

The components that get constructed from a particular metadata model
can change from release to release.

The only part the profile service needs to know about these is the
context names. i.e. what are the MBean/POJO names
so it can map missing dependencies back to the original deployment
that caused them.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005244#4005244

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005244


From do-not-reply at jboss.com  Tue Jan 23 05:47:20 2007
From: do-not-reply at jboss.com (radzish)
Date: Tue, 23 Jan 2007 05:47:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: LayouStrategy and
	StrategyResponse API
Message-ID: <1067978.1169549240550.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi Julien!

Yesterday I evaluated your first version of solution and it worked for me! :) Thank you very much for that. Today I will try annother way you posted, but it will take more time for me because since now I have to build my jboss portal from sources (previous example was just compiled to jar and put to jboss portal's lib). Anyway, I believe it will work.

So, once more, thank you very much. I really appreciate your help!
This is the best support I have ever had!

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005246#4005246

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005246


From do-not-reply at jboss.com  Tue Jan 23 06:13:50 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 23 Jan 2007 06:13:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	serializable KernelDeployment
Message-ID: <23414895.1169550830060.JavaMail.jboss@colo-br-02.atl.jboss.com>

"alesj" wrote : 
  | So if our returned MetaData is non-Serializable, we should throw exception (since we want all our MD to be serializable, right?)?
  | 

Correct.

This is a candidate for AbstractTestCase in the jboss-test project.


  |    /**
  |     * Check we have the expected type
  |     * 
  |     * @param <T> the expected type
  |     * @param o the object
  |     * @param expectedType the excepted class of the exception
  |     * @return the expected type
  |     */
  |    protected <T> T assertInstanceOf(Object o, Class<T> expectedType)
  |    {
  |       return assertInstanceOf(o, expectedType, true);
  |    }
  | 
  |    /**
  |     * Check we have the expected type
  |     * 
  |     * @param <T> the expected type
  |     * @param o the object
  |     * @param expectedType the excepted class of the exception
  |     * @param allowNull whether the object can be null
  |     * @return the expected type
  |     */
  |    protected <T> T assertInstanceOf(Object o, Class<T> expectedType, boolean allowNull)
  |    {
  |       if (expectedType == null)
  |          fail("Null expectedType");
  | 
  |       if (o == null && allowNull)
  |          return null;
  | 
  |       try
  |       {
  |          return expected.cast(o);
  |       }
  |       catch (ClassCastException e)
  |       {
  |          fail("Object " + o + " of class " + o.getClass().getName() + " is not an instanceof " + expectedType.getName());
  |       }
  |    }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005260#4005260

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005260


From do-not-reply at jboss.com  Tue Jan 23 07:33:20 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 23 Jan 2007 07:33:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re:
	@PortComponent replacement
Message-ID: <19915809.1169555600728.JavaMail.jboss@colo-br-02.atl.jboss.com>

"heiko.braun at jboss.com" wrote : While working on config issues i realized that  the PortComponentAnnotation needed refactoring. It's now split into @WebContext and @EndpointConfig. 
  | The main reason for this was the distinction between client and server side annotations. 
  | 

This change breaks the EJB3 testsuite


  | [ejort at warjort ejb3]$ ./build.sh -f build-test.xml 
  | Buildfile: build-test.xml
  | Overriding previous definition of reference to jboss.test.classpath
  | 
  | init:
  | 
  | compile-classes:
  |     [javac] Compiling 1124 source files to /home/ejort/jboss-head/ejb3/output/test-classes
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/regression/ejbthree440/model/MyResource.java:12: warning: unmappable character for encoding UTF8
  |     [javac]  * @author Ortwin Gl?
  |     [javac]                     ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/jaxws/EndpointEJB.java:36: package org.jboss.ws.annotation does not exist
  |     [javac] import org.jboss.ws.annotation.PortComponent;
  |     [javac]                                ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/jaxws/unit/ContextEJBTestCase.java:37: package org.jboss.ws.metadata.wsdl does not exist
  |     [javac] import org.jboss.ws.metadata.wsdl.WSDLDefinitions;
  |     [javac]                                   ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/jaxws/unit/ContextEJBTestCase.java:38: package org.jboss.ws.tools.wsdl does not exist
  |     [javac] import org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory;
  |     [javac]                                ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/webservices/jsr181/EJB3Bean.java:25: package org.jboss.ws.annotation does not exist
  |     [javac] import org.jboss.ws.annotation.PortComponent;
  |     [javac]                                ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/webservices/jsr181/EndpointInterface.java:24: package org.jboss.ws.annotation does not exist
  |     [javac] import org.jboss.ws.annotation.PortComponent;
  |     [javac]                                ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/webservices/unit/JSR181TestCase.java:37: package org.jboss.ws.metadata.wsdl does not exist
  |     [javac] import org.jboss.ws.metadata.wsdl.WSDLDefinitions;
  |     [javac]                                   ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/webservices/unit/JSR181TestCase.java:38: package org.jboss.ws.tools.wsdl does not exist
  |     [javac] import org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory;
  |     [javac]                                ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/jaxws/EndpointEJB.java:39: cannot find symbol
  |     [javac] symbol: class PortComponent
  |     [javac] @PortComponent(contextRoot = "/jaxws-context", urlPattern = "/*")
  |     [javac]  ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/webservices/jsr181/EJB3Bean.java:38: cannot find symbol
  |     [javac] symbol: class PortComponent
  |     [javac] @PortComponent(contextRoot="/jsr181", urlPattern="/*")
  |     [javac]  ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/dd/web/servlets/SubjectFilter.java:76: warning: [deprecation] getActiveSubject() in org.jboss.security.AuthenticationManager has been deprecated
  |     [javac]       Subject s0 = mgr.getActiveSubject();
  |     [javac]                       ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/jaxws/unit/ContextEJBTestCase.java:63: cannot find symbol
  |     [javac] symbol  : class WSDLDefinitionsFactory
  |     [javac] location: class org.jboss.ejb3.test.jaxws.unit.ContextEJBTestCase
  |     [javac]       WSDLDefinitionsFactory factory = WSDLDefinitionsFactory.newInstance();
  |     [javac]       ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/jaxws/unit/ContextEJBTestCase.java:63: cannot find symbol
  |     [javac] symbol  : variable WSDLDefinitionsFactory
  |     [javac] location: class org.jboss.ejb3.test.jaxws.unit.ContextEJBTestCase
  |     [javac]       WSDLDefinitionsFactory factory = WSDLDefinitionsFactory.newInstance();
  |     [javac]                                        ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/jaxws/unit/ContextEJBTestCase.java:64: cannot find symbol
  |     [javac] symbol  : class WSDLDefinitions
  |     [javac] location: class org.jboss.ejb3.test.jaxws.unit.ContextEJBTestCase
  |     [javac]       WSDLDefinitions wsdlDefinitions = factory.parse(wsdlURL);
  |     [javac]       ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/standalone/unit/StandardTestCase.java:167: warning: non-varargs call of varargs method with inexact argument type for last parameter;
  |     [javac] cast to java.lang.Object for a varargs call
  |     [javac] cast to java.lang.Object[] for a non-varargs call and to suppress this warning
  |     [javac]       Object testCase = constructor.newInstance(constructorParams);
  |     [javac]                                                 ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/standalone/unit/StandardTestCase.java:192: warning: non-varargs call of varargs method with inexact argument type for last parameter;
  |     [javac] cast to java.lang.Object for a varargs call
  |     [javac] cast to java.lang.Object[] for a non-varargs call and to suppress this warning
  |     [javac]       Object testCase = constructor.newInstance(constructorParams);
  |     [javac]                                                 ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/webservices/unit/JSR181TestCase.java:106: cannot find symbol
  |     [javac] symbol  : class WSDLDefinitionsFactory
  |     [javac] location: class org.jboss.ejb3.test.webservices.unit.JSR181TestCase
  |     [javac]       WSDLDefinitionsFactory factory = WSDLDefinitionsFactory.newInstance();
  |     [javac]       ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/webservices/unit/JSR181TestCase.java:106: cannot find symbol
  |     [javac] symbol  : variable WSDLDefinitionsFactory
  |     [javac] location: class org.jboss.ejb3.test.webservices.unit.JSR181TestCase
  |     [javac]       WSDLDefinitionsFactory factory = WSDLDefinitionsFactory.newInstance();
  |     [javac]                                        ^
  |     [javac] /home/ejort/jboss-head/ejb3/src/test/org/jboss/ejb3/test/webservices/unit/JSR181TestCase.java:107: cannot find symbol
  |     [javac] symbol  : class WSDLDefinitions
  |     [javac] location: class org.jboss.ejb3.test.webservices.unit.JSR181TestCase
  |     [javac]       WSDLDefinitions wsdlDefinitions = factory.parse(wsdlURL);
  |     [javac]       ^
  |     [javac] Note: Some input files use unchecked or unsafe operations.
  |     [javac] Note: Recompile with -Xlint:unchecked for details.
  |     [javac] 15 errors
  |     [javac] 4 warnings
  | 
  | BUILD FAILED
  | /home/ejort/jboss-head/ejb3/build-test.xml:347: Compile failed; see the compiler error output for details.
  | 

What is it with the webservices team that they can't resist refactoring code
and consequentially continually breaking the JBossAS build? :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005293#4005293

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005293


From do-not-reply at jboss.com  Tue Jan 23 07:37:56 2007
From: do-not-reply at jboss.com (alesj)
Date: Tue, 23 Jan 2007 07:37:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	serializable KernelDeployment
Message-ID: <6789931.1169555876344.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : "alesj" wrote : 
  |   | So if our returned MetaData is non-Serializable, we should throw exception (since we want all our MD to be serializable, right?)?
  |   | 
  | 
  | Correct.
  | 

Ok, for MetaData there is no problem.
What do we do with JavaBeans (which now fail - since with wildcard test's we use plain java.lang.Object)?

anonymous wrote : 
  | This is a candidate for AbstractTestCase in the jboss-test project.
  | 
  | 
  |   |    /**
  |   |     * Check we have the expected type
  |   |     * 
  |   |     * @param <T> the expected type
  |   |     * @param o the object
  |   |     * @param expectedType the excepted class of the exception
  |   |     * @return the expected type
  |   |     */
  |   |    protected <T> T assertInstanceOf(Object o, Class<T> expectedType)
  |   |    {
  |   |       return assertInstanceOf(o, expectedType, true);
  |   |    }
  |   | 
  |   |    /**
  |   |     * Check we have the expected type
  |   |     * 
  |   |     * @param <T> the expected type
  |   |     * @param o the object
  |   |     * @param expectedType the excepted class of the exception
  |   |     * @param allowNull whether the object can be null
  |   |     * @return the expected type
  |   |     */
  |   |    protected <T> T assertInstanceOf(Object o, Class<T> expectedType, boolean allowNull)
  |   |    {
  |   |       if (expectedType == null)
  |   |          fail("Null expectedType");
  |   | 
  |   |       if (o == null && allowNull)
  |   |          return null;
  |   | 
  |   |       try
  |   |       {
  |   |          return expectedType.cast(o);
  |   |       }
  |   |       catch (ClassCastException e)
  |   |       {
  |   |          fail("Object " + o + " of class " + o.getClass().getName() + " is not an instanceof " + expectedType.getName());
  |   |       }
  |   |    }
  |   | 

Cool.
I added this code to test project.
Will use it in MC once I update test snapshot.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005296#4005296

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005296


From do-not-reply at jboss.com  Tue Jan 23 07:43:48 2007
From: do-not-reply at jboss.com (ambika)
Date: Tue, 23 Jan 2007 07:43:48 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] -
	Failures/Errors while runing Testsuite on HPUX platform
Message-ID: <24939940.1169556228106.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi,
 Following testcases are failing when i run a testsuite on HPUX. ant tests is what i have run.

1) org.jboss.test.cmp2.commerce
2) org.jboss.test.cmp2.optimisticlock.test
3) org.jboss.test.cmp2.perf.test
4) org.jboss.test.cmp2.relationship
5) org.jboss.test.cmp2.simple
6) org.jboss.test.jmx.test
7) org.jboss.test.security.test
8) org.jboss.test.testbyvalue.test
9) org.jboss.test.util.test

Details are :
1) org.jboss.test.cmp2.commerce.CompleteUnitTestCase(JACC+SecurityMgr)
 2) org.jboss.test.cmp2.relationship.RelationshipUnitTestCase(JACC+SecurityMgr)
3) org.jboss.test.cmp2.simple.SimpleUnitTestCase(JACC+SecurityMgr)
4) org.jboss.test.cmp2.commerce.CompleteUnitTestCase(JACC+SecurityMgr)
 have same error message log.
Status : error
access denied (java.lang.RuntimePermission getClassLoader)

java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader)
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
	at java.security.AccessController.checkPermission(AccessController.java:401)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:528)
	at java.lang.Class.getClassLoader(Class.java:523)

5) org.jboss.test.cmp2.optimisticlock.test.OptimisticLockUnitTestCase

error checking if entity exists:java.sql.SQLException: Column not found: OIDCMP in statement [SELECT COUNT(*) FROM ENTITYA WHERE OIDCMP=?]

javax.ejb.CreateException: Error checking if entity exists:java.sql.SQLException: Column not found: OIDCMP in statement [SELECT COUNT(*) FROM ENTITYA WHERE OIDCMP=?]
	at org.jboss.ejb.plugins.cmp.jdbc.JDBCInsertPKCreateCommand.beforeInsert(JDBCInsertPKCreateCommand.java:105)
	at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractCreateCommand.execute(JDBCAbstractCreateCommand.java:150)
	at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.createEntity(JDBCStoreManager.java:587)
	at org.jboss.ejb.plugins.CMPPersistenceManager.createEntity(CMPPersistenceManager.java:237)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.createEntity(CachedConnectionInterceptor.java:225)
	at org.jboss.ejb.EntityContainer.createLocalHome(EntityContainer.java:625)



How to resolve these error?

Thanks and Regards,
Ambika



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005297#4005297

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005297


From do-not-reply at jboss.com  Tue Jan 23 07:43:52 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 23 Jan 2007 07:43:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	serializable KernelDeployment
Message-ID: <15936931.1169556232358.JavaMail.jboss@colo-br-02.atl.jboss.com>

"alesj" wrote : 
  | Ok, for MetaData there is no problem.
  | What do we do with JavaBeans (which now fail - since with wildcard test's we use plain java.lang.Object)?
  | 

Just change the test to use something like the following class:


  | package org.jboss.test.....;
  | 
  | import java.io.Serializable;
  | 
  | public class SerializableObject implements Serializable
  | {
  |    private static final long serialVersionUID = -1L;
  | }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005298#4005298

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005298


From do-not-reply at jboss.com  Tue Jan 23 07:59:29 2007
From: do-not-reply at jboss.com (ambika)
Date: Tue, 23 Jan 2007 07:59:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - How
	do i run a single test using in the testsuite?
Message-ID: <32739339.1169557169499.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi,
    I am trying to analyse the failures/errors while runing th testsuite. Can i run a single test from the testsuite. For me following test is failing. I am runing testsuite on hpux platform.

org.jboss.test.cmp2.commerce.CompleteUnitTestCase(JACC+SecurityMgr)


   Is it possible to run this test only? If yes, how that is possible? 

Thanks and Regards,
Ambika


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005302#4005302

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005302


From do-not-reply at jboss.com  Tue Jan 23 08:30:31 2007
From: do-not-reply at jboss.com (jaroslaw.kijanowski)
Date: Tue, 23 Jan 2007 08:30:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	How do i run a single test using in the testsuite?
Message-ID: <24910445.1169559031060.JavaMail.jboss@colo-br-02.atl.jboss.com>

start your AS:
./run.sh -c jacc-securitymgr -b localhost

run a single test:
./build.sh one-test -Dtest=org.jboss.test.cmp2.commerce.CompleteUnitTestCase

What are your AS and java versions?

Thanks,
 Jarek

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005304#4005304

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005304


From do-not-reply at jboss.com  Tue Jan 23 09:17:02 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Tue, 23 Jan 2007 09:17:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: EJBTHREE-615 still
	present in Embedded-ALPHA9
Message-ID: <25836114.1169561822183.JavaMail.jboss@colo-br-02.atl.jboss.com>

So how do I reproduce?  just use the existing ejb3 embedded security example?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005319#4005319

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005319


From do-not-reply at jboss.com  Tue Jan 23 09:19:36 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Tue, 23 Jan 2007 09:19:36 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	serializable KernelDeployment
Message-ID: <17054524.1169561976378.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : The property replacement during the parsing is coming from JBossXB.
  | 
  | This is redundant since the microcontainer does do property replacement during
  | the setter, see ValueConvertor.convertValue() invoked indirectly from the
  | StringValueMetaData.
  | 

Thats not the behavior I saw.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005320#4005320

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005320


From do-not-reply at jboss.com  Tue Jan 23 09:23:13 2007
From: do-not-reply at jboss.com (heiko.braun@jboss.com)
Date: Tue, 23 Jan 2007 09:23:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re:
	@PortComponent replacement
Message-ID: <17694701.1169562193318.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have removed all dependencies  on proprietary JBossWS API. AS modules should solely rely on JAX-RPC or JAX-WS API.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005322#4005322

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005322


From do-not-reply at jboss.com  Tue Jan 23 09:24:00 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Tue, 23 Jan 2007 09:24:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <29597906.1169562243198.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | But what I will say is that components are an implementation detail.
  | The profile service should not be interested in the components directly,
  | it is not going to touch their attachments. 
  | 

Don't know about this....I had an idea to be able to serialize an EJB Container so that redeployment is super fast.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005323#4005323

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005323


From do-not-reply at jboss.com  Tue Jan 23 09:37:15 2007
From: do-not-reply at jboss.com (alesj)
Date: Tue, 23 Jan 2007 09:37:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Property
	replacement
Message-ID: <20223642.1169563035030.JavaMail.jboss@colo-br-02.atl.jboss.com>

Just so that we don't totally hijack this thread:
 - http://www.jboss.com/index.html?module=bb&op=viewtopic&t=99508

I'm working on the issue.
Just in the testing phase (having some problems with permission to set System property).

I added this tests:
 - org.jboss.test.kernel.config.test.PropertyTestCase
 - org.jboss.test.kernel.config.test.PropertyXMLTestCase


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005331#4005331

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005331


From do-not-reply at jboss.com  Tue Jan 23 09:38:48 2007
From: do-not-reply at jboss.com (alesj)
Date: Tue, 23 Jan 2007 09:38:48 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	serializable KernelDeployment
Message-ID: <12688904.1169563128444.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bill.burke at jboss.com" wrote : "adrian at jboss.org" wrote : The property replacement during the parsing is coming from JBossXB.
  |   | 
  |   | This is redundant since the microcontainer does do property replacement during
  |   | the setter, see ValueConvertor.convertValue() invoked indirectly from the
  |   | StringValueMetaData.
  |   | 
  | 
  | Thats not the behavior I saw.
  | 
  | 

Let's move this property replacement discussion here:
 - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005331#4005331

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005333#4005333

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005333


From do-not-reply at jboss.com  Tue Jan 23 10:06:38 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Tue, 23 Jan 2007 10:06:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - jboss-portlet dtd for
	2.6
Message-ID: <19898458.1169564798882.JavaMail.jboss@colo-br-02.atl.jboss.com>

I am working on redoing correctly the DTDs for our various deployment  descriptors.

For the jboss-portlet.xml there is the very useful header-content that I was able to comment, however although I understand its content I might not be the most qualified person to document it.


  | <!--
  | Specify content which should be included in the portal aggregated page when the portlet is present
  | on that page. This setting only applies when the portlet is used in the local mode.
  | -->
  | <!ELEMENT header-content (link|script|meta)*>
  | 
  | <!--
  | todo
  | -->
  | <!ELEMENT link>
  | 
  | <!--
  | todo
  | -->
  | <!ATTLIST link href title type media ref CDATA #IMPLIED>
  | 
  | <!--
  | todo
  | -->
  | <!ELEMENT script>
  | 
  | <!--
  | todo
  | -->
  | <!ATTLIST script src type CDATA #IMPLIED>
  | 
  | <!--
  | todo
  | -->
  | <!ELEMENT meta>
  | 
  | <!--
  | todo
  | -->
  | <!ATTLIST meta name content CDATA #REQUIRED>
  | 

If someone can provide useful comment with examples to put here it would be great.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005338#4005338

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005338


From do-not-reply at jboss.com  Tue Jan 23 10:25:26 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 23 Jan 2007 10:25:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <31722043.1169565926173.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bill.burke at jboss.com" wrote : anonymous wrote : 
  |   | But what I will say is that components are an implementation detail.
  |   | The profile service should not be interested in the components directly,
  |   | it is not going to touch their attachments. 
  |   | 
  | 
  | Don't know about this....I had an idea to be able to serialize an EJB Container so that redeployment is super fast.

That's not what I'm talking about.

I'm saying that the users should modify the -ds.xml,
they shouldn't be allowed to modifed the underlying MBean definitions
and expect the modified version to work across releases.

I don't have a problem with advanced features in the profile service
that cache the components (either metadata or resulting objects)
as long as the cache is flushed when a new version of JBoss is released
or some significant global config changes.

In fact, it would be a useful debugging feature in the admin console
to be able to click on an "Advanced" button and see the underlying
MC/JMX configurations generated.

But, I'd imagine the feature you are talking about is incredibly difficult to
implement anyway.

The basics are pretty simple, you could replace the "InstantiateAction"
in the MC/JMX with a "DeserializeAction" but then it has still got to go through
configure/create/start to get up-to-date references and do things
like binding its entry point into jndi.

"No man is and island" and references to things like the 
TransactionManager singleton cannot be serialized, they must be
reinjected.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005341#4005341

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005341


From do-not-reply at jboss.com  Tue Jan 23 10:39:25 2007
From: do-not-reply at jboss.com (alesj)
Date: Tue, 23 Jan 2007 10:39:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Property replacement
Message-ID: <30471835.1169566765908.JavaMail.jboss@colo-br-02.atl.jboss.com>

How do I get pass this:

  | access denied (java.util.PropertyPermission test.property.value write)
  | java.security.AccessControlException: access denied (java.util.PropertyPermission test.property.value write)
  | 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
  | 	at java.security.AccessController.checkPermission(AccessController.java:427)
  | 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
  | 	at java.lang.System.setProperty(System.java:699)
  | 	at org.jboss.test.kernel.config.test.PropertyTestCase$1.run(PropertyTestCase.java:64)
  | 	at java.security.AccessController.doPrivileged(Native Method)
  | 	at org.jboss.test.kernel.config.test.PropertyTestCase.testPropertyWithPropertyValue(PropertyTestCase.java:60)
  | 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
  | 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
  | 	at junit.extensions.TestSetup.run(TestSetup.java:23)
  | 

My code:
   public void testPropertyWithPropertyValue() throws Throwable
  |    {
  |       // set property to be replaced
  |       final String CONST = "PropertyReplaceTestCase";
  | 
  |       AbstractTestDelegate delegate = getDelegate();
  |       delegate.enableSecurity = false;
  |       AccessController.doPrivileged(new PrivilegedAction<Object>()
  |       {
  |          public Object run()
  |          {
  |             System.setProperty("test.property.value", CONST);
  |             return null;
  |          }
  |       });
  |       
  |       // get property
  |       Object value = instantiateReplacePropertyValue();
  |       assertNotNull(value);
  |       assertEquals(String.class, value.getClass());
  |       assertEquals(CONST, value);
  |    }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005348#4005348

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005348


From do-not-reply at jboss.com  Tue Jan 23 10:46:12 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Tue, 23 Jan 2007 10:46:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <4536346.1169567172577.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : But, I'd imagine the feature you are talking about is incredibly difficult to
  | implement anyway.

Not hard, just a lot of work as refactorings of AOP would be required.

anonymous wrote : The basics are pretty simple, you could replace the "InstantiateAction"
  | in the MC/JMX with a "DeserializeAction" but then it has still got to go through
  | configure/create/start to get up-to-date references and do things
  | like binding its entry point into jndi. 

The EJB Deployer can do what it already does:  instantiate the container itself and install them manually into the kernel.  No need for special MC states.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005351#4005351

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005351


From do-not-reply at jboss.com  Tue Jan 23 10:52:58 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 23 Jan 2007 10:52:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <20529773.1169567578876.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bill.burke at jboss.com" wrote : 
  | The EJB Deployer can do what it already does:  instantiate the container itself and install them manually into the kernel.  No need for special MC states.

I'm talking about solving the problem generically rather 20 different
solutions (each with their own bugs) in 20 different services.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005354#4005354

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005354


From do-not-reply at jboss.com  Tue Jan 23 10:59:51 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 23 Jan 2007 10:59:51 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Property replacement
Message-ID: <11743976.1169567991235.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hard to tell without seeing the whole code.

I'd guess you have AbstractKernelTest somewhere in your hierarchy?

Which installs a SecurityManager:


  |    public static AbstractTestDelegate getDelegate(Class clazz) throws Exception
  |    {
  |       AbstractTestDelegate delegate = new AbstractTestDelegate(clazz);
  |       delegate.enableSecurity = true;
  |       return delegate;
  |    }
  | 

The tests get only very basic privilieges, the idea being that we want to make
sure the MC works properly in a restricted environment.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005359#4005359

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005359


From do-not-reply at jboss.com  Tue Jan 23 11:06:45 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 23 Jan 2007 11:06:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Property replacement
Message-ID: <4536121.1169568405936.JavaMail.jboss@colo-br-02.atl.jboss.com>

"alesj" wrote : 
  |       AbstractTestDelegate delegate = getDelegate();
  |       delegate.enableSecurity = false;
  | 

This won't work.
The flag is only considered during test setup

You could perhaps add a couple of methods to AbstractTestCaseWithSetup
that let you temporarily suspend the security manager.


  | protected SecurityManager suspendSecurity()
  | {
  |    SecurityManager result = System.getSecurityManager();
  |    System.setSecurityManager(null);
  |    return result;
  | }
  | 
  | protected void resumeSecurity(SecurityManager securityManager)
  | {
  |    System.setSecurityManager(securityManager);
  | }
  | 
  |   | 
  |   | You could then do:
  |   | 
  |   | 
  |   |   | SecurityManager sm = suspendSecurity();
  |   |   | try
  |   |   | {
  |   |   |    // Do priviledged stuff
  |   |   | }
  |   |   | finally
  |   |   | {
  |   |   |    resumeSecurity(sm);
  |   |   | }
  |   |   | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005362#4005362

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005362


From do-not-reply at jboss.com  Tue Jan 23 11:13:08 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 23 Jan 2007 11:13:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Property replacement
Message-ID: <11203803.1169568788719.JavaMail.jboss@colo-br-02.atl.jboss.com>

Sorry that would of course need to be :-)


  | protected SecurityManager suspendSecurity()
  | {
  |       return AccessController.doPrivileged(new PrivilegedAction<SecurityManager>
  |       {
  |          SecurityManager result = System.getSecurityManager();
  |          System.setSecurityManager(null);
  |          return result;
  |       });
  | }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005372#4005372

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005372


From do-not-reply at jboss.com  Tue Jan 23 11:14:05 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Tue, 23 Jan 2007 11:14:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] -
	Pointcut tests
Message-ID: <5704020.1169568845171.JavaMail.jboss@colo-br-02.atl.jboss.com>

I've added a test for testing pointcuts in org.jboss.test.aop.pointcut.PointcutTester. I've made no attempt to include everything that should work right now, but just something to keep in mind if you

a) Ever extend the pointcut language
b) Find yourself underworked ;-)

This would be a good place to start for any wannabe committers...

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005374#4005374

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005374


From do-not-reply at jboss.com  Tue Jan 23 11:16:49 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Tue, 23 Jan 2007 11:16:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <5191880.1169569009894.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : "bill.burke at jboss.com" wrote : 
  |   | The EJB Deployer can do what it already does:  instantiate the container itself and install them manually into the kernel.  No need for special MC states.
  | 
  | I'm talking about solving the problem generically rather 20 different
  | solutions (each with their own bugs) in 20 different services.

I'd rather have each with their own bugs rather than a buggy generic solution that I have to keep backward compatibility with.

At least with the EJB container, what  a non-generic solution would be doing anyways is pushing as much information and processing to metadata and the metadata phase of deployment.  For instance, much of the processing for EJB container is pointcut bindings.  Theres no reason this processing cant be pushed to metadata.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005377#4005377

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005377


From do-not-reply at jboss.com  Tue Jan 23 11:24:30 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 23 Jan 2007 11:24:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: JMS Example in 3.2
	Beta
Message-ID: <28289724.1169569470828.JavaMail.jboss@colo-br-02.atl.jboss.com>

"jeffdelong" wrote : 
  | 1) The JMSMessage Service is getting a ClassCastException when casting the lookup of java:/JmsXa to an XAConnectionFactory which should work and did work previously.
  | 

i don't recall this in the testing that i did.  have you got any clues that could help me reproduce ?

"jeffdelong" wrote : 
  | 2) The NewProcessInstance command needs to set the variablesMap contained with the command.

this is now added in cvs.   thanks !

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005379#4005379

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005379


From do-not-reply at jboss.com  Tue Jan 23 11:34:44 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 23 Jan 2007 11:34:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <10122122.1169570084475.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bill.burke at jboss.com" wrote : 
  | I'd rather have each with their own bugs rather than a buggy generic solution that I have to keep backward compatibility with.
  | 

Well if you not interested in providing a generic solution then
you shouldn't be discussing in the POJO Server forum. :-)

And good luck on trying to persuade Scott to use the 20 different implementations
of this feature from inside the profile service. :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005383#4005383

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005383


From do-not-reply at jboss.com  Tue Jan 23 14:11:12 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 23 Jan 2007 14:11:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - ManagementView refresh
Message-ID: <19118240.1169579472383.JavaMail.jboss@colo-br-02.atl.jboss.com>

As a status, I am reving the profile service ManagementView to better align with the jsr88 notions, expose the deployment structure, and support the component type notion Charles wanted.

The two main query by type methods of the ManagementView become:

  |    /**
  |     * Get the deployments of a type.
  |     * @param type - the deployment or module type.
  |     * @return the possibly empty set of deployment with the given type.
  |     * @throws Exception
  |     */
  |    public Set<ManagedDeployment> getDeploymentsForType(String type)
  |       throws Exception;
  | 
  |    /**
  |     * Get the components of a type. The 
  |     * @param type - the component type.
  |     * @return the possibly empty set of components with the given type.
  |     * @throws Exception
  |     */
  |    public Set<ManagedComponent> getComponentsForType(ComponentType type)
  |       throws Exception;
  | 

The associated ManagedDeployment, ManagedComponent and ComponentType are:

  | /**
  |  * A collection of ManagedComponent and structural information
  |  * about a deployment.
  |  * 
  |  * @author Scott.Stark at jboss.org
  |  * @version $Revision:$
  |  */
  | public interface ManagedDeployment
  | {
  |    public String getName();
  |    public DeploymentPhase getDeploymentPhase();
  |    /**
  |     * Get the deployment/module types.
  |     * @return deployment types
  |     */
  |    public Set<String> getType();
  |    public ManagedObject getManagedObject();
  |    /**
  |     * Get the ManagedComponents for the deployment module.
  |     * @return ManagedComponents for the deployment module.
  |     */
  |    public List<ManagedComponent> getComponents();
  |    /**
  |     * Get the nested deployment modules.
  |     * @return nested deployment modules.
  |     */
  |    public List<ManagedDeployment> getChildren();
  | 
  |    /**
  |     * Get the DeploymentTemplate names for components
  |     * that can be added to this deployment.
  |     * @return 
  |     */
  |    public Set<String> getComponentTemplateNames();
  |    public DeploymentTemplateInfo getTemplate(String name);
  |    /**
  |     * Add a component to this deployment
  |     * @param info
  |     * @return
  |     */
  |    public ManagedComponent addComponent(DeploymentTemplateInfo info);
  |    public void removeComponent(ManagedComponent mc);
  |    
  |    /**
  |     * Get the DeploymentTemplate names for deployments
  |     * that can be added to this deployment.
  |     * @return 
  |     */
  |    public Set<String> getDeploymentTemplateNames();
  |    /**
  |     * Add a deployment
  |     * @param info
  |     * @return
  |     */
  |    public ManagedDeployment addModule(DeploymentTemplateInfo info);
  | }
  | 
  | /**
  |  * A runtime component associated with a deployment.
  |  * 
  |  * @author Scott.Stark at jboss.org
  |  * @version $Revision:$
  |  */
  | public interface ManagedComponent
  | {
  |    /**
  |     * The component name, typically only unique within the ManagedDeployment
  |     * @return omponent name
  |     */
  |    public String getName();
  |    /**
  |     * The component classification as a type/subtype.
  |     * @return component type.
  |     */
  |    public ComponentType getType();
  |    /**
  |     * The component ManagedObject.
  |     * @return component ManagedObject.
  |     */
  |    public ManagedObject getManagedObject();
  |    /**
  |     * The deployment the component is associated with.
  |     * @return component deployment.
  |     */
  |    public ManagedDeployment getDeployment();
  | }
  | 
  | /**
  |  * A simple type/subtype key for a ManagedComponent. Example
  |  * type/subtypes include: DataSource/{XA,LocalTx,NoTX}, JMSDestination/{Queue,Topic},
  |  * EJB/{StatelessSession,StatefulSession,Entity,MDB}, MBean/{Standard,XMBean,Dynamic},
  |  * ...
  |  * 
  |  * @author Scott.Stark at jboss.org
  |  * @version $Revision:$
  |  */
  | public class ComponentType
  | {
  |    private String type;
  |    private String subtype;
  | 
  |    public String getType()
  |    {
  |       return type;
  |    }
  |    public void setType(String type)
  |    {
  |       this.type = type;
  |    }
  | 
  |    public String getSubtype()
  |    {
  |       return subtype;
  |    }
  |    public void setSubtype(String subtype)
  |    {
  |       this.subtype = subtype;
  |    }
  | }
  | 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005444#4005444

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005444


From do-not-reply at jboss.com  Tue Jan 23 14:46:32 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 23 Jan 2007 14:46:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <22554709.1169581592225.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : COMPONENTS
  | 
  | This is very much a prototype. When I wrote this it was just to get something
  | working and express the idea. Like I said before, this needs revisiting and
  | doing properly.
  | 
  | But what I will say is that components are an implementation detail.
  | The profile service should not be interested in the components directly,
  | it is not going to touch their attachments.
  | 
  | The components that get constructed from a particular metadata model
  | can change from release to release.
  | 
  | The only part the profile service needs to know about these is the
  | context names. i.e. what are the MBean/POJO names
  | so it can map missing dependencies back to the original deployment
  | that caused them.

There is a notion of components in the profile service since the management interface wants to be able to query by functional detail rather than structural. A service deployment has mbeans which have managed objects. How this maps back onto the DeploymentUnit attachments depends on the ModelObjectBuilder. I don't see why it could not map to a component DeploymentUnit if desired.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005458#4005458

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005458


From do-not-reply at jboss.com  Tue Jan 23 14:51:08 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 23 Jan 2007 14:51:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <5473016.1169581868169.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : This seems to be getting very confused?
  | 
  | ATTACHMENTS
  | 
  | The original design was the following:
  | 
  | You have two types of attachment:
  | 1) Transient - these are created by the parsing deployers from the raw xml
  | inside the deployments
  | 2) Predetermined - these are what the profile service (or some other invoker of the
  | deployers) passes in to override what is in the deployment.
  | 
  | The Predetermined attachments are a sort of alt-dd but done programmatically.
  | 
  | I can see an argument for having a third type of attachment which is internal state
  | related to the deployment but it is stuff that we don't want the profile service/management
  | layer to override. It will always be constructed at runtime.
  | 
  | However, this can also be trivially dealt with by the ManagedObjectBuilder
  | NOT creating a ManagedObject for that attachment type.

I don't see the confusion as, other than the new third form of attachment, this is how I have described the attachments usage is it not? The notion of the third attachment being classified separately was really only to control what attachments have some serialization requirement.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005460#4005460

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005460


From do-not-reply at jboss.com  Tue Jan 23 14:57:23 2007
From: do-not-reply at jboss.com (pgier)
Date: Tue, 23 Jan 2007 14:57:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Build System] - Creating a
	subversion trunks folder in JBoss Common
Message-ID: <1722921.1169582243919.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm not sure if this is the right forum for this, but I would like to create a trunks folder at the root of the JBoss commons project.  It would use svn externals properties to map to each of the subproject trunk folders.  This would allow us to keep separate the trunk/tags/branches separate for the subfolders, but also allow an easy checkout process.

Currently we have to check out each common subproject trunk folder separately.  If I create a folder called "trunks" here:
https://svn.jboss.org/repos/common/trunks

I can put one svn property that maps to the trunk folder of each of the subprojects.  So that all the subproject (common-core, common-logging-jdk, etc) trunk folders can be checked out at one time.

For more information about how this works you can look here:
http://svnbook.red-bean.com/en/1.1/ch07s04.html



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005462#4005462

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005462


From do-not-reply at jboss.com  Tue Jan 23 14:58:40 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 23 Jan 2007 14:58:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <13276545.1169582320921.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bill.burke at jboss.com" wrote : 
  | The EJB Deployer can do what it already does:  instantiate the container itself and install them manually into the kernel.  No need for special MC states.
Then your back to the old monolithic model of mixing describing how to do something with doing it. This will complicate interaction with generalized notions like admin ops affecting all transport interfaces, clustering behaviors, as well as resue of code across server versions.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005463#4005463

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005463


From do-not-reply at jboss.com  Tue Jan 23 15:04:27 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 23 Jan 2007 15:04:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <4466793.1169582667156.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : DEPLOYMENT PROTOCOL
  | 
  | This is something that is not a part of the original prototype but it is a part of the
  | original design.
  | 
  | The basic idea is that the deployers can be run in two modes.
  | 1) Runtime - this is what is implemented, it is the full deployment
  | 2) Profile Service - in this case, the "real deployers" create contexts that have
  | stubbed out actions for the MC and JMX layers.
  | 
  | That is when it runs in Profile Service mode, it still goes through the full
  | deployment process, creates all the contexts and tries to resolve dependencies,
  | but it doesn't create any objects or invoke any setters or lifecycle methods.
  | 
  | NOTE: This is only for the deployments. It does need to do the full work
  | for the deployers and classloaders otherwise they wouldn't be able to do anything. :-)
Then the real deployers simply need to select the approriate contexts based on a DeploymentMode(Runtime,Validation) type of attachment. This of course precludes non-real deployers from directly interacting with any kernels.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005468#4005468

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005468


From do-not-reply at jboss.com  Tue Jan 23 15:15:12 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 23 Jan 2007 15:15:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	serializable KernelDeployment
Message-ID: <27309080.1169583312079.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : "alesj" wrote : 
  |   | Ok, for MetaData there is no problem.
  |   | What do we do with JavaBeans (which now fail - since with wildcard test's we use plain java.lang.Object)?
  |   | 
  | 
  | Just change the test to use something like the following class:
  | 
  | 
  |   | package org.jboss.test.....;
  |   | 
  |   | import java.io.Serializable;
  |   | 
  |   | public class SerializableObject implements Serializable
  |   | {
  |   |    private static final long serialVersionUID = -1L;
  |   | }
  |   | 

We do have the ability to serialize non-Serializable objects, and this notion should be coming in as an annotation/external metadata passed to the serialization layer rather than a tagging interface that has to be seen in the type system in my view. Exposing Serializable in the mc apis is too onerous a contract.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005471#4005471

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005471


From do-not-reply at jboss.com  Tue Jan 23 15:34:17 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 23 Jan 2007 15:34:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Case
	sensitivity in injecting a bean's property
Message-ID: <26765004.1169584457384.JavaMail.jboss@colo-br-02.atl.jboss.com>

A task to create the interaction tests
http://jira.jboss.com/jira/browse/JBAS-4009

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005475#4005475

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005475


From do-not-reply at jboss.com  Tue Jan 23 16:01:05 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 23 Jan 2007 16:01:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re:
	DataSource/ServiceXSLDeployer processing issue
Message-ID: <28239360.1169586065300.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : 
  | ...
  | There are complications like the XSL deployer which needs to be changed
  | so you can pass in some form of DOM representation as the predetermined
  | attachment and still do the XSL transform on it, but this is an exceptional case
  | caused by badly written deployers that don't have a proper metadata model.

This is a deficiency of the base JAXPDeployer though. If it supported a dom document attachment rather than always parsing a virtual file this would just work. I created the following feature request for that:
http://jira.jboss.com/jira/browse/JBMICROCONT-144

I would assume its easier to add this than update the datasource deployer.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005479#4005479

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005479


From do-not-reply at jboss.com  Tue Jan 23 16:04:12 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 23 Jan 2007 16:04:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Build System] - Re: Creating a
	subversion trunks folder in JBoss Common
Message-ID: <6083594.1169586252175.JavaMail.jboss@colo-br-02.atl.jboss.com>

The reason why it was not done this way originally was to allow for separate releases of these projects. I guess your just talking about simplifying the situation where you want to pull down all the projects together as a group. That sounds fine.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005481#4005481

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005481


From do-not-reply at jboss.com  Tue Jan 23 16:47:11 2007
From: do-not-reply at jboss.com (jazir1979)
Date: Tue, 23 Jan 2007 16:47:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: EJBTHREE-615 still
	present in Embedded-ALPHA9
Message-ID: <10487666.1169588831501.JavaMail.jboss@colo-br-02.atl.jboss.com>


Hi Bill,

I'll verify that for you ASAP and let you know.  So far I've only tried it in my own app, not those examples - and the exception that I get is slightly different from what the original poster had, although it does look to be related.

I'll let you know.

thanks,
Daniel.

"bill.burke at jboss.com" wrote : So how do I reproduce?  just use the existing ejb3 embedded security example?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005501#4005501

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005501


From do-not-reply at jboss.com  Tue Jan 23 17:22:26 2007
From: do-not-reply at jboss.com (pgier)
Date: Tue, 23 Jan 2007 17:22:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Build System] - Re: Creating a
	subversion trunks folder in JBoss Common
Message-ID: <6663642.1169590946305.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes, it's just for convenience.  You would still have a trunk folder for each subproject, and you can still do separate releases.  I'll just add an additional "trunks" folder that contains a link to each of the trunks.

I noticed that this is how the maven svn repository is setup, and it seemed like a nice idea.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005511#4005511

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005511


From do-not-reply at jboss.com  Tue Jan 23 19:02:58 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Tue, 23 Jan 2007 19:02:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: JMS Example in 3.2
	Beta
Message-ID: <8044113.1169596978677.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have a simple process that has an action. I configured the action with async="yes", and got a ClassCastException in the JMSMessageService when it casts to an XAConnnectionFactory the result of the lookup of Jms:/XA

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005542#4005542

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005542


From do-not-reply at jboss.com  Tue Jan 23 23:38:55 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Tue, 23 Jan 2007 23:38:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Navigation changes
	committed
Message-ID: <3626553.1169613535759.JavaMail.jboss@colo-br-02.atl.jboss.com>

Well, all the navigation changes have been committed.  Everything has been tested fairly rigorously, well at least with websale anyway, with the exception of the group task list that I still need to test a lot more.  Also I need to deploy some of my edge-case processes and see how they hold up.  Feel free to direct abuse to this thread.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005609#4005609

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005609


From do-not-reply at jboss.com  Wed Jan 24 01:14:00 2007
From: do-not-reply at jboss.com (ambika)
Date: Wed, 24 Jan 2007 01:14:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	How do i run a single test using in the testsuite?
Message-ID: <28591663.1169619240686.JavaMail.jboss@colo-br-02.atl.jboss.com>

hi jarek,

    Following are the versions.

1) Jboss AS : 4.0.5GA
2) Java 1.4
  
<< ./run.sh -c jacc-securitymgr -b localhost 
Its failed to run beacuse 
Failed to boot JBoss:
org.jboss.deployment.DeploymentException: url file:/opt/jboss-4.0.5.GA/server/jacc-securitymgr/conf/jboss-service.xml could not be opened, does it exist?
 -It doesnot exists , we need to copy that file from somewhere else?
 I am new to jboss, please can you help me regarding this error.


Thanks, 
Ambika

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005639#4005639

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005639


From do-not-reply at jboss.com  Wed Jan 24 02:11:55 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Wed, 24 Jan 2007 02:11:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Cache.removeRegion(Fqn)
Message-ID: <28433602.1169622715236.JavaMail.jboss@colo-br-02.atl.jboss.com>

We need to expose removeRegion(Fqn) in Cache. Right now you can create a region but there is no way to clean it up without doing 

((CacheSPI) cache).getRegionManager().removeRegion(Fqn);

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005663#4005663

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005663


From do-not-reply at jboss.com  Wed Jan 24 02:22:51 2007
From: do-not-reply at jboss.com (chengk)
Date: Wed, 24 Jan 2007 02:22:51 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: LDAP Connection
	handled by JBoss?
Message-ID: <2481173.1169623371036.JavaMail.jboss@colo-br-02.atl.jboss.com>

try to use hashtable. 

example: Hashtable env = ldapCtx.getEnvironment();

then retrieve the value from hashtable.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005670#4005670

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005670


From do-not-reply at jboss.com  Wed Jan 24 03:17:23 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Wed, 24 Jan 2007 03:17:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Navigation changes
	committed
Message-ID: <16641923.1169626643435.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'll try and get started with the 3.2 beta2 release this afternoon

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005690#4005690

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005690


From do-not-reply at jboss.com  Wed Jan 24 06:07:30 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Wed, 24 Jan 2007 06:07:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: JMS Example in 3.2
	Beta
Message-ID: <15583069.1169636850363.JavaMail.jboss@colo-br-02.atl.jboss.com>

i'll check that out this afternoon.  weird...  the tests should have been able to reproduce that question.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005740#4005740

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005740


From do-not-reply at jboss.com  Wed Jan 24 06:48:30 2007
From: do-not-reply at jboss.com (juha@jboss.org)
Date: Wed, 24 Jan 2007 06:48:30 -0500 (EST)
Subject: [jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re:
	Tracing what happens before EARDeployer starts
Message-ID: <4138722.1169639310154.JavaMail.jboss@colo-br-02.atl.jboss.com>

RuntimePermission.setIO

But I've never tried running AS with security manager enabled.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005749#4005749

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005749


From do-not-reply at jboss.com  Wed Jan 24 07:48:45 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Wed, 24 Jan 2007 07:48:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <19591284.1169642925120.JavaMail.jboss@colo-br-02.atl.jboss.com>

At this point I do not believe there is a release of GPD (even the alpha) that can upload process definitions via the upload servlet.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005763#4005763

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005763


From do-not-reply at jboss.com  Wed Jan 24 08:00:37 2007
From: do-not-reply at jboss.com (koen.aers@jboss.com)
Date: Wed, 24 Jan 2007 08:00:37 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <9327206.1169643637579.JavaMail.jboss@colo-br-02.atl.jboss.com>

I did not test this after David changed the commons-fileupload.jar... What is the error you are getting Jeff?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005771#4005771

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005771


From do-not-reply at jboss.com  Wed Jan 24 08:04:28 2007
From: do-not-reply at jboss.com (alesj)
Date: Wed, 24 Jan 2007 08:04:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Property replacement
Message-ID: <32949737.1169643868954.JavaMail.jboss@colo-br-02.atl.jboss.com>

I added this SecurityManager suspend / resume and things get pass that write permission problem.

But now I see that the ${x} string gets actually picked up by simple StringEditor, and not by 'replacing' Editor.

I added this code check (in ValueConvertor):

  | if (clazz.isAssignableFrom(valueClass) && isPropertyReplaceValue(value) == false)
  |          return value;
  | 

So that we even get to PropertyEditors.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005773#4005773

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005773


From do-not-reply at jboss.com  Wed Jan 24 08:42:32 2007
From: do-not-reply at jboss.com (alesj)
Date: Wed, 24 Jan 2007 08:42:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Property replacement
Message-ID: <10083434.1169646152965.JavaMail.jboss@colo-br-02.atl.jboss.com>

"alesj" wrote : 
  | But now I see that the ${x} string gets actually picked up by simple StringEditor, and not by 'replacing' Editor.

Ok, this is expected behaviour, since our targetType is String.

Should I change the StringEditor to look for replacement?
Or should I wrap the string value in some ReplecamentString class and add ReplecamentStringEditor into commons editors?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005790#4005790

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005790


From do-not-reply at jboss.com  Wed Jan 24 08:46:21 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 24 Jan 2007 08:46:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Failing
	tests
Message-ID: <4133966.1169646381281.JavaMail.jboss@colo-br-02.atl.jboss.com>

Some of the tests in the Microcontainer are failing because this change
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/common/common-core/trunk/src/main/java/org/jboss/util/xml/JBossEntityResolver.java?r1=2222&r2=2237
has not made into jboss-common-core.jar that is used by the MC build.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005792#4005792

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005792


From do-not-reply at jboss.com  Wed Jan 24 08:56:53 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 24 Jan 2007 08:56:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- JBoss TS - MQ recovery integration tests
Message-ID: <25410723.1169647013309.JavaMail.jboss@colo-br-02.atl.jboss.com>

Does anyone know if there are any integration tests that show JBoss TS recovery manager, interacting with JBoss MQ and performing recovery?

I know there are tests that exercise the XAResource api and call recover() etc manually, but I couldn't see any that actual use JBoss TS to do this.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005796#4005796

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005796


From do-not-reply at jboss.com  Wed Jan 24 09:13:46 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 24 Jan 2007 09:13:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Property replacement
Message-ID: <10220962.1169648026412.JavaMail.jboss@colo-br-02.atl.jboss.com>

None of the property editors should be doing system property replacement.

The best way to fix this and maintain backwards compatibility is the following
diff in ValueConvertor.

  | [ejort at warjort plugins]$ svn diff ValueConvertor.java 
  | Index: ValueConvertor.java
  | ===================================================================
  | --- ValueConvertor.java (revision 59913)
  | +++ ValueConvertor.java (working copy)
  | @@ -31,6 +31,7 @@
  |  import org.jboss.reflect.plugins.introspection.ReflectionUtils;
  |  import org.jboss.reflect.spi.ProgressionConvertor;
  |  import org.jboss.reflect.spi.ProgressionConvertorFactory;
  | +import org.jboss.util.StringPropertyReplacer;
  |  import org.jboss.util.propertyeditor.PropertyEditors;
  |  
  |  /**
  | @@ -69,15 +70,37 @@
  |      * @return the value or null if there is no editor
  |      * @throws Throwable for any error
  |      */
  | -   @SuppressWarnings("unchecked")
  |     public static Object convertValue(Class<? extends Object> clazz, Object value) throws Throwable
  |     {
  | +      return convertValue(clazz, value, false);
  | +   }
  | +
  | +   /**
  | +    * Convert a value
  | +    *
  | +    * @param clazz the class
  | +    * @param value the value
  | +    * @param replaceProperties whether to replace system properties
  | +    * @return the value or null if there is no editor
  | +    * @throws Throwable for any error
  | +    */
  | +   @SuppressWarnings("unchecked")
  | +   public static Object convertValue(Class<? extends Object> clazz, Object value, boolean replaceProperties) throws Throwable
  | +   {
  |        if (clazz == null)
  |           throw new IllegalArgumentException("Null class");
  |        if (value == null)
  |           return null;
  |  
  |        Class<? extends Object> valueClass = value.getClass();
  | +
  | +      // If we have a string replace any system properties when requested
  | +      if (replaceProperties && valueClass == String.class)
  | +      {
  | +         String string = (String) value;
  | +         value = StringPropertyReplacer.replaceProperties(string);
  | +      }
  | +
  |        if (clazz.isAssignableFrom(valueClass))
  |           return value;
  | 

Then add the following new method to TypeInfo
that invokes the alternative method in ValueConvertor


  |    /**
  |     * Convert a value
  |     * 
  |     * @param value the original value
  |     * @param replaceProperties whether to replace properties
  |     * @return the converted value
  |     * @throws Throwable for any error
  |     */
  |    Object convertValue(Object value, boolean replaceProperties) throws Throwable;
  | 

The StringValueMetaData should be invoking this new method.

Finally, it would be good if StringValueMetaData also had an additional
parameter to turn off string property replace (like the JMX stuff does)

e.g. (but also for other places that take a "value")


  | <!-- This property is not replaced -->
  | <property name="blah" replace="false">${hello}</property>
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005799#4005799

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005799


From do-not-reply at jboss.com  Wed Jan 24 09:30:28 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 24 Jan 2007 09:30:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JBoss TS - MQ recovery integration tests
Message-ID: <22832639.1169649028984.JavaMail.jboss@colo-br-02.atl.jboss.com>

No there are no tests for this in the testsuite since at the time I wrote
this JBossTM was integrated into the main build.

The tests in the testsuite deploy a second copy of JBossMQ into JBossAS
that I can reboot and test recovery using the XAResource api directly.
i.e. they are unit tests not integration tests.

The only test I have is in a private ant project that uses the
JMSProviderXAResourceRecovery
with the following change in jbossjta-properties.xml

  |         <property name="com.arjuna.ats.jta.recovery.XAResourceRecoveryJMS=org.jboss.jta.recovery.jms.JMSProviderXAResourceRecovery;DefaultJMSProvider"/>
  | 

It also includes a subclass of the persistence manager
so I can force the server to crash during commit

  | /*
  | * JBoss, Home of Professional Open Source
  | * Copyright 2006, JBoss Inc., and individual contributors as indicated
  | * by the @authors tag. See the copyright.txt in the distribution for a
  | * full listing of individual contributors.
  | *
  | * This is free software; you can redistribute it and/or modify it
  | * under the terms of the GNU Lesser General Public License as
  | * published by the Free Software Foundation; either version 2.1 of
  | * the License, or (at your option) any later version.
  | *
  | * This software is distributed in the hope that it will be useful,
  | * but WITHOUT ANY WARRANTY; without even the implied warranty of
  | * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
  | * Lesser General Public License for more details.
  | *
  | * You should have received a copy of the GNU Lesser General Public
  | * License along with this software; if not, write to the Free
  | * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
  | * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
  | */
  | package org.jboss.test.jbossmq;
  | 
  | import javax.jms.JMSException;
  | 
  | import org.jboss.mq.pm.Tx;
  | import org.jboss.mq.pm.jdbc2.PersistenceManager;
  | 
  | public class TestPersistenceManager extends PersistenceManager implements TestPersistenceManagerMBean
  | {
  |    private boolean crashInCommit = false;
  |    
  |    public TestPersistenceManager() throws JMSException
  |    {
  |    }
  |    
  |    public boolean getCrashInCommit()
  |    {
  |       return crashInCommit;
  |    }
  |    
  |    public void makeCrashInCommit(boolean crashInCommit)
  |    {
  |       this.crashInCommit = crashInCommit;
  |    }
  |    
  |    public void commitPersistentTx(Tx txId) throws JMSException
  |    {
  |       if (crashInCommit)
  |       {
  |          System.out.println("I'm going to crash in 20 seconds");
  |          try
  |          {
  |             Thread.sleep(20000);
  |          }
  |          catch (Exception ignored) {}
  |          Runtime.getRuntime().halt(0);
  |       }
  |       else
  |          super.commitPersistentTx(txId);
  |    }
  | }
  | 

The sleep is just to workaround the fact that hypersonic doesn't
persist data to its transaction log synchronously
It does it on a timer every 10 seconds. UGLY! :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005805#4005805

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005805


From do-not-reply at jboss.com  Wed Jan 24 09:54:08 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 24 Jan 2007 09:54:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] -
	Spring-int tests
Message-ID: <16344547.1169650448143.JavaMail.jboss@colo-br-02.atl.jboss.com>

Are the spring-int tests supposed to working?
There are currently 2 failures out of 4 tests.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005814#4005814

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005814


From do-not-reply at jboss.com  Wed Jan 24 10:12:28 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 24 Jan 2007 10:12:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <15761167.1169651548172.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm not sure why this would be; the regular upload (from a web browser) still seems to function.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005820#4005820

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005820


From do-not-reply at jboss.com  Wed Jan 24 10:21:38 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Wed, 24 Jan 2007 10:21:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re:
	Cache.removeRegion(Fqn)
Message-ID: <8383711.1169652098073.JavaMail.jboss@colo-br-02.atl.jboss.com>

Good point.  DOne.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005823#4005823

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005823


From do-not-reply at jboss.com  Wed Jan 24 10:59:33 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 24 Jan 2007 10:59:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - JAXBDeployer
Message-ID: <8999795.1169654374005.JavaMail.jboss@colo-br-02.atl.jboss.com>

I've added initial support for a JAXB parsing deployer.
This is currently in the deployers project.

However, I think this should really live in a seperate JAXB integration project
so we don't end up pulling our choice of implementation into the bootstrap classpath.

The same is probably true of the some of the other integrations?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005838#4005838

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005838


From do-not-reply at jboss.com  Wed Jan 24 11:04:32 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Wed, 24 Jan 2007 11:04:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <2976348.1169654672979.JavaMail.jboss@colo-br-02.atl.jboss.com>

Lovely. So, we like JAXB now? All I can remember is getting sh*@ from you two about how we didn't like it ;-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005844#4005844

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005844


From do-not-reply at jboss.com  Wed Jan 24 11:19:27 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 24 Jan 2007 11:19:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <32851232.1169655567431.JavaMail.jboss@colo-br-02.atl.jboss.com>

The original versions were crap, that is unless you never wanted to change
your schema/code.

And you also had to do a precompilation stage to generate your parser.

The latest version has resolved many of these issues, although there
are still a number of features missing, e.g. dynamic wildcard handling
like JBossXB can do.

e.g. the recent spring integration code lets you mix and match
JBoss MC and Spring xml in the same file:

  | <?xml version="1.0" encoding="UTF-8"?>
  | 
  | <deployment xmlns="urn:jboss:bean-deployer:2.0">
  | 
  |    <bean name="oldBean" class="org.jboss.test.spring.support.OldBean">
  |       <property name="testBean"><inject/></property>
  |    </bean>
  | 
  |    <bean xmlns="urn:jboss:spring-beans:2.0" id="testBean" class="org.jboss.test.spring.support.SimpleBean">
  |       <property name="mylist">
  |          <list value-type="java.lang.String">
  |             <value>onel</value>
  |             <value>twol</value>
  |             <value>threel</value>
  |          </list>
  |       </property>
  |    </bean>
  | 
  | </deployment>
  | 

I'd also need to do a lot more testing before I was convinced it actually works.

e.g. I recently filed a bug which shows Sun's impl doesn't inheritance properly.

I've been assigned a bug number, but it hasn't appeared on the website yet
- who knows when it will get fixed, hopefully not 4 years like the classloader
problems :-)

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6516905


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005861#4005861

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005861


From do-not-reply at jboss.com  Wed Jan 24 11:26:16 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Wed, 24 Jan 2007 11:26:16 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <20046667.1169655976331.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | The original versions were crap, that is unless you never wanted to change 
  | your schema/code. 
  | 

Quite right, but as I pointed out, JAXB 2.0 seemed to mitigate this

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=86414

and

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=95273

Since I was originally planning on using JAXB to do the *-dsx.xml binding (note, this is not *-ds.xml but an updated and more rigorous version with an associated XSD) can I assume that we are going to allow for JAXB in our new meta model implementation(s). Because, if so, I can officially delete all the JBossXB crap I had to do up until this point. This would seem to hold for the ejb3 stuff which was done using JBossXB as well...

You know..the code you hate ;-)





View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005866#4005866

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005866


From do-not-reply at jboss.com  Wed Jan 24 11:33:24 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 24 Jan 2007 11:33:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <10306631.1169656404515.JavaMail.jboss@colo-br-02.atl.jboss.com>

Incidently, if you want to use (I don't have a test for it yet :-)

You would do something like:


  | public class MyParser extends JAXBDeployer<SomeMetaData>
  | {
  |    public MyParser()
  |    {
  |       super(SomeMetaData.class);
  |    }
  | 
  |    public void deploy(DeploymentUnit unit) throws DeploymentException
  |    {
  |       createMetaData(unit, null, "-my-extension.xml");
  |    }
  | }
  | 

Which will create the SomeMetaData attachment ready for the real deployer to pick up.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005869#4005869

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005869


From do-not-reply at jboss.com  Wed Jan 24 11:35:10 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Wed, 24 Jan 2007 11:35:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <16569648.1169656510525.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hey, that's great...since I already wrote this about 2 months ago, I am glad that I can get around to actually using it!





View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005870#4005870

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005870


From do-not-reply at jboss.com  Wed Jan 24 11:35:15 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 24 Jan 2007 11:35:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <32855203.1169656515477.JavaMail.jboss@colo-br-02.atl.jboss.com>

"weston.price at jboss.com" wrote : can I assume that we are going to allow for JAXB in our new meta model implementation(s).

Go ahead - if it works for you.
You've got to maintain the code. ;-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005871#4005871

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005871


From do-not-reply at jboss.com  Wed Jan 24 11:41:36 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Wed, 24 Jan 2007 11:41:36 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <20354602.1169656896958.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : 
  | I'd also need to do a lot more testing before I was convinced it actually works.
  | 
  | e.g. I recently filed a bug which shows Sun's impl doesn't inheritance properly.
  | 
  | I've been assigned a bug number, but it hasn't appeared on the website yet
  | - who knows when it will get fixed, hopefully not 4 years like the classloader
  | problems :-)
  | 
  | http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6516905
  | 

It works great for me. What's the inheritence problem? 

Also, bugs for it are supposed to be opened here:
https://jaxb.dev.java.net/servlets/ProjectIssues

-Jason

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005880#4005880

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005880


From do-not-reply at jboss.com  Wed Jan 24 12:47:26 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Wed, 24 Jan 2007 12:47:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - JBossTS/JCA Recovery
	work for JBoss 4.2
Message-ID: <2129706.1169660846263.JavaMail.jboss@colo-br-02.atl.jboss.com>

Currently in the 4.2 branch the


  | org.jboss.resource.connectionmanager.xa.JcaXAResourceWrapper
  | 

has been provided for two reasons:

1) We needed a way to override the isSameRM method to address a well known WebSphereMQ bug where mutliple XAResouces could not be enlisted in the same transaction from the same RM. Basically this simply amounted to moving the isSameRM stuff that was originally done for Oracle to be more generic. 

2)Provide a serializable wrapper to support XA resource recovery using JBossTS. 

It was my plan to use this wrapper both on the inbound and outbound for JCA. From my understanding, this would enable JBossTS to reconsruct the XAResource and call recover as the XAResource (in this case the wrapper) would be written to the transaction log enabling JBossTS to do it's thing. 

I wanted to throw this out in the forum just be sure I am not missing anything and to solicit advice as to if this is the appropriate approach to take. The alternative approach would be to implement the 


  | com.arjuna.ats.jta.recovery.XAResourceRecovery
  | 

interface and do things in the same manner as the JMS recovery work.  

Thoughts?



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005906#4005906

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005906


From do-not-reply at jboss.com  Wed Jan 24 12:53:46 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 24 Jan 2007 12:53:46 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <30802677.1169661226475.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm probably misunderstanding what you're doing here, but for JMS the recovery manager interfaces with the jms provider via an XAResourceRecovery instance - i.e. there's no JCA involved.

Are you suggesting that all XA recovery is driven via the JCA adapter?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005914#4005914

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005914


From do-not-reply at jboss.com  Wed Jan 24 13:04:49 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Wed, 24 Jan 2007 13:04:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <27368089.1169661889638.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | I'm probably misunderstanding what you're doing here, but for JMS the recovery manager interfaces with the jms provider via an XAResourceRecovery instance - i.e. there's no JCA involved. 
  | 

For JCA inflow, it has to be through JCA as I am the one initiating the transaction calling XASession.getXAResource() so I am not sure how your recovery stuff would come into play. Also, for outbound connections (ie JDBC) this has to be done to properly register recoverables with JBossTS. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005927#4005927

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005927


From do-not-reply at jboss.com  Wed Jan 24 13:35:28 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 24 Jan 2007 13:35:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Failing tests
Message-ID: <15877728.1169663729005.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'll fix this.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005940#4005940

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005940


From do-not-reply at jboss.com  Wed Jan 24 13:40:04 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Wed, 24 Jan 2007 13:40:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <9859633.1169664004736.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 2)Provide a serializable wrapper to support XA resource recovery using JBossTS.
  | 
  | It was my plan to use this wrapper both on the inbound and outbound for JCA. From my understanding, this would enable JBossTS to reconsruct the XAResource and call recover as the XAResource (in this case the wrapper) would be written to the transaction log enabling JBossTS to do it's thing.
  | 

One issue with this is that the user that executed the original transaction may not have permission to perform a recovery.  For instance, only a DBA may have the permission to perform recovery on the database.  Also, because the XA spec is a bit ambiguous,  different XAResources of different vendors may have different requirements on what flags you pass into XAResource.recover().  There's also the general problem that some XAResources require Xid padding and others don't.  I'm guessing that JBoss TS solves the latter two problems in very very hacky ways that are easy to break as there is no defined integration contract between JBoss, JBoss JCA, and Arjuna.  I do not know how or if they solve the permission problem.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005943#4005943

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005943


From do-not-reply at jboss.com  Wed Jan 24 13:51:57 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 24 Jan 2007 13:51:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <19341483.1169664717775.JavaMail.jboss@colo-br-02.atl.jboss.com>

"weston.price at jboss.com" wrote : 
  | For JCA inflow, it has to be through JCA as I am the one initiating the transaction calling XASession.getXAResource() so I am not sure how your recovery stuff would come into play. Also, for outbound connections (ie JDBC) this has to be done to properly register recoverables with JBossTS. 

Why does it matter who initiated the tx?

For recovery with JBoss TS, as long as you have provided an XAResourceRecovery instance, the recovery manager will call upon that to get an XAresource then call recover() on that to get the list of xids from the resource manager. (You can also make the XAresource serializable but that is another story)

The recovery manager will then call commit or rollback on them as it deems appropriate.

I don't see what relevance it has who started the transaction.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005948#4005948

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005948


From do-not-reply at jboss.com  Wed Jan 24 13:53:59 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Wed, 24 Jan 2007 13:53:59 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <7630471.1169664839084.JavaMail.jboss@colo-br-02.atl.jboss.com>

Sorry, I should have been more clear. You are outlining the case for JBM. The JMS/JCA adapter had to account for multiple foreign providers, not just JBM. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005951#4005951

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005951


From do-not-reply at jboss.com  Wed Jan 24 13:59:06 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 24 Jan 2007 13:59:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <19330080.1169665146918.JavaMail.jboss@colo-br-02.atl.jboss.com>

"weston.price at jboss.com" wrote : You are outlining the case for JBM. The JMS/JCA adapter had to account for multiple foreign providers, not just JBM. 

Not really. JBoss TS recovery works that way for any XAResource - whether it's from JBM, a database, or whatever.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005952#4005952

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005952


From do-not-reply at jboss.com  Wed Jan 24 14:04:20 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 24 Jan 2007 14:04:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <15670857.1169665460599.JavaMail.jboss@colo-br-02.atl.jboss.com>

Also, not everyone that wants recovery will be using JCA.

I guess I'm still missing something, but I don't really see why recovery is being viewed as the responsibility of JCA. They seem orthogonal to me.

Have I totally misunderstood this thread? :)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005959#4005959

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005959


From do-not-reply at jboss.com  Wed Jan 24 14:07:35 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Wed, 24 Jan 2007 14:07:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <19593913.1169665655730.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | Not really. JBoss TS recovery works that way for any XAResource - whether it's from JBM, a database, or whatever.
  | 

Huh? The underlying XAResource either has to be serializable, or the the XAResourceRecovery interface has to be implemented to support recovery via JBossTS. 

Can we agree on that ;-)





View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005961#4005961

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005961


From do-not-reply at jboss.com  Wed Jan 24 14:11:13 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Wed, 24 Jan 2007 14:11:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <25612789.1169665873242.JavaMail.jboss@colo-br-02.atl.jboss.com>


I think we may be crossing wires ;-)

anonymous wrote : 
  | Also, not everyone that wants recovery will be using JCA. 
  | 

This is true, but in JCA land, to support recovery one approach (ie serializable XAResource or XAResourceRecovery implementaion) has to be done. Just as you had to do this for JBM, JCA needs to support this as well to integrate with JBossTS.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005962#4005962

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005962


From do-not-reply at jboss.com  Wed Jan 24 14:20:25 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 24 Jan 2007 14:20:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <21139939.1169666425206.JavaMail.jboss@colo-br-02.atl.jboss.com>

"weston.price at jboss.com" wrote : anonymous wrote : 
  |   | Not really. JBoss TS recovery works that way for any XAResource - whether it's from JBM, a database, or whatever.
  |   | 
  | 
  | Huh? The underlying XAResource either has to be serializable, or the the XAResourceRecovery interface has to be implemented to support recovery via JBossTS. 
  | 
  | Can we agree on that ;-)
  | 
  | 

I was just saying, that (for JBoss TS at least) you can write an XAResourceRecovery instance that will provide an XAResource on which the tx mgr can call recover(). This shouldn't be any different for any provider.

Whether the transaction was started by JCA or not (e.g. for inflow) should be of no consequence.

When the recovery manager calls recover() the resource manager is supposed to return a list of in doubt xids, whether they were started by JCA, some user application, or your great Aunt Doris.

I still don't see what any of this has got to do with JCA.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005966#4005966

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005966


From do-not-reply at jboss.com  Wed Jan 24 14:21:30 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 24 Jan 2007 14:21:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Failing tests
Message-ID: <13920388.1169666490359.JavaMail.jboss@colo-br-02.atl.jboss.com>

The common-core version has been updated to 2.0.4.Alpha3 to pickup this change. There still is one expected test failure in the kernel module I need to resolve:

InstantiateXMLTestCase.testValueInstantiateFromJavabean2

  | junit.framework.AssertionFailedError
  | 	at junit.framework.Assert.fail(Assert.java:47)
  | 	at junit.framework.Assert.assertTrue(Assert.java:20)
  | 	at junit.framework.Assert.assertTrue(Assert.java:27)
  | 	at org.jboss.test.kernel.config.test.InstantiateXMLTestCase.testValueInstantiateFromJavabean2(InstantiateXMLTestCase.java:57)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:585)
  | 	at junit.framework.TestCase.runTest(TestCase.java:154)
  | 	at junit.framework.TestCase.runBare(TestCase.java:127)
  | 	at junit.framework.TestResult$1.protect(TestResult.java:106)
  | 	at junit.framework.TestResult.runProtected(TestResult.java:124)
  | 	at junit.framework.TestResult.run(TestResult.java:109)
  | 	at junit.framework.TestCase.run(TestCase.java:118)
  | 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
  | 	at junit.framework.TestSuite.run(TestSuite.java:203)
  | 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
  | 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
  | 	at junit.framework.TestResult.runProtected(TestResult.java:124)
  | 	at junit.extensions.TestSetup.run(TestSetup.java:23)
  | 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
  | 	at junit.framework.TestSuite.run(TestSuite.java:203)
  | 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
  | 	at junit.framework.TestSuite.run(TestSuite.java:203)
  | 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
  | 	at junit.framework.TestSuite.run(TestSuite.java:203)
  | 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005967#4005967

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005967


From do-not-reply at jboss.com  Wed Jan 24 14:26:45 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 24 Jan 2007 14:26:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <24627422.1169666805861.JavaMail.jboss@colo-br-02.atl.jboss.com>

"weston.price at jboss.com" wrote : 
  | This is true, but in JCA land, to support recovery one approach (ie serializable XAResource or XAResourceRecovery implementaion) has to be done. Just as you had to do this for JBM, JCA needs to support this as well to integrate with JBossTS.

I disagree.

Let's take the example of JBM for a minute. We already have a recovery mechanism in place (we use an XAResourceRecovery instance).

Now whether the transaction was started via JCA or directly by the user is of no consequence.

The JBoss TS recovery manager will just get an xaresource from our XAResourceRecovery instance and return a list of xids, some of these may come from transactions initiated by JCA and others not. It doesn't matter.

In this scenario there is absolutely no need for JCA to do anything.

I think the same logic applies to any resource manager for which you can write an XAResourceRecovery.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005970#4005970

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005970


From do-not-reply at jboss.com  Wed Jan 24 14:51:58 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Wed, 24 Jan 2007 14:51:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <1829982.1169668318218.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | I disagree. 
  | 
  | Let's take the example of JBM for a minute. We already have a recovery mechanism in place (we use an XAResourceRecovery instance). 
  | 

That's fine. In this case, because you implemented XAResourceRecovery, you are able to integrate with JBossTS directly. This is the situation you control...all fine well and good. 

Now, how about for XAResources you don't control? How about Oracle, DB2, WebSphereMQ, etc. What about those? 

How do you think these XAResource get enlisted in a transaction to begin with and who provides access to them? Guess what, it's JCA. ResourceManagers (JMS, JDBC or otherwise) are managed in an EE environment via JCA. Because JCA is a generic framework for resource integration use of the underlying XAResource is governed by this framework.  There is no concept of a standalone ResourceManager in an EE environment without an associated JCA resource adapter...well, other than in the case where the person is just blatantly attempting to do something wrong, Aunt Doris or otherwise.

For your fundamental disagreement to hold water, you would effectively have to remove JCA from the equation all together and assume that the Tx Manager has direct access the underlying XAResources/ResourceManagers *without* JCA intervention. This is simply not the case and will never be the case in our Application server, or any compliant EE application server for that matter. 





View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005980#4005980

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005980


From do-not-reply at jboss.com  Wed Jan 24 14:57:23 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Wed, 24 Jan 2007 14:57:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <2071861.1169668643200.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : 
  | The latest version has resolved many of these issues, although there
  | are still a number of features missing, e.g. dynamic wildcard handling
  | like JBossXB can do.
  | 
  | e.g. the recent spring integration code lets you mix and match
  | JBoss MC and Spring xml in the same file:
  | 
  |   | <?xml version="1.0" encoding="UTF-8"?>
  |   | 
  |   | <deployment xmlns="urn:jboss:bean-deployer:2.0">
  |   | 
  |   |    <!-- Microcontainer xml -->
  |   |    <bean name="oldBean" class="org.jboss.test.spring.support.OldBean">
  |   |       <property name="testBean"><inject/></property>
  |   |    </bean>
  |   | 
  |   |    <!-- Spring xml - via a wildcard binding -->
  |   |    <bean xmlns="urn:jboss:spring-beans:2.0" id="testBean" class="org.jboss.test.spring.support.SimpleBean">
  |   |       <property name="mylist">
  |   |          <list value-type="java.lang.String">
  |   |             <value>onel</value>
  |   |             <value>twol</value>
  |   |             <value>threel</value>
  |   |          </list>
  |   |       </property>
  |   |    </bean>
  |   | 
  |   | </deployment>
  |   | 
  | 
This is possible in JAXB, if you have the following in your root type: 

  |   // Array of Element or JAXB elements.
  |  @XmlAnyElement(lax="true")
  |  public Object[] others;
  | 

JAXB dynamically resolves type information off of annotations. So before unmarshalling, if you pass the JAXBContext a FooType.class. and FooType has an @XmlElementRoot, and the unmarshalled value matches that declaration, then "others" would contain an instance of FooType. Unknown elements would present a DOM Element.

-Jason

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005984#4005984

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005984


From do-not-reply at jboss.com  Wed Jan 24 14:58:34 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Wed, 24 Jan 2007 14:58:34 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <31832843.1169668714842.JavaMail.jboss@colo-br-02.atl.jboss.com>

Put another way ;-)

Take the case of say an RDBMS system..let's take our friend Oracle for an example. Oracle is deployed, managed, utilized in JBossAS via our JCA JDBC Resource adapter. It is the adapter that manages resource enlistment/delistment of the underlying XAResource...in sum, JCA takes care of all the messy details of driving the underlying managed connection through the XA transaction lifecycle (and pooling, security etc). 

So, who implements the XAResourceRecovery interface in this case? In other words, how does the underlying Oracle XAResource participate in recovery assuming that the vendor doesn't provide the necessary mechanism to do so? 

 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005985#4005985

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005985


From do-not-reply at jboss.com  Wed Jan 24 16:32:35 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Wed, 24 Jan 2007 16:32:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <20284546.1169674355269.JavaMail.jboss@colo-br-02.atl.jboss.com>

Tim, if you do it your way, won't recovery not work for JBMessaging in other app servers?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006034#4006034

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006034


From do-not-reply at jboss.com  Wed Jan 24 16:38:14 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Wed, 24 Jan 2007 16:38:14 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <22068868.1169674694815.JavaMail.jboss@colo-br-02.atl.jboss.com>

Technically, in that scenaior the JCA/JMS adapter is supposed to provide the recovery mechanism via the 


  | XAResouce[] ResourceAdapter.getXAResources(ActivationSpec[]) 
  | 

method. 

This is still TODO on my list to implement for our JMS/JCA adapter

Ideally if an AppServer supports recovery it should call into this method after a crash and query the ResourceAdapter for the XAResource --> ActivationSpec (those specs that were deployed at the time fo the crash) mappings. From the XAResource they can obviously get the outstanding recovery work. 

I think the miscommunication is that Tim is thinking solely from the JMS, non EE perspective...at least that's what I can gather. 






View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006037#4006037

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006037


From do-not-reply at jboss.com  Wed Jan 24 16:49:10 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 24 Jan 2007 16:49:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <14712035.1169675350930.JavaMail.jboss@colo-br-02.atl.jboss.com>

I think you guys are thinking in purely JEE terms, in which case you are probably correct.

But what abou people who use JBoss as an all purpose service hosting container and aren't doing JEE - it would nice for them to be able to use recovery too.

For instance, JBM has a messaging bridge - which can run standalone in basically a stripped down version of JBoss. The bridge creates connections to other jms servers, and (depending on QoS required) consumes and send messages from one server to the other in a JTA transaction.

No JCA is used here, but we need recovery. So far we have done this by implementing our own XAResourceRecovery.

And you can imagine many more cases where people implement their own non JEE services which do stuff with XA not using JCA.

So, yes, I admit that from inside the JEE app server, all XA stuff should be done via JCA, but should we limit ourselves to that?

Why not abstract out the recovery stuff to another service which can be used by both JCA and anyone else?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006041#4006041

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006041


From do-not-reply at jboss.com  Wed Jan 24 17:17:59 2007
From: do-not-reply at jboss.com (alesj)
Date: Wed, 24 Jan 2007 17:17:59 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Spring-int tests
Message-ID: <1852534.1169677079706.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : Are the spring-int tests supposed to working?
  | There are currently 2 failures out of 4 tests.

Unfortunately no - I'm having some XB + schema issues that I don't know how to solve quickly - getting a CCE:
 - http://www.jboss.org/index.html?module=bb&op=viewtopic&t=96523&start=20

I'm bugging Alexey, but he is busy with CTS. :-)

It's on my todo list - fixing this problem and implementing most of the 'special' features via our AOP, etc.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006051#4006051

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006051


From do-not-reply at jboss.com  Wed Jan 24 17:24:06 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Wed, 24 Jan 2007 17:24:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JCA
	Recovery work for JBoss 4.2
Message-ID: <20043037.1169677446393.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | For instance, JBM has a messaging bridge - which can run standalone in basically a stripped down version of JBoss. The bridge creates connections to other jms servers, and (depending on QoS required) consumes and send messages from one server to the other in a JTA transaction. 
  | 

How stripped down? I would be interested to see how you got rid of JCA being that, without it, JBoss typically won't run (at least all those parts of the code requiring JDBC access). I am assuming that your JMS implementation is using a persistence store is it not? Are you managing your connections yourself, do you rely on JBoss to do this? If the latter..well...I hate to be the bearer of bad tidings... ;-)

anonymous wrote : 
  | So, yes, I admit that from inside the JEE app server, all XA stuff should be done via JCA, but should we limit ourselves to that?
  | 

On the 'Design of JCA on JBoss' forum we will. 
anonymous wrote : 
  | 
  | Why not abstract out the recovery stuff to another service which can be used by both JCA and anyone else?
  | 

Because this is what the SPI contract of JCA already provides to a ResourceAdapter, ResourceManager, Application Server and Transaction Manager. Again, this is in the context of JBoss 4.2 and what needs to be done to finish this work. Not JBoss5 or later. If you want, please feel free to start another thread to that end. 



 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006054#4006054

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006054


From do-not-reply at jboss.com  Wed Jan 24 18:41:47 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Wed, 24 Jan 2007 18:41:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <23362101.1169682107659.JavaMail.jboss@colo-br-02.atl.jboss.com>

Try uplaoding using the GPD 3.0.12.

The problem is GPD 3.0.12 does not use the latest version of commons-fileupload.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006083#4006083

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006083


From do-not-reply at jboss.com  Wed Jan 24 19:11:11 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 24 Jan 2007 19:11:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] -
	JBMICROCONT-145, ManagedPropertyImpl serialization changes
Message-ID: <23511335.1169683871127.JavaMail.jboss@colo-br-02.atl.jboss.com>

I ran into this NPE issue caused by the circular relationshp between a ManagedObject and ManagedProperty. In order to fix it the serialization format needs to change to not use the ObjectStreamField api. The reason is that a ManagedProperty must be deserialized sufficiently in terms of its identity before it tries to read its containing ManagedObject reference. The ObjectInputStream.readFields api does not allow one to read the fields in a particular order, so we will have to take control of the reading/writing of the fields. To support better evolution I'll add a version to the serial output as well.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006092#4006092

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006092


From do-not-reply at jboss.com  Thu Jan 25 03:41:24 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Thu, 25 Jan 2007 03:41:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: ManagementView
	refresh
Message-ID: <21727780.1169714484557.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have checked in the current api changes. To get the update scenario working and have persistence of the changes there needs to be better integration between the deployers and profile service to load the attachments with the correct class loader. There are a few implementation changes that need to be addressed to correct this and other deployment issues.

First, the ComponentType needs to integrated into the deployments and working with ManagedComponents validated. That is what I'm currently working on.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006243#4006243

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006243


From do-not-reply at jboss.com  Thu Jan 25 03:51:58 2007
From: do-not-reply at jboss.com (jazir1979)
Date: Thu, 25 Jan 2007 03:51:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: EJBTHREE-615 still
	present in Embedded-ALPHA9
Message-ID: <22316498.1169715118075.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi Bill,

We did some further testing today using the original CalculatorBean example provided with the old embedded EJB3 stuff.  

I found that the bug that was reported originally -- a NullPointerException when calling EJBContext.getCallerPrincipal() is definitely FIXED in the latest code from SVN.

However, the (similar) bug that I'm having still occurs.

You can reproduce it by modifying the add() method in CalculatorBean.java to call ctx.isCallerInRole("student")  (or "teacher", or anything..).  You will get an IllegalArgumentException in Util.getSubjectRoles(), because the Subject is null:

  |      [java] java.lang.IllegalArgumentException: Subject is null
  |     [java]     at org.jboss.security.Util.getSubjectRoles(Util.java:632)
  |     [java]     at
  | org.jboss.security.plugins.JBossAuthorizationManager.getCurrentRoles(JBossAu
  | thorizationManager.java:302)
  |     [java]     at
  | org.jboss.security.plugins.JBossAuthorizationManager.doesUserHaveRole(JBossA
  | uthorizationManager.java:126)
  |     [java]     at
  | org.jboss.security.plugins.JaasSecurityManager.doesUserHaveRole(JaasSecurity
  | Manager.java:401)
  |     [java]     at
  | org.jboss.ejb3.BaseSessionContext.isCallerInRole(BaseSessionContext.java:233
  | )
  |     [java]     at
  | com.synyati.spurwing.test.bean.CalculatorBean.add(CalculatorBean.java:51)
  | 

thanks for your help on this one,
Daniel.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006244#4006244

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006244


From do-not-reply at jboss.com  Thu Jan 25 10:44:38 2007
From: do-not-reply at jboss.com (charles.crouch@jboss.com)
Date: Thu, 25 Jan 2007 10:44:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: ManagementView
	refresh
Message-ID: <3182107.1169739878799.JavaMail.jboss@colo-br-02.atl.jboss.com>

Running ProfileServiceUnitTestCase from eclipse I just get two failures:

testUpdateDataSource()

org.jboss.profileservice.spi.NoSuchDeploymentException: name=testAddDataSource-dsf.xml, phase=null
  | 	at org.jboss.system.server.profileservice.repository.SerializableDeploymentRepository.getDeployment(SerializableDeploymentRepository.java:283)
  | 	at org.jboss.system.server.profile.repository.ProfileImpl.getDeployment(ProfileImpl.java:122)
  | 	at org.jboss.profileservice.management.ManagementViewImpl.getDeployment(ManagementViewImpl.java:205)
  | 

testRemoveDataSource()

  | org.jboss.profileservice.spi.NoSuchDeploymentException: Failed to find deployment for name: testAddDataSource-dsf.xml
  | 	at org.jboss.profileservice.management.ManagementViewImpl.getMatchingDeploymentName(ManagementViewImpl.java:175)
  | 	
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006398#4006398

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006398


From do-not-reply at jboss.com  Thu Jan 25 11:54:08 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Thu, 25 Jan 2007 11:54:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: Last minute 2.0 API
	suggestions
Message-ID: <28202087.1169744048436.JavaMail.jboss@colo-br-02.atl.jboss.com>

I've accepted your patch about returning booleans for remove()'s.

I'd rather leave out the suggestion re: a Version object for cache version, until a proper use case comes up.  Over-engineering, IMO.  :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006431#4006431

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006431


From do-not-reply at jboss.com  Thu Jan 25 14:21:26 2007
From: do-not-reply at jboss.com (sacramentojoe)
Date: Thu, 25 Jan 2007 14:21:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Error loading
	Web Services
Message-ID: <18626475.1169752886073.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have downloaded JBoss AS 4.0.5. I'm on JDK 1.5. I downloaded the jbossws-1.0.4.GA. I followed the install directions in the install.txt. 
I get the following error during startup. I'm new to J2EE and App Servers so I don't even know where to start.

Thank you in advance for your assistance.

--- MBeans waiting for other MBeans ---
ObjectName: jboss.beans:service=JBossBeanDeployment,name='jbossws.beans'
  State: FAILED
  Reason: org.jboss.deployment.DeploymentException: Cannot start AbstractKernelD
eployment at ed65e0{name=file:/C:/Program Files/jboss/server/default/deploy/jbossws
/jbossws.beans/META-INF/jboss-beans.xml installed=true beans=[AbstractBeanMetaDa
ta at 1bb9533{name=ServiceEndpointManager bean=org.jboss.ws.server.ServiceEndpointM
anager properties=[serviceEndpointInvokerMDB, serviceEndpointInvokerJSE, service
EndpointInvokerEJB3, alwaysModifySOAPAddress, serviceEndpointInvokerEJB21, webSe
rviceHost] constructor=null}, AbstractBeanMetaData at 406b09{name=ServiceEndpointDe
ployer bean=org.jboss.ws.deployment.ServiceEndpointDeployer properties=[serviceE
ndpointManager] constructor=null}, AbstractBeanMetaData at 1332b63{name=ServiceEndp
ointPublisher bean=org.jboss.ws.integration.jboss.JBossServiceEndpointPublisher
properties=[serviceEndpointServlet, serviceEndpointDeployer] constructor=null},
AbstractBeanMetaData at 657c7b{name=JMSMessageDispatcher bean=org.jboss.ws.integrat
ion.jboss.jms.JMSMessageDispatcher properties= constructor=null}, AbstractBeanMe
taData at cf7fda{name=SubscriptionManager bean=org.jboss.ws.eventing.mgmt.Subscript
ionManager properties=[defaultLeaseTimeMins, maxLeaseTimeMins] constructor=null}
, AbstractBeanMetaData at d2f5f1{name=ServerConfig bean=org.jboss.ws.integration.jb
oss.ServerConfigImpl properties= constructor=null}, AbstractBeanMetaData at 10c276{
name=KernelLocator bean=org.jboss.ws.server.KernelLocator properties= constructo
r=null}]}; - nested throwable: (java.lang.IllegalStateException: Incompletely de
ployed:

*** DEPLOYMENTS IN ERROR:
SubscriptionManager -> org.jboss.joinpoint.spi.JoinpointException: Property defa
ultLeaseTimeMins not found for AbstractBeanInfo at 12bbe6b{name=org.jboss.ws.eventi
ng.mgmt.SubscriptionManager classInfo= properties=[completedTaskCount, largestPo
olSize, activeCount, eventKeepAlive, class, maxPoolSize, maximumPoolSize, corePo
olSize] methods=[, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
 , , , , , , , , ] constructors=[] events=}
ServiceEndpointManager -> javax.management.InstanceAlreadyExistsException: jboss
.ws:service=ServiceEndpointManager already registered.
JMSMessageDispatcher -> java.lang.ClassNotFoundException: No ClassLoaders found
for: org.jboss.ws.integration.jboss.jms.JMSMessageDispatcher

*** DEPLOYMENTS MISSING DEPENDENCIES:
ServiceEndpointPublisher -> ServiceEndpointDeployer{Configured:Instantiated}
ServiceEndpointDeployer -> ServiceEndpointManager{Configured:**ERROR**}
)

--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.beans:service=JBossBeanDeployment,name='jbossws.beans'
  State: FAILED
  Reason: org.jboss.deployment.DeploymentException: Cannot start AbstractKernelD
eployment at ed65e0{name=file:/C:/Program Files/jboss/server/default/deploy/jbossws
/jbossws.beans/META-INF/jboss-beans.xml installed=true beans=[AbstractBeanMetaDa
ta at 1bb9533{name=ServiceEndpointManager bean=org.jboss.ws.server.ServiceEndpointM
anager properties=[serviceEndpointInvokerMDB, serviceEndpointInvokerJSE, service
EndpointInvokerEJB3, alwaysModifySOAPAddress, serviceEndpointInvokerEJB21, webSe
rviceHost] constructor=null}, AbstractBeanMetaData at 406b09{name=ServiceEndpointDe
ployer bean=org.jboss.ws.deployment.ServiceEndpointDeployer properties=[serviceE
ndpointManager] constructor=null}, AbstractBeanMetaData at 1332b63{name=ServiceEndp
ointPublisher bean=org.jboss.ws.integration.jboss.JBossServiceEndpointPublisher
properties=[serviceEndpointServlet, serviceEndpointDeployer] constructor=null},
AbstractBeanMetaData at 657c7b{name=JMSMessageDispatcher bean=org.jboss.ws.integrat
ion.jboss.jms.JMSMessageDispatcher properties= constructor=null}, AbstractBeanMe
taData at cf7fda{name=SubscriptionManager bean=org.jboss.ws.eventing.mgmt.Subscript
ionManager properties=[defaultLeaseTimeMins, maxLeaseTimeMins] constructor=null}
, AbstractBeanMetaData at d2f5f1{name=ServerConfig bean=org.jboss.ws.integration.jb
oss.ServerConfigImpl properties= constructor=null}, AbstractBeanMetaData at 10c276{
name=KernelLocator bean=org.jboss.ws.server.KernelLocator properties= constructo
r=null}]}; - nested throwable: (java.lang.IllegalStateException: Incompletely de
ployed:

*** DEPLOYMENTS IN ERROR:
SubscriptionManager -> org.jboss.joinpoint.spi.JoinpointException: Property defa
ultLeaseTimeMins not found for AbstractBeanInfo at 12bbe6b{name=org.jboss.ws.eventi
ng.mgmt.SubscriptionManager classInfo= properties=[completedTaskCount, largestPo
olSize, activeCount, eventKeepAlive, class, maxPoolSize, maximumPoolSize, corePo
olSize] methods=[, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
 , , , , , , , , ] constructors=[] events=}
ServiceEndpointManager -> javax.management.InstanceAlreadyExistsException: jboss
.ws:service=ServiceEndpointManager already registered.
JMSMessageDispatcher -> java.lang.ClassNotFoundException: No ClassLoaders found
for: org.jboss.ws.integration.jboss.jms.JMSMessageDispatcher

*** DEPLOYMENTS MISSING DEPENDENCIES:
ServiceEndpointPublisher -> ServiceEndpointDeployer{Configured:Instantiated}
ServiceEndpointDeployer -> ServiceEndpointManager{Configured:**ERROR**}
)


10:52:36,844 INFO  [Http11BaseProtocol] Starting Coyote HTTP/1.1 on http-0.0.0.0
-8080
10:52:36,969 INFO  [ChannelSocket] JK: ajp13 listening on /0.0.0.0:8009
10:52:36,985 INFO  [JkMain] Jk running ID=0 time=0/79  config=null
10:52:36,985 INFO  [Server] JBoss (MX MicroKernel) [4.0.5.GA (build: CVSTag=Bran
ch_4_0 date=200610162339)] Started in 34s:672ms
10:55:30,625 ERROR [[/jbossws]] StandardWrapper.Throwable
org.jboss.kernel.spi.registry.KernelRegistryEntryNotFoundException: Entry not fo
und with name: ServiceEndpointManager
        at org.jboss.kernel.plugins.registry.AbstractKernelRegistry.getEntry(Abs
tractKernelRegistry.java:99)



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006502#4006502

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006502


From do-not-reply at jboss.com  Thu Jan 25 14:23:09 2007
From: do-not-reply at jboss.com (sacramentojoe)
Date: Thu, 25 Jan 2007 14:23:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: Error
	loading Web Services
Message-ID: <29558036.1169752989582.JavaMail.jboss@colo-br-02.atl.jboss.com>

I should have stated I'm on Windows XP Pro.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006503#4006503

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006503


From do-not-reply at jboss.com  Thu Jan 25 14:45:34 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Thu, 25 Jan 2007 14:45:34 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] -
	XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2
Message-ID: <2817143.1169754334677.JavaMail.jboss@colo-br-02.atl.jboss.com>

In one of our unit tests


  | org.jboss.test.jca.test.XAExceptionUnitTestCase
  | 

we have two tests that simulate errors when a JCA resource is used in an EJB. One is a resource exception, the other a runtime exception. Both occur in the matchManagedConnections() method of of the TestManagedConnectionFactory. Being that an error/excpetion occurs, the underlying connection is destroyed prior to use; no problems here. Howerver, in one test the transaction is rolled back at the end of the in the finally block. Because the 


  | <track-by-transaction>
  | 

flag is set to false when JBossTS attempts any sort of activity on the underlying resource it fails because the resource has already been destroyed. JBossTM seemed to either mask this condition, or just ignore it all together whileJBossTS reports a failure which is causing an ERROR in the tests. From what I understand, it seems that the 


  | <track-by-transaction>
  | 

flag should really be true by default for XA connections(we already do this for local resources). I can't envision why this shouldn't be set as the default moving forward with the new transaction manager stuff. In fact, most JDBC based resources from the big RDBMS vendors (Oracle, DB2) and some of the open source guys (Postgres most notably but for other reasons) already require this. 








View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006507#4006507

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006507


From do-not-reply at jboss.com  Thu Jan 25 15:26:02 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Thu, 25 Jan 2007 15:26:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <22378340.1169756762372.JavaMail.jboss@colo-br-02.atl.jboss.com>

How can this be specified via schema level annotations?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006518#4006518

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006518


From do-not-reply at jboss.com  Thu Jan 25 15:30:34 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Thu, 25 Jan 2007 15:30:34 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re:
	XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2
Message-ID: <21612501.1169757034829.JavaMail.jboss@colo-br-02.atl.jboss.com>

A bit more.

What is actually happening is because the tests required to matchManagedConnections to fail, when the test originally runs, the pool is empty. A connection is successfully created and enlisted/delisted in the tranasction and returned to the pool. The second attempt to acquire the connection fails in the match and the connection is destroeyd. Howerve,r JBossTS rightfully 'remembers' this guy and when JBossTS attempts to finish the txn protocol the connection has already been destroyed. This is where the error occurs. So, effectively the <track-connection-by-txn> really should be here and in fact, I believe it's a bug that it's not. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006519#4006519

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006519


From do-not-reply at jboss.com  Thu Jan 25 17:43:03 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Thu, 25 Jan 2007 17:43:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <24301871.1169764983951.JavaMail.jboss@colo-br-02.atl.jboss.com>

"scott.stark at jboss.org" wrote : How can this be specified via schema level annotations?
  | 

It reads everything directly from the Java annotations. The schema bindings just control the Java annotations that are generated when xjc is ran on the schema. So in order to have a plugable schema extension mechanism, you would have to have a way to register annotationed JAXB objects with some kind of MC context, and that would then be used to generate the JAXBContext that is responsible for unmarshalling the deployment descriptor. 

So the big difference here is that unlike JBossXB, there is no way to override the java annotations with schema annotations. This loss of flexibility is for performance reasons (no need to read/parse the schema at runtime).

-Jason

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006579#4006579

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006579


From do-not-reply at jboss.com  Thu Jan 25 17:58:06 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Thu, 25 Jan 2007 17:58:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <25426178.1169765886250.JavaMail.jboss@colo-br-02.atl.jboss.com>

"jason.greene at jboss.com" wrote :  
  | So the big difference here is that unlike JBossXB, there is no way to override the java annotations with schema annotations. This loss of flexibility is for performance reasons (no need to read/parse the schema at runtime).
  | 

So this creates a problem if the object model needs to be fixed (public API etc), but the schema needs to change significantly. Or different schemas need to be associated with the same object model. Under these scenarios, it's better to use the JAXB object model as an intermediary that directly represents the xml (in object form), and then copy / merge this information into a more elegant public API.

-Jason

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006588#4006588

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006588


From do-not-reply at jboss.com  Thu Jan 25 18:05:51 2007
From: do-not-reply at jboss.com (prassib)
Date: Thu, 25 Jan 2007 18:05:51 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - what are the new
	features in JBPM 3.2?
Message-ID: <23781477.1169766351222.JavaMail.jboss@colo-br-02.atl.jboss.com>

Is there any documentation available?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006591#4006591

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006591


From do-not-reply at jboss.com  Thu Jan 25 18:43:21 2007
From: do-not-reply at jboss.com (zipwow)
Date: Thu, 25 Jan 2007 18:43:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Guidance for JBPM-725?
	Applies to 3.2?
Message-ID: <21705388.1169768601518.JavaMail.jboss@colo-br-02.atl.jboss.com>

I ran into the issue described in JBPM-725 in jbpm 3.1:

http://jira.jboss.com/jira/browse/JBPM-725
Set auto-import="false" for all hibernate-mapping elements in hibernate mapping files.

>From a cursory glance of the 3.1 code, it looks like all (or the majority) of the hibernate queries are already written with fully qualified names, so I'm willing to tackle this change.  Before I begin:

Would it make sense to do this against the 3.2 codebase instead?  
Are there any pitfalls I should be aware of?
Where should I look for the baseline of expected passing unit tests?  (I seem to get some failures out of the box for 3.1)

Thanks,

Kevin Klinemeier

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006603#4006603

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006603


From do-not-reply at jboss.com  Thu Jan 25 18:49:22 2007
From: do-not-reply at jboss.com (prassib)
Date: Thu, 25 Jan 2007 18:49:22 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - JBPM_LOG issue
Message-ID: <1192190.1169768962614.JavaMail.jboss@colo-br-02.atl.jboss.com>

I wrote a test program that runs against an in-memory database. I can successfully create a LoggingInstance by calling the method getLoggingInstance on the ProcessInstance. I can catch hold of the NodeLogs from the LoggingInstance & get the Node_Enter & Node_leave times.

when we run similar code inside my application against my production database(DB2), my NodeLogs List size is always 0. I checked the database, there are no records in the JBPM_LOG table. Other tables like JBPM_PROCESSINSTANCE, JBPM_TOKEN, JBPM_TRANSITION show all the appropriate records but the JBPM_LOG table is always empty.

Could anyone throw some light, why this could be happening?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006607#4006607

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006607


From do-not-reply at jboss.com  Thu Jan 25 19:48:50 2007
From: do-not-reply at jboss.com (jaroslaw.kijanowski)
Date: Thu, 25 Jan 2007 19:48:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] -
	testsuite's log4j configuration leads to large reports
Message-ID: <32133862.1169772530482.JavaMail.jboss@colo-br-02.atl.jboss.com>

Testsuite's log4j was configured to print DEBUG messages to system.out.
This leads to a large TESTS-TestSuites.xml file.

There are two targets in build.xml:
tests-report-xml
tests-report-text
The first one generates testsuite/output/reports/text/TESTS-TestSuites.txt
The second one testsuite/output/reports/xml/TESTS-TestSuites.xml
Both files are small summaries (see below).

Both targets uses a XSL Transformation to transform this huge TESTS-TestSuites.xml file. If this file is larger than 100MB, JAVA's embedded XSLT is unable finish this process:
812 tests = 98 MB = 11 minutes 27 seconds
813 tests = 100 MB = 21 minutes 26 seconds
817 tests (the whole testsuite) = 111MB = OOME after over 80 minutes

So we can:
- use another XSLT - STX, but this needs new stylesheets, new libraries
- make the noisiest tests less verbose by commenting log.debug()
- make log4j less verbose (this was already done by changing level from DEBUG to FATAL)
- skip both targets above - do we need these files generated by that targets?

TESTS-TestSuites.txt:
**********************
<?xml version="1.0" encoding="UTF-8"?>
<time-of-test>2007-01-25.10-47</time-of-test><jdk-vendor>Sun Microsystems Inc.</jdk-vendor><jdk-version>1.4.2_09</jdk-version><jvm-vm-spec-version>1.0</jvm-vm-spec-version><jvm-name>Java HotSpot(TM) Client VM</jvm-name><jvm-version>1.4.2_09-b05</jvm-version><jvm-info>mixed mode</jvm-info><java-spec-version>1.4</java-spec-version><java-class-version>48.0</java-class-version><os-name>Linux</os-name><os-arch>i386</os-arch><os-version>2.6.9-42.0.2.ELsmp</os-version>4167416511
**********************

TESTS-TestSuites.txt:
**********************
JBoss daily test results

SUMMARY

Number of tests run:   4167

--------------------------------------------

Successful tests:      4165

Errors:                1

Failures:              1

--------------------------------------------



[time of test: 2007-01-25.10-47 GMT]
[java.version: 1.4.2_09]
[java.vendor: Sun Microsystems Inc.]
[java.vm.version: 1.4.2_09-b05]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.6.9-42.0.2.ELsmp]

Useful resources:

- http://jboss.sourceforge.net/junit-results/32/2007-01-25.10-47 for
the junit report of this test.


NOTE: If there are any errors shown above - this mail is only highlighting
them - it is NOT indicating that they are being looked at by anyone.

It is assumed that whoever makes change(s) to jboss that
break the test will be fixing the test or jboss, as appropriate!

--------------------------------------------



DETAILS OF ERRORS



Suite:       org.jboss.test.pooled.test.SSLSocketsUnitTestCase
Test:        testClientCertSSLAccess
Type:        error
Exception:   java.rmi.AccessException
Message:     SecurityException; nested exception is:   javax.security.auth.login.FailedLoginException: Supplied Credential did not match existing credential for null
---------------------------------



Suite:       org.jboss.test.security.test.SRPLoginModuleUnitTestCase
Test:        testSRPLoginWithAuxChallenge
Type:        failure
Exception:   junit.framework.AssertionFailedError
Message:     Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
---------------------------------

**********************

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006616#4006616

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006616


From do-not-reply at jboss.com  Thu Jan 25 20:16:17 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Thu, 25 Jan 2007 20:16:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	testsuite's log4j configuration leads to large reports
Message-ID: <33537836.1169774177546.JavaMail.jboss@colo-br-02.atl.jboss.com>

They are used for the reports summary as well as the email msgs. Perhaps we need a better formatter that produces a more concise summary that does not include all of the console output.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006617#4006617

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006617


From do-not-reply at jboss.com  Thu Jan 25 20:39:53 2007
From: do-not-reply at jboss.com (jailau_24)
Date: Thu, 25 Jan 2007 20:39:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Labs] - JBOSS Problem... When
	trying to contact with JBOSS my server
Message-ID: <9234219.1169775593707.JavaMail.jboss@colo-br-02.atl.jboss.com>

Pls.. help..

Everytime I connect to jboss, tomcat has been dead..
And It returns error:
/var/log/momasrv.log (scanned at Wed Jan 24 16:14:59 PHT 2007) 2007-01-24 16:14:43,300 [MO Service HTTP Client] ERROR com.mwise.HTTP.Client - IOException trying to finish connecting to <202.163.229.51>: java.net.ConnectException: Connection refused 2007-01-24 16:14:43,506 [MO Service HTTP Client] ERROR com.mwise.HTTP.Client - IOException trying to finish connecting to <202.163.229.51>: java.net.ConnectException: Connection refused 2007-01-24 16:14:43,712 [MO Service HTTP Client] ERROR com.mwise.HTTP.Client - IOException trying to finish connecting to <202.163.229.51>: java.net.ConnectException: Connection refused 2007-01-24 16:14:43,918 [MO Service HTTP Client] ERROR com.mwise.HTTP.Client - IOException trying to finish connecting to <202.163.229.51>: java.net.ConnectException: Connection refused 2007-01-24 16:14:43,946 [SmsEngine #50] ERROR mwise.smsengine.Distributor - Error parsing Wddx

Pls. tell me what's the meaning of the error. thanx..

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006620#4006620

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006620


From do-not-reply at jboss.com  Thu Jan 25 20:48:15 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Thu, 25 Jan 2007 20:48:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - DB test matrix
Message-ID: <19100737.1169776095484.JavaMail.jboss@colo-br-02.atl.jboss.com>

The actual tests have a success rate of 78.18%. The goal is to increase the rate to 100%.

The latest tests executed by our labs are visible at http://cruisecontrol.jboss.com:80/cc/buildresults/jboss-portal-2.6-testsuite-db

For now I class the issues into 2 classes :

1/ JBP bugs
2/ configuration issues in labs

So it's a joint effort to achieve 100% :-)


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006622#4006622

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006622


From do-not-reply at jboss.com  Thu Jan 25 20:48:22 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Thu, 25 Jan 2007 20:48:22 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: DB test matrix
Message-ID: <28521531.1169776102235.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have fixed some of them for oracle (Cannot execute query) in InstanceContainerTestCase with persistLocally=false. So in the next run that number should increase a little.

The other large categories failing are :
- SQLServer seems in the limbos, so nothing to look at until I see "Cannot open connection" disappear.

- Mysql X also seems weird in InstanceContainerTestCase : "An instance with id MyInstance already exist". I'll give a try to mysql.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006623#4006623

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006623


From do-not-reply at jboss.com  Thu Jan 25 20:52:53 2007
From: do-not-reply at jboss.com (prabhat.jha@jboss.com)
Date: Thu, 25 Jan 2007 20:52:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: DB test matrix
Message-ID: <21315782.1169776373200.JavaMail.jboss@colo-br-02.atl.jboss.com>

I will  take a look at conneciton issues and URLs.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006624#4006624

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006624


From do-not-reply at jboss.com  Thu Jan 25 21:36:47 2007
From: do-not-reply at jboss.com (jailau_24)
Date: Thu, 25 Jan 2007 21:36:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss/Tomcat Integration] - TOMCAT
	dead everytime I connect to JBOSS
Message-ID: <33444954.1169779007329.JavaMail.jboss@colo-br-02.atl.jboss.com>

Pls.. help.. 

Everytime I connect to jboss, tomcat is dead.. 
And It returns error: 
/var/log/momasrv.log (scanned at Wed Jan 24 16:14:59 PHT 2007) 2007-01-24 16:14:43,300 [MO Service HTTP Client] ERROR com.mwise.HTTP.Client - IOException trying to finish connecting to <202.163.229.51>: java.net.ConnectException: Connection refused 2007-01-24 16:14:43,506 [MO Service HTTP Client] ERROR com.mwise.HTTP.Client - IOException trying to finish connecting to <202.163.229.51>: java.net.ConnectException: Connection refused 2007-01-24 16:14:43,712 [MO Service HTTP Client] ERROR com.mwise.HTTP.Client - IOException trying to finish connecting to <202.163.229.51>: java.net.ConnectException: Connection refused 2007-01-24 16:14:43,918 [MO Service HTTP Client] ERROR com.mwise.HTTP.Client - IOException trying to finish connecting to <202.163.229.51>: java.net.ConnectException: Connection refused 2007-01-24 16:14:43,946 [SmsEngine #50] ERROR mwise.smsengine.Distributor - Error parsing Wddx 

Pls. tell me what's the meaning of the error. thanx..

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006628#4006628

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006628


From do-not-reply at jboss.com  Fri Jan 26 02:42:14 2007
From: do-not-reply at jboss.com (dimitris@jboss.org)
Date: Fri, 26 Jan 2007 02:42:14 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	testsuite's log4j configuration leads to large reports
Message-ID: <18263526.1169797334142.JavaMail.jboss@colo-br-02.atl.jboss.com>

Where are those summaries used? I mean when you browse CC results.

I very much like the stdout output on every test, so I'd rather drop the 2 summaries.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006679#4006679

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006679


From do-not-reply at jboss.com  Fri Jan 26 03:25:20 2007
From: do-not-reply at jboss.com (wojsal1)
Date: Fri, 26 Jan 2007 03:25:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - 2.4.1 - source
	without thirdparty
Message-ID: <9054567.1169799920171.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have got source jboss Portal 2.4.1. In documentation, referenceGuide chapter 2.3.1, is directory thirdparty.
But I have not this directory in my source.
I can't build datasource (because I haven't this direcotory).

What I have to do? Where from I get direcory thirdparty? How I can create this directory with content?

Regards,
WOJSAL

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006692#4006692

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006692


From do-not-reply at jboss.com  Fri Jan 26 03:45:19 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 26 Jan 2007 03:45:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] -
	Registering a bean as an aspect in the bootstrap
Message-ID: <22629026.1169801119625.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm not able to register an aspect using the aop:lifecycle-configure mechanism:

  |    <aop:lifecycle-configure xmlns:aop="urn:jboss:aop-beans:1.0"
  |       name="Deployers"
  |       class="org.jboss.profileservice.aop.DeployerAspects"
  |       classes="org.jboss.deployers.spi.deployer.Deployer"
  |       manager-bean="AspectManager"
  |       manager-property="aspectManager"
  |       pointcut="execution(* $instanceof{org.jboss.deployers.spi.deployer.Deployer}->prepareDeploy(..))">
  |    </aop:lifecycle-configure>
  | 

I have to use the AspectManager ctor config to get this aspect to be applied to the deployers:

  | ...
  |    <aspect name="deployers" class="org.jboss.profileservice.aop.DeployerAspects"/>
  |    <bind pointcut="execution(* $instanceof{org.jboss.deployers.spi.deployer.Deployer}->commitDeploy(..))">
  |       <advice name="commitDeploy" aspect="deployers"/>							         
  |    </bind>
  | 

Is there a way to have an aspect as a bean that can be manipulated as an mc bean that will still be applied to the beans being loaded?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006696#4006696

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006696


From do-not-reply at jboss.com  Fri Jan 26 03:56:08 2007
From: do-not-reply at jboss.com (thomas.heute@jboss.com)
Date: Fri, 26 Jan 2007 03:56:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: 2.4.1 - source
	without thirdparty
Message-ID: <12199898.1169801768752.JavaMail.jboss@colo-br-02.atl.jboss.com>

Just start the building, it will create the directory and get all the stuff in it from the Web.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006702#4006702

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006702


From do-not-reply at jboss.com  Fri Jan 26 04:24:21 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Fri, 26 Jan 2007 04:24:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: what are the new
	features in JBPM 3.2?
Message-ID: <28762715.1169803461455.JavaMail.jboss@colo-br-02.atl.jboss.com>

* email integration is explained in a new chapter in the userguide in the download

* enterprise beans an .ear packaging.  these are not yet properly documented... working on it.

* new project structure (both source tree and download)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006720#4006720

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006720


From do-not-reply at jboss.com  Fri Jan 26 04:28:56 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Fri, 26 Jan 2007 04:28:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Guidance for
	JBPM-725? Applies to 3.2?
Message-ID: <32498670.1169803736784.JavaMail.jboss@colo-br-02.atl.jboss.com>

thanks for bringing that up.  it's a good poit and it would be great if you could help us with that.

did you already sign a contributors agreement ?  if not, see the jbpm wiki oncontributions and check Cotributors Agreement in the left menu of labs.jboss.org (you have to be logged in to sign an agreement)

once that is done, you can get cvs commit access to apply ths change.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006721#4006721

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006721


From do-not-reply at jboss.com  Fri Jan 26 04:34:37 2007
From: do-not-reply at jboss.com (wojsal1)
Date: Fri, 26 Jan 2007 04:34:37 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: 2.4.1 - source
	without thirdparty
Message-ID: <8834836.1169804077144.JavaMail.jboss@colo-br-02.atl.jboss.com>

"thomas.heute at jboss.com" wrote : Just start the building, it will create the directory and get all the stuff in it from the Web.

Thanks,

WOJSAL

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006722#4006722

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006722


From do-not-reply at jboss.com  Fri Jan 26 07:45:53 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Fri, 26 Jan 2007 07:45:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re:
	XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2
Message-ID: <10000752.1169815553945.JavaMail.jboss@colo-br-02.atl.jboss.com>

No.
<track-connection-by-tx/>
is there to disable transaction interleaving.
It is only relevant for XA, it must be true for local.

There has been some debate in the past on whether we should disable
interleaving by default since most XAResources don't support it.
This includes all xa datasources that I've come across which is why
their examples disable it.

e.g. possible change
1) Disable interleaving by default
2) Ignore the track-connection-by-tx
3) Add a new flag <interleaving/>

JBossMQ supports transaction interleaving, meaning the pool
does not have to be as big as for other JMS impls! See below.

Explanation of transaction interleaving:

The purpose of interleaving is to improve the performance of the pool.

If the XAResource supports interleaving then multiple transactions can
go through it at once (although only one transaction can be associated at once).

e.g. Using a single real connection/XAResource

Tx1: Ask for a connection and enlist the xa resource 
XAResource.start(xid1, TMNOFLAGS)

Tx1: Return the connection to the pool 
XAResource.end(xid1, TMSUSPEND)

Tx2: Ask for a connection and enlist the xa resource (it is the same) - XAResource.start(xid2, TMNOFLAGS)

(Point A)

Tx2: Return the connection to the pool
XAResource.end(xid2, TMSUSPEND)

Tx1: Ask for a connection and enlist the xa resource - we resume the old one
XAResource.start(xid1, TMRESUME)

Additionally, the XAResource 2PC commtt protocol can be invoked
concurrently if the XAResource supports interleaving.

i.e. in the above at (Point A) the Tx1/xid1 could be committed even
though the XAResource is currently associated with xid2

As you can see. Support for interleaving greatly reduces the number
of connections required in the pool. 
If you have transaction stickiness (track-connection-by-tx),
you need one connection per transaction, even if the transaction
has already tried to return the connection to the pool, but it hasn't committed it yet.

Example of where interleaving is useful:

1) get jms connection and receive a message
2) return jms connection for somebody else to use
3) do long running process (might take minutes)
4) commit

With track-connection-by-tx, the connection won't become available
until after the long running process is complete, with interleaving
somebody else can use the connection during the long running process.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006779#4006779

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006779


From do-not-reply at jboss.com  Fri Jan 26 07:49:39 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Fri, 26 Jan 2007 07:49:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re:
	XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2
Message-ID: <30568557.1169815779347.JavaMail.jboss@colo-br-02.atl.jboss.com>

Now the explanation is over, what is the exact problem?

The whole point of the XAException test is to make sure the correct
exceptions are being reported, e.g. RuntimeExceptions are not getting leaked
where XAExceptions are expected.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006782#4006782

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006782


From do-not-reply at jboss.com  Fri Jan 26 08:10:00 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Fri, 26 Jan 2007 08:10:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <953353.1169817000687.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | This is possible in JAXB, if you have the following in your root type:
  | Code:
  | 
  |   // Array of Element or JAXB elements.
  |  @XmlAnyElement(lax="true")
  |  public Object[] others;
  | 
  | JAXB dynamically resolves type information off of annotations. So before unmarshalling, if you pass the JAXBContext a FooType.class.
  | 

That isn't what the example does.

JBossXB uses the xml namespace to determine the class to unmarshal
as the wildcard. You don't have to tell it a fixed number of classes/packages upfront
on the JAXBContext.

JAXB is simply not extensible to abitrary wildcards.



  |       <xsd:choice>
  |          <xsd:element name="string" type="stringType" minOccurs="0"/>
  |          <xsd:element name="blah" type="blahType" minOccurs="0"/>
  |          <xsd:any namespace="##other" processContents="strict" minOccurs="0"/>
  |       </xsd:choice>
  | 
  | @RootElement
  | public class MyClass
  | {
  |    <!-- Known bindings -->
  |    @XmlElement(name="string" type=StringSomething.class)
  |    @XmlElement(name="blah" type=BlahSomething.class)
  | 
  |    <!-- Wildcard -->
  |    @XmlAnyElement(I'll accept anything that implements the interface!)
  |    public void setSomethings(List<Something> somethings) {}
  | }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006792#4006792

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006792


From do-not-reply at jboss.com  Fri Jan 26 08:23:37 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Fri, 26 Jan 2007 08:23:37 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <24926115.1169817817675.JavaMail.jboss@colo-br-02.atl.jboss.com>

"jason.greene at jboss.com" wrote : Or different schemas need to be associated with the same object model. 
  | -Jason

Yes, this is also broken as well. :-)

The namspace is associated with the
package level annotation rather the root element.
This is a basic reusability issue.

e.g. It should be:


  | public class AbstractEJBModel
  | {
  |     @XMLElement(name="enterpriseBeans")
  |     public void setEJBs(List<EJB> ejbs);
  | }
  | 
  | @XmlRootElement(namespace="EJB21Namespace")
  | public class Ejb21Model extends AbstractEJBModel
  | {
  | }
  | 
  | @XmlRootElement(namespace="EJB30Namespace")
  | public class Ejb30Model extends AbstractEJBModel
  | {
  | }
  | 

The ejbs property should be mapped to EJB21Namespace/EJB21Model or EJB30Namespace/EJB30Model
depending on the model chosen (the namespace in the xml).

I have this in my prototype of bindings for JBossXB annotations -
the USE_PARENT_NAMESPACE.


  | /**
  |  * SchemaProperty.
  |  * 
  |  * @author <a href="adrian at jboss.com">Adrian Brock</a>
  |  * @version $Revision: 1.1 $
  |  */
  | @Documented
  | @Target(ElementType.METHOD)
  | @Retention(RetentionPolicy.RUNTIME)
  | public @interface SchemaProperty
  | {
  |    /** Whether it is mandatory */
  |    boolean mandatory() default true;
  |    
  |    /** The namespace, default empty */
  |    String namespace() default SchemaConstants.USE_PARENT_NAMESPACE;
  | 
  |    /** The local name, default use the property name */
  |    String name() default SchemaConstants.USE_PROPERTY_NAME;
  |    
  |    /** The implementation class */
  |    Class<?> impl() default Object.class;
  |    
  |    /** TODO remove this when groups work properly */
  |    boolean noInterceptor() default false;
  |    
  |    /** TODO combine with mandatory */
  |    boolean ignore() default false;
  | }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006802#4006802

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006802


From do-not-reply at jboss.com  Fri Jan 26 09:57:56 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Fri, 26 Jan 2007 09:57:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Failing tests
Message-ID: <3638766.1169823476898.JavaMail.jboss@colo-br-02.atl.jboss.com>

I've fixed the javabean2 test.

The problem was caused because there was no constructor element
on which the construction callback was invoked.

I've added some fixup in the endElement of the javabean to cope with this case.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006834#4006834

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006834


From do-not-reply at jboss.com  Fri Jan 26 10:01:26 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Fri, 26 Jan 2007 10:01:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Failing tests
Message-ID: <27162489.1169823686049.JavaMail.jboss@colo-br-02.atl.jboss.com>

I don't like that this javabean2 code is using the MC metadata.

1) There is no way the javabean xml can support all this metadata
2) I want to move the javabean xml to the container project since it should
only really be relying on the BeanInfo abstraction.

The reason I have not moved it before is because it has a dependency
on the KernelConfig class, so it needs a bit of refactoring to make this possible.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006842#4006842

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006842


From do-not-reply at jboss.com  Fri Jan 26 10:09:05 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Fri, 26 Jan 2007 10:09:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re:
	XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2
Message-ID: <20184418.1169824145522.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | Now the explanation is over, what is the exact problem? 
  | 

I explained this already. 

anonymous wrote : 
  | The tests require the failure to occur in the matchManagedConnections method. When the test originally runs, the pool is empty. As a result, a connection is successfully created and enlisted/delisted in the tranasction and returned to the pool. 
  | 
  | The second attempt to acquire the connection fails in the match and the connection is destroyed. Howerver, JBossTS rightfully 'remembers' this guy and when JBossTS attempts to finish the txn protocol the connection has already been destroyed causing the failure. 
  | 
  | 

Basically, JBossTS is attempting to complete the XA protocol on a resource that has already been destroyed which is causing the failure presented in the JIRA issue. The tests itself, as you point out, is designed to make sure that the correct behavior occurs when a match in the managed connection fails. However, as is often the case, it has turned up this other issue.

When you say

anonymous wrote : 
  | There has been some debate in the past on whether we should disable 
  | interleaving by default since most XAResources don't support it. 
  | This includes all xa datasources that I've come across which is why 
  | their examples disable it. 
  | 

This is basically what I am proposing since the default setting to allow for interleaving seems to cause problems with JBossTS and XAResources. 

My plan was to enable <track-connection-by-tx> by default for XA resources, and force it to be explicitly enabled for resources where this makes sense (ie JMS resources). 






View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006848#4006848

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006848


From do-not-reply at jboss.com  Fri Jan 26 10:14:01 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Fri, 26 Jan 2007 10:14:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re:
	XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2
Message-ID: <13486537.1169824441805.JavaMail.jboss@colo-br-02.atl.jboss.com>

Sorry, I probably should have linked this sooner: 


http://jira.jboss.org/jira/browse/JBAS-4017

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006851#4006851

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006851


From do-not-reply at jboss.com  Fri Jan 26 10:16:00 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Fri, 26 Jan 2007 10:16:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re:
	XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2
Message-ID: <27518155.1169824560588.JavaMail.jboss@colo-br-02.atl.jboss.com>

"weston.price at jboss.com" wrote : anonymous wrote : 
  |   | Now the explanation is over, what is the exact problem? 
  |   | 
  | I explained this already. 
  | 

The explanation was incomprehensible since in principal the tests
should work in both mode interleaving and transaction stickiness modes.

I want to hear what the underlying cause is:
1) The test is broken - it is basicaclly a mock test so it is entirely possible
that it is not following the spec properly
2) JBossTS is throwing the wrong exception
3) Some other root problem

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006852#4006852

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006852


From do-not-reply at jboss.com  Fri Jan 26 10:19:27 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Fri, 26 Jan 2007 10:19:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re:
	XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2
Message-ID: <28747590.1169824767981.JavaMail.jboss@colo-br-02.atl.jboss.com>

"weston.price at jboss.com" wrote : 
  | When you say
  | 
  | anonymous wrote : 
  |   | There has been some debate in the past on whether we should disable 
  |   | interleaving by default since most XAResources don't support it. 
  |   | This includes all xa datasources that I've come across which is why 
  |   | their examples disable it. 
  |   | 
  | 
  | This is basically what I am proposing since the default setting to allow for interleaving seems to cause problems with JBossTS and XAResources. 
  | 

Support for interleaving is a spec requirement, see the JTA spec section 3.4.4,
so if JBossTS is broken then it is a bug.

NOTE: Interleaving is a "gambit".

Because of interleaving you can have multiple transactions associated
with the same connection. If the connection breaks you have more
transactions failing for that single underlying failure!

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006854#4006854

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006854


From do-not-reply at jboss.com  Fri Jan 26 11:36:50 2007
From: do-not-reply at jboss.com (alesj)
Date: Fri, 26 Jan 2007 11:36:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Failing tests
Message-ID: <17760769.1169829410294.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : 
  | The reason I have not moved it before is because it has a dependency
  | on the KernelConfig class, so it needs a bit of refactoring to make this possible.

If you give me some directions, I can take a shot at this.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006895#4006895

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006895


From do-not-reply at jboss.com  Fri Jan 26 11:48:53 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Fri, 26 Jan 2007 11:48:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - web console deployment
	problem
Message-ID: <7544281.1169830133893.JavaMail.jboss@colo-br-02.atl.jboss.com>

we are pulling together the build for 3.2.Beta2 on HEAD. there was one last issue we encountered during process deployment from the designer to the console

17:43:51,703 ERROR [[ProcessUploadServlet]] Servlet.service() for servlet ProcessUploadServlet threw exception
  | java.lang.NoClassDefFoundError: org/apache/commons/io/output/DeferredFileOutputStream
  |         at org.apache.commons.fileupload.DefaultFileItemFactory.createItem(DefaultFileItemFactory.java:102)
  |         at org.apache.commons.fileupload.FileUploadBase.createItem(FileUploadBase.java:500)
  |         at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:367)
  |         at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:268)
  |         at org.jbpm.webapp.servlet.ProcessUploadServlet.handleRequest(ProcessUploadServlet.java:87)
  |         at org.jbpm.webapp.servlet.ProcessUploadServlet.service(ProcessUploadServlet.java:63)
  |         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  |         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
  |         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  |         at org.jbpm.webapp.filter.LogFilter.doFilter(LogFilter.java:59)
  |         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  |         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  |         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
  |         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  |         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  |         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
  |         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
  |         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
  |         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
  |         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
  |         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
  |         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
  |         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
  |         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
  |         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
  |         at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
  |         at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
  |         at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
  |         at java.lang.Thread.run(Thread.java:595)
  | 17:43:52,265 DEBUG [JobExecutorThread] acquiring jobs for execution...

Did the introduction of the fileupload 1.1.1 introduce a new dependency on another lib ? 

Maybe you are deploying to jboss 4.0.5, which might have a different set of commons libs...

David could you have a look at it ?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006900#4006900

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006900


From do-not-reply at jboss.com  Fri Jan 26 12:01:01 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Fri, 26 Jan 2007 12:01:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Failing tests
Message-ID: <20423491.1169830861445.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | If you give me some directions, I can take a shot at this.
  | 

Basically move
org.jboss.kernel.plugins.config.xml
to something like
org.jboss.javabean.plugins.xml
in the container project and remove all dependency on the kernel project.

It means changing it to use the
org.jboss.config.spi.Configuration
api rather the KernelConfig.

There might be a few other issues as well?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006909#4006909

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006909


From do-not-reply at jboss.com  Fri Jan 26 12:51:39 2007
From: do-not-reply at jboss.com (pgier)
Date: Fri, 26 Jan 2007 12:51:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Build System] - Common parent
	pom.xml
Message-ID: <1931084.1169833899564.JavaMail.jboss@colo-br-02.atl.jboss.com>

After creating the pom files for microcontainer, and looking at the poms for common, there are some common things that I would like to put into a parent pom.  The main thing initially is the definition of the jboss maven repository and plugin repository.  This parent pom can be put into the maven repository so that we wouldn't have to add it to each project.

Here is what it looks like:

  | <!--
  |   A parent pom with default settings for JBoss projects
  |   Each jboss project should have something similar to the following lines in their pom file.
  | 	<parent>
  | 		<artifactId>jboss-build</artifactId>
  | 		<groupId>jboss</groupId>
  | 		<version>snapshot</version>
  | 	</parent>
  | 
  |   To build this project maven 2 should be installed and "mvn" should be in the system path.  From the command line
  |   run "mvn install".
  | -->
  | 
  | <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  |   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  |   <modelVersion>4.0.0</modelVersion>
  |   <groupId>jboss</groupId>
  |   <version>snapshot</version>
  |   <artifactId>jboss-build</artifactId>
  |   <name>JBoss Build</name>
  |   <url>http://www.jboss.org</url>
  |   <description>Parent POM for all JBoss Projects</description>
  |   <licenses>
  |    <license>
  |       <name>lgpl</name>
  |       <url>http://repository.jboss.com/licenses/lgpl.txt</url>
  |    </license>
  |   </licenses>
  |   <organization>
  |     <name>JBoss Inc.</name>
  |     <url>http://www.jboss.org</url>
  |   </organization>
  | 
  |   <packaging>pom</packaging>
  |   
  |   <repositories>
  |     <repository>
  |       <id>jboss</id>
  |       <name>JBoss Inc. Repository</name>
  |       <layout>default</layout>
  |       <url>http://repository.jboss.com/maven2/</url>
  |       <snapshots>
  |         <enabled>true</enabled>
  |       </snapshots>
  |     </repository>
  |   </repositories>
  | 
  |   <pluginRepositories>
  |      <pluginRepository>
  |         <id>jbosspluginrepo</id>
  |         <name>jboss plugin repository</name>
  |         <url>http://repository.jboss.com/maven2</url>
  |         <layout>default</layout>
  |         <snapshots>
  |            <enabled>false</enabled>
  |            <updatePolicy>never</updatePolicy>
  |         </snapshots>
  |      </pluginRepository>
  |   </pluginRepositories>
  |   
  |   <distributionManagement>
  |     <repository>
  |       <!-- Copy the distribution jar file to a local copy of the maven repository, for use by other projects -->
  |       <id>cvs-file-repository</id>
  |       <url>file://${maven.cvs.root}</url>
  |     </repository>
  |   </distributionManagement>
  | 
  | </project>
  | 

The pom files for the various projects would then add a section like this in the beginning of the file:

  | 	<parent>
  | 		<artifactId>jboss-build</artifactId>
  | 		<groupId>jboss</groupId>
  | 		<version>snapshot</version>
  | 	</parent>
  | 

The parent pom would have to be in the main maven repository (not just the jboss one) because otherwise the child project poms wouldn't be able to find it.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006934#4006934

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006934


From do-not-reply at jboss.com  Fri Jan 26 12:52:06 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Fri, 26 Jan 2007 12:52:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console
	deployment problem
Message-ID: <18774349.1169833926819.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hm, odd that I didn't run across this.  What jbossas version is this on?  I'm running on 4.0.4.GA right now.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006935#4006935

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006935


From do-not-reply at jboss.com  Fri Jan 26 12:56:01 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Fri, 26 Jan 2007 12:56:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console
	deployment problem
Message-ID: <8071916.1169834161544.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ah, never mind - I still had the old version in my deployment.  User error!

I'll check this out.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006939#4006939

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006939


From do-not-reply at jboss.com  Fri Jan 26 13:02:35 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 26 Jan 2007 13:02:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Failing tests
Message-ID: <18353378.1169834555151.JavaMail.jboss@colo-br-02.atl.jboss.com>

I think the Configuration class is missing some function to create the ctor joinpoints which is why I had to use the KernelConfig and kernel metadata. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006944#4006944

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006944


From do-not-reply at jboss.com  Fri Jan 26 13:03:57 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 26 Jan 2007 13:03:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Build System] - Re: Common
	parent pom.xml
Message-ID: <22594438.1169834637981.JavaMail.jboss@colo-br-02.atl.jboss.com>

I want to get to the point of not relying on the maven repos for anything. It should all be in our repository. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006945#4006945

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006945


From do-not-reply at jboss.com  Fri Jan 26 13:46:59 2007
From: do-not-reply at jboss.com (charles.crouch@jboss.com)
Date: Fri, 26 Jan 2007 13:46:59 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: ManagementView
	refresh
Message-ID: <16013945.1169837219804.JavaMail.jboss@colo-br-02.atl.jboss.com>

"charles.crouch at jboss.com" wrote : Running ProfileServiceUnitTestCase from eclipse I just get two failures:
  | 

This was just me not reading the tests properly and the tests themselves not being repeatable. The tests work fine the first time after a Server restart, then fail everytime after that, because one test removes a DataSource, which both tests reference.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006967#4006967

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006967


From do-not-reply at jboss.com  Fri Jan 26 13:51:03 2007
From: do-not-reply at jboss.com (charles.crouch@jboss.com)
Date: Fri, 26 Jan 2007 13:51:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: ManagementView
	refresh
Message-ID: <11600787.1169837463437.JavaMail.jboss@colo-br-02.atl.jboss.com>

I've added a couple more methods to ProfileServiceUnitTestCase to try out the new ManagedComponent api.

Let me know if I'm not using the API in the correct way, and if you have any comments on my inline comments below..


  |  public void testListComponents () throws Exception
  |    {
  | 	   ManagementView mgtView = getManagementView();
  | 	   
  | 	   // maybe needs a ctor which takes type,subtype ?
  | 	   ComponentType type = new ComponentType();
  | 	   type.setType("DataSource");
  | 	   type.setType("LocalTX");
  | 	   Set<ManagedComponent> comps = mgtView.getComponentsForType(type);
  | 	   
  | 	   if (comps != null) 
  | 	   {
  | 		   for (ManagedComponent comp : comps)
  | 		   {
  | 			  String name = comp.getName();
  | 			  Map<String,ManagedProperty> props = comp.getProperties();
  | 		   }
  | 	   }
  |    }
  | 
  |    /**
  |     * test api usage only
  |     * @throws Exception
  |     */   
  |    public void testRemoveComponent () throws Exception
  |    {
  | 	   String componentName = "defaultDS";
  | 	   ManagementView mgtView = getManagementView();
  | 	   
  | 	   ComponentType type = new ComponentType();
  | 	   type.setType("DataSource");
  | 	   type.setType("LocalTX");
  | 	   Set<ManagedComponent> comps = mgtView.getComponentsForType(type);
  | 	   
  | 	   // maybe a mgtView.getComponentByNameAndType(type, componentName) would be helpful
  | 	   // i'm assuming componentName and type will be unique in a given profile.
  | 	   
  | 	   if (comps != null) 
  | 	   {
  | 		   for (ManagedComponent comp : comps)
  | 		   {
  | 			  if (componentName.equals(comp.getName()))
  | 			  {
  | 				  ManagedDeployment deployment = comp.getDeployment();
  | 				  deployment.removeComponent(comp); 
  | 				  break;
  | 			  }		 
  | 		   }
  | 	   }
  |    }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006972#4006972

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006972


From do-not-reply at jboss.com  Fri Jan 26 14:00:08 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Fri, 26 Jan 2007 14:00:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <13597596.1169838008643.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : anonymous wrote : 
  |   | 
  |   | JBossXB uses the xml namespace to determine the class to unmarshal
  |   | as the wildcard. You don't have to tell it a fixed number of classes/packages upfront
  |   | on the JAXBContext.
  |   | 
  | 
  | Either way the mapping of namespace to classes has to be known before unmarshalling, the difference is that you can lazy load classes with JBossXB.    If lazy discovery is important, we should get involved with the spec and get it added.   
  | 
  | anonymous wrote : 
  |   | JAXB is simply not extensible to abitrary wildcards.
  |   | 
  |   | 
  |   |   |       <xsd:choice minOccurs="0" maxOccurs="unbounded">
  |   |   |          <xsd:element name="string" type="stringType" minOccurs="0"/>
  |   |   |          <xsd:element name="blah" type="blahType" minOccurs="0"/>
  |   |   |          <xsd:any namespace="##other" processContents="strict" minOccurs="0"/>
  |   |   |       </xsd:choice>
  |   |   | 
  |   |   | @RootElement
  |   |   | public class MyClass
  |   |   | {
  |   |   |    // Known bindings
  |   |   |    @XmlElement(name="string" type=StringSomething.class)
  |   |   |    @XmlElement(name="blah" type=BlahSomething.class)
  |   |   | 
  |   |   |    // Wildcard
  |   |   |    @XmlAnyElement(I'll accept anything that implements the interface!)
  |   |   |    public void setSomethings(List<Something> somethings) {}
  |   |   | }
  |   |   | 
  | 
  | The issue with a mapping like this is that if there is any similarity between the types that could be present on a wildcard, then using schema subtyping is more appropriate.
  | 
  | -Jason 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006975#4006975

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006975


From do-not-reply at jboss.com  Fri Jan 26 14:04:25 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Fri, 26 Jan 2007 14:04:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <12589418.1169838265437.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : "jason.greene at jboss.com" wrote : Or different schemas need to be associated with the same object model. 
  |   | -Jason
  | 
  | Yes, this is also broken as well. :-)
  | 
  | The namspace is associated with the
  | package level annotation rather the root element.
  | This is a basic reusability issue.
  | 

The package level namespace declaration in JAXB is just a default value for convenience purposes. You can specify the namespace on XmlType and XmlRootElement. 

What I meant is that the you can't have both the ejb2.1 schema and ejb3 schema map to the same objects.

-Jason

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006978#4006978

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006978


From do-not-reply at jboss.com  Fri Jan 26 14:29:07 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Fri, 26 Jan 2007 14:29:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Registering a bean as an aspect in the bootstrap
Message-ID: <3372208.1169839747657.JavaMail.jboss@colo-br-02.atl.jboss.com>

I don't think so unless there is a way to make the MainDeployer and deployers wait until the AspectManagerService is fully installed.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006986#4006986

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006986


From do-not-reply at jboss.com  Fri Jan 26 14:40:36 2007
From: do-not-reply at jboss.com (pgier)
Date: Fri, 26 Jan 2007 14:40:36 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Build System] - Re: Common
	parent pom.xml
Message-ID: <26080918.1169840436762.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, in that case I could leave the repository specification out of the parent pom.  Should we still use a common parent?
We could put the JBoss repository config in each specific project pom, but put the plugin repository and other common configuration into the parent.  Then the build would still function without access to the main maven repository.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006989#4006989

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006989


From do-not-reply at jboss.com  Fri Jan 26 15:28:10 2007
From: do-not-reply at jboss.com (npkphilips)
Date: Fri, 26 Jan 2007 15:28:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - How to Signout from
	MyFacesGenericportlet
Message-ID: <6250963.1169843290662.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm trying to write my own userPortlet. It must be jsf portlet. I am registering users using usermodule and also store my specific registartion information i my Databese table. evrything works fine. i have only problems with logout. I have in my jsf managed bean:
public void logout(ActionEvent event){
  | 	ExternalContext context = FacesContext.getCurrentInstance().getExternalContext();
  | 	JBossActionResponse respone = (JBossActionResponse) context.getResponse();
  | 	respone.signOut();
  | 	}

and call it from jsf page:
<h:commandLink value="logout" actionListener="#{bean.logout}" ></h:commandLink>

response.signOut create errors.
 
registration process uses jsf validation and converters so i don't wont to convert portlet into normal portlet. How can i logout from jsf portlet? When and how can I acces actionResponse from jsf portlet. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007009#4007009

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007009


From do-not-reply at jboss.com  Fri Jan 26 16:43:09 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 26 Jan 2007 16:43:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Build System] - Re: Common
	parent pom.xml
Message-ID: <5440567.1169847789974.JavaMail.jboss@colo-br-02.atl.jboss.com>

That sounds fine. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007038#4007038

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007038


From do-not-reply at jboss.com  Fri Jan 26 17:05:12 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 26 Jan 2007 17:05:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: ManagementView
	refresh
Message-ID: <25697264.1169849112688.JavaMail.jboss@colo-br-02.atl.jboss.com>

"charles.crouch at jboss.com" wrote : I've added a couple more methods to ProfileServiceUnitTestCase to try out the new ManagedComponent api.
  | 
  | Let me know if I'm not using the API in the correct way, and if you have any comments on my inline comments below..
  | 
  | 
  |   |  public void testListComponents () throws Exception
  |   |    {
  |   | 	   ManagementView mgtView = getManagementView();
  |   | 	   
  |   | 	   // maybe needs a ctor which takes type,subtype ?
  |   | 	   ComponentType type = new ComponentType();
  |   | 	   type.setType("DataSource");
  |   | 	   type.setType("LocalTX");
  |   | 	   Set<ManagedComponent> comps = mgtView.getComponentsForType(type);
  |   | 	   
  |   | 	   if (comps != null) 
  |   | 	   {
  |   | 		   for (ManagedComponent comp : comps)
  |   | 		   {
  |   | 			  String name = comp.getName();
  |   | 			  Map<String,ManagedProperty> props = comp.getProperties();
  |   | 		   }
  |   | 	   }
  |   |    }
  |   | 
Needs to use type.setSubtype("LocalTX"), and there is a ctor now. I just checked it in as well. We will need enums for the standard component types as well.

"charles.crouch at jboss.com" wrote : 
  |    /**
  |     * test api usage only
  |     * @throws Exception
  |     */   
  |    public void testRemoveComponent () throws Exception
  |    {
  | 	   String componentName = "defaultDS";
  | 	   ManagementView mgtView = getManagementView();
  | 	   
  | 	   ComponentType type = new ComponentType();
  | 	   type.setType("DataSource");
  | 	   type.setType("LocalTX");
  | 	   Set comps = mgtView.getComponentsForType(type);
  | 	   
  | 	   // maybe a mgtView.getComponentByNameAndType(type, componentName) would be helpful
  | 	   // i'm assuming componentName and type will be unique in a given profile.
  | 	   
  | 	   if (comps != null) 
  | 	   {
  | 		   for (ManagedComponent comp : comps)
  | 		   {
  | 			  if (componentName.equals(comp.getName()))
  | 			  {
  | 				  ManagedDeployment deployment = comp.getDeployment();
  | 				  deployment.removeComponent(comp); 
  | 				  break;
  | 			  }		 
  | 		   }
  | 	   }
  |    }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007043#4007043

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007043


From do-not-reply at jboss.com  Fri Jan 26 17:15:33 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 26 Jan 2007 17:15:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <17591324.1169849733570.JavaMail.jboss@colo-br-02.atl.jboss.com>

"jason.greene at jboss.com" wrote : 
  | Either way the mapping of namespace to classes has to be known before unmarshalling, the difference is that you can lazy load classes with JBossXB.    If lazy discovery is important, we should get involved with the spec and get it added.   
  | anonymous wrote : 
  |   | The more immeadiate question is whether getting involved with jaxb to get jbossxb features into it is worth while. 
  |   | 
  |   | "jason.greene at jboss.com" wrote : 
  |   |   | The issue with a mapping like this is that if there is any similarity between the types that could be present on a wildcard, then using schema subtyping is more appropriate.
  |   |   | 
  |   | I don't see how that resolves the problem. That just introduces a common base schema type for the interface, but it still has a wildcard because the implementation details are outside of the contract. This is a common issue with a plugin architecture.
  |   | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007049#4007049

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007049


From do-not-reply at jboss.com  Fri Jan 26 17:20:14 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Fri, 26 Jan 2007 17:20:14 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <28477753.1169850014402.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | The more immeadiate question is whether getting involved with jaxb to get jbossxb features into it is worth while. 
  | 

There are a lot of specs that I think we should be involved in (ie JDBC etc) and this is one of them. Time constraints notwithstanding, I think it's important to get our voice/participation. I hate the NIH syndrome and I think we fall prey to it more often than not. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007051#4007051

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007051


From do-not-reply at jboss.com  Fri Jan 26 17:22:02 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 26 Jan 2007 17:22:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Registering a bean as an aspect in the bootstrap
Message-ID: <29379723.1169850122708.JavaMail.jboss@colo-br-02.atl.jboss.com>

It should be possible because the MainDeployer is just a bean in the bootstrap process. The classes should all be in the same class loader space, and we should be able to know the aspects that will be applied before any bean class is loaded (unless that is a limitation of the current bean introspection implementation). Adrian thought this should be possible when I asked him about it this morning. I'm going to create a simpler testcase in the mc project to describe and validate the usecase I'm after.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007052#4007052

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007052


From do-not-reply at jboss.com  Fri Jan 26 17:23:56 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 26 Jan 2007 17:23:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <3740077.1169850236746.JavaMail.jboss@colo-br-02.atl.jboss.com>

"weston.price at jboss.com" wrote : anonymous wrote : 
  |   | The more immeadiate question is whether getting involved with jaxb to get jbossxb features into it is worth while. 
  |   | 
  | 
  | There are a lot of specs that I think we should be involved in (ie JDBC etc) and this is one of them. Time constraints notwithstanding, I think it's important to get our voice/participation. I hate the NIH syndrome and I think we fall prey to it more often than not. 
  | 
  | 
The spec is not the issue though. Its clearly under defined for our legacy usecases. I'm more interested in implementation first, spec second. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007053#4007053

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007053


From do-not-reply at jboss.com  Fri Jan 26 17:38:57 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Fri, 26 Jan 2007 17:38:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <7909856.1169851137056.JavaMail.jboss@colo-br-02.atl.jboss.com>

That's fine, and I many ways I agree with you. However, my next question would be how many legacy use cases do we really have,  and more importantly, are there enough cases to develop an entire in-house, non-standard binding framework to handle 2%, 5%? 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007055#4007055

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007055


From do-not-reply at jboss.com  Fri Jan 26 17:41:53 2007
From: do-not-reply at jboss.com (jaroslaw.kijanowski)
Date: Fri, 26 Jan 2007 17:41:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	testsuite's log4j configuration leads to large reports
Message-ID: <20219728.1169851313186.JavaMail.jboss@colo-br-02.atl.jboss.com>

Which formatter do you mean? JUnit? there are just three - xml, brief and plain... or a custom one.

We need for every test the DEBUG messages - this lead to bigger TEST-testname.xml files - this leads to a huge (unparseable by XSLT) TESTS-Testsuites.xml file. 

What do you think about this:
Let's generate TEST-testname.xml files like before, with all the DEBUG messages
Let's parse 817 TEST-testname.xml files (the whole testsuite) to 817 small TEST-testname_short_version.xml files, just for the purpose to create this two summaries.
Now we could generate two TESTS-Testsuites.xml files, the big one for the html report (which does not nead a XSL Transformation) and the small one for these summaries where XSLT is involved. 

Pros: We can leave DEBUG messages in the html report

Cons:
 - we need a lot of more space ~ 200MB per testsuite
 - it could take a while (how long? no idea...) to parse 817 files to 817 smaller files

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007056#4007056

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007056


From do-not-reply at jboss.com  Fri Jan 26 17:46:33 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 26 Jan 2007 17:46:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <2103838.1169851593980.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes, its the plethora of legacy dtds, as well as features like the wildcard issue. We should be looking first to get support for these in the jaxb project as extensions, and then worry about what can be standarized.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007057#4007057

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007057


From do-not-reply at jboss.com  Fri Jan 26 17:48:10 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Fri, 26 Jan 2007 17:48:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <11210263.1169851690018.JavaMail.jboss@colo-br-02.atl.jboss.com>

+1

Well said. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007058#4007058

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007058


From do-not-reply at jboss.com  Fri Jan 26 17:58:53 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 26 Jan 2007 17:58:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	testsuite's log4j configuration leads to large reports
Message-ID: <32955180.1169852333020.JavaMail.jboss@colo-br-02.atl.jboss.com>

I was thinking of a custom xml formatter that produced the current TEST-testname.xml along with a TEST-summary-testname.xml that would not contain any stderr/out output to feed into the summary. It may also be easier to just write a simple summary java program and bypas the use of xsl for the simple xml/txt summaries.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007060#4007060

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007060


From do-not-reply at jboss.com  Fri Jan 26 18:18:32 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Fri, 26 Jan 2007 18:18:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Issues with passivation of
	nested SFSBs
Message-ID: <20038660.1169853512085.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm seeing some issues related to caching and passivation of nested SFSBs (i.e. one SFSB holds a ref to another, i.e. through an @EJB annotation).  I'd like to get some input as to what the proper behavior is.

What I'm seeing is:

If the nested bean declares an @Remote interface, when the parent bean is being constructed for the nested bean an instance of StatefulBeanContext ends up being cached.  This works fine.

If the nested bean does not declare an @Remote interface, when the parent bean is being constructed, for the nested bean an instance of ProxiedStatefulBeanContext ends up being cached.  This leads to problems.

The problem occurs if the parent bean is later removed. This does not result in a call to remove the child bean from the cache. (I don't know if that's a problem or not; Chapter 11.7 of Bill Burke's book says it should be removed, but I couldn't find a discussion of that in the spec.)

A replicated ProxiedStatefulBeanContext is useless if its parent is not in the cache. The replication clears the transient reference to the parent bean.  If the context is later used, ProxiedStatefulBeanContext.getDelegate() will attempt to look up the parent, which will result in a NoSuchEjbException.

The problem occurs when the background passivation thread decides to passivate the orphaned ProxiedStatefulBeanContext and calls prePassivate(). You get this:


  | javax.ejb.NoSuchEJBException: Could not find Stateful bean: a1g1m-b11vx1-exf6itu4-1-exf6mcqp-1v
  | 	at org.jboss.ejb3.cache.tree.StatefulTreeCache.get(StatefulTreeCache.java:148)
  | 	at org.jboss.ejb3.stateful.StatefulBeanContextReference.getBeanContext(StatefulBeanContextReference.java:72)
  | 	at org.jboss.ejb3.stateful.ProxiedStatefulBeanContext.getDelegate(ProxiedStatefulBeanContext.java:70)
  | 	at org.jboss.ejb3.stateful.ProxiedStatefulBeanContext.getContainer(ProxiedStatefulBeanContext.java:213)
  | 	at org.jboss.ejb3.stateful.StatefulBeanContext.prePassivate(StatefulBeanContext.java:178)
  | 	at org.jboss.ejb3.cache.tree.StatefulTreeCache$ClusteredStatefulCacheListener.nodePassivated(StatefulTreeCache.java:376)
  | 	at org.jboss.cache.notifications.Notifier.notifyNodePassivated(Notifier.java:423)
  |    ...

Id a1g1m-b11vx1-exf6itu4-1-exf6mcqp-1v belongs to the parent bean.

Some solutions I can see are:

1) If the child bean is meant to be removed along with the parent, fix whatever's preventing that from happening.

2) Have the StatefulCache impls not cache instances of ProxiedStatefulBeanContext. I don't understand the usage of this class well enough to know whether that's a valid solution or not. I doubt it.

3) Have the StatefulCache impls catch NoSuchEjbException when they call prePassivate().  Check if the context type is ProxiedStatefulBeanContext; if it is, suppress the exception and remove the useless context from the cache.  That's ugly but limited in scope.

Any comments/suggestions are most appreciated.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007065#4007065

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007065


From do-not-reply at jboss.com  Fri Jan 26 18:22:00 2007
From: do-not-reply at jboss.com (jaroslaw.kijanowski)
Date: Fri, 26 Jan 2007 18:22:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	testsuite's log4j configuration leads to large reports
Message-ID: <33343326.1169853720271.JavaMail.jboss@colo-br-02.atl.jboss.com>

I think it's easier to get xml files without stderr/out by writing a new stylesheet. writing an own formatter or a java program would need to integrate it with the testsuite.

Finally these "short-version" files could be removed so additional space is not needed.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007066#4007066

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007066


From do-not-reply at jboss.com  Fri Jan 26 18:29:33 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Fri, 26 Jan 2007 18:29:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <29610132.1169854173226.JavaMail.jboss@colo-br-02.atl.jboss.com>

As expected, solution #2 above is not an option; if you don't cache the context the parent bean can't invoke on the child. DOH!

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007068#4007068

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007068


From do-not-reply at jboss.com  Fri Jan 26 18:35:23 2007
From: do-not-reply at jboss.com (charles.crouch@jboss.com)
Date: Fri, 26 Jan 2007 18:35:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: ManagementView
	refresh
Message-ID: <26146821.1169854523672.JavaMail.jboss@colo-br-02.atl.jboss.com>

"scott.stark at jboss.org" wrote : 
  | The component name will not be unique in a profile in general because of scoped components like mdbs, local ejbs which only need unique names within their deployment. 
  | 

Understood. -1 on getComponentByNameAndType.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007072#4007072

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007072


From do-not-reply at jboss.com  Fri Jan 26 19:08:25 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 26 Jan 2007 19:08:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	testsuite's log4j configuration leads to large reports
Message-ID: <14392462.1169856505615.JavaMail.jboss@colo-br-02.atl.jboss.com>

If that works, great. I was not clear on whether a new stylesheet avoids the current memory problem. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007075#4007075

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007075


From do-not-reply at jboss.com  Fri Jan 26 21:04:25 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Fri, 26 Jan 2007 21:04:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Re: JAXBDeployer
Message-ID: <16428869.1169863465538.JavaMail.jboss@colo-br-02.atl.jboss.com>

"scott.stark at jboss.org" wrote : "jason.greene at jboss.com" wrote : 
  |   | Either way the mapping of namespace to classes has to be known before unmarshalling, the difference is that you can lazy load classes with JBossXB.    If lazy discovery is important, we should get involved with the spec and get it added.   
  |   | 
  | The more immeadiate question is whether getting involved with jaxb to get jbossxb features into it is worth while. 
  | 

I definately can't say, but my guess is that its not necessary at this point. since so much is built on JBossXB. However, longer term it should be looked at IMO. 

anonymous wrote : 
  | "jason.greene at jboss.com" wrote : 
  |   | The issue with a mapping like this is that if there is any similarity between the types that could be present on a wildcard, then using schema subtyping is more appropriate.
  |   | 
  | I don't see how that resolves the problem. That just introduces a common base schema type for the interface, but it still has a wildcard because the implementation details are outside of the contract. This is a common issue with a plugin architecture.
  | 

It doesn't. I was looking at it from the perspective of how a general xml binding framework should work.  Mapping a wildcard to an interface, or common subtype adds restrictions that aren't represented in the schema definition.  So Object (or some binding based wildcard java type) is a more natural container for a schema wildcard. However, I can see where being able to add your own generic wildcard type would simplify the programming model.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007100#4007100

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007100


From do-not-reply at jboss.com  Fri Jan 26 21:22:29 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Fri, 26 Jan 2007 21:22:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of the JBoss EJB Container] - JBAS-3873,
	Clarify the setRollbackOnly issue
Message-ID: <12971550.1169864549618.JavaMail.jboss@colo-br-02.atl.jboss.com>

http://jira.jboss.com/jira/browse/JBAS-3873 what is the non-deterministic behavior that needs to be fixed?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007101#4007101

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007101


From do-not-reply at jboss.com  Fri Jan 26 22:17:37 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Fri, 26 Jan 2007 22:17:37 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console
	deployment problem
Message-ID: <4533075.1169867858005.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, should be fixed now.  I had to put commons-io 1.2 out on the repository server since the latest out there was 1.0.  I tested uploading a process in the webapp and it works.  Also flushed out a bug in the console ant script and a console redirect bug which I somehow missed before.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007112#4007112

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007112


From do-not-reply at jboss.com  Sat Jan 27 03:25:45 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Sat, 27 Jan 2007 03:25:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - wsgen API, SPI,
	command line tool, and ant task
Message-ID: <29634578.1169886345939.JavaMail.jboss@colo-br-02.atl.jboss.com>

As of today, I checked in a full implementation of the JAX-WS wsgen tool. This work includes a full API and SPI, as well as an ant task and command line tool.

The WebServiceGenerator API is available here:
http://labs.jboss.com/file-access/default/members/jbossws/downloads/api-docs/org/jboss/ws/tools/jaxws/api/WebServiceGenerator.html

The WebServiceGeneratorProvider SPI here:
http://labs.jboss.com/file-access/default/members/jbossws/downloads/api-docs/index.html

A custom provider can be specified using the system property "org.jboss.ws.tools.jaxws.webServiceGeneratorProvider". This property is also available as static public field on WebServiceGenerator.

The command line tool documentation is available here:
http://labs.jboss.com/file-access/default/members/jbossws/downloads/api-docs/org/jboss/ws/tools/jaxws/WSGenerate.html

The ant task documentation is available here:
http://labs.jboss.com/file-access/default/members/jbossws/downloads/api-docs/org/jboss/ws/tools/jaxws/ant/WSGenerate.html

The test case that demonstrates the API is located here:
http://fisheye.jboss.com/browse/JBossWS/trunk/jbossws-tests/src/main/java/org/jboss/test/ws/tools/jaxws/WebServiceGeneratorTestCase.java?r=2156

-Jason

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007142#4007142

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007142


From do-not-reply at jboss.com  Sat Jan 27 04:27:45 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Sat, 27 Jan 2007 04:27:45 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console
	deployment problem
Message-ID: <20497121.1169890065970.JavaMail.jboss@colo-br-02.atl.jboss.com>

cool, thanks!

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007150#4007150

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007150


From do-not-reply at jboss.com  Sat Jan 27 08:07:25 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Sat, 27 Jan 2007 08:07:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: DB test matrix
Message-ID: <25478689.1169903245637.JavaMail.jboss@colo-br-02.atl.jboss.com>

The success rate has increased to 79.85% (1320 tests) due to the tests for oracle/InstanceContainer which are passing now.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007167#4007167

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007167


From do-not-reply at jboss.com  Sat Jan 27 08:11:39 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Sat, 27 Jan 2007 08:11:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: DB test matrix
	(Repost)
Message-ID: <7871416.1169903499143.JavaMail.jboss@colo-br-02.atl.jboss.com>

The success rate has increased to 79.85% (1320 tests) due to the tests for oracle/InstanceContainer which are passing now.

The InstanceContainerTestCase was showing (total/errors/failures) :


  | 84/35/1
  | 84/33/1
  | 84/23/1
  | 84/23/1
  | 

Now we have :


  | 84/23/1
  | 84/23/1
  | 84/23/1
  | 84/23/1
  | 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007167#4007167

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007167


From do-not-reply at jboss.com  Sat Jan 27 11:26:59 2007
From: do-not-reply at jboss.com (camunda)
Date: Sat, 27 Jan 2007 11:26:59 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: committing content
	from our
Message-ID: <18984755.1169915219794.JavaMail.jboss@colo-br-02.atl.jboss.com>

Okay, I have started to transfer our code to Commands. The first thing to say is, that we will need a lot of commands (because for working with a fat client we need a command for every communication with the engine), but I think that is not a problem (and I do not know a good way around that).

I have some questions on code conventions in the jbpm project, I haven't figured it our myself and the JBoss-Website seems to be down today :-(

1) What Exception to use if I get invalid data in a command? The JbpmException?

2.) Where to put Hibernate-Queries? We had to build some additional ones for some circumstances. I have seen you put them into a xml-file. This is good for seperating of concerns but I don't like it to much because you get typos in Classes or package names faster there. But anyway, if I have additional queries, can I add them there? Or write them into the commands (not a good idea I think), or just move the HibernateQuery-class we have to the jBPM code base?

3) Which JDK to use? Can I use generics (so loose JDK 1.4 compability)?

Another question: Shouldn't be every attribute in the commands private? Because in the existing commands all attributes are package local...

And the last question: Where to put concrete questions on the already existing commands. In the sourcecode? Here in the forum? Wiki?

Thanks in advance for the answers and a nice weekend
Bernd

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007207#4007207

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007207


From do-not-reply at jboss.com  Sat Jan 27 11:34:55 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Sat, 27 Jan 2007 11:34:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Property replacement
Message-ID: <7661601.1169915695230.JavaMail.jboss@colo-br-02.atl.jboss.com>

Apologies in advance if this is a hijack; I'll open another thread if the work discussed here isn't the cause...

In AS trunk with the latest microcontainer jars, this no longer works in a -beans.xml:

<annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=HASingletonDeploymentScanner,partitionName=${jboss.partition.name:DefaultPartition}", exposedInterface=org.jboss.ha.singleton.HASingletonDeploymentScannerMBean.class, registerDirectly=true)</annotation>

You get:

10:18:00,181 ERROR [AbstractKernelController] Error installing to Configured: name=HASingletonDeploymentScanner state=Instantiated
  | javax.management.MalformedObjectNameException: Invalid character ':' in value part of property
  |         at javax.management.ObjectName.construct(ObjectName.java:529)
  |         at javax.management.ObjectName.<init>(ObjectName.java:1304)
  |         at org.jboss.aop.microcontainer.aspects.jmx.JMXIntroduction.invoke(JMXIntroduction.java:71)
  |         at org.jboss.aop.advice.org.jboss.aop.microcontainer.aspects.jmx.JMXIntroduction_z_invoke_24464082.invoke(JMXIntroduction_z_invoke_24464082.java)
  |         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
  |         at AOPContainerProxy$5.setKernelControllerContext(AOPContainerProxy$5.java)
  |         at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:208)
  |         at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
  | ...

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007210#4007210

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007210


From do-not-reply at jboss.com  Sat Jan 27 11:40:28 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Sat, 27 Jan 2007 11:40:28 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: committing content
	from our
Message-ID: <10062892.1169916028498.JavaMail.jboss@colo-br-02.atl.jboss.com>

I've no idea about 1 and 2, but the answer to 3 is that jdk 1.4 compatibility is still required for the 3.2 core. Don't know if 3.3 or 4 will target 1.5/5 but 3.2 definately not. Sorry.

The questions if it is not a summary should be discussed here. The outcom could be summarized in the wiki


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007212#4007212

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007212


From do-not-reply at jboss.com  Sat Jan 27 13:05:24 2007
From: do-not-reply at jboss.com (alesj)
Date: Sat, 27 Jan 2007 13:05:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Property replacement
Message-ID: <333788.1169921124150.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bstansberry at jboss.com" wrote : 
  | <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=HASingletonDeploymentScanner,partitionName=${jboss.partition.name:DefaultPartition}", exposedInterface=org.jboss.ha.singleton.HASingletonDeploymentScannerMBean.class, registerDirectly=true)</annotation>

Uf, yes. 
I removed the XB doing the replacement, but forgot to add this in the annotation value handling - since this string value is directly used, and not via StringValueMetaData.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007229#4007229

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007229


From do-not-reply at jboss.com  Sat Jan 27 13:44:13 2007
From: do-not-reply at jboss.com (alesj)
Date: Sat, 27 Jan 2007 13:44:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Property replacement
Message-ID: <11454213.1169923453831.JavaMail.jboss@colo-br-02.atl.jboss.com>

How do we change this:

  |    <xsd:simpleType name="annotationType">
  |       <xsd:annotation>
  |          <xsd:documentation>
  |            <![CDATA[
  |            The annotation type represents a Java5 annotation on the particular join point.
  |            ]]>
  |          </xsd:documentation>
  |       </xsd:annotation>
  |       <xsd:restriction base="xsd:string">
  |          <xsd:whiteSpace value="collapse"/>
  |       </xsd:restriction>
  |    </xsd:simpleType>
  | 

so that I can add an this (replace="false"):
<annotation replace="false">@SomeAnnotation</annotation>

Is it ok that we have StringPropertyReplacer in AbstractAnnotationMetaData?
         String annString = StringPropertyReplacer.replaceProperties(annotation);
  |          //FIXME [JBMICROCONT-99] [JBAOP-278] Use the loader for the bean?
  |          ann = (Annotation)AnnotationCreator.createAnnotation(annString, Thread.currentThread().getContextClassLoader());
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007231#4007231

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007231


From do-not-reply at jboss.com  Sat Jan 27 13:49:33 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Sat, 27 Jan 2007 13:49:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	testsuite's log4j configuration leads to large reports
Message-ID: <7851561.1169923773992.JavaMail.jboss@colo-br-02.atl.jboss.com>

"scott.stark at jboss.org" wrote : If that works, great. I was not clear on whether a new stylesheet avoids the current memory problem. 


I agree with Scott.. I don't think just replacing the XSL would fix the memory problem.

The stdout still on the XML for each test. When JUnitReport aggregates all the tests in a single XML, you will still have a problem to read that huge XML entry. (The System.out/ System.err). And that's what I think is happening.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007232#4007232

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007232


From do-not-reply at jboss.com  Sat Jan 27 14:38:57 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Sat, 27 Jan 2007 14:38:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Property replacement
Message-ID: <18684582.1169926737069.JavaMail.jboss@colo-br-02.atl.jboss.com>

The places where I was using that syntax, it wasn't critical. So for now I've removed it so the AS trunk builds will work correctly. I'll monitor JBMICRONTAINER-143 and once it's done I'll restore the property replacement syntax in the annotation values.

Thanks!

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007245#4007245

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007245


From do-not-reply at jboss.com  Sat Jan 27 15:09:24 2007
From: do-not-reply at jboss.com (jaroslaw.kijanowski)
Date: Sat, 27 Jan 2007 15:09:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re:
	testsuite's log4j configuration leads to large reports
Message-ID: <19669747.1169928564582.JavaMail.jboss@colo-br-02.atl.jboss.com>

A huge TESTS-Testsuites.xml file is ok as long it is not parsed by XSLT. To generate a html report we don't use XSLT. We use XSLT just for generating these two summaries.

So my idea is to use XSLT not for the huge TESTS-Testsuites.xml, but to generate smaller TEST-testname_short_version.xml files. Then, JUnitReport will generate a second TESTS-Testsuites_short_version.xml by aggregating these "short_version" xml files and not the bigger ones.

Finally TESTS-Testsuites_short_version.xml would be used for generating summaries with the old stylesheets.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007256#4007256

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007256


From do-not-reply at jboss.com  Sat Jan 27 17:53:40 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Sat, 27 Jan 2007 17:53:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: DB test matrix
Message-ID: <12143475.1169938420682.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have executed the test suite against mysql5 and all tests are passing so there is something wrong in the QA mysql5 configuration which prevents tests to execute correctly.

My configuration is :

Server version: 5.0.33 Source distribution
mysql-connector-java-5.0.4-bin.jar

datasource configured in datasources.xml


  | <datasource>
  |      <datasource-name>mysql5</datasource-name>
  |      <connection-url>jdbc:mysql://localhost:3306/jbossportal?useServerPrepStmts=false&jdbcCompliantTruncation=false</connection-url>
  |      <driver-class>com.mysql.jdbc.Driver</driver-class>
  |      <user-name>portal</user-name>
  |      <password>portalpassword</password>
  | </datasource>
  | 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007286#4007286

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007286


From do-not-reply at jboss.com  Sat Jan 27 18:59:35 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Sat, 27 Jan 2007 18:59:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <22187802.1169942375744.JavaMail.jboss@colo-br-02.atl.jboss.com>

I implemented solution #3 above for StatefulTreeCache, since normal usage of clustered SFSBs with nested beans will lead to ERRORs in the logs. I think the usage pattern that would lead problems with non-clustered beans is more of an edge case (requires the parent to hand out a ref to the child), so I won't implement it in SimpleStatefulCache without more feedback.

The callbacks related to activation/passivation are also not handled correctly.  See http://jira.jboss.com/jira/browse/EJBTHREE-849.

The same analysis I applied in EJBTHREE-849 could also apply to the @PreDestroy callback.  Currently, o.j.e.test.clusteredsession.ExtendedPersistenceContextUnitTestCase is failing because this callback is not invoked.  I'm not sure if the spec requires invoking the @PreDestroy callback in this situation though.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007303#4007303

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007303


From do-not-reply at jboss.com  Sat Jan 27 19:10:32 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Sat, 27 Jan 2007 19:10:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <21267131.1169943032546.JavaMail.jboss@colo-br-02.atl.jboss.com>

Tangentially related to this is the issue of ClusteredStatefulCache.replicate(StatefulBeanContext) for a nested SFSB with no remote interface.  This method gets invoked on the return side of a clustered SFSB invocation.  Again, in this case, the cached context is a proxy.  Replicating the proxy here serves little purpose, as it doesn't result in any bean state being replicated.

Question is, should the *parent context* be replicated in this case? That's what actually holds the child bean's state.

Replicating the parent is more correct, as it ensures the data is replicated. But it can be inefficient -- i.e. imagine a call on the parent that internally results in calls on 3 child beans.  That would result in 4 replications of the parent, when 1 would suffice.  It could also cause problems, as 3 of the replications would occur while the parent bean is in the middle of the outer invocation.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007306#4007306

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007306


From do-not-reply at jboss.com  Sun Jan 28 03:37:07 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Sun, 28 Jan 2007 03:37:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Property replacement
Message-ID: <8628165.1169973427302.JavaMail.jboss@colo-br-02.atl.jboss.com>

"alesj" wrote : How do we change this:
  | 
  |   |    <xsd:simpleType name="annotationType">
  |   |       <xsd:annotation>
  |   |          <xsd:documentation>
  |   |            <![CDATA[
  |   |            The annotation type represents a Java5 annotation on the particular join point.
  |   |            ]]>
  |   |          </xsd:documentation>
  |   |       </xsd:annotation>
  |   |       <xsd:restriction base="xsd:string">
  |   |          <xsd:whiteSpace value="collapse"/>
  |   |       </xsd:restriction>
  |   |    </xsd:simpleType>
  |   | 
  | anonymous wrote : 
  |   | 
  |   | To allow an attribute on the annotation element, you need to change it to a complexType/simpleContent:
  |   | 
  |   | 
  |   |   |    <xsd:complexType name="annotationType">
  |   |   |       <xsd:annotation>
  |   |   |          <xsd:documentation>
  |   |   |             <![CDATA[
  |   |   |            The annotation type represents a Java5 annotation on the particular join point.
  |   |   |            ]]>
  |   |   |          </xsd:documentation>
  |   |   |       </xsd:annotation>
  |   |   | 
  |   |   |       <xsd:simpleContent>
  |   |   |          <xsd:extension base="xsd:string">
  |   |   |             <xsd:attribute name="replace" type="xsd:boolean" default="false" />
  |   |   |          </xsd:extension>
  |   |   |       </xsd:simpleContent>
  |   |   |    </xsd:complexType>
  |   |   | 
  |   | 
  |   | "alesj" wrote : 
  |   |   | Is it ok that we have StringPropertyReplacer in AbstractAnnotationMetaData?
  |   |   |          String annString = StringPropertyReplacer.replaceProperties(annotation);
  |   |   |   |          //FIXME [JBMICROCONT-99] [JBAOP-278] Use the loader for the bean?
  |   |   |   |          ann = (Annotation)AnnotationCreator.createAnnotation(annString, Thread.currentThread().getContextClassLoader());
  |   |   |   | 
  |   |   | 
  |   | I guess, but I don't see this as a natural usage. A check of the replace attribute would be needed.
  |   | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007381#4007381

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007381


From do-not-reply at jboss.com  Sun Jan 28 05:10:38 2007
From: do-not-reply at jboss.com (litalh)
Date: Sun, 28 Jan 2007 05:10:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JMX on JBoss (JBoss/JMX)] - Problem
	deploy my application using JMX over RMI
Message-ID: <3504746.1169979038193.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi,

I'm trying to deploy my application using JMX over RMI. This works great on jboss 4.0.2 but failes on jboss 4.0.3 and later versions.
I'm performing the deploy operation calling:

  server.invoke(deployment.getMainDeployer(), "deploy", new Object[]{"http://localhost:8080/AppSight/download/installer?filename=/jboss/AppSightInstallerService.deployer"},
                        new String[]{"java.lang.String"});

As aresult I get the following error:
Caused by: Incomplete Deployment listing:

--- Packages waiting for a deployer ---
org.jboss.deployment.DeploymentInfo at e8499f27 { url=http://localhost:8080/AppSight/download/installer?filename=/jboss/AppSightInstallerService.deployer }
  deployer: null
  status: null
  state: INIT_WAITING_DEPLOYER
  watch: http://localhost:8080/AppSight/download/installer?filename=/jboss/AppSightInstallerService.deployer
  altDD: null
  lastDeployed: 1169745706645
  lastModified: 1169745706630
  mbeans:

Was there any change in the way the JMX works in these versions.

I will appreciate any help.
Thanks,
Lital

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007393#4007393

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007393


From do-not-reply at jboss.com  Sun Jan 28 17:55:19 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Sun, 28 Jan 2007 17:55:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Registering a bean as an aspect in the bootstrap
Message-ID: <31165145.1170024919218.JavaMail.jboss@colo-br-02.atl.jboss.com>

I created two tests in the aop-mc-int project org.jboss.test.microcontainer.test.{DeployersInterceptedTestCase,DeployersLifecycleTestCase} that I was able to get working. However, the $instanceof{org.acme.IfA}->$implements(org.acme.IfA) pointcut expression is either not working or not working as expected. I left the DeployersInterceptedTestCase.xml descriptor with the pointcut that does not work. Can you look at why this fails to match anything?

Both $instanceof{org.acme.IfA}->*(..) and $instanceof{org.acme.IfA}->someMethod(..) are working.

Now I need to see if this can be made to work in the jboss5 bootstrap. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007580#4007580

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007580


From do-not-reply at jboss.com  Sun Jan 28 18:40:56 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Sun, 28 Jan 2007 18:40:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Registering a bean as an aspect in the bootstrap
Message-ID: <20942561.1170027656540.JavaMail.jboss@colo-br-02.atl.jboss.com>

The same type of configuration in the jboss5 conf/bootstrap-beans.xml fails to apply the deployer aspects. How are the org.jboss.aop.deployers.AspectManagerJDK5 and org.jboss.aop.AspectManager going to differ?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007596#4007596

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007596


From do-not-reply at jboss.com  Mon Jan 29 03:20:22 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 29 Jan 2007 03:20:22 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: committing content
	from our
Message-ID: <2114207.1170058822182.JavaMail.jboss@colo-br-02.atl.jboss.com>


Java version:
runtime engine of 3.x.x must run on JDK 1.4.2
the next version of the console 3.3+  probably will require java 5

Commands
Having a lot of commands is not a problem.  That is in fact the reason why we use the command pattern over the typical session facade.

But you could do similar things like with database connections: provide a base API with which you can send queries and retrieve results.  There is one catch however: lazy loading.  Together with the query, you should send some instructions on which relations of the retrieved objects should be eager loaded.

When the result is serialized and deserialized on the client, lazy loading will not work.

Another approach to adding eager loading indications is to create commands to navigate the relations: e.g. 1 command to get all the swimlaneInstances for this taskInstance.

If you want more info on these various approaches and their tradeoffs, you can give me a skype.

Exceptions
Use JbpmException or create a specific command exception if you think it is applicable.  as long as it inherits from JbpmException and as long as you keep the total number of exception types low.  

More important, try to document very carefully the return values of the commands and the exceptions they throw

Where to put the queries
Is this the file you're looking for ?

  | jpdl/jar/src/main/java/org/jbpm/db/hibernate.queries.hbm.xml

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007681#4007681

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007681


From do-not-reply at jboss.com  Mon Jan 29 03:31:18 2007
From: do-not-reply at jboss.com (neil4374)
Date: Mon, 29 Jan 2007 03:31:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Apache Jackrabbit
Message-ID: <1722032.1170059478389.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hey, Does anybody know why Jacrabbit does not have a visual front end like its rival Days Crx?
Thank you

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007684#4007684

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007684


From do-not-reply at jboss.com  Mon Jan 29 04:57:31 2007
From: do-not-reply at jboss.com (thomas.diesler@jboss.com)
Date: Mon, 29 Jan 2007 04:57:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: wsgen API,
	SPI, command line tool, and ant task
Message-ID: <23972483.1170064651473.JavaMail.jboss@colo-br-02.atl.jboss.com>

Thanks Jason, I'll have a look at it.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007704#4007704

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007704


From do-not-reply at jboss.com  Mon Jan 29 05:40:52 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 29 Jan 2007 05:40:52 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - web console problem
Message-ID: <24145980.1170067252688.JavaMail.jboss@colo-br-02.atl.jboss.com>

hi david,

could you check out this problem ?

when i do a full build of the jpdl suite from head, i can create and deploy a process from the designer.  but when i start a new process instance from this definition, i get the following exception.  Could you have a look asap ?

Also, can i just take HEAD to build the 3.2.Beta2 ? (after this problem is fixed ?)

11:37:18,656 DEBUG [Bind] (Re-)binding org.jbpm.webapp.tag.jbpm.ui.Bind at 1a99295
  | 11:37:18,656 DEBUG [Bind] No request parameter '/common/template.xhtml @60,63 name="tdid": ValueExpression[tdid]' found
  | 11:37:18,656 DEBUG [Bind] In restoreState! org.jbpm.webapp.tag.jbpm.ui.Bind at 1d694da
  | 11:37:18,656 DEBUG [Bind] (Re-)binding org.jbpm.webapp.tag.jbpm.ui.Bind at 1d694da
  | 11:37:18,656 DEBUG [Bind] No request parameter '/common/template.xhtml @61,74 name="piid": ValueExpression[piid]' found
  | 11:37:18,656 DEBUG [Bind] In restoreState! org.jbpm.webapp.tag.jbpm.ui.Bind at c67f69
  | 11:37:18,656 DEBUG [Bind] (Re-)binding org.jbpm.webapp.tag.jbpm.ui.Bind at c67f69
  | 11:37:18,656 DEBUG [Bind] No request parameter '/common/template.xhtml @62,66 name="pdid": ValueExpression[pdid]' found
  | 11:37:18,671 ERROR [STDERR] 29-jan-2007 11:37:18 com.sun.faces.lifecycle.LifecycleImpl phase
  | WARNING: executePhase(RESTORE_VIEW 1,com.sun.faces.context.FacesContextImpl at 54864c) threw exception
  | java.lang.IllegalStateException: org.jbpm.webapp.bean.ProcessBean$1
  |         at javax.faces.component.StateHolderSaver.restore(StateHolderSaver.java:98)
  |         at javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1394)
  |         at javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:1260)
  |         at javax.faces.component.UICommand.restoreState(UICommand.java:332)
  |         at javax.faces.component.html.HtmlCommandLink.restoreState(HtmlCommandLink.java:876)
  |         at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1129)
  |         at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1145)
  |         at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1145)
  |         at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1145)
  |         at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1145)
  |         at org.jbpm.webapp.tag.jbpm.ui.Search.processRestoreState(Search.java:126)
  |         at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1145)
  |         at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1145)
  |         at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:173)
  |         at org.ajax4jsf.framework.ajax.AjaxStateManager.restoreView(AjaxStateManager.java:76)
  |         at com.sun.faces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:290)
  |         at org.jbpm.webapp.application.JbpmViewHandler.restoreView(JbpmViewHandler.java:62)
  |         at com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:317)
  |         at org.ajax4jsf.framework.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:109)
  |         at org.ajax4jsf.framework.ajax.AjaxViewHandler.restoreView(AjaxViewHandler.java:140)
  |         at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:142)
  |         at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
  |         at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
  |         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
  |         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
  |         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  |         at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:75)
  |         at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:213)
  |         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  |         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  |         at org.jbpm.webapp.filter.LogFilter.doFilter(LogFilter.java:59)
  |         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  |         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  |         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
  |         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  |         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  |         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
  |         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
  |         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
  |         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
  |         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
  |         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
  |         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
  |         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
  |         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
  |         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
  |         at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
  |         at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
  |         at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
  |         at java.lang.Thread.run(Thread.java:595)
  | 11:37:18,671 DEBUG [JbpmPhaseListener] After phase RESTORE_VIEW 1
  | 11:37:18,671 DEBUG [AjaxPhaseListener] Process after phase RESTORE_VIEW 1
  | 11:37:18,671 ERROR [[FacesServlet]] Servlet.service() for servlet FacesServlet threw exception
  | java.lang.IllegalStateException: org.jbpm.webapp.bean.ProcessBean$1
  |         at javax.faces.component.StateHolderSaver.restore(StateHolderSaver.java:98)
  |         at javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1394)
  |         at javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:1260)
  |         at javax.faces.component.UICommand.restoreState(UICommand.java:332)
  |         at javax.faces.component.html.HtmlCommandLink.restoreState(HtmlCommandLink.java:876)
  |         at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1129)
  |         at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1145)
  |         at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1145)
  |         at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1145)
  |         at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1145)
  |         at org.jbpm.webapp.tag.jbpm.ui.Search.processRestoreState(Search.java:126)
  |         at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1145)
  |         at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1145)
  |         at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:173)
  |         at org.ajax4jsf.framework.ajax.AjaxStateManager.restoreView(AjaxStateManager.java:76)
  |         at com.sun.faces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:290)
  |         at org.jbpm.webapp.application.JbpmViewHandler.restoreView(JbpmViewHandler.java:62)
  |         at com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:317)
  |         at org.ajax4jsf.framework.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:109)
  |         at org.ajax4jsf.framework.ajax.AjaxViewHandler.restoreView(AjaxViewHandler.java:140)
  |         at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:142)
  |         at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
  |         at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
  |         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
  |         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
  |         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  |         at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:75)
  |         at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:213)
  |         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  |         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  |         at org.jbpm.webapp.filter.LogFilter.doFilter(LogFilter.java:59)
  |         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  |         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  |         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
  |         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  |         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  |         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
  |         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
  |         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
  |         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
  |         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
  |         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
  |         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
  |         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
  |         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
  |         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
  |         at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
  |         at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
  |         at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
  |         at java.lang.Thread.run(Thread.java:595)


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007714#4007714

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007714


From do-not-reply at jboss.com  Mon Jan 29 05:41:16 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 29 Jan 2007 05:41:16 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <10669039.1170067276529.JavaMail.jboss@colo-br-02.atl.jboss.com>

skype me in case you have problems reproducing this.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007715#4007715

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007715


From do-not-reply at jboss.com  Mon Jan 29 05:43:10 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 29 Jan 2007 05:43:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <6082644.1170067390129.JavaMail.jboss@colo-br-02.atl.jboss.com>

another thing is that i added jakarta-io references in the build/base.project.build.xml.   first in the up-to-date check and second in the libs classpath.

please, keep this in mind for next classpath updates.

(yes i know i should document this better :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007716#4007716

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007716


From do-not-reply at jboss.com  Mon Jan 29 06:36:31 2007
From: do-not-reply at jboss.com (twittemb)
Date: Mon, 29 Jan 2007 06:36:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Security on JBoss] - Clustered
	JbossSecurityMgrRealm
Message-ID: <63758.1170070591315.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hello all,

I have a problem with the JBossSecurityMgrRealm local cache (roleMap).

We have developped our own SSO mecanism, and i wonder if the is a clustered version of JBossSecurityMgrRealm that could parse a distributed cache in order to get users roles in the 'hasRole' method. 

I have developped my own clustered JbossSecurityMgrRealm that parse such a distributed cache, but i'm in trouble whith local cache persistence because it is never refreshed when a user disconnect for example.

Do anyone has already face this kind of problem ?

How does the JBoss SSO mechanism deal with the Realm ?

Thanks a lot.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007727#4007727

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007727


From do-not-reply at jboss.com  Mon Jan 29 07:51:13 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Mon, 29 Jan 2007 07:51:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re:
	XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2
Message-ID: <8407236.1170075073828.JavaMail.jboss@colo-br-02.atl.jboss.com>

I was thinking about this over the weekend.

The best way to fix this would be to implement the XAResource wrapper
that we have been talking about for JCA.

We could then check whether the connection is closed in end()
and also reinstate the old behaviour for a failure (i.e. log a warning).

This would also require some form of xid/transaction mapping
which I'm not sure how we do generically - probably some trick
in the tx.enlistResource() call which will callback on our XAResource wrapper
with the XID?

e.g. Something like:

  |       public void end(Xid xid, int flags) throws XAException
  |       {
  |          // Ignore if we are already destroyed
  |          if (cl.getState() == ConnectionListener.DESTROYED)
  |             return;
  |          
  |          try
  |          {
  |             delegate.end(xid, flags);
  |          }
  |          catch (Throwable t)
  |          {
  |             // We log the warning and force a rollback
  |             log.warn("Error ending resource " + cl, t);
  |             try
  |             {
  |             Transaction tx = getTransaction(xid); // ?????
  |                if (TxUtils.isActive(tx))
  |                   tx.setRollbackOnly();
  |             }
  |             catch (Throwable t)
  |             {
  |                log.warn("Unable to setRollbackOnly " + xid, t);
  |             }
  |          }
  |       }
  | 

Similar already destroyed checks would also be possible
in the other calls (e.g. prepare/commit), except there we want to raise an XAException.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007751#4007751

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007751


From do-not-reply at jboss.com  Mon Jan 29 07:55:37 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Mon, 29 Jan 2007 07:55:37 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re:
	XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2
Message-ID: <10777181.1170075337382.JavaMail.jboss@colo-br-02.atl.jboss.com>

Also, prehaps the code would be better always invoking the delegate XAResource
with the end() call, but then only log the warning if we are not already destroyed,
e.g.


  |       public void end(Xid xid, int flags) throws XAException
  |       {
  |          try
  |          {
  |             delegate.end(xid, flags);
  |          }
  |          catch (Throwable t)
  |          {
  |             // We log the warning (UNLESS WE ARE ALREADY DESTROYED) and force a rollback
  |             if (cl.getState() != ConnectionListener.DESTROYED)
  |                log.warn("Error ending resource " + cl, t);
  | ...
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007755#4007755

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007755


From do-not-reply at jboss.com  Mon Jan 29 08:30:36 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Mon, 29 Jan 2007 08:30:36 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Changes to default
	configurations for 4.2/5.0
Message-ID: <14081012.1170077436867.JavaMail.jboss@colo-br-02.atl.jboss.com>

For 4.2 and 5.0 we should change the default JCA configurations
to take advantage of all the features associated with the relevant backend.

The main change should be to enable
<set-tx-query-timeout/>
for all databases.

Other changes should include enable to valid connection checkers
e.g. the Oracle one in oracle-ds.xml

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007777#4007777

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007777


From do-not-reply at jboss.com  Mon Jan 29 08:41:57 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Mon, 29 Jan 2007 08:41:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <13555514.1170078117071.JavaMail.jboss@colo-br-02.atl.jboss.com>

What is the resolution here?

Will 3.2 be released with a compatible version of the GPD, or will the change to use commons-fileupload-1.1.1 be made compatible with 3.0.12?

Also, any further thoughts on the configuration changes described eariler in the thread to allow uploads to work?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007785#4007785

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007785


From do-not-reply at jboss.com  Mon Jan 29 09:35:08 2007
From: do-not-reply at jboss.com (thomas.diesler@jboss.com)
Date: Mon, 29 Jan 2007 09:35:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - jar references
	from jaxb-impl.jar
Message-ID: <3648683.1170081308814.JavaMail.jboss@colo-br-02.atl.jboss.com>

David reports:


  | 2007-01-09 10:15:29,265 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.detectDuplicateNesting=true
  | org.jboss.deployment.DeploymentException: url file:/C:/jboss-4.0.5.GA-ejb3/server/default/deploy/jbossws.sar/activation.jar could not be opened, does it exist?
  | 2007-01-09 10:15:29,281 DEBUG [org.jboss.deployment.MainDeployer] The manifest entry in file:/C:/jboss-4.0.5.GA-ejb3/server/default/deploy/jbossws.sar/jaxb-impl.jar references URL file:/C:/jboss-4.0.5.GA-ejb3/server/default/deploy/jbossws.sar/jsr173_1.0_api.jar which could not be opened, entry ignored rg.jboss.deployment.DeploymentException: url file:/C:/jboss-4.0.5.GA-ejb3/server/default/deploy/jbossws.sar/jsr173_1.0_api.jar could not be opened, does it exist?
  | 2007-01-09 10:15:29,281 DEBUG [org.jboss.deployment.MainDeployer] The manifest entry in file:/C:/jboss-4.0.5.GA-ejb3/server/default/deploy/jbossws.sar/jaxb-impl.jar references URL file:/C:/jboss-4.0.5.GA-ejb3/server/default/deploy/jbossws.sar/jaxb1-impl.jar which could not be opened, entry ignored
  | 
  | org.jboss.deployment.DeploymentException: url file:/C:/jboss-4.0.5.GA-ejb3/server/default/deploy/jbossws.sar/jaxb1-impl.jar could not be opened, does it exist?
  | 

I tracked this down and these jars are referenced in the manifest.mf file within the jaxb-impl.jar file:


  | Class-Path: jaxb-api.jar activation.jar jsr173_1.0_api.jar jaxb1-impl.jar
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007811#4007811

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007811


From do-not-reply at jboss.com  Mon Jan 29 09:37:48 2007
From: do-not-reply at jboss.com (koen.aers@jboss.com)
Date: Mon, 29 Jan 2007 09:37:48 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <27615815.1170081468590.JavaMail.jboss@colo-br-02.atl.jboss.com>

Jeff,

AFAIK, the changes are compatible with the latest 3.0.13 release of the GPD. There still was a small issue at the end of last week, but I saw a post from David mentioning that he fixed it.

Regards,
Koen

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007812#4007812

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007812


From do-not-reply at jboss.com  Mon Jan 29 09:39:04 2007
From: do-not-reply at jboss.com (thomas.diesler@jboss.com)
Date: Mon, 29 Jan 2007 09:39:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: jar
	references from jaxb-impl.jar
Message-ID: <18003928.1170081544645.JavaMail.jboss@colo-br-02.atl.jboss.com>

I would say this debug warnings can be ignored. The activation.jar is the only one that we need (AFAI am aware of) and it is in fact on the classpath when its needed

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007813#4007813

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007813


From do-not-reply at jboss.com  Mon Jan 29 09:43:06 2007
From: do-not-reply at jboss.com (jason.greene@jboss.com)
Date: Mon, 29 Jan 2007 09:43:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: jar
	references from jaxb-impl.jar
Message-ID: <15588864.1170081786291.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes, we provide all of the jars that are refernced here (jsr-173 = StAX). They can for sure be ignored, although we could also remove that classpath entry. from the manifest.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007814#4007814

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007814


From do-not-reply at jboss.com  Mon Jan 29 09:44:10 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 29 Jan 2007 09:44:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <4336146.1170081850637.JavaMail.jboss@colo-br-02.atl.jboss.com>

that one is indeed fixed, but i still have a problem when starting a new process instance

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007816#4007816

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007816


From do-not-reply at jboss.com  Mon Jan 29 10:05:57 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Mon, 29 Jan 2007 10:05:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re:
	XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2
Message-ID: <28817056.1170083157506.JavaMail.jboss@colo-br-02.atl.jboss.com>

Good thoughts all around. The Wrapper already exists, I just need to accomodate this condition. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007828#4007828

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007828


From do-not-reply at jboss.com  Mon Jan 29 10:06:40 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Mon, 29 Jan 2007 10:06:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Changes to
	default configurations for 4.2/5.0
Message-ID: <19436373.1170083200570.JavaMail.jboss@colo-br-02.atl.jboss.com>

Come again? I am not sure what you are referrring to. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007831#4007831

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007831


From do-not-reply at jboss.com  Mon Jan 29 10:09:25 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 29 Jan 2007 10:09:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <20063835.1170083365919.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, I'm checking this out - looking at it I'm suddenly 100% sure that it is because these action listener classes are anonymous inner classes.  I'll do up a quick fix...

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007833#4007833

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007833


From do-not-reply at jboss.com  Mon Jan 29 10:16:39 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Mon, 29 Jan 2007 10:16:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: Changes to
	default configurations for 4.2/5.0
Message-ID: <29507593.1170083799458.JavaMail.jboss@colo-br-02.atl.jboss.com>

Sorry I missed your referring discussion. Got it now.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007842#4007842

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007842


From do-not-reply at jboss.com  Mon Jan 29 10:19:02 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Mon, 29 Jan 2007 10:19:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re:
	XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2
Message-ID: <226974.1170083942042.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | Also, prehaps the code would be better always invoking the delegate XAResource 
  | with the end() call, but then only log the warning if we are not already destroyed, 
  | 

This is effectively what happens now without the exception behavior. In the org.jboss.resource.connectionmanager.xa.JcaXAResourceWrapper, I simply delegate all the XA calls to the underlying XAResource with the exception of the isSameRM which gets overriden depending upon the value in the *-ds.xml file. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007844#4007844

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007844


From do-not-reply at jboss.com  Mon Jan 29 10:23:54 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 29 Jan 2007 10:23:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <22366610.1170084234826.JavaMail.jboss@colo-br-02.atl.jboss.com>

cool.  when your fix is done, try if you can do a full suite build.

look at the jpdl.test.buld target in build/build.xml  that should give you an idea on how to build and test the suite bundle.  you can even use the script.  the exec tasks won't work on linux and you'll have to do those by hand.

let me know how it goes.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007847#4007847

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007847


From do-not-reply at jboss.com  Mon Jan 29 10:25:37 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 29 Jan 2007 10:25:37 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <10694962.1170084337101.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ok, should be fixed now.  Sorry about the library deps problem.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007849#4007849

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007849


From do-not-reply at jboss.com  Mon Jan 29 10:31:27 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 29 Jan 2007 10:31:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Build problem in Linux
Message-ID: <26250857.1170084687963.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm getting the following error when running a plain "ant" from the build/ directory under linux:

BUILD FAILED
  | /home/david/src/jboss/jbpm.3/build/build.xml:55: The following error occurred while executing this line:
  | java.io.FileNotFoundException: /home/david/src/jboss/jbpm.3/jboss/db/build.xml (No such file or directory)


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007852#4007852

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007852


From do-not-reply at jboss.com  Mon Jan 29 10:39:27 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Mon, 29 Jan 2007 10:39:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Build problem in
	Linux
Message-ID: <13684285.1170085167271.JavaMail.jboss@colo-br-02.atl.jboss.com>

STFF :-P

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007575#4007575

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007854#4007854

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007854


From do-not-reply at jboss.com  Mon Jan 29 10:43:11 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 29 Jan 2007 10:43:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <8994925.1170085391974.JavaMail.jboss@colo-br-02.atl.jboss.com>

the initial problem is resolved.

now i found a new problem: i created a minimal process with a start task with 2 variables, a and b.  then, i first pressed save in the task form that was presented after creation of the process instance.  then i pressed the end task task button and this jbpm console error message (not a stacktrace) appeared : 
anonymous wrote : 
  | 	Error	
  | Show detailsError taking transition: task node does not have leaving transition 'End Task'

please build the suite and make a few processes, deploy and test them in the console.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007856#4007856

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007856


From do-not-reply at jboss.com  Mon Jan 29 10:45:35 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 29 Jan 2007 10:45:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <5324636.1170085535918.JavaMail.jboss@colo-br-02.atl.jboss.com>

also it appears that the console has become very slow.  do you see the same ?  do you think the cause is the navigation layout and increased page contents ?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007857#4007857

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007857


From do-not-reply at jboss.com  Mon Jan 29 10:48:15 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 29 Jan 2007 10:48:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Build problem in
	Linux
Message-ID: <1801505.1170085695350.JavaMail.jboss@colo-br-02.atl.jboss.com>

give more of the logs/stacktrace.

i had a similar problem today.  if it is the ant.task.properties or something like that, you just need to retry.  i don't know why it sometimes fails.  all help with that is appreciated.

previously i thought that problem was because the jpdl library was not build before ant scans the classpath.  with the new build scripts that problem should be fixed and i still got that error this morning...  so i'm a bit clueless there.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007859#4007859

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007859


From do-not-reply at jboss.com  Mon Jan 29 10:53:13 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Mon, 29 Jan 2007 10:53:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <20475508.1170085993832.JavaMail.jboss@colo-br-02.atl.jboss.com>

Brian,

Nested SFSBs have to share the same lifecycle as their parents.  They also have to share the same Extended Persistence Contexts the reference!

Another thought I had was to actually store the Nested Bean's instance inide of its proxy and propagate it to the Nested Bean's EJB container via the invocation object.  If the invocation object had the actual bean instance already set, then the EJB container would not look in the cache.

I don't remember why I didn't do this....Maybe I didn't think of it at first?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007860#4007860

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007860


From do-not-reply at jboss.com  Mon Jan 29 11:11:30 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 29 Jan 2007 11:11:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <28068874.1170087090862.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : the initial problem is resolved.
  | 
  | now i found a new problem: i created a minimal process with a start task with 2 variables, a and b.  then, i first pressed save in the task form that was presented after creation of the process instance.  then i pressed the end task task button and this jbpm console error message (not a stacktrace) appeared : 
  | anonymous wrote : 
  |   | 	Error	
  |   | Show detailsError taking transition: task node does not have leaving transition 'End Task'
  | 
  | please build the suite and make a few processes, deploy and test them in the console.

This happens when you have a transition button that uses a to="" attribute that does not match the name of any actual trasition in the process definition.  Older versions of the websale example had this problem.  The latest one in CVS works for me.

If you have only one exiting transition, don't specify a destination transition and the default one should be taken.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007867#4007867

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007867


From do-not-reply at jboss.com  Mon Jan 29 11:12:44 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 29 Jan 2007 11:12:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <6836557.1170087164260.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : also it appears that the console has become very slow.  do you see the same ?  do you think the cause is the navigation layout and increased page contents ?

My laptop is pretty fast so I didn't notice anything too slow.  But I think I'm going to run the console with a profiler just to see if there are any bits that can be optimized.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007869#4007869

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007869


From do-not-reply at jboss.com  Mon Jan 29 11:29:33 2007
From: do-not-reply at jboss.com (prabhat.jha@jboss.com)
Date: Mon, 29 Jan 2007 11:29:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: DB test matrix
Message-ID: <1404341.1170088173774.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have corrected sqlserver connection problem and modified mysql5 URL. Tonight's portal DB run should pick it up.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007876#4007876

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007876


From do-not-reply at jboss.com  Mon Jan 29 11:35:30 2007
From: do-not-reply at jboss.com (bazoo)
Date: Mon, 29 Jan 2007 11:35:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <346619.1170088530338.JavaMail.jboss@colo-br-02.atl.jboss.com>

If you use the Designer to build a transition from one node to another it creates an unnamed transition with an attribute of to="" which is by default filled out with the name of the node the transition is pointing to. It seems a bit strange to then force the user to then go in and delete the to="" attribute? Anyway, wouldn't that mean that the transition doesn't actually go anywhere?

Shouldn't it look up the transition name="" attribute instead? 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007883#4007883

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007883


From do-not-reply at jboss.com  Mon Jan 29 11:48:42 2007
From: do-not-reply at jboss.com (alesj)
Date: Mon, 29 Jan 2007 11:48:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Property replacement
Message-ID: <26263613.1170089322067.JavaMail.jboss@colo-br-02.atl.jboss.com>

"scott.stark at jboss.org" wrote : 
  | I guess, but I don't see this as a natural usage. A check of the replace attribute would be needed.
  | 

I agree.
How can we move this in the same way as we did it with StringValueMD?
But with this one is different - it's a plain String value with possible replacement.
Own TypeInfo --> StringInfo (similar to NumberInfo)?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007887#4007887

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007887


From do-not-reply at jboss.com  Mon Jan 29 12:03:21 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 29 Jan 2007 12:03:21 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <4725735.1170090201395.JavaMail.jboss@colo-br-02.atl.jboss.com>

I agree this is a problem.  The current logic of the transition button is that if the attribute is not there, or if its value is "default", then the default transition will be taken.  A value of "" will translate into a lookup for a transition named ""... this is not really optimal.

Koen, is it possible to modify the GPD so that if there is only one transition, that the "to" attribute is not emitted?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007897#4007897

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007897


From do-not-reply at jboss.com  Mon Jan 29 12:31:38 2007
From: do-not-reply at jboss.com (paolodt)
Date: Mon, 29 Jan 2007 12:31:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Process definition
	element label attribute
Message-ID: <27031460.1170091898550.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm a new to jBPM and it seems to be a great tool.

One of the most interesting feature is the Graphical Process Designer that permits to design and show a "business" view of the process workflow.

Anyway I think would be very useful to have "label" attribute as well as the "name" attribute for each process definition element (nodes, tasks, transitions, .. ).

In this way it would be possible to have a displayable name showed in the jBPM designer (for the business users / analysts interested to the graphical model diagram) and a element name to use as identifier in the application / workflow coding.


What do you think? Any plan to support that?

Thanks a lot, Paolo

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007907#4007907

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007907


From do-not-reply at jboss.com  Mon Jan 29 12:34:33 2007
From: do-not-reply at jboss.com (prabhat.jha@jboss.com)
Date: Mon, 29 Jan 2007 12:34:33 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: DB test matrix
Message-ID: <10171259.1170092073613.JavaMail.jboss@colo-br-02.atl.jboss.com>

Nuked mysql4 tables to see if that takes care of "object already exists" error.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007909#4007909

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007909


From do-not-reply at jboss.com  Mon Jan 29 12:43:07 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Mon, 29 Jan 2007 12:43:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Process definition
	element label attribute
Message-ID: <6888088.1170092587525.JavaMail.jboss@colo-br-02.atl.jboss.com>

There already is a description element which could be used for this if not filled in to 'prosaic'. Displaying it in the GPD is another story

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007913#4007913

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007913


From do-not-reply at jboss.com  Mon Jan 29 13:32:53 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Mon, 29 Jan 2007 13:32:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <24685360.1170095573237.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bill.burke at jboss.com" wrote : 
  | Nested SFSBs have to share the same lifecycle as their parents.  They also have to share the same Extended Persistence Contexts the reference!

OK, good; that's a clear rule that makes deciding how to handle everything else simpler. :)

This is broken if the nested SFSB declares @Remote. This test fails:


  | ParentStatefulRemote stateful = (ParentStatefulRemote) ctx.lookup("testParentStateful/remote");
  |       
  | assertEquals("Counter: ", 1, stateful.increment());
  |       
  | NestedStateful nested = stateful.getNested();
  |       
  | stateful.remove();
  |       
  | // Confirm nested no longer works following parent remove
  | try
  | {
  |    nested.increment();
  |    fail("Nested bean still exists following destruction of parent");
  | }
  | catch (Exception good)  
  | {
  |    // this is what we want -- nested has no independent lifecycle
  | }
  | 

I'll open a JIRA for this. Hopefully one of you guys can figure it out. I've been digging around trying to understand what's going on.  For some reason, if the nested bean declares @Remote, when a StatefulCache calls Pool.get(), it gets back a standard StatefulBeanContext rather ProxiedStatefulBeanContext.  This has to be a function of how calls are nested (i.e. the nested bean gets created *before* the parent, thus the parent hasn't been pushed onto the ThreadLocalStack when the nested bean is created.) 

As for the initial issue of the ProxiedStatefulBeanContext not being removed from the cache when it's parent is, I think I found that -- it was a bug in StatefulTreeCache.

anonymous wrote : Another thought I had was to actually store the Nested Bean's instance inide of its proxy and propagate it to the Nested Bean's EJB container via the invocation object.  If the invocation object had the actual bean instance already set, then the EJB container would not look in the cache.
  | 
  | I don't remember why I didn't do this....Maybe I didn't think of it at first?

Was this thought sparked by my last post re: replicating the proxy? That is, if we store the bean instance in the proxy and replicate it, that solves the issue?

If so, I think the reason you didn't do it that way was because you wanted the nested beans to always be serialized as a unit with the parent. Otherwise after deserialization you no longer have shared refs to things like ExtendedPersistenceContext.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007942#4007942

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007942


From do-not-reply at jboss.com  Mon Jan 29 13:53:43 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Mon, 29 Jan 2007 13:53:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <20303202.1170096823886.JavaMail.jboss@colo-br-02.atl.jboss.com>

JIRA for broken lifecycle dependency is http://jira.jboss.com/jira/browse/EJBTHREE-854 .

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007945#4007945

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007945


From do-not-reply at jboss.com  Mon Jan 29 14:06:58 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Mon, 29 Jan 2007 14:06:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <25616664.1170097618775.JavaMail.jboss@colo-br-02.atl.jboss.com>

@Remote beans are not supposed to be nested.  They are separate because they may be located in another server (@Remote).

Ok, i got you on the shared refs...I'll put some thought into it.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007953#4007953

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007953


From do-not-reply at jboss.com  Mon Jan 29 14:08:53 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 29 Jan 2007 14:08:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <20375336.1170097733524.JavaMail.jboss@colo-br-02.atl.jboss.com>

"david.lloyd at jboss.com" wrote : "tom.baeyens at jboss.com" wrote : also it appears that the console has become very slow.  do you see the same ?  do you think the cause is the navigation layout and increased page contents ?
  | 
  | My laptop is pretty fast so I didn't notice anything too slow.  But I think I'm going to run the console with a profiler just to see if there are any bits that can be optimized.

then this will probably be something else on my system.  i'll try again tomorrow.  before the navigation rework, it took approx .5 second for a page to show.  now it was approx 7-10 seconds.  if you don't have this problem, it will be something local.  i'll figure it out first.

profiling should not be necessary at this point.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007954#4007954

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007954


From do-not-reply at jboss.com  Mon Jan 29 14:14:31 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 29 Jan 2007 14:14:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <3389297.1170098071310.JavaMail.jboss@colo-br-02.atl.jboss.com>

"david.lloyd at jboss.com" wrote : I agree this is a problem.  The current logic of the transition button is that if the attribute is not there, or if its value is "default", then the default transition will be taken.  A value of "" will translate into a lookup for a transition named ""... this is not really optimal.
  | 
  | Koen, is it possible to modify the GPD so that if there is only one transition, that the "to" attribute is not emitted?
  | 

i don't quite get the point you're trying to make.  'to' is a required attribute on the transition.  only the name is optional.  it should be unique in case there are multiple leaving transitions.

afaik, the designer already left out the name in case there is only 1.  but in case the designer should put in name="", that should work as well.

mayeb the problem is in the forms.xml generation...

if you want to reproduce this, just build the suite from head and create a simple new process with a start state and 1 task node.  add a task to the start state.  generate a minimal form for it,  deploy the process, start it and end the start task.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007955#4007955

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007955


From do-not-reply at jboss.com  Mon Jan 29 14:17:53 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 29 Jan 2007 14:17:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Process definition
	element label attribute
Message-ID: <18461468.1170098273345.JavaMail.jboss@colo-br-02.atl.jboss.com>

this might actually make sense.  currently, we use the name field for display, but that is also used as an id field.

the important thing is that the current approach of combining is and label in the 'name' attribute should be kept.  but coming to think of it, nothing keeps us from adding a label attribute that is optional.  the label returns the label or the name in case there is no specific label specified...

let me think some more.  i think this might be a good idea.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007958#4007958

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007958


From do-not-reply at jboss.com  Mon Jan 29 14:20:16 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 29 Jan 2007 14:20:16 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Web console changes -
	IMPORTANT
Message-ID: <21627414.1170098416977.JavaMail.jboss@colo-br-02.atl.jboss.com>

I profiled the web console performance and found that the #1 bottleneck, at least on the first run, was the ajax4jsf library.  Since the last navigation restructure removed all the ajax features anyway, I went ahead and removed this library, and performance seems to be greatly improved... however I discovered a fairly catastrophic side-effect of this change.

It turns out that ajax4jsf uses the Tidy parser to quietly "clean up" mistakes in the generated XHTML.  One side-effect of this is that including a file that includes a <!DOCTYPE> header, or any html tags that are not valid within the body of an html document, causes strict XHTML parsing to break on client web browsers.  This is an important revelation because we cannot always assume that the end-user is using ajax4jsf.

Because of this, it is very important that the GPD be updated to output task forms without any containing <!DOCTYPE> or  tags.  I've updated the websale example to show how the task forms should look.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007959#4007959

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007959


From do-not-reply at jboss.com  Mon Jan 29 14:20:19 2007
From: do-not-reply at jboss.com (wolfc)
Date: Mon, 29 Jan 2007 14:20:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <2348562.1170098419075.JavaMail.jboss@colo-br-02.atl.jboss.com>

I don't get the EJBTHREE-854.

The nested.increment() is supposed to work properly because it's just another SLSB. Okay so it was created by another SLSB, so what.

Why should any SLSB have a dependant lifecycle?
(What goes for @Remote can also go for @Local, if someone returns the SLSB to a servlet for example, which puts it in the HttpSession.)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007960#4007960

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007960


From do-not-reply at jboss.com  Mon Jan 29 14:24:00 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 29 Jan 2007 14:24:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <1006863.1170098640687.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : i don't quite get the point you're trying to make.  'to' is a required attribute on the transition.  only the name is optional.  it should be unique in case there are multiple leaving transitions.

I'm not talking about the process definition, I'm talking about the task form buttons (the actual XHTML being produced).  Sorry if I was unclear.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007961#4007961

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007961


From do-not-reply at jboss.com  Mon Jan 29 14:27:36 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 29 Jan 2007 14:27:36 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <2492636.1170098856351.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : then this will probably be something else on my system.  i'll try again tomorrow.  before the navigation rework, it took approx .5 second for a page to show.  now it was approx 7-10 seconds.  if you don't have this problem, it will be something local.  i'll figure it out first.
  | 
  | profiling should not be necessary at this point.

It actually is a symptom of a very serious issue - see my new forum topic for details.  Short version is, ajax4jsf did it so I ripped it out.  It uncovered a few bugs that were hidden.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007962#4007962

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007962


From do-not-reply at jboss.com  Mon Jan 29 14:57:26 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Mon, 29 Jan 2007 14:57:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Web console changes
	- IMPORTANT
Message-ID: <23532471.1170100646715.JavaMail.jboss@colo-br-02.atl.jboss.com>

task forms are included through facelets.

i thought facelets rips out the doctype and everything else except what is in the body tag. 

this is how i did it before.  i didn't use ajax so i don't think there was any hidden tidying going on.

i don't think that the GPD should solve this by removing the doctype declarations from the forms generation



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007969#4007969

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007969


From do-not-reply at jboss.com  Mon Jan 29 15:20:50 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Mon, 29 Jan 2007 15:20:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <559606.1170102050837.JavaMail.jboss@colo-br-02.atl.jboss.com>

OK, if the @Remote case is supposed to work, EJBTHREE-854 should be closed as Rejected. This weekend I originally wrote the unit test the opposite way, to assert that the nested.increment() call worked; got ahead of myself and changed it this morning.

Carlo, I agree with you about @Local; that kind of case is what prompted my initial confusion about spec behavior.  If the nested bean has a dependent lifecycle, it's very difficult use normal pojo programming with a SFSB.

If the nested bean doesn't have a dependent lifecycle, we need to come up with another approach to maintaining shared refs to the XPC.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007979#4007979

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007979


From do-not-reply at jboss.com  Mon Jan 29 15:24:29 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 29 Jan 2007 15:24:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Web console changes
	- IMPORTANT
Message-ID: <16091891.1170102269546.JavaMail.jboss@colo-br-02.atl.jboss.com>

Facelets does not do this.  It passes the xhtml on verbatim.  Some web browsers will accept this, but firefox 2.0 will give you an XML validation error.  IE just ignores those elements I think (IE does not have xhtml support so it just treats it like HTML 4.01).

The task form generation uses the facelets include mechanism just like it did before.

By using the proper root element and not relying on filtering, it guarantees the best compatibility for user applications.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007982#4007982

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007982


From do-not-reply at jboss.com  Mon Jan 29 15:45:07 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Mon, 29 Jan 2007 15:45:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <10870351.1170103507198.JavaMail.jboss@colo-br-02.atl.jboss.com>

again, nested bean shares lifecycle if it is injected as a @Local reference.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007989#4007989

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007989


From do-not-reply at jboss.com  Mon Jan 29 16:06:19 2007
From: do-not-reply at jboss.com (wolfc)
Date: Mon, 29 Jan 2007 16:06:19 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <11614420.1170104779358.JavaMail.jboss@colo-br-02.atl.jboss.com>

Again, why share life cycle?

What is supposed to happen in the following scenario:

SFSB A:
@EJB B beanB;
  | getB() { return B };

SFSB C:
B ref;
  | void setB(A beanA) { ref = beanA.getB(); }
  | void incrementB(B beanB) { ref.increment(); }

Client:
@EJB A beanA;
  | @EJB C beanC;
  | void iAmDoingSomething() { 
  |   beanC.setB(beanA); 
  |   beanA.remove();
  |   beanC.incrementB();
  | }

I think it should work. So each SFSB has an independent life cycle.
(I still don't see the problem why they can't have an independent life cycle.)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007997#4007997

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007997


From do-not-reply at jboss.com  Mon Jan 29 16:24:56 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Mon, 29 Jan 2007 16:24:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <650302.1170105896109.JavaMail.jboss@colo-br-02.atl.jboss.com>

The issue is maintaining shared references to an XPC between the parent and the children across serialization/deserialization (i.e. passivation/activation or replication).  This was done by storing the nested bean contexts inside a collection in the parent bean context and only serializing/deserializing the whole thing as a unit.  This data structure implies a common lifecycle.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008003#4008003

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008003


From do-not-reply at jboss.com  Mon Jan 29 16:31:00 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Mon, 29 Jan 2007 16:31:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Web console changes
	- IMPORTANT
Message-ID: <5011818.1170106260311.JavaMail.jboss@colo-br-02.atl.jboss.com>

I use doctype in all my seam pages and have no problems (FF1.5, 2.0, IE6). My seam apps use myfaces, so maybe it is a JSF-RI issue of not ripping out the doctypes. So Toms' observation is correct (since he also used myfaces)

If I do not have doctypes in my pages, my eclipse plugin (exadel) cannot validate the pages, so I definately want the docstypes in.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008006#4008006

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008006


From do-not-reply at jboss.com  Mon Jan 29 16:41:55 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Mon, 29 Jan 2007 16:41:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <11816437.1170106915503.JavaMail.jboss@colo-br-02.atl.jboss.com>

I swear that the nested @Local SFSB shared the same lifecycle as its parent, but I cannot find it in the spec.  I distinctly remember talking about it in the expert group.

IMO, because of managed entities and extended PCs, we should implement the behavior this way, otherwise, it becomes impossible to reallign the object references.

Ineed to reread and rethink the problem based on Brian's clustering problems...

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008012#4008012

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008012


From do-not-reply at jboss.com  Mon Jan 29 16:42:01 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Mon, 29 Jan 2007 16:42:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Web console changes
	- IMPORTANT
Message-ID: <1076143.1170106921176.JavaMail.jboss@colo-br-02.atl.jboss.com>

"kukeltje" wrote : I use doctype in all my seam pages and have no problems (FF1.5, 2.0, IE6). My seam apps use myfaces, so maybe it is a JSF-RI issue of not ripping out the doctypes. So Toms' observation is correct (since he also used myfaces)
  | 
  | If I do not have doctypes in my pages, my eclipse plugin (exadel) cannot validate the pages, so I definately want the docstypes in.

Well if the difference is between being broken for everyone using the RI, and not having eclipse be able to validate the XML, I'd rather break eclipse.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008013#4008013

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008013


From do-not-reply at jboss.com  Mon Jan 29 16:50:38 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Mon, 29 Jan 2007 16:50:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <12378128.1170107438689.JavaMail.jboss@colo-br-02.atl.jboss.com>

Brian....so, if we attach the lifecycle of the child nested bean to that of its parent, will there be no problems?

Another thing we could do is if the parent is removed, we can replace the Proxied with the real thing.

It seems to me though that if you don't tie the lifecycle of the child to the parent, then if this usebase becomes prevalent, there could could quite possibly be orphaned beans.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008020#4008020

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008020


From do-not-reply at jboss.com  Mon Jan 29 17:01:31 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Mon, 29 Jan 2007 17:01:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Web console changes
	- IMPORTANT
Message-ID: <8551817.1170108091859.JavaMail.jboss@colo-br-02.atl.jboss.com>

sorry, that was not what I meant. I agree with you, but would like to be sure there is no other solution to this... I'm searching on google now to see if it is realy the RI or maybe something else. Stay tuned

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008025#4008025

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008025


From do-not-reply at jboss.com  Mon Jan 29 17:07:42 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Mon, 29 Jan 2007 17:07:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <21395780.1170108462589.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bill.burke at jboss.com" wrote : Brian....so, if we attach the lifecycle of the child nested bean to that of its parent, will there be no problems?

I believe the initial problem that led to this thread (orphaned ProxiedStatefulBeanContext left in cache) was a bug in StatefulTreeCache that can be easily fixed (StatefulTreeCache.remove() wasn't calling Pool.remove() when it should, preventing cleanup of the nested beans.)

The issue of when to replicate still remains. If we follow Carlo's example where a ref to the nested bean is handed to another in-VM client, if that client causes replication, only the proxy is replicated.  If instead, the cache finds the  ultimate parent bean and replicates that, then there is the potential problem of the parent getting replicated multiple times as it invokes methods on its children.

OK - I see the solution to that. Put a ThreadLocalStack in StatefulReplicationInterceptor; push and pop as the invocation proceeds; on the return side only replicate when the stack is empty.  Similar to what the web session repl code does with cross-context requests.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008032#4008032

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008032


From do-not-reply at jboss.com  Mon Jan 29 17:43:03 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Mon, 29 Jan 2007 17:43:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Process definition
	element label attribute
Message-ID: <21298413.1170110583506.JavaMail.jboss@colo-br-02.atl.jboss.com>

Come on Tom.... Now I do not get you anymore... you opposed the addition of the variable type to the jdpl file so strongly and now in addition to a name, a mappedname and a description, a new label is added? Then please include the variable type as well, and now I come to think of it, why not include the coordinates as well (like xpdl) 

The name is to be unique (like an id) is, on transitions used, for reference (like an idref) why not ditch the name/to then and realy use an ID and idref? the xsd standard can make sure these constraints are automatically met (a refid should point to an existing id, id's should be unique etc..etc..etc..ebBP uses this) Sorry if I sound a little frustrated (two STFF posts in 10 minutes) but I do mean what I say

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008048#4008048

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008048


From do-not-reply at jboss.com  Mon Jan 29 18:54:04 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Mon, 29 Jan 2007 18:54:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Failover possible dead lock
Message-ID: <11815915.1170114844301.JavaMail.jboss@colo-br-02.atl.jboss.com>

I found a possible dead lock on Failover / valves.

This is the scenario:


One Connection

Two Threads
 .. Thread1 is called Consumer
 .. Thread2 is called Producer

(Each thread will have its own session, of course)


The Consumer thread will do:

  
  | 
  |  while (true)
  |  {
  |     Message message = consumer.receive();
    System.out.println("Message = " + message);
 }




While the Producer will do

  | while(true)
  | {
  |    producer.send(session.createTextMessage("Message from producer " + id + " counter=" + (counter)));
  | }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008072#4008072

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008072


From do-not-reply at jboss.com  Mon Jan 29 19:02:32 2007
From: do-not-reply at jboss.com (timfox)
Date: Mon, 29 Jan 2007 19:02:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover possible dead lock
Message-ID: <20928757.1170115352955.JavaMail.jboss@colo-br-02.atl.jboss.com>

I don't think this is a deadlock - deadlock implies a race for two exclusive locks:

thread 1 gets lock on resource A.

thread 2 gets lock on resource B

thread 1 tries to get lock on resource B and blocks

thread 2 tries to get lock on resource A and blocks

However, it's still an issue.

Can't you interrupt the receive thread, to cause it to return?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008076#4008076

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008076


From do-not-reply at jboss.com  Mon Jan 29 19:04:50 2007
From: do-not-reply at jboss.com (timfox)
Date: Mon, 29 Jan 2007 19:04:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover possible dead lock
Message-ID: <8850104.1170115490302.JavaMail.jboss@colo-br-02.atl.jboss.com>

So... when the producer detects the failover it (eventually) calls all the message callback handlers interruptReceiveThread() method, which calls interrupt() on the receive thread.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008077#4008077

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008077


From do-not-reply at jboss.com  Mon Jan 29 19:21:12 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Mon, 29 Jan 2007 19:21:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover possible dead lock
Message-ID: <14969859.1170116472897.JavaMail.jboss@colo-br-02.atl.jboss.com>

"Tim Fox" wrote : I don't think this is a deadlock - deadlock implies a race for two exclusive locks: 

Well.. I know technical name wouldn't be dead lock...

But you will still be waiting forever on a writeLock, that will never occur. (you're dead anyway :-) )


I guess I could call Failover to notify the receive thread.. yes...  but I just don't think it would be a good solution. The way it works now, we only start failure detection after we close the valve. We can't close the valve if there is an invocation pending.

I would prefer using the Valve only on places where a server communication is needed.  On that case we don't have a problem as we will aways get an IOException or a CannotConnectException when the server dies.

A receive is only waiting on an internal buffer and I don't see any problems on letting it wait Callback to be re-established and feed the buffer again after failover.

I have talked to Ovidiu by IM, and he thinks it would make sense to use the Valve only on places where an IO to the server is being performed.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008084#4008084

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008084


From do-not-reply at jboss.com  Mon Jan 29 20:10:53 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Mon, 29 Jan 2007 20:10:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Property replacement
Message-ID: <27088287.1170119453843.JavaMail.jboss@colo-br-02.atl.jboss.com>

In terms of the current schema, its just a different type of element that would need to be treated separately as the AnnotationMetaData does not have a natural string representation outside of the annotation attribute values.  We would have to make this a richer type of element with more of a javabean type of property/value structure, but the allowed values are more restricted.

There already is an AnnotationInfo. Doesn't the inherrited TypeInfo.convertValue(Object value, boolean replaceProperties) come into play? 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008095#4008095

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008095


From do-not-reply at jboss.com  Mon Jan 29 20:22:12 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Mon, 29 Jan 2007 20:22:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Failover possible dead lock
Message-ID: <31255891.1170120132782.JavaMail.jboss@colo-br-02.atl.jboss.com>

http://jira.jboss.org/jira/browse/JBMESSAGING-790

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008097#4008097

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008097


From do-not-reply at jboss.com  Mon Jan 29 20:51:59 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Mon, 29 Jan 2007 20:51:59 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - JBCACHE-957 Discussion
	Thread
Message-ID: <4898861.1170121919694.JavaMail.jboss@colo-br-02.atl.jboss.com>

Discussions related to http://jira.jboss.com/jira/browse/JBCACHE-957 -- Allow per-node configuration of LockParentForChildInsertRemove.

Elias Ross had a good suggestion on this:

anonymous wrote : 
  | The Node itself keeps a NodeLock instance.  Perhaps the specific choice of lock (read-write) could be delegated to the NodeLock itself?
  | 
  | In particular, for the method:
  |  
  | boolean acquire(Object caller, long timeout, NodeLock.LockType lock_type);
  |  
  | it might make sense to replace the LockType parameter with an operation parameter?  E.g.
  |  
  | boolean acquire(Object caller, long timeout, NodeLock.Operation op);
  |  
  | Then there needs to be some way to set the particular strategy per node. It's theoretically possible, but there needs to be a standard API to expose this.  E.g.
  | 
  | void setLockStrategy( ... );
  |  
  | With this in mind, the NodeLock interface should get revisited in time for 2.0.
  | 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008104#4008104

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008104


From do-not-reply at jboss.com  Mon Jan 29 22:03:44 2007
From: do-not-reply at jboss.com (jeffdelong)
Date: Mon, 29 Jan 2007 22:03:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Can't deploy
	processdefinition from GPD into jBPM 3.2 -
Message-ID: <6342183.1170126224972.JavaMail.jboss@colo-br-02.atl.jboss.com>

Koen,

Thanks, I will test this combo out.

Jeff

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008114#4008114

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008114


From do-not-reply at jboss.com  Mon Jan 29 22:57:13 2007
From: do-not-reply at jboss.com (kurt.stam@jboss.com)
Date: Mon, 29 Jan 2007 22:57:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss ESB] - Two more ESB packaging
	options.
Message-ID: <19943586.1170129433708.JavaMail.jboss@colo-br-02.atl.jboss.com>

In the product/install directory on the trunk we now have two more packaging options. Besides deploying to JBossAS, you can now create a standalone launcher or deploy as a war to tomcat. I'd love if people could give this a spin and provide some feedback.

For standalone launching read the README in install/launcher, for deploying to tomcat read the README in install/tomcat.

Thanks!

--Kurt

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008119#4008119

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008119


From do-not-reply at jboss.com  Tue Jan 30 01:39:13 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Tue, 30 Jan 2007 01:39:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - TxInterceptor logging
	of exceptions
Message-ID: <5080018.1170139153269.JavaMail.jboss@colo-br-02.atl.jboss.com>

TxInterceptor catches all exceptions that come up from lower in the interceptor chain, logs them at INFO, and then rethrows the exception if there isn't a failSilently option set.

1) Why log at all if the exception is going to be rethrown? The log doesn't indicate any action on the part of the interceptor. Eviction now uses a 0 ms timeout, so a lot of those timeouts could end up getting logged.

2) If failSilently is set, a stack trace in the log at INFO doesn't seem very silent. People freak at stack traces no matter what level. At a minimum I think any INFO logging should be just the message, with a stack trace only at DEBUG or TRACE.  But with Hibernate's usage, I think these are going to be too frequent for INFO.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008144#4008144

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008144


From do-not-reply at jboss.com  Tue Jan 30 03:13:58 2007
From: do-not-reply at jboss.com (koen.aers@jboss.com)
Date: Tue, 30 Jan 2007 03:13:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <22971216.1170144838057.JavaMail.jboss@colo-br-02.atl.jboss.com>

"david.lloyd at jboss.com" wrote : Koen, is it possible to modify the GPD so that if there is only one transition, that the "to" attribute is not emitted?
  | 
As Tom stated, this has nothing to do with the 'to' attribute of the transition which is a mandatory attribute. I will revisit the task form generation shortly. I assume you guys want the following:
- if there is no name on the transition, do nothing
- if there is a name, use the name
- offer the possibility to override in both cases
Is this correct?

Regards,
Koen

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008157#4008157

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008157


From do-not-reply at jboss.com  Tue Jan 30 03:38:54 2007
From: do-not-reply at jboss.com (wolfc)
Date: Tue, 30 Jan 2007 03:38:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <22663006.1170146334906.JavaMail.jboss@colo-br-02.atl.jboss.com>

I say we should not attach lifecycle from one SFSB to another. You don't know where a reference ends up and I can always come up with a scenario in which it breaks (we haven't even covered handles yet).

The bean developer should be responsible for both parent and child lifecycle. We can always have orphaned SFSB, because that's the nature of the beast.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008165#4008165

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008165


From do-not-reply at jboss.com  Tue Jan 30 04:00:42 2007
From: do-not-reply at jboss.com (heiko.braun@jboss.com)
Date: Tue, 30 Jan 2007 04:00:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - RI tools
	dependency
Message-ID: <848593.1170147642076.JavaMail.jboss@colo-br-02.atl.jboss.com>

I introduced a dependency on the RI tools in order to create the interop artifacts. The main reasons for this are: 

- We need to be more flexible when facing the next plug-fest
- Having a pluggable tools layer within the test suite means that we can easily verify our own JAX-WS tools codebase at some later point in time
- We do verify that our stack really works with the JAX-WS artifacts that the RI tools generate 

Currently this requires a now build property to be set


  | #
  | # JAX-WS Home
  | # The testsuite requires the RI tools to generate the artifacts
  | # NOTE: Don't use the JWSDP 2.0, it contains legacy API.
  | # Use the RI codebase from java.net instead:
  | # https://jax-ws.dev.java.net/jax-ws-20-fcs/ 
  | # 
  | ri.home=/home/hbraun/dev/env/jaxws-ri_2.0
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008171#4008171

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008171


From do-not-reply at jboss.com  Tue Jan 30 04:04:26 2007
From: do-not-reply at jboss.com (heiko.braun@jboss.com)
Date: Tue, 30 Jan 2007 04:04:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: RI tools
	dependency
Message-ID: <22453114.1170147866434.JavaMail.jboss@colo-br-02.atl.jboss.com>

In order to plugin a different tools layer it is necessary to implement an ant macro that will be used to invoke the tools codebase. See 

 
  | jbossws-test/ant-import/jaxws-tools-delegate.xml
  | 

for an example.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008172#4008172

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008172


From do-not-reply at jboss.com  Tue Jan 30 04:05:59 2007
From: do-not-reply at jboss.com (paolodt)
Date: Tue, 30 Jan 2007 04:05:59 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Process definition
	element label attribute
Message-ID: <12186415.1170147959225.JavaMail.jboss@colo-br-02.atl.jboss.com>

Nice Tom,

I was thinking exactly the mechanism you have described.

The descriptive label should be optional if not provided it would return the name value.

In this way it would be possible to have a more flexible process model presentation view, not tied to the elements name that should never change being identifiers used in the workflow application code.

In which version do you think it could be released?

Thanks, Paolo



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008173#4008173

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008173


From do-not-reply at jboss.com  Tue Jan 30 04:43:09 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 30 Jan 2007 04:43:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Web console changes
	- IMPORTANT
Message-ID: <22017530.1170150189110.JavaMail.jboss@colo-br-02.atl.jboss.com>

"david.lloyd at jboss.com" wrote : The task form generation uses the facelets include mechanism just like it did before.

Are you sure ?

I can remember that I struggled with that problem as well.  Also I remember about facelets docs mentioning that only content inside the body tag was included.  I don't remember how I actually solved it.  Afaik, I already checked with firefox at the time, but I'm not sure of that.

Did you have a look at facelets composition, fragment, include and insert ?

Preferrably, we should have it working with the DOCTYPE's included in the forms.  But if that is not possible, we should change the designer.  Please, let Koen know asap wether or not you can get the desired behaviour out of facelets.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008197#4008197

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008197


From do-not-reply at jboss.com  Tue Jan 30 04:48:12 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Tue, 30 Jan 2007 04:48:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Web console changes
	- IMPORTANT
Message-ID: <569916.1170150492747.JavaMail.jboss@colo-br-02.atl.jboss.com>

I could not find any references of problems with this in the RI and just looked at the seam templates for seam-gen. This also generates the doctype but that uses myfaces.... so I realy think it has something to do with the RI. Maybe we should post something there and remove it (temporarily for now)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008201#4008201

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008201


From do-not-reply at jboss.com  Tue Jan 30 05:43:13 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Tue, 30 Jan 2007 05:43:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Process definition
	element label attribute
Message-ID: <18294742.1170153793121.JavaMail.jboss@colo-br-02.atl.jboss.com>

"kukeltje" wrote : Come on Tom.... Now I do not get you anymore... you opposed the addition of the variable type to the jdpl file so strongly and now in addition to a name, a mappedname and a description, a new label is added? Then please include the variable type as well, and now I come to think of it, why not include the coordinates as well (like xpdl) 
  | 

there are a lot of things that i don't want.  
* usage of the id attribute and an optional name attribute would be nice xml, but backwards incompatible
* forced label declaration separate from the id.

probably this was the spark that made me something that i do want : an optional extra attribute called label.

sorry if this is what you already proposed before.


As for the variable declarations, I have already changed my mind on that some time ago.  I think it would be good to have it in, although, there is no need for it now, there are some extensions in the core engine that i want like variable initialization and type declaration.  Both optional, of course.

Mostly, the variable declarations also can have there benefits for the GPD.  So that the GPD can offer drop downs instead of text boxes for variables.

I don't treat this as a priority yet.  Since there is no actual usage for it now.  Also the way to use user-defined variable declaration data in e.g. forms has to be studied further for it to work in a general case.


"kukeltje" wrote : The name is to be unique (like an id) is, on transitions used, for reference (like an idref) why not ditch the name/to then and realy use an ID and idref? the xsd standard can make sure these constraints are automatically met (a refid should point to an existing id, id's should be unique etc..etc..etc..ebBP uses this) Sorry if I sound a little frustrated (two STFF posts in 10 minutes) but I do mean what I say

in 4.0, i might consider want to switch to id and schema idref stuff. but that would become backwards incompatible...  and needs a conversion utility.  if the schema idref can be added to point to the name attribute, we could add it in our current schema (although we have to see how this works with superstates)



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008213#4008213

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008213


From do-not-reply at jboss.com  Tue Jan 30 06:27:56 2007
From: do-not-reply at jboss.com (danthony74)
Date: Tue, 30 Jan 2007 06:27:56 -0500 (EST)
Subject: [jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] -
	Classpath problems in deployment
Message-ID: <12017595.1170156476379.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi All,

I'm trying to deploy an ear with the following components:
EAR
    ->SAR (depends on classes in WAR, JAR and HAR)
    ->WAR(depends on classes in JAR and HAR)
    ->JAR(depends on classes in HAR)
    ->HAR

The SAR needs to access classes defined in the WAR and JAR. It is unable to find classes defined in the Jar, and won't deploy. Everything else works as intended.

I believe this to be a classloader problem. Does anyone have any thoughts on how to resolve this?

Cheers,

Dan

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008234#4008234

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008234


From do-not-reply at jboss.com  Tue Jan 30 06:49:50 2007
From: do-not-reply at jboss.com (visolvejboss)
Date: Tue, 30 Jan 2007 06:49:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] -
	4.0.5 org.jboss.test.compatibility.test.SerialVersionUIDUnit
Message-ID: <2805712.1170157790349.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hello All,

We have encountered an error in  org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase which was already discussed and the error has been filed as a bug against JBoss 4.0.3SP1 AS. The bug was closed saying that it was fixed in 4.0.4.GA. But we are facing same error again in the same platform.

AS : JBoss 4.0.5.GA
JDK : 1.5.0.02 (HP-UX JVM)
OS : HP-UX 

The error message is given below.

  | Failures on SerialVersionComparisson:javax.management.loading.MLet, org.jboss.monitor.alarm.AlarmNotification, org.jboss.monitor.alarm.AlarmTableNotification
  | 
  | junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.management.loading.MLet,
  | org.jboss.monitor.alarm.AlarmNotification,
  | org.jboss.monitor.alarm.AlarmTableNotification
  | 	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test401Compatibility(SerialVersionUIDUnitTestCase.java:185)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 

Refer the following for the former discussion and bug.

Discussion : http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77604
Bug : http://jira.jboss.com/jira/browse/JBAS-2965

Please help.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008240#4008240

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008240


From do-not-reply at jboss.com  Tue Jan 30 07:19:51 2007
From: do-not-reply at jboss.com (danthony74)
Date: Tue, 30 Jan 2007 07:19:51 -0500 (EST)
Subject: [jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re:
	Classpath problems in deployment
Message-ID: <17023439.1170159591084.JavaMail.jboss@colo-br-02.atl.jboss.com>

please disregard - realised this is the wrong forum.

Cheers.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008252#4008252

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008252


From do-not-reply at jboss.com  Tue Jan 30 07:26:40 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Tue, 30 Jan 2007 07:26:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: DB test matrix
Message-ID: <598480.1170160000723.JavaMail.jboss@colo-br-02.atl.jboss.com>

It looks like the URL is not correct for mysql :

java.lang.reflect.InvocationTargetExceptionCaused by: org.xml.sax.SAXParseException: The reference to entity "jdbcCompliantTruncation" must end with the ';' delimiter.	at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)	at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)	at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:76)	at org.jboss.portal.test.framework.embedded.DataSourceSupport$Config.fromXML(DataSourceSupport.java:271)	at org.jboss.portal.test.framework.embedded.DataSourceSupport$Config.fromXML2(DataSourceSupport.java:259)	at org.jboss.portal.test.cms.AbstractCMSTestCase.createTestSuite(AbstractCMSTestCase.java:83)	at org.jboss.portal.test.cms.commands.TestFileArchiveUpload.suite(TestFileArchiveUpload.java:74)	... 7 more


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008254#4008254

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008254


From do-not-reply at jboss.com  Tue Jan 30 08:33:53 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Tue, 30 Jan 2007 08:33:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Moved federation
	module to portlet-federation
Message-ID: <767919.1170164033361.JavaMail.jboss@colo-br-02.atl.jboss.com>

The federation module has been moved to portlet-federation which means :

- the top module federation is renamed portlet-federation
- the package org.jboss.portal.federation to org.jboss.portal.portlet.federation
- the intellij module has been renamed and updated

Probably that Thomas will have to modify the eclipse files as well to keep them in sync.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008284#4008284

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008284


From do-not-reply at jboss.com  Tue Jan 30 09:04:05 2007
From: do-not-reply at jboss.com (prabhat.jha@jboss.com)
Date: Tue, 30 Jan 2007 09:04:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: DB test matrix
Message-ID: <8977311.1170165845401.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes, I saw that error right after test was finished. I have corrected it. I will force a CC run early today so that we don't have to wait to see something else is broken.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008294#4008294

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008294


From do-not-reply at jboss.com  Tue Jan 30 09:25:29 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Tue, 30 Jan 2007 09:25:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Web console changes
	- IMPORTANT
Message-ID: <11991246.1170167129730.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : Did you have a look at facelets composition, fragment, include and insert ?

Ah, yes that is correct.  The task form itself could include <ui:fragment> around the body in order to trim outside of the tags.  I thought you were talking about something in the facelets API.

So yes, a task form could look like this:

  | <jbpm:dataform xmlns="http://www.w3.org/1999/xhtml"
  |       xmlns:ui="http://java.sun.com/jsf/facelets"
  |       xmlns:c="http://java.sun.com/jstl/core"
  |       xmlns:h="http://java.sun.com/jsf/html"
  |       xmlns:f="http://java.sun.com/jsf/core"
  |       xmlns:tf="http://jbpm.org/jsf/tf"
  |       xmlns:jbpm="http://jbpm.org/jsf">
  | 
  |   <f:facet name="header">
  |     <h:outputText value="#{taskName}"/>
  |   </f:facet>
  | 
  |   <!-- TASKFORM ROWS -->
  |   <jbpm:datacell>
  |     <f:facet name="header">
  |       <h:outputText value="Payment ID:"/>
  |     </f:facet>
  |     <h:inputText value="#{var['paymentId']}"/>
  |   </jbpm:datacell>
  |   <jbpm:datacell>
  |     <f:facet name="header">
  |       <h:outputText value="Actions:"/>
  |     </f:facet>
  |     <!-- TASKFORM BUTTONS -->
  |     <tf:saveButton value="Save"/>
  |     <tf:transitionButton value="Update Books"/>
  |   </jbpm:datacell>
  | 
  | </jbpm:dataform>
  | 

Or if this:


  | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
  | 
  | <!-- the DOCTYPE means we are required to use html for a root element -->
  | <html xmlns="http://www.w3.org/1999/xhtml"
  |       xmlns:ui="http://java.sun.com/jsf/facelets"
  |       xmlns:c="http://java.sun.com/jstl/core"
  |       xmlns:h="http://java.sun.com/jsf/html"
  |       xmlns:f="http://java.sun.com/jsf/core"
  |       xmlns:tf="http://jbpm.org/jsf/tf"
  |       xmlns:jbpm="http://jbpm.org/jsf">
  | <ui:fragment>
  | 
  | <jbpm:dataform>
  |   <f:facet name="header">
  |     <h:outputText value="#{taskName}"/>
  |   </f:facet>
  | 
  |   <!-- TASKFORM ROWS -->
  |   <jbpm:datacell>
  |     <f:facet name="header">
  |       <h:outputText value="Payment ID:"/>
  |     </f:facet>
  |     <h:inputText value="#{var['paymentId']}"/>
  |   </jbpm:datacell>
  |   <jbpm:datacell>
  |     <f:facet name="header">
  |       <h:outputText value="Actions:"/>
  |     </f:facet>
  |     <!-- TASKFORM BUTTONS -->
  |     <tf:saveButton value="Save"/>
  |     <tf:transitionButton value="Update Books"/>
  |   </jbpm:datacell>
  | 
  | </jbpm:dataform>
  | </ui:fragment>
  | </html>
  | 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008312#4008312

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008312


From do-not-reply at jboss.com  Tue Jan 30 09:30:17 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Tue, 30 Jan 2007 09:30:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Bug in
	Sun compiler?
Message-ID: <9363207.1170167417684.JavaMail.jboss@colo-br-02.atl.jboss.com>

I found this while looking at a microcontainer test.

It fails in both JDK5 and JDK6, but works with eclipse.

Looks like a bug to me? Anybody confirm?

  | package test;
  | 
  | import java.lang.reflect.Constructor;
  | import java.lang.reflect.Type;
  | import java.util.Arrays;
  | 
  | public class Main
  | {
  |    public static void main(String[] args) throws Exception
  |    {
  |       Class<MyEnum> clazz = MyEnum.class;
  |       Constructor<MyEnum> constructor = clazz.getDeclaredConstructor(new Class[] { String.class, Integer.TYPE });
  |       Type[] types = constructor.getParameterTypes();
  |       Type[] generic = constructor.getGenericParameterTypes();
  |       System.out.println("types   = " + Arrays.asList(types));
  |       System.out.println("generic = " + Arrays.asList(generic));
  |       if (Arrays.equals(types, generic) == false)
  |          throw new RuntimeException("They should be the same?");
  |    }
  |    
  |    public enum MyEnum { ONE, TWO, THREE };
  | }
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008317#4008317

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008317


From do-not-reply at jboss.com  Tue Jan 30 09:33:30 2007
From: do-not-reply at jboss.com (kukeltje)
Date: Tue, 30 Jan 2007 09:33:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Process definition
	element label attribute
Message-ID: <15779997.1170167610086.JavaMail.jboss@colo-br-02.atl.jboss.com>

The variable declarations have their advantage in the GPD, but also in the webservice. It would be possible to generate xsd's with the correct types for setting variables in certain states/nodes/tasks. Now, there is not  type checking other than manualy generating an XSD and using XSD validation. 

Regarding the generation, seam form generation does a nice job. They are kind of similar to the jbpm forms. The FTL templates that are used use the type to generate correct input types, which is nice. Using FTL for the jBPM forms would be cool and in line with  using similar frameworks for similar things across multiple jboss projects.

If I find time (lots of experimenting with seam now) I'll have a look at the id/ref stuff.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008318#4008318

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008318


From do-not-reply at jboss.com  Tue Jan 30 09:41:41 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Tue, 30 Jan 2007 09:41:41 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: web console problem
Message-ID: <8693981.1170168101728.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes, and to be clear, here are the attributes that you can have on a transitionButton:

* value: This is the caption of the button.  If none is given, the transition name is given.
* transition: This is the transition to take.  (Up above I said it was called "to" - my apologies for the confusion).
* src: The URL of an image file, if you want to override the little icon.  Sensible defaults are automatically chosen for task form buttons.
* All default h:commandButton attributes (except for "action"), which can be found here: http://java.sun.com/javaee/javaserverfaces/1.2/docs/tlddocs/h/commandButton.html

You may also have these attributes (except for "transition") on the saveButton.

I think it would be wise for the GPD to not emit cancelButtons, since the cancel button does not serve any purpose that cannot be also done with a plain <h:commandButton>.

Finally, the GPD should no longer generate a "comments" field by default.  This field is already present elsewhere on the task view page.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008323#4008323

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008323


From do-not-reply at jboss.com  Tue Jan 30 09:50:05 2007
From: do-not-reply at jboss.com (alesj)
Date: Tue, 30 Jan 2007 09:50:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Property replacement
Message-ID: <4050658.1170168605537.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | There already is an AnnotationInfo. Doesn't the inherrited TypeInfo.convertValue(Object value, boolean replaceProperties) come into play?
  |  
  | 
If we wanted to use this, it probably means that we should push the replace param with the current Annotation creation:

  | ann = (Annotation) AnnotationCreator.createAnnotation(annString, Thread.currentThread().getContextClassLoader());
  | 

But I don't see any easy way to call AnnotationInfo.convertValue(Object, boolean).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008325#4008325

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008325


From do-not-reply at jboss.com  Tue Jan 30 10:00:36 2007
From: do-not-reply at jboss.com (bkeh12)
Date: Tue, 30 Jan 2007 10:00:36 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Bug
	in Sun compiler?
Message-ID: <7544650.1170169236027.JavaMail.jboss@colo-br-02.atl.jboss.com>

Sorry I post there.

types = [class.java.lang.string, int]
generic = []
Exception in thread "main" java.lang.RuntimeException: They should be the same?

my config fedora5 + NetBeans 5.5  +  jdk 6 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008334#4008334

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008334


From do-not-reply at jboss.com  Tue Jan 30 10:49:13 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Tue, 30 Jan 2007 10:49:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <25010793.1170172153810.JavaMail.jboss@colo-br-02.atl.jboss.com>

Can we solve the XPC issue with something along these lines?

1) XPC is stored in the parent bean context.
2) Child beans have an independent lifecycle (i.e. bean instance is cached with the context, not in an internal data structure of the parent. Child bean context stores data about location of parent, and vice versa.
3) When nested bean is invoked, interceptor accesses the parent bean, gets the XPC and injects it into the nested bean instance.  On the way out clear the XPC ref from the nested bean. I.e. don't try to maintain a shared ref to XPC across serialization; instead cache it in the parent and inject it into the child as needed.
4) As part of remove process, check if the bean is a parent.  If so, check if any children are still alive.  If yes, don't remove context from the cache; instead set a removed flag in the context.  If removed flag is set an interceptor will not allow any call to the context (throw NoSuchEjbException). But the context is still cached, so child beans can find the XPC.
5) As part of remove process, check if bean is a child.  If so, have parent re-check if all its children are still alive.  If not, parent context can be removed.

Along with this, in general it would be good to have a background thread that runs to check for and remove orphaned beans.  But that's true regardless of the value of the above.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008363#4008363

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008363


From do-not-reply at jboss.com  Tue Jan 30 11:44:35 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Tue, 30 Jan 2007 11:44:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: JBCACHE-957
	Discussion Thread
Message-ID: <27336953.1170175475901.JavaMail.jboss@colo-br-02.atl.jboss.com>

While this is an interesting idea, and will very cleanly encapsulate the decision around the type of lock acquired based on:

1) Locking Scheme (opt or pess)
2) Operation (readdata, writedata, deletedata, readchild, createchild, deletechild for PL, readIntoWorkspace, writeFromWorkspace for OL)
3) State of the LockParentForChildInsertRemove param.

I'm a bit concerned about getting this into 2.0.0.B1.  If anything, this will be a B2 feature, but I am really concerned with feature creep in 2.0.0.  Anyone has the spare cycles for this?  :-)



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008386#4008386

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008386


From do-not-reply at jboss.com  Tue Jan 30 11:46:34 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Tue, 30 Jan 2007 11:46:34 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: TxInterceptor
	logging of exceptions
Message-ID: <2622867.1170175594868.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | 
  | 1) Why log at all if the exception is going to be rethrown? The log doesn't indicate any action on the part of the interceptor. Eviction now uses a 0 ms timeout, so a lot of those timeouts could end up getting logged. 
  | 

Agreed.  Unless we intend to NOT throw the exception (failSilently is present) we should not log the exception.

anonymous wrote : 
  | 
  | 2) If failSilently is set, a stack trace in the log at INFO doesn't seem very silent. People freak at stack traces no matter what level. At a minimum I think any INFO logging should be just the message, with a stack trace only at DEBUG or TRACE. But with Hibernate's usage, I think these are going to be too frequent for INFO.
  | 

+1 as well.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008387#4008387

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008387


From do-not-reply at jboss.com  Tue Jan 30 11:53:12 2007
From: do-not-reply at jboss.com (julien@jboss.com)
Date: Tue, 30 Jan 2007 11:53:12 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: DB test matrix
Message-ID: <6010659.1170175992561.JavaMail.jboss@colo-br-02.atl.jboss.com>

It looks like it's improving now :

1320/7/60 with a success rate of 94.92%

I sees errors in

- CMS
- RegistrationPersistenceManagerTestCase
- WSRP (but it does not seem related to the database)

I'll look first at RegistrationPersistenceManagerTestCase.

Roy or Sohil will have to look at the CMS issues.

We'll look at WSRP later, it may be a transient issue as it was not occuring before.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008393#4008393

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008393


From do-not-reply at jboss.com  Tue Jan 30 12:04:03 2007
From: do-not-reply at jboss.com (prabhat.jha@jboss.com)
Date: Tue, 30 Jan 2007 12:04:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Portal] - Re: DB test matrix
Message-ID: <3961258.1170176643398.JavaMail.jboss@colo-br-02.atl.jboss.com>

I am glad it's going up. The DB config issues seem to have resolved now.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008398#4008398

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008398


From do-not-reply at jboss.com  Tue Jan 30 12:05:02 2007
From: do-not-reply at jboss.com (berkum)
Date: Tue, 30 Jan 2007 12:05:02 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Profiler] - Re: could not find
	agent library on the library path or in t
Message-ID: <29379201.1170176702249.JavaMail.jboss@colo-br-02.atl.jboss.com>

Look at the readme.txt file that comes with jbossprofiler.  You must put jbossInspector.dll in your path.  That could be your problem.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008400#4008400

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008400


From do-not-reply at jboss.com  Tue Jan 30 12:14:48 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Tue, 30 Jan 2007 12:14:48 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: TxInterceptor
	logging of exceptions
Message-ID: <10921091.1170177288729.JavaMail.jboss@colo-br-02.atl.jboss.com>

"manik.surtani at jboss.com" wrote : 
  | +1 as well.

To logging the message INFO and the stack trace lower, or the whole thing lower?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008406#4008406

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008406


From do-not-reply at jboss.com  Tue Jan 30 12:29:07 2007
From: do-not-reply at jboss.com (wolfc)
Date: Tue, 30 Jan 2007 12:29:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <28317223.1170178147505.JavaMail.jboss@colo-br-02.atl.jboss.com>

I finally found the relevant bit in the specs: EJB 3 Persistence 5.6.2.1.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008415#4008415

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008415


From do-not-reply at jboss.com  Tue Jan 30 12:56:16 2007
From: do-not-reply at jboss.com (kabir.khan@jboss.com)
Date: Tue, 30 Jan 2007 12:56:16 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Registering a bean as an aspect in the bootstrap
Message-ID: <1893495.1170179776194.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have fixed the pointcut in the test. I'll try to figure out the AspectManagerJDK5 issue around the training I am delivering

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008420#4008420

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008420


From do-not-reply at jboss.com  Tue Jan 30 13:01:14 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Tue, 30 Jan 2007 13:01:14 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <17294340.1170180074889.JavaMail.jboss@colo-br-02.atl.jboss.com>

I guess that sounds good Brian.  That's gonna be one piece of ugly non-modular code.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008423#4008423

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008423


From do-not-reply at jboss.com  Tue Jan 30 13:28:42 2007
From: do-not-reply at jboss.com (otasyn)
Date: Tue, 30 Jan 2007 13:28:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - XML
	Validation Error
Message-ID: <30434870.1170181722879.JavaMail.jboss@colo-br-02.atl.jboss.com>

This may be useless to someone else, so I am making this post.

If eclipse is set to validate XML and the XML files direct the validation to "http://java.sun.com/xml/ns/j2ee" then you probably receive an error that j2ee_web_services_client_1_1.xsd could not be validated.

If so, this is because something in JBoss (or Eclipse) is attempting to parse the file j2ee.htm at this location.  In this file, the old URL is commented out and a new one is written directly after it.  However, the parser logic doesn't seem to take into account the html comments.  To fix this, host j2ee.htm on your local machine and remove the commented sections.  Replace the link in your XML file, with the path to you local machine.  I, personally, loaded it onto my own web site, but I don't see why it wouldn't work locally.

I am fairly new to this, especially JBoss, so if I am missing something, or if this seems to be just a completely useless post, then feel free to ignore this.

Otasyn

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008435#4008435

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008435


From do-not-reply at jboss.com  Tue Jan 30 13:37:01 2007
From: do-not-reply at jboss.com (manik.surtani@jboss.com)
Date: Tue, 30 Jan 2007 13:37:01 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: TxInterceptor
	logging of exceptions
Message-ID: <2309915.1170182221620.JavaMail.jboss@colo-br-02.atl.jboss.com>

Sorry, shld have specified - the whole thing for lower.  

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008438#4008438

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008438


From do-not-reply at jboss.com  Tue Jan 30 13:46:34 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Tue, 30 Jan 2007 13:46:34 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: TxInterceptor
	logging of exceptions
Message-ID: <8613381.1170182794116.JavaMail.jboss@colo-br-02.atl.jboss.com>

Cool. Done.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008444#4008444

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008444


From do-not-reply at jboss.com  Tue Jan 30 13:52:49 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Tue, 30 Jan 2007 13:52:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <29489046.1170183169964.JavaMail.jboss@colo-br-02.atl.jboss.com>

I didn't see anything in section 5.6.2 about the sharing not applying to beans with an @Remote. But since it's possible such a nested bean isn't even in the same VM, that's probably too much to try to deal with.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008447#4008447

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008447


From do-not-reply at jboss.com  Tue Jan 30 14:21:25 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Tue, 30 Jan 2007 14:21:25 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <17638237.1170184885416.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm pretty sure that somehwere it says that XPC PC is not propagated across remote boundaries.  That's another think I know we discussed in great detail on the expert group.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008456#4008456

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008456


From do-not-reply at jboss.com  Tue Jan 30 14:53:00 2007
From: do-not-reply at jboss.com (pgier)
Date: Tue, 30 Jan 2007 14:53:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Build System] - Cleanup of
	JBoss Maven plugins
Message-ID: <25131521.1170186780944.JavaMail.jboss@colo-br-02.atl.jboss.com>

I believe the jboss version of the maven clean plugin is no longer needed.  It is located here:
https://svn.labs.jboss.org/labs/jbossbuild/trunk/projects/maven-plugins/maven-clean-plugin

It looks like it was created to add the functionality of configuring which directories are deleted when "mvn clean" is run.  This is no longer needed because the regular maven clean plugin has this functionality.

So if no one has a problem with me deleting it, I will remove it from subversion.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008469#4008469

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008469


From do-not-reply at jboss.com  Tue Jan 30 16:31:30 2007
From: do-not-reply at jboss.com (genman)
Date: Tue, 30 Jan 2007 16:31:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBossCache] - Re: JBCACHE-957
	Discussion Thread
Message-ID: <13905861.1170192690880.JavaMail.jboss@colo-br-02.atl.jboss.com>

I took a stab at the API, but I don't know well enough what to do with the 13-14 references to the old acquire calls.

I uploaded my patch to the JIRA issue at the top.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008523#4008523

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008523


From do-not-reply at jboss.com  Tue Jan 30 16:45:38 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Tue, 30 Jan 2007 16:45:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Duplicated client IDs
Message-ID: <2144209.1170193538775.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm working on the integration testsuite, and one failing test is DuplicateClientIDUnitTestCase::testDuplicate.

I wrote a similar test within JBossMessaging testsuite (org.jboss.test.jbossmessaging.test.DuplicateClientIDUnitTestCase) and the test is failing.

If we decide this is not a bug, we will have to decide what to do on the integration testsuite.

This is the JIRA issue:

http://jira.jboss.org/jira/browse/JBMESSAGING-791

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008529#4008529

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008529


From do-not-reply at jboss.com  Tue Jan 30 17:12:08 2007
From: do-not-reply at jboss.com (timfox)
Date: Tue, 30 Jan 2007 17:12:08 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Duplicated client IDs
Message-ID: <2764217.1170195128332.JavaMail.jboss@colo-br-02.atl.jboss.com>

I think this bug is a duplicate of http://jira.jboss.com/jira/browse/JBMESSAGING-286.

It looks like an easy fix, you could do it now if you want.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008533#4008533

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008533


From do-not-reply at jboss.com  Tue Jan 30 17:46:49 2007
From: do-not-reply at jboss.com (wolfc)
Date: Tue, 30 Jan 2007 17:46:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <29896017.1170197209313.JavaMail.jboss@colo-br-02.atl.jboss.com>

I would rather have the SFSB register themselves as users in the XPC. The XPC then maintains this list. On @Remove SFSB deregisters and if XPC is empty close itself.

For injection: any SFSB with an XPC with creates a SFSB propagates the XPC with the exception of @Remote. Hmm... still don't like it, but there is no other way.

The final part: orphaned SFSBs must be removed by a reaper as per spec after a timeout.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008546#4008546

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008546


From do-not-reply at jboss.com  Tue Jan 30 18:19:40 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Tue, 30 Jan 2007 18:19:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <28879114.1170199180057.JavaMail.jboss@colo-br-02.atl.jboss.com>

"wolfc" wrote : I would rather have the SFSB register themselves as users in the XPC. The XPC then maintains this list. On @Remove SFSB deregisters and if XPC is empty close itself.

OK. But only parent context holds a ref to the XPC, yes? Otherwise you have the problem of multiple contexts independently serializing/deserializing the XPC, after which you no longer have a shared reference.

The XPC would need to know which context has the ref to it, so as part of the close process it can inform that context it no longer needs to be cached.  It's the caching of the parent context that keeps the XPC from being gc'd.  Unless we come up with a separate cache for these.

Shit, if a call to a child bean triggers replication, the parent bean must be replicated as well, otherwise the XPC isn't. Perhaps separately caching XPCs makes sense. :(

anonymous wrote : For injection: any SFSB with an XPC with creates a SFSB propagates the XPC with the exception of @Remote. Hmm... still don't like it, but there is no other way.

Not clear exactly what you mean here. :)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008561#4008561

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008561


From do-not-reply at jboss.com  Tue Jan 30 19:01:39 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Tue, 30 Jan 2007 19:01:39 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <30472209.1170201699312.JavaMail.jboss@colo-br-02.atl.jboss.com>

no it doesn't...

Again, the big problem is managed entities.  This is why all the SFSBs and XPC's need to be serialized together.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008570#4008570

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008570


From do-not-reply at jboss.com  Tue Jan 30 19:14:23 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Tue, 30 Jan 2007 19:14:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <24883303.1170202463479.JavaMail.jboss@colo-br-02.atl.jboss.com>

Furthermore, there can be multiple XPCs...I still think the parent owning all the instances makes the most sense and for the child to have the same lifecycle as the parent.  I'm not sure there is anything in the spec that forbids us from doing this.

What we could do is, when the parent gets removed, pick a new "master" SFSB to hold the references to the other SFSB instances as well as the XPCs. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008574#4008574

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008574


From do-not-reply at jboss.com  Tue Jan 30 21:16:09 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Tue, 30 Jan 2007 21:16:09 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Bug
	in Sun compiler?
Message-ID: <1081057.1170209769741.JavaMail.jboss@colo-br-02.atl.jboss.com>

Its a known bug for inner classes that has been open for some time:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5087240

although, even if I pull the enum into a separate class I still see the same problem. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008601#4008601

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008601


From do-not-reply at jboss.com  Tue Jan 30 21:45:13 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Tue, 30 Jan 2007 21:45:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Profiler] - Re: could not find
	agent library on the library path or in t
Message-ID: <7775740.1170211513754.JavaMail.jboss@colo-br-02.atl.jboss.com>

the other possibility would be...

You are using Linux... and you don't have the dependency (such as the libgc) installed.

You could compile the library yourself in your system... look at the manual on how to compile the libraries.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008608#4008608

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008608


From do-not-reply at jboss.com  Wed Jan 31 00:00:06 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Wed, 31 Jan 2007 00:00:06 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - JBAS-1434 Part 2
Message-ID: <13861348.1170219606740.JavaMail.jboss@colo-br-02.atl.jboss.com>

Quick check of moving over to the JCA/JMS adapter. Change in standardjboss.xml is required. The easiest thing is simply to switch the default container configuration from


  | 
  |       <container-name>Standard Message Driven Bean</container-name>
  |       <call-logging>false</call-logging>
  |       <invoker-proxy-binding-name>message-driven-bean</invoker-proxy-binding-name>
  | 

to


  |       <container-name>Standard Message Driven Bean</container-name>
  |       <call-logging>false</call-logging>
  |       <invoker-proxy-binding-name>jms-message-inflow-driven-bean</invoker-proxy-binding-name>
  | 

Also, as we all know, the old JMSContainerInvoker allowed for creating destinations when a listener was being deployed without one. EJB3 carries this tradition over for EJB3, but for EJB 2.x the JMS/JCA adapter will not. 

There are a few reasons for this

a) It's not portable and JBoss specific
b) While we could create a temporary destination using the JMS API, I don't think it is a good idea to carry this 'convenience' forward as it simply masks underlying configuration issues on the client. 

In sum, you want to use JMS/JCA inflow, create your destination. Further, I am not sure how much from the JMS API without having to fall back on JBoss specific constructs to create the destination. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008640#4008640

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008640


From do-not-reply at jboss.com  Wed Jan 31 00:02:55 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Wed, 31 Jan 2007 00:02:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re:
	XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2
Message-ID: <28050534.1170219775515.JavaMail.jboss@colo-br-02.atl.jboss.com>

Something about this still just doesn't seem right. I am attempting to get with the JBossTS team to discuss what, if anything, we should be doing differently. I am not sure how catching, logging (basically masking) the underlying XA exception is going to help matters. While the JcaXAResourceWrapper could do some trickery to make this problem 'go away' I am not sure this is the right approach. 

In the tests we are simply reporting what could very well be a real XA exception. If this is causing an IllegalStateException in JBossTS, I would really like to know what and what the *right* way to to fix this is. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008641#4008641

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008641


From do-not-reply at jboss.com  Wed Jan 31 00:15:23 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Wed, 31 Jan 2007 00:15:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- JGroups configuration for clustering testing
Message-ID: <12507122.1170220523449.JavaMail.jboss@colo-br-02.atl.jboss.com>

Clebert,

What JGroups stack configurations are we using now for clustering testing? 

The ones from src/etc/server/default/deploy/clustered-mysql-persistence-service.xml or those from src/etc/server/default/deploy/multiplexer-stacks.xml?

Thanks
Ovidiu

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008646#4008646

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008646


From do-not-reply at jboss.com  Wed Jan 31 00:29:52 2007
From: do-not-reply at jboss.com (ashish.mishra16)
Date: Wed, 31 Jan 2007 00:29:52 -0500 (EST)
Subject: [jboss-dev-forums] [Javassist development Forum] - How to use Log4j
	in Struts
Message-ID: <28355065.1170221392562.JavaMail.jboss@colo-br-02.atl.jboss.com>

 I m facing problem in using log4j in my struts application. My director strutcture is 
SRC,Web-Root
             WEB-INF
                   lib,classes,web.xml,struts-config.xml
                           In classes i have class files, config.properties for log4j, ApplicationResources.properties.

Now i m not able to read the config.properties file. in any ways, the config.properties file is like this:

log4j.rootLogger=DEBUG, A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n.

I m using the following method to read the it in LoginAction.java:

static Logger logger = Logger.getLogger(LoginAction.class.getName());
try {
			
	Properties logProperties = new Properties();
	logProperties.load(new FileInputStream("config.properties"));
	PropertyConfigurator.configure(logProperties);				
      } catch (Exception e) {
      
      throw new RuntimeException("Enable to Load Logging Properties File");
      }
Please tell me how to read the config.properties file. Or what is d other ways to handle Log4J. 




         

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008650#4008650

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008650


From do-not-reply at jboss.com  Wed Jan 31 05:12:18 2007
From: do-not-reply at jboss.com (wolfc)
Date: Wed, 31 Jan 2007 05:12:18 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <14632286.1170238338077.JavaMail.jboss@colo-br-02.atl.jboss.com>

Okay, but introduce a new object XPCHolder or something to hold the administration of XPC users. Then there is no "master", parent or child. Just an XPC holder and users. That's more easily to understand (at least to my brain :-) ).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008722#4008722

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008722


From do-not-reply at jboss.com  Wed Jan 31 05:32:35 2007
From: do-not-reply at jboss.com (alesj)
Date: Wed, 31 Jan 2007 05:32:35 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Scoped
	beans deployment
Message-ID: <14033026.1170239555233.JavaMail.jboss@colo-br-02.atl.jboss.com>

What's the status of being able to define in which scope you want to put / lookup your beans?
E.g. 'visible' only for current deployment unit (single xml file), whole archive deployment (multiple files in .sar, ...), whole app deployment, current kernel bootstrap, cluster, ... 

What I want to do with OSGi integration is be able to put in current Bundle bean (under some specific name - similar to what we do with Kernel), and then later use it when wiring beans with OSGi layer. OSGi aware beans are normal beans deployed with BeanMetaDataDeployer, which is currently bound with bootstrap Kernel. There is only special schema handling + the part that is missing = currently deployed beans being aware of their underlying Bundle.

How do I get the currently deployed beans be aware of their Bundle (which is a part of DeploymentUnit attachments). Any elegant way or a horrible ThreadLocal? ;-(


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008731#4008731

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008731


From do-not-reply at jboss.com  Wed Jan 31 08:16:44 2007
From: do-not-reply at jboss.com (alesj)
Date: Wed, 31 Jan 2007 08:16:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Mixing
	schemas WildcardBinding exception
Message-ID: <22085148.1170249404127.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm using this xml:

  | <?xml version="1.0" encoding="UTF-8"?>
  | 
  | <beans xmlns="urn:jboss:spring-beans:2.0">
  | 
  |    <bean id="testBean" class="org.jboss.test.spring.support.SimpleBean">
  |       <property name="refBean"><ref bean="oldBean"/></property>
  |    </bean>
  | 
  |    <bean xmlns="urn:jboss:bean-deployer:2.0" name="oldBean" class="org.jboss.test.spring.support.OldBean">
  |       <property name="javaBeanString"><value>JavaBean</value></property>
  |    </bean>
  | 
  | </beans>

and I get the following exception:

  | org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/C:/projects/microcontainer/classes/test/spring-int/org/jboss/test/spring/test/InstantiateMixed2TestCase.xml at 13,9
  | 	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:173)
  | 	at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:133)
  | 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:135)
  | 	at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:212)
  | 	at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:283)
  | 	at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.setUp(MicrocontainerTestDelegate.java:78)
  | 	at org.jboss.test.spring.test.TempSpringMicrocontainerTestDelegate.setUp(TempSpringMicrocontainerTestDelegate.java:48)
  | 	at org.jboss.test.AbstractTestSetup.setUp(AbstractTestSetup.java:63)
  | 	at junit.extensions.TestSetup$1.protect(TestSetup.java:18)
  | 	at junit.extensions.TestSetup.run(TestSetup.java:23)
  | 	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
  | Caused by: java.lang.ClassCastException: org.jboss.xb.binding.sunday.unmarshalling.WildcardBinding
  | 	at org.jboss.xb.binding.sunday.unmarshalling.DefaultElementHandler.setParent(DefaultElementHandler.java:109)
  | 	at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endRepeatableParticle(SundayContentHandler.java:730)
  | 	at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endElement(SundayContentHandler.java:138)
  | 	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.endElement(SaxJBossXBParser.java:353)
  | 	at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
  | 	at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown Source)
  | 	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
  | 	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
  | 	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
  | 	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
  | 	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
  | 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
  | 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
  | 	at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
  | 	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:169)
  | 	... 23 more

When I do it the other way around - defining root element deployment as MC schema, and using Spring bean inside deployment - it works.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008769#4008769

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008769


From do-not-reply at jboss.com  Wed Jan 31 08:48:30 2007
From: do-not-reply at jboss.com (yperey)
Date: Wed, 31 Jan 2007 08:48:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - SOAP request
	missing namespace
Message-ID: <5320347.1170251310722.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hello,

I've followed step by step the http://wiki.jboss.org/wiki/Wiki.jsp?page=WS4EEDOCClientStepByStep

to deploy a web service client on JBoss 4.0.2 using JWSDP 1.6. The problem is that in the SOAP request I send to the server there are attributes of a complex type with missing namespace:

<?xml version="1.0" encoding="UTF-8"?>
  | <soapenv:Envelope
  | xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
  | xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
  | xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  |  <soapenv:Header>
  |   <jbws:username soapenv:actor="http://webservice.jboss.com/ws4ee/login"
  | xmlns:jbws="http://webservice.jboss.com/ws4ee">root</jbws:username>
  |   <jbws:password soapenv:actor="http://webservice.jboss.com/ws4ee/login"
  | xmlns:jbws="http://webservice.jboss.com/ws4ee">cm9vdDE=</jbws:password>
  |  </soapenv:Header>
  |  <soapenv:Body>
  |   <ns1:LHUB_PutIntoTargetSystemsProcessRequest
  |   xmlns:ns1="http://xmlns.oracle.com/LHUB_PutIntoTargetSystems">
  |    <source>1</source>
  |    <targets>0</targets>
  |   </ns1:LHUB_PutIntoTargetSystemsProcessRequest>
  |  </soapenv:Body>
  | </soapenv:Envelope>

like for source and targets event if in the wsdl it is specified attributeFormDefault="qualified" and elementFormDefault="qualidied" as you can see:


  | ...
  | <types>
  |         <schema attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://xmlns.oracle.com/LHUB_PutIntoTargetSystems"
  |              xmlns="http://www.w3.org/2001/XMLSchema">
  |             <element name="LHUB_PutIntoTargetSystemsProcessRequest">
  |                 <complexType>
  |                     <sequence>
  |                         <element name="source" type="string"/>
  |                         <element name="targets" type="string"/>
  |                     </sequence>
  |                 </complexType>
  |             </element>
  |             <element name="LHUB_PutIntoTargetSystemsProcessResponse">
  |                 <complexType>
  |                     <sequence>
  |                         <element name="error" type="string"/>
  |                         <element name="description" type="string"/>
  |                         <element name="details" type="string"/>
  |                     </sequence>
  |                 </complexType>
  |             </element>
  |         </schema>
  |     </types>
  | ...
  | 

here is my wscompile line:
anonymous wrote : wscompile -gen:client -f:documentliteral -f:wsi -mapping jaxrpc-mapping-client.xml -keep config-client.xml

Here is the correct SOAP envelope that I'm supposed to have:

<?xml version="1.0" encoding="UTF-8"?>
  | <soapenv:Envelope
  | xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
  | xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
  | xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  |  <soapenv:Header>
  |   <jbws:username soapenv:actor="http://webservice.jboss.com/ws4ee/login"
  | xmlns:jbws="http://webservice.jboss.com/ws4ee">root</jbws:username>
  |   <jbws:password soapenv:actor="http://webservice.jboss.com/ws4ee/login"
  | xmlns:jbws="http://webservice.jboss.com/ws4ee">cm9vdDE=</jbws:password>
  |  </soapenv:Header>
  |  <soapenv:Body>
  |   <ns1:LHUB_PutIntoTargetSystemsProcessRequest
  |   xmlns:ns1="http://xmlns.oracle.com/LHUB_PutIntoTargetSystems">
  |    <ns1:source>1</ns1:source>
  |    <ns1:targets>0</ns1:targets>
  |   </ns1:LHUB_PutIntoTargetSystemsProcessRequest>
  |  </soapenv:Body>
  | </soapenv:Envelope>

Any idea ?

Yann.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008779#4008779

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008779


From do-not-reply at jboss.com  Wed Jan 31 09:03:48 2007
From: do-not-reply at jboss.com (alex.loubyansky@jboss.com)
Date: Wed, 31 Jan 2007 09:03:48 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Mixing schemas WildcardBinding exception
Message-ID: <26467543.1170252228541.JavaMail.jboss@colo-br-02.atl.jboss.com>

For some reason an extension of the DefaultElementHandler is used for a wildcard.
I haven't looked at the schema and initialization yet. But this happens for a repeated wildcard. Have a look at org.jboss.test.xml.AnyComplexTypeUnitTestCase. Maybe it'll give you an idea.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008785#4008785

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008785


From do-not-reply at jboss.com  Wed Jan 31 09:37:07 2007
From: do-not-reply at jboss.com (estaub)
Date: Wed, 31 Jan 2007 09:37:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Support for Bean
	Scripting Framework (BSF)
Message-ID: <31998199.1170254227351.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm planning to implement support for BSF and will contribute it back if it's wanted. 
(BSF supports pluggable scripting engines and pluggable domain classes.) 

I'm posting this here, rather than on the forum, to make sure we don't end up with duplicate efforts. 
If this was the wrong thing to do, apologies in advance. 

My current plans are to just provide a way to configure a global scripting engine via jbpm.cfg.xml. In the future, it would be desirable to make this settable in the Process Definition. 

I'll make sure this works with BeanShell and Groovy - other folks will have to vet Rhino, etc. 
Current estimate is "before end of February". 

Any thoughts? Requests? Is this useful to others? I haven't seen much about it on the forums. 

This was originally misposted on JIRA as http://jira.jboss.com/jira/browse/JBPM-830.

Tom Baeyens responded there:

anonymous wrote : good idea. i mainly would be interested to know how you could enhance the current scripting support to BSF without braking backwards compatibility. 
  | 
  | if this could be done with adding a language attribute to the script tag that has the default value of 'bsh', I'm all ears :-) 

Backward compatibility is certainly a requirement.  As for "how", it superficially looks easy; I'll know more shortly.

A <script language="bsh"> attribute sounds good; folks also might want to set a default language in the process definition or even in the config file.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008798#4008798

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008798


From do-not-reply at jboss.com  Wed Jan 31 10:24:29 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Wed, 31 Jan 2007 10:24:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JGroups configuration for clustering testing
Message-ID: <3003613.1170257069167.JavaMail.jboss@colo-br-02.atl.jboss.com>

Our services are verifying the existence of multiplexer MBean (configured on the postOffice) ... if available, we use multiplexer, if not we use the config on clustered-mysql-persistence-service.xml (I mean.. .regular channels).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008812#4008812

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008812


From do-not-reply at jboss.com  Wed Jan 31 10:33:32 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Wed, 31 Jan 2007 10:33:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JGroups configuration for clustering testing
Message-ID: <5722314.1170257612904.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have done this per Brian's suggestion.

If we were running messaging on JBoss 4.0 or 4.2 (not defined yet I guess if we will have or not the multiplexer) we would use regular channels. 

If jboss-5 -> multiplexer.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008817#4008817

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008817


From do-not-reply at jboss.com  Wed Jan 31 10:52:55 2007
From: do-not-reply at jboss.com (ovidiu.feodorov@jboss.com)
Date: Wed, 31 Jan 2007 10:52:55 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JGroups configuration for clustering testing
Message-ID: <28779779.1170258775334.JavaMail.jboss@colo-br-02.atl.jboss.com>

OK.

That's what I saw in the code, too.

However, trying to use multiplexer doesn't work, so right now we're resorting to the good old channels.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008832#4008832

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008832


From do-not-reply at jboss.com  Wed Jan 31 11:04:57 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 31 Jan 2007 11:04:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Web console changes
	- IMPORTANT
Message-ID: <27667006.1170259497729.JavaMail.jboss@colo-br-02.atl.jboss.com>

"david.lloyd at jboss.com" wrote : 
  | 
  |   | <ui:fragment>
  |   | 
  | 
  | This should be:
  | <ui:component>
  | 
  | Sorry about the mixup.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008835#4008835

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008835


From do-not-reply at jboss.com  Wed Jan 31 11:40:31 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Wed, 31 Jan 2007 11:40:31 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <10970704.1170261631927.JavaMail.jboss@colo-br-02.atl.jboss.com>

StatefulBeanContext already has a "removed" field, and already has a ref to all its (non @Remote) children. Those children already have a ref to the parent. So it should be quite easy to just change the caching code to not de-cache the parent while any children are alive.  Then StatefulInstanceInterceptor just checks the removed field to ensure the parent is no longer accessible (should probably do that anyway).

That seems easier than moving data around from one bean to another. It's a quick and dirty improvement, if such a thing is wanted for RC10/4.2.

But, a general problem with making XPCs and managed entities part of the replicated state of any SFSB is the possibility of something like this:

1) Parent A has nested children B and C.
2) A exposes getters for B and C, and 3 separate clients have refs to A, B and C.
3) All 3 clients make concurrent requests that result in a need to replicate.

This can result in one thread attempting to serialize the bean instances, calls to @PrePassivate, etc. while another thread is actively operating on the bean. Yuck!

Encapsulating the shared state in something like an XPCHolder might help with that, if the XPCHolder could be cached and replicated independently of the bean instances. This assumes that one thread serializing the XPC and managed entities while another thread is using them is not a problem.

A separate caching infrastructure for XPCHolder would take quite a bit of time, as I'm sure there are hidden gotchas.

Another potential workaround to the concurrent replication problem is to modify StatefulInstanceInterceptor to require a lock on the parent bean before an invocation can proceed.  Serialize the requests to A, B, C.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008849#4008849

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008849


From do-not-reply at jboss.com  Wed Jan 31 11:53:30 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Wed, 31 Jan 2007 11:53:30 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JGroups configuration for clustering testing
Message-ID: <19543597.1170262410728.JavaMail.jboss@colo-br-02.atl.jboss.com>

We don't need to change code for this...  just config files.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008858#4008858

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008858


From do-not-reply at jboss.com  Wed Jan 31 12:05:00 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 31 Jan 2007 12:05:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBAS-1434 Part 2
Message-ID: <15196823.1170263100369.JavaMail.jboss@colo-br-02.atl.jboss.com>

"weston.price at jboss.com" wrote : 
  | Also, as we all know, the old JMSContainerInvoker allowed for creating destinations when a listener was being deployed without one. EJB3 carries this tradition over for EJB3, but for EJB 2.x the JMS/JCA adapter will not. 
  | 

Its turned off by default in JBoss5 since it is JBossMQ specific.

There is a feature request somewhere to allow JCA admin objects
to be defined in jboss.xml which would replace this bad feature with
something more portable.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008863#4008863

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008863


From do-not-reply at jboss.com  Wed Jan 31 12:12:42 2007
From: do-not-reply at jboss.com (weston.price@jboss.com)
Date: Wed, 31 Jan 2007 12:12:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBAS-1434 Part 2
Message-ID: <7584652.1170263562257.JavaMail.jboss@colo-br-02.atl.jboss.com>

Technically, it would be nice to eliminate the JMSProviderAdapter all together and just extend the JmsActivationSpec to include the necessary information to acquire the connection factory, destination etc. This would eliminate another semi non-portable mechanism. 

Again, this doesn't solve the auto create destination thing (which again, I think is just a bad idea to begin with), but it would go a long way to making the JMS/JCA adapter more relevant in other environments. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008870#4008870

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008870


From do-not-reply at jboss.com  Wed Jan 31 12:15:26 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 31 Jan 2007 12:15:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re:
	XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2
Message-ID: <13871413.1170263726492.JavaMail.jboss@colo-br-02.atl.jboss.com>

The issue came up because the old TM throws RollbackException
when resources cannot be ended, the new TM throws IllegalStateException.

This is not catered for in TxInterceptorCMT:

  | 
  |       try
  |       {
  |          // Marked rollback
  |          if (tx.getStatus() == Status.STATUS_MARKED_ROLLBACK)
  |          {
  |             tx.rollback();
  |          }
  |          else
  |          {
  |             // Commit tx
  |             // This will happen if
  |             // a) everything goes well
  |             // b) app. exception was thrown
  |             tx.commit();
  |          }
  |       }
  |       catch (RollbackException e)
  |       {
  |          throwJBossException(e, invocation.getType());
  |       }
  |       catch (HeuristicMixedException e)
  |       {
  |          throwJBossException(e, invocation.getType());
  |       }
  |       catch (HeuristicRollbackException e)
  |       {
  |          throwJBossException(e, invocation.getType());
  |       }
  |       catch (SystemException e)
  |       {
  |          throwJBossException(e, invocation.getType());
  |       }
  | 

So the EJB caller doesn't get the same exeption
"JBossTransactionRollbackException".

This needs including in the following work:
http://jira.jboss.com/jira/browse/JBAS-3633
as a general tidying up the exception handling logging
with the changed TM semantics.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008872#4008872

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008872


From do-not-reply at jboss.com  Wed Jan 31 12:35:07 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 31 Jan 2007 12:35:07 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Bug
	in Sun compiler?
Message-ID: <2504074.1170264907530.JavaMail.jboss@colo-br-02.atl.jboss.com>

I originally found it with a standalone enum.

I've reported it as a bug. I did find a bug report that asked
for the opposite in apt (don't show the synthetic parameters)
 so I guess they hacked the compiler to not annotate the class properly. :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008879#4008879

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008879


From do-not-reply at jboss.com  Wed Jan 31 12:45:20 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 31 Jan 2007 12:45:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Scoped beans deployment
Message-ID: <7810003.1170265520118.JavaMail.jboss@colo-br-02.atl.jboss.com>

The idea is to be able define a sub-kernel in the scoped metadata.


  | Kernel kernel = MetaData.getMetaData(Kernel.class);
  | 

Then it needs two changes:

1) Either modifying the KernelController or create a subclass
that understands delegation from sub-kernel to parent kernels

A bean in a sub-kernel can depend upon a bean in a parent kernel
but not the other way around!

2) Adding something to the kernel deployment that says you want your
own private kernel for this deployment.

Something like:


  | <deployment kernel="private">
  |    <bean ....>
  | </deployment>
  | 

Although I think a more general notion would come out of the work
we need to do to define scoped metadata, probably by annotating the
deployment or bean?

e.g. define these beans in the jca subsystem scope

  | <deployment>
  |    <annotation>@org.jboss.metadata.scope.Subsystem("jca")</annotation>
  |    <bean ....>
  | </deployment>
  | 

For the metadata there already is a thread local to get the current context:

  | MetaData metaData = MetaDataStack.peek();
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008883#4008883

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008883


From do-not-reply at jboss.com  Wed Jan 31 13:07:20 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Wed, 31 Jan 2007 13:07:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Scoped beans deployment
Message-ID: <16649209.1170266840469.JavaMail.jboss@colo-br-02.atl.jboss.com>

I was looking at Seam and their concepts of scopes.  He has differently deployed components that are deployed statically, but are created as part of a particular scope: i.e. A Session or a Conversation.  So, when a particular Scope is created (i.e. a Session) the component is instantiated and configured based on the component.xml file.

In MC land, this would translate to describing each bean deployed to a particular scope and this meta cloned to a new kernel that finally installs the beans.

It would be cool to get the things that make sense that are duplicated in Seam into MC so we can unify things.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008891#4008891

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008891


From do-not-reply at jboss.com  Wed Jan 31 13:08:32 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Wed, 31 Jan 2007 13:08:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Scoped beans deployment
Message-ID: <25054349.1170266912498.JavaMail.jboss@colo-br-02.atl.jboss.com>

Here's some notes I jotted down when looking at SEam:

* Context/scope aware kernel
- ability to define components and attach them to a scope
- metadata would set in scope definition and not execute to expliclity created.
- can inject between scopes.  One scope can override another scope with bean definition.
- almost "federated" but a little different as you can declare beans of different scopes in the same file.
- maybe starting off with federation is the correct way.  With a kernel having a parent and children kernels.
- scope/context is a bit different than federation.  You'd want the base template of the scope/context defined in bean.xml and you want to ask the kernel to create you a specific scope/context.  So scope/context may be implemented via federation, but the kernel would have to know about the scope.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008893#4008893

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008893


From do-not-reply at jboss.com  Wed Jan 31 13:08:57 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 31 Jan 2007 13:08:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JCA on JBoss] - Re: JBAS-1434 Part 2
Message-ID: <26617124.1170266937876.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yes, the modern approach should be to bind connection factories into jndi
as admin objects. You could then just reference the jndi name from
the activation config.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008894#4008894

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008894


From do-not-reply at jboss.com  Wed Jan 31 13:09:10 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 31 Jan 2007 13:09:10 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - JBoss configuration
	build
Message-ID: <14394293.1170266950638.JavaMail.jboss@colo-br-02.atl.jboss.com>

If you run the create.jbpm.server.config ant task in jbpm.3/jboss/configuration, it deletes the whole jboss installation that is located at ${jboss.home}.

If you set ${jboss.home} to be a non-existant directory, the build fails.

Why is this directory required to exist if it is only going to be deleted?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008896#4008896

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008896


From do-not-reply at jboss.com  Wed Jan 31 13:12:58 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Wed, 31 Jan 2007 13:12:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] -
	Precedence level
Message-ID: <24904129.1170267178426.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm looking at the Seam component model to see how it could be merged with MC.  Here's an interesting feature they got.

When you deploy a component, it can have both dependencies as well as a precedence level.  Basically the precedence level is a numerical value of where in the chain the component should be deployed.  Gavin uses this so that somebody could say:  "I want this component deployed after all Seam BUILT IN components".

Maybe we could translate this into logical groupings of beans:


  | <bean name="Foo" group="BUILT IN" .../>
  | <bean name="Bar" group="BUILT IN" .../>
  | 
  | 
  | <bean name="MyStuff">
  |    <depends-group>BUILT IN</depends-group>
  | </bean>
  | 

"MyStuff" would have a logical dependency to Foo and Bar through the "BUILT IN" tag.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008899#4008899

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008899


From do-not-reply at jboss.com  Wed Jan 31 13:16:04 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Wed, 31 Jan 2007 13:16:04 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Class
	dependencies
Message-ID: <18478676.1170267364770.JavaMail.jboss@colo-br-02.atl.jboss.com>

Yet another thing from Seam.

Seam components can state that if a certain class is not in the classpath, then don't deploy them.  Sound like an interesting feature?


  | <bean name="foo" class="org.drools.Shit" load-if-class-not-available="false"/>
  | 

I think this is another example of the "ON DEMAND" mode except that the user turns off the bean by removing "drools" from the classpath.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008904#4008904

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008904


From do-not-reply at jboss.com  Wed Jan 31 13:21:40 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Wed, 31 Jan 2007 13:21:40 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <16434442.1170267700043.JavaMail.jboss@colo-br-02.atl.jboss.com>

For a nested structure, again, I think we need the concept of ownership and relatively the same code that already exists with the proxy context.

At first, the parent SFSB owns all the children.  If a child is "touched" by an invocation, it must ping the parent to replicate the whole tree: parent and all its children.

If the parent is removed, a child is picked as the new "parent".

As for your concurrency problem.  I don't think we should code for this and document that that scenario is not supported.  SFSBs are supposed to be used by one client, not multiple clients concurrently.  This will make things easier IMO.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008905#4008905

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008905


From do-not-reply at jboss.com  Wed Jan 31 13:25:41 2007
From: do-not-reply at jboss.com (tom.baeyens@jboss.com)
Date: Wed, 31 Jan 2007 13:25:41 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: JBoss configuration
	build
Message-ID: <182253.1170267941094.JavaMail.jboss@colo-br-02.atl.jboss.com>

maybe it is the parent directory of ${jboss.home} that needs to exist.  it's in the parent directory that the jboss zip file is unzipped.

does the ant script itself give a clue ?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008911#4008911

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008911


From do-not-reply at jboss.com  Wed Jan 31 13:26:47 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 31 Jan 2007 13:26:47 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Scoped beans deployment
Message-ID: <30776183.1170268007751.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bill.burke at jboss.com" wrote : 
  | In MC land, this would translate to describing each bean deployed to a particular scope and this meta cloned to a new kernel that finally installs the beans.
  | 

The same feature has also been requested by jbpm.
Although there it is more related to scoped factory references that pass under the wire.

And there are multiple runtime scopes e.g. a process is long running
but can have subtasks that override the process with different factories.

The basic code would then look something like:


  | // Get the current metadata 
  | MetaData metaData = MetaDataStack.peek();
  | 
  | // Get the controller
  | KernelController controller = metaData.getMetaData(Kernel.class).getController();
  | 
  | // Get the factories and create the objects
  | SomeFactory factory1 = controller.getInstance("SomeFactory").getTarget();
  | MyObject1 object = factory1.create();
  | AnotherFactory factory2 = controller.getInstance("AnotherFactory").getTarget();
  | MyObject2 object = factory2.create();
  | 

Incidently, it would look much nicer if the scope included a MetaDataLoader
that just delegated to the local kernel, i.e. it did the wiring above inside the
MetaDataLoader.


  | // Get the current metadata 
  | MetaData metaData = MetaDataStack.peek();
  | 
  | // Get the factories and create the objects
  | SomeFactory factory1 = metaData.getMetaData(SomeFactory.class);
  | MyObject1 object = factory1.create();
  | AnotherFactory factory1 = metaData.getMetaData(AnotherFactory.class);
  | MyObject2 object = factory2.create();
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008912#4008912

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008912


From do-not-reply at jboss.com  Wed Jan 31 13:28:23 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 31 Jan 2007 13:28:23 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Scoped beans deployment
Message-ID: <21109190.1170268103829.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : "bill.burke at jboss.com" wrote : 
  |   | Although there it is more related to scoped factory references
  |   | 
  | 
  | The advantages of using factories is that you get late binding of injections
  | during the "create()" not when you define the beans in the kernel.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008914#4008914

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008914


From do-not-reply at jboss.com  Wed Jan 31 13:30:03 2007
From: do-not-reply at jboss.com (estaub)
Date: Wed, 31 Jan 2007 13:30:03 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Support for Bean
	Scripting Framework (BSF)
Message-ID: <32196183.1170268203506.JavaMail.jboss@colo-br-02.atl.jboss.com>

Ronald van Kuijk (mis)posted "isn't there a JSR for pluggable scripting?" on another thread (http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008880).

Oops - yes, there is - JSR-223 (https://scripting.dev.java.net/).
I didn't realize it was so far advanced.

I'll use it if possible.

(Thanks, Ronald!)

-Ed Staub


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008915#4008915

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008915


From do-not-reply at jboss.com  Wed Jan 31 13:37:54 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 31 Jan 2007 13:37:54 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: JBoss configuration
	build
Message-ID: <28043910.1170268674991.JavaMail.jboss@colo-br-02.atl.jboss.com>

"tom.baeyens at jboss.com" wrote : maybe it is the parent directory of ${jboss.home} that needs to exist.  it's in the parent directory that the jboss zip file is unzipped.
  | 
  | does the ant script itself give a clue ?

In this case, the parent does exist.  Looking in depth I think this is the problem:

  <target name="clean.jboss.install" description="deletes the current jboss installation at ${jboss.home}">
  |     <delete dir="${jboss.home}" />
  |   </target>

The problems here are:

* The  will fail on error
* This task is executed by default - perhaps it is better to fail if the directory exists rather than delete it automatically, and let the user manually delete or rename the directory if it does exist


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008920#4008920

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008920


From do-not-reply at jboss.com  Wed Jan 31 13:38:49 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 31 Jan 2007 13:38:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Scoped beans deployment
Message-ID: <10072526.1170268729664.JavaMail.jboss@colo-br-02.atl.jboss.com>

The other piece is linking in the AOP domain concept into the scope.
i.e. so you can do the same thing with aspect definitions.

e.g. Being able to define advices for jdbc objects that only apply when
the jdbc object is used inside JCA.
User's jdbc objects would be unadvised.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008921#4008921

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008921


From do-not-reply at jboss.com  Wed Jan 31 13:43:50 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 31 Jan 2007 13:43:50 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Class
	dependencies
Message-ID: <4934771.1170269030445.JavaMail.jboss@colo-br-02.atl.jboss.com>

Somewhat, but then how is this reflected in the profile and exposed via management interfaces? Its hard to deal with something that does not exist. There would have to be some unresolved bean notion that does not fail a deployment when its validated.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008922#4008922

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008922


From do-not-reply at jboss.com  Wed Jan 31 13:43:56 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 31 Jan 2007 13:43:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Precedence level
Message-ID: <11897908.1170269036600.JavaMail.jboss@colo-br-02.atl.jboss.com>

The problem with this is that it works fine for Seam or Spring where you
are only dealing with a single application with a fixed set of deployments.

The MC has to deal with hotdeployment where beans can be added at anytime.

e.g. suppose we define a jboss-jca group so you can depend upon
all of jca being deployed, but then you add a new rar to the jboss-jca group?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008923#4008923

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008923


From do-not-reply at jboss.com  Wed Jan 31 13:43:57 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 31 Jan 2007 13:43:57 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Web console changes
	- IMPORTANT
Message-ID: <25560470.1170269037686.JavaMail.jboss@colo-br-02.atl.jboss.com>

I verified that the above form (the second one) with ui:component instead of ui:fragment does work.

Also I removed the comment (which was mainly for the benefit of you, the reader).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008924#4008924

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008924


From do-not-reply at jboss.com  Wed Jan 31 13:46:49 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Wed, 31 Jan 2007 13:46:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Scoped beans deployment
Message-ID: <14567564.1170269209453.JavaMail.jboss@colo-br-02.atl.jboss.com>

Adrian, I'm not grokking here...

I was thinking more of:


  | <deploymen>
  |    <scope name="application">
  |        <bean name="Foo"/>
  |        <scope name="session">
  |             <bean name="bar/>
  |        </scope>
  |    </scope
  | </deployment>
  | 
  | Kernel app= kernel.createScope("Application");
  | Kernel session = app.createScope("session");
  | 

Or something like that.  I hope you get the idea.

All scoped beans would just be described and their metadata deployed into a new kernel when the scope is created.  Child scopes would not be created, but instead registered with the parent scope.





View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008925#4008925

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008925


From do-not-reply at jboss.com  Wed Jan 31 13:47:44 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 31 Jan 2007 13:47:44 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Class
	dependencies
Message-ID: <32221198.1170269264783.JavaMail.jboss@colo-br-02.atl.jboss.com>

This has the same problem as the precedence.

When do you check that the class is available?

Under hotdeployment, the class could be added later and even removed and
redeployed.

When classloading dependencies are implemented (needs integration
between the classloader and the kernel - see other discussions)
a better feature might be to say:


  | <bean ... class="org.drools.Shit" optional="true"/>
  | 

So if the class doesn't exist we don't report it as a missing dependency.
We just don't start the bean until somebody deploys the class.

This would also extend to other dependencies, not just classes.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008927#4008927

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008927


From do-not-reply at jboss.com  Wed Jan 31 13:49:53 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 31 Jan 2007 13:49:53 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Broken
	javassist tests
Message-ID: <3775800.1170269393060.JavaMail.jboss@colo-br-02.atl.jboss.com>

FYI.

Some of the javassist annotation tests are broken.
This is due to a bug in the way its annotation does equals/hashCode.

I've fixed the problem in javassist, but it needs an updated version for
these tests to start working again.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008928#4008928

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008928


From do-not-reply at jboss.com  Wed Jan 31 13:51:52 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 31 Jan 2007 13:51:52 -0500 (EST)
Subject: [jboss-dev-forums] [Javassist development Forum] - FYI: Fixed the
	annotation equals/hashCode
Message-ID: <25477603.1170269512376.JavaMail.jboss@colo-br-02.atl.jboss.com>

I found a bug in the annotation's equals/hashcode processing.

It wasn't following the spec so you couldn't compare them with JDK annotations
or use them in the same collections.

I've fixed it in javassist head.

Related:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008928#4008928

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008930#4008930

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008930


From do-not-reply at jboss.com  Wed Jan 31 13:52:37 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 31 Jan 2007 13:52:37 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Precedence level
Message-ID: <10280239.1170269557867.JavaMail.jboss@colo-br-02.atl.jboss.com>

A dependency + an order is just introduces an implicit dependency on the components in the dependency tree with a lower order. The problem is defining the dependency tree as Adrian points out. We would need some alternate dependency scope notion that could be restricted to the current top-level deployment, as an example.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008931#4008931

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008931


From do-not-reply at jboss.com  Wed Jan 31 13:55:26 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Wed, 31 Jan 2007 13:55:26 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Class
	dependencies
Message-ID: <1613027.1170269726718.JavaMail.jboss@colo-br-02.atl.jboss.com>

don't you have the same issue with "On Demand" stuff?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008935#4008935

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008935


From do-not-reply at jboss.com  Wed Jan 31 14:00:38 2007
From: do-not-reply at jboss.com (bill.burke@jboss.com)
Date: Wed, 31 Jan 2007 14:00:38 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Precedence level
Message-ID: <25039879.1170270039001.JavaMail.jboss@colo-br-02.atl.jboss.com>

anonymous wrote : 
  | e.g. suppose we define a jboss-jca group so you can depend upon
  | all of jca being deployed, but then you add a new rar to the jboss-jca group?

I see your point.  The aliased dependent components would not be allowed to start until a complete scan was complete.  So, you couldn't resolve dependencies until every single deployment in the system had been at least described.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008939#4008939

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008939


From do-not-reply at jboss.com  Wed Jan 31 14:05:00 2007
From: do-not-reply at jboss.com (bstansberry@jboss.com)
Date: Wed, 31 Jan 2007 14:05:00 -0500 (EST)
Subject: [jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with
	passivation of nested SFSBs
Message-ID: <21770048.1170270300848.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bill.burke at jboss.com" wrote : 
  | At first, the parent SFSB owns all the children.  If a child is "touched" by an invocation, it must ping the parent to replicate the whole tree: parent and all its children.

Easily encapsulated in the StatefulReplicationInterceptor.

anonymous wrote : If the parent is removed, a child is picked as the new "parent".

This will be lot of work, for I'm not sure what gain vs. leaving the old parent context in the cache, but marked "removed" and with refs to any unneeded state nulled out. You've got to:

1) Pick a child (ok, trivial)
2) Move the data to the child (not sure if there are any integration issues)
3) Add all of the parent's children to the new "semi-parent".
4) Notify all the children of the new semi-parent
5) Do a lookup of the ProxiedStatefulBeanContext of each of the children (no direct ref to it) and modify it to point to the new parent.
6) Replace the cached context for the new "semi-parent" so it's no longer a ProxiedStatefulBeanContext, but rather a regular one (otherwise any calls to the new parent will fail).
7) Replicate every affected context so the rest of the cluster knows what you did.  Probably should do this in a tx.

anonymous wrote : As for your concurrency problem.  I don't think we should code for this and document that that scenario is not supported.  SFSBs are supposed to be used by one client, not multiple clients concurrently.  This will make things easier IMO.

:-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008942#4008942

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008942


From do-not-reply at jboss.com  Wed Jan 31 14:08:11 2007
From: do-not-reply at jboss.com (heiko.braun@jboss.com)
Date: Wed, 31 Jan 2007 14:08:11 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss Web Services] - Re: SOAP
	request missing namespace
Message-ID: <32159799.1170270491803.JavaMail.jboss@colo-br-02.atl.jboss.com>

Please post these questions to the user forum:
 http://www.jboss.org/index.html?module=bb&op=viewforum&f=200

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008944#4008944

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008944


From do-not-reply at jboss.com  Wed Jan 31 14:13:05 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 31 Jan 2007 14:13:05 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Scoped beans deployment
Message-ID: <13442311.1170270785646.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bill.burke at jboss.com" wrote : Adrian, I'm not grokking here...

See the scoped metadata in org.jboss.metadata in the container project
and its integration with the MC which was discussed/done within the last
couple of months.

anonymous wrote : 
  | 
  |    
  |        
  |        
  |             <bean name="bar/>
  |        
  |    </scope
  | 
  | 

That won't work because you define the scopes hierarchically
but also somewhat randomly (even without introducing session/thread/transaction/converstation/etc. :-)

e.g. You can have a bean scope
myapplication/mydeployment1/mybean1
myapplication/mydeployment1/mybean2
myapplication/mydeployment2/mybean1

But you also want to be able to define it in code, e.g. adding beans
to a subsystem scope which isn't part of a deployment but deployments
can be in that subsystem.

e.g. I know this part of the jca code goes in the jboss-jca subsystem scope

  | @org.jboss.metadata.scope.Subsystem("jboss-jca")
  | public class MyJCAImplementationObject {}
  | 

So it needs to be abitrary scope annotations against the bean
(and the deployment for convenience).

anonymous wrote : 
  | Kernel app= kernel.createScope("Application");
  | Kernel session = app.createScope("session");
  | 

Yes, you need to be able to create a child kernel
see my point (1) in the first response,
but you also need to add it to the MetaData scope
otherwise how does somebody which kernel to use in an abitrary context.

That is the purpose of the MetaData/MetaDataStack.

NOTE: This is all very speculative since besides maintaining the
MetaDataRepository yourself in some code none of this exists.
i.e. there is nothing that says I want to deploy this metadata into this scope.
That is what I meant before when I said:
"Although I think a more general notion would come out of the work
we need to do to define scoped metadata".

The repository exists with all the plumbing, but there is nothing to fill it! :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008952#4008952

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008952


From do-not-reply at jboss.com  Wed Jan 31 14:21:15 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 31 Jan 2007 14:21:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Class
	dependencies
Message-ID: <23051325.1170271275465.JavaMail.jboss@colo-br-02.atl.jboss.com>

No because "On Demand" doesn't "On Undemand". :-)

If somebody references the bean we deploy it, but we don't undeploy it
when it is de-referenced.

That is mainly because it would wasted effort if the referencer is just redeloying.

For class dependencies the issue is different. You have to redeploy if the class changes
or undeploy if the class is removed.

It's not difficult, the semantics are just a bit exacting.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008956#4008956

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008956


From do-not-reply at jboss.com  Wed Jan 31 14:23:42 2007
From: do-not-reply at jboss.com (adrian@jboss.org)
Date: Wed, 31 Jan 2007 14:23:42 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Precedence level
Message-ID: <2892532.1170271422499.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bill.burke at jboss.com" wrote : So, you couldn't resolve dependencies until every single deployment in the system had been at least described.

Which is something that could only be defined with reference to something
like the profile service.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008958#4008958

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008958


From do-not-reply at jboss.com  Wed Jan 31 14:52:32 2007
From: do-not-reply at jboss.com (petemuir)
Date: Wed, 31 Jan 2007 14:52:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Precedence level
Message-ID: <10662841.1170273152360.JavaMail.jboss@colo-br-02.atl.jboss.com>

"bill.burke at jboss.com" wrote : When you deploy a component, it can have both dependencies as well as a precedence level.  Basically the precedence level is a numerical value of where in the chain the component should be deployed.  Gavin uses this so that somebody could say:  "I want this component deployed after all Seam BUILT IN components".

Just to clarify, precedence is actually used to say "I want this component used INSTEAD OF this other component (with the same name)".  So if I had a built-in-to-seam component foo (precedence 0) and a component I had developed also called foo, but with precedence 40, my component would get used instead of the built in one (both by Seam and by my app).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008975#4008975

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008975


From do-not-reply at jboss.com  Wed Jan 31 14:53:58 2007
From: do-not-reply at jboss.com (aaubryfr)
Date: Wed, 31 Jan 2007 14:53:58 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss ESB] - Feedback needed on JBoss
	ESB
Message-ID: <28403934.1170273238390.JavaMail.jboss@colo-br-02.atl.jboss.com>

Hi to Jboss community!

I'd like to have a feedback about JBoss ESB platform.
I need to start an integration project with my IT and en external provider. That integration will be base on file integration and transformation.

Does JBoss ESB fit this goal?
What about dev productivity?
What about monitoring the platform?

Any feedback?

Alexandre Aubry
IT manager

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008976#4008976

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008976


From do-not-reply at jboss.com  Wed Jan 31 15:10:34 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 31 Jan 2007 15:10:34 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Registering a bean as an aspect in the bootstrap
Message-ID: <3256759.1170274234554.JavaMail.jboss@colo-br-02.atl.jboss.com>

I'm also having problems with the bootstrap xml intercepting some classes. For example, if I add an org.jboss.deployers.spi.attachments.Attachments interceptor:


  |     <bean name="AspectManager" class="org.jboss.aop.deployers.AspectManagerJDK5">
  |         <constructor>
  |             <parameter><![CDATA[
  | 	         <aop>
  | 					<aspect name="deployers" class="org.jboss.profileservice.aop.DeployerAspects"/>
  | 					<bind pointcut="execution(* $instanceof{org.jboss.deployers.spi.deployer.Deployer}->*(..))">
  | 				      <advice name="invoke" aspect="deployers"/>							         
  | 				   </bind>
  | 			      <aspect name="mainDeployer" class="org.jboss.profileservice.aop.MainDeployerAspect"/>
  | 					<bind pointcut="execution(* $instanceof{org.jboss.deployers.spi.deployment.MainDeployer}->process(..))">
  | 				      <advice name="process" aspect="mainDeployer"/>
  | 				   </bind>
  | 					<aspect name="track" class="org.jboss.profileservice.aop.TrackingAdvice"/>
  |                <bind pointcut="execution(* $instanceof{org.jboss.deployers.spi.attachments.Attachments}->addAttachment(..))">
  |                   <advice name="invoke" aspect="track"/>
  |                </bind>
  | 				</aop>]]>
  |             </parameter>
  |         </constructor>
  | 
  | 

This is not applied. I had to go into one particular usage context (AbstractDeploymentContext) and wrap the Attachments instance I wanted to inercept in an aop proxy in order for the above aspect to be applied. 


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008988#4008988

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008988


From do-not-reply at jboss.com  Wed Jan 31 15:12:29 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 31 Jan 2007 15:12:29 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Test graveyard
Message-ID: <30261227.1170274349488.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have created a directory messaging/graveyard into which we should put any test java files that are no longer valid (instead of deleting them).

If only some of the tests in an individual test file are invalid they can be cut and pasted into GraveyardTest.

These will then be automatically excluded from the test run.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008990#4008990

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008990


From do-not-reply at jboss.com  Wed Jan 31 17:25:20 2007
From: do-not-reply at jboss.com (scott.stark@jboss.org)
Date: Wed, 31 Jan 2007 17:25:20 -0500 (EST)
Subject: [jboss-dev-forums] [Design of POJO Server] - Not keeping track of
	deployment class loader
Message-ID: <32200945.1170282320195.JavaMail.jboss@colo-br-02.atl.jboss.com>

I finally looked into a shutdown error I have been seeing with the repository based profile service. There is a CNFE thrown from the deployers/profileservice-beans.xml ProxyFactory due to the incorrect TCL:


  | 14:12:48,161 WARN  [StartStopLifecycleAction] Error during stop for ProfileServiceProxyFactory
  | javax.naming.NoInitialContextException: Cannot instantiate class: org.jnp.interfaces.NamingContextFactory [Root exception is java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory]
  |         at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:657)
  |         at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
  |         at javax.naming.InitialContext.init(InitialContext.java:223)
  |         at javax.naming.InitialContext.<init>(InitialContext.java:175)
  |         at org.jboss.profileservice.remoting.ProxyFactory.stop(ProxyFactory.java:150)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  |         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  |         at java.lang.reflect.Method.invoke(Method.java:585)
  |         at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:55)
  |         at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:108)
  |         at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
  |         at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103)
  |         at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:167)
  |         at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.uninstallAction(KernelControllerContextAction.java:243)
  |         at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.uninstall(KernelControllerContextAction.java:180)
  |         at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
  |         at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:240)
  |         at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:723)
  |         at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:685)
  |         at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:615)
  |         at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:663)
  |         at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:615)
  |         at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:663)
  |         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:325)
  |         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
  |         at org.jboss.system.ServiceController.doChange(ServiceController.java:656)
  |         at org.jboss.system.ServiceController.stop(ServiceController.java:481)
  |         at org.jboss.system.deployers.ServiceDeployer.stop(ServiceDeployer.java:149)
  |         at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:129)
  |         at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:46)
  |         at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.undeploy(AbstractSimpleRealDeployer.java:64)
  |         at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.prepareUndeploy(AbstractSimpleDeployer.java:42)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  |         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  |         at java.lang.reflect.Method.invoke(Method.java:585)
  |         at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:121)
  |         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:110)
  |         at org.jboss.profileservice.aop.DeployerAspects.prepareUndeploy(DeployerAspects.java:203)
  |         at org.jboss.profileservice.aop.DeployerAspects.invoke(DeployerAspects.java:100)
  |         at org.jboss.aop.advice.org.jboss.profileservice.aop.DeployerAspects_z_invoke_1601866242.invoke(DeployerAspects_z_invoke_1601866242.java)
  |         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
  |         at AOPContainerProxy$8.prepareUndeploy(AOPContainerProxy$8.java)
  |         at org.jboss.deployers.plugins.deployer.DeployerWrapper.prepareUndeploy(DeployerWrapper.java:130)
  |         at org.jboss.deployers.plugins.deployment.MainDeployerImpl.prepareUndeploy(MainDeployerImpl.java:517)
  |         at org.jboss.deployers.plugins.deployment.MainDeployerImpl.prepareUndeploy(MainDeployerImpl.java:526)
  |         at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:448)
  |         at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:406)
  |         at org.jboss.deployers.plugins.deployment.MainDeployerImpl.shutdown(MainDeployerImpl.java:634)
  |         at AOPContainerProxy$6.shutdown(AOPContainerProxy$6.java)
  |         at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:767)
  |         at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:749)
  |         at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.run(ServerImpl.java:716)
  | Caused by: java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory
  |         at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
  |         at java.security.AccessController.doPrivileged(Native Method)
  |         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
  |         at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
  |         at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
  |         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
  |         at java.lang.Class.forName0(Native Method)
  |         at java.lang.Class.forName(Class.java:242)
  |         at com.sun.naming.internal.VersionHelper12.loadClass(VersionHelper12.java:42)
  |         at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:654)
  |         ... 53 more
  | 

On startup we have a hack in the ProfileServiceBootstrap to take the first bootstrap DeploymentContext as the base TCL. I suppose the ShutdownHook should be going through the profile service to shutdown the deployments in phases and employ the same hack, but shouldn't there be an association in the ControllerContext to the install action class loader if it came from the TCL rather than the BeanMetaData?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009075#4009075

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009075


From do-not-reply at jboss.com  Wed Jan 31 17:42:56 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 31 Jan 2007 17:42:56 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Re: Build problem in
	Linux
Message-ID: <10154946.1170283376268.JavaMail.jboss@colo-br-02.atl.jboss.com>

This problem is fixed - the build target of the build/build.xml was calling into a nonexistant subproject build.xml.  I was going to post a fix... but Tom got there ahead of me.  Looks like he made a couple other fixes to.

It works now in any case.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009087#4009087

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009087


From do-not-reply at jboss.com  Wed Jan 31 17:47:24 2007
From: do-not-reply at jboss.com (alesj)
Date: Wed, 31 Jan 2007 17:47:24 -0500 (EST)
Subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Re:
	Scoped beans deployment
Message-ID: <31772078.1170283644192.JavaMail.jboss@colo-br-02.atl.jboss.com>

"adrian at jboss.org" wrote : Although I think a more general notion would come out of the work
  | we need to do to define scoped metadata, probably by annotating the
  | deployment or bean? 
  | 
I think it's better if we go from the start into the direction of annotation support.

"adrian at jboss.org" wrote : 
  | That is what I meant before when I said:
  | "Although I think a more general notion would come out of the work
  | we need to do to define scoped metadata".
  | 
  | The repository exists with all the plumbing, but there is nothing to fill it! :-)
If we/you can get some (semi) clear picture where and how we want this plumbing to happen, I can go and code some initial ideas - so that we can see what fits us best. And I can test this with our OSGi project (as previously mentioned requirement).




View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009088#4009088

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009088


From do-not-reply at jboss.com  Wed Jan 31 18:45:43 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Wed, 31 Jan 2007 18:45:43 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- JORAM Test failing
Message-ID: <13303327.1170287143418.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have this integration JORAM-test failing on jboss-head:



  |             receiverConnection.stop();
  |             receiverSession = receiverConnection.createQueueSession(false, Session.CLIENT_ACKNOWLEDGE);
  |             receiver = receiverSession.createReceiver(receiverQueue);
  |             receiverConnection.start();
  | 
  |             Message message = senderSession.createMessage();
  |             sender.send(message);
  | 
  |             // no sleep here..
  | 
  |             Message m = receiver.receive(0); << -- sometimes it never leave receive.
  | 
  |            System.out.println("message received");
  |             receiverConnection.close();
  |             m.acknowledge(); // this should throw an exception
  | 

I wrote a similar test-case in our SVN and it is not failing.

Any idea if this would fail in 1.0 GA?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009118#4009118

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009118


From do-not-reply at jboss.com  Wed Jan 31 18:50:27 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 31 Jan 2007 18:50:27 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JORAM Test failing
Message-ID: <23531091.1170287427877.JavaMail.jboss@colo-br-02.atl.jboss.com>

This is an invalid test for the same reasons we discussed the other day, if you remember.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009119#4009119

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009119


From do-not-reply at jboss.com  Wed Jan 31 19:07:49 2007
From: do-not-reply at jboss.com (clebert.suconic@jboss.com)
Date: Wed, 31 Jan 2007 19:07:49 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JORAM Test failing
Message-ID: <9649519.1170288469174.JavaMail.jboss@colo-br-02.atl.jboss.com>

This one is different...

it should wait forever... until the message arrives.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009128#4009128

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009128


From do-not-reply at jboss.com  Wed Jan 31 20:56:32 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 31 Jan 2007 20:56:32 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: JORAM Test failing
Message-ID: <13454987.1170294992652.JavaMail.jboss@colo-br-02.atl.jboss.com>

Sorry, my mistake. This test should pass in all JBM versions.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009160#4009160

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009160


From do-not-reply at jboss.com  Wed Jan 31 20:58:15 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 31 Jan 2007 20:58:15 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- New wireformat
Message-ID: <24190525.1170295095802.JavaMail.jboss@colo-br-02.atl.jboss.com>

I have committed the refactoring of our wireformat.

Gone is the ugly if...else ladder matching on method names, and in is a set of new request and response objects encapsulating each request, response.

I think you'll find it's much cleaner and OO now.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009161#4009161

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009161


From do-not-reply at jboss.com  Wed Jan 31 21:27:13 2007
From: do-not-reply at jboss.com (timfox)
Date: Wed, 31 Jan 2007 21:27:13 -0500 (EST)
Subject: [jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)]
	- Re: Bug in transactional delivery in an MDB
Message-ID: <26099720.1170296834003.JavaMail.jboss@colo-br-02.atl.jboss.com>

This is now fixed in TRUNK.

I still need to backport the fix to 1.0

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009170#4009170

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009170


From do-not-reply at jboss.com  Wed Jan 31 21:50:17 2007
From: do-not-reply at jboss.com (david.lloyd@jboss.com)
Date: Wed, 31 Jan 2007 21:50:17 -0500 (EST)
Subject: [jboss-dev-forums] [Design of JBoss jBPM] - Bug in token actions in
	process instance view of the console
Message-ID: <15411419.1170298217025.JavaMail.jboss@colo-br-02.atl.jboss.com>

I did some more testing with different mockup processes and I found a bug in how tokens are signalled, cancelled, and moved by the ProcessInstanceBean.  Basically the action class holds a reference to the old instance of the managed bean that it uses for certain things, causing the part of the transaction to possibly be executed on an old jbpmContext, which would then fail.

I have reorganized some of that code to handle JbpmContexts more correctly, and I ported the token signalling to use this structure and the problem is now fixed.  Tomorrow I will go through and update the remainder of the actions similarly, and go through another round of testing.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009180#4009180

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009180