geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ruebsam <mario.rueb...@googlemail.com>
Subject Re: Self-contained EAR
Date Fri, 07 Jul 2006 11:22:13 GMT
Santosh Koti wrote:
> Maria, 
       ^  --> o
> Thanks for ur explanation.
> 
> Going by this...
> "I can't talk for the current Tomcat release but in the past ...
> let's turn around some common phrase to "never run a changing system" 
> 
> Should I pursue with J/G/Open source...? :~)

ok, replace "change" with "redesign" which is good
when it happens, but not to often

this is just personal feeling and experience, I know many
people who started later with Tomcat and they are very satisfied

Thanks,
Mario


> Thanks,
> Santosh.
> "Don't talk about yourself; it will be done when you leave. "
>  
> 
> -----Original Message-----
> From: Mario Ruebsam [mailto:mario.ruebsam@googlemail.com] 
> Sent: Friday, July 07, 2006 4:06 PM
> To: user@geronimo.apache.org
> Subject: Re: Self-contained EAR
> 
> Santosh,
> 
> Santosh Koti wrote:
>> Mario,
>>
>> Why u stick to Jetty , why not Tomcat...?  :)
> 
> this is a long story and the story is driven by the many releases of
> Tomcat (with major changes) and problems we had to to sail round when
> we used JBoss/Tomcat until we used JBoss/Jetty
> 
> I can't talk for the current Tomcat release but in the past ...
> let's turn around some common phrase to "never run a changing system"
> 
>> Any technical explanation, just ur passion for Jetty...?
> 
> small, smart, fast and yes it's a bit passion ;-)
> 
>> For lesser complex applications, G is fine, but for very large &
> complex
>> systems, better choose G to sub-ordinate some tasks of it.
> 
> That may be true, but what complex? You can write an EJB application
> to sell some goods in an simple webshop. That is complexity by app
> design
> but not by requirement. When I find some time I write an entry in my
> blog about
> how to unhype EJB for simple structured business projects.
> I can't talk about the large projects with many subsystems involved, but
> I can tell you that there are a lot of systems where performance is
> burned by
> overhead in the app design and the middleware used.
> 
> Clustering G is an issue currently but this will change in future.
> 
>> But still G is special ..!
> 
> it is
> 
> 
> Thanks,
> Mario
> 
> 
>> Thanks,
>> Santosh.
>> "Don't talk about yourself; it will be done when you leave. "
>>
>>
>>
>> -----Original Message-----
>> From: Mario Ruebsam [mailto:mario.ruebsam@googlemail.com]
>>
>> Sent: Friday, July 07, 2006 2:35 PM
>> To: user@geronimo.apache.org
>> Subject: Re: Self-contained EAR
>>
>> What I learned in the last 6 years with EJB's and webapps is that
>> performance is mainly founded in the design of the application.
>> So it can differ from one app to another. Some app servers prefer
>> the used design some not.
>> I like to have a server which is customizable and G is customizable,
>> not only in the way the server runs but also in the way I can
>> distribute it(look at "Little G" and plugins). G is easily
>> configurable even by the customer and I can run the same system
>> on the central server and also on a notebook (Little-G) with db and
>> app. The latter is a mandatory requirement by our customer.
>> I don't like that huge systems that can do everything and I need
>> only 30% of it for a particular project. Also G comes with Jetty :-)
>> Thats in short why I stick with G.
>>
>> Thanks,
>> Mario
>>
>>
>> gb.forums@yahoo.com wrote:
>>> I'll check out 1.0 then, but I've heard that performance is not
> really
>> up to par...  Is this true?  And would you mind telling me why you
>> sticked with Geronimo?
>>
>>> Thanks a lot Mario,
>>> GB
>>>
>>> ----- Original Message ----
>>> From: Mario Ruebsam <mario.ruebsam@googlemail.com>
>>> To: user@geronimo.apache.org
>>> Sent: Friday, July 7, 2006 12:27:08 PM
>>> Subject: Re: Self-contained EAR
>>>
>>> It worked nice with G 1.0, the problem report was in release phase of
>> 1.1 so
>>> you could evaluate with G 1.0. The class loading problems will be
>> fixed.
>>
>>> btw, I evaluated JBoss and JSAS and had a production system running
> on
>> it,
>>> but I'm still here ;-)
>>>
>>> Thanks,
>>> Mario
>>>
>>
>>> gb.forums@yahoo.com wrote:
>>>> Super...
>>>>
>>>> The funny thing is that I'm evaluating Geronimo as a replacement for
>> OC4J because of its class loading problems...  So should I switch to
>> JBoss or GlassFish? :)
>>>> Thanks,
>>>> GB
>>>>
>>>> ----- Original Message ----
>>>> From: Mario Ruebsam <mario.ruebsam@googlemail.com>
>>>> To: user@geronimo.apache.org
>>>> Sent: Friday, July 7, 2006 12:06:28 PM
>>>> Subject: Re: Self-contained EAR
>>>>
>>>> Hi Guillaume,
>>>>
>>>> it's a known issue, maybe theres a patch in the near future.
>>>>
>>>> http://issues.apache.org/jira/browse/GERONIMO-2125
>>>>
>>>> Thanks,
>>>> Mario
>>>>
>>>>
>>>> Guillaume Bilodeau wrote:
>>>>> Hi all,
>>>>>
>>>>> I gotta say I'm dumbfounded by how class loading with EARs works in
>> Geronimo, although it is my first time dealing with that kind of issue
>> (deploying a WAR to Tomcat is much simpler).
>>>>> According to this URL
>> (http://www.chariotsolutions.com/geronimo/ejb.html) :
>>>>> "If the EJB JAR file is included in an application EAR, then
>> Geronimo will respect Class-Path entries in the META-INF/MANIFEST.MF
>> file of the EJB JAR. Any JARs referenced there should also be packaged
>> within the EAR, and paths to JAR files will be resolved relative to
> the
>> position of the EJB JAR file in the EAR. If the EJB JAR file is not
>> included in an EAR, then manifest class path entries will be ignored.
> In
>> either case, external libraries can also be placed in the Geronimo
>> server repository and referenced with dependency elements in the
>> Geronimo deployment plan (see Section 12.3.1, Customizing the Class
>> Path)."
>>>>> My EAR contains an EJB JAR which includes a META-INF/MANIFEST.MF
>> file, which does include the libraries that should be in the
> classpath.
>> However, those libraries are not found at runtime.  Here is my EAR's
>> structure:
>>>>> promo-ear.ear
>>>>> + commons-*.jar
>>>>> + spring-*.jar
>>>>> + other-libraries.jar
>>>>> + promo-server.jar
>>>>>   + all-classes.class (including some EJB implementations - not
>> interfaces)
>>>>>   + META-INF
>>>>>     + ejb-jar.xml
>>>>>     + MANIFEST.MF (containing a Class-path entry with references to
>> libraries in the EAR, such as spring-*.jar without any path)
>>>>> + promo-api.jar
>>>>>   + all-ejb-interfaces.class (not implementations)
>>>>>   + META-INF
>>>>>     + MANIFEST.MF (with no Class-path entry)
>>>>> + promo-web.war
>>>>>   + all web content (JSP, CSS, JS, etc.)
>>>>>   + WEB-INF
>>>>>     + web.xml
>>>>> + META-INF
>>>>>   + application.xml
>>>>>   + MANIFEST.MF
>>>>>
>>>>> Somehow the Spring library is not visible since I get the following
>> message:
>>>>> java.lang.ClassNotFoundException:
>> org.springframework.context.support.ClassPathXmlApplicationContext in
>> classloader
>>
> default/promo-ear-2.0.0-snapshot_promo-web-2.0.0-SNAPSHOT.war/1152257080
>> 360/car
>>>>> Surely there must be a way to have a self-contained EAR, which can
>> reference its own libraries.  How can this be done?
>>>>> Thanks a lot,
>>>>> GB
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>>
>>
>>
>>
>> **************** CAUTION - Disclaimer *****************
>> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
> solely for the use of the addressee(s). If you are not the intended
> recipient, please notify the sender by e-mail and delete the original
> message. Further, you are not to copy, disclose, or distribute this
> e-mail or its contents to any other person and any such actions are
> unlawful. This e-mail may contain viruses. Infosys has taken every
> reasonable precaution to minimize this risk, but is not liable for any
> damage you may sustain as a result of any virus in this e-mail. You
> should carry out your own virus checks before opening the e-mail or
> attachment. Infosys reserves the right to monitor and review the content
> of all messages sent to or from this e-mail address. Messages sent to or
> from this e-mail address may be stored on the Infosys e-mail system.
>> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>>
> 
> 


Mime
View raw message