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

[Design the new POJO MicroContainer] - Re: classloading dependencies

by jhalliday

Whilst waiting for the fix to make its way into branch 5.x I used the <demand state="PreInstall">barModule</demand> approach instead. This correctly prevents a classloading attempt when barModule is not present. However, when the module is present the ClassDefNotFound comes back. I'm guessing barModule's classes are not exposed to other modules by default? If I don't control barModule, is there any way I can still get at its classes, short of copying the .jar files? :-) Failing that, what's the correct meta data for barModule to expose things? jboss-classloading.xml with capabilities elements for anything it wants to publish? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208635#4208635 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208635

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Problems with change in ConstructorInstantiator

by camunda

Cool, thanks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208622#4208622 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208622

15 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Paging, lastPageTransaction, and duplicate detection.

by timfox

Yeah, we can do that as an optimisation - it should be fairly straightforward. Deleting it however won't make any difference - they get deleted anyway when the cache gets full. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208619#4208619 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208619

15 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Design of Portal Deployer

by mwringe

"alesj" wrote : "mwringe" wrote : | | 1) The current approach is that we have all the jars that used to exist in the portlet container sar moved over to the deployer. The sar is then used to just to start the portlet container at run time (it becomes basically just a jboss-service.xml file). | | | Why -service.xml instead of -beans.xml? | Thats the way the current sar is setup, I can be converted to a -beans.xml in the future. Is there a big reason to switch? "alesj" wrote : | "mwringe" wrote : | | The deployer uses the microcontainer kernel to get a reference to the portlet containers runtime objects and uses those to directly inject the information into the running server. | | | Why MC kernel usage? | Inject portal objects directly. | Because the deployers are started before the deployables, so I can't inject something from a deployable into a deployer (correct me if I am wrong, but I have tried this) So I use the MC kernel to get a reference to the objects at runtime which gives me the same result. "alesj" wrote : | "mwringe" wrote : | | 2) more distinct separation between the deployer and the portlet container. | | The deployer would only contain jars for the metadata, the deployers themselves and for interface classes that will be used to pass data between the deployer and the portlet container. | | In this case the deployer would parse the xml files into metadata, then convert the metadata into the proper classes for the common interface, then have the portal container have new classes to interface with the deployer to convert the common interface into the classes that it requires. | | | OK, the common metadata driven approach. | So the common metadata driven approach is the best? "alesj" wrote : | Any new idea with the .tld handling? No, and there are other deployers which need to do similar things (sometimes even worst than the tld deployers). I know its not the best way of doing it, but it works. It something that will need to be looked into more and fixed (if possible). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208616#4208616 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208616

15 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Paging, lastPageTransaction, and duplicate detection.

by clebert.suconic＠jboss.com

If you' re not using transactions on perfSender, it is storing one per message. It would be better to do it per-depage. (or the transaction used on depaging). Also... It would be even better (for reclaiming and compating), to delete the duplicate record as soon as the message is deleted. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208609#4208609 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208609

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Concurrency in jBPM4

by camunda

I didn't get the problem yet. You don't have JTA in place but work in a clustered environment? Or just one resource is non transacted? I know quite huge systems where jbpm with JMS and "normal" JTA transactions are no problem, even with some rollbacks. Especially with JMS, the message is automatically redelivered and JMS scales quite well, why is that such a big problem? BTW: Pesimistic locking could be done in jbpm as well by using Hibernate if you really need it. Normally I don't think baking your own stuff there is a good idea... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208581#4208581 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208581

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - test restructuring

by tom.baeyens＠jboss.com

in order to proceed with fixing the job executor functional tests (they fail once and a while), i will first clean up the base test class structure. The end result should look like this: module test-base will contain following classes: * JbpmTestCase (currently this is called DbTestCase) | - base test case for our users and our own service based tests | - only uses api | - makes all services available based on configuration in jbpm.cfg.xml | - contains helper methods to execute specific jobs that should have been created | - verifies clean DB after every test and cleans up only if necessary | * Db | - basic DB cleaning operations View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208554#4208554 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208554

15 years, 5 months

1
0
0 / 0

[Design of JBossXB] - Re: 2 root elements question

by alex.loubyansky＠jboss.com

Ah, I didn't think about adding this to the resolver. You can try a workaround using the examples in the testsuite and SchemaBindingInitializer. I'll add support for multi-class binding to the resolver. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208551#4208551 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208551

15 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Design of Portal Deployer

by alesj

"mwringe" wrote : | 1) The current approach is that we have all the jars that used to exist in the portlet container sar moved over to the deployer. The sar is then used to just to start the portlet container at run time (it becomes basically just a jboss-service.xml file). | Why -service.xml instead of -beans.xml? "mwringe" wrote : | The deployer uses the microcontainer kernel to get a reference to the portlet containers runtime objects and uses those to directly inject the information into the running server. | Why MC kernel usage? Inject portal objects directly. "mwringe" wrote : | 2) more distinct separation between the deployer and the portlet container. | The deployer would only contain jars for the metadata, the deployers themselves and for interface classes that will be used to pass data between the deployer and the portlet container. | In this case the deployer would parse the xml files into metadata, then convert the metadata into the proper classes for the common interface, then have the portal container have new classes to interface with the deployer to convert the common interface into the classes that it requires. | OK, the common metadata driven approach. Any new idea with the .tld handling? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208518#4208518 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208518

15 years, 5 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Custome Authenticators Defined At Web Application Level

by mikala

Is JBOSS 5.0.0GA supports custom authenticators defined in jboss-web.xml ? How to define custom authenticators in ear in AS5.0.0GA ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208517#4208517 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208517

15 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2009