Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #28477 > unrolled thread

application server, just without the "web" part...

Back to article view | Back to comp.lang.java.programmer

Contents

  application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-05-14 19:16 +0000
    Re: application server, just without the "web" part... markspace <markspace@nospam.nospam> - 2014-05-14 13:23 -0700
    Re: application server, just without the "web" part... leif.roar@invalid.com (Leif Roar Moldskred) - 2014-05-14 16:57 -0500
      Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-05-15 14:16 +0000
    Re: application server, just without the "web" part... Arne Vajhøj <arne@vajhoej.dk> - 2014-05-14 19:46 -0400
      Re: application server, just without the "web" part... Joerg Meier <joergmmeier@arcor.de> - 2014-05-15 12:25 +0200
        Re: application server, just without the "web" part... Arne Vajhøj <arne@vajhoej.dk> - 2014-05-16 21:06 -0400
      Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-05-15 14:32 +0000
        Re: application server, just without the "web" part... Arne Vajhøj <arne@vajhoej.dk> - 2014-05-16 21:10 -0400
          Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-05-17 09:46 +0000
            Re: application server, just without the "web" part... Jeff Higgins <jeff@invalid.invalid> - 2014-05-17 07:42 -0400
              Re: application server, just without the "web" part... Jeff Higgins <jeff@invalid.invalid> - 2014-05-17 08:52 -0400
                Re: application server, just without the "web" part... Jeff Higgins <jeff@invalid.invalid> - 2014-05-17 09:07 -0400
                  Re: application server, just without the "web" part... Jeff Higgins <jeff@invalid.invalid> - 2014-05-17 09:12 -0400
                    Re: application server, just without the "web" part... Luuk <luuk@invalid.lan> - 2014-05-17 15:35 +0200
                      Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-06-16 18:21 +0000
          Re: application server, just without the "web" part... "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-05-17 10:49 +0100
    Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-05-15 14:10 +0000
    Re: application server, just without the "web" part... "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-05-17 11:00 +0100
      Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-03 17:51 +0000
        Re: application server, just without the "web" part... Martin Gregorie <martin@address-in-sig.invalid> - 2014-09-03 18:29 +0000
          Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-03 18:43 +0000
          Re: application server, just without the "web" part... Martin Gregorie <martin@address-in-sig.invalid> - 2014-09-03 19:43 +0000
            Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-04 07:36 +0000
              Re: application server, just without the "web" part... Martin Gregorie <martin@address-in-sig.invalid> - 2014-09-04 12:13 +0000
                Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-05 00:43 +0000
                  Re: application server, just without the "web" part... Martin Gregorie <martin@address-in-sig.invalid> - 2014-09-05 09:14 +0000
                    Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-05 10:43 +0000
                      Re: application server, just without the "web" part... Martin Gregorie <martin@address-in-sig.invalid> - 2014-09-05 21:45 +0000
    Re: application server, just without the "web" part... Roedy Green <see_website@mindprod.com.invalid> - 2014-06-20 08:09 -0700
    Re: application server, just without the "web" part... Roedy Green <see_website@mindprod.com.invalid> - 2014-06-20 08:13 -0700
      Re: application server, just without the "web" part... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-03 17:33 +0000

Page 1 of 2  [1] 2  Next page →

#28477 — application server, just without the "web" part...

Essentially my application is a couple of separate command-line
utilities, called from users with shell-access (or from unix
shell scripts).

Startup-time still isn't exactly Java's strong point, and often
enough in my situation the startup time is by far the "longest
pole in the tent".
Adding option -Xshareclasses improved things, but not enough.

I'd like to consider some kind of application server, that would 
run the actual java-code of any number of jobs (of one user) in one
jvm, and with an "interface", that would only allow that one user to
start new jobs.

Does something like this already exist?

PS: the actual jobs need to be in Java, because they need certain
  Java-libraries for their work. The server would know all relevant
  classes beforehand.

[toc] | [next] | [standalone]

#28478

On 5/14/2014 12:16 PM, Andreas Leitgeb wrote:
> Does something like this already exist?


  ClassName.main( "arguments" );

?

After you add the Jar file to your app server's classpath, of course.

Output could be a little weird, depending on how your sever handles 
stdout.  Most of the output will likely end up in the log file.

Not sure what else...

[toc] | [prev] | [next] | [standalone]

#28481

Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> wrote:
> Essentially my application is a couple of separate command-line
> utilities, called from users with shell-access (or from unix
> shell scripts).
> 
> Startup-time still isn't exactly Java's strong point, and often
> enough in my situation the startup time is by far the "longest
> pole in the tent".
> Adding option -Xshareclasses improved things, but not enough.
> 
> I'd like to consider some kind of application server, that would 
> run the actual java-code of any number of jobs (of one user) in one
> jvm, and with an "interface", that would only allow that one user to
> start new jobs.
> 
> Does something like this already exist?
> 
> PS: the actual jobs need to be in Java, because they need certain
>  Java-libraries for their work. The server would know all relevant
>  classes beforehand.
> 

One possible solution is to have a program that scans a given
directory (say, ~/.javaTriggers) which only that user has write access
to. Upon encountering a new trigger file in that directory, the main
programs executes one of the utilities. The trigger files contains
information about which utility to run and, possibly, with which
arguments.

Make a couple of bash aliases or shell scripts to easily create the
correct trigger files in the target directory.

Start the main program and keep it running in the background, and let
the user interact with it through the aliases / shell scripts.

If the utilities need to write output to stdOut, it gets a little
trickier, but you can finagle your way around that too.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#28488

Leif Roar Moldskred <leif.roar@invalid.com> wrote:
> Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> wrote:
>> I'd like to consider some kind of application server, that would 
>> run the actual java-code of any number of jobs (of one user) in one
>> jvm, and with an "interface", that would only allow that one user to
>> start new jobs.
>
> One possible solution is to have a program that scans a given
> directory (say, ~/.javaTriggers) which only that user has write access
> to.

I hoped for unix domain sockets or named pipes, if the server can
handle those.

> If the utilities need to write output to stdOut, it gets a little
> trickier, but you can finagle your way around that too.

I'll probably need to multiplex it into the communication channel...

I hoped I wouldn't need to start from zero, though.

Thanks, anyway.

[toc] | [prev] | [next] | [standalone]

#28482

On 5/14/2014 3:16 PM, Andreas Leitgeb wrote:
> Essentially my application is a couple of separate command-line
> utilities, called from users with shell-access (or from unix
> shell scripts).
>
> Startup-time still isn't exactly Java's strong point, and often
> enough in my situation the startup time is by far the "longest
> pole in the tent".
> Adding option -Xshareclasses improved things, but not enough.
>
> I'd like to consider some kind of application server, that would
> run the actual java-code of any number of jobs (of one user) in one
> jvm, and with an "interface", that would only allow that one user to
> start new jobs.
>
> Does something like this already exist?
>
> PS: the actual jobs need to be in Java, because they need certain
>    Java-libraries for their work. The server would know all relevant
>    classes beforehand.

Why not run beanshell and run the classes from that.

$ java -cp wherebshis:whereyourstuffis bsh.Interpreter
bsh% somepackage.SomeClass.main(null);
bsh% somepackage.SomeOtherClass.main(null);

Arne

[toc] | [prev] | [next] | [standalone]

#28486

On Wed, 14 May 2014 19:46:42 -0400, Arne Vajhøj wrote:

> bsh% somepackage.SomeClass.main(null);
> bsh% somepackage.SomeOtherClass.main(null);

It seems to me that would break the vast majority of Java applications,
which tend to start with something like "if (args.length > 0) ...".

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#28504

On 5/15/2014 6:25 AM, Joerg Meier wrote:
> On Wed, 14 May 2014 19:46:42 -0400, Arne Vajhøj wrote:
>
>> bsh% somepackage.SomeClass.main(null);
>> bsh% somepackage.SomeOtherClass.main(null);
>
> It seems to me that would break the vast majority of Java applications,
> which tend to start with something like "if (args.length > 0) ...".

Yeah. new String[0] would be a bit nicer than null.

Arne

[toc] | [prev] | [next] | [standalone]

#28489

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 5/14/2014 3:16 PM, Andreas Leitgeb wrote:
>> Startup-time still isn't exactly Java's strong point,...
>> I'd like to consider some kind of application server, that would
>> run the actual java-code of any number of jobs (of one user) in one
>> jvm, and with an "interface", that would only allow that one user to
>> start new jobs.

> Why not run beanshell and run the classes from that.
> $ java -cp wherebshis:whereyourstuffis bsh.Interpreter
> bsh% somepackage.SomeClass.main(null);
> bsh% somepackage.SomeOtherClass.main(null);

I googled and found http://www.beanshell.org/javadoc/bsh/Interpreter.html
I'm not yet sure if this will help me with separating multiple
jobs running at the same time, but it might help me in my process
of incrementally implementing what I need.

Thanks!

PS: for the other F'up: of course I would not pass null for args...
  I'd definititely have something sensible to pass instead.

[toc] | [prev] | [next] | [standalone]

#28505

On 5/15/2014 10:32 AM, Andreas Leitgeb wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 5/14/2014 3:16 PM, Andreas Leitgeb wrote:
>>> Startup-time still isn't exactly Java's strong point,...
>>> I'd like to consider some kind of application server, that would
>>> run the actual java-code of any number of jobs (of one user) in one
>>> jvm, and with an "interface", that would only allow that one user to
>>> start new jobs.
>
>> Why not run beanshell and run the classes from that.
>> $ java -cp wherebshis:whereyourstuffis bsh.Interpreter
>> bsh% somepackage.SomeClass.main(null);
>> bsh% somepackage.SomeOtherClass.main(null);
>
> I googled and found http://www.beanshell.org/javadoc/bsh/Interpreter.html
> I'm not yet sure if this will help me with separating multiple
> jobs running at the same time, but it might help me in my process
> of incrementally implementing what I need.

Now I am confused.

You worry about the JVM startup time - implying that it is
somewhat significant compared to job run time.

But you want to run multiple jobs in parallel - implying that
jobs run for a long time.

Am I missing something?

Arne

[toc] | [prev] | [next] | [standalone]

#28511

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 5/15/2014 10:32 AM, Andreas Leitgeb wrote:
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 5/14/2014 3:16 PM, Andreas Leitgeb wrote:
>>>> Startup-time still isn't exactly Java's strong point,...
>>>> I'd like to consider some kind of application server, that would
>>>> run the actual java-code of any number of jobs (of one user) in one
>>>> jvm, and with an "interface", that would only allow that one user to
>>>> start new jobs.
>>> Why not run beanshell and run the classes from that.
>>> $ java -cp wherebshis:whereyourstuffis bsh.Interpreter
>>> bsh% somepackage.SomeClass.main(null);
>>> bsh% somepackage.SomeOtherClass.main(null);
>> I googled and found http://www.beanshell.org/javadoc/bsh/Interpreter.html
>> I'm not yet sure if this will help me with separating multiple
>> jobs running at the same time, but it might help me in my process
>> of incrementally implementing what I need.
>
> Now I am confused.
>
> You worry about the JVM startup time - implying that it is
> somewhat significant compared to job run time.
> But you want to run multiple jobs in parallel - implying that
> jobs run for a long time.

There are short jobs, long jobs eventually spawning short
jobs while running.

In principle I could distinguish them beforehand and only 
use bean-shell for the short ones (running them serialized).

However, I'm not sure if I can correctly predict it in 
all cases, so I'm looking for a general solution that 
won't require me to distinguish.

[toc] | [prev] | [next] | [standalone]

#28518

On 05/17/2014 05:46 AM, Andreas Leitgeb wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 5/15/2014 10:32 AM, Andreas Leitgeb wrote:
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 5/14/2014 3:16 PM, Andreas Leitgeb wrote:
>>>>> Startup-time still isn't exactly Java's strong point,...
>>>>> I'd like to consider some kind of application server, that would
>>>>> run the actual java-code of any number of jobs (of one user) in one
>>>>> jvm, and with an "interface", that would only allow that one user to
>>>>> start new jobs.
>>>> Why not run beanshell and run the classes from that.
>>>> $ java -cp wherebshis:whereyourstuffis bsh.Interpreter
>>>> bsh% somepackage.SomeClass.main(null);
>>>> bsh% somepackage.SomeOtherClass.main(null);
>>> I googled and found http://www.beanshell.org/javadoc/bsh/Interpreter.html
>>> I'm not yet sure if this will help me with separating multiple
>>> jobs running at the same time, but it might help me in my process
>>> of incrementally implementing what I need.
>>
>> Now I am confused.
>>
>> You worry about the JVM startup time - implying that it is
>> somewhat significant compared to job run time.
>> But you want to run multiple jobs in parallel - implying that
>> jobs run for a long time.
>
> There are short jobs, long jobs eventually spawning short
> jobs while running.
>
> In principle I could distinguish them beforehand and only
> use bean-shell for the short ones (running them serialized).
>
> However, I'm not sure if I can correctly predict it in
> all cases, so I'm looking for a general solution that
> won't require me to distinguish.
>

It's starting to sound like OSGI to me.
OSGI Standard Services
<http://en.wikipedia.org/wiki/OSGi#Services>

Or even a Business Process Management platform | framework

[toc] | [prev] | [next] | [standalone]

#28520

On 05/17/2014 07:42 AM, Jeff Higgins wrote:
>
> It's starting to sound like OSGI to me.

The Apache Karaf Service Wrapper
<http://karaf.apache.org/manual/latest/users-guide/wrapper.html>

[toc] | [prev] | [next] | [standalone]

#28521

On 05/17/2014 08:52 AM, Jeff Higgins wrote:
> On 05/17/2014 07:42 AM, Jeff Higgins wrote:
>>
>> It's starting to sound like OSGI to me.
>
> The Apache Karaf Service Wrapper
> <http://karaf.apache.org/manual/latest/users-guide/wrapper.html>
>
Karaf Instances
<http://karaf.apache.org/manual/latest/users-guide/instances.html>

[toc] | [prev] | [next] | [standalone]

#28522

On 05/17/2014 09:07 AM, Jeff Higgins wrote:
> On 05/17/2014 08:52 AM, Jeff Higgins wrote:
>> On 05/17/2014 07:42 AM, Jeff Higgins wrote:
>>>
>>> It's starting to sound like OSGI to me.
>>
>> The Apache Karaf Service Wrapper
>> <http://karaf.apache.org/manual/latest/users-guide/wrapper.html>
>>
> Karaf Instances
> <http://karaf.apache.org/manual/latest/users-guide/instances.html>
>
Karaf Realms
<http://karaf.apache.org/manual/latest/users-guide/security.html>

[toc] | [prev] | [next] | [standalone]

#28524

On 17-5-2014 15:12, Jeff Higgins wrote:
> On 05/17/2014 09:07 AM, Jeff Higgins wrote:
>> On 05/17/2014 08:52 AM, Jeff Higgins wrote:
>>> On 05/17/2014 07:42 AM, Jeff Higgins wrote:
>>>>
>>>> It's starting to sound like OSGI to me.
>>>
>>> The Apache Karaf Service Wrapper
>>> <http://karaf.apache.org/manual/latest/users-guide/wrapper.html>
>>>
>> Karaf Instances
>> <http://karaf.apache.org/manual/latest/users-guide/instances.html>
>>
> Karaf Realms
> <http://karaf.apache.org/manual/latest/users-guide/security.html>
>
>

just the complete docs:
http://karaf.apache.org/manual/latest/users-guide/

;-)

[toc] | [prev] | [next] | [standalone]

#28759

Luuk <luuk@invalid.lan> wrote:
> On 17-5-2014 15:12, Jeff Higgins wrote:
>> On 05/17/2014 09:07 AM, Jeff Higgins wrote:
>>> On 05/17/2014 08:52 AM, Jeff Higgins wrote:
>>>> On 05/17/2014 07:42 AM, Jeff Higgins wrote:
>>>>> It's starting to sound like OSGI to me.
>>>> The Apache Karaf Service Wrapper
>>>> <http://karaf.apache.org/manual/latest/users-guide/wrapper.html>
>>> Karaf Instances
>>> <http://karaf.apache.org/manual/latest/users-guide/instances.html>
>> Karaf Realms
>> <http://karaf.apache.org/manual/latest/users-guide/security.html>
> just the complete docs:
> http://karaf.apache.org/manual/latest/users-guide/
> ;-)

Thanks for the cascade of Karaf links :-)

It's not quite what I was looking for, and I saw, that I have to
refine my requirements until I really know what I need. As it seems,
an "application server" is much more than what I need, as it also
has the concept of deploying and undeploying code dynamically.

I'll probably only need to deal with unix domain sockets (not 
internet sockets) for starting applications and interacting with
them, and I'll need to learn how to deal with classloaders, taking
care not to accidentally load certain classes too early (thus into
the system classloader).  I could probably learn that from karaf
but I expect to learn it easier somewhere else.

[toc] | [prev] | [next] | [standalone]

#28512

Arne Vajhøj wrote:

> You worry about the JVM startup time - implying that it is
> somewhat significant compared to job run time.
>
> But you want to run multiple jobs in parallel - implying that
> jobs run for a long time.

I presume that the reason for wanting parallel is to avoid constraining the 
end-users who may want to fire off "jobs" at roughly the same time.

If so then that /doesn't/ imply that the jobs themselves must execute in 
parallel -- there could instead be a (parallel) queuing mechanism inside the 
server.

    -- chris 

[toc] | [prev] | [next] | [standalone]

#28487

Ok, I noticed from the replies that my posting was apparently
unclear in ways I didn't anticipate...

First of all, the "server" was meant as a process on the same
host, not as a separate machine.

Second, The server is supposed to handle multiple processes in
parallel (as threads), separating them (and each's static fields)
by use of separate classloaders.  (I thought that would be implicit
by referring to "application server", but obviously it wasn't)

Thanks anyway for the answers so far.

PS: I already caught the drift, though, that what I need is a
     bit further off mainstream than I feared it would be.


Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> wrote:
> Essentially my application is a couple of separate command-line
> utilities, called from users with shell-access (or from unix
> shell scripts).
>
> Startup-time still isn't exactly Java's strong point, and often
> enough in my situation the startup time is by far the "longest
> pole in the tent".
> Adding option -Xshareclasses improved things, but not enough.
>
> I'd like to consider some kind of application server, that would 
> run the actual java-code of any number of jobs (of one user) in one
> jvm, and with an "interface", that would only allow that one user to
> start new jobs.
>
> Does something like this already exist?
>
> PS: the actual jobs need to be in Java, because they need certain
>   Java-libraries for their work. The server would know all relevant
>   classes beforehand.
>

[toc] | [prev] | [next] | [standalone]

#28513

Andreas Leitgeb wrote:

> I'd like to consider some kind of application server, that would
> run the actual java-code of any number of jobs (of one user) in one
> jvm, and with an "interface", that would only allow that one user to
> start new jobs.
>
> Does something like this already exist?

What is the sticking-point here ?

Is it the server (or server framework) or the application-security (only 
designated users permitted) that you'd like to find pre-packaged solution for ?

If it's the server, then probably some small web-server framework (does 
Pico-container still exist) would do the job.  But, personally, I'd expect that 
I could code the server up myself in much less time than it would take to 
research server frameworks, find a small-but-healthy one, and learn how to use 
it.

If it's the restriction part that's bothersome, then that's harder.  If you 
want to restrict access to the service to only certain users, then it really 
depends on how /much/ you need that restriction.  At the simplest level, you 
just don't tell anyone about the service unless they need to use it (port name, 
protocol definition etc).  Or you could use simple encryption.  Or you could 
use more complex asymmetric encryption.  But if your needs come anywhere close 
to that, then code-it-yourself becomes a mug's game.  I'd be inclined (in the 
absence of more info) to use SSL/TSL with mandatory client certificates.

Then code the client in some handy fast-starting scripting language.  Or -- in 
fact -- almost any language (except Java ;-).

(Of course, a server framework would probably be able to handle the SSL/TLS 
too, so it might hit two stone with one bird for you.  I can't recommend a 
lightweight framework that supports TLS and has a short learning curve because 
I don't know of one -- but they may exist in large numbers that I don't know 
about)

    -- chris 

[toc] | [prev] | [next] | [standalone]

#29894

Chris Uppal <chris.uppal@metagnostic.REMOVE-THIS.org> wrote:
> Andreas Leitgeb wrote:
>> I'd like to consider some kind of application server, that would
>> run the actual java-code of any number of jobs (of one user) in one
>> jvm, and with an "interface", that would only allow that one user to
>> start new jobs.
> What is the sticking-point here ?

Some time (and another thread about classloading) have passed since this one.
I took a while to understand what I really need.

> Is it the server (or server framework) or the application-security (only 
> designated users permitted) that you'd like to find pre-packaged solution for ?

Meanwhile that's the remaining part of my problem. The authorization should not
be part of the protocol, but some local "challenge", that only a particular user
on the same machine can do. E.g. write to an appropriately set up named pipe 
or unix domain socket.  Unfortunately, Java doesn't seem to support unix domain
sockets without JNI, and named pipes have their own bag of downsides.  See new
thread "java unix domain sockets ..."

> Then code the client in some handy fast-starting scripting language.  Or -- in 
> fact -- almost any language (except Java ;-).

I do have my scripting language of choice, which will likely do the client-part.


The other original part of my problem was working with a ClassLoader.
I can proudly say now, that I got rid of almost all the static mutables
and the remaining ones are stored behind a single ThreadLocal instance.
I no longer need a custom ClassLoader.  Thanks to all who asserted that
not-needing a custom ClassLoader is the real goal.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web