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

[JBoss OSGi Development] - Tests no longer work in eclipse

by adrian＠jboss.org

After the lastest round of refactoring the tests now don't run in eclipse. And this is not just the usual log4j mess again. The root cause is an eclipse/maven problem with the classpath, i.e. it is now looking for /META-INF/jboss-osgi-bootstrap.xml but it is finding a META-INF in some jar instead of src/test/resources and so not find the xml. I'm moving this back to the bootstrap subfolder so there can be no confusion. Another broken part is because the following method has been removed from FrameworkTest extensions e.g. | public static Test suite() | { | return suite(OSGiSmokeTestCase.class); | } | This construction of the TestSuite is what sets up and tears down the whole testcase rather than reconstructing it for every method. See junit's TestSetup mechanism. As I've said before, I don't see the point of all this refactoring. Especially when it is to "standards" that are not traditional jboss, e.g. * internal instead of plugins? (in some cases both :-) * tests no longer go in a "test" subfolder and don't end in TestCase? etc. But at least don't change the semantics and break things. On a related issue, the "no manifest" tests are there for a reason. As are some other ones I'm going to add now I see what an abortion has been made of this. i.e. it should be possible to install NORMAL deployments using the OSGi api. They don't have to be osgi bundles, they could be wars or any other type of deployment. Part of the reason for implementing OSGi is for users to have a standardized framework for installing and controlling their deployments. OSGi implementation details should go in the OSGi deployers not the bundle manager which is just a facade for the MainDeployer. You only do OSGi processing when it has OSGiMetaData and you only know that once it is deployed through the deployers. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265069#4265069 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265069

16 years, 4 months

1
0
0 / 0

[JBoss ESB Development] - Conversion of org.jboss.soa.esb.message.Message to SOAPMessa

by masterkey

Hi, I am new in SOA and ESB Development. Actually I am trying to modify some samples and would like to convert a JBoss-Message that has a complete SOAP-Message in its body to a SOAPMessage object. I've tried many things but I can't imagine that this can be as difficult as it looks like for me. Can anyone help? Thanks in advance. Best Regards Dennis View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265063#4265063 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265063

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - ResolverPlugin is just Wrong

by adrian＠jboss.org

RESOLVER PLUGIN IS INOPERABLE WITH OTHER CLASSLOADING Thomas, can you stop working on the ResolverPlugin, it is just plain wrong. One of the major points of developing the MC based OSGi facade is that OSGi bundles should be able to play nicely with other JBoss deployments. What are doing breaks that requirement. Besides that, the resolver plugin is incomplete compared to all the things that JBoss ClassLoading can do and is broken in other ways e.g. like the way it processes RequireBundle re-exports which can have additional filters on what is exported for non-osgi deployments. What I did for the original work was introduce the OSGi*Requirement/Capability as a way to add the OSGi features without distribuing the jboss-cl code initially. i.e. determine what is required before changing the classloader code. But all those features should and will "bubble up" into jboss-cl project making them redundant in the osgi code. WHAT IS REQUIRED The way to make the resolving work is to do what I said in at least two previous posts and you've ignored. That is to have "on-demand" classloading requirements handled automatically. This could be done in the OSGi code now, but it would be messy, so it needs doing properly in the jboss-cl code. There are additional requirements for osgi, which your resolver doesn't handle either. 1) Introduce a ClassNotFoundException handler This will allow dynamic imports to force a resolution of a bundle that isn't in the resolved state rather than throwing an error 2) Introduce a repository api This will allow both the normal and dynamic imports to load a requirement from a repository. i.e. a bundle/deployment that isn't even installed. Both of the above need to be completed in jboss-cl for the OSGi classloading work that I'm doing. There is some additional work to the ClassLoading/Module api so that the PackageAdmin api can be implemented on top it, and finally fragments and extension bundles need to be supported. The current resolver plugin certainly can't handle some of these and in most cases, we want these features in the core classloading - it shouldn't be OSGi specific. Remember the OSGi framework should just be a facade on JBoss MC features. If the JBossMC feature doesn't exist, it should be added. The only reason to do it in the OSGi project is to determine what is required before it goes in the main codebase. I'm working on doing all this, or at least putting the mechanisms in place so they can be done - so you are just wasting your time, trying to do duplicate stuff that can't possibly be implemented/extended in the way you are doing it. DROOLS PLUGIN On a further topic, the osgi-mc integration project (reactor/framework) is not the place to put things like the drools plugin. As a matter of of general policy, it should live in a seperate project so you don't force an optional plugin (along with all it dependencies - it's a lot for drools) on all users. But, the MC/ClassLoading already has mechanisms such as being able to write your own Requirement/Capability to handle things like this. It doesn't need a "plugin". e.g. something like: | <classloading ...> | <requirements> | <drools-requirement> | rule: | etc. | </drools-requirement> | ... | Even if that is not the level you want to do it at, the extension mechanism belongs in jboss-cl not the osgi facade, so it can be used for everything. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265057#4265057 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265057

16 years, 4 months

1
0
0 / 0

[JBoss Web Services Development] - Re: Create new deployer to deploy java first jms transport w

by alessio.soldano＠jboss.com

The point here is that we need to deploy cxf jms endpoint independently from the http endpoint, which might not even be provided. For this reason we need a mean of processing the jbossws-cxf.xml at deplyo time, instead of when initializing the CXFServletExt we have (that extends the CXF servlet). Basically we need a correct integration point for jms transport. So, Richard is right in saying that adding a new deployer might not be a viable solution as it will break the current container integration. A proposal for doing this might then be to add another deployment aspect for doing what Jim originally though about doing in the new deployer (parsing the jbossws-cxf.xml, installing the jms only endpoint, start the cxf bus, etc.) and leave the generated webapp there just to serve wsdl requests (in case of jms only endpoints of course). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265027#4265027 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265027

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by adrian＠jboss.org

"alesj" wrote : "alesj" wrote : | | * Service --> MC | | | What to do about tracking this "OSGi --> MC" injection? | | If we add this service to bundle's inUse, then there is no proper callback to decrease inUse count. | Which in the case of ServiceFactory (SF) means SF::ungetService might never be called. | | We can completely ignore bundle service count + serviceCache, | but potentially some service unregister could invoke SF::ungetService, | although we would still be using it in MC bean. | The service tracking needs moving into the MC as part of this integration. The issue is what you track against. As part of the OSGi stuff, I've made the DeploymentUnit part of the MDR's deployment level metadata. You should extend this concept so that the dependency project can look for a "ServiceTracker" in the MDR rather than a DeploymentUnit. The deployers project would then add the ServiceTracker attachment by the default to the deployment level metadata. If there is no such data (e.g. for MC contexts created by the bootstrap) then you should track against the "SystemBundle", i.e. a shared default deployment. The OSGi stuff would then just delegate to those items for service tracking instead of having to do it itself in the AbstractBundleState. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265003#4265003 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265003

16 years, 4 months

1
0
0 / 0

[JBoss ESB Development] - Getting started with Jboss SOA

by lahvenai

Hi ! Is there anyone that can point me to a tutorial on how to get started with Jboss SOA.? What's needed to download, how to install and so on . View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265002#4265002 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265002

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by adrian＠jboss.org

"alesj" wrote : I'm actually wondering what's the best or proper way to expose or use this services in MC. | What should be the keys that we expose or match. | | "alesj" wrote : | | * Service --> MC | | | In OSGi service we expose classes and properties. | | Probably the key could look something like this: | * org.jboss.acme.X,org.jboss.acme.Y;(a=b) | a set of FQNs and a filter. | Only matching services that expose all the FQNs and match the filter. | | Perhaps if there are no properties, we could directly expose service under registered classes? | What do you mean by key? The name of the OSGi service context should be something generated that won't change or interfere with other names e.g. a UID or $OSGiService + serviceID Ideally you need an index (rather than a key) by class name to optimize the search but we don't currently do that in the OSGi prototype. You should already have something similar for the anonymous injection and the install callbacks which should be more efficient than what is currently used? The only thing that is probably missing is the security check? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265000#4265000 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265000

16 years, 4 months

1
0
0 / 0

[JBoss Web Services Development] - Re: Create new deployer to deploy java first jms transport w

by alessio.soldano＠jboss.com

"richard.opalka(a)jboss.com" wrote : "jim.ma" wrote : If this can be deployed without web.xml, it will be more quick and flexible.Can we create another deployer to do this job ? | | | IMHO this is not good idea :( Why complicate things? I don't see the problem web.xml have to be provided. why would you need a servlet for a jms only endpoint? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264988#4264988 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264988

16 years, 4 months

1
0
0 / 0

[JBoss Web Services Development] - Re: Create new deployer to deploy java first jms transport w

by alessio.soldano＠jboss.com

I agree on having another deployer for jms endoints, as we said on IRC last week. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264987#4264987 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264987

16 years, 4 months

1
0
0 / 0

[JBoss Web Services Development] - Re: Create new deployer to deploy java first jms transport w

by richard.opalka＠jboss.com

"jim.ma" wrote : If this can be deployed without web.xml, it will be more quick and flexible.Can we create another deployer to do this job ? | IMHO this is not good idea :( Why complicate things? I don't see the problem web.xml have to be provided (just my opinion). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264986#4264986 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264986

16 years, 4 months

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