Don't know how to turn off directoryindex

[dynamodan]

Sorry if this is out of context here, but I noticed that the running instance is serving up a directoryIndex. How can I turn this off? It is less of a concern if I can count on runner.getContextServer().isPromiscuous() == false (not sure where to set that!). Are these settings accessible from the JavaBridgeRunner instance, or??

Thanks in advance.

[cplerch]

Which instance of JavaBridge are you running: JavaBridgeTemplate.war or Standalone jar? On which servlet container do you run it (if any): Tomcat? Version? Please give us more specific information on your runtime configuration. Regards, Chris

2017-02-24 22:47 GMT+01:00 Dynamo Dan notifications@github.com:

Sorry if this is out of context here, but I noticed that the running instance is serving up a directoryIndex. How can I turn this off? It is less of a concern if I can count on runner.getContextServer().isPromiscuous() == false (not sure where to set that!). Are these settings accessible from the JavaBridgeRunner instance, or??

Thanks in advance.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/belgattitude/php-java-bridge/issues/43, or mute the thread https://github.com/notifications/unsubscribe-auth/AIA12yWmy56ZBJ-p4b8jQKwllLgcf7nwks5rf0_tgaJpZM4MLtpS .

[dynamodan]

I'm running the standalone version included by a dependency in the pom.xml of my maven project, and then using this statement within my java program: final io.soluble.pjb.bridge.JavaBridgeRunner runner = io.soluble.pjb.bridge.JavaBridgeRunner.getInstance(javaBridgePort);

So I'm guessing there is some system property I need to set, or maybe some function to call on runner (or perhaps an http object gotten from runner?) . I just don't know what.

[cplerch]

Using the standalone version means that you are using the embedded, proprietary http server, which has this behaviour hard coded: whenever you ask for a file that is in fact a directory it will serve a directory index. Sorry, there is no way in the current version to turn it off by setting some parameter or system property.

TBD: future enhancement or wont fix. Seb?

2017-02-28 16:49 GMT+01:00 Dynamo Dan notifications@github.com:

I'm running the standalone version included by a dependency in the pom.xml of my maven project, and then using this statement within my java program: final io.soluble.pjb.bridge.JavaBridgeRunner runner = io.soluble.pjb.bridge.JavaBridgeRunner.getInstance(javaBridgePort);

So I'm guessing there is some system property I need to set, or maybe some function to call on runner (or perhaps an http object gotten from runner?) . I just don't know what.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/belgattitude/php-java-bridge/issues/43#issuecomment-283076767, or mute the thread https://github.com/notifications/unsubscribe-auth/AIA120xpsvwAZYe576-dKGcQz8BdaxZvks5rhEHygaJpZM4MLtpS .

[belgattitude]

Sorry took some days off. My long term idea was to remove the support of the internal http server (JavaBridgeRunner)... Mostly because:

1. I haven't used it (I've always deployed on Tomcat)
2. I had the feeling it was made for testing purposes (not made with scaling and performance in mind)
3. I don't really know how to support it.

Of course, this is not a definitive plan... To be sure @dynamodan can you give us more info about the intended use ?

And check if solutions like embedding jetty or undertow (only 1M) in your jar is not a better option (Embedding Tomcat is also possible but more heavy) I guess, those solutions will give you more solid server experience

What do you think ?

[cplerch]

I agree that the internl http server should be phased out.

Proposal:

• I could do a quick fix for @dynamodan https://github.com/dynamodan's issue by providing 2 new runner methods enableDirectoryIndex() and disableDirectoryIndex() with default = disabled.
• At the same time we should deprecate the internal http server by deprecating the JavaBridgeRunner class and announce its removal at the next major release.

What do you think?

2017-03-01 11:09 GMT+01:00 Sébastien Vanvelthem notifications@github.com:

Sorry took some days off. My long term idea was to remove the support of the internal http server (JavaBridgeRunner)... Mostly because:

1. I haven't used it (I've always deployed on Tomcat)
2. I had the feeling it was made for testing purposes (not made with scaling and performance in mind)
3. I don't really know how to support it.

Of course, this is not a definitive plan... To be sure @dynamodan https://github.com/dynamodan can you give us more info about the intended use ?

And check if solutions like embedding jetty https://www.eclipse.org/jetty/documentation/9.4.x/embedding-jetty.html or undertow https://github.com/undertow-io/undertow/tree/master/examples (only 1M) in your jar is not a better option (Embedding Tomcat is also possible but more heavy) I guess, those solutions will give you more solid server experience

What do you think ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/belgattitude/php-java-bridge/issues/43#issuecomment-283298760, or mute the thread https://github.com/notifications/unsubscribe-auth/AIA12_WYC4W6FW5J7nY6lUkblTbLQH9Jks5rhUPbgaJpZM4MLtpS .

[dynamodan]

I don't want to run Tomcat. Embedding Jetty seems like a better route. If there's something wrong with using the current standalone server, then fix it, rather than just deprecating JavaBridgeRunner for no specific reason. (Sorry if that sounds rude)

For now, I've determined that creating an empty folder, cd'ing to that folder and then running from there effectively disables the directory listing (by virtue of there being nothing to list). There's probably a way to set the docroot too, not sure how to do that either. Startup variable?

[belgattitude]

Hi @dynamodan.

Don't worry too much about deprecations, there's probably a long road before we remove things, and if we do, we'll increment major version... and keep fixes possibles.

Please keep in mind, that @cplerch and myself have absolutely no idea about usage people might do with the bridge... We just keep focus on what we actually use or imagine with it. So it's very welcome you share your thoughts, otherwise we may never be aware.

That said,

If there's something wrong with using the current standalone server, then fix it, rather than just deprecating JavaBridgeRunner for no specific reason.

I'm not sure if the original phpjavabridge developers made the Runner for prod systems or even imagine customizations... There's a doc: http://php-java-bridge.sourceforge.net/pjb/desktop-apps.php but I'm pretty sure I remember some warnings about production on the mailing list. Remember no jetty or undertow, grizzly at that time.

So, with that in mind... are you going with jetty ? Or do you prefer working with the JavaBridgeRunner (I believe it works) ?

[belgattitude]

@cplerch

Depending on answers from @dynamodan ... I'm totally agree with your propositions:

• 2 new runner methods enableDirectoryIndex() and disableDirectoryIndex() with default = disabled.
• At the same time we should deprecate the internal http server

Could be nice to document how to embed jetty or undertow when deprecating the internal http server. @dynamodan are you open to help on this ?

[dynamodan]

Here's the situation as best I can describe it. We have redundant codebases, one in Java, and one in PHP. Instead of maintaining them both, we are doing bug fixes and new features in the Java codebase, and have the PHP code call the functions in the Java codebase, hence my need for the bridge. Most of it is internal between systems behind firewall, but I still don't like the idea of serving a directory listing.

I would be happy to help with embedding jetty.

Also, depending on how far I get with php-java-bridge, I may even use it to replace my quercus integration which on another project, goes the other direction -- calling php code from java in a templating application for a billing system.

[belgattitude]

I would be happy to help with embedding jetty.

:+1:, would be great ! I would not include a jetty dependency in the bridge but I see it more like a documentation (for example a markdown doc in the ./doc folder: howto_embed_jetty.md or a better name)... No need to be precise, but at least provide the gradle deps, and the how to register the servlet and it's context. I did something similar here: https://github.com/belgattitude/pjb-starter-springboot/blob/master/src/main/java/io/soluble/pssb/Application.java for spring-boot... I believe you'll end up with something very similar on Jetty. Let me know your thoughts...

replace my quercus integration

Good to know, be sure to read the considerations and some benchmarks. The bridge is very sensitive to roundtrips... (where quercus is a real PHP/JVM implementation). There's some limitations to keep in mind.

[belgattitude]

FYI, I plan to write a doc website about the bridge... But I'm very slow at it, you can have a look to a work in progress on the soluble-japha client site: http://docs.soluble.io/soluble-japha/ (needs fixes)

[dynamodan]

Well I've played around with jetty a bit, and the first problem I'm running into is jetty's inability to deal with the lack of an EOF when running the doPut(). The client never sends an EOF so jetty times out the request after 30 seconds. I'm probably doing something way wrong.

[belgattitude]

Not sure to understand, neither that you did something wrong ;)

I'm not experienced in Java at all but If you suspect something wrong about the client (I guess the PHP one), I can help... Also that you can override the doPut()

@Override
protected void doPut(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    // make some tests here
}

Let me know how it goes...

[dynamodan]

Oh yes, I have the doPut() override function in place.

[dynamodan]

In the try block, it always times out on the handleRequests(is, os) and the stack trace shows the timeout happening in the bridge parser's read function (and subsequently jetty's http read stack).

[cplerch]

I can see from the sources that at line 103 the Parser is simply trying to read the next block from its input stream. The docs about the read method say:

The default implementation of this method blocks until the requested amount of input data len has been read, end of file is detected, or an exception is thrown.

And: It should throw an IOException https://docs.oracle.com/javase/7/docs/api/java/io/IOException.html - If the first byte cannot be read for any reason other than end of file, or if the input stream has been closed, or if some other I/O error occurs.

Since it throws an IOException and doesn't wait indefinitly for the next character it looks to me that the other side has closed the input stream without "sending an EOF" first, as @dynamodan has already suspected.

Q: Why does it work with embedded Tomcat, standalone Tomcat but not with embedded Jetty? How about standalone Jetty?

Maybe we have overlooked something stupid simple.

2017-03-02 14:06 GMT+01:00 Dynamo Dan notifications@github.com:

In the try block, it always times out on the handleRequests(is, os) and the stack trace shows the timeout happening in the bridge parser's read function (and subsequently jetty's http read stack). [image: zol ubuntu1604-p6720f -documents-git_bwman-splunktocsv_037] https://cloud.githubusercontent.com/assets/737226/23508343/334a4c2a-ff1f-11e6-868a-f23bb44b047d.jpg

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/belgattitude/php-java-bridge/issues/43#issuecomment-283648566, or mute the thread https://github.com/notifications/unsubscribe-auth/AIA1297UcScqgg2t9YhrZYaGuDLrhMzYks5rhr7xgaJpZM4MLtpS .

[belgattitude]

Looks weird,

@dynamodan can you confirm that the doGet method works ?

PS: I might be very wrong on that one, but have you registered the 'io.soluble.pjb.servlet.ContextLoaderListener' as well ?

<listener>
     <listener-class>io.soluble.pjb.servlet.ContextLoaderListener</listener-class>
</listener>

Please ignore if totally out of context ;)

[belgattitude]

Might be again totally wrong, but on the sourceforge website, the handleRequests() is called directly on RemoteHttpServletContextFactory ctx = new RemoteHttpServletContextFactory(this, getServletContext(), request, request, response) which is a bit different from your use ctx.getBridge().handleRequest()...

See:

RemoteHttpServletContextFactory ctx = new RemoteHttpServletContextFactory(this,
  getServletContext(), request, request, response);

response.setHeader("X_JAVABRIDGE_CONTEXT", ctx.getId());
response.setHeader("Pragma", "no-cache");
response.setHeader("Cache-Control", "no-cache");

try {
  ctx.handleRequests(request.getInputStream(), response.getOutputStream());
} finally {
  ctx.destroy();
}

[dynamodan]

can you confirm that the doGet method works

Yes, the doGet method works. Also, the doPut method doesn't hang when I send rubbish payloads from other web clients with the PUT method. (Advance REST Client was handy for this.) Of course the java bridge didn't know what to do with test messages being sent as the payload and threw another error, but at least Parser.read() wasn't hanging.

have you registered the 'io.soluble.pjb.servlet.ContextLoaderListener' as well?

It might be out of context, I dunno. I'm not using any xml config like that, i.e. web.xml, *.war files or nothing like that, everything is in source code. How would I register that using java statements?

which is a bit different from your use ctx.getBridge().handleRequest()

Yeah I started from that example. The reason stuff is broken out like that is from me trying to sort out exactly where the code execution was hanging. It was a lot messier before I posted that screenshot. ;)

[dynamodan]

UPDATE: embedding Tomcat works just fine, so the problem is somewhere in Jetty. In my maven's pom.xml I added:

        <dependency>
            <groupId>org.apache.tomcat.embed</groupId>
            <artifactId>tomcat-embed-core</artifactId>
            <version>7.0.75</version>
        </dependency>       
        <dependency>
            <groupId>org.apache.tomcat</groupId>
            <artifactId>tomcat-juli</artifactId>
            <version>7.0.75</version>
        </dependency>

And then starting Tomcat with a very, very minimal set of java statements it works fine (well still have to give it some work to do, hah).

public void startTomcat() {
    Tomcat tomcat = new Tomcat();
        tomcat.setPort(8087);
        Context ctx = tomcat.addContext("/", new File(".").getAbsolutePath());
        Tomcat.addServlet(ctx, "jbs", new JavaBridgeServlet());
        ctx.addServletMapping("/*", "jbs");
        try {
            tomcat.start();
            log("started, now waiting for connections...");
            tomcat.getServer().await();
        } catch (Exception e) {
            warning(e.getMessage());
        }
}

[belgattitude]

How would I register that using java statements? (io.soluble.pjb.servlet.ContextLoaderListener)

Not sure how to with Jetty, but I've had to do on it with spring-boot, see here

Eventually look at https://kielczewski.eu/2013/11/using-embedded-jetty-spring-mvc/, there's an example of ContextLoaderListener registration.

---

Update: as you had success with Tomcat, looks the ContextLoaderListener might not be needed... Are you on Windows/Unix, using the latest soluble-japha client for tests ? (php version ?) Sorry I'm might be out of context here... would love to be a little more experienced on the bridge to help but need to start somewhere ;)

[cplerch]

Please show us the code where you setup the defunct embedded Jetty sever. Just adding the servlet and the servlet mapping to the context (as you did with Tomcat) might not be enough for Jetty.

2017-03-02 22:39 GMT+01:00 Sébastien Vanvelthem notifications@github.com:

How would I register that using java statements? (io.soluble.pjb.servlet. ContextLoaderListener)

Not sure how to with Jetty, but I've had to do on it with spring-boot, see here https://github.com/belgattitude/pjb-starter-springboot/blob/master/src/main/java/io/soluble/pssb/Application.java#L63

Eventually look at https://kielczewski.eu/2013/11/using-embedded-jetty- spring-mvc/, there's an example of ContextLoaderListener registration.

Update: as you had success with Tomcat, looks the ContextLoaderListener might not be needed... Are you on Windows/Unix, using the latest soluble-japha client for tests ? (php version ?)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/belgattitude/php-java-bridge/issues/43#issuecomment-283790628, or mute the thread https://github.com/notifications/unsubscribe-auth/AIA12w1m1FYwSKYrRLybiEabQWSs0BGjks5rhzcggaJpZM4MLtpS .

[dynamodan]

I will work out a minimal code base to demonstrate the jetty bug. It might take me a few days.

[cplerch]

@belgattitude

Meanwhile I could commit to develop a quick fix that prevents the internal http server listing the directory index by default. If you want the index you could still call runner.enableDirectoryIndex(). Is this OK for you?

2017-03-03 17:02 GMT+01:00 Dynamo Dan notifications@github.com:

I will work out a minimal code base to demonstrate the jetty bug. It might take me a few days.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/belgattitude/php-java-bridge/issues/43#issuecomment-283993267, or mute the thread https://github.com/notifications/unsubscribe-auth/AIA12_ne04grbpW5fuHD4WUYSukfMRUtks5riDmGgaJpZM4MLtpS .

[belgattitude]

Great chris !

On 03 Mar 2017 5:25 PM, "Christian P. Lerch" notifications@github.com wrote:

@belgattitude

Meanwhile I could commit to develop a quick fix that prevents the internal http server listing the directory index by default. If you want the index you could still call runner.enableDirectoryIndex(). Is this OK for you?

2017-03-03 17:02 GMT+01:00 Dynamo Dan notifications@github.com:

I will work out a minimal code base to demonstrate the jetty bug. It might take me a few days.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/belgattitude/php-java-bridge/issues/43#issuecomment- 283993267, or mute the thread https://github.com/notifications/unsubscribe-auth/AIA12_ ne04grbpW5fuHD4WUYSukfMRUtks5riDmGgaJpZM4MLtpS .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/belgattitude/php-java-bridge/issues/43#issuecomment-283999773, or mute the thread https://github.com/notifications/unsubscribe-auth/AAP21l4rWoXd-tUHy6YlDmv5BdAxial3ks5riD7xgaJpZM4MLtpS .

[belgattitude]

Hey @chris,

I'll plan to release some upstream fixes soon (7.0.1, see #50 )... Especially the bugfix there:

https://github.com/belgattitude/php-java-bridge/commit/4fc1b403fae04171981601aabb1f395359458457?diff=split

Could be nice to include the runner.enabeDirectoryIndex() if it's still ok for you to do ?

Simply push on develop and we'll have an option for @dynamodan

All the best

[cplerch]

Hi Sep, I have already commited the enableDirectoryIndex quick fix on March, 4th. See: https://github.com/belgattitude/php-java-bridge/commit/8e34e2e242417892a6909c6f7c0a334df6a98a69 Best Chris

2017-03-05 20:27 GMT+01:00 Sébastien Vanvelthem notifications@github.com:

Hey @chris https://github.com/chris,

I'll plan to release some upstream fixes soon (7.0.1, see #50 https://github.com/belgattitude/php-java-bridge/pull/50 )... Especially the bugfix there:

4fc1b40?diff=split https://github.com/belgattitude/php-java-bridge/commit/4fc1b403fae04171981601aabb1f395359458457?diff=split

Could be nice to include the runner.enabeDirectoryIndex() if it's still ok for you to do ?

Simply push on develop and we'll have an option for @dynamodan https://github.com/dynamodan

All the best

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/belgattitude/php-java-bridge/issues/43#issuecomment-284253480, or mute the thread https://github.com/notifications/unsubscribe-auth/AIA128ciwuICn44i32_AsqhEHytLfBItks5riwyfgaJpZM4MLtpS .

[belgattitude]

Hi Chris,

My mind was away ;) I'll update the changelog and link the issue. Will be included in 7.0.0.

Thanks a lot.

(Always good to put the issue number in the commit message for reference, like "working on #43")

[belgattitude]

Hi Chris,

for ensuring no bc-break, or too much divergences from the original project.

Can I revert the default behaviour of "enableDirectoryIndex()" to true ?

[belgattitude]

Hey @dynamodan,

Thanks for code snippets, I've set up a recipe document from your examples (we can improve later).

Please use the issue #51 instead for future comment about embedding as this one will be closed soon

(Currently living in the develop branch, under ./docs/recipes_embedding.md)

[cplerch]

Yes, of course. But please have another look at my changes: I also commented out a line which I believe to be a bug (see comments for some reasoning).

2017-03-06 12:14 GMT+01:00 Sébastien Vanvelthem notifications@github.com:

Hi Chris,

for ensuring no bc-break, or too much divergences from the original project.

Can I revert the default behaviour of "enableDirectoryIndex()" to true ?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/belgattitude/php-java-bridge/issues/43#issuecomment-284368900, or mute the thread https://github.com/notifications/unsubscribe-auth/AIA121z3KUwTbTcxGJrZN1dTsUpzVWnuks5ri-qygaJpZM4MLtpS .

[belgattitude]

Looks you always go a step forward ;)

Indeed a 403.. As it look not possible, let's keep it as todo... and hope with the introduction of embedding recipe #51 nobody will use it again.

I'll just put false be default and close. Thanks for your precisions