Sounds good to me.
Same as EE could start with logging. In fact, While still at BEA, the BPM
tools (formerly ABPM or Fuego) contained not only a LogViewer, similar to a
web-based equivalent I wrote last year, it had a common notion of log
severity to configure in some of the main properties or XML files.
http://docs.oracle.com/cd/E13165_01/albsi/docs60/logviewer/index.html
As you notice, these were more on the Log4J side, not so surprising, if you
know, at least the ABPM Admin Console also runs on Tomcat, not WLS,
Glassfish or whatever. It might now or in future versions, but historically
that was when BEA was closer to Apache than Sun in many aspects.
Werner
On Fri, Jul 20, 2012 at 3:26 PM, Jeff Genender <jgenender_at_savoirtech.com>wrote:
> But why wait on our side at this stage? Why can't we create an
> SPI/Adapter framework for EE and plug in whatever modularity in the
> background? That way we can start with OSGi and then additionally hook up
> Jigsaw when/if that ever comes to fruition...
>
> Thoughts?
>
> Jeff
>
> On Jul 20, 2012, at 7:54 AM, Werner Keil wrote:
>
> Jim/all,
>
> Interesting thoughts. Although Mark tried to mitigate damage done by the
> Jigsaw delay a bit, a lot of the finer grained Modularity in EE is likely
> to be delayed until EE can actually use Java 9+ Modularity.
>
> Whether that'll be EE8 or 9, let's see, usual naming scheme leans towards
> the latter.
>
> For those profiles that already exist or may be created without JMS, why
> not consider making MDBs optional, but for any scenario where Messaging
> like MQ Server or other JMS solutions need to be consumed, I strongly
> suggest keeping MDBs in there.
> I saw them work perfectly fine in some of the biggest Java EE farms
> probably out there with large telcos. About a year ago another big telco in
> a much smaller system insisted on using their wrong experience and
> understanding of Spring and Spring JMS Template for a similar requirement.
> Spring mimicking proper Java EE and protocols like JTA (sorry having to say
> that, but the whole "Spring vs. Standard EE" has its point, I am not trying
> to fuel it) by adding its "AOP Voodoo" caused that part of the project to
> end up in a horrible failure. And us coaches recommended different
> approaches which they unfortunately didn't listen to<326.gif>
>
> Removing MDBs by default from ANY EE Profile would send the wrong signal
> and raise temptation for similar experiments with other technologies. While
> considering them optional in certain profiles where JMS is not required at
> all, that I could imagine.
>
> Regards,
> --
>
> Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead
>
> Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR
> Skype werner.keil | Google+ gplus.to/wernerkeil
>
> * Chip-to-Cloud Security Forum: September 19 2012, Nice, French Riviera.
> Werner Keil, JCP Executive Committee, JSR-321 EG Member will present
> "Trusted Computing API for Java™"
>
> * Eclipse Day Delft: September 27 2012, Delft, Netherlands. Werner Keil,
> Eclipse Committer, UOMo Lead, Mærsk Build Manager will present "Triple-E
> class Continuous Delivery with Hudson, Maven and Mylyn"
>
>
> On Fri, Jul 20, 2012 at 12:00 AM, Jim Knutson <knutson_at_us.ibm.com> wrote:
>
>> Linda DeMichiel <linda.demichiel_at_oracle.com> wrote on 05/10/2012
>> 02:50:43 PM:
>> > The Java EE Platform and EJB specifications currently require the
>> > capability of using RMI-IIOP to export EJB components and to access EJB
>> > components over a network. This requirement enables interoperability
>> > between Java EE products.
>> >
>> > It has been suggested that we consider removing the requirement for
>> > such interoperability support from the Java EE Platform and EJB
>> > specifications.
>>
>> Apologies for the late reply. In general, I'm in favor of making optional
>> some of the less used parts of the platform, so consider this a +1.
>>
>> However, we all need to agree on what this means as there are intended
>> compliance implications. I agree with Jason that interop is important
>> and that there are certain QoS characteristics that go along with
>> RMI-IIOP.
>>
>> > There are several reasons behind this proposed change:
>> >
>> > * RMI/IIOP has been largely superseded by modern web technologies
>> > that provide interoperability support, such as SOAP and REST.
>> > Hence, few developers are currently relying on RMI/IIOP for this
>> purpose.
>> > * Implementing the required support is seen as an unnecessary
>> > burden on Java EE implementors.
>> > * There is a perception that this requirement makes Java EE seem
>> > heavyweight at a time when we're trying to appeal to developers
>> > who want a lightweight solution.
>>
>> The first bullet above implies more than just making RMI-IIOP optional
>> to me. It says that the RMI programming model itself with its
>> corresponding QoS has been replaced by web services / REST when
>> interop is required.
>>
>> The second bullet is not quite true. It's an implementation burden
>> for any _new_ Java EE implementor, but any existing vendor who already
>> supports RMI-IIOP is not likely to remove support from their
>> existing customers just because it's optional now. As usage drops to
>> zero, then existing vendors can stop supporting it, but it's still
>> a non-zero effort in the meantime.
>>
>> There's more than a perception that RMI-IIOP is heavyweight. There's
>> a very noticeable memory footprint that goes with an ORB, OTS, INS,
>> and CSIv2 and not everyone will require this. So making this optional
>> is a definite improvement for a large customer segment.
>>
>> > Removing this requirement would mean that an implementation of the
>> > Platform would still be required to support remote access to EJBs, but
>> > would not be required to use IIOP to do so. That is, we would be
>> > removing requirements that provide interoperability across products,
>> > but would not be removing requirements that require support for remote
>> > access within a single product, since other protocols could be used.
>>
>> This is where we start to get into ironing out a common understanding
>> of what is truly being proposed. The first bullet implies that all of
>> the RMI programming model is optional and you just annotate your web
>> profile EJBs with @WebService if you want to expose remote access (or
>> use REST). I like the idea of provisioning in web services remoting
>> function without also being required to provide RMI remoting function.
>> The way the spec is today, vendors are technically in violation of
>> the spec if they provide one without the other. However, the previous
>> paragraph implies that RMI stays and it's only the CORBA interop
>> (ORB, OTS, INS, CSIv2) requirements that disappear.
>>
>> Let's assume for the moment that just the CORBA interop requirements
>> go away and we keep the RMI programming model. Will transaction and
>> security context flows still be required? What about remote JNDI
>> lookup? If we have no portability requirements, are we confident
>> that CTS can validate compliant behavior when the client and the
>> server are vendor specific?
>>
>> From my perspective, RMI, RMI-IIOP, and all the OTS, CSIv2, INS
>> related aspects and qualities of service should be tied together.
>> I don't mind them being made optional and vendors can implement
>> RMI or not as they choose, but if they choose to implement RMI,
>> a compliant and interoperable set of QoS should be part of the
>> package.
>>
>> If push came to shove, I could accept non-interoperable RMI iff:
>> 1. RMI is separately optional (e.g. you can deliver web profile +
>> JAX-WS + EJBs as JAX-WS components without requiring RMI,
>> MDBs, etc.)
>> 2. a non-interoperable RMI is required to support the same QoS
>> as RMI-IIOP based RMI.
>>
>> While you're at it, how about making MDBs optional so I can
>> deliver web profile + MDBs, but without web services and RMI
>> if I want?
>>
>> Thanks,
>> Jim Knutson
>> WebSphere Java EE Architect
>>
>>
>
>
>
>
>