April 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: jBPM 4 Emails Sync vs Async

by kukeltje

Yes, sounds like a good decision to me View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223842#4223842 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223842

17 years

1
0
0 / 0

[Design of JBoss jBPM] - jBPM 4 Emails Sync vs Async

by bradsdavis

Alejandro and I were discussing the job executor and the sending of emails. It is our theory that it would be best to always schedule emails to be sent rather than try to accomplish the task synchronously. The benefit, which we believe is worth the cost of scheduling and executing asynchronously, is that emailing would then be participating in JTA transactions. In other words... if the process failed after the email node was encountered, the email scheduling would be rolled back, and the email would not be sent -- which in essence is allowing JavaMail never to be called unless the transaction succeeds. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223841#4223841 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223841

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Improving the process of applying AnnotationPlugins on M

by jason.greene＠jboss.com

Now for an actual productive comment :) Is there any reason why the MDR has to eager allocate everything about every element of of every scanned class in memory like that? Any reason it can't just represent metadata as a series of overrides + lazily discovered / proxied calls to reflection data. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223828#4223828 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223828

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Improving the process of applying AnnotationPlugins on M

by jason.greene＠jboss.com

Guys we need to stop designing crap that is so over-abstracted, that it becomes *impossible* to optimize. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223827#4223827 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223827

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Clustered example and a few other example things

by timfox

I also added a clustered topic example. Note that I didn't update the readme etc - that still needs to be done but it gives an idea of how to put these clustering examples together. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223789#4223789 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223789

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Clustered example and a few other example things

by timfox

For a test that uses JNDI to get the connection factorys and queus then we'll need to create two initial contexts. I don't know if the example framework currently supports that. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223783#4223783 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223783

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Clustered example and a few other example things

by timfox

I have taken Howard's simple clustered-queue example and got it to work. The example programmatically creates two connection factories one to each node. It then creates a consumer on each node and a producer on one node. It sends 10 messages and verifies that the messages are received round robin. The example should probably be renamed to ServerLoadBalancing example or something similar. I had to make a few changes to the config to get this to work. One thing that I found confusing is the usage of two beans files - one for each server. This meant I had to change all the directories journal, bindings, large messages so each server was using a distinct set. If we just had a different config directory for each server we wouldn't have to do that. Also I found that start() was being called on each component twice during the startup - one time by the MC before it injects and another time inside the MessagingServerImpl start method. We need to add the annotation to prevent the MC calling start/stop, Andy told me what this was the other day but I have forgotten. This still needs to be added. Other stuff - there is lots of unnecessary cruft in the config files. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223781#4223781 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223781

17 years

1
0
0 / 0

[Design of POJO Server] - Integration of Clustered DeploymentRepository in

by bstansberry＠jboss.com

I've gotten a clustered DeploymentRepository working, providing functionality equivalent to (actually better than) the AS 4.x FarmService.[1] It's checked into trunk and Branch_5_x and is being tested via the tests-clustered-profileservice target in the testsuite. But it's not currently used in the all/default/standard configs. Next step is to get it used in at least "all", approach to which is the subject of this thread. The configuration change to make this work is in the conf/bootstrap/profile.xml file. The configuration that is needed can be seen at [2]. This is fairly different; has a different impl of the "BootstrapProfileFactory" bean plus adds three other beans. A couple of possible approaches here: A) Keep two versions of this profile.xml file in the source tree and change the build script such that the cluster-aware one gets used in the "all" config only. This is the way we used to handle the JBoss Web service's -service.xml. Downside is you have to keep the two source files in sync, which proved to be a minor pain point with the JBoss Web integration. B) Use the version at [2] for all the configs, all/default/standard. The way the clustered deployment repo works, this doesn't actually pull in any extra dependencies to the bootstrap. The "ClusteredDeploymentRepositoryFactory" bean has an incallback via which the HAPartition clustering support services are injected when stuff in all/deploy/cluster is deployed [3]. The clustered deployment repository only checks that the necessary clustering services are available if one of the URLs it's configured to manage actually exists. Bottom line, if you run the "default" config you won't have an HAPartition, but the clustered deployment repository won't fail/complain because you also won't have a "farm" dir. Personally, I think A) is the way to go; B) is a kludge that's hard to explain. Thoughts? BTW, this will be simpler in AS 6/trunk since finer-grained subprofiles will be used instead of the Branch_5_x "BootstrapProfileFactory" impl. An "all" config would include the needed beans in subprofiles; "default" wouldn't. [1] See http://www.jboss.org/index.html?module=bb&op=viewtopic&t=150107 for some discussions on this. [2] https://svn.jboss.org/repos/jbossas/branches/Branch_5_x/testsuite/src/res... [3] https://svn.jboss.org/repos/jbossas/branches/Branch_5_x/testsuite/src/res... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223778#4223778 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223778

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Testing latest 2.2.0M1/2 releases

by alesj

I'll check those NPEs. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223776#4223776 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223776

17 years

1
0
0 / 0

[Design of JBoss Portal] - Re: Changing the JBossPortal logo issue

by wesleyhales

portal_style.css (line 234) the 77px is what you want to adjust to meet your needs. It is 0 by default. | ul#tabsHeader { | ... | margin:0 77px -5px 0; | ... | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223774#4223774 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223774

17 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2009