Karaf 3.0.0 Console Extender
Hi, I am trying to create a bundle that will provide me with custom commands in the console. My blueprint file looks like this: blueprint xmlns=*http://www.osgi.org/xmlns/blueprint/v1.0.0* command-bundle xmlns=*http://karaf.apache.org/xmlns/shell/v1.1.0* command name=*test/sample* action class=*com.test.sample.shell.commands.SampleCommand* / /command /command-bundle /blueprint The pom.xml has the bundle-plugin configured like this: plugin groupIdorg.apache.felix/groupId artifactIdmaven-bundle-plugin/artifactId version2.3.7/version extensionstrue/extensions configuration instructions Import-Package org.apache.felix.service.command, org.apache.karaf.shell.commands, org.apache.karaf.shell.console, org.osgi.service.blueprint.container, org.osgi.service.blueprint.reflect, org.apache.aries.blueprint, * /Import-Package /instructions /configuration /plugin However, when I deploy this to Karaf 3.0-SNAPSHOT, I am getting the following error: Unable to start blueprint container for bundle com.fico.ifm.scheduler.shell.commands org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to validate xml at org.apache.aries.blueprint.parser.Parser.validate(Parser.java:288)[25:org.apache.aries.blueprint.core:1.0.1] at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:304)[25:org.apache.aries.blueprint.core:1.0.1] at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:252)[25:org.apache.aries.blueprint.core:1.0.1] at org.apache.aries.blueprint.container.BlueprintExtender.checkBundle(BlueprintExtender.java:315)[25:org.apache.aries.blueprint.core:1.0.1] at org.apache.aries.blueprint.container.BlueprintExtender.bundleChanged(BlueprintExtender.java:235)[25:org.apache.aries.blueprint.core:1.0.1] at org.apache.aries.blueprint.container.BlueprintExtender$BlueprintBundleTrackerCustomizer.modifiedBundle(BlueprintExtender.java:434)[25:org.apache.aries.blueprint.core:1.0.1] at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:198)[8:org.apache.aries.util:1.0.0] at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:128)[8:org.apache.aries.util:1.0.0] at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:468)[8:org.apache.aries.util:1.0.0] at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:161)[8:org.apache.aries.util:1.0.0] at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:117)[8:org.apache.aries.util:1.0.0] at org.eclipse.osgi.framework.internal.core.Framework$10.call(Framework.java:1606)[osgi-3.8.0.v20120529-1548.jar:] at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1239)[osgi-3.8.0.v20120529-1548.jar:] at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHooksPrivileged(ServiceRegistry.java:1222)[osgi-3.8.0.v20120529-1548.jar:] at org.eclipse.osgi.framework.internal.core.Framework.notifyEventHooksPrivileged(Framework.java:1603)[osgi-3.8.0.v20120529-1548.jar:] at org.eclipse.osgi.framework.internal.core.Framework.publishBundleEventPrivileged(Framework.java:1558)[osgi-3.8.0.v20120529-1548.jar:] at org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent(Framework.java:1505)[osgi-3.8.0.v20120529-1548.jar:] at org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent(Framework.java:1500)[osgi-3.8.0.v20120529-1548.jar:] at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:391)[osgi-3.8.0.v20120529-1548.jar:] at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:300)[osgi-3.8.0.v20120529-1548.jar:] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1247)[17:org.apache.felix.fileinstall:3.2.6] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1219)[17:org.apache.felix.fileinstall:3.2.6] at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:508)[17:org.apache.felix.fileinstall:3.2.6] at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)[17:org.apache.felix.fileinstall:3.2.6] Caused by: org.xml.sax.SAXParseException: cvc-complex-type.3.2.2: Attribute 'name' is not allowed to appear in element 'command'. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198)[:1.6.0_24] at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134)[:1.6.0_24] at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:387)[:1.6.0_24] at
Karaf RPMs - what options are out there?
Hi all, I am currently packaging an application stack as RPMs for deployment to a production system, and am looking for RPM packages for karaf. JPackage provide a set of RPMs, but these RPMs depend on unstable (from package's perspective) packages, and weigh in at an eye watering 274MB of RPM dependencies. Has anyone other than package packaged karaf as an RPM? Regards, Graham --
Re: Karaf RPMs - what options are out there?
What would we need to do to provide a RPM/DEB package? Where/how would we need to distribute it? Kind regards, Andreas On Tue, Jan 15, 2013 at 6:09 PM, aj...@virginia.edu aj...@virginia.edu wrote: I have, for local consumption. I based the build on an ActiveMQ RPM script. It wasn't too difficult and I can send you the example, if you like. There has been discussion before on this list about maintaining a semi-blessed RPM of Karaf directly from the project. I'd be happy to work on that, if I could get guidance and help integrating it into the release process. --- A. Soroka Software Systems Engineering :: Online Library Environment the University of Virginia Library On Jan 15, 2013, at 11:53 AM, Graham Leggett wrote: Hi all, I am currently packaging an application stack as RPMs for deployment to a production system, and am looking for RPM packages for karaf. JPackage provide a set of RPMs, but these RPMs depend on unstable (from package's perspective) packages, and weigh in at an eye watering 274MB of RPM dependencies. Has anyone other than package packaged karaf as an RPM? Regards, Graham --
Re: Can not login into karaf-webconsole on Karaf 2.3.0 and 2.2.10
Hi I have created i Jira issue for this problem https://issues.apache.org/jira/browse/KARAF-2118 Best regards Krzysztof On Tuesday 15 of January 2013 02:09:00 you wrote: It works for 2.2.10. I had to upgrade the karaf.version to 2.2.10 and add the *.karaf.jaas.boot dependency to the karaf-webconsole/core. 2.3.0 not tested yet. Regards Krzysztof Sobkowiak On Jan 15, 2013 1:13 AM, Achim Nierbeck bcanh...@googlemail.com wrote: Ok, looks like it's not adapted to the latest changes for roles, since you checked out the sources, you might just need to change the dependencies from org.apache.karaf.jaas.modules.RolePrincipal to org.apache.karaf.jaas.boot.principal.RolePrincipal regards, Achim 2013/1/15 Krzysztof Sobkowiak krzys.sobkow...@gmail.com Hi I have checked out and built the latest karaf-webconsole sources. I can install and access the console on Karaf 2.2.9. I can also install it on 2.2.10 and 2.3.0, but login into console causes following exception: java.lang.NoClassDefFoundError: org/apache/karaf/jaas/modules/RolePrincipal at org.apache.karaf.webconsole.core.security.KarafJaasWebSession.isRole(KarafJaasWebSession.java:39) at org.apache.karaf.webconsole.core.security.JaasWebSession.authenticate(JaasWebSession.java:66) at org.apache.wicket.authroles.authentication.AuthenticatedWebSession.signIn(AuthenticatedWebSession.java:65) at org.apache.wicket.authroles.authentication.panel.SignInPanel.signIn(SignInPanel.java:221) at org.apache.wicket.authroles.authentication.panel.SignInPanel.access$100(SignInPanel.java:51) at org.apache.wicket.authroles.authentication.panel.SignInPanel$SignInForm.onSubmit(SignInPanel.java:296) at org.apache.wicket.markup.html.form.Form$9.component(Form.java:1246) at org.apache.wicket.markup.html.form.Form$9.component(Form.java:1240) Regards Krzysztof Sobkowiak -- Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead OPS4J Pax for Vaadin http://team.ops4j.org/wiki/display/PAXVAADIN/Home Commiter Project Lead blog http://notizblog.nierbeck.de/
Re: Karaf RPMs - what options are out there?
I can't speak to DEB, but a RPM is made by running a build script over a distribution. The script explains any prerequisites (in Karaf's case, just Java) where to put files, what permissions to use, what files are marked as to be deleted on uninstall, that kind of thing. Distribution varies, but there are a handful of large RPM repositories (mostly associated with different Linux distros) that we could target. They fulfill much the same role as Maven repos. --- A. Soroka Software Systems Engineering :: Online Library Environment the University of Virginia Library On Jan 15, 2013, at 12:14 PM, Andreas Pieber wrote: What would we need to do to provide a RPM/DEB package? Where/how would we need to distribute it? Kind regards, Andreas On Tue, Jan 15, 2013 at 6:09 PM, aj...@virginia.edu aj...@virginia.edu wrote: I have, for local consumption. I based the build on an ActiveMQ RPM script. It wasn't too difficult and I can send you the example, if you like. There has been discussion before on this list about maintaining a semi-blessed RPM of Karaf directly from the project. I'd be happy to work on that, if I could get guidance and help integrating it into the release process. --- A. Soroka Software Systems Engineering :: Online Library Environment the University of Virginia Library On Jan 15, 2013, at 11:53 AM, Graham Leggett wrote: Hi all, I am currently packaging an application stack as RPMs for deployment to a production system, and am looking for RPM packages for karaf. JPackage provide a set of RPMs, but these RPMs depend on unstable (from package's perspective) packages, and weigh in at an eye watering 274MB of RPM dependencies. Has anyone other than package packaged karaf as an RPM? Regards, Graham --
Re: Can not login into karaf-webconsole on Karaf 2.3.0 and 2.2.10
If JB isn't faster I might be able to look at it tonight ;) 2013/1/15 Krzysztof Sobkowiak krzys.sobkow...@gmail.com ** Hi I have created i Jira issue for this problem https://issues.apache.org/jira/browse/KARAF-2118 Best regards Krzysztof On Tuesday 15 of January 2013 02:09:00 you wrote: It works for 2.2.10. I had to upgrade the karaf.version to 2.2.10 and add the *.karaf.jaas.boot dependency to the karaf-webconsole/core. 2.3.0 not tested yet. Regards Krzysztof Sobkowiak On Jan 15, 2013 1:13 AM, Achim Nierbeck bcanh...@googlemail.com wrote: Ok, looks like it's not adapted to the latest changes for roles, since you checked out the sources, you might just need to change the dependencies from org.apache.karaf.jaas.modules.RolePrincipal to org.apache.karaf.jaas.boot.principal.RolePrincipal regards, Achim 2013/1/15 Krzysztof Sobkowiak krzys.sobkow...@gmail.com Hi I have checked out and built the latest karaf-webconsole sources. I can install and access the console on Karaf 2.2.9. I can also install it on 2.2.10 and 2.3.0, but login into console causes following exception: java.lang.NoClassDefFoundError: org/apache/karaf/jaas/modules/RolePrincipal at org.apache.karaf.webconsole.core.security.KarafJaasWebSession.isRole(KarafJaasWebSession.java:39) at org.apache.karaf.webconsole.core.security.JaasWebSession.authenticate(JaasWebSession.java:66) at org.apache.wicket.authroles.authentication.AuthenticatedWebSession.signIn(AuthenticatedWebSession.java:65) at org.apache.wicket.authroles.authentication.panel.SignInPanel.signIn(SignInPanel.java:221) at org.apache.wicket.authroles.authentication.panel.SignInPanel.access$100(SignInPanel.java:51) at org.apache.wicket.authroles.authentication.panel.SignInPanel$SignInForm.onSubmit(SignInPanel.java:296) at org.apache.wicket.markup.html.form.Form$9.component(Form.java:1246) at org.apache.wicket.markup.html.form.Form$9.component(Form.java:1240) Regards Krzysztof Sobkowiak -- Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead OPS4J Pax for Vaadin http://team.ops4j.org/wiki/display/PAXVAADIN/Home Commiter Project Lead blog http://notizblog.nierbeck.de/ -- Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead OPS4J Pax for Vaadin http://team.ops4j.org/wiki/display/PAXVAADIN/Home Commiter Project Lead blog http://notizblog.nierbeck.de/
Re: Karaf RPMs - what options are out there?
On 15 Jan 2013, at 7:09 PM, aj...@virginia.edu wrote: I have, for local consumption. I based the build on an ActiveMQ RPM script. It wasn't too difficult and I can send you the example, if you like. If you can, I would hugely appreciate it. There has been discussion before on this list about maintaining a semi-blessed RPM of Karaf directly from the project. I'd be happy to work on that, if I could get guidance and help integrating it into the release process. I maintain the spec file that is shipped with Apache httpd, the idea is that you can download a httpd tarball and run rpmbuild -tb tarball and it just works. All that is required is that a file called package.spec exists in the root of the tarball. (It might also work if the spec file is elsewhere in the tree, but I've not tried). I am busy looking at the jpackage version of karaf, and it seems to have a significantly different structure to that shipped by Apache. Still need to get my head around it. Regards, Graham --
Re: Karaf RPMs - what options are out there?
That's simpler than distributing an RPM to the repos, by a long ways. With that
approach, all we'd need would be the spec (build) script. I append the example
at the end of this email. As you can see, it's not very much. I'm sure it could
be better written (I'm no RPM maven {grin}) but it's a place to start. I used
the Tanuki Java wrapper as part of the dependency, because that software is
commonly available for almost any Linux distro. I also included a separate
body of source for the package (shown below as wrapper-gear) which is just
the files that Karaf creates from its wrapper: commands. These two
inclusions allow the RPM to install Karaf as a Linux system service using the
Tanuki wrapper.
Graham-- I'll send you a tarball of wrapper-gear off-list, just so you can
see what I did.
It's this worthy of opening an issue?
---
A. Soroka
Software Systems Engineering :: Online Library Environment
the University of Virginia Library
On Jan 15, 2013, at 12:26 PM, Graham Leggett wrote:
On 15 Jan 2013, at 7:09 PM, aj...@virginia.edu wrote:
I have, for local consumption. I based the build on an ActiveMQ RPM script.
It wasn't too difficult and I can send you the example, if you like.
If you can, I would hugely appreciate it.
There has been discussion before on this list about maintaining a
semi-blessed RPM of Karaf directly from the project. I'd be happy to work
on that, if I could get guidance and help integrating it into the release
process.
I maintain the spec file that is shipped with Apache httpd, the idea is that
you can download a httpd tarball and run rpmbuild -tb tarball and it
just works. All that is required is that a file called package.spec
exists in the root of the tarball. (It might also work if the spec file is
elsewhere in the tree, but I've not tried).
I am busy looking at the jpackage version of karaf, and it seems to have a
significantly different structure to that shipped by Apache. Still need to
get my head around it.
Regards,
Graham
--
[ajs6f@esbdev2 SPECS]$ cat apache-karaf.spec
# turn off Red Hat's jar repacking macro
%define __jar_repack %{nil}
#
# Spec file for packaging Apach Karaf
#
Summary: Apache Karaf
Name: apache-karaf
Version: 2.2.7
Release: 1
License: Apache
Group: Networking/Daemons
Source0:
http://www.apache.org/dyn/closer.cgi/karaf/2.2.7/apache-karaf-2.2.7.tar.gz
Source1: wrapper-gear
URL: http://karaf.apache.org/
Vendor: Apache Foundation
Packager: A. Soroka aj...@virginia.edu
BuildArch: noarch
Requires: java
Requires: tanukiwrapper
%description
Apache Karaf is a small OSGi runtime which provides a lightweight container
into which various components and applications can be deployed.
%define karaf_home /usr/share/karaf
%define karaf_data /var/cache/karaf
%define karaf_config /etc/karaf
%define karaf_deploy /var/local/karaf-deploy
%define karaf_startuplib /usr/local/lib/karaf
%define karaf_systemlib /usr/local/lib/karaf-system
%define karaf_logs /var/log/karaf
%prep
%setup
%build
# No build needed for a pure-Java application like Karaf
/bin/true
%install
# Add the karaf user and group
# the || : (or NOP) on the end allows for the condition that this user and
group already exist
/usr/sbin/groupadd --system karaf 2 /dev/null || :
/usr/sbin/useradd --comment Apache Karaf -g karaf \
--shell /bin/bash --system --home-dir %{karaf_home} karaf 2 /dev/null || :
# We put the various pieces of Karaf into FHS-appropriate places, then symln
them
# together in /usr/share/karaf.
# First copy all of the Karaf tree into %{karaf_home} (should be
/usr/share/karaf)
mkdir -p $RPM_BUILD_ROOT%{karaf_home}
mv --verbose * $RPM_BUILD_ROOT%{karaf_home}/
# Now we make the FHS locations for Karaf stuff
mkdir -p $RPM_BUILD_ROOT%{karaf_config} $RPM_BUILD_ROOT%{karaf_deploy}
$RPM_BUILD_ROOT%{karaf_deploy} \
$RPM_BUILD_ROOT%{karaf_startuplib} $RPM_BUILD_ROOT%{karaf_systemlib}
$RPM_BUILD_ROOT%{karaf_data} \
$RPM_BUILD_ROOT%{karaf_logs} $RPM_BUILD_ROOT/etc/init.d
# Now we move pieces of the tree out of there into FHS-appropriate spots and
re-symln them
pushd $RPM_BUILD_ROOT%{karaf_home}
mv etc/* $RPM_BUILD_ROOT%{karaf_config}
rmdir etc
ln -s %{karaf_config} etc
mv deploy/* $RPM_BUILD_ROOT%{karaf_deploy}
rmdir deploy
ln -s %{karaf_deploy} deploy
mv lib/* $RPM_BUILD_ROOT%{karaf_startuplib}
rmdir lib
ln -s %{karaf_startuplib} lib
mv system/* $RPM_BUILD_ROOT%{karaf_systemlib}
rmdir system
ln -s %{karaf_systemlib} system
popd
# Karaf logs show up in the data dir by default, so we make a symlink
ln -s %{karaf_logs} $RPM_BUILD_ROOT%{karaf_data}/log
# Tanuki wrapper configuration
cp -v %{SOURCE1}/karaf-wrapper.conf $RPM_BUILD_ROOT/etc/karaf/karaf-wrapper.conf
# init.d script
cp -v %{SOURCE1}/karaf $RPM_BUILD_ROOT/etc/init.d/karaf
# Java to support Wrapper operation
cp -v %{SOURCE1}/*.jar $RPM_BUILD_ROOT%{karaf_startuplib}
%post
# install
Re: Can not login into karaf-webconsole on Karaf 2.3.0 and 2.2.10
I have created a patch to which solves the problem on 2.2.10. I have also managed to create a patch which solves the problem with 2.3.0 (I can install the console and log in), but change of karaf.version to 2.3.0 causes problems while bootstrapping the itest (see attachment). Probably some other dependencies should be updated to a newer versions. Best regards Krzysztof On Tuesday 15 of January 2013 18:23:30 Achim Nierbeck wrote: If JB isn't faster I might be able to look at it tonight ;) --- T E S T S --- Running org.apache.karaf.webconsole.itest.FeaturesIntegrationTest 0[main] INFO org.ops4j.pax.exam.spi.DefaultExamSystem - Pax Exam System (Version: 2.3.0) created. 16214 [main] INFO org.openengsb.labs.paxexam.karaf.container.internal.KarafTestContainer - Wait for test container to finish its initialization [ RelativeTimeout value = 18 ] 16215 [main] INFO org.ops4j.pax.exam.rbc.client.RemoteBundleContextClient - Waiting for remote bundle context.. on 21413 name: c3ba032b-f52a-4587-b38e-2bf3f67dc11e timout: [ RelativeTimeout value = 18 ] ERROR: Error parsing system bundle export statement: org.osgi.framework.startlevel;uses:=org.osgi.framework;version=1.0, org.osgi.framework.wiring;uses:=org.osgi.resource,org.osgi.framework;version=1.1, org.osgi.framework.hooks.bundle;uses:=org.osgi.framework;version=1.1, org.osgi.framework.hooks.service;uses:=org.osgi.framework;version=1.1, org.osgi.framework.hooks.resolver;uses:=org.osgi.framework.wiring;version=1.0, org.osgi.framework.launch;uses:=org.osgi.framework;version=1.1, org.osgi.framework.namespace;uses:=org.osgi.resource;version=1.0, org.osgi.framework;version=1.7,org.osgi.framework.hooks.weaving;uses:=org.osgi.framework.wiring;version=1.0,org.osgi.resource;version=1.0,org.osgi.service.url;version=1.0,org.osgi.service.startlevel;uses:=org.osgi.framework;version=1.1,org.osgi.service.packageadmin;uses:=org.osgi.framework;version=1.2,org.osgi.service.url;version=1.0, org.osgi.util.tracker;uses:=org.osgi.framework;version=1.5.1, org.apache.karaf.jaas.boot;version=2.3.0, org.apache.karaf.jaas.boot.principal;version=2.3.0, org.apache.karaf.version;version=2.3.0, javax.accessibility, javax.activation;version=1.1, javax.activity, javax.annotation;version=1.1, javax.annotation.processing;version=1.1, javax.crypto, javax.crypto.interfaces, javax.crypto.spec, javax.imageio, javax.imageio.event, javax.imageio.metadata, javax.imageio.plugins.bmp, javax.imageio.plugins.jpeg, javax.imageio.spi, javax.imageio.stream, javax.jws, javax.jws.soap, javax.lang.model, javax.lang.model.element, javax.lang.model.type, javax.lang.model.util, javax.management, javax.management.loading, javax.management.modelmbean, javax.management.monitor, javax.management.openmbean, javax.management.relation, javax.management.remote, javax.management.remote.rmi, javax.management.timer, javax.naming, javax.naming.directory, javax.naming.event, javax.naming.ldap, javax.naming.spi, javax.net, javax.net.ssl, javax.print, javax.print.attribute, javax.print.attribute.standard, javax.print.event, javax.rmi, javax.rmi.CORBA, javax.rmi.ssl, javax.script, javax.security.auth, javax.security.auth.callback, javax.security.auth.kerberos, javax.security.auth.login, javax.security.auth.spi, javax.security.auth.x500, javax.security.cert, javax.security.sasl, javax.sound.midi, javax.sound.midi.spi, javax.sound.sampled, javax.sound.sampled.spi, javax.sql, javax.sql.rowset, javax.sql.rowset.serial, javax.sql.rowset.spi, javax.swing, javax.swing.border, javax.swing.colorchooser, javax.swing.event, javax.swing.filechooser, javax.swing.plaf, javax.swing.plaf.basic, javax.swing.plaf.metal, javax.swing.plaf.multi, javax.swing.plaf.synth, javax.swing.table, javax.swing.text, javax.swing.text.html, javax.swing.text.html.parser, javax.swing.text.rtf, javax.swing.tree, javax.swing.undo, javax.tools, javax.transaction; javax.transaction.xa; partial=true; mandatory:=partial, javax.xml, javax.xml.bind;version=2.2.1, javax.xml.bind.annotation;version=2.2.1, javax.xml.bind.annotation.adapters;version=2.2.1, javax.xml.bind.attachment;version=2.2.1, javax.xml.bind.helpers;version=2.2.1, javax.xml.bind.util;version=2.2.1, javax.xml.crypto, javax.xml.crypto.dom, javax.xml.crypto.dsig, javax.xml.crypto.dsig.dom, javax.xml.crypto.dsig.keyinfo, javax.xml.crypto.dsig.spec, javax.xml.datatype, javax.xml.namespace, javax.xml.parsers, javax.xml.soap;version=1.3, javax.xml.stream;version=1.2, javax.xml.stream.events;version=1.2, javax.xml.stream.util;version=1.2, javax.xml.transform, javax.xml.transform.dom, javax.xml.transform.sax, javax.xml.transform.stax, javax.xml.transform.stream, javax.xml.validation, javax.xml.ws;version=2.2, javax.xml.ws.handler;version=2.2, javax.xml.ws.handler.soap;version=2.2, javax.xml.ws.http;version=2.2,
Re: Can not login into karaf-webconsole on Karaf 2.3.0 and 2.2.10
Hi To solve the problem with itest with karaf.version 2.3.0 I have attached a patch upgrading the itests to PAX Exam 2.6.0 and PAX Exam Karaf Best regards Krzysztof -- Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead OPS4J Pax for Vaadin http://team.ops4j.org/wiki/display/PAXVAADIN/Home Commiter Project Lead blog http://notizblog.nierbeck.de/
Re: Gogo vs. Karaf Commands
Hi Gokturk, I am interested in seeing this happen as well. Perhaps you can share what you did so far on github? Just make a fork of apache karaf then push your changes to your fork? thanks, Gareth -- View this message in context: http://karaf.922171.n3.nabble.com/Gogo-vs-Karaf-Commands-tp4027219p4027303.html Sent from the Karaf - User mailing list archive at Nabble.com.
Karaf Cellar 3.0.0 SNAPSHOT
I know I was told that this version isn't stable yet, but I still wanted to see if the build should be able to complete successfully or not. I want to determine if some issues I'm having are something on my end or not. Currently the itests always seem to fail with cellar trunk, is that the current known state of it? Or is it failing on my side only? Thanks, Ryan
Re: Karaf RPMs - what options are out there?
TBH I'm still not against the idea of having deb/rpm for Karaf. So the
release manager would
a) run mvn release:prepare ...
b) scripts/rpmPackaging.sh
c) deploy the final artifact to a rpm repo? Or simply provide it for
download with the rest of the distribution in hope someone will pick
up the package and distribute it to their favorite repos?
Feel free to correct me, but it sounds reasonable to me. BUT the
decision need to be made by our release managers:
@Jamie: WDYT?
Kind regards,
Andreas
p.s.: yes, please create an issue with this script anyway. Would make
it ways easier to find later on.
On Tue, Jan 15, 2013 at 6:37 PM, aj...@virginia.edu aj...@virginia.edu wrote:
That's simpler than distributing an RPM to the repos, by a long ways. With
that approach, all we'd need would be the spec (build) script. I append the
example at the end of this email. As you can see, it's not very much. I'm
sure it could be better written (I'm no RPM maven {grin}) but it's a place
to start. I used the Tanuki Java wrapper as part of the dependency, because
that software is commonly available for almost any Linux distro. I also
included a separate body of source for the package (shown below as
wrapper-gear) which is just the files that Karaf creates from its wrapper:
commands. These two inclusions allow the RPM to install Karaf as a Linux
system service using the Tanuki wrapper.
Graham-- I'll send you a tarball of wrapper-gear off-list, just so you can
see what I did.
It's this worthy of opening an issue?
---
A. Soroka
Software Systems Engineering :: Online Library Environment
the University of Virginia Library
On Jan 15, 2013, at 12:26 PM, Graham Leggett wrote:
On 15 Jan 2013, at 7:09 PM, aj...@virginia.edu wrote:
I have, for local consumption. I based the build on an ActiveMQ RPM script.
It wasn't too difficult and I can send you the example, if you like.
If you can, I would hugely appreciate it.
There has been discussion before on this list about maintaining a
semi-blessed RPM of Karaf directly from the project. I'd be happy to work
on that, if I could get guidance and help integrating it into the release
process.
I maintain the spec file that is shipped with Apache httpd, the idea is that
you can download a httpd tarball and run rpmbuild -tb tarball and it
just works. All that is required is that a file called package.spec
exists in the root of the tarball. (It might also work if the spec file is
elsewhere in the tree, but I've not tried).
I am busy looking at the jpackage version of karaf, and it seems to have a
significantly different structure to that shipped by Apache. Still need to
get my head around it.
Regards,
Graham
--
[ajs6f@esbdev2 SPECS]$ cat apache-karaf.spec
# turn off Red Hat's jar repacking macro
%define __jar_repack %{nil}
#
# Spec file for packaging Apach Karaf
#
Summary: Apache Karaf
Name: apache-karaf
Version: 2.2.7
Release: 1
License: Apache
Group: Networking/Daemons
Source0:
http://www.apache.org/dyn/closer.cgi/karaf/2.2.7/apache-karaf-2.2.7.tar.gz
Source1: wrapper-gear
URL: http://karaf.apache.org/
Vendor: Apache Foundation
Packager: A. Soroka aj...@virginia.edu
BuildArch: noarch
Requires: java
Requires: tanukiwrapper
%description
Apache Karaf is a small OSGi runtime which provides a lightweight container
into which various components and applications can be deployed.
%define karaf_home /usr/share/karaf
%define karaf_data /var/cache/karaf
%define karaf_config /etc/karaf
%define karaf_deploy /var/local/karaf-deploy
%define karaf_startuplib /usr/local/lib/karaf
%define karaf_systemlib /usr/local/lib/karaf-system
%define karaf_logs /var/log/karaf
%prep
%setup
%build
# No build needed for a pure-Java application like Karaf
/bin/true
%install
# Add the karaf user and group
# the || : (or NOP) on the end allows for the condition that this user
and group already exist
/usr/sbin/groupadd --system karaf 2 /dev/null || :
/usr/sbin/useradd --comment Apache Karaf -g karaf \
--shell /bin/bash --system --home-dir %{karaf_home} karaf 2 /dev/null ||
:
# We put the various pieces of Karaf into FHS-appropriate places, then symln
them
# together in /usr/share/karaf.
# First copy all of the Karaf tree into %{karaf_home} (should be
/usr/share/karaf)
mkdir -p $RPM_BUILD_ROOT%{karaf_home}
mv --verbose * $RPM_BUILD_ROOT%{karaf_home}/
# Now we make the FHS locations for Karaf stuff
mkdir -p $RPM_BUILD_ROOT%{karaf_config} $RPM_BUILD_ROOT%{karaf_deploy}
$RPM_BUILD_ROOT%{karaf_deploy} \
$RPM_BUILD_ROOT%{karaf_startuplib} $RPM_BUILD_ROOT%{karaf_systemlib}
$RPM_BUILD_ROOT%{karaf_data} \
$RPM_BUILD_ROOT%{karaf_logs} $RPM_BUILD_ROOT/etc/init.d
# Now we move pieces of the tree out of there into FHS-appropriate spots and
re-symln them
pushd $RPM_BUILD_ROOT%{karaf_home}
mv etc/* $RPM_BUILD_ROOT%{karaf_config}
rmdir etc
ln -s %{karaf_config}
Re: Gogo vs. Karaf Commands
This kind of a change is one that I feel should be rolled into a future release of Karaf. Unless anyone has an objection, I suggest a Jira ticket (for a new feature) be created, and that a patch be submitted to that Jira ticket with Gokturk's code. IMHO, this approach is preferable to a fork of Karaf. Thoughts? On 1/15/2013 9:11 PM, Gareth [via Karaf] wrote: Hi Gokturk, I am interested in seeing this happen as well. Perhaps you can share what you did so far on github? Just make a fork of apache karaf then push your changes to your fork? thanks, Gareth If you reply to this email, your message will be added to the discussion below: http://karaf.922171.n3.nabble.com/Gogo-vs-Karaf-Commands-tp4027219p4027303.html To start a new topic under Karaf - User, email ml-node+s922171n930749...@n3.nabble.com To unsubscribe from Karaf - User, click here http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=930749code=bXZhbmdlZXJ0cnV5QGNvbWNhc3QubmV0fDkzMDc0OXwtNjA0ODc4OTY2. NAML http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml - Mike Van (All links open in new tabs) Committer - Kalumet Atraxia Technologies Mike Van's Open Source Technologies Blog -- View this message in context: http://karaf.922171.n3.nabble.com/Gogo-vs-Karaf-Commands-tp4027219p4027306.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Karaf RPMs - what options are out there?
The concept of providing an RPM/Deb release option is perfectly fine
from my POV, this would require opening issues in Jira to add these
release targets. A quick search turns up a Maven rpm plugin
(http://mojo.codehaus.org/rpm-maven-plugin/) that may be used to keep
our release process streamlined. There may be other methodologies
available that we should consider as well
(http://www.rpm.org/max-rpm-snapshot/rpmbuild.8.html).
A couple of things we'd also have to check is how we can sign these
artifacts in accordance with ASF procedures, update release process to
reflect any new steps, and test our new RPMs.
One thing I would like to do before hand however is see how other
Apache projects provide RPMs. Far as I can tell RPMs are being
provided by other groups (i.e., HTTPD and Tomcat can be found as RPMs
but the project pages do not have links for obtaining them, OpenOffice
seems to be one of the few to list these other packages
http://www.openoffice.org/download/other.html). We need to check if
there are any guidance from the ASF regarding their standards for
RPM/Deb/DMG/etc package releases.
Cheers,
Jamie
On Tue, Jan 15, 2013 at 10:54 PM, Andreas Pieber anpie...@gmail.com wrote:
TBH I'm still not against the idea of having deb/rpm for Karaf. So the
release manager would
a) run mvn release:prepare ...
b) scripts/rpmPackaging.sh
c) deploy the final artifact to a rpm repo? Or simply provide it for
download with the rest of the distribution in hope someone will pick
up the package and distribute it to their favorite repos?
Feel free to correct me, but it sounds reasonable to me. BUT the
decision need to be made by our release managers:
@Jamie: WDYT?
Kind regards,
Andreas
p.s.: yes, please create an issue with this script anyway. Would make
it ways easier to find later on.
On Tue, Jan 15, 2013 at 6:37 PM, aj...@virginia.edu aj...@virginia.edu
wrote:
That's simpler than distributing an RPM to the repos, by a long ways. With
that approach, all we'd need would be the spec (build) script. I append the
example at the end of this email. As you can see, it's not very much. I'm
sure it could be better written (I'm no RPM maven {grin}) but it's a place
to start. I used the Tanuki Java wrapper as part of the dependency, because
that software is commonly available for almost any Linux distro. I also
included a separate body of source for the package (shown below as
wrapper-gear) which is just the files that Karaf creates from its
wrapper: commands. These two inclusions allow the RPM to install Karaf as
a Linux system service using the Tanuki wrapper.
Graham-- I'll send you a tarball of wrapper-gear off-list, just so you can
see what I did.
It's this worthy of opening an issue?
---
A. Soroka
Software Systems Engineering :: Online Library Environment
the University of Virginia Library
On Jan 15, 2013, at 12:26 PM, Graham Leggett wrote:
On 15 Jan 2013, at 7:09 PM, aj...@virginia.edu wrote:
I have, for local consumption. I based the build on an ActiveMQ RPM
script. It wasn't too difficult and I can send you the example, if you
like.
If you can, I would hugely appreciate it.
There has been discussion before on this list about maintaining a
semi-blessed RPM of Karaf directly from the project. I'd be happy to
work on that, if I could get guidance and help integrating it into the
release process.
I maintain the spec file that is shipped with Apache httpd, the idea is
that you can download a httpd tarball and run rpmbuild -tb tarball and
it just works. All that is required is that a file called package.spec
exists in the root of the tarball. (It might also work if the spec file is
elsewhere in the tree, but I've not tried).
I am busy looking at the jpackage version of karaf, and it seems to have a
significantly different structure to that shipped by Apache. Still need to
get my head around it.
Regards,
Graham
--
[ajs6f@esbdev2 SPECS]$ cat apache-karaf.spec
# turn off Red Hat's jar repacking macro
%define __jar_repack %{nil}
#
# Spec file for packaging Apach Karaf
#
Summary: Apache Karaf
Name: apache-karaf
Version: 2.2.7
Release: 1
License: Apache
Group: Networking/Daemons
Source0:
http://www.apache.org/dyn/closer.cgi/karaf/2.2.7/apache-karaf-2.2.7.tar.gz
Source1: wrapper-gear
URL: http://karaf.apache.org/
Vendor: Apache Foundation
Packager: A. Soroka aj...@virginia.edu
BuildArch: noarch
Requires: java
Requires: tanukiwrapper
%description
Apache Karaf is a small OSGi runtime which provides a lightweight container
into which various components and applications can be deployed.
%define karaf_home /usr/share/karaf
%define karaf_data /var/cache/karaf
%define karaf_config /etc/karaf
%define karaf_deploy /var/local/karaf-deploy
%define karaf_startuplib /usr/local/lib/karaf
%define karaf_systemlib /usr/local/lib/karaf-system
%define karaf_logs /var/log/karaf
%prep
%setup
%build
# No build
