[Design of JCA on JBoss] - jaxb whitepsace handling
by scott.stark＠jboss.org
Is there a way to get jaxb to trim string data? I'm seeing a problem with the parsing of the jmx or the connection-factories/tx-connection-factory/connection-definition is failing to be mapped correctly because it contains the newlines from the xml:
| <connection-factories>
| <tx-connection-factory>
| <jndi-name>QueueConnectionFactory</jndi-name>
| <rar-name>jms-ra.rar</rar-name>
| <connection-definition>
| org.jboss.resource.adapter.jms.JmsConnectionFactory
| </connection-definition>
| ...
|
Also, the fields for the associated TxConnectionFactoryDeploymentMetaData are set directly rather than going through the javabean accessors, so I can't intercept and trim there. Is there a way to change the whitespace handling for a field?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063330#4063330
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063330
18 years, 9 months
[Design of JBoss Build System] - Re: jboss-head build testsuite action plan
by scott.stark＠jboss.org
"rrajesh" wrote : This algorithm would work fine for build breakages. However one issue when we rollback the commits to a previous working version, we might lose the commits that were done after the build started; which would have ideally been included in the next build.
| In that case, can we rollback to the previous working version and then apply the commits that were done after this build started?
|
In general the commits made after the build are invalid as they could rely on changes that need to be rolled back. The main issue is how are the rolled back changes identified and the responsible parties notified so that the breakage is fixed soon.
"rrajesh" wrote :
| For testsuite regressions,
| * We need to get in place a notion of known failures, to actually track the regressions.
| And, is rolling back the commits, a right option for testsuite regressions as well?
|
Not all tests are equal, which is why I only wanted to see this validated against integration tests where a failure means some contract usage is broken.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063274#4063274
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063274
18 years, 9 months
[Javassist development Forum] - Advanced Classloader issue w Drools
by atdixon
I'm using Drools 4.0.0.12865MR3.
I have a rules file "Foo.drl" and class "com.foo.Foo" that I'd like to load and execute rules against. However, I potentially need to load Foo in the same VM using two different classloaders, CL1 and CL2. (The underlying use case is one in which I'm doing dynamic class generation.)
Drools will fail with the below exception if I attempt to build afresh and execute my rules in the same VM but loading the class with a second class loader. See code and exception below.
NOTE. The first execution (using CL1) succeeds. It seems that Drools is maintaining some kind of internal state/cache of some dynamically generated classes that causes it to fail when loading using the second classloader.
| public void go() throws Exception {
| // Save original classloader
| ClassLoader original = Thread.currentThread().getContextClassLoader();
|
| // Create Classloader 1 with parent of original
| FooClassLoader loader1 = new FooClassLoader(original);
| Thread.currentThread().setContextClassLoader(loader1);
| testRules();
|
| // Create Classloader 2 with parent of original
| FooClassLoader loader2 = new FooClassLoader(original);
| Thread.currentThread().setContextClassLoader(loader2);
| testRules();
|
| // Restore
| Thread.currentThread().setContextClassLoader(original);
| }
|
| private void testRules() throws Exception {
| PackageBuilder builder = new PackageBuilder();
| Package pkg = buildPackage(new String[] { "Foo.drl" }, builder);
| RuleBase base = RuleBaseFactory.newRuleBase();
| base.addPackage(pkg);
| StatelessSession session = base.newStatelessSession();
| final ClassLoader loader = Thread.currentThread().getContextClassLoader();
| Object inst = loader.loadClass("com.foo.Foo").newInstance();
| session.execute(new Object[] { inst });
| }
|
[1] Found foo : foo
Exception in thread "main" java.lang.ClassCastException: adixon.prototype.rules.classloader.demo.copy.FooShadowProxy
at org.drools.base.adixon.prototype.rules.classloader.demo.copy.Foo$getName.getValue(Unknown Source)
at org.drools.base.ClassFieldExtractor.getValue(ClassFieldExtractor.java:94)
at org.drools.base.evaluators.StringFactory$StringEqualEvaluator.evaluate(StringFactory.java:85)
at org.drools.rule.LiteralRestriction.isAllowed(LiteralRestriction.java:61)
at org.drools.rule.LiteralConstraint.isAllowed(LiteralConstraint.java:82)
at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:121)
at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:159)
at org.drools.reteoo.Rete.assertObject(Rete.java:175)
at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:772)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:584)
at org.drools.reteoo.ReteooStatelessSession.execute(ReteooStatelessSession.java:63)
at adixon.prototype.rules.classloader.demo.copy.Driver.testRules(Driver.java:47)
at adixon.prototype.rules.classloader.demo.copy.Driver.go(Driver.java:33)
at adixon.prototype.rules.classloader.demo.copy.Driver.main(Driver.java:17)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063260#4063260
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063260
18 years, 9 months
[Design of JBossCache] - SingletonStoreCacheLoader: upgrade to java.util.concurrent?
by galder.zamarreno＠jboss.com
I was just about to finish http://jira.jboss.com/jira/browse/JBCACHE-1091 when I have realised that SingletonStoreCacheLoader was still developed under the old Threading model. Seeing as I'm reading the JCIP book, I thought it'd be good to change SingletonStoreCacheLoader to use java.util.concurrent classes.
I then realised that actually, with java.util.concurrent, I can now set a timeout to the in-memory state push to cache loader very easily with a Future, which would be a nice add on to singleton store. This is currently implemented via a Thread.join().
All this has lead to me think whether XML configuration should still look like this:
| <singletonStore class="org.jboss.cache.loader.SingletonStoreCacheLoader" pushStateWhenCoordinator="false">false</singletonStore>
|
This format probably not the most appropiate going forward, if I wanna add a push timeout and if we look at configuration style used for cacheloaders and buddyreplication.
We're not GA yet, so we still have the chance to change this (although maybe it should have happened during the Beta period)
So, this is the configuration I would suggest going forward:
| <cacheloader>
| ....
| <singletonStore>
| <enabled>true</enabled>
| <class>org.jboss.cache.loader.SingletonStoreCacheLoader</class>
| <pushStateWhenCoordinator timeout="60">true</pushStateWhenCoordinator>
| </singletonStore>
| ...
| <cacheloader>
|
Seeing that we're now providing users with the ability to set the class, maybe we wanna be more flexibles in the way the properties are set for this cache loader, in similar fashion to buddy locator?
| <cacheloader>
| ....
| <singletonStore>
| <enabled>true</enabled>
| <class>org.jboss.cache.loader.SingletonStoreCacheLoader</class>
| <properties>
| pushStateWhenCoordinator = true
| pushStateWhenCoordinatorTimeout = 60
| </properties>
| </singletonStore>
| ...
| <cacheloader>
|
Right now, my preference is with the second one as it allows to extend the implementation and it's corresponding properties/settings in a tidier way.
I think I could have all this done by the end of next week latest.
Thoughts? Manik?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063254#4063254
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063254
18 years, 9 months