date:20030203

[JBoss-user] Transactions in XPetstore

2003-02-03 Thread Alex Loubyansky

Transaction configurations in XPetstore-2.2 aren't spec 2.0 compliant.
CMP beans can have only Required, RequiresNew or Mandatory tx
attrs, while in XPetstore we can meet Supports and even NotSupported
(Account.getUserId()).

I didn't run the XPetstore on 3.0 but I ran it on JBoss-3.2RC2 and
HEAD.
In RC2 I was able to browse the catalog but something's wrong with
the shopping cart: the state is just not stored.
In HEAD, I couldn't even browse the catalog due to the exception saying
there is not tx associated with the current thread.

Changing tx attributes to Required fixes the problem.

PS: below is the relevant excerpt from the spec.

alex

17.4.1 Transaction attributes
...
For entity beans that use EJB 2.0 container-managed persistence, only the Required,
RequiresNew, or Mandatory transaction attributes should be used for the methods 
defined in the
beans component interface and all the direct and indirect superinterfaces of the 
component interface,
excluding the getEJBHome, getEJBLocalHome, getHandle, getPrimaryKey, and isIdentical
methods; and for the methods defined in the beans home interface and all the direct 
and
indirect superinterfaces of the home interface, excluding the getEJBMetaData and 
getHomeHandle
methods specific to the remote home interface. Containers may optionally support the 
use of the
NotSupported, Supports, and Never transaction attributes for the methods of entity 
beans with
container-managed persistence. However, entity beans with container-managed 
persistence that use
these transaction attributes will not be portable.




---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Re: [JBoss-user] Say No to NetBeans

2003-02-03 Thread Tony Tortallini

Blah blah blah ... but you still never rebutted my point about NetBeans
screwing up Java IDE revenue models. Thanks for reminding me that JBoss and
NetBeans are both open source. As for open source app servers, we already
got one. It's called the Sun ONE app server. It's certified. Put that in
your JBoss pipe 'n smoke it.

http://www.oetrends.com/cgi-bin/page_display.cgi?77


- Original Message -
From: "Curt Johnson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, February 02, 2003 11:24 PM
Subject: Re: [JBoss-user] Say No to NetBeans


> Tony Tortallini wrote:
>
> >I recommend against using the NetBeans IDE for application development. I
> >think it's important to have a community process, open specs, and choice
for
> >the customer, absolutely. How that gets implemented, I don't particularly
> >care. I actually think we need more revenue in the Java IDE space, so
that
> >they can do more advertising to get the message out, because right now
the
> >world is getting blitzed with Microsoft advertising, and promotion and
> >branding and propaganda, and big lies, and that's why they're going, not
> >because it's a better product.
> >
> >So, potentially you could make an argument that the open source IDE thing
is
> >just screwing up all the revenue models and they aren't getting the
> >advertising, because it isn't the best technology that always wins, it's
who
> >advertises more. You could make a very strong argument that says, "No
that's
> >messing with it." And in fact Bill Gates may be sitting up there laughing
> >his butt off because the open source IDE community is cutting the legs
out
> >from under all the R&D and promotion efforts of all the open interface
> >strategies -- not open implementation, but open interface strategies.
> >NetBeans is ruining it for everyone and don't even get me started on that
> >while Apache thing.
> >
> >
> >
> Sorry, but the shortsightedness and ignorance of this post compels me to
> reply. I don't know if this is a troll or very subtle sarcasm, but in
> any case I can't let it sit out there without a rebuttal.
>
> Personally, I don't like NetBeans, I prefer IntelliJ for my IDE. I like
> how IntelliJ gets in my way less than other IDE's and stays out of my
> way when I use it's features. I don't have to change my development
> style to match the IDE, nor am I tied in any way to the IDE. That's what
> I want out of an IDE and that's what I feel that IntelliJ currently
> delivers the best.
>
> Now, will I always use IntelliJ? That is always up for debate, Eclipse
> may provide better integration with my tools, or NetBeans might get rid
> of the 'virtual filesystem' stupidity that turned me off the first time
> I used it. The second I think I will be more productive, you can bet I'm
> jumping ship. I use JBoss for the same reason. I've been writing J2EE
> apps for several years now and JBoss is by far the least brain-damaged
> of all the J2EE app servers. I don't want to tie myself to WebSphere or
> pay through the nose for a less stable platform like WebLogic. However,
> my loyalty to JBoss only continues because the JBoss team continues to
> deliver a product that meets my needs (My gratitude goes much farther
> though, thanks guys).
>
> So what does JBoss or NetBeans, or most Open Source apps have in common?
> They provide infrastructure services, the basic building blocks of the
> system. Quite frankly, Sun's brain damage has done a lot more to hurt
> the Java community than any Open Source project could dream to do. If it
> wasn't for the Open Source implimentations do you have any question that
> J2EE would be a niche technology today? Like Linux, Apache, Sendmail and
> Bind, JBoss and NetBeans provide the basic tools to use these
> environments. They all are the most popular because they are the most
> cost effective solution and provide the most value to the majority of
> the infrastructure's users.
>
> Given the choice between a Sun workstation and a RedHat box for my
> desktop, I'd take the RedHat box, why? Does Solaris scale better? Yes.
> Does Solaris have a more proven track-record? Yes. Minus hardware costs,
> are they the same price? Yes. Why would I choose RedHat? With RedHat I
> get every app I need with a 20 minute install and most of the others are
> an 'rpm -ivh' away. I don't have to hand install bash, or make, or gcc,
> it comes preinstalled. Perl is already there, as is Apache and Gnome. It
> makes me more productive.
>
> Back to my comment about Sun causing more damage to the Java community.
> Why doesn't my RedHat install have a working JDK, or a J2EE library
> preinstalled? Because Sun thought it would be a good idea to charge
> RedHat ~$2million for the privilege of doing compliance testing and
> signing a distribution agreement. I got this from several RH employees
> at the last ALS in Atlanta. Sun has also never released an Open Source
> implementation of the JVM, they always cite 'predatory companies' in the
> marketplace as the

Re: [JBoss-user] basic clustering question

2003-02-03 Thread Brian McSweeney

Thanks Sacha,

> in this case, use a hardware or software loadbalancer that uses sticky
> sessions.

what exactly are sticky sessions? And how if it's a hardware load
balancer could you do this?

Eg, say we're running a web app.
We have two boxes A and B both running the web and ejb tiers.
Each box has a stateful session bean as a facade and also with a
stateless session bean as a facade between the web and ejb tiers.

In front of them is a little hardware load-balancer that randomly
picks between A and B. If a client uses the stateful session bean
does it have to always have to go back to the same box? Or
can we cluster the stateful session bean too?

thanks,
Brian

- Original Message -
From: "Sacha Labourey" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 01, 2003 2:45 PM
Subject: RE: [JBoss-user] basic clustering question


> > this makes sense if the client is a heavyweight app (say swing). But
> > if the client is the web tier and the app is basically an internet site,
> > then
> > the ultimate client is a web browser. Now, you could have the "proxy"
> > being the code in the web tier - ie, a servlet, which could pick which
of
> > the ejb tiers to hit, as you say.
>
> in this case, use a hardware or software loadbalancer that uses sticky
> sessions.
>
> > However I would have thought it would be better to let this proxy be a
> > little hardware device that just selects which of the boxes to
> > hit, and then
>
> if it is a web app, yes. If it is a java app, no.
>
>
>
> ---
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> ___
> JBoss-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-user
>




---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

[JBoss-user] [ANN] Tammi 1.0 Released - a JMX Application Framework

2003-02-03 Thread Marketta Priha





 

Hello 

 
This message is relevant to JBoss users interested in applying JBoss'  JMX
capabilities also in servlet development and business logic  implementation. 

 
The Norther Organization has released Tammi 1.0 open source development framework
for web applications at http://tammi.sourceforge.net/. Downloads,
a demo with an on-line manual, extensive tech spec and API docs are available. 

 
Tammi is a Java component based development framework and run-time container
for applications supporting web browsers, mobile terminals and/or Swing based
user interfaces. 
 
The key technologies applied include service proxy architecture with Java
Management Extensions (JMX), dynamic configuration with Dynamic Java, MVC
filters and filter chains with Java Servlets, template processing with Apache
Velocity and Freemarker, and general design derived from Apache Turbine.
The architecture allows effortless integration of additional libraries when
needed. 
 
Tammi, as well as applications built with it, can be executed either as a
servlet or filter chain under a J2EE compatible servlet container, the recommended
approach for JBoss users. In addition, it contains an internal HTTP(S) 1.1
capable connector with competent performance. 
 
Separate notes on how to build and deploy Tammi to JBoss are in Sourceforge
under Docs-section. 
http://sourceforge.net/docman/display_doc.php?docid=15052&group_id=62554 

 
Tammi application components are JMX MBeans meant for implementing independent
business logic themselves or to act as proxies to native libraries, remote
programs and other kinds of manageable systems. 
 
In Tammi, we have chosen to exploit a template engine instead of JSP. The
localization and customization of look-and-feel, as well as the RAD support
for HTML forms, is based on that approach. 
 
Tammi implements an MBean administration interface with templates. Under
JBoss you'll have two options for administration: the JMX Console  and Tammi
administration pages. In both interfaces, you can view all the  MBeans in
the JBoss and Tammi domains. 
 
Regards, 
Marketta 
mpriha at users.sourceforge.net

Re: [JBoss-user] [ANN] Tammi 1.0 Released - a JMX Application Framework

2003-02-03 Thread Andreas Mecky

Hi,
maybe I am the only one but I don't think that this
is the right place for this kind
of shameless self commercial.
Or if nobody else agrees then I can also start
using JBoss as my mailing list
for my open source projects?
WBR
Andreas

- Original Message -
From:
Marketta Priha
To: [EMAIL PROTECTED]

Sent: Monday, February 03, 2003 11:18
AM
Subject: [JBoss-user] [ANN] Tammi 1.0
Released - a JMX Application Framework

Hello This message is
relevant to JBoss users interested in applying JBoss' JMX capabilities also in
servlet development and business logic implementation. The Norther
Organization has released Tammi 1.0 open source development framework for web
applications at http://tammi.sourceforge.net/.
Downloads, a demo with an on-line manual, extensive tech spec and API docs are
available. Tammi is a Java component based development framework and
run-time container for applications supporting web browsers, mobile terminals
and/or Swing based user interfaces. The key technologies applied
include service proxy architecture with Java Management Extensions (JMX),
dynamic configuration with Dynamic Java, MVC filters and filter chains with
Java Servlets, template processing with Apache Velocity and Freemarker, and
general design derived from Apache Turbine. The architecture allows effortless
integration of additional libraries when needed. Tammi, as well as
applications built with it, can be executed either as a servlet or filter
chain under a J2EE compatible servlet container, the recommended approach for
JBoss users. In addition, it contains an internal HTTP(S) 1.1 capable
connector with competent performance. Separate notes on how to build
and deploy Tammi to JBoss are in Sourceforge under Docs-section. http://sourceforge.net/docman/display_doc.php?docid=15052&group_id=62554
Tammi application components are JMX MBeans meant for implementing
independent business logic themselves or to act as proxies to native
libraries, remote programs and other kinds of manageable systems. In
Tammi, we have chosen to exploit a template engine instead of JSP. The
localization and customization of look-and-feel, as well as the RAD support
for HTML forms, is based on that approach. Tammi implements an MBean
administration interface with templates. Under JBoss you'll have two options
for administration: the JMX Console and Tammi administration pages. In both
interfaces, you can view all the MBeans in the JBoss and Tammi domains.
Regards, Marketta mpriha at users.sourceforge.net

45 matches

Mail list logo