Re: Suggestions on OSGi-context testing

2011-12-09 Thread Ken Gilmer
Hi Karl,

  Thanks for the additional guidance.  So I spent some time setting up
a vanilla maven osgi bundle project.  I was able to add pojosr and
create a simple test case that started my bundle, retrieved the
service via the pojosr service registry, and executed the service.

  I then moved to integrating pojosr into httplite so I could begin
writing tests.  As my bundle starts in my test case, I ran into a
problem where "org.osgi.vendor.framework" is an undefined system
property.  I did some digging and determined that the FrameworkUtil
class tries to be dynamically loaded based on the root classname as
defined by "org.osgi.vendor.framework".  Setting to this to
"org.osgi.framework", (which is the root package name for the class
contained in pojosr) resulted in a stack overflow.  The FrameworkUtil
in the Felix framework is available but has all sorts of private
dependencies and is not easy to pull out into my own package. It
appears that the pojosr implementation is just calling itself, or
expecting another class to be available?  Any suggestions?

thx
ken

On Thu, Dec 8, 2011 at 6:58 PM, Karl Pauls  wrote:
> On Thu, Dec 8, 2011 at 8:59 AM, Ken Gilmer  wrote:
>> Thanks Andreas, Karl, and Arjun!
>>
>> Andreas,
>>
>>  I spent some time learning the basics of Pax Exam.  One of my
>> particular requirements is JUnit3/Java1.4.  I see it mentioned in a
>> JIRA issue that support has been added but cannot find a suitable
>> example of how this works.  Ideally for me, the Pax Exam documentation
>> would contain the initial description of what Pax Exam is, and then
>> want to see only a maven-based project with:
>>
>> a) a service definition (public api)
>> b) some implementation (private)
>> c) a test that gets the service and executes a method via junit
>> d) the minimal POM that builds the regular bundle and also runs the junit 
>> test
>>
>>  The existing example code is helpful but doesn't really answer my
>> immediate needs of getting started quickly, (as one who is not too
>> familiar with Maven yet).
>>
>> Karl,
>>
>>  Regarding PojoSR, I probably do not need a full OSGi framework for
>> my tests, so it could be suitable for me.  However I need a bit more
>> guidance on how to set up running a test (I can visualize how to
>> compose a test) in Maven.  Can you point me to an existing pom.xml
>> that uses PojoSR to execute JUnit tests against a service?
>
> I guess there are (at least could be) several approaches which also
> depend on your needs. One public example I know of is the work
> Guillaume Nodet (and maybe others) did for fuse:
>
> https://github.com/fusesource/fuse/tree/master/fabric/fabric-itests/fabric-pojosr
>
> Does that help?
>
>>  Regarding bnd, it seems to utilize Ant makefiles.  I'd like to avoid
>> that if possible.  Nothing against Ant, in fact I have my own
>> Ant-based osgi test framework, but I'd like to keep the test stuff as
>> simple as I can and keep things in Maven.
>
> It might not be impossible to hook it up to maven (if nothing else, by
> executing the and file from there). I think it is mostly based on bnd
> and the ant files are just very lightweight wrappers around it but I
> can't say whether it would be easy or not. You can see an example in
> ricks sandbox (the example requires you to use ant to execute the
> tests but it uses maven to get the thing assembled iirc) :
>
> http://svn.apache.org/repos/asf/felix/sandbox/rickhall/bnd-test/
>
> regards,
>
> Karl
>
>> Arjun,
>>
>>  For me, the most difficult part is the Maven integration.  I want
>> the tests to run and fail as part of the build.  In any case it's good
>> to know you've got that, I'll check it out.
>>
>> thx,
>> ken
>>
>>
>>
>> On Tue, Dec 6, 2011 at 6:56 PM, Karl Pauls  wrote:
>>> To use PojoSR for testing with your dependencies from maven I guess
>>> you could just use the exec-maven-plugin, hook it up to the test phase
>>> and have it start with all dependencies from the test scope.
>>>
>>> regards,
>>>
>>> Karl
>>>
>>> On Tue, Dec 6, 2011 at 9:25 AM, Karl Pauls  wrote:
 If you are looking for real integration testing, Pax Exam is probably
 what you want.

 However, if you want to test you services without a full OSGi
 framework you might want to have  a look at PojoSR:

 http://pojosr.googlecode.com

 I know that some people use it for JUnit testing their services.
 Finally, bnd itself can be used for testing (we use that in the
 framework) and it is used by the OSGi ct.

 regards,

 Karl

 On Tue, Dec 6, 2011 at 9:17 AM, Andreas Pieber  wrote:
> Hey Ken,
>
> You might want to give Pax Exam a look for integration tests with OSGi:
> http://team.ops4j.org/wiki/display/paxexam/Pax+Exam
>
> Kind regards,
> Andreas
>
> On Tue, Dec 6, 2011 at 09:11, Ken Gilmer  wrote:
>
>> Hi,
>>
>>  I'd like to begin adding some test cases to the httplite bundle.  
>> Ideally
>> I'd like my tests exe

[jira] [Created] (FELIX-3265) AJAX Error: Request Failed: FULL head

2011-12-09 Thread Deniz Acay (Created) (JIRA)
AJAX Error: Request Failed: FULL head
-

 Key: FELIX-3265
 URL: https://issues.apache.org/jira/browse/FELIX-3265
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service, Web Console
Affects Versions: http-2.2.0, webconsole-3.1.8
 Environment: Windows Vista x86, Java 6
Reporter: Deniz Acay


I have been using Web Console for a while to configure my DS components. But 
recently, one of my component's metatype.xml file got larger due to increase in 
configuration options for the component. Suddenly, now when I try to configure 
that component, even without changing a value, I get an AJAX error. Although 
sometimes there is no message inside the AJAX Error dialog at all, I frequently 
get a "Request failed: FULL head" message in the AJAX Error modal dialog. I 
have searched around the internet and it looks like the cause of this is about 
the size of the Jetty's header buffer 
(http://jira.codehaus.org/browse/JETTY-336).

Any fix is appreciated as this prevents me from debugging configuration of my 
component.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (FELIX-3264) Dependency manager shell should not print the state of optional dependencies when not all required ones are available

2011-12-09 Thread Marcel Offermans (Resolved) (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans resolved FELIX-3264.
-

Resolution: Fixed

Committed a fix for this.

> Dependency manager shell should not print the state of optional dependencies 
> when not all required ones are available
> -
>
> Key: FELIX-3264
> URL: https://issues.apache.org/jira/browse/FELIX-3264
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager
>Affects Versions: dependencymanager-3.0.0
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
>
> Internally, the dependency manager only starts listening to optional 
> dependencies once all required ones are available. That means that optional 
> dependencies will always be listed as "unavailable" in that scenario. That 
> looks somewhat funny though: a required dependency to A that is available 
> might also be shown as an optional one to A in a different component, and it 
> might seem unavailable there.
> The fix is to not print the state of (optional) dependencies if they have not 
> been started yet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Assigned] (FELIX-3264) Dependency manager shell should not print the state of optional dependencies when not all required ones are available

2011-12-09 Thread Marcel Offermans (Assigned) (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans reassigned FELIX-3264:
---

Assignee: Marcel Offermans

> Dependency manager shell should not print the state of optional dependencies 
> when not all required ones are available
> -
>
> Key: FELIX-3264
> URL: https://issues.apache.org/jira/browse/FELIX-3264
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager
>Affects Versions: dependencymanager-3.0.0
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
>
> Internally, the dependency manager only starts listening to optional 
> dependencies once all required ones are available. That means that optional 
> dependencies will always be listed as "unavailable" in that scenario. That 
> looks somewhat funny though: a required dependency to A that is available 
> might also be shown as an optional one to A in a different component, and it 
> might seem unavailable there.
> The fix is to not print the state of (optional) dependencies if they have not 
> been started yet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




SCR Ant Task Download link is broken

2011-12-09 Thread Daniel Kuffner
Hi,

Just want to note that the SCR Ant Task downloadlink is broken:
http://felix.apache.org/site/downloads.cgi

regards,
Daniel


[jira] [Created] (FELIX-3264) Dependency manager shell should not print the state of optional dependencies when not all required ones are available

2011-12-09 Thread Marcel Offermans (Created) (JIRA)
Dependency manager shell should not print the state of optional dependencies 
when not all required ones are available
-

 Key: FELIX-3264
 URL: https://issues.apache.org/jira/browse/FELIX-3264
 Project: Felix
  Issue Type: Improvement
  Components: Dependency Manager
Affects Versions: dependencymanager-3.0.0
Reporter: Marcel Offermans


Internally, the dependency manager only starts listening to optional 
dependencies once all required ones are available. That means that optional 
dependencies will always be listed as "unavailable" in that scenario. That 
looks somewhat funny though: a required dependency to A that is available might 
also be shown as an optional one to A in a different component, and it might 
seem unavailable there.

The fix is to not print the state of (optional) dependencies if they have not 
been started yet.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (FELIX-3263) NPE in calculateExportedPackages

2011-12-09 Thread Ioannis Canellos (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-3263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ioannis Canellos updated FELIX-3263:


Priority: Trivial  (was: Major)

> NPE in calculateExportedPackages
> 
>
> Key: FELIX-3263
> URL: https://issues.apache.org/jira/browse/FELIX-3263
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-3.0.9
>Reporter: Ioannis Canellos
>Priority: Trivial
>
> I've created a Karaf feature that gives me this error:
> java.lang.NullPointerException
>   at 
> org.apache.felix.framework.resolver.ResolverImpl.calculateExportedPackages(ResolverImpl.java:1212)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:594)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:601)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:90)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:4033)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3439)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.felix.framework.Felix.startBundle(Felix.java:1734)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:918)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:350)[27:org.apache.karaf.features.core:2.2.4]
>   at 
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:280)[27:org.apache.karaf.features.core:2.2.4]
>   at 
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:276)[27:org.apache.karaf.features.core:2.2.4]
>   at 
> org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:62)[22:org.apache.karaf.features.command:2.2.4]
>   at 
> org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[22:org.apache.karaf.features.command:2.2.4]
>   at 
> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:474)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:400)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.karaf.shell.console.jline.Console.run(Console.java:218)[23:org.apache.karaf.shell.console:2.2.4]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (FELIX-3263) NPE in calculateExportedPackages

2011-12-09 Thread Ioannis Canellos (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-3263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166254#comment-13166254
 ] 

Ioannis Canellos commented on FELIX-3263:
-

Hi Richard. I don't think this is a dublicate, since Felix-2741 refers to an 
older version and is marked as released.

I will try to use the latest 3.x version of the framework. In the meanwhile I 
have a small update on this.

In my case, the root cause of the problem was that one of the many fragments 
had unsatisfied dependencies. Once I fixed that the problem was also fixed.

However, the NPE in the framework is still an issue even if it happens when 
there is a "user error". So I think that I could decrease the priority to 
trivial.



> NPE in calculateExportedPackages
> 
>
> Key: FELIX-3263
> URL: https://issues.apache.org/jira/browse/FELIX-3263
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-3.0.9
>Reporter: Ioannis Canellos
>
> I've created a Karaf feature that gives me this error:
> java.lang.NullPointerException
>   at 
> org.apache.felix.framework.resolver.ResolverImpl.calculateExportedPackages(ResolverImpl.java:1212)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:594)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:601)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:90)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:4033)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3439)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.felix.framework.Felix.startBundle(Felix.java:1734)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:918)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)[org.apache.felix.framework-3.0.9.jar:]
>   at 
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:350)[27:org.apache.karaf.features.core:2.2.4]
>   at 
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:280)[27:org.apache.karaf.features.core:2.2.4]
>   at 
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:276)[27:org.apache.karaf.features.core:2.2.4]
>   at 
> org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:62)[22:org.apache.karaf.features.command:2.2.4]
>   at 
> org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[22:org.apache.karaf.features.command:2.2.4]
>   at 
> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:474)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:400)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)[23:org.apache.karaf.shell.console:2.2.4]
>   at 
> org.apache.karaf.shell.console.jline.Console.run(Console.java:218)[23:org.apache.karaf.shell.console:2.2.4]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: Suggestions on OSGi-context testing

2011-12-09 Thread Andreas Pieber
Hey Ken,

I don't think that exam 2.x runs with java < 1.5.

For source examples though
https://github.com/ops4j/org.ops4j.pax.exam2/tree/master/it-regression is a
good starting point.

Kind regards,
Andreas

On Thu, Dec 8, 2011 at 08:59, Ken Gilmer  wrote:

> Thanks Andreas, Karl, and Arjun!
>
> Andreas,
>
>  I spent some time learning the basics of Pax Exam.  One of my
> particular requirements is JUnit3/Java1.4.  I see it mentioned in a
> JIRA issue that support has been added but cannot find a suitable
> example of how this works.  Ideally for me, the Pax Exam documentation
> would contain the initial description of what Pax Exam is, and then
> want to see only a maven-based project with:
>
> a) a service definition (public api)
> b) some implementation (private)
> c) a test that gets the service and executes a method via junit
> d) the minimal POM that builds the regular bundle and also runs the junit
> test
>
>  The existing example code is helpful but doesn't really answer my
> immediate needs of getting started quickly, (as one who is not too
> familiar with Maven yet).
>
> Karl,
>
>  Regarding PojoSR, I probably do not need a full OSGi framework for
> my tests, so it could be suitable for me.  However I need a bit more
> guidance on how to set up running a test (I can visualize how to
> compose a test) in Maven.  Can you point me to an existing pom.xml
> that uses PojoSR to execute JUnit tests against a service?
>
>  Regarding bnd, it seems to utilize Ant makefiles.  I'd like to avoid
> that if possible.  Nothing against Ant, in fact I have my own
> Ant-based osgi test framework, but I'd like to keep the test stuff as
> simple as I can and keep things in Maven.
>
> Arjun,
>
>  For me, the most difficult part is the Maven integration.  I want
> the tests to run and fail as part of the build.  In any case it's good
> to know you've got that, I'll check it out.
>
> thx,
> ken
>
>
>
> On Tue, Dec 6, 2011 at 6:56 PM, Karl Pauls  wrote:
> > To use PojoSR for testing with your dependencies from maven I guess
> > you could just use the exec-maven-plugin, hook it up to the test phase
> > and have it start with all dependencies from the test scope.
> >
> > regards,
> >
> > Karl
> >
> > On Tue, Dec 6, 2011 at 9:25 AM, Karl Pauls  wrote:
> >> If you are looking for real integration testing, Pax Exam is probably
> >> what you want.
> >>
> >> However, if you want to test you services without a full OSGi
> >> framework you might want to have  a look at PojoSR:
> >>
> >> http://pojosr.googlecode.com
> >>
> >> I know that some people use it for JUnit testing their services.
> >> Finally, bnd itself can be used for testing (we use that in the
> >> framework) and it is used by the OSGi ct.
> >>
> >> regards,
> >>
> >> Karl
> >>
> >> On Tue, Dec 6, 2011 at 9:17 AM, Andreas Pieber 
> wrote:
> >>> Hey Ken,
> >>>
> >>> You might want to give Pax Exam a look for integration tests with OSGi:
> >>> http://team.ops4j.org/wiki/display/paxexam/Pax+Exam
> >>>
> >>> Kind regards,
> >>> Andreas
> >>>
> >>> On Tue, Dec 6, 2011 at 09:11, Ken Gilmer  wrote:
> >>>
>  Hi,
> 
>   I'd like to begin adding some test cases to the httplite bundle.
>  Ideally
>  I'd like my tests executed within an OSGi context so I don't have to
> mock
>  anything, and the test environment is as close as possible to a real
>  instance.  Also I'd like my tests to execute as part of the maven
> build
>  process.  Can anyone suggest an existing and somewhat current Felix
> project
>  that does this or provide other suggestions?
> 
>  Thanks!
>  ken
> 
> >>
> >>
> >>
> >> --
> >> Karl Pauls
> >> karlpa...@gmail.com
> >> http://twitter.com/karlpauls
> >> http://www.linkedin.com/in/karlpauls
> >> https://profiles.google.com/karlpauls
> >
> >
> >
> > --
> > Karl Pauls
> > karlpa...@gmail.com
> > http://twitter.com/karlpauls
> > http://www.linkedin.com/in/karlpauls
> > https://profiles.google.com/karlpauls
>