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

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

by mwringe

"alesj" wrote : "mwringe" wrote : | | But if we use the common metadata approach, this doesn't work as the deployer won't have access to the containers jars in its classpath, so I would still probably have to use the indirect reference method using the MC kernel. | I don't get it. :-) | | How do you then get stuff from container? | Plain object and then hack over reflection? :-) | | You need type safe model. | All the interfaces should be on deployers side, | only some impls at container side. | yes, that how it should work. mwringe needs more coffee today. "alesj" wrote : | This should work with current flat cl model (or "big ball of mud"), | once we kick-in OSGi you should add more exact cl logic + move to proxy services. | | But that's another story. :-) Oh great, OSGi and manipulating jar manifest files, sounds like fun :P View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209190#4209190 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209190

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Duplicate DeploymentContext registration

by alesj

I thought I had this one: - http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209160#4209160 But now I'm sure I got it wrong. :-) I did a small test, with having -beans.xml as a sub-sub-deployment, and it fails as expected. ;-( * test.jar ** META-INF ** inner.jar *** META-INF *** my-beans.xml It's the recursion in AbstractDeploymentContext that gets called twice. It will always fail for any sub^n-deployment, where n > 1. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209189#4209189 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209189

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Journal Clean up / Compactor (Repost)

by clebert.suconic＠jboss.com

"Tim" wrote : Why would you need to update the file on disk? If you update in memory, then the files get deleted, so they won't get reloaded... What am I missing here? Take my initial example in consideration: | f1: A1, A2 (A2 won't be deleted for a while) | | f2: D1, A3, A4 | | f3: D3, D4 A5 A6 | | f4: D5, D6, A7, a8 | | f5: d7, d8, A9, A10 | .... | | f1000: d998, d999, a1000, a1001 | | You have 1000 hanging on A2. So what I need to do on the above example is to phisically update f1, so f1 will be: f1: A2 (There is no more A1 on the file). And remove the memory dependency between f1 and f2. After I do that, 999 files will be reclaimed or deleted. If I don't update F1, during reload A1 would appear back, as the delete D1 is gone with the file. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209159#4209159 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209159

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Journal Clean up / Compactor

by clebert.suconic＠jboss.com

"Tim" wrote : Why would you need to update the file on disk? If you update in memory, then the files get deleted, so they won't get reloaded... What am I missing here? Take my initial example in consideration: | f1: A1, A2 (A2 won't be deleted for a while) | | f2: D1, A3, A4 | | f3: D3, D4 A5 A6 | | f4: D5, D6, A7, a8 | | f5: d7, d8, A9, A10 | .... | | f1000: d998, d999, a1000, a1001 | | You have 1000 hanging on A2. So what I need to do on the above example is to phisically update f1, so f1 will be: f1: A2 (There is no more A1 on the file). And remove the memory dependency between f1 and f2. After I do that, 999 files will be reclaimed or deleted. If I don't update F1, during reload A1 would appear back, as the delete file is gone. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209159#4209159 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209159

17 years, 1 month

1
0
0 / 0

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

by alesj

"mwringe" wrote : | But if we use the common metadata approach, this doesn't work as the deployer won't have access to the containers jars in its classpath, so I would still probably have to use the indirect reference method using the MC kernel. I don't get it. :-) How do you then get stuff from container? Plain object and then hack over reflection? :-) You need type safe model. All the interfaces should be on deployers side, only some impls at container side. This should work with current flat cl model (or "big ball of mud"), once we kick-in OSGi you should add more exact cl logic + move to proxy services. But that's another story. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209157#4209157 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209157

17 years, 1 month

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: 'public' API stability when embedded in JBossAS

by mark.little＠jboss.com

Where does it say 'no deprecation' in the CP rules? Certainly no breaking backward compatibility if it can be avoided, but there are times when changes need to be made to fix bugs and they do break backwards compatibility. But then backwards compatibility with a bug is something we don't want. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209140#4209140 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209140

17 years, 1 month

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: 'public' API stability when embedded in JBossAS

by jhalliday

OK, this seems to be missing the point at bit. I'm not concerned with the deprecation rules that exist between project point releases. I'm concerned with CP maintenance i.e. the product branch. The rules there are different. No deprecation. And no additions either if they may break clients e.g. adding a new method to an interface. Even changing the behaviour of an existing public method is dodgy. That's why I want to minimise what we support as our API on the CP line. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209130#4209130 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209130

17 years, 1 month

1
0
0 / 0

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

by mwringe

"alesj" wrote : | It depends how you inject them. ;-) | | After each phase deploy - boot, deployers, deploy - a MainDeployer::checkComplete is called, | to make sure everything is deployed as it should be. | | But you can make your injections optional, injected via callback. | So it will be almost the same as you have now, | except that your code will be MC agnostic, hence more flexible. | | Think POJO. ;-) | Oh, ok, well that makes more sense. But if we use the common metadata approach, this doesn't work as the deployer won't have access to the containers jars in its classpath, so I would still probably have to use the indirect reference method using the MC kernel. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209121#4209121 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209121

17 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: how to get JBoss portal Source code

by prabhat.jha＠jboss.com

Two ways you can get source: 1. From sourceforge, you can get the source zip. 2. You can checkout from at http://anonsvn.jboss.org/repos/portal/tags/. You pick the tag that you want. such as JBoss_Portal_2_7_1/ View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209108#4209108 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209108

17 years, 1 month

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: 'public' API stability when embedded in JBossAS

by mark.little＠jboss.com

BTW in terms of XTS, mwlabs == internal View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209100#4209100 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209100

17 years, 1 month

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