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

[Design of JCA on JBoss] - Re: [JBAS-5221] tx-connection-factory/no-tx-connection-facto

by jesper.pedersen

The feature is tired in with the deployer, so that layer also have to be changed if the clean up is going to happen. Something for the 6.0 - making sure that things are kept separate. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214634#4214634 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214634

17 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: jbossjts sources

by jhalliday

My point is there is no direct correspondence between the binary .jar files and the layout of our source tree. It's tricky to produce source bundles that match to the individual .jar files. I can give you a single big source bundle but I don't know if eclipse will deal with that. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214592#4214592 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214592

17 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: jbossjts sources

by scott.stark＠jboss.org

We don't need the full source tree, just the java files that correspond to the classes in the jars. I was trying to see what the TransactionManagerServiceMBean looked like in jbas, and could not just open its source up from within eclipse since there was no source artifact. Its just an ease of use issue. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214589#4214589 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214589

17 years

1
0
0 / 0

[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1

by scott.stark＠jboss.org

"emuckenhuber" wrote : | This test is just a quick prototype and is not finalized at all. Basically i just was testing the XmlAnyElement - so that you can plugin your own meta data implementation. Ok, great. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214586#4214586 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214586

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ByteBuffer.allocateDirect ridiculously slow

by clebert.suconic＠jboss.com

anonymous wrote : It's a well known fact that direct bytebuffer allocation is much slower I knew that already. But I didn't expect it to be 100X slower. I have changed the code to allocate and free buffers directly, and performance won't be a problem for these buffers any more. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214584#4214584 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214584

17 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: JBossAS transaction test regression

by jason.greene＠jboss.com

I ran into the same thing: https://jira.jboss.org/jira/browse/JBAS-6561 It seems the association semantics are indeed wrong, so I am going to just "correct" the test. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214575#4214575 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214575

17 years

1
0
0 / 0

[Design of JBoss Wiki] - Portal 2.7 support

by piergiorgiolucidi

I have completed the implementation of porting of JBoss Wiki on JBoss Portal 2.7.x. During these days I hope to commit all the source code and then release the newest binary files. Stay in touch ;) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214572#4214572 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214572

17 years

1
0
0 / 0

[Design of OSGi Integration] - Re: Runtime and bundle lifecycle/dependency resolution

by alesj

"alesj" wrote : "thomas.diesler(a)jboss.com" wrote : | | I'd suggest the BundleStartStopDeployer maintains a list of unresolved bundles and tries to resolve them before bundle.start() is attempted. | | | MC already does this. | Bundle == DeploymentControllerContext. | | You're missing my point. | We should make sure the Bundle only gets to BSSD if it's properly resolved. | Any other hacking/duplicating is a step in the wrong direction. | Why do I see | // The list of unresolved bundles | private List<Bundle> unresolvedBundles = new ArrayList<Bundle>(); | when I explicitly said this is wrong? Don't get me wrong or harsh or ..., but this way of interaction won't work. At least you could argue/discuss/justify with me on this before you put it in. To get into details even more. All this code is just unnecessary, as it over complicates things | // Get the required dependency on the PackageAdmin service | if (packageAdmin == null) | { | ServiceReference sref = systemContext.getServiceReference(PackageAdmin.class.getName()); | packageAdmin = (PackageAdmin)systemContext.getService(sref); | if (packageAdmin == null) | throw new IllegalStateException("Cannot obtain PackageAdmin service"); | } | | // Always add the bundle as unresolved | unresolvedBundles.add(bundle); | | Bundle[] bundleArr = new Bundle[unresolvedBundles.size()]; | unresolvedBundles.toArray(bundleArr); | | // Try to resolve the bundles | packageAdmin.resolveBundles(bundleArr); | | // Find resolved bundles and start them | Iterator<Bundle> it = unresolvedBundles.iterator(); | while(it.hasNext()) | { | Bundle auxBundle = it.next(); | int state = auxBundle.getState(); | if (Bundle.RESOLVED == state) | { | it.remove(); | try | { | auxBundle.start(); | log.info("Started: " + auxBundle.getSymbolicName() + ",state=" + auxBundle.getState()); | } | catch (BundleException e) | { | log.warn("Cannot start bundle", e); | } | } | } | A simple proper DI creation in BundleClassLoaderDependencyDeployer would do all of the "tricks" necessary: * create proper spi/abstraction over what we can use * limit PackageAdmin usage to DI * no need to start all off the non-involved bundles And I guess usage of system Bundle could also be reduced to minimum. Perhaps moving the DI creation into OSGiDeployer. Something to discuss ... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214571#4214571 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214571

17 years

1
0
0 / 0

[Design of OSGi Integration] - Re: JBOSGI-38 and bundle deployment order

by alesj

"thomas.diesler(a)jboss.com" wrote : | The ResolvedBundleDependencyItem would probably not fix that, because deployment of A would already fail - if I understand this correctly. | No, it would work. Or, why do you think it would fail? When X gets installed, the framework knows A can be resolved. e.g. * POST_PARSE: install X (this makes A resolved) * pre CLASSLOADER: asking RBDI if A can be resolved == true --> move to CL --> move to start/stop bundle deployer It's the RBDI that should use PackageAdmin. Or actually, one of the DI impls that we add in BundleClassLoaderDependencyDeployer would use it. Like stated here: "alesj" wrote : | e.g. BundleClassLoaderDependencyDeployer::createResolveDependencyItem() could return diff DI instance based on what is available | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214561#4214561 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214561

17 years

1
0
0 / 0

[Design of Clustering on JBoss] - Re: Clustering the webapplication

by jiwils

The documentation has the answers you want, but you should use the Clustering Forum for questions like this as this is the forum for design-related discussions not user questions. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214550#4214550 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214550

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 March 2009