[Design of OSGi Integration] - Javadocs and OO design
by alesj
John, I don't want to bother you, but I will. ;-)
Code needs javadocs, even as trivial as a simple getter.
I might have missed some of it in the osgi-int code, but the rest of MC is well javadocumentized. :-)
Simple things require very simple javadocs, something more abstract should get some more effort.
You can create as much as util classes as you like, in order to make things proper OO.
I don't mind if you have many helpers, as long as they make sense. And have proper package location.
But the N of ifs/else ifs is not good OO design. :-)
For example BundleHeaders could be split into many small util classes, that just take metadata and do a single method check, if that's not-null, put it into previously provided map.
I know it's 20 classes for a single task, but they can all be private classes inside the same BundleHeaders class, and it's a lot easier to not make a mistake while maintaining it.
The same (as I already posted) applies with BundleImpl.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131878#4131878
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131878
18 years, 1 month
[Design of OSGi Integration] - Re: Facade Questions
by alesj
"johnbailey" wrote :
| 1. What is the best way to get the location of the deployed asset (jar, etc..). I see the name of the VFSFile in the name of the DeploymentContext, but I want to make sure the location returned will always be a valid path to the asset. The Bundle Facade needs to return the location as well as search for entries without a classloader (Bundle.getEntry, Bundle.getEntryPaths)
|
The DeploymentContext should really be VFSDeploymentContext.
And that one has all the hooks you need.
"johnbailey" wrote :
| 2. Will we be supporting the OSGI AdminPermission checks?
|
We should. But it's not a priority.
I still need to look at that more thoroughly.
"johnbailey" wrote :
| 3. Is there an existing Id that can be used for the Bundle ID? It needs to be unique, and I don't want to create a new scheme if there is something in place to use.
|
Underlying context name should do.
That's how module's get their name.
| private static String determineContextName(DeploymentUnit unit)
| {
| if (unit == null)
| throw new IllegalArgumentException("Null unit");
| ControllerContext context = unit.getAttachment(ControllerContext.class);
| if (context == null)
| throw new IllegalStateException("Deployment has no controller context");
| return (String) context.getName();
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131865#4131865
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131865
18 years, 1 month
[Design of OSGi Integration] - Re: Facade Questions
by alesj
"johnbailey" wrote : Makes sense. I wasn't sure if it would be in a state that would allow it to move directly to INSTALLED.
|
You can always try to move it to any state from any state (except error state).
But it doesn't mean it will actually move there - e.g. still some unresolved dependencies 'blocking' the transition.
"johnbailey" wrote :
| The getState method will simply map the ControllerState to an equivelent Bundle State. Are the following resonable?
|
|
| | ControllerState controllerState = getControllerContext().getState();
| | if (ControllerState.ERROR.equals(controllerState))
| | {
| | bundleState = Bundle.INSTALLED; // Seems strange, but see javadoc
| | }
| | else if (ControllerState.NOT_INSTALLED.equals(controllerState))
| | {
| | bundleState = Bundle.UNINSTALLED;
| | }
| | else if (ControllerState.PRE_INSTALL.equals(controllerState)
| | || ControllerState.DESCRIBED.equals(controllerState))
| | {
| | bundleState = Bundle.INSTALLED;
| | }
| | else if (ControllerState.INSTANTIATED.equals(controllerState)
| | || ControllerState.CONFIGURED.equals(controllerState)
| | || ControllerState.CREATE.equals(controllerState))
| | {
| | bundleState = Bundle.RESOLVED;
| | }
| | else if (ControllerState.START.equals(controllerState))
| | {
| | bundleState = Bundle.STARTING;
| | }
| | else if (ControllerState.INSTALLED.equals(controllerState))
| | {
| | bundleState = Bundle.ACTIVE;
| | }
| |
|
Let's make this more OO. ;-)
e.g.
| List<BundleState2ControllerState> states ...
| ...
| for(BundleState2ControllerState bs2cs : states)
| {
| if (bs2cs.getControllerState().equals(state))
| return bs2cs.getBundleState();
| }
| throw new IllegalArgumentException("No such matching BS2CS.");
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131858#4131858
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131858
18 years, 1 month
[Design of JBoss Build System] - Re: Moving jbossas to a maven repo for thirdparty
by pgier
Unfortunately the mapping part will be separate from the dependencies, because the mapping will have to be a parameter to the plugin. I can't change the XML for the dependencies in the pom without hacking up and forking the maven code. I'll post an example tomorrow of what it looks like once I get a couple more of the details figured out.
I'm going to make this a new mojo (maven plugin class) in the current jboss-deploy plugin because they can share some code for writing component-info files and other stuff. I'm thinking about renaming the plugin to something like jboss-thirdparty plugin, but that's low priority.
I'll post artifacts that aren't in the repository as I find them. It shouldn't be too bad to add the ones that are missing. They don't have to be built with maven, they can just have a basic auto-generated pom. I had to add some stuff like that already when I was working on the app server poms that are there now.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131851#4131851
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131851
18 years, 1 month
[Design of OSGi Integration] - Re: Facade Questions
by johnbailey
Makes sense. I wasn't sure if it would be in a state that would allow it to move directly to INSTALLED.
The getState method will simply map the ControllerState to an equivelent Bundle State. Are the following resonable?
| ControllerState controllerState = getControllerContext().getState();
| if (ControllerState.ERROR.equals(controllerState))
| {
| bundleState = Bundle.INSTALLED; // Seems strange, but see javadoc
| }
| else if (ControllerState.NOT_INSTALLED.equals(controllerState))
| {
| bundleState = Bundle.UNINSTALLED;
| }
| else if (ControllerState.PRE_INSTALL.equals(controllerState)
| || ControllerState.DESCRIBED.equals(controllerState))
| {
| bundleState = Bundle.INSTALLED;
| }
| else if (ControllerState.INSTANTIATED.equals(controllerState)
| || ControllerState.CONFIGURED.equals(controllerState)
| || ControllerState.CREATE.equals(controllerState))
| {
| bundleState = Bundle.RESOLVED;
| }
| else if (ControllerState.START.equals(controllerState))
| {
| bundleState = Bundle.STARTING;
| }
| else if (ControllerState.INSTALLED.equals(controllerState))
| {
| bundleState = Bundle.ACTIVE;
| }
|
Want to make sure I get this correct.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131848#4131848
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131848
18 years, 1 month
[Design of JBoss Build System] - Re: Moving jbossas to a maven repo for thirdparty
by scott.stark＠jboss.org
So the mapping would be configured something like:
| <plugin>
| ...
| <configuration>
| <groupId>org.apache.maven.plugins</groupId>
| <artifactId>maven-compiler-plugin</artifactId>
| <dependencies>
| <dependency>
| <groupId>org.jboss</groupId>
| <artifactId>jboss-common-core</artifactId>
| <mapping>
| <groupId>org.jboss</groupId>
| <artifactId>jboss-common-core</artifactId>
| </mapping>
| </dependency>
| <dependency>
| <groupId>org.jboss.microcontainer</groupId
| <artifactId>jboss-aop-mc-int</artifactId>
| <mapping>
| <groupId>jboss.microcontainer</groupId>
| <artifactId>jboss-aop-mc-int</artifactId>
| </mapping>
| </dependency>
| <dependency>
| <groupId>org.jboss.microcontainer</groupId>
| <artifactId>jboss-dependency</artifactId>
| <mapping>
| <groupId>jboss.microcontainer</groupId>
| <artifactId>jboss-dependency</artifactId>
| </mapping>
| </dependency>
| ...
| <dependency>
| <groupId>jboss</groupId
| <artifactId>jboss-cache</artifactId>
| <mapping>
| <groupId>jboss.cache</groupId>
| <artifactId>jbosscache</artifactId>
| </mapping>
| </dependency>
| ...
| </dependencies>
| </configuration>
| </plugin>
|
the problem I still see are the artifacts not in maven. For example, the jboss repo for jboss/cache includes a jbosscache.jar & pojocache.jar. I don't see any pojo cache artifact in maven. I guess these will have to be added to maven. I would put out a list of these first so that we can start adding them.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131727#4131727
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131727
18 years, 1 month