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

[Design of OSGi Integration] - Re: Logging and Exception Handling

by adrian＠jboss.org

"johnbailey" wrote : There are couple places in the OSGI API that expect different behavior than the MC. One example is the Bundle getEntry and getEntryPaths methods. These methods should return 'null' in if the entry can not be found within the Bundle. The call to the DeploymentUnit to get the file will result in a RuntimeException wrapped FileNotFoundException, which makes sense, as the file does not exist. In this case I think the Bundle methods should catch the Exception and return 'null'. Should we catch it here, or propagate to client? | What method are you using? It should return null for not found: VFSDeploymentUnit or VFSDeploymentResourceLoader | /** | * Get a virtual file | * | * @param path the relative path of the file | * @return the virtual file or null if not found | */ | VirtualFile getFile(String path); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133260#4133260 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133260

16 years, 6 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Moving jbossas to a maven repo for thirdparty

by pgier

I haven't finished duplicating all the thirdparty directory yet, but I should be able to finish it today. So the next things to do are: 1. Make sure the testsuite works against the thirdparty with maven artifacts. 2. Change the testsuite to use the maven generated module artifacts. And make sure that everything still works. What still needs to be done after this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133259#4133259 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133259

16 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Update the relevant .classpath files

by ALRubinger

"alesj" wrote : I'm always in favor of not keeping things around that can be generated. +1. For Eclipse, this may be done: mvn eclipse:clean; mvn eclipse:eclipse ...and then set the Variable "M2_REPO" within the IDE to point to your Maven2 Repo (~/.m2/repository by default in *nix). S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133258#4133258 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133258

16 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: BeanMetaDataBuilder

by adrian＠jboss.org

"kabir.khan(a)jboss.com" wrote : | Should I create new replacePropertyMetaData() methods, or update the existing addPropertyMetaData() methods? Fix it. It should replace. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133256#4133256 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133256

16 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Domain resolve algorithm

by adrian＠jboss.org

"alesj" wrote : What's the status of this: | - http://jira.jboss.com/jira/browse/JBMICROCONT-182 | It's a "quality of implementation issue" required for OSGi. It isn't required for JBoss5 (no OSGi dependencies defined yet) so its on the back burner. I think most of the work will actually be in creating the test coverage. I can think of complicated scenarios in OSGi and for example the scoped domains with (parent first/last) or "importAll" are addtional features beyond what OSGi can do. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133255#4133255 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133255

16 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Domain resolve algorithm

by adrian＠jboss.org

"alesj" wrote : | I'm just asking, since after reading this | - http://www.osgi.org/blog/2008/02/research-challenges-for-osgi.html | I started thinking about the challenge | If you don't track references properly then you're bound to get that problem. Even when you do, e.g. the MC or declaritive services in OSGi, the user might still leak the type into somebody else's singleton (apache clogging, digester, etc. you are guilty here! ;-) anonymous wrote : | http://post-office.corp.redhat.com/mailman/private/jboss-osgi-dev-list/20... | Post it in public if you want others to be able to comment. anonymous wrote : | in more mathematical fashion, providing some concrete proof for the actual algorithm used, time usage wise. It boils down to graph theory, and finding some known problem to 'map' this usage to it. | It's not a graph, although it might look like one in the raw data. Like I said elsewhere, "I know how to do it". The trick is to actually to try to collapse it into a group of Sets of related classloader exports and when that is impossible (e.g. conflicting versions) you fail the one that wants to join. Like I also said elsewhere, there's some "Gotchas", More details: * hot deployment - merging/disjoining sets (if disjoining is a word? ;-) * recursion - resolving classloader references leads to deployment from the repository * circular references * etc. anonymous wrote : | A quick thought. | How does re-wiring stand against the actual ClassLoader usage. | e.g. we already have wired bundles, | We wires "ClassLoaderPolicy"s, but yes they are similar to what the OSGi spec calls wires. (Part of what they call wires is done by the RequirementDependencyItem). anonymous wrote : | and we want to add a new one. But with the current wiring that is not possible (possibly some 'uses' constraints in the way), but if we re-wire things, we might be able to wire the new bundle as well. | I guess that means uninstalling current deployments, and installing them back on after we 'discovered' that there is a wire configuration that makes everyone happy. :-) Correct. Although I doubt we would enable this by default. Undeploying an application (however temporarily) because some other related application wants to join the group with conflicting requirements isn't a very good semantic for a production machine. OSGi requires a seperate invocation on an "update classes" method. It could be a useful feature for developers who just want to drop a updated package into "deploy" and have everything re-adjust. i.e. try it, if it fails, see if it would work if you redeployed those that are conflicting and if so, do that by invoking the "udpate classes" automatically. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133254#4133254 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133254

16 years, 6 months

1
0
0 / 0

[Design of OSGi Integration] - Logging and Exception Handling

by johnbailey

There are couple places in the OSGI API that expect different behavior than the MC. One example is the Bundle getEntry and getEntryPaths methods. These methods should return 'null' in if the entry can not be found within the Bundle. The call to the DeploymentUnit to get the file will result in a RuntimeException wrapped FileNotFoundException, which makes sense, as the file does not exist. In this case I think the Bundle methods should catch the Exception and return 'null'. Should we catch it here, or propagate to client? The main question I have if the Exception is caught, is how to log it. I would guess we would want the information available if the client makes the call, but we don't want to log it as an error and flood the log, for a call that is valid. Should the Exception/message be logged at the DEBUG or INFO level so the client could get it if they think the call should have resulted in something? I would also like to know if there are any ground rules on logging and Exception handling to follow. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133252#4133252 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133252

16 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Transaction rollback in action pipeline

by beve

Hey Kevin, yeah, that would be much better. I'll reopen and add that. Thanks, /Daniel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133248#4133248 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133248

16 years, 6 months

1
0
0 / 0

[Design of POJO Server] - JBAS-5268, AbstractTopLevelClassLoaderDeployer

by scott.stark＠jboss.org

As we have talked about, the WarClassLoaderDeployer really should not exist as AbstractTopLevelClassLoaderDeployer should be able to create subdeployment class loaders based on metadata. I need this to move the war deployer forward and address problems like JBAS-5268. I don't see a current JBMICROCONT or JBCL issue for this. Can we prioritize this for JBossMC-2.0.0.CR1? I"ll start working on it if so, otherwise I'll keep the WarClassLoaderDeployer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133247#4133247 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133247

16 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: How to force strict validation?

by alex.loubyansky＠jboss.com

Later XB versions should check the presence of required attributes during marshalling. Xerces-based marshaller is deprecated. org.jboss.xb.binding.sunday.marshalling.MarshallerImpl is the recommended one. It's based on SchemaBinding. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133246#4133246 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133246

16 years, 6 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 2008