Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

accessing EJB from perl

by abhishes (Friar)
on Oct 21, 2002 at 09:57 UTC ( [id://206802]=perlquestion: print w/replies, xml ) Need Help??

abhishes has asked for the wisdom of the Perl Monks concerning the following question:

Hello All,

Is it possible to access an EJB from perl? this would require looking up the jndi and obtaining the remote interface of the ejb and then making a call to it.

If so I can develop a test harness for my application which uses ejbs... rather than write test client in java.


Replies are listed 'Best First'.
Re: accessing EJB from perl
by ignatz (Vicar) on Oct 21, 2002 at 11:39 UTC
    This question triggered my spidy senses. While the hacker in me can find a perverse pleasure in trying to spoof the object needed to get access to an EJB application server as a remote user, I must say that this sounds like a bad idea and a waste of time. (Oooo look at me!!! I'm Sun Certified! Watch me do my Java Certified happy dance. La la la....) Luckily, my hacking skills aren't good enough to even try to go down that path. Even building some sort of SOAP cluge isn't going to give you access to an EJB's internal local and local home methods. I, personally, don't like the idea of building a test suite that only deals with an object's public face.

    Luckily, there is JUnit, which is a wonderful set of testing libraries for Java. It's so cool it's even been ported to Perl.

Re: accessing EJB from perl
by lachoy (Parson) on Oct 21, 2002 at 12:51 UTC

    ignatz is correct, it's best to do your testing with native code. You wind up running into too many barriers. Since JUnit is easy to use and darned near ubiquitous there aren't many excused for not using it. (You might check out Cactus which, combined with JUnit, will give you in-container testing.)

    ...that said: if you have web services hooked up, you can probably test your processes (Session Beans) using the SOAP::Lite interface.

    M-x auto-bs-mode

Re: accessing EJB from perl
by perrin (Chancellor) on Oct 21, 2002 at 14:03 UTC
    What's the matter, is your Perl code running too fast? You need to tie some EJB weights around its ankles?

    Well, you can. Resin provides XML access to EJBs. It should work.

      > It should work.

      Sure... motions for the guards
      that makes perfect sense... unzips strait jacket...
      use Perl to generate XML EBJ test requests... pulls perrin's arms through the sleeves
      that are sent by Resin to an EJB application server... Buckles sleeves
      that SHOULD work very well.

        Since this is exactly what Resin's XML access was designed for, it seems like a reasonable approach. It will be slow, but everything involving EJB is slow already anyway. This seems a bit more likely to work than something like JPL or Inline::Java.
Re: accessing EJB from perl
by SarahM (Monk) on Oct 21, 2002 at 12:54 UTC
    You may want to see if JPL/JNI does what you need. I've only played around with it, but it seemed to work fine. The best part of JPL/JNI is that they are part of perl's core. Here's a good tutorial to help you get started with integrating Java and perl.
      Why? Why try to breed these two beasts? What advantage do you have to writing tests in Perl for an Enterprise Java application? You'd spend more time testing your tests because of each languages different natures. I could see, yes, maybe using Perl to test one's servlets using HTTP (In the past I've actually used silktest for that purpose), but only for such public requests and I'd still want to test my internals using Java.

      Test in the language that you code in. Know how to test in every language you code in. If you don't know how to test it, don't code in it.

      Just because you can do something, doesn't mean that you should. Yes, I can fly, but I'm still going to pick an airplane over jumping off of a building for that purpose. (Insert I don't know, maybe that ain't such a bad idea in your case joke here)

        The advantage you get from breeding these two beasts is using the strengths of each language to offset the weakness of the other. Currently I do most of my coding with perl, C# and C++, occasionally I use Java as well. The language I choose to use depends on which language is best suited for the object I wish to create. I have projects that are tens of thousands of lines long that have some objects written in perl, others in C#, and yet others in C++. But they are all part of the same program, and each language uses the objects from the other languages. Often times Iíll choose perl to test each of the objects. That is because perl is the best at writing quick test programs. I know how to test in each language, but choose perl to save time during the testing phase. Once you have an object, it doesnít matter what language you choose to test the object with. You will get the same result whether you use perl, C#, C++, or Java. An object has interfaces, and all you need to do when testing is make sure each interface does its job. Any language that can use that objectís interface can test that. Of course this assumes you know how to call one languageís object from another language, but that isnít too difficult to learn.

        It all comes down to TIMTOWTDI. You may not feel comfortable using perl to interact with another language, but that doesnít mean other people are the same way.

Re: accessing EJB from perl
by mystik (Sexton) on Oct 21, 2002 at 12:47 UTC
    There is always Inline::Java, but i've never used it, so I can't promise success...

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://206802]
Approved by robartes
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others exploiting the Monastery: (4)
As of 2024-07-24 14:49 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.