Re: Problem with apache felix when using jamvm and gnu classpath (thru gcj-4.1wrapper)

[Ken Robinson <ke...@gmail.com>]

Thanks for your reply.
As you said, by using a system.properties file as follows:

java.protocol.handler.pkgs=gnu.java.net.protocol

I can leave the code unaltered and run the framework as follows:

java -jar bin/felix.jar

I've found that the problem resides with the maven.felix.plugin.  I
somehow need to set the system property as part of the integration
test phase in maven. I have tried passing the system property like so:
mvn -Dfelix.system.properties=file:/home/krobinson/Desktop/work/6/felix/trunk/main/conf/system.properties
install

This does not work.

Looking at the debug info (in my post) I can see it also uses
Felix.java. Any ideas?
ken.

On 1/31/07, Richard S. Hall <he...@ungoverned.org> wrote:
> Ken Robinson wrote:
> > I have then changed the file URLHandlers as follows but still get the
> > same message:
> >    private static final String DEFAULT_STREAM_HANDLER_PACKAGE =
> > "gnu.java.net.protocol";
> > //    private static final String DEFAULT_STREAM_HANDLER_PACKAGE =
> > "sun.net.www.protocol";
> >
> >    //private static final String DEFAULT_CONTENT_HANDLER_PACKAGE =
> > "sun.net.www.content";
> >    private static final String DEFAULT_CONTENT_HANDLER_PACKAGE =
> > "gnu.java.net.content";
> >
> > Is there something else I can do to get it working on jamvm and gnu
> > classpath?
>
> Yes, you definitely need to change these values. Are you sure those are
> the correct values? In other words, did you look in the GNU Classpath
> source, for example, and see if gnu.java.net.protocol.file.Handler exists?
>
> BTW, you are not required to modify the source code, you can also just
> set the "java.protocol.handler.pkgs" and "java.content.handler.pkgs"
> system properties appropriately.
>
> When searching for a handler, the URL Handlers service simply does a
> class load probe in all listed packages using the following pattern:
>
>     <pkg-prefix>.<protocol>.Handler
>
> So, there should be a class named "gnu.java.net.protocol.file.Handler"
> in your situation.
>
> I am pretty sure someone else got this working, maybe they have
> something to add.
>
> -> richard
>
>

Re: Problem with apache felix when using jamvm and gnu classpath (thru gcj-4.1wrapper)

["Richard S. Hall" <he...@ungoverned.org>]

Ken Robinson wrote:
> Thanks for your reply.
> As you said, by using a system.properties file as follows:
>
> java.protocol.handler.pkgs=gnu.java.net.protocol
>
> I can leave the code unaltered and run the framework as follows:
>
> java -jar bin/felix.jar
>
> I've found that the problem resides with the maven.felix.plugin.  I
> somehow need to set the system property as part of the integration
> test phase in maven. I have tried passing the system property like so:
> mvn 
> -Dfelix.system.properties=file:/home/krobinson/Desktop/work/6/felix/trunk/main/conf/system.properties 
>
> install
>
> This does not work.

The Felix launcher is responsible for interpreting the 
"felix.system.properties" property. Since you are not using the Felix 
launcher, this property is being ignored.

Unless you are setting a bunch of system properties, it seems that you'd 
be better off just setting the system property directly on the maven 
command.

I am not so sure the maven-felix-plugin is completely baked at this 
point, since it was part of an experiment by Alex Karasulu. The plugin 
creates its own launcher for Felix. Looking at the source code, it does 
not provide a mechanism to set a bunch of system properties via a file 
like the standard Felix launcher does.

You have two options the way I see it:

   1. Set your system properties manually when issuing the mvn command.
   2. Modify the maven-felix-plugin code to process the
      "system.properties" file or some similar approach.

-> richard

>
> Looking at the debug info (in my post) I can see it also uses
> Felix.java. Any ideas?
> ken.
>
> On 1/31/07, Richard S. Hall <he...@ungoverned.org> wrote:
>> Ken Robinson wrote:
>> > I have then changed the file URLHandlers as follows but still get the
>> > same message:
>> >    private static final String DEFAULT_STREAM_HANDLER_PACKAGE =
>> > "gnu.java.net.protocol";
>> > //    private static final String DEFAULT_STREAM_HANDLER_PACKAGE =
>> > "sun.net.www.protocol";
>> >
>> >    //private static final String DEFAULT_CONTENT_HANDLER_PACKAGE =
>> > "sun.net.www.content";
>> >    private static final String DEFAULT_CONTENT_HANDLER_PACKAGE =
>> > "gnu.java.net.content";
>> >
>> > Is there something else I can do to get it working on jamvm and gnu
>> > classpath?
>>
>> Yes, you definitely need to change these values. Are you sure those are
>> the correct values? In other words, did you look in the GNU Classpath
>> source, for example, and see if gnu.java.net.protocol.file.Handler 
>> exists?
>>
>> BTW, you are not required to modify the source code, you can also just
>> set the "java.protocol.handler.pkgs" and "java.content.handler.pkgs"
>> system properties appropriately.
>>
>> When searching for a handler, the URL Handlers service simply does a
>> class load probe in all listed packages using the following pattern:
>>
>>     <pkg-prefix>.<protocol>.Handler
>>
>> So, there should be a class named "gnu.java.net.protocol.file.Handler"
>> in your situation.
>>
>> I am pretty sure someone else got this working, maybe they have
>> something to add.
>>
>> -> richard
>>
>>