I am trying to create a GoGo-Shell-Command using the Felix-Dependency-Manager (Version 3.2.0) without Annotations.
As far as I understand, the gogo-runtime uses the whiteboard-pattern and scans for services with Properties using the keys CommandProcessor.COMMAND_SCOPE and CommandProcessor.COMMAND_FUNCTION.
In my case, the bundle is started, the service is registered with the correct properties but my command is not listed under "help" nor does it work when I try to call it.
The following code registers the service within the BundleActivator (DependencyActivatorBase):
Properties props = new Properties();
props.put(CommandProcessor.COMMAND_SCOPE, "test");
props.put(CommandProcessor.FUNCTION_SCOPE, new String[] {"command"});
manager.add(createComponent()
.setInterface(Object.class.getName(), props)
.setImplementation(MyConsole.class)
.add(createServiceDependency()
.setService(MyService.class)));
The following bundles are listed with lb-Command when running my code.
org.apache.felix.gogo.command
org.apache.felix.gogo.runtime
org.apache.felix.gogo.shell
org.apache.felix.dependencymanager
org.apache.felix.dependencymanager.shell
mybundle.service
mybundle.api
mybundle.console
Development is done with BndTools.
Am I missing something here?
First of all, your assumption about how to register gogo commands is correct: a whiteboard pattern is used and the scope and function properties determine the commands.
You did not post the code for MyConsole. Does it actually contain a method called command? If not, that could be the problem.
Another potential problem could be that you did not actually add a Bundle-Activator line in your manifest.
If that's not it, use the dm notavail command to see if there are any unregistered components (because of missing dependencies).
Related
I succeedeed in creating my own OAuth2 server using JCache as token store but I'm facing an issue when moving to JPA.
My configuration is :
"--users","test=test",
"--roles","test=test",
"--oauth2-provider","jpa",
"--oauth2-jpa-database-driver","org.h2.Driver",
"--oauth2-jpa-database-url","jdbc:h2:mem:oauth",
"--oauth2-jpa-database-username","sa",
"--oauth2-jpa-database-password",""
But I got exception below during OpenJPA bootstrap :
here was an error while setting up the configuration plugin option "MetaDataFactory".
The plugin was of type "org.apache.openjpa.persistence.jdbc.PersistenceMappingFactory".
Setter methods for the following plugin properties were not available in that type: [
org.apache.cxf.rs.security.oauth2.tokens.bearer.BearerAccessToken,
org.apache.cxf.rs.security.oauth2.common.OAuthPermission,
org.apache.cxf.rs.security.oauth2.tokens.refresh.RefreshToken,
org.apache.cxf.rs.security.oauth2.grants.code.ServerAuthorizationCodeGrant,
org.apache.cxf.rs.security.oauth2.common.UserSubject].
Possible plugin properties are:
[AnnotationParser, ClasspathScan, FieldOverride, Files, JAR_FILE_URLS, MAPPING_FILE_NAMES, MODE_ALL, MODE_ANN_MAPPING, MODE_MAPPING, MODE_MAPPING_INIT, MODE_META, MODE_NONE, MODE_QUERY, PERSISTENCE_UNIT_ROOT_URL, Repository, Resources, STORE_DEFAULT, STORE_PER_CLASS, STORE_VERBOSE, StoreDirectory, StoreMode, Strict, Types, URLs, XMLAnnotationParser, XMLParser].
Ensure that your plugin configuration string uses key values that correspond to setter methods in the plugin class.
I suppose I missed something in configuration...
Any help would be appreciated.
Tx
Using --oauth2-jpa-properties you can set any persistence unit properties you want, I guess you will have to override openjpa.MetaDataFactory default value which is set to jpa(Types=org.apache.cxf.rs.security.oauth2.common.Client,org.apache.cxf.rs.security.oauth2.common.OAuthPermission,org.apache.cxf.rs.security.oauth2.common.UserSubject,org.apache.cxf.rs.security.oauth2.grants.code.ServerAuthorizationCodeGrant,org.apache.cxf.rs.security.oauth2.tokens.bearer.BearerAccessToken,org.apache.cxf.rs.security.oauth2.tokens.refresh.RefreshToken).
You can also check if your configuration is properly propagated and if there is no classpath conflict (another persistence.xml with an oauth2 unit?) because I just retested and your configuration seems to work.
Romain
I am using ICN 3.0.3 IF7. I have a custom plugin that writes the following error to the console when I initially configure it into ICN.
The plugin itself works fine once configured.
Uncaught TypeError: cls is not a constructor
at Object.eval (ecm/widget/layout/AdminPane.js:9845)
at dojo.js.jgz:22442
at runFactory (dojo.js.jgz:611)
at execModule (dojo.js.jgz:691)
at dojo.js.jgz:397
at guardCheckComplete (dojo.js.jgz:699)
at contextRequire (dojo.js.jgz:396)
at req (dojo.js.jgz:32)
at Object._displayPluginConfig (ecm/widget/layout/AdminPane.js:9844)
at Object._pluginRequestCompleted (ecm/widget/layout/AdminPane.js:9759)
In addition, once it is configured, I cannot get the details on it like I can for the included AFP Viewer plugin:
Name: AFP Viewer
Version: 2.0.3.5
Repository types: None
Actions: None
Open Actions: None
Viewers: AFP Viewer
Features: None
Layouts: None
It seems like something is wrong with the plugin structure that doesn't affect its ability to run. I am worried because I just don't like seeing errors. Has anyone seen this before?
Looking at the error it seems like the module you specified in the plugin.java#getConfigurationDijitClass is either failing to instantiate, or isn't specified at all.
If you have a configuration dijit class configured, then ensure it's actually a widget and that it's constructor and postCreate method (if provided) don't throw an error :).
If you don't have one configured, set it to null to prevent instantiation
We're trying to let two JBoss EAP 6.2 Servers communicate via JNDI.
One server is using it's own LoginModule .
The first server will recieve requests via webservices and delegate them to the second server. For that reason, the first server needs to log in to look for the beans it needs to delegate.
I've figured out, that we need the following information to connect to the main (second) server:
remote.connections=default
endpoint.name=client-endpoint
remote.connection.default.port=4447
remote.connection.default.host=localhost
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false
remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER
remote.connection.default.callback.handler.class=our.own.callbackhandler.class
java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.factory.url.pkgs=org.jboss.ejb.client.naming
We put this information into the 'jboss-ejb-client.properties' file, but our server didn't react on that.
The tutorial (https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+server+instance) says that we need to use the jboss-ejb-client.xml.
Because of our LoginModule (and Callbackhandler) we don't need an user and/or password to connect to the server!
My first solution for that problem is putting all information into the InitialContext using the Properties-Class.
final Properties props = new Properties();
props.put("remote.connections", "default");
props.put("remote.connection.default.host", "localhost");
props.put("remote.connection.default.port", "4447");
props.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS", "false");
props.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");
props.put("remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS", "JBOSS-LOCAL-USER");
props.put("remote.connection.default.callback.handler.class",
"our.own.callbackhandler.class");
props.put("org.jboss.ejb.client.scoped.context", "true");
props.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false");
props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
Context ic = new InitialContext(prop);
It's working that way.
My question now is: Is there any workaround to put that information in the standalone.xml or jboss-ejb-client.properties / jboss-ejb-client.xml?
I did not find any place to put the classname of our Callbackhandler.
Thank you in advance.
Try turning up the logging for the category org.jboss.ejb.client to DEBUG or TRACE and you should see where the server is trying to read jboss-ejb-client.properties from.
I'm running JBoss 4.2.2. I'm trying to determine the correct code to both:
Lookup the org.jboss.resource.connectionmanager.JBossManagedConnectionPool
Perform a flush() operation on said pool.
I've found a couple other questions out there with no answers. I'm hoping this doesn't become yet another one of them.
The closest question I've found so far: https://community.jboss.org/message/637784
Here's the basics using a quickie groovy example.
First, you want jboss-4.2.2/client/jbossall-client.jar in your classpath.
Next, you need the JMX ObjectName of the data source. It may be helpful to find this in the JMX Console at http://localhost:8080/jmx-console/ or however you have deployed. So the string value of the ObjectName is the domain + ":" + the properties.
For example:
The ObjectName is: jboss.jca:name=DefaultDS,service=ManagedConnectionPool.
Next, look up the RMIAdaptor in JNDI. This is the MBeanServer interfac that will allow you to invoke the flush operation on the target MBean. Then call the invocation. That's it.
import javax.management.*;
import javax.naming.*;
p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
p.put(Context.PROVIDER_URL, "localhost:1099");
ctx = new InitialContext(p);
rmiAdaptor = ctx.lookup("jmx/rmi/RMIAdaptor");
rmiAdaptor.invoke(new ObjectName("jboss.jca:name=DefaultDS,service=ManagedConnectionPool"), "flush", [] as Object[], [] as String[]);
Make sense ?
===== Update =====
If you are executing this from inside the JBoss JVM, you don't need the JNDI setup:
import javax.management.*;
import org.jboss.mx.util.MBeanServerLocator;
MBeanServer server = MBeanServerLocator.locateJBoss();
server.invoke(new ObjectName("jboss.jca:name=DefaultDS,service=ManagedConnectionPool"), "flush", [] as Object[], [] as String[]);
I have successfully configured our app to export Quartz's MBeans into JMX and can view everything in JConsole. I can run the majority of the scheduler operations.
The one I really want to run is 'triggerJob', but that is showing up in JConsole as greyed-out/disabled so I can't run it.
I've scanned the commits that added the JMX code to Quartz but can't see any differences between triggerJob and the other operations that are enabled.
Anyone have a clue what's going on?
EDIT - explanation found
A different StackOverflow issue describes what's going on: Why are some methods on the JConsole disabled
triggerJob (and two other operations) take non-primitive parameters, these complex parameters cannot be provided in JConsole.
I am not clear if the MBean provider might provide a custom editor for JConsole (or simlar), but at least I have my answer.
Thank you for your explanation. I have successfully triggered a job remotely through JMX using the following Groovy code:
def callParams = new Object[3]
callParams[0] = 'com.test.project.TestJob'
callParams[1] = 'DEFAULT_JOB_GROUP'
callParams[2] = new HashMap()
def callSignature = new String[3]
callSignature[0] = 'java.lang.String'
callSignature[1] = 'java.lang.String'
callSignature[2] = 'java.util.Map'
// server is an instance of MBeanServerConnection
server.invoke('triggerJob', callParams, callSignature)