You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Göktürk Gezer <go...@gmail.com> on 2011/10/19 05:21:11 UTC
Instantiating Manipulated Class without IPojo
Hi Everyone,
We're in the middle of moving our codebase to OSGI using IPojo. Problem is,
I can not instantiate the manipulated classes without IPojo.
AFAIK, IPojo manipulates the constructors with no argument and BundleContext
argument. So we can use other constructors for instance creation without
getting through IPojo, and all field and method delegations will be disabled
in that case. Am i wrong?
IPojoized classes are subclasses of some generic type, and i just use
@Component and @Provides on them. That's all, just for easy service
publication. But after that i can not instantiate them using _ctor(String)
constructor.
If you ask why you're using normal instantiation, these usages without IPojo
are just on unit tests. Eventually we'll move these tests to OSGI, but it
would be cool to be able to still use them until we do.
Regards,
Gokturk
Re: Instantiating Manipulated Class without IPojo
Posted by Göktürk Gezer <go...@gmail.com>.
Hi,
I forgot to mention why i couldn't instantiate. Maven says,
"cannot access org.apache.felix.ipojo.InstanceManager
[ERROR] class file for org.apache.felix.ipojo.InstanceManager not found."
at the point where i try to instantiate through constructor.
Regards,
Gokturk
Re: Instantiating Manipulated Class without IPojo
Posted by Göktürk Gezer <go...@gmail.com>.
Hi Clement,
On Wed, Oct 19, 2011 at 5:06 PM, Clement Escoffier <
clement.escoffier@gmail.com> wrote:
> Hi,
>
> On 19.10.2011, at 05:21, Göktürk Gezer wrote:
>
> > Hi Everyone,
> >
> > We're in the middle of moving our codebase to OSGI using IPojo. Problem
> is,
> > I can not instantiate the manipulated classes without IPojo.
> >
> > AFAIK, IPojo manipulates the constructors with no argument and
> BundleContext
> > argument. So we can use other constructors for instance creation without
> > getting through IPojo, and all field and method delegations will be
> disabled
> > in that case. Am i wrong?
>
> You're mostly right. iPOJO 'replaces' all constructors (since the 1.8.0
> because of the constructor injection support). However, original
> constructors are still existing, and accessible.
>
Yes, much more like it.
>
> So, if you have a class with:
> public class Foo {
>
> public String m_foo;
>
> public ConstructorCheck(String foo) {
> m_foo = foo;
> }
>
> }
>
> You will get:
> public ConstructorCheck(String s)
> {
> this(null, s);
> }
>
> private ConstructorCheck(InstanceManager _manager, String foo)
> {
> _setInstanceManager(_manager);
> __setm_foo(foo);
> }
>
> It means that you need to have iPOJO in your class path, but the semantic
> is not changed.
> (For information, __setm_foo(foo); will just do m_foo = foo; )
>
I have almost the same semantic, except generics involved.
>
> >
> > IPojoized classes are subclasses of some generic type, and i just use
> > @Component and @Provides on them. That's all, just for easy service
> > publication. But after that i can not instantiate them using
> _ctor(String)
> > constructor.
>
> Inheritance (using annotations on parent classes) is not yet supported.
> This is on the roadmap of iPOJO 2.0.
>
I'm not using it. But maybe i over modified files. Its about 30 classes, so
maybe i wrongly modified some parent. I'll look into that.
>
> >
> > If you ask why you're using normal instantiation, these usages without
> IPojo
> > are just on unit tests. Eventually we'll move these tests to OSGI, but it
> > would be cool to be able to still use them until we do.
> >
>
> I'm doing the same. So, avoid the inheritance, and it should work.
>
I'll go through it again with caution. Thanks.
>
> Regards,
>
> Clement
>
> >
> > Regards,
> > Gokturk
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
Re: Instantiating Manipulated Class without IPojo
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
On 19.10.2011, at 05:21, Göktürk Gezer wrote:
> Hi Everyone,
>
> We're in the middle of moving our codebase to OSGI using IPojo. Problem is,
> I can not instantiate the manipulated classes without IPojo.
>
> AFAIK, IPojo manipulates the constructors with no argument and BundleContext
> argument. So we can use other constructors for instance creation without
> getting through IPojo, and all field and method delegations will be disabled
> in that case. Am i wrong?
You're mostly right. iPOJO 'replaces' all constructors (since the 1.8.0 because of the constructor injection support). However, original constructors are still existing, and accessible.
So, if you have a class with:
public class Foo {
public String m_foo;
public ConstructorCheck(String foo) {
m_foo = foo;
}
}
You will get:
public ConstructorCheck(String s)
{
this(null, s);
}
private ConstructorCheck(InstanceManager _manager, String foo)
{
_setInstanceManager(_manager);
__setm_foo(foo);
}
It means that you need to have iPOJO in your class path, but the semantic is not changed.
(For information, __setm_foo(foo); will just do m_foo = foo; )
>
> IPojoized classes are subclasses of some generic type, and i just use
> @Component and @Provides on them. That's all, just for easy service
> publication. But after that i can not instantiate them using _ctor(String)
> constructor.
Inheritance (using annotations on parent classes) is not yet supported. This is on the roadmap of iPOJO 2.0.
>
> If you ask why you're using normal instantiation, these usages without IPojo
> are just on unit tests. Eventually we'll move these tests to OSGI, but it
> would be cool to be able to still use them until we do.
>
I'm doing the same. So, avoid the inheritance, and it should work.
Regards,
Clement
>
> Regards,
> Gokturk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Instantiating Manipulated Class without IPojo
Posted by Göktürk Gezer <go...@gmail.com>.
On Wed, Oct 19, 2011 at 11:02 AM, Karl Pauls <ka...@gmail.com> wrote:
> Can you show your maven pom maybe?
>
> regards,
>
> Karl
>
> This pom belongs to project which exposes some of its classes using
@Component@Provides
..................................
......................................
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
</dependency>
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.ipojo.annotations</artifactId>
<version>1.8.0</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>generate-sources</phase>
<configuration />
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>antlr-maven-plugin</artifactId>
<configuration>
<grammars>*.g</grammars>
</configuration>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<excludes>
<exclude>**/Abstract*</exclude>
<exclude>**/*RegressionTest*</exclude>
</excludes>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestFile>META-INF/MANIFEST.MF</manifestFile>
<addMavenDescriptor>false</addMavenDescriptor>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<inherited>true</inherited>
<extensions>true</extensions>
<configuration>
<manifestLocation>META-INF</manifestLocation>
<instructions>
<Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName>
<Export-Package>
{local-packages};version=${project.version};-noimport:=true
</Export-Package>
</instructions>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-ipojo-plugin</artifactId>
<version>1.8.0</version>
<executions>
<execution>
<goals>
<goal>ipojo-bundle</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
And that one belongs to a one that tries to instantiate normally
..........................
.........................................
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.ipojo</artifactId>
<version>1.8.0</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>attach-tests</id>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<inherited>true</inherited>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName>
<Export-Package>
{local-packages};version=${project.version};-noimport:=true,
org.apache.directory.server.core.partition.impl.avl;version="${project.version}";-noimport:=true,
org.apache.directory.server.core.partition.impl.btree;version="${project.version}";-noimport:=true,
org.apache.directory.server.log.impl.avl;version="${project.version}";-noimport:=true,
org.apache.directory.server.xdbm.impl.avl;version="${project.version}";-noimport:=true,
org.apache.directory.server.xdbm.search.impl;version="${project.version}";-noimport:=true
</Export-Package>
</instructions>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-ipojo-plugin</artifactId>
<version>1.8.0</version>
<executions>
<execution>
<goals>
<goal>ipojo-bundle</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
to give some example, We have LdapComparator<?> base type
@Component
@Provides
BinaryComparator extends LdapComparator<String>
In class that's under second pom,
we have something like
LdapComparator<?> comparator = new BinaryComparator( "1.0.4.3" ); //This is
where the error is given.
That BinaryComparator's _ctor(String) is calling base constructor and that
chain goes all the way to top base class without calling parameterless
constructor at any level.
Regards,
Gokturk
Re: Instantiating Manipulated Class without IPojo
Posted by Karl Pauls <ka...@gmail.com>.
Can you show your maven pom maybe?
regards,
Karl
On Wed, Oct 19, 2011 at 9:24 AM, Göktürk Gezer <go...@gmail.com> wrote:
> Hi Karl,
>
> On Wed, Oct 19, 2011 at 9:38 AM, Karl Pauls <ka...@gmail.com> wrote:
>
>> iirc, all you need to do is to have iPOJO on the classpath.
>>
> That was the first thing i tried, but unfortunately it didn't save me .
>
>>
>> regards,
>>
>> Karl
>>
>> On Wed, Oct 19, 2011 at 5:21 AM, Göktürk Gezer <go...@gmail.com>
>> wrote:
>> > Hi Everyone,
>> >
>> > We're in the middle of moving our codebase to OSGI using IPojo. Problem
>> is,
>> > I can not instantiate the manipulated classes without IPojo.
>> >
>> > AFAIK, IPojo manipulates the constructors with no argument and
>> BundleContext
>> > argument. So we can use other constructors for instance creation without
>> > getting through IPojo, and all field and method delegations will be
>> disabled
>> > in that case. Am i wrong?
>> >
>> > IPojoized classes are subclasses of some generic type, and i just use
>> > @Component and @Provides on them. That's all, just for easy service
>> > publication. But after that i can not instantiate them using
>> _ctor(String)
>> > constructor.
>> >
>> > If you ask why you're using normal instantiation, these usages without
>> IPojo
>> > are just on unit tests. Eventually we'll move these tests to OSGI, but it
>> > would be cool to be able to still use them until we do.
>> >
>> >
>> > Regards,
>> > Gokturk
>> >
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>> http://twitter.com/karlpauls
>> http://www.linkedin.com/in/karlpauls
>> https://profiles.google.com/karlpauls
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
--
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Instantiating Manipulated Class without IPojo
Posted by Göktürk Gezer <go...@gmail.com>.
Hi Karl,
On Wed, Oct 19, 2011 at 9:38 AM, Karl Pauls <ka...@gmail.com> wrote:
> iirc, all you need to do is to have iPOJO on the classpath.
>
That was the first thing i tried, but unfortunately it didn't save me .
>
> regards,
>
> Karl
>
> On Wed, Oct 19, 2011 at 5:21 AM, Göktürk Gezer <go...@gmail.com>
> wrote:
> > Hi Everyone,
> >
> > We're in the middle of moving our codebase to OSGI using IPojo. Problem
> is,
> > I can not instantiate the manipulated classes without IPojo.
> >
> > AFAIK, IPojo manipulates the constructors with no argument and
> BundleContext
> > argument. So we can use other constructors for instance creation without
> > getting through IPojo, and all field and method delegations will be
> disabled
> > in that case. Am i wrong?
> >
> > IPojoized classes are subclasses of some generic type, and i just use
> > @Component and @Provides on them. That's all, just for easy service
> > publication. But after that i can not instantiate them using
> _ctor(String)
> > constructor.
> >
> > If you ask why you're using normal instantiation, these usages without
> IPojo
> > are just on unit tests. Eventually we'll move these tests to OSGI, but it
> > would be cool to be able to still use them until we do.
> >
> >
> > Regards,
> > Gokturk
> >
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
RE : RE : Scripting felix
Posted by DEBROUX Lionel <Li...@atos.net>.
Hi again,
> Thanks for the example given, you are right, we are using Maven. I am
> currently adding base depencies by using copy-dependencies as you
> describe. But I am not using some of the additional maven niceties
> you are demonstrating, so thanks for the pointers.
You're welcome.
> What I like about the gogo-deployment method is that dependency
> resolution for obr:deploy happens on the basis of manifest.mf, so
> for our project bundles I can test this functionality directly as part
> of the integration build.
OK.
> I realize I could deploy the felix output of the maven method during
> the build in order to test manifest issues, but I must admit I am a
> little worried about runtime dependency issues and/or adding too much
> to our felix build with maven as dependency resolver... I note you
> are setting excludeTransitive to true in copy-dependencies of the
> example below :)
I guess that having excludeTransitive to true, in the POM I extracted
and simplified for posting here, was just a way to force explicit
specification of dependencies in the POM, so that no new dependency
can slip in without anybody noticing.
> -> Is there no way to have gogo persist its deployments, as it does
> when I deploy bundles interactively?
>
> -> Would you advise against using this approach for other reasons?
I don't know, let's wait for answers from other persons :)
Regards,
Lionel.
________________________________
Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
Re: RE : Scripting felix
Posted by Sam Spycher <sa...@spycher.info>.
Hi Lionel & felix users,
Thanks for the example given, you are right, we are using Maven. I am
currently adding base depencies by using copy-dependencies as you
describe. But I am not using some of the additional maven niceties you
are demonstrating, so thanks for the pointers.
What I like about the gogo-deployment method is that dependency
resolution for obr:deploy happens on the basis of manifest.mf, so for
our project bundles I can test this functionality directly as part of
the integration build.
I realize I could deploy the felix output of the maven method during the
build in order to test manifest issues, but I must admit I am a little
worried about runtime dependency issues and/or adding too much to our
felix build with maven as dependency resolver... I note you are setting
excludeTransitive to true in copy-dependencies of the example below :)
-> Is there no way to have gogo persist its deployments, as it does when
I deploy bundles interactively?
-> Would you advise against using this approach for other reasons?
Thanks again for any input,
Sam
Am 19.10.11 09:42, schrieb DEBROUX Lionel:
> Hello,
>
>> I am currently writing a small shell script which is supposed to run
>> felix, install the necessary bundles with gogo, then quit and package
>> felix for deployment on our integration servers.
>>
>> [snip]
> If you are using Maven, and your bundles are deployed in Maven
> repositories (besides being deployed in OBR repositories), you can
> add bundles to a Felix installation without running Felix.
>
> The two following sample files add a File Install 3.1.10 bundle to a
> Felix 4.0.1 framework, then re-package the result as a gzipped tarball:
>
> pom.xml:
> "
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
> <modelVersion>4.0.0</modelVersion>
> <packaging>pom</packaging>
> <name>NAME</name>
> <description>DESCRIPTION</description>
> <groupId>GROUP</groupId>
> <artifactId>ARTIFACT</artifactId>
> <version>VERSION</version>
>
> <properties>
> <felix.version>4.0.1</felix.version>
> <felix.dir>${project.build.directory}/felix-framework-${felix.version}</felix.dir>
> <fileinstall.version>3.1.10</fileinstall.version>
> </properties>
>
> <dependencies>
> <dependency>
> <groupId>org.apache.felix</groupId>
> <artifactId>org.apache.felix.fileinstall</artifactId>
> <version>${fileinstall.version}</version>
> </dependency>
>
> <!-- Add more dependencies here if you want -->
> </dependencies>
>
> <build>
> <plugins>
> <!-- 1. Unpack Felix distribution to target/${felix.dir} and install dependencies in bundle -->
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-dependency-plugin</artifactId>
> <executions>
> <execution>
> <id>unpack-felix</id>
> <phase>generate-resources</phase>
> <goals>
> <goal>unpack</goal>
> </goals>
> <configuration>
> <outputDirectory>${project.build.directory}</outputDirectory>
> <excludeTransitive>true</excludeTransitive>
> <overWrite>true</overWrite>
> <artifactItems>
> <artifactItem>
> <groupId>org.apache.felix</groupId>
> <artifactId>org.apache.felix.main.distribution</artifactId>
> <version>${felix.version}</version>
> <type>tar.gz</type>
> </artifactItem>
> </artifactItems>
> </configuration>
> </execution>
>
> <execution>
> <id>fill-out-bundle</id>
> <phase>process-resources</phase>
> <goals>
> <goal>copy-dependencies</goal>
> </goals>
> <configuration>
> <outputDirectory>${felix.dir}/bundle</outputDirectory>
> <useRepositoryLayout>false</useRepositoryLayout>
> <excludeTransitive>true</excludeTransitive>
> <overWrite>true</overWrite>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
> <!-- 2. Create an assembly package of the modified Felix distribution -->
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-assembly-plugin</artifactId>
> <executions>
> <execution>
> <id>make-assembly</id>
> <phase>package</phase>
> <goals>
> <goal>single</goal>
> </goals>
> <configuration>
> <archiveBaseDirectory>${felix.dir}</archiveBaseDirectory>
> <tarLongFileMode>gnu</tarLongFileMode>
> <descriptors>
> <descriptor>assembly.xml</descriptor>
> </descriptors>
> </configuration>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
> </project>
> "
>
> assembly.xml:
> "
> <?xml version="1.0" encoding="UTF-8"?>
> <assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
> http://maven.apache.org/xsd/assembly-1.1.0.xsd">
> <formats>
> <format>tar.gz</format>
> </formats>
> <fileSets>
> <fileSet>
> <directory>.</directory>
> </fileSet>
> </fileSets>
> </assembly>
> "
>
>
> Regards,
> Lionel.
> ________________________________
>
>
> Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis.
>
> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE : Scripting felix
Posted by DEBROUX Lionel <Li...@atos.net>.
Hello,
> I am currently writing a small shell script which is supposed to run
> felix, install the necessary bundles with gogo, then quit and package
> felix for deployment on our integration servers.
>
> [snip]
If you are using Maven, and your bundles are deployed in Maven
repositories (besides being deployed in OBR repositories), you can
add bundles to a Felix installation without running Felix.
The two following sample files add a File Install 3.1.10 bundle to a
Felix 4.0.1 framework, then re-package the result as a gzipped tarball:
pom.xml:
"
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<packaging>pom</packaging>
<name>NAME</name>
<description>DESCRIPTION</description>
<groupId>GROUP</groupId>
<artifactId>ARTIFACT</artifactId>
<version>VERSION</version>
<properties>
<felix.version>4.0.1</felix.version>
<felix.dir>${project.build.directory}/felix-framework-${felix.version}</felix.dir>
<fileinstall.version>3.1.10</fileinstall.version>
</properties>
<dependencies>
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.fileinstall</artifactId>
<version>${fileinstall.version}</version>
</dependency>
<!-- Add more dependencies here if you want -->
</dependencies>
<build>
<plugins>
<!-- 1. Unpack Felix distribution to target/${felix.dir} and install dependencies in bundle -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack-felix</id>
<phase>generate-resources</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}</outputDirectory>
<excludeTransitive>true</excludeTransitive>
<overWrite>true</overWrite>
<artifactItems>
<artifactItem>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.main.distribution</artifactId>
<version>${felix.version}</version>
<type>tar.gz</type>
</artifactItem>
</artifactItems>
</configuration>
</execution>
<execution>
<id>fill-out-bundle</id>
<phase>process-resources</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${felix.dir}/bundle</outputDirectory>
<useRepositoryLayout>false</useRepositoryLayout>
<excludeTransitive>true</excludeTransitive>
<overWrite>true</overWrite>
</configuration>
</execution>
</executions>
</plugin>
<!-- 2. Create an assembly package of the modified Felix distribution -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<archiveBaseDirectory>${felix.dir}</archiveBaseDirectory>
<tarLongFileMode>gnu</tarLongFileMode>
<descriptors>
<descriptor>assembly.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
"
assembly.xml:
"
<?xml version="1.0" encoding="UTF-8"?>
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd">
<formats>
<format>tar.gz</format>
</formats>
<fileSets>
<fileSet>
<directory>.</directory>
</fileSet>
</fileSets>
</assembly>
"
Regards,
Lionel.
________________________________
Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
Re: Scripting felix
Posted by Sam Spycher <sa...@spycher.info>.
Hi Karl
It is true that I haven't done anything cache-wise at all! Do I need to
configure this in some special way?
The cache location is at default. In fact, I haven't changed anything at
all in config.properties. The working directory of the script is the
felix root directory.
Best regards,
Sam
Am 19.10.11 17:30, schrieb Karl Pauls:
> On Wed, Oct 19, 2011 at 5:23 PM, Richard S. Hall <he...@ungoverned.org> wrote:
>> On 10/19/11 03:24 , Sam Spycher wrote:
>>>
>>> Hi
>>>
>>> I am currently writing a small shell script which is supposed to run
>>> felix, install the necessary bundles with gogo, then quit and package
>>> felix for deployment on our integration servers.
>>>
>>> Unfortunately, felix seems to undeploy the deployed bundles when
>>> shutting down. If I do this manually, felix retains the bundles across
>>> shutdowns and startups.
>>
>> I'm not sure what you mean, nor what you are doing exactly, but the Felix
>> framework always retains bundles across shutdowns and restarts. The
>> framework will never undeploy a bundle unless someone tells it to do so.
>
> Maybe you didn't include the cache?
>
> regards,
>
> Karl
>
>> -> richard
>>
>>>
>>> The only difference I can find is on how I exit Felix. From the script,
>>> felix exits "normally", and when configuring interactively I exit with
>>> Ctrl-C.
>>>
>>> -> so my question is: how can I persuade Felix to keep the installed
>>> bundles (and keep their active state) across shutdowns and startups?
>>>
>>> -> would the proper way to do this be over config.properties?
>>>
>>> -> if yes, and if this means that deployment of bundles happens on every
>>> startup, then how do I work around the issue of potentially not having
>>> access to a repo on the server that felix is to be installed?
>>>
>>>
>>> Here is the part of the script which uses gogo:
>>>
>>> #!/bin/bash
>>> # ...
>>> # GOGO deployment script
>>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>> obr:deploy -s "Bundle A"
>>> obr:deploy -s "Bundle B"
>>> obr:deploy -s "Bundle C"
>>> # etc.
>>> felix:refresh
>>> felix:lb
>>> END_GOGO_SCRIPT
>>> # ...
>>> # run felix and GOGO script
>>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>>> gosh --nointeractive --login -x $GOGO_SCRIPT
>>> END_GOGO_SCRIPT_STARTUP
>>>
>>>
>>> Thanks for any help,
>>> Sam
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by Karl Pauls <ka...@gmail.com>.
On Wed, Oct 19, 2011 at 5:23 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> On 10/19/11 03:24 , Sam Spycher wrote:
>>
>> Hi
>>
>> I am currently writing a small shell script which is supposed to run
>> felix, install the necessary bundles with gogo, then quit and package
>> felix for deployment on our integration servers.
>>
>> Unfortunately, felix seems to undeploy the deployed bundles when
>> shutting down. If I do this manually, felix retains the bundles across
>> shutdowns and startups.
>
> I'm not sure what you mean, nor what you are doing exactly, but the Felix
> framework always retains bundles across shutdowns and restarts. The
> framework will never undeploy a bundle unless someone tells it to do so.
Maybe you didn't include the cache?
regards,
Karl
> -> richard
>
>>
>> The only difference I can find is on how I exit Felix. From the script,
>> felix exits "normally", and when configuring interactively I exit with
>> Ctrl-C.
>>
>> -> so my question is: how can I persuade Felix to keep the installed
>> bundles (and keep their active state) across shutdowns and startups?
>>
>> -> would the proper way to do this be over config.properties?
>>
>> -> if yes, and if this means that deployment of bundles happens on every
>> startup, then how do I work around the issue of potentially not having
>> access to a repo on the server that felix is to be installed?
>>
>>
>> Here is the part of the script which uses gogo:
>>
>> #!/bin/bash
>> # ...
>> # GOGO deployment script
>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>> obr:repos add file:$HOME/.m2/repository/repository.xml
>> obr:deploy -s "Bundle A"
>> obr:deploy -s "Bundle B"
>> obr:deploy -s "Bundle C"
>> # etc.
>> felix:refresh
>> felix:lb
>> END_GOGO_SCRIPT
>> # ...
>> # run felix and GOGO script
>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>> gosh --nointeractive --login -x $GOGO_SCRIPT
>> END_GOGO_SCRIPT_STARTUP
>>
>>
>> Thanks for any help,
>> Sam
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/19/11 13:38 , Sam Spycher wrote:
> Hi everybody
>
> I'm sorry, this has really been much ado about something very small :(
>
> My mistake was a typo. I oversaw a small dash right in front of the
> heredoc marker in the script:
>
> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
Makes sense, you renamed the cache on the command line. :-)
-> richard
>
> Thanks to Richard and Karl for bringing up the felix-cache, the weird
> naming there pointed me in the right direction.
>
> Best regards,
> Sam
>
> Am 19.10.11 18:36, schrieb Richard S. Hall:
>> On 10/19/11 12:09 , Sam Spycher wrote:
>>> Hmm, that is interesting.
>>>
>>> When I deploy felix via script, I can observe the creation of a
>>> directory called '-' in the working directory while the script is
>>> executing.
>>>
>>> Looking at the contents of '-', I find bundleX subdirectories just as is
>>> to be expected from the felix cache. Indeed if i cat the bundle.info
>>> of the bundle with the highest number I can see this corresponds to a
>>> bundle that I installed with gogo.
>>>
>>> However, when I run Felix interactively from the shell after having run
>>> the script, it creates a new cache directory with the proper default
>>> name 'felix-cache'. Of course this directory now contains no traces of
>>> what was installed with gogo, it only has the bundles which were copied
>>> into the bundle/ subdirectory.
>>>
>>> -> Some issue with the cache directory name when running felix
>>> non-interactively?
>>>
>>> Note that I'm running 4.0.1 directly off maven, with no modifications to
>>> config.properties.
>> Not sure if the way you are launching it somehow overrides the default
>> cache value or not, but if you want to see what is going on, perhaps you
>> can try to debug it and set a break point at:
>>
>> org.apache.felix.framework.cache.BundleCache.determineCacheDir()
>>
>> This calculates the cache directory based on the default config and/or
>> any specified configuration.
>>
>> -> richard
>>
>>> Thanks& Best regards,
>>> Sam
>>>
>>> Am 19.10.11 17:44, schrieb Richard S. Hall:
>>>> On 10/19/11 11:39 , Sam Spycher wrote:
>>>>> Hi Richard,
>>>>>
>>>>> I am running a bash script which sends some gogo deployment commands to
>>>>> install some bundles in felix. I then list the bundles I just deployed
>>>>> with gogo with the command 'lb'. These bundles are all correctly
>>>>> displayed and have their state set to active. At the end of the script
>>>>> Felix then terminates (I assume because it is called non-interactively
>>>>> via a script).
>>>>>
>>>>> Now if I startup this exact same deployment and list the installed
>>>>> bundles via 'lb', all I get is the bundles I previously copied into the
>>>>> bunde/ subdirectory. The bundles I installed via gogo have disappeared,
>>>>> although I never undeployed them.
>>>>>
>>>>> What am I missing?
>>>> Well, the framework installs bundles into a cache, which is by default
>>>> in the current directory called felix-cache. Do you see this directory
>>>> get created? Is it still there after shutdown? What happens to it after
>>>> startup?
>>>>
>>>> -> richard
>>>>
>>>>> Here is a minimal version of my deployment script:
>>>>>
>>>>> #!/bin/bash
>>>>> java -verbose -jar bin/felix.jar<<-END_GOGO_SCRIPT_STARTUP
>>>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>>>> obr:deploy -s "Some bundle from maven repo"
>>>>> felix:refresh
>>>>> felix:lb
>>>>> END_GOGO_SCRIPT_STARTUP
>>>>>
>>>>> Best regards,
>>>>> Sam
>>>>>
>>>>> Am 19.10.11 17:23, schrieb Richard S. Hall:
>>>>>> On 10/19/11 03:24 , Sam Spycher wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> I am currently writing a small shell script which is supposed to run
>>>>>>> felix, install the necessary bundles with gogo, then quit and package
>>>>>>> felix for deployment on our integration servers.
>>>>>>>
>>>>>>> Unfortunately, felix seems to undeploy the deployed bundles when
>>>>>>> shutting down. If I do this manually, felix retains the bundles
>>>>>>> across
>>>>>>> shutdowns and startups.
>>>>>> I'm not sure what you mean, nor what you are doing exactly, but the
>>>>>> Felix framework always retains bundles across shutdowns and restarts.
>>>>>> The framework will never undeploy a bundle unless someone tells it
>>>>>> to do
>>>>>> so.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>> The only difference I can find is on how I exit Felix. From the
>>>>>>> script,
>>>>>>> felix exits "normally", and when configuring interactively I exit
>>>>>>> with
>>>>>>> Ctrl-C.
>>>>>>>
>>>>>>> -> so my question is: how can I persuade Felix to keep the
>>>>>>> installed
>>>>>>> bundles (and keep their active state) across shutdowns and startups?
>>>>>>>
>>>>>>> -> would the proper way to do this be over config.properties?
>>>>>>>
>>>>>>> -> if yes, and if this means that deployment of bundles happens on
>>>>>>> every
>>>>>>> startup, then how do I work around the issue of potentially not
>>>>>>> having
>>>>>>> access to a repo on the server that felix is to be installed?
>>>>>>>
>>>>>>>
>>>>>>> Here is the part of the script which uses gogo:
>>>>>>>
>>>>>>> #!/bin/bash
>>>>>>> # ...
>>>>>>> # GOGO deployment script
>>>>>>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>>>>>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>>>>>> obr:deploy -s "Bundle A"
>>>>>>> obr:deploy -s "Bundle B"
>>>>>>> obr:deploy -s "Bundle C"
>>>>>>> # etc.
>>>>>>> felix:refresh
>>>>>>> felix:lb
>>>>>>> END_GOGO_SCRIPT
>>>>>>> # ...
>>>>>>> # run felix and GOGO script
>>>>>>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>>>>>>> gosh --nointeractive --login -x $GOGO_SCRIPT
>>>>>>> END_GOGO_SCRIPT_STARTUP
>>>>>>>
>>>>>>>
>>>>>>> Thanks for any help,
>>>>>>> Sam
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by Sam Spycher <sa...@spycher.info>.
Hi everybody
I'm sorry, this has really been much ado about something very small :(
My mistake was a typo. I oversaw a small dash right in front of the
heredoc marker in the script:
java -verbose -jar bin/felix.jar - <<-END_GOGO_SCRIPT_STARTUP
Thanks to Richard and Karl for bringing up the felix-cache, the weird
naming there pointed me in the right direction.
Best regards,
Sam
Am 19.10.11 18:36, schrieb Richard S. Hall:
> On 10/19/11 12:09 , Sam Spycher wrote:
>> Hmm, that is interesting.
>>
>> When I deploy felix via script, I can observe the creation of a
>> directory called '-' in the working directory while the script is
>> executing.
>>
>> Looking at the contents of '-', I find bundleX subdirectories just as is
>> to be expected from the felix cache. Indeed if i cat the bundle.info
>> of the bundle with the highest number I can see this corresponds to a
>> bundle that I installed with gogo.
>>
>> However, when I run Felix interactively from the shell after having run
>> the script, it creates a new cache directory with the proper default
>> name 'felix-cache'. Of course this directory now contains no traces of
>> what was installed with gogo, it only has the bundles which were copied
>> into the bundle/ subdirectory.
>>
>> -> Some issue with the cache directory name when running felix
>> non-interactively?
>>
>> Note that I'm running 4.0.1 directly off maven, with no modifications to
>> config.properties.
>
> Not sure if the way you are launching it somehow overrides the default
> cache value or not, but if you want to see what is going on, perhaps you
> can try to debug it and set a break point at:
>
> org.apache.felix.framework.cache.BundleCache.determineCacheDir()
>
> This calculates the cache directory based on the default config and/or
> any specified configuration.
>
> -> richard
>
>>
>> Thanks& Best regards,
>> Sam
>>
>> Am 19.10.11 17:44, schrieb Richard S. Hall:
>>> On 10/19/11 11:39 , Sam Spycher wrote:
>>>> Hi Richard,
>>>>
>>>> I am running a bash script which sends some gogo deployment commands to
>>>> install some bundles in felix. I then list the bundles I just deployed
>>>> with gogo with the command 'lb'. These bundles are all correctly
>>>> displayed and have their state set to active. At the end of the script
>>>> Felix then terminates (I assume because it is called non-interactively
>>>> via a script).
>>>>
>>>> Now if I startup this exact same deployment and list the installed
>>>> bundles via 'lb', all I get is the bundles I previously copied into the
>>>> bunde/ subdirectory. The bundles I installed via gogo have disappeared,
>>>> although I never undeployed them.
>>>>
>>>> What am I missing?
>>> Well, the framework installs bundles into a cache, which is by default
>>> in the current directory called felix-cache. Do you see this directory
>>> get created? Is it still there after shutdown? What happens to it after
>>> startup?
>>>
>>> -> richard
>>>
>>>>
>>>> Here is a minimal version of my deployment script:
>>>>
>>>> #!/bin/bash
>>>> java -verbose -jar bin/felix.jar<<-END_GOGO_SCRIPT_STARTUP
>>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>>> obr:deploy -s "Some bundle from maven repo"
>>>> felix:refresh
>>>> felix:lb
>>>> END_GOGO_SCRIPT_STARTUP
>>>>
>>>> Best regards,
>>>> Sam
>>>>
>>>> Am 19.10.11 17:23, schrieb Richard S. Hall:
>>>>> On 10/19/11 03:24 , Sam Spycher wrote:
>>>>>> Hi
>>>>>>
>>>>>> I am currently writing a small shell script which is supposed to run
>>>>>> felix, install the necessary bundles with gogo, then quit and package
>>>>>> felix for deployment on our integration servers.
>>>>>>
>>>>>> Unfortunately, felix seems to undeploy the deployed bundles when
>>>>>> shutting down. If I do this manually, felix retains the bundles
>>>>>> across
>>>>>> shutdowns and startups.
>>>>> I'm not sure what you mean, nor what you are doing exactly, but the
>>>>> Felix framework always retains bundles across shutdowns and restarts.
>>>>> The framework will never undeploy a bundle unless someone tells it
>>>>> to do
>>>>> so.
>>>>>
>>>>> -> richard
>>>>>
>>>>>> The only difference I can find is on how I exit Felix. From the
>>>>>> script,
>>>>>> felix exits "normally", and when configuring interactively I exit
>>>>>> with
>>>>>> Ctrl-C.
>>>>>>
>>>>>> -> so my question is: how can I persuade Felix to keep the
>>>>>> installed
>>>>>> bundles (and keep their active state) across shutdowns and startups?
>>>>>>
>>>>>> -> would the proper way to do this be over config.properties?
>>>>>>
>>>>>> -> if yes, and if this means that deployment of bundles happens on
>>>>>> every
>>>>>> startup, then how do I work around the issue of potentially not
>>>>>> having
>>>>>> access to a repo on the server that felix is to be installed?
>>>>>>
>>>>>>
>>>>>> Here is the part of the script which uses gogo:
>>>>>>
>>>>>> #!/bin/bash
>>>>>> # ...
>>>>>> # GOGO deployment script
>>>>>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>>>>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>>>>> obr:deploy -s "Bundle A"
>>>>>> obr:deploy -s "Bundle B"
>>>>>> obr:deploy -s "Bundle C"
>>>>>> # etc.
>>>>>> felix:refresh
>>>>>> felix:lb
>>>>>> END_GOGO_SCRIPT
>>>>>> # ...
>>>>>> # run felix and GOGO script
>>>>>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>>>>>> gosh --nointeractive --login -x $GOGO_SCRIPT
>>>>>> END_GOGO_SCRIPT_STARTUP
>>>>>>
>>>>>>
>>>>>> Thanks for any help,
>>>>>> Sam
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/19/11 12:09 , Sam Spycher wrote:
> Hmm, that is interesting.
>
> When I deploy felix via script, I can observe the creation of a
> directory called '-' in the working directory while the script is executing.
>
> Looking at the contents of '-', I find bundleX subdirectories just as is
> to be expected from the felix cache. Indeed if i cat the bundle.info
> of the bundle with the highest number I can see this corresponds to a
> bundle that I installed with gogo.
>
> However, when I run Felix interactively from the shell after having run
> the script, it creates a new cache directory with the proper default
> name 'felix-cache'. Of course this directory now contains no traces of
> what was installed with gogo, it only has the bundles which were copied
> into the bundle/ subdirectory.
>
> -> Some issue with the cache directory name when running felix
> non-interactively?
>
> Note that I'm running 4.0.1 directly off maven, with no modifications to
> config.properties.
Not sure if the way you are launching it somehow overrides the default
cache value or not, but if you want to see what is going on, perhaps you
can try to debug it and set a break point at:
org.apache.felix.framework.cache.BundleCache.determineCacheDir()
This calculates the cache directory based on the default config and/or
any specified configuration.
-> richard
>
> Thanks& Best regards,
> Sam
>
> Am 19.10.11 17:44, schrieb Richard S. Hall:
>> On 10/19/11 11:39 , Sam Spycher wrote:
>>> Hi Richard,
>>>
>>> I am running a bash script which sends some gogo deployment commands to
>>> install some bundles in felix. I then list the bundles I just deployed
>>> with gogo with the command 'lb'. These bundles are all correctly
>>> displayed and have their state set to active. At the end of the script
>>> Felix then terminates (I assume because it is called non-interactively
>>> via a script).
>>>
>>> Now if I startup this exact same deployment and list the installed
>>> bundles via 'lb', all I get is the bundles I previously copied into the
>>> bunde/ subdirectory. The bundles I installed via gogo have disappeared,
>>> although I never undeployed them.
>>>
>>> What am I missing?
>> Well, the framework installs bundles into a cache, which is by default
>> in the current directory called felix-cache. Do you see this directory
>> get created? Is it still there after shutdown? What happens to it after
>> startup?
>>
>> -> richard
>>
>>>
>>> Here is a minimal version of my deployment script:
>>>
>>> #!/bin/bash
>>> java -verbose -jar bin/felix.jar<<-END_GOGO_SCRIPT_STARTUP
>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>> obr:deploy -s "Some bundle from maven repo"
>>> felix:refresh
>>> felix:lb
>>> END_GOGO_SCRIPT_STARTUP
>>>
>>> Best regards,
>>> Sam
>>>
>>> Am 19.10.11 17:23, schrieb Richard S. Hall:
>>>> On 10/19/11 03:24 , Sam Spycher wrote:
>>>>> Hi
>>>>>
>>>>> I am currently writing a small shell script which is supposed to run
>>>>> felix, install the necessary bundles with gogo, then quit and package
>>>>> felix for deployment on our integration servers.
>>>>>
>>>>> Unfortunately, felix seems to undeploy the deployed bundles when
>>>>> shutting down. If I do this manually, felix retains the bundles across
>>>>> shutdowns and startups.
>>>> I'm not sure what you mean, nor what you are doing exactly, but the
>>>> Felix framework always retains bundles across shutdowns and restarts.
>>>> The framework will never undeploy a bundle unless someone tells it to do
>>>> so.
>>>>
>>>> -> richard
>>>>
>>>>> The only difference I can find is on how I exit Felix. From the script,
>>>>> felix exits "normally", and when configuring interactively I exit with
>>>>> Ctrl-C.
>>>>>
>>>>> -> so my question is: how can I persuade Felix to keep the installed
>>>>> bundles (and keep their active state) across shutdowns and startups?
>>>>>
>>>>> -> would the proper way to do this be over config.properties?
>>>>>
>>>>> -> if yes, and if this means that deployment of bundles happens on
>>>>> every
>>>>> startup, then how do I work around the issue of potentially not having
>>>>> access to a repo on the server that felix is to be installed?
>>>>>
>>>>>
>>>>> Here is the part of the script which uses gogo:
>>>>>
>>>>> #!/bin/bash
>>>>> # ...
>>>>> # GOGO deployment script
>>>>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>>>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>>>> obr:deploy -s "Bundle A"
>>>>> obr:deploy -s "Bundle B"
>>>>> obr:deploy -s "Bundle C"
>>>>> # etc.
>>>>> felix:refresh
>>>>> felix:lb
>>>>> END_GOGO_SCRIPT
>>>>> # ...
>>>>> # run felix and GOGO script
>>>>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>>>>> gosh --nointeractive --login -x $GOGO_SCRIPT
>>>>> END_GOGO_SCRIPT_STARTUP
>>>>>
>>>>>
>>>>> Thanks for any help,
>>>>> Sam
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by Sam Spycher <sa...@spycher.info>.
P.S.
Just wanted to mention also that there is no urgency to this issue, at
least not to me personally.
Since I have proceeded in the meantime by adding our project bundles
with maven copy-dependencies per Lionel's recommendations, and
test-running felix afterwards, the only disadvantage I have at the
moment is that I have an unnecessary felix cache directory called '-'
after running maven.
Best regards,
Sam
Am 19.10.11 18:09, schrieb Sam Spycher:
> Hmm, that is interesting.
>
> When I deploy felix via script, I can observe the creation of a
> directory called '-' in the working directory while the script is executing.
>
> Looking at the contents of '-', I find bundleX subdirectories just as is
> to be expected from the felix cache. Indeed if i cat the bundle.info
> of the bundle with the highest number I can see this corresponds to a
> bundle that I installed with gogo.
>
> However, when I run Felix interactively from the shell after having run
> the script, it creates a new cache directory with the proper default
> name 'felix-cache'. Of course this directory now contains no traces of
> what was installed with gogo, it only has the bundles which were copied
> into the bundle/ subdirectory.
>
> -> Some issue with the cache directory name when running felix
> non-interactively?
>
> Note that I'm running 4.0.1 directly off maven, with no modifications to
> config.properties.
>
> Thanks & Best regards,
> Sam
>
> Am 19.10.11 17:44, schrieb Richard S. Hall:
>> On 10/19/11 11:39 , Sam Spycher wrote:
>>> Hi Richard,
>>>
>>> I am running a bash script which sends some gogo deployment commands to
>>> install some bundles in felix. I then list the bundles I just deployed
>>> with gogo with the command 'lb'. These bundles are all correctly
>>> displayed and have their state set to active. At the end of the script
>>> Felix then terminates (I assume because it is called non-interactively
>>> via a script).
>>>
>>> Now if I startup this exact same deployment and list the installed
>>> bundles via 'lb', all I get is the bundles I previously copied into the
>>> bunde/ subdirectory. The bundles I installed via gogo have disappeared,
>>> although I never undeployed them.
>>>
>>> What am I missing?
>>
>> Well, the framework installs bundles into a cache, which is by default
>> in the current directory called felix-cache. Do you see this directory
>> get created? Is it still there after shutdown? What happens to it after
>> startup?
>>
>> -> richard
>>
>>>
>>>
>>> Here is a minimal version of my deployment script:
>>>
>>> #!/bin/bash
>>> java -verbose -jar bin/felix.jar<<-END_GOGO_SCRIPT_STARTUP
>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>> obr:deploy -s "Some bundle from maven repo"
>>> felix:refresh
>>> felix:lb
>>> END_GOGO_SCRIPT_STARTUP
>>>
>>> Best regards,
>>> Sam
>>>
>>> Am 19.10.11 17:23, schrieb Richard S. Hall:
>>>> On 10/19/11 03:24 , Sam Spycher wrote:
>>>>> Hi
>>>>>
>>>>> I am currently writing a small shell script which is supposed to run
>>>>> felix, install the necessary bundles with gogo, then quit and package
>>>>> felix for deployment on our integration servers.
>>>>>
>>>>> Unfortunately, felix seems to undeploy the deployed bundles when
>>>>> shutting down. If I do this manually, felix retains the bundles across
>>>>> shutdowns and startups.
>>>> I'm not sure what you mean, nor what you are doing exactly, but the
>>>> Felix framework always retains bundles across shutdowns and restarts.
>>>> The framework will never undeploy a bundle unless someone tells it to do
>>>> so.
>>>>
>>>> -> richard
>>>>
>>>>> The only difference I can find is on how I exit Felix. From the script,
>>>>> felix exits "normally", and when configuring interactively I exit with
>>>>> Ctrl-C.
>>>>>
>>>>> -> so my question is: how can I persuade Felix to keep the installed
>>>>> bundles (and keep their active state) across shutdowns and startups?
>>>>>
>>>>> -> would the proper way to do this be over config.properties?
>>>>>
>>>>> -> if yes, and if this means that deployment of bundles happens on
>>>>> every
>>>>> startup, then how do I work around the issue of potentially not having
>>>>> access to a repo on the server that felix is to be installed?
>>>>>
>>>>>
>>>>> Here is the part of the script which uses gogo:
>>>>>
>>>>> #!/bin/bash
>>>>> # ...
>>>>> # GOGO deployment script
>>>>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>>>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>>>> obr:deploy -s "Bundle A"
>>>>> obr:deploy -s "Bundle B"
>>>>> obr:deploy -s "Bundle C"
>>>>> # etc.
>>>>> felix:refresh
>>>>> felix:lb
>>>>> END_GOGO_SCRIPT
>>>>> # ...
>>>>> # run felix and GOGO script
>>>>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>>>>> gosh --nointeractive --login -x $GOGO_SCRIPT
>>>>> END_GOGO_SCRIPT_STARTUP
>>>>>
>>>>>
>>>>> Thanks for any help,
>>>>> Sam
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by Sam Spycher <sa...@spycher.info>.
Hmm, that is interesting.
When I deploy felix via script, I can observe the creation of a
directory called '-' in the working directory while the script is executing.
Looking at the contents of '-', I find bundleX subdirectories just as is
to be expected from the felix cache. Indeed if i cat the bundle.info
of the bundle with the highest number I can see this corresponds to a
bundle that I installed with gogo.
However, when I run Felix interactively from the shell after having run
the script, it creates a new cache directory with the proper default
name 'felix-cache'. Of course this directory now contains no traces of
what was installed with gogo, it only has the bundles which were copied
into the bundle/ subdirectory.
-> Some issue with the cache directory name when running felix
non-interactively?
Note that I'm running 4.0.1 directly off maven, with no modifications to
config.properties.
Thanks & Best regards,
Sam
Am 19.10.11 17:44, schrieb Richard S. Hall:
> On 10/19/11 11:39 , Sam Spycher wrote:
>> Hi Richard,
>>
>> I am running a bash script which sends some gogo deployment commands to
>> install some bundles in felix. I then list the bundles I just deployed
>> with gogo with the command 'lb'. These bundles are all correctly
>> displayed and have their state set to active. At the end of the script
>> Felix then terminates (I assume because it is called non-interactively
>> via a script).
>>
>> Now if I startup this exact same deployment and list the installed
>> bundles via 'lb', all I get is the bundles I previously copied into the
>> bunde/ subdirectory. The bundles I installed via gogo have disappeared,
>> although I never undeployed them.
>>
>> What am I missing?
>
> Well, the framework installs bundles into a cache, which is by default
> in the current directory called felix-cache. Do you see this directory
> get created? Is it still there after shutdown? What happens to it after
> startup?
>
> -> richard
>
>>
>>
>> Here is a minimal version of my deployment script:
>>
>> #!/bin/bash
>> java -verbose -jar bin/felix.jar<<-END_GOGO_SCRIPT_STARTUP
>> obr:repos add file:$HOME/.m2/repository/repository.xml
>> obr:deploy -s "Some bundle from maven repo"
>> felix:refresh
>> felix:lb
>> END_GOGO_SCRIPT_STARTUP
>>
>> Best regards,
>> Sam
>>
>> Am 19.10.11 17:23, schrieb Richard S. Hall:
>>> On 10/19/11 03:24 , Sam Spycher wrote:
>>>> Hi
>>>>
>>>> I am currently writing a small shell script which is supposed to run
>>>> felix, install the necessary bundles with gogo, then quit and package
>>>> felix for deployment on our integration servers.
>>>>
>>>> Unfortunately, felix seems to undeploy the deployed bundles when
>>>> shutting down. If I do this manually, felix retains the bundles across
>>>> shutdowns and startups.
>>> I'm not sure what you mean, nor what you are doing exactly, but the
>>> Felix framework always retains bundles across shutdowns and restarts.
>>> The framework will never undeploy a bundle unless someone tells it to do
>>> so.
>>>
>>> -> richard
>>>
>>>> The only difference I can find is on how I exit Felix. From the script,
>>>> felix exits "normally", and when configuring interactively I exit with
>>>> Ctrl-C.
>>>>
>>>> -> so my question is: how can I persuade Felix to keep the installed
>>>> bundles (and keep their active state) across shutdowns and startups?
>>>>
>>>> -> would the proper way to do this be over config.properties?
>>>>
>>>> -> if yes, and if this means that deployment of bundles happens on
>>>> every
>>>> startup, then how do I work around the issue of potentially not having
>>>> access to a repo on the server that felix is to be installed?
>>>>
>>>>
>>>> Here is the part of the script which uses gogo:
>>>>
>>>> #!/bin/bash
>>>> # ...
>>>> # GOGO deployment script
>>>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>>> obr:deploy -s "Bundle A"
>>>> obr:deploy -s "Bundle B"
>>>> obr:deploy -s "Bundle C"
>>>> # etc.
>>>> felix:refresh
>>>> felix:lb
>>>> END_GOGO_SCRIPT
>>>> # ...
>>>> # run felix and GOGO script
>>>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>>>> gosh --nointeractive --login -x $GOGO_SCRIPT
>>>> END_GOGO_SCRIPT_STARTUP
>>>>
>>>>
>>>> Thanks for any help,
>>>> Sam
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/19/11 11:39 , Sam Spycher wrote:
> Hi Richard,
>
> I am running a bash script which sends some gogo deployment commands to
> install some bundles in felix. I then list the bundles I just deployed
> with gogo with the command 'lb'. These bundles are all correctly
> displayed and have their state set to active. At the end of the script
> Felix then terminates (I assume because it is called non-interactively
> via a script).
>
> Now if I startup this exact same deployment and list the installed
> bundles via 'lb', all I get is the bundles I previously copied into the
> bunde/ subdirectory. The bundles I installed via gogo have disappeared,
> although I never undeployed them.
>
> What am I missing?
Well, the framework installs bundles into a cache, which is by default
in the current directory called felix-cache. Do you see this directory
get created? Is it still there after shutdown? What happens to it after
startup?
-> richard
>
>
> Here is a minimal version of my deployment script:
>
> #!/bin/bash
> java -verbose -jar bin/felix.jar<<-END_GOGO_SCRIPT_STARTUP
> obr:repos add file:$HOME/.m2/repository/repository.xml
> obr:deploy -s "Some bundle from maven repo"
> felix:refresh
> felix:lb
> END_GOGO_SCRIPT_STARTUP
>
> Best regards,
> Sam
>
> Am 19.10.11 17:23, schrieb Richard S. Hall:
>> On 10/19/11 03:24 , Sam Spycher wrote:
>>> Hi
>>>
>>> I am currently writing a small shell script which is supposed to run
>>> felix, install the necessary bundles with gogo, then quit and package
>>> felix for deployment on our integration servers.
>>>
>>> Unfortunately, felix seems to undeploy the deployed bundles when
>>> shutting down. If I do this manually, felix retains the bundles across
>>> shutdowns and startups.
>> I'm not sure what you mean, nor what you are doing exactly, but the
>> Felix framework always retains bundles across shutdowns and restarts.
>> The framework will never undeploy a bundle unless someone tells it to do
>> so.
>>
>> -> richard
>>
>>> The only difference I can find is on how I exit Felix. From the script,
>>> felix exits "normally", and when configuring interactively I exit with
>>> Ctrl-C.
>>>
>>> -> so my question is: how can I persuade Felix to keep the installed
>>> bundles (and keep their active state) across shutdowns and startups?
>>>
>>> -> would the proper way to do this be over config.properties?
>>>
>>> -> if yes, and if this means that deployment of bundles happens on every
>>> startup, then how do I work around the issue of potentially not having
>>> access to a repo on the server that felix is to be installed?
>>>
>>>
>>> Here is the part of the script which uses gogo:
>>>
>>> #!/bin/bash
>>> # ...
>>> # GOGO deployment script
>>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>> obr:deploy -s "Bundle A"
>>> obr:deploy -s "Bundle B"
>>> obr:deploy -s "Bundle C"
>>> # etc.
>>> felix:refresh
>>> felix:lb
>>> END_GOGO_SCRIPT
>>> # ...
>>> # run felix and GOGO script
>>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>>> gosh --nointeractive --login -x $GOGO_SCRIPT
>>> END_GOGO_SCRIPT_STARTUP
>>>
>>>
>>> Thanks for any help,
>>> Sam
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by Sam Spycher <sa...@spycher.info>.
Hi Richard,
I am running a bash script which sends some gogo deployment commands to
install some bundles in felix. I then list the bundles I just deployed
with gogo with the command 'lb'. These bundles are all correctly
displayed and have their state set to active. At the end of the script
Felix then terminates (I assume because it is called non-interactively
via a script).
Now if I startup this exact same deployment and list the installed
bundles via 'lb', all I get is the bundles I previously copied into the
bunde/ subdirectory. The bundles I installed via gogo have disappeared,
although I never undeployed them.
What am I missing?
Here is a minimal version of my deployment script:
#!/bin/bash
java -verbose -jar bin/felix.jar <<-END_GOGO_SCRIPT_STARTUP
obr:repos add file:$HOME/.m2/repository/repository.xml
obr:deploy -s "Some bundle from maven repo"
felix:refresh
felix:lb
END_GOGO_SCRIPT_STARTUP
Best regards,
Sam
Am 19.10.11 17:23, schrieb Richard S. Hall:
> On 10/19/11 03:24 , Sam Spycher wrote:
>> Hi
>>
>> I am currently writing a small shell script which is supposed to run
>> felix, install the necessary bundles with gogo, then quit and package
>> felix for deployment on our integration servers.
>>
>> Unfortunately, felix seems to undeploy the deployed bundles when
>> shutting down. If I do this manually, felix retains the bundles across
>> shutdowns and startups.
>
> I'm not sure what you mean, nor what you are doing exactly, but the
> Felix framework always retains bundles across shutdowns and restarts.
> The framework will never undeploy a bundle unless someone tells it to do
> so.
>
> -> richard
>
>>
>> The only difference I can find is on how I exit Felix. From the script,
>> felix exits "normally", and when configuring interactively I exit with
>> Ctrl-C.
>>
>> -> so my question is: how can I persuade Felix to keep the installed
>> bundles (and keep their active state) across shutdowns and startups?
>>
>> -> would the proper way to do this be over config.properties?
>>
>> -> if yes, and if this means that deployment of bundles happens on every
>> startup, then how do I work around the issue of potentially not having
>> access to a repo on the server that felix is to be installed?
>>
>>
>> Here is the part of the script which uses gogo:
>>
>> #!/bin/bash
>> # ...
>> # GOGO deployment script
>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>> obr:repos add file:$HOME/.m2/repository/repository.xml
>> obr:deploy -s "Bundle A"
>> obr:deploy -s "Bundle B"
>> obr:deploy -s "Bundle C"
>> # etc.
>> felix:refresh
>> felix:lb
>> END_GOGO_SCRIPT
>> # ...
>> # run felix and GOGO script
>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>> gosh --nointeractive --login -x $GOGO_SCRIPT
>> END_GOGO_SCRIPT_STARTUP
>>
>>
>> Thanks for any help,
>> Sam
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/19/11 03:24 , Sam Spycher wrote:
> Hi
>
> I am currently writing a small shell script which is supposed to run
> felix, install the necessary bundles with gogo, then quit and package
> felix for deployment on our integration servers.
>
> Unfortunately, felix seems to undeploy the deployed bundles when
> shutting down. If I do this manually, felix retains the bundles across
> shutdowns and startups.
I'm not sure what you mean, nor what you are doing exactly, but the
Felix framework always retains bundles across shutdowns and restarts.
The framework will never undeploy a bundle unless someone tells it to do so.
-> richard
>
> The only difference I can find is on how I exit Felix. From the script,
> felix exits "normally", and when configuring interactively I exit with
> Ctrl-C.
>
> -> so my question is: how can I persuade Felix to keep the installed
> bundles (and keep their active state) across shutdowns and startups?
>
> -> would the proper way to do this be over config.properties?
>
> -> if yes, and if this means that deployment of bundles happens on every
> startup, then how do I work around the issue of potentially not having
> access to a repo on the server that felix is to be installed?
>
>
> Here is the part of the script which uses gogo:
>
> #!/bin/bash
> # ...
> # GOGO deployment script
> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
> obr:repos add file:$HOME/.m2/repository/repository.xml
> obr:deploy -s "Bundle A"
> obr:deploy -s "Bundle B"
> obr:deploy -s "Bundle C"
> # etc.
> felix:refresh
> felix:lb
> END_GOGO_SCRIPT
> # ...
> # run felix and GOGO script
> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
> gosh --nointeractive --login -x $GOGO_SCRIPT
> END_GOGO_SCRIPT_STARTUP
>
>
> Thanks for any help,
> Sam
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Scripting felix
Posted by Sam Spycher <sa...@spycher.info>.
Hi
I am currently writing a small shell script which is supposed to run
felix, install the necessary bundles with gogo, then quit and package
felix for deployment on our integration servers.
Unfortunately, felix seems to undeploy the deployed bundles when
shutting down. If I do this manually, felix retains the bundles across
shutdowns and startups.
The only difference I can find is on how I exit Felix. From the script,
felix exits "normally", and when configuring interactively I exit with
Ctrl-C.
-> so my question is: how can I persuade Felix to keep the installed
bundles (and keep their active state) across shutdowns and startups?
-> would the proper way to do this be over config.properties?
-> if yes, and if this means that deployment of bundles happens on every
startup, then how do I work around the issue of potentially not having
access to a repo on the server that felix is to be installed?
Here is the part of the script which uses gogo:
#!/bin/bash
# ...
# GOGO deployment script
cat > $GOGO_SCRIPT <<-END_GOGO_SCRIPT
obr:repos add file:$HOME/.m2/repository/repository.xml
obr:deploy -s "Bundle A"
obr:deploy -s "Bundle B"
obr:deploy -s "Bundle C"
# etc.
felix:refresh
felix:lb
END_GOGO_SCRIPT
# ...
# run felix and GOGO script
java -verbose -jar bin/felix.jar - <<-END_GOGO_SCRIPT_STARTUP
gosh --nointeractive --login -x $GOGO_SCRIPT
END_GOGO_SCRIPT_STARTUP
Thanks for any help,
Sam
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Instantiating Manipulated Class without IPojo
Posted by Karl Pauls <ka...@gmail.com>.
iirc, all you need to do is to have iPOJO on the classpath.
regards,
Karl
On Wed, Oct 19, 2011 at 5:21 AM, Göktürk Gezer <go...@gmail.com> wrote:
> Hi Everyone,
>
> We're in the middle of moving our codebase to OSGI using IPojo. Problem is,
> I can not instantiate the manipulated classes without IPojo.
>
> AFAIK, IPojo manipulates the constructors with no argument and BundleContext
> argument. So we can use other constructors for instance creation without
> getting through IPojo, and all field and method delegations will be disabled
> in that case. Am i wrong?
>
> IPojoized classes are subclasses of some generic type, and i just use
> @Component and @Provides on them. That's all, just for easy service
> publication. But after that i can not instantiate them using _ctor(String)
> constructor.
>
> If you ask why you're using normal instantiation, these usages without IPojo
> are just on unit tests. Eventually we'll move these tests to OSGI, but it
> would be cool to be able to still use them until we do.
>
>
> Regards,
> Gokturk
>
--
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org