Bekijk Volledige Versie : Java EJB vraagje met JBoss
Joost Kraaijeveld
18/02/04, 17:55
Hi allemaal,
Is het mogelijk, en zo ja hoe, met behulp van een EJB op de remote server
een bash script op te starten onder het root account?
BVD
Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
e-mail: J.Kraaijeveld@Askesis.nl
web: www.askesis.nl
Daniel Tryba
18/02/04, 20:25
Joost Kraaijeveld <J.Kraaijeveld@askesis.nl> wrote:
> Is het mogelijk, en zo ja hoe, met behulp van een EJB op de remote server
> een bash script op te starten onder het root account?
Ik zou niet inzien waarom dat niet zou kunnen (althans als de
securitymanager van jboss java.lang.Runtime.exec() toestaat). Maar
waarom zou je dat uberhaupt willen? Dit riekt naar een vieze hack.
--
Daniel Tryba
Joost Kraaijeveld
18/02/04, 20:45
> Ik zou niet inzien waarom dat niet zou kunnen (althans als de
> securitymanager van jboss java.lang.Runtime.exec() toestaat).
Hoewel ik e.e.a. van JBoss afweet heb ik hier niets concreets over kunnen
vinden.
> waarom zou je dat uberhaupt willen? Dit riekt naar een vieze hack.
Dit voornamelijk riekt naar een mogelijkheid om een webmin-achtige programma
in Java te maken.
Groeten
Joost
Joost Kraaijeveld <J.Kraaijeveld@Askesis.nl>:
>> waarom zou je dat uberhaupt willen? Dit riekt naar een vieze hack.
>
> Dit voornamelijk riekt naar een mogelijkheid om een webmin-achtige
> programma in Java te maken.
Remote rootlogins toestaan is een veiligsheidsrisico, maar daar ben je
natuurlijk van op de hoogte en zo :)
--
robert
Rene Pijlman
19/02/04, 00:25
Joost Kraaijeveld:
>Dit voornamelijk riekt naar een mogelijkheid om een webmin-achtige programma
>in Java te maken.
Hoe kom je van een "webmin-achtig programma" op "bash scripts"? Bash is
prachtig voor de command line en Q&D-scripts, maar waarom zou je het in
een EJB-applicatie gebruiken?
--
René Pijlman
Wat wil jij leren? http://www.leren.nl
Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> Joost Kraaijeveld:
>>Dit voornamelijk riekt naar een mogelijkheid om een webmin-achtige
>>programma in Java te maken.
>
> Hoe kom je van een "webmin-achtig programma" op "bash scripts"? Bash is
> prachtig voor de command line en Q&D-scripts...
bash is nooit prachtig, maar laten we er geen shellwar van maken ;)
> ...maar waarom zou je het in een EJB-applicatie gebruiken?
Als je geautomatiseerde systeembeheertaken op een *nixdoos wilt uitvoeren
kom je al snel terecht bij shellscripting.
--
robert
Joost Kraaijeveld
19/02/04, 08:15
> Hoe kom je van een "webmin-achtig programma" op "bash scripts"? Bash is
> prachtig voor de command line en Q&D-scripts, maar waarom zou je het in
> een EJB-applicatie gebruiken?
Om commandlinetools op te starten die met die, mits de juiste argumenten
worden meegegeven, doen wat je wil.
Rene Pijlman
19/02/04, 11:45
Joost Kraaijeveld:
>> Hoe kom je van een "webmin-achtig programma" op "bash scripts"? Bash is
>> prachtig voor de command line en Q&D-scripts, maar waarom zou je het in
>> een EJB-applicatie gebruiken?
>Om commandlinetools op te starten die met die, mits de juiste argumenten
>worden meegegeven, doen wat je wil.
De shell _is_ een commandline tool, die doet wat je zegt (soms niet wat je
wilt).
Als je die kunt opstarten, dan kun je ook direct die andere
commandlinetools opstarten :-)
--
René Pijlman
Wat wil jij leren? http://www.leren.nl
Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> Joost Kraaijeveld:
>
>>> Hoe kom je van een "webmin-achtig programma" op "bash scripts"? Bash
>>> is prachtig voor de command line en Q&D-scripts, maar waarom zou je
>>> het in een EJB-applicatie gebruiken?
>
>>Om commandlinetools op te starten die met die, mits de juiste argumenten
>>worden meegegeven, doen wat je wil.
>
> De shell _is_ een commandline tool, die doet wat je zegt (soms niet wat
> je wilt).
>
> Als je die kunt opstarten, dan kun je ook direct die andere
> commandlinetools opstarten :-)
Toch lijkt me het grouperen van aanroepen van externe tools in één script
een stukje handiger dan die aanroepen te hardcoden in een Java-applicatie.
--
robert
Joost Kraaijeveld
19/02/04, 11:55
> De shell _is_ een commandline tool, die doet wat je zegt (soms niet wat je
> wilt).
>
> Als je die kunt opstarten, dan kun je ook direct die andere
> commandlinetools opstarten :-)
Ah ja, natuurlijk. Ik noemde de shell voornamelijk als voorbeeld van de
commandline tool. Ik heb een hele zut aan scripts die al wrappers zijn om
andere commandline tools. Vandaar.
Weet jij een methode om met behulp van JBoss externe programma's op te
starten op de remote server?
Groeten
Joost
Rene Pijlman
19/02/04, 11:55
robert:
>Toch lijkt me het grouperen van aanroepen van externe tools in één script
>een stukje handiger dan die aanroepen te hardcoden in een Java-applicatie.
Que? Waarom is programmeren in Java "hardcoden" (wat is dat eigenlijk?) en
programmeren in script "handiger" ("softcoden")?
Ik zou juist zo snel mogelijk van die vage shell scripts afwillen en het
volledig in een nette programmeertaal als Java programmeren. Denk aan de
voordelen van exception handling enzo.
Of dat in het abstracte platform-onafhankelijke Java een beetje gaat
lukken weet ik niet, maar met Python zou ik zeker die benadering kiezen.
--
René Pijlman
Wat wil jij leren? http://www.leren.nl
Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> robert:
>
>>Toch lijkt me het grouperen van aanroepen van externe tools in één
>>script een stukje handiger dan die aanroepen te hardcoden in een
>>Java-applicatie.
>
> Que? Waarom is programmeren in Java "hardcoden" (wat is dat eigenlijk?)
> en programmeren in script "handiger" ("softcoden")?
Zo moeilijk is het toch niet om te begrijpen? Stel dat je een taak wilt
uitvoeren die er als volgt uit ziet:
programma1 > bestand1
programma2 < bestand1 > bestand2
programma3 < bestand2 | programma4 > bestand3
Als je dat in Java wilt coden, prima, ga je gang (maar leuk lijkt het me
met die redirects en pipes niet...).
Op een later tijdstip wil je echter de uitvoer van programma4 pipen door
programma5. Dat houdt in dat je je Java source kunt gaan aanpassen,
programma5 in de pipeline moet opnemen, je code opnieuw moet compileren, en
je hele applicatie opnieuw kunt opstarten omdat er een aangepaste .class
file in je .jar zit.
Of je roept vanuit je Javacode één shellscript aan, en past on-the-fly dat
script aan als er aanpassingen gemaakt moeten worden aan de pipeline.
Ik weet wel waar ik voor zou kiezen.
> Ik zou juist zo snel mogelijk van die vage shell scripts afwillen en het
> volledig in een nette programmeertaal als Java programmeren. Denk aan de
> voordelen van exception handling enzo.
>
> Of dat in het abstracte platform-onafhankelijke Java een beetje gaat
> lukken weet ik niet, maar met Python zou ik zeker die benadering kiezen.
Het gaat om het aanroepen van _externe_ programma's. Om daar Python, als
mislukte shellinterpreter, voor te gebruiken is je goed recht, maar het
lijkt me weinig nuttig.
Je kan natuurlijk de functionaliteiten van die externe programma's gaan
implementeren in Python/Java/..., maar zoiets is vaak maar in beperkte mate
voordeliger dan een aanroep van een extern programma.
--
robert
Rene Pijlman
19/02/04, 12:55
robert:
>Rene Pijlman:
> > robert:
> >
> >>Toch lijkt me het grouperen van aanroepen van externe tools in één
> >>script een stukje handiger dan die aanroepen te hardcoden in een
> >>Java-applicatie.
> >
> > Que? Waarom is programmeren in Java "hardcoden" (wat is dat eigenlijk?)
> > en programmeren in script "handiger" ("softcoden")?
>
>Zo moeilijk is het toch niet om te begrijpen?
Er was nog niets om te begrijpen, behalve een niet-onderbouwde bewering
met een onduidelijke betekenis :-)
>Stel dat je een taak wilt uitvoeren die er als volgt uit ziet:
>
> programma1 > bestand1
> programma2 < bestand1 > bestand2
Da's gewoon file I/O. Dat is toch niets bijzonders in Java? Waarom zou je
dat kleine stukje van een Java-programma opeens in een externe shell gaan
doen?
> programma3 < bestand2 | programma4 > bestand3
>
>Als je dat in Java wilt coden, prima, ga je gang (maar leuk lijkt het me
>met die redirects en pipes niet...).
Waar komt toch het idee vandaan dat je functionaliteit moet implementeren
door text stream-producerende en -consumerende programma's aan elkaar te
knopen?
Ontwerp toch een normaal OO-programma met classes, exception handling
etc., dat functioneel hetzelfde doet.
>Op een later tijdstip wil je echter de uitvoer van programma4 pipen door
>programma5. Dat houdt in dat je je Java source kunt gaan aanpassen,
>programma5 in de pipeline moet opnemen, je code opnieuw moet compileren, en
>je hele applicatie opnieuw kunt opstarten omdat er een aangepaste .class
>file in je .jar zit.
Ja, zo werkt Java-programmeren nu eenmaal. Dat geldt bij alle wijzigingen
van het algoritme.
>Of je roept vanuit je Javacode één shellscript aan, en past on-the-fly dat
>script aan als er aanpassingen gemaakt moeten worden aan de pipeline.
>
>Ik weet wel waar ik voor zou kiezen.
Ik ook: Python :-) Dat combineert OO-programmeren met de eenvoud van
shell-scripts.
--
René Pijlman
Wat wil jij leren? http://www.leren.nl
Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> robert:
>
>>Stel dat je een taak wilt uitvoeren die er als volgt uit ziet:
>>
>> programma1 > bestand1
>> programma2 < bestand1 > bestand2
>
> Da's gewoon file I/O. Dat is toch niets bijzonders in Java? Waarom zou
> je dat kleine stukje van een Java-programma opeens in een externe shell
> gaan doen?
>
>> programma3 < bestand2 | programma4 > bestand3
>>
>>Als je dat in Java wilt coden, prima, ga je gang (maar leuk lijkt het me
>>met die redirects en pipes niet...).
>
> Waar komt toch het idee vandaan dat je functionaliteit moet
> implementeren door text stream-producerende en -consumerende programma's
> aan elkaar te knopen?
Ik noem een voorbeeld dat niet geheel ondenkbaar is in een applicatie
waarmee je systeembeheer wilt uitvoeren. Logs parsen en interessante
onderdelen van die logs archiveren, om maar iets te noemen.
> Ontwerp toch een normaal OO-programma met classes, exception handling
> etc., dat functioneel hetzelfde doet.
gzip zelf bouwen, tar zelf bouwen, grep zelf bouwen, sed zelf bouwen, tr
zelf bouwen, enzovoort. Plus dat ik niet verwacht dat jij in Java een
grep kunt bouwen die sneller is dan de commandlineversie; en met mega-GB
logfiles is snelheid toch vaak echt wel een vereiste.
--
robert
Rene Pijlman
19/02/04, 14:35
robert:
>Rene Pijlman:
> > Ontwerp toch een normaal OO-programma met classes, exception handling
> > etc., dat functioneel hetzelfde doet.
>
>gzip zelf bouwen, tar zelf bouwen, grep zelf bouwen, sed zelf bouwen, tr
>zelf bouwen, enzovoort.
Nu haal je twee dingen door elkaar:
1) Programmeermodel Java vs. shell script
2) Hergebruiken vs. zelf bouwen
Ik had het over punt 1.
>Plus dat ik niet verwacht dat jij in Java een grep kunt bouwen die sneller is
>dan de commandlineversie; en met mega-GB logfiles is snelheid toch vaak echt
>wel een vereiste.
Nu haal je twee dingen door elkaar:
1) Programmeermodel Java vs. shell script
2) De performance van C vs. die van Java.
Als performance belangrijk is dan zou ik zeggen: implementeer de code in C
en gebruik JNI.
Het wordt tijd dat we shell scripts naar het computermuseum verbannen en
dat we normale OO-talen, APIs en componentarchitecturen gaan gebruiken om
bouwstenen aan elkaar te knopen.
Shell scripts zijn een idee uit de jaren 80, toen nog niemand
daadwerkelijk gebruik maakte van OO-talen en componentarchitecturen.
Hé, is J2EE/EJB trouwens niet een componentarchitectuur? Gebruik het dan
zo!
--
René Pijlman
Wat wil jij leren? http://www.leren.nl
Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> robert:
>>Rene Pijlman:
>> > Ontwerp toch een normaal OO-programma met classes, exception handling
>> > etc., dat functioneel hetzelfde doet.
>>
>>gzip zelf bouwen, tar zelf bouwen, grep zelf bouwen, sed zelf bouwen, tr
>>zelf bouwen, enzovoort.
>
> Nu haal je twee dingen door elkaar:
>
> 1) Programmeermodel Java vs. shell script
>
> 2) Hergebruiken vs. zelf bouwen
>
> Ik had het over punt 1.
Jij hebt het over dezelfde functionaliteit, oftewel 'hergebruiken versus
zelf bouwen'.
>>Plus dat ik niet verwacht dat jij in Java een grep kunt bouwen die
>>sneller is dan de commandlineversie; en met mega-GB logfiles is snelheid
>>toch vaak echt wel een vereiste.
>
> Nu haal je twee dingen door elkaar:
>
> 1) Programmeermodel Java vs. shell script
>
> 2) De performance van C vs. die van Java.
>
> Als performance belangrijk is dan zou ik zeggen: implementeer de code in
> C en gebruik JNI.
Puntje 2 van hierboven, dus: hergebruiken versus zelf bouwen. Daarnaast is
JNI voor lokaal gebruik wellicht een oplossing, maar het remote aanroepen
van een systeembeheertaak _die als pipeline moet worden uitgevoerd_ is geen
werkbare optie, tenzij je op de remote machine ook meteen je hele Java
runtime wilt gaan draaien (en dat voor alleen wat systeembeheertaken!).
> Het wordt tijd dat we shell scripts naar het computermuseum verbannen en
> dat we normale OO-talen, APIs en componentarchitecturen gaan gebruiken
> om bouwstenen aan elkaar te knopen.
Shellscripting is vooralsnog noodzakelijke glue tussen componenten die
ervan uitgaan dat je ze vanaf een commandline draait.
Jij hebt het over applicatieontwikkeling, en ik heb mezelf in deze gehele
thread nog niet zien roepen dat shellscripts daar de perfecte omgeving voor
zijn...
> Shell scripts zijn een idee uit de jaren 80, toen nog niemand
> daadwerkelijk gebruik maakte van OO-talen en componentarchitecturen.
Nu haal je twee dingen door elkaar:
1) programmeren
2) batchprocessing
--
robert
Jaap-Andre de Hoop
19/02/04, 15:35
In article <nde930t7178s3qjn17jl2q62k5c3uorjl7@4ax.com>, Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>Het wordt tijd dat we shell scripts naar het computermuseum verbannen en
>dat we normale OO-talen, APIs en componentarchitecturen gaan gebruiken om
>bouwstenen aan elkaar te knopen.
>
>Shell scripts zijn een idee uit de jaren 80, toen nog niemand
>daadwerkelijk gebruik maakte van OO-talen en componentarchitecturen.
mmmm leuke discussie.
Vind het wel een leuk idee uit de jaren '80 ;-)
als leek op java: Hoe zit het met schedulingen (crontab) is dat mogelijk?
of mis ik hier helemaal waar het over gaat ;-)
Jaap-Andre
Rene Pijlman
19/02/04, 15:55
Jaap-Andre de Hoop:
>mmmm leuke discussie.
Inderdaad. Maar wie heeft er nu gewonnen? :-)
--
René Pijlman
Wat wil jij leren? http://www.leren.nl
NNTP-Posting-Host: cust.91.90.adsl.cistron.nl
X-Trace: ncc1701.cistron.net 1077202426 20328 195.64.91.90 (19 Feb 2004 14:53:46 GMT)
X-Complaints-To: abuse@cistron.nl
NNTP-Posting-Date: Thu, 19 Feb 2004 14:53:46 +0000 (UTC)
User-Agent: slrn/0.9.7.4 (Darwin)
Xref: nl-news.euro.net nl.internet.www.server-side:33960
Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> Jaap-Andre de Hoop:
>>mmmm leuke discussie.
>
> Inderdaad. Maar wie heeft er nu gewonnen? :-)
;)
--
robert
Daniel Tryba
19/02/04, 16:55
Joost Kraaijeveld <J.Kraaijeveld@askesis.nl> wrote:
> Die zich nog steeds afvraagt hoe ie met behulp van een servlet of ejb een
> programma remote kan opstarten...
RMI?
--
Daniel Tryba
Jaap-Andre de Hoop
21/02/04, 06:55
X-Newsreader: News Xpress 2.01
Date: Sat, 21 Feb 2004 05:50:44 GMT
Lines: 11
Message-ID: <4036f1b5$0$128$e4fe514c@dreader6.news.xs4all.nl>
NNTP-Posting-Host: 80.126.118.72
X-Trace: 1077342645 dreader6.news.xs4all.nl 128 [::ffff:80.126.118.72]:10606
Xref: nl-news.euro.net nl.internet.www.server-side:34004
In article <5cj9309sh2glu1r6ddcc2s4oi8ohpstb92@4ax.com>, Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>Jaap-Andre de Hoop:
>>mmmm leuke discussie.
>
>Inderdaad. Maar wie heeft er nu gewonnen? :-)
>
tsja aangezien er naar mijn opmerking over scheduling geen verdere bijdrage is
geweest zou ik bijna zeggen dat ik de winnaar ben ;-)
Jaap-Andre