Re: [jboss-dev] Looking for Wow factor in AS 5.x
by robb.greathouse＠jboss.com
Hey, I like that. Nice concept, easy to explain. And with IOC you could plug and play life cycles, basic JSF, basic JSP, etc, etc.
Also, means that we can emphasis the "everything just works together" in the AS. So, if you want to have Portal, work with ESB, work with Messaging, work with DNA, et.al. you just deploy it into the app server. Sure it can't be that easy. But boy, if it could be we would be the greatest thing since sliced bread.
Robb Greathouse
JBoss
CELL 505-507-4906
…
[View More]OFFICE 505-255-2652
FAX 505-554-2834
----- "Andrew Lee Rubinger" <andrew.rubinger(a)redhat.com> wrote:
> On 09/14/2009 10:45 AM, Robb Greathouse wrote:
> > It is interesting that all the wow factors seem to be in the
> products/projects vs being in the core AS.
> >
> > Am I wrong in seeing it that way?
>
> I think that's exactly how we should be pushing forward, leaving AS as
>
> an integration point for various projects. The AS then provides
> runtime
> and lifecycle.
>
> S,
> ALR
> >
> > Robb Greathouse
> > JBoss
> > CELL 505-507-4906
> > OFFICE 505-255-2652
> > FAX 505-554-2834
> >
> > ----- "Ales Justin"<ales.justin(a)gmail.com> wrote:
> >
> >> Simply go over BMW's blog:
> >> - http://oddthesis.org/theses/jboss-rails/projects/jboss-rails
> >>
> >> Robb Greathouse wrote:
> >>> Do tell. Do you have more detail.
> >>>
> >>> Robb Greathouse
> >>> JBoss
> >>> CELL 505-507-4906
> >>> OFFICE 505-255-2652
> >>> FAX 505-554-2834
> >>>
> >>> ----- "Ales Justin"<ales.justin(a)gmail.com> wrote:
> >>>
> >>>> I like the ease with how TorqueBox was developed / integrated.
> >>>>
> >>>> Robb Greathouse wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I am putting together a workshop for JBoss AS 5.x. I am
> looking
> >>>> for
> >>>>> some real wow factors. And frankly, even after talking to the
> >> core
> >>>>> developers (who agree) I am not finding any wow factors.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Robb Greathouse JBoss CELL 505-507-4906 OFFICE 505-255-2652 FAX
> >>>>> 505-554-2834 SKYPE rgreathouse
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> ----- "Shelly McGowan"<smcgowan(a)redhat.com> wrote:
> >>>>>
> >>>>>> Jason,
> >>>>>>
> >>>>>>
> >>>>>> RE:
> >>>>>>>> Also, let me know if you have a component you would like to
> >>>>>>>> update/include that has low impact.
> >>>>>> jboss-test and jboss-server-manager currently include alpha
> >>>>>> releases; specifically,
> >>>>>>
> >>>>>> <groupId>org.jboss.test</groupId>
> >>>>>> <artifactId>jboss-test</artifactId>
> >>>>>> <version>1.1.5-alpha-2</version>
> >>>>>>
> >>>>>> <groupId>org.jboss.jbossas</groupId>
> >>>>>> <artifactId>jboss-server-manager</artifactId>
> >>>>>> <version>1.0.3-alpha-2</version>
> >>>>>>
> >>>>>>
> >>>>>> These were needed as part of ALRs new bootstrap implementation
> >>>>>> (JBASM-30, JBASM-31). Are these alpha versions acceptable for
> >> the
> >>>>>> Beta1 release or would you prefer .GA?
> >>>>>>
> >>>>>>
> >>>>>> Shelly
> >>>>>>
> >>>>>> _______________________________________________
> >> jboss-development
> >>>>>> mailing list jboss-development(a)lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
> >>>>> _______________________________________________
> jboss-development
> >>>>> mailing list jboss-development(a)lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
> >>>>>
> >>>
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development
>
> --
> Andrew Lee Rubinger
> Sr. Software Engineer
> JBoss by Red Hat
> http://exitcondition.alrubinger.com
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
[View Less]
15 years, 6 months
Re: [jboss-dev] Looking for Wow factor in AS 5.x
by robb.greathouse＠jboss.com
These are good points.
With regard to the application stack war. For us, getting all our frameworks/products/projects to play well with each other will be a huge advantage. We are well along with this effort.
We need to keep going and identify hubs in the product/project world to drive it forward. For example, Infinispan/JCloud could be the hub for products/projects becoming "cloudy". Seam could be the integration point for integration with web apps. ESB for services. Andiamo (AKA Teiid, …
[View More]AKA Metamatrix) for data exchange.
For the near future there is a lot of functionality that can be created just by making integration of frameworks easier.
Robb Greathouse
JBoss
CELL 505-507-4906
OFFICE 505-255-2652
FAX 505-554-2834
----- "Trustin Lee (이희승)" <trustin(a)gmail.com> wrote:
> On Sat, Sep 12, 2009 at 4:46 PM, Emmanuel Bernard
> <emmanuel(a)hibernate.org> wrote:
> > And bean validation and jsf2. In and by themselves these specs are a
> leap
> > forward our current stack (and everybody else's). And for the first
> time
> > these specs (jpa 2, jsf 2, bv, cdi) have been designed to actually
> work
> > naturally as a unified whole.
> > The framework war is over, welcome to the application stack war.
>
> As long as the frameworks are part of the stack and users have access
> to them, the frameworks matter IMHO, especially when it comes to API
> design and usability. Two frameworks or libraries with same feature
> set and different APIs can make a huge difference. It's something
> like we say we can't tell the quality of software by the number of
> ticked check boxes.
>
> But, I do agree with you the application stack matters a LOT, too. :)
>
> — Trustin Lee, http://gleamynode.net/
>
> > On 12 sept. 2009, at 09:15, Max Rydahl Andersen
> <max.andersen(a)redhat.com>
> > wrote:
> >
> > JPA2, CDI/WebBeans and JBoss Embedded is not enough for you ? ;)
> >
> > /max
> >
> > Robb Greathouse wrote:
> >
> > Hi,
> >
> > I am putting together a workshop for JBoss AS 5.x. I am looking for
> some
> > real wow factors. And frankly, even after talking to the core
> developers
> > (who agree) I am not finding any wow factors.
> >
> >
> >
> >
> >
> >
> >
> >
> > Robb Greathouse
> > JBoss
> > CELL 505-507-4906
> > OFFICE 505-255-2652
> > FAX 505-554-2834
> > SKYPE rgreathouse
> >
> >
> >
> >
> > ----- "Shelly McGowan" <smcgowan(a)redhat.com> wrote:
> >
> >
> >
> > Jason,
> >
> >
> > RE:
> >
> >
> > Also, let me know if you have a component you would like to
> > update/include that has low impact.
> >
> >
> > jboss-test and jboss-server-manager currently include alpha
> releases;
> > specifically,
> >
> > <groupId>org.jboss.test</groupId>
> > <artifactId>jboss-test</artifactId>
> > <version>1.1.5-alpha-2</version>
> >
> > <groupId>org.jboss.jbossas</groupId>
> > <artifactId>jboss-server-manager</artifactId>
> > <version>1.0.3-alpha-2</version>
> >
> >
> > These were needed as part of ALRs new bootstrap implementation
> > (JBASM-30, JBASM-31). Are these alpha versions acceptable
> > for the Beta1 release or would you prefer .GA?
> >
> >
> > Shelly
> >
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development
> >
> >
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development
> >
> >
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development
> >
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development
> >
> >
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
[View Less]
15 years, 6 months
Re: [jboss-dev] 5.2.0.Beta1 Release Plan
by Shelly McGowan
Jason,
RE:
>>Also, let me know if you have a component you would like to
>>update/include that has low impact.
jboss-test and jboss-server-manager currently include alpha releases;
specifically,
<groupId>org.jboss.test</groupId>
<artifactId>jboss-test</artifactId>
<version>1.1.5-alpha-2</version>
<groupId>org.jboss.jbossas</groupId>
<artifactId>jboss-server-manager</artifactId>
<…
[View More]version>1.0.3-alpha-2</version>
These were needed as part of ALRs new bootstrap implementation (JBASM-30, JBASM-31). Are these alpha versions acceptable
for the Beta1 release or would you prefer .GA?
Shelly
[View Less]
15 years, 6 months
Re: [jboss-dev] Looking for Wow factor in AS 5.x
by Robb Greathouse
much grass.
Robb Greathouse
JBoss
CELL 505-507-4906
OFFICE 505-255-2652
FAX 505-554-2834
----- "Andrew Lee Rubinger" <alr(a)jboss.org> wrote:
> The next Beta of 5.2 will have some Embedded support; I'll forward
> along
> a guideline and docs as they become available.
>
> S,
> ALR
>
> On 09/11/2009 09:14 PM, Robb Greathouse wrote:
> > Hi,
> >
> > I am putting together a workshop for JBoss AS 5.x. I am looking for
> some real wow …
[View More]factors. And frankly, even after talking to the core
> developers (who agree) I am not finding any wow factors.
> >
> >
> >
> >
> >
> >
> >
> >
> > Robb Greathouse
> > JBoss
> > CELL 505-507-4906
> > OFFICE 505-255-2652
> > FAX 505-554-2834
> > SKYPE rgreathouse
> >
> >
> >
> >
> > ----- "Shelly McGowan"<smcgowan(a)redhat.com> wrote:
> >
> >> Jason,
> >>
> >>
> >> RE:
> >>>> Also, let me know if you have a component you would like to
> >>>> update/include that has low impact.
> >>
> >>
> >> jboss-test and jboss-server-manager currently include alpha
> releases;
> >> specifically,
> >>
> >> <groupId>org.jboss.test</groupId>
> >> <artifactId>jboss-test</artifactId>
> >> <version>1.1.5-alpha-2</version>
> >>
> >> <groupId>org.jboss.jbossas</groupId>
> >> <artifactId>jboss-server-manager</artifactId>
> >> <version>1.0.3-alpha-2</version>
> >>
> >>
> >> These were needed as part of ALRs new bootstrap implementation
> >> (JBASM-30, JBASM-31). Are these alpha versions acceptable
> >> for the Beta1 release or would you prefer .GA?
> >>
> >>
> >> Shelly
> >>
> >> _______________________________________________
> >> jboss-development mailing list
> >> jboss-development(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/jboss-development
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development
>
> --
> Andrew Lee Rubinger
> Sr. Software Engineer
> JBoss by Red Hat
> http://exitcondition.alrubinger.com
[View Less]
15 years, 6 months
Enforcing JDK6 in AS trunk
by Jaikiran Pai
Hello everyone,
Half way while building a clean AS trunk today, the build failed with
incompatible class versions. With the recent changes to AS trunk, JDK6
is now mandatory for the build to complete successfully. If no one has
any objections, i'll update the parent pom.xml in AS trunk to enforce
this through the enforcer plugin:
Index: pom.xml
===================================================================
--- pom.xml (revision 93223)
+++ pom.xml (working copy)
@@ -609,7 +…
[View More]609,7 @@
<version>2.0.9</version>
</requireMavenVersion>
<requireJavaVersion>
- <version>1.5</version>
+ <version>1.6</version>
</requireJavaVersion>
</rules>
</configuration>
regards,
-Jaikiran
[View Less]
15 years, 6 months
fragile JBossAS component integration
by Jonathan Halliday
Hi all
I'm attempting to test a new version of the transaction
manager against AS trunk and running into assorted problems.
Some unit tests are essentially stress tests. I can make
them pass on my hardware, but only by cranking up memory
settings, thread pool sizes and various ulimit values. Is it
really desirable to require this? If should the environment
settings with which the tests are expected/required to pass
be documented somehwere?
Now onto the main issue:
Some tests use …
[View More]methods on the transaction manager that are
not part of the transactions integration spi. Or to put it
another way, they rely on implementation details of the
component.
For example, tests that use JMX to get the TransactionCount
in order to determine if a tx ran or not. Lets set aside the
fact this is broken because the method always returns 0
unless you remember to turn on statistics gathering, which
is off by default.
Instead, can we discuss what constitutes the stable API for
test purposes? If I'm expected to fix assorted tests that
break whenever I change the component API (rather than the
SPI) that's fine, but I need to know in advance so I can
plan time for it.
On a similar theme, I'm adding a bunch of new transactions
related beans to the transaction-jboss-beans.xml file. These
are essentially implementation specific for the transaction
manager, but nothing prevents other modules beans.xml using
them, even though they are not part of the SPI. What's the
stability/revision policy here? Should anything in the
-beans.xml have to be in the SPI .jar? Be commented with the
expected stability so people wiring their beans to it can
make informed decisions?
MC is great, but it takes us into a world where the
traditional spi interface .jars are no longer the whole
integration story. I'd appreciate some guidelines on how to
maintain clean separation of components in the new server
architecture.
Thanks
Jonathan.
--
------------------------------------------------------------
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111
Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No.
3798903 Directors: Michael Cunningham (USA), Charlie Peters
(USA), Matt Parsons (USA) and Brendan Lane (Ireland)
[View Less]
15 years, 6 months
Integrating components to AS
by Dimitris Andreadis
I think it becomes more and more evident we need better integration testing when bringing
any type of components into JBoss AS.
E.g. I was looking into the recent integration of Bean Validation:
https://jira.jboss.org/jira/browse/JBAS-7167
The one test added would most probably be suitable for a smoke test.
We need more tests and better coverage for the common use cases, including the testing of
remote client access.
/Dimitris
15 years, 6 months
