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

[Design of JBoss Admin Console] - Re: Admin Console URL

by saguilar

Does anybody knows how to change the default port 8080 of those consoles? I'm installing jboss AS 4.2.3 on a shared server running SunOS and would like to avoid conflicts with that port. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213207#4213207 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213207

14 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Integrating platform mbeans into kernel bus?

by scott.stark＠jboss.org

Ok, I have the dispatch working using a subclass of AbstractKernelRegistryEntry that implements InvokeDispatchContext, but there is an issue with the RuntimeComponentDispatcher implementation and spi. The problem with the implementation is that it does not build the correct signature for a method if the method takes a primitive. The signature is java.lang.Long rather than just long. However, the MetaType spi does not have an isPrimitive notion, so there is not much the default RuntimeComponentDispatcher can do. I can work around this in my InvokeDispatchContext and try to match the invocation against the MBeanOperationInfo metadata. In general we need a notion of primitives in MetaType, or we need it on the ManagedParameter api. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213189#4213189 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213189

14 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1

by bstansberry＠jboss.com

Sounds good. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213177#4213177 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213177

14 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1

by emuckenhuber

"bstansberry(a)jboss.com" wrote : | So with the kind of setup I'm talking about, having the default profile be the one associated with ProfileKey($jboss.server.name}) would not work, since it will have no URIs associated with it. | | I think the key question for 5.1 is how embedded-console/jopr are using the DeploymentManager -- what ProfileKey are the passing to loadProfile (or to your new distribute(String name, URL url, ProfileKey key) method. Well we can create a additional application (deploy/) profile by default, as it's more likely to be similar with the XmlProfileFactory - and would match what you are doing. Furthermore we could add a getProfiles() to the DeploymentManager (maybe with the notion of mutable profiles) then jopr could provide a dropdown menu to select where you actually want to upload your content to. As the profiles from ProfileService are not necessarily 'mutable' profiles. And we can also make those names configurable over the profile.xml. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213175#4213175 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213175

14 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1

by bstansberry＠jboss.com

"emuckenhuber" wrote : | There is a sort of defaultProfileKey notion - so when you do e.g. profileService.getActiveProfile(new ProfileKey(null)); it would return the profile associated with ProfileKey($jboss.server.name}). | So distribute(String name, URL url, copyContent = true) would add it to the injected default profile. So with the kind of setup I'm talking about, having the default profile be the one associated with ProfileKey($jboss.server.name}) would not work, since it will have no URIs associated with it. I think the key question for 5.1 is how embedded-console/jopr are using the DeploymentManager -- what ProfileKey are the passing to loadProfile (or to your new distribute(String name, URL url, ProfileKey key) method. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213170#4213170 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213170

14 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Changing ClassLoader creation

by alesj

While using Runtime and its underlying framework we need to use the ClassLoader created by underlying OSGi framework, actually its Bundle instance that can mock ClassLoader. We can do this by implementing ClassLoaderFactory and adding it as an attachment. But I see we cannot avoid the usage of * ClassLoadingDefaultDeployer * VFSClassLoaderClassPathDeployer * VFSClassLoaderDescribeDeployer I guess it's best if we add empty/non-exposing CLMD to attachments, when we use Runtime, so that Module is not able to expose anything? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213169#4213169 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213169

14 years, 1 month

1
0
0 / 0

[Design of JBoss Tools (dev)] - Can't compile Jbpm tool

by paucarre

After configuring the build_local.properties properly ANT gives me an error: Buildfile: C:\Users\Pau\workspace\jbpm\builders\org.jboss.tools.flow.jpdl4.builder\build.xml main: -properties: -clean: [echo] Cleaning directory C:/Users/Pau/workspace/jbpm/builders/org.jboss.tools.flow.jpdl4.builder//target/ [delete] Deleting directory C:\Users\Pau\workspace\jbpm\builders\org.jboss.tools.flow.jpdl4.builder\target [mkdir] Created dir: C:\Users\Pau\workspace\jbpm\builders\org.jboss.tools.flow.jpdl4.builder\target -prepare.build.host: unpack.eclipse: -unpack.eclipse.ifnecessary: -build: -build.internal: [java] Buildfile: C:/Users/Pau/eclipse/plugins/org.eclipse.pde.build_3.4.1.R34x_v20080805/scripts/build.xml [java] main: [java] preBuild: [java] preSetup: [java] getMapFiles: [java] [echo] Copying map files. [java] [copy] Copying 1 file to C:\Users\Pau\workspace\jbpm\builders\org.jboss.tools.flow.jpdl4.builder\target\maps [java] postSetup: [java] fetch: [java] preFetch: [java] allElements: [java] allElementsExceptSvnFetch: [java] norcpbuild: [java] init: [java] fetchElement: [java] [mkdir] Created dir: C:\Users\Pau\workspace\jbpm\builders\org.jboss.tools.flow.jpdl4.builder\target\features [java] [mkdir] Created dir: C:\Users\Pau\workspace\jbpm\builders\org.jboss.tools.flow.jpdl4.builder\target\plugins BUILD FAILED C:\Users\Pau\workspace\jbpm\builders\org.jboss.tools.flow.jpdl4.builder\build.xml:183: The following error occurred while executing this line: C:\Users\Pau\workspace\jbpm\builders\org.jboss.tools.flow.jpdl4.builder\build.xml:81: The following error occurred while executing this line: C:\Users\Pau\workspace\jbpm\builders\org.jboss.tools.flow.jpdl4.builder\build.xml:116: Java returned: 13 Total time: 5 seconds The configuration file is: # The location of this pluginbuilder project. It provides the base directory for the build scripts. # @category localsettings # @type Directory buildHome=C:/Users/Pau/workspace/jbpm/builders/org.jboss.tools.flow.jpdl4.builder/ # The directory where the build takes place. This directory WILL BE DELETED before every build. # @category localsettings # @type Directory buildDirectory=${buildHome}/target/ # The eclipse build host. Must be an Eclipse SDK installation with JDT and PDE. And in the case of RCP builds the RCP Delta Pack must be included, too. # @category localsettings # @type Directory eclipseDir=C:/Users/Pau/eclipse/ # Environment for both the Eclipse build and test host. Determines baseos. # @category localsettings os=win32 # Environment for both the Eclipse build and test host. Determines basews. # @category localsettings ws=win32 # Environment for both the Eclipse build and test host. Determines basearch. # @category localsettings arch=x86 The build.xml line that fails is: java classname="org.eclipse.equinox.launcher.Main" fork="true" Any idea? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213168#4213168 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213168

14 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Re: New project structure

by thomas.diesler＠jboss.com

Here it is online https://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/trunk/ View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213161#4213161 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213161

14 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Runtime and bundle lifecycle/dependency resolution

by alesj

In Runtime when we delegate most of the work to underlying OSGi framework, we still need to tie into existing MC's lifecycle/dependency handling. Otherwise the bundle will be pushed to Installed even though its cl isn't resolved. We need to add a new DependencyItem which does it's resolution based on Bundle resolution. e.g. BudleDependencyItem | public boolean resolve(Controller controller) | { | return bundle.isResolved(); // pseudo method | } | Perhaps this also requires additional deployers that will change the Bundle's state. * one that would just install the bundle * another one that would create it * one that would start it (after bundle/cl was resolved) (I need to check the spec on how exactly this goes :-)) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213159#4213159 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213159

14 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1

by emuckenhuber

ManagementView is handling all active profiles, so that should be fine. But i'm not really sure about the DeploymentManager. I mean it should be possible to define to which profile you want to add your content. Although we might need to drop the loadProfile and releaseProfile, as this does not seem to be thread safe. It might make more sense to have just: | deploymentMgr.distribute(String name, URL url, boolean copyContent); | // and | deploymentMgr.distribute(String name, URL url, ProfileKey key); | Whereas the 2nd way would imply copyContent == true. As transient deployments are handled by a own profile now. So we might want to have load() where it creates a mapping between a deployment and the profile. So you can stop and remove all deployments easily. And for distribute and start we would need to cache the DeploymentID with it's profile. And those stuff will get cleaned when you do release(). There is a sort of defaultProfileKey notion - so when you do e.g. profileService.getActiveProfile(new ProfileKey(null)); it would return the profile associated with ProfileKey($jboss.server.name}). So distribute(String name, URL url, copyContent = true) would add it to the injected default profile. Whereas we might also want to differentiate between a normal Profile and a MutableProfile - where you can add and remove content. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213137#4213137 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213137

14 years, 1 month

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2009