October 2009 - jboss-osgi-dev - Jboss List Archives

[JBoss OSGi Development] - Re: OSGi WebApps on JBossWeb

by thomas.diesler＠jboss.com

"Burr" wrote : | Will this feature allow me to have 2 of the same .war files deployed at the same time but with different version numbers and with possibly different implementations? | | If so, how will we "route" requests to the right version of the .war file? | | If so, how will we handle http session replication across a cluster, like when the 2 versions of the .war file have slightly different implementations of POJOs that used in the session (e.g. ShoppingCart, UserProfile)? | I would assume that the deployment name would have to be different (i.e. mywebapp_v1.war, mywebapp_v2.war). Each webapp would have to be deployed to its own http context. OSGi Package-Import manifest headers would make sure that each webapp is wired to the correct implementation View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262176#4262176 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262176

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - OSGi WebApps on JBossWeb

by thomas.diesler＠jboss.com

https://jira.jboss.org/jira/browse/JBOSGI-193 OSGi webapps are currently deployed onto jboss-osgi-webapp, which contains an embedded PAX-Web WAR extender that in turn delegates to the PAX-Web provided WebContainer based on Jetty. In the future, OSGi webapps should be handled by JBossWeb and be deployed onto the JBoss embedded Tomcat instance. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262175#4262175 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262175

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Consolidating OSGi deployers

by thomas.diesler＠jboss.com

There are two "types" deployers #1 generic #2 mc framework specific https://jira.jboss.org/jira/browse/JBOSGI-180 The generic deployers are used by the jboss-osgi-microcontainer bundle, the jbossas integration for felix/equinox and the mc framework. They are generic in a sense that they only have a dependency on the org.osgi API and not on any specific framework implementation. The specific mc framework deployers are an integral part of that framework. They have a dependency on implementation details and also need to be available to run the tests A possible structure that allows generic and specific deployers to move together would be | framework | +- core | +- deployers | +- testsuite | We may revisit this issue when the framework starts to fall into multiple modules anyway. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261804#4261804 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261804

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Moving framework to reactor

by thomas.diesler＠jboss.com

anonymous wrote : | (b) this is something I would like to debate, | as the current situation is just too tangled up, | no way to know where and how things fit in. | The current situation is that 'framework' is a reactor project of jboss-osgi, which builds as part of the jboss-osgi/trunk anonymous wrote : | (b) should be the priority and something we should made easily accessible and distributable (short and independent release schedule) | At this stage of development framework has a release cycle of eight weeks, which is the shortest that we do in jboss-osgi. It is also the release cycle of jboss-osgi itself. The next framework release will be on 1-Dec-2009 When framework becomes more stable it can start its own release cycle. The criteria for that is that framework reaches at least Beta (i.e. feature complete) stage. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260665#4260665 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260665

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Moving framework to reactor

by alesj

I think you're doing too much of re-factoring. ;-) (a) package renaming: removed MC naming notion of separation between spi, api, plugins (b) location: this should be top level jbossas/projects if you ask me (a) might not be that crucial, as we're not expecting to extend this any futher e.g. any other MC piece is actually a building block for other things, as it clearly shows here, hence a strict spi, api, plugins is in order (b) this is something I would like to debate, as the current situation is just too tangled up, no way to know where and how things fit in. (b) should be the priority and something we should made easily accessible and distributable (short and independent release schedule) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260587#4260587 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260587

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Moving framework to reactor

by thomas.diesler＠jboss.com

Folks, having the framework under its own SVN location https://svn.jboss.org/repos/jbossas/projects/jboss-osgi/trunk does not prove practical at this early phase in project development. The jboss-osgi examples, the functional tests and the blueprint implementation now use that framework as the default We already have the notion of "reactor" project that is part of the overall jboss-osgi build. Currently Blueprint is in the reactor already. I plan to move the framework to the reactor as well. This would remove issues with jboss-osgi test failures because the latest framework SNAPSHOT has not been deployed. It is also impractical to frequently deploy the framework because of the size of its artifacts | [tdiesler@tdvaio trunk]$ ls -l target/ | total 9512 | -rw-rw-r--. 1 tdiesler tdiesler 4706688 2009-10-09 09:58 jboss-osgi-framework-1.0.0-SNAPSHOT-all.jar | -rw-rw-r--. 1 tdiesler tdiesler 323857 2009-10-09 09:58 jboss-osgi-framework-1.0.0-SNAPSHOT.jar | -rw-rw-r--. 1 tdiesler tdiesler 448742 2009-10-09 09:58 jboss-osgi-framework-1.0.0-SNAPSHOT-javadoc.jar | -rw-rw-r--. 1 tdiesler tdiesler 214299 2009-10-09 09:58 jboss-osgi-framework-1.0.0-SNAPSHOT-sources.jar | After the move you can find the framework here https://svn.jboss.org/repos/jbossas/projects/jboss-osgi/trunk/reactor/ View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259556#4259556 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4259556

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Should BundleStructureDeployer add embedded archives ?

by thomas.diesler＠jboss.com

ok, I moved the Bundle-ClassPath handling to the bundle structore deployer. The OSGiClassLoaderFacory picks up the classpath from the structure View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259362#4259362 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4259362

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Should BundleStructureDeployer add embedded archives ?

by alesj

"alesj" wrote : | Yes, it should be the structure deployer to handle this, not policy creation code. | In this case it could also be some real deployer (pre CL stage), similar to what we do in InMemoryClassesDeployer. But since you're already parsing manifest for symbolic name in structure deployer, I guess you don't gain that much by moving this code on top of existing OSGiMetaData in some real deployer. e.g. it would make sense to move it to real deployer and work on existing OSGiMetaData, hence not reading manifest headers twice But like I said, this is not the case here, as you *must* already read it in structure deployer View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259312#4259312 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4259312

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Should BundleStructureDeployer add embedded archives ?

by alesj

"thomas.diesler(a)jboss.com" wrote : | Should the structure deployer also be Bundle-ClassPath aware or should it perhaps not handle embedded jars at all? | Yes, it should be the structure deployer to handle this, not policy creation code. See JARStructure and its addClassPath call, where includeRootManifestCP == true. | // Add the manifest locations | if (includeRootManifestCP && isLeaf(entry) == false) | { | try | { | VFSUtils.addManifestLocations(entry, paths); | } | catch(Exception e) | { | if (trace) | log.trace("Failed to add manifest locations", e); | } | } | | ... | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259304#4259304 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4259304

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Should BundleStructureDeployer add embedded archives ?

by thomas.diesler＠jboss.com

Currently BundleStructureDeployer adds embedded archives like this | // Create a context for this jar file with META-INF as the location for metadata | context = createContext(structureContext, "META-INF"); | | // The classpath is the root | addClassPath(structureContext, file, true, true, context); | | // Add archive children to the classpath | for (VirtualFile child : root.getChildren()) | { | if (child.isArchive()) | addClassPath(structureContext, child, true, true, context); | } | In this post http://www.jboss.org/index.html?module=bb&op=viewtopic&t=162196 I describe how Bundle-ClassPath entries cause root files in the classloading policy. Should the structure deployer also be Bundle-ClassPath aware or should it perhaps not handle embedded jars at all? Please advice. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259295#4259295 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4259295

14 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

jboss-osgi-dev October 2009