[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-community] About Profiles / Servlet API
|
Right - although I'd anticipate more than
just the RI providing a complete platform implementation. I agree application
deployments will focus on the profile they need - not the complete platform.
For example, the branch of the discussion we're on here was the potential
need for a discrete profile for fully async cloud native apps. These should
run on a complete JakartaEE platform in the future (as they can with careful
design on EE today) but are surely going to have a much better life with
a targetted profile that recognizes different use cases from the web profile.
Regards,
Ian
Ian Robinson, IBM Distinguished
Engineer
WebSphere Foundation Chief Architect
IBM Hursley, UK
irobins@xxxxxxxxxx
Admin Assistant: Janet Brooks - jsbrooks12@xxxxxxxxxx
From:
"Ondrej Mihályi"
<ondrej.mihalyi@xxxxxxxxxxx>
To:
Jakarta EE community
discussions <jakarta.ee-community@xxxxxxxxxxx>
Date:
22/05/2018 15:25
Subject:
Re: [jakarta.ee-community]
About Profiles / Servlet API
Sent by:
jakarta.ee-community-bounces@xxxxxxxxxxx
I agree that it makes sense to define what's
Core and Complete profiles, though it may not make sense to use just Core
or all of Complete to build and run applications. Rather, I think about
them as a reference to be used for other profiles. All profiles should
share core principles (Core profile). The Complete profile would define
how all individual components should integrate, e.g. in case we want to
combine 2 or more profiles or assemble a custom profile.
The Core should really be just core, with
only general-purpose components like DI (a subset of CDI), Config, Security,
Testing, Logging, etc. There's no point in adding Servlets or JAX-RS or
even asynchronous processing into the Core as it may not fit all use cases.
On the other side, the Complete profile
wouldn't be meant to be used in production and maybe only the RI would
implement all of it. Most of the other implementations would be of a specific
profile or multiple profiles for the usecases they aim at.
Cheers,
Ondrej Mihályi
Senior Payara Service Engineer
Payara Server – Robust.
Reliable. Supported.
E: ondrej.mihalyi@xxxxxxxxxxx
| T: +1 415 523 0175 | M: +421 902 079 891
----------------------------------------------------------------------------------------------------------------------
Payara Services Limited, Registered office:
Unit 11, Malvern Hills Science Park, Geraldine Road, Malvern, WR14 3SZ
Registered in England and Wales: 09998946 | www.payara.fish
| info@xxxxxxxxxxx
| @Payara_Fish
From: jakarta.ee-community-bounces@xxxxxxxxxxx
<jakarta.ee-community-bounces@xxxxxxxxxxx> on behalf of Richard Monson-Haefel
<rmonson@xxxxxxxxxxxxx>
Sent: 22 May 2018 13:54:56
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] About Profiles / Servlet API
I can see profiles that would not benefit from the Core,
whatever that is, but then what is the platform we are defining? Is
it simply a collection of specifications for which there is no common foundation
(other than Java SE)? I don’t think that could be called a platform,
do you? What is a platform?
The other side of this coin is the “Full” or “Complete”
profile. It has been suggested that the Complete Profile be a specification
that bundles all of the specifications together and defines how they interoperate
- all of them together. At first I thought this was over kill, but
it’s actually another way to define the platform.
Imagine that there was no Core and there was no Complete
profiles. Instead their is a “Legacy” profile that captures the legacy
Java EE platform and then a bunch of independent profiles like Reactive
Streams, Web, REST, IoT, etc.
Now, as a user or a vendor I want a Reactive Streams profile
combined with a Legacy Profile. How are cross cutting concerned handled
if security and transactions, for example, are not defined consistently
across Reactive Streams and EJB, JMS or CDI? How do I use them in
combination in a way that is portable?
The argument for a Complete Profile is that: any new specification
should automatically be compatable and be included in the next version
of the Complete profile, so that portability when combining different specifications
isn’t an issue. The argument for a Complete Profile makes sense
if you want to ensure portability across the entire Jakarta EE ecosystem.
The Complete Profile other side of the platform coin from
Core. I don’t know if you can have a platform without one or the
other, but I’m very open to hearing otherwise.
On Tue, May 22, 2018 at 5:45 AM Ian Robinson <ian_robinson@xxxxxxxxxx>
wrote:
If we're going to set up JakartaEE to
be a platform for the next 20 years then we're going to have to do some
wildly different things alongside supporting what got us here in the first
place. Profiles may be a way to help with that but not (in my opinion)
if we restrict the way we think about them as being simple concentric circles
around a single core. Different style of programming are going to need
different profiles (defined sets) of technologies that may share
some in common without necessarily having to have a single common minimum
set of core technologies in all profiles. Reactive streams are a good example.
The servlet spec (for example) is important to JakartaEE full and web profiles
but doesn't need to be part of some future JakartaEE ReactiveStreams profile
(if we worked on such a thing). It would still be part of the profiles
for which its relevant including the full profile.
I see near universal agreement that the the JakartaEE full profile will
remain important, and it will grow. If we get new and smaller profiles
right then they can support platform innovation without having to drag
everything forward at the pace of the oldest. So I agree with James' final
sentiment by thinking about it without the 4-letter c word.
> I think a cloud native Jakarta EE is one that treats servlets as an
option chosen for the right use cases, not as a default in the core.
Regards,
Ian
Ian Robinson
From: James
Roper <james@xxxxxxxxxxxxx>
To: jakarta.ee-community@xxxxxxxxxxx
Date: 22/05/2018
03:54
Subject: Re:
[jakarta.ee-community] About Profiles / Servlet API
Sent by: jakarta.ee-community-bounces@xxxxxxxxxxx
Not sure where to put this reply since the thread seems to have split a
couple of times, but to clarify my original suggestion.
When I say synchronous communication, I'm not referring to IO. Whether
the servlet API is blocking or not is not a consideration to me at least
in whether it should be part of the core. Rather, the question is whether
synchronous communication - ie, request/response, where both parties in
the communication need to be actively participating in the communication
for it to succeed, where one party being down leads to the other unable
to proceed, synchronous communication is what I don't think should be in
the core. The servlet API is inherently synchronous, if a client tries
to send a message to a servlet, and the servlet isn't running, is overloaded,
or is failing, the servlet won't get that message later when the problem
is fixed, this is because it is based on synchronous (dictionary definition
"at the same time", ie, both parties active at the same time)
communication, whether it's using non blocking IO or not.
The alternative, asynchronous communication, which typically uses message
brokers as an intermediary transport, does not require both parties to
be participating at the same time, so the sender can send the message regardless
of whether the receiver is able to receive it at that time. In a world
where deployments now consist of tens, hundreds even thousands of services,
requiring all services to be running at the same time, which synchronous
communication does, leads to a system that is fragile and far worse than
a monolith. Hence, asynchronous communication is imperative in this world
of cloud native services.
I'm quite aware that Servlets aren't tied to HTTP, but they are tied to
request/response, and this is the issue.
I anticipate that in 5 years, most backend services will primarily just
use asynchronous communication - the primary places that will use synchronous
communication will be services that directly face users, where users need
a timely response to their requests. In many architectures today, this
is already the case.
That's not to say Servlets are ever going to go away - it's not an either
or, both synchronous and asynchronous communication are needed in all systems.
But the current situation, where synchronous is the primary means of communication,
reflected by the fact that the servlet spec is in the core, is coming to
an end, and it's cloud native that is signalling the end of that. I think
a cloud native Jakarta EE is one that treats servlets as an option chosen
for the right use cases, not as a default in the core.
On Tue, 22 May 2018 at 04:15, Werner Keil <werner.keil@xxxxxxxxx>
wrote:
You are aware that each of these standards are defined elsewhere (e.g.
OASIS) therefore it is important to separate the specs (if you propose
something underneath MQTT or AMQP this is simply the wrong place) and implementing
solutions (this is what can be shaped or influenced here)
Werner
On Mon, May 21, 2018 at 8:05 PM, Markus KARG <markus@xxxxxxxxxxxxxxx>
wrote:
JMS is for applications accessing MOMs, which in turn use AMQP/MMQT.
What I proposed is a layer
UNDERNEATH AMQP/MMQT.
-Markus
From: jakarta.ee-community-bounces@xxxxxxxxxxx
[mailto:jakarta.ee-community-bounces@xxxxxxxxxxx]
On Behalf Of Werner Keil
Sent: Montag, 21. Mai 2018 19:47
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] About Profiles / Servlet API
Of course
AMQP / MMQT are message-based, so they are by nature closer to e.g. JMS.
I can't say, what the just
forming EE4J Messaging/JMS project might like to do about this, but having
worked in a cross-cut between MQTT and JMS for major clients, I see potential
for synergies between EE4J and IoT especially now they are both under the
Eclipse umbrella
Werner
On Mon, May 21, 2018 at 7:37 PM, Markus KARG <markus@xxxxxxxxxxxxxxx>
wrote:
I also thought so but in
fact Servlet API only works for request-response communication models,
which is not given for at least UDP, AMQP and MMQT. IMHO you cannot implement
AMQP / MMQT ontop of Servlet API.
-Markus
From: jakarta.ee-community-bounces@xxxxxxxxxxx
[mailto:jakarta.ee-community-bounces@xxxxxxxxxxx]
On Behalf Of Richard Monson-Haefel
Sent: Montag, 21. Mai 2018 18:23
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] About Profiles / Servlet API
I’m not up to speed on everything Servlet, but I do like
the idea of breaking it up so that you have an HTTP specific Servlet and
a more general Servlet programming model that can be extended to the semantics
of other application protocols. I think, to some degree, this already
exists its just a matter of the Servlet provider supporting the stack desired
(e.g. UDP/TCP/SCTP) and then having a higher level programming model for
each application protocol (e.g. HTTP, AMQP).
On Mon, May 21, 2018 at 11:07 AM Markus KARG <markus@xxxxxxxxxxxxxxx>
wrote:
I'd like to extend this idea by a new API for the UDP/TCP/SCTP layer: It
might be useful to build the HTTP API layer (= former Servlet API) ontop
of a new UDP/TCP/SCTP API layer which allows Servlet engines to replace
the underlying transport technology easily. That API could wrap micro-servers
dealing solely with data packets instead of application protocols. So not
only HTTP would run ontop of that, but also AMQP or MQTT or even FTP. The
bean driven by such a system would be a "Stream-let" or "Protocol-let"
for example. So re-implementing the Servlet API would mean to write a "HttpProtocolLet",
AMQP would use an "AmqpProtocolLet" etc. In the IoT-Environment
this could be beneficial, and it would simply re-use the technical platform
already existing e. g. in Grizzly.
-Markus
From: jakarta.ee-community-bounces@xxxxxxxxxxx
[mailto:jakarta.ee-community-bounces@xxxxxxxxxxx]
On Behalf Of arjan tijms
Sent: Montag, 21. Mai 2018 17:58
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] About Profiles
Hi,
On Mon, May 21, 2018 at 3:12 PM, Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxxxx>
wrote:
I think that James didn't mean to toss out HTTP processing but that the
servlet API isn't well suited for reactive processing. The Servlet spec
is also huge, comparable to EJB and could be designed and split into multiple
specs. Or even obsoleted by another more modern spec in a similar way as
CDI is now obsoleting much of the EJB spec.
I don't quite see the Servlet spec being deprecated /
obsoleted, like EJB was.
I do like the suggestion of splitting out the Servlet
spec in parts. Specifically we could potentially have a core HTTP engine
(like Netty, Grizzly, and Coyote), a "bare" Servlet API layer,
and something like a higher level CDI based layer (making a simpler Servlet
that's a proper CDI bean).
Kind regards,
Arjan
Cheers,
Ondrej Mihályi
Senior Payara Service Engineer
Payara Server – Robust.
Reliable. Supported.
E: ondrej.mihalyi@xxxxxxxxxxx
| T: +1 415 523 0175 | M: +421 902 079 891
----------------------------------------------------------------------------------------------------------------------
Payara Services Limited, Registered office:
Unit 11, Malvern Hills Science Park, Geraldine Road, Malvern, WR14 3SZ
Registered in England and Wales: 09998946 | www.payara.fish
| info@xxxxxxxxxxx
| @Payara_Fish
From: jakarta.ee-community-bounces@xxxxxxxxxxx
<jakarta.ee-community-bounces@xxxxxxxxxxx>
on behalf of Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>
Sent: 21 May 2018 16:03:00
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community]
About Profiles
James,
I think you have missed something in the Servlet programming
model. While its primarily used for HTTP requests its not bound to that
model or even synchronous request/response messaging. Reactive Streams
could work well within the Servlet model or form another programming model.
If I’m wrong than Serlvets have changed more than I thought since
I used them for pure TCP/IP processing back in 1998.
I’m an advocate of Reactive Streams as a new programming/processing/messaging
model, but it would be premature to toss out HTTP processing and Servlets
in order to embrace Reactive Streams as the “one true” model. Having
been around for a long time I can tell you that today’s silver bullet
often becomes tomorrows legacy nightmare. I’ve lived through that
transition at least a dozen times. There is no “one true” model.
There is only those options that most useful now.
I don’t believe that is the fate of Reactive Streams
to become legacy, but at this point its not a widely adopted programming
model and I think we need to serve the needs of the mass majority of developers
who use HTTP and Servlets IN ADDITION TO introducing and supporting new
methods like Reactive Streams.
I would not make Reactive Streams a required part of the
Core at this point, but as Reza pointed out the Core can evolve over time
just as well as any profile. If Reactive Streams is introduced as
a Specification and wrapped into a Profile on top of the Core, it could
remain very lightweight while providing a powerful programming model for
those interested in that paradigm.
On Sun, May 20, 2018 at 9:18 PM James Roper <james@xxxxxxxxxxxxx>
wrote:
Are servlets really necessary in the core? Yes, they may have been central
to Java EE for as long as Java EE has existed, but things are changing,
systems can no longer be seen is a big static state store that can just
be queried and updated with synchronous communication, rather they are
being build using streams, where the current state is in a constant state
of converging, but never actually getting there, and communication is primarily
asynchronous. Look at things like Kafka Streams and AWS Lambda and Azure
Event Grid - event based systems that are only concerned with asynchronous
messaging are rising rapidly in popularity at the moment. And this isn't
even that new, almost 10 years ago Heroku had both web dynos and worker
dynos - worker dynos had no HTTP interface, and you could argue that deploying
something that started an HTTP server to a worker dyno was overkill. Now
is a perfect opportunity to realign Jakarta EE with current industry trends.
And even for technologies that use synchronous communication,
look at the rise of things like gRPC - this does use HTTP, but not on top
of servlets. No one wants to deploy both a servlet HTTP server and a gRPC
server, that's too heavyweight. Other things like gRPC may well surface,
do we want the servlet API to get in the way of people using these new
technologies with Java EE?
As a counter point against requiring servlets, the MicroProfile
messaging spec currently being developed will have no dependence on servlets,
and I anticipate that there will be many use cases where you'll deploy
services that use nothing but MicroProfile messaging for communication,
plus a database.
Perhaps as little as 2 years ago, I would have agreed,
servlets are core. But I think there's a big shift at the moment, and a
decision to make servlets core today could leave Jakarta EE behind.
On Mon, 21 May 2018 at 01:16, reza_rahman <reza_rahman@xxxxxxxxx>
wrote:
You know I have a tremendous amount of respect for you, but as I suggested
the truth is that none of this is about technical merit. Sometimes we really
do need to just bow to where the market is driving us and not fight it.
Once we have the technology on firmer footing is the time to explain to
the marker why we are right. That's not now.
The market demand from where I clearly have seen again
and again is allowing people to start with Java EE with nothing more than
Servlet and a la carte let them add whatever else on top. In addition there
is a viable smaller market for one or two sensible profiles. Right now
people also want fat jars and hollow uber jars.
Giving people basically what we've been trying to push
for years plus some ability to remove things or define things is yet another
road to fighting another uphill battle that's honestly tiresome. The end
result of where we are today should be telling us loud and clear we need
to be thinking about these things differently going forward.
Sent via the Samsung Galaxy S7, an AT&T
4G LTE smartphone
-------- Original message --------
From: arjan tijms <arjan.tijms@xxxxxxxxx>
Date: 5/20/18 4:40 PM (GMT+01:00)
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] About Profiles
Hi,
On Fri, May 18, 2018 at 11:30 PM, reza_rahman <reza_rahman@xxxxxxxxx>
wrote:
I am totally with Mark on these particular
issues. Whatever the actual merits of the argument that we can argue endlessly,
the reality is that customers cite Java EE "weight" as a reason
to not adopt it with Docker/Cloud/Microservices, etc.
It's true that this is being cited, although it's indeed
"weight' between quotes. With only a few exceptions I've seen the
actual weight (startup time / memory size / footprint on disk) of the supposedly
lighter weight solution actually been approximately the same size or even
bigger.
People arguing that they use e.g. Tomcat because it starts
in 500ms and is only 7MB in size, but then they add 50MB worth of libraries
to /lib and an other 40MB of libraries to WEB-INF/lib. The combined whole
being just under 100MB in disk space.
As a second point, a (standard) static config + pruning
tool would again address this concern, and I argue it can do even better
than any profile ever can.
Kind regards,
Arjan
Additionally I believe other than minimizing
endless conflict with Spring folks over CDI, making clear what Java EE
is and how well adopted/not it is, a Servlet only core is also the right
answer to combat the criticism that Java EE is fat.
Sent via the Samsung Galaxy S7, an AT&T
4G LTE smartphone
-------- Original message --------
From: Mark Little <mlittle@xxxxxxxxxx>
Date: 5/18/18 3:47 PM (GMT+01:00)
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] About Profiles
On 18 May 2018, at 14:40, arjan tijms <arjan.tijms@xxxxxxxxx>
wrote:
Hi,
On Thu, May 17, 2018 at 1:46 PM, Mark Little <mlittle@xxxxxxxxxx>
wrote:
This isn’t just about vendor choice. You are certainly
not alone in being happy with the full profile option. However, there are
other classes of users/developers that aren’t and these have existed since
the dawn of J2EE. For example, some people want to deploy their favour
app server on to constrained devices which may be running on the cloud
where an additional 50MB costs real money when run for hours or days or
weeks or longer.
I wonder, is there in practice any service / device where
a mere 50MB of disk space makes all the difference?
You mean apart from cloud (yes, those 1 cent costs do
add up, and there’s private cloud deployments of which you may be unaware
and have some funky architectural choices behind them), IoT? Oh and maybe
it’s not just 50MB but some modern implementations can still be a bit
“plump” in some areas ;)
Some developers want to reduce the maintenance complexity or boot time
of their favourite app server by stripping out those capabilities they
don’t want.
For that particular issue a static configuration (such
as liberty's server.xml and in limited way JBoss/WildFly's standalone.xml),
and/or the aforementioned prune tool would work just as well.
And then we get into the world of portability. As a developer
I want to know a priori that my app will work across app servers and I
really don’t want to have to check when I do the migration. Having app
server A and B both say they support and are compliant with Profile X is
extremely useful.
Now you could argue that these developers could just do this themselves
anyway, e.g., JBossAS has supported this kind of pruning from the start.
However, if you want portability and interoperability of your apps so you’re
not tied to a specific app server implementation/vendor, having standardised
profiles is the right approach.
Or a standardised static config, perhaps?
And what would we call those static configs. Oh hold on,
let me suggest … profiles? ;)
Kind regards,
Arjan
Mark.
On 16 May 2018, at 23:16, Dominik Hufnagel <mail@xxxxxxxxxxxxxxxxxxx>
wrote:
As a user of JavaEE, I do not get the idea
behind having multiple profiles. May someone can explain the benefits for
users? If I can have a single profile with all available features, I would
take it and I do not bother using a server which is 50MB larger of one
with a „smaller“ profile. I can understand that it could be harder for
vendors to enter the market having to provide the full profile. But for
me, this would not be an argument for using smaller profiles. I’d rather
take a server from a vendor which offers me the full profile.
If I would use the MicroProfile and want
to have JPA, do I have to add external dependencies? I really like some
of the new APIs of the MicroProfile and would be happy to see them coming
to JakartaEE.
Dominik
Von: jakarta.ee-community-bounces@xxxxxxxxxxx
[mailto:jakarta.ee-community-bounces@xxxxxxxxxxx]
Im Auftrag von Mark Little
Gesendet: Mittwoch, 16. Mai 2018 11:42
An: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Betreff: Re: [jakarta.ee-community] About Profiles
Hopefully others have responded already
but … it’s for both: quick summary … vendors so they can ensure conformance
and users so they can ensure portability and interoperability of their
apps.
Speaking with my MicroProfile hat on, I
for one would not want to trade the current MicroProfile for a full Jakarta
EE profile and neither would our users.
Mark.
On 7 May 2018, at 17:33, arjan tijms <arjan.tijms@xxxxxxxxx>
wrote:
So then the first question is perhaps;
who wants profiles and benefits from it? Is a profile intended for vendors
or for users?
---
Mark Little
mlittle@xxxxxxxxxx
JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork
Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell
Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill,
Keith Phelan, Matt Parson (USA)
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
---
Mark Little
mlittle@xxxxxxxxxx
JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business
Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell
Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill,
Keith Phelan, Matt Parson (USA)
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
---
Mark Little
mlittle@xxxxxxxxxx
JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business
Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell
Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill,
Keith Phelan, Matt Parson (USA)
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
--
James Roper
Senior Octonaut
Lightbend
– Build reactive apps!
Twitter: @jroper
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Richard Monson-Haefel
http://twitter.com/rmonson
http://www.tomitribe.com
http://www.tomitribe.io
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Richard Monson-Haefel
http://twitter.com/rmonson
http://www.tomitribe.com
http://www.tomitribe.io
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
--
James Roper
Senior Octonaut
Lightbend
– Build reactive apps!
Twitter: @jroper_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Richard Monson-Haefel
http://twitter.com/rmonson
http://www.tomitribe.com
http://www.tomitribe.io
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU