Adrian Brock wrote:
I see a number of possible use cases here
(I'll continue with appserver example):
1) Fully JSR 277
The appserver and JavaEE specs are updated to fully understand
JSR277/294. In this case, the JavaEE deployment process would
probably make use of a JSR 277 repository.
2)
Adrian Brock wrote:
So a 291 module that hasn't been updated to reflect changes from 294
would just expose package exports and the importing 277 module
would know how to deal with that?
A 291 module which exports packages is fundamentally exporting public
types, which will continue to work
Hi Adrian,
Adrian Brock wrote:
My critisms of using the JSR277 repositories to do the integration
included:
I want to better understand your concerns around developing
repositories, since I believe some of your concerns have already been
addressed in the draft API.
* There are already
Hi Adrian,
Adrian Brock wrote:
On Mon, 2008-04-28 at 20:16 -0700, Stanley M. Ho wrote:
3.2 ModuleDefinition class
Two new methods are added in the ModuleDefinition class to return the
exported packages and member packages respectively. The export and
member definitions contained in the OSGi
Dear 277 observers,
The original message is too big for this observer list, so I forward the
original message with first attachment only. If any of you are
interested in getting the latest API javadoc, please send email to
[EMAIL PROTECTED]
- Stanley
Dear 277 experts,
The first
Hi Brett,
We are in the process of finalizing the document, and hopefully we could
provide more details to the EG next week.
- Stanley
Brett Porter wrote:
On 03/04/2008, at 1:27 PM, Stanley M. Ho wrote:
The good news is that we now have a prototype that allows JSR 277
modules
The current APis do not prohibit module definition to have split
packages. It is only when a Java module is instantiated from the module
definition, the implementation of the default module system would
perform shallow validation and consider split packages as an error.
Other module system
Hi Glyn,
The work is in progress, and there are ongoing prototypings to figure
out how it should work and to also validate the overall approach. I will
send out the strawman proposal for the EG to review and discuss when it
is ready. Interoperability is definitely something that I would like to
Hi Bryan,
Bryan Atsatt wrote:
Um, I'm not arguing about the restriction in custom import policies, I
certainly understand why that is present.
I'm saying that an initializer *should* be able to rely on imported
modules, so we need a separate mechanism. And that separate mechanism
would kick in
Hi Bryan,
Bryan Atsatt wrote:
Custom import policies cannot leverage any other modules; this would be
a severe limitation for an initialization mechanism.
There are good reasons why there is such restriction. When the module is
being initialized, its imported modules might also be in the
Bryan Atsatt wrote:
Stanley, I assume you are proposing a general mechanism in which any
code can register listeners? If so, then I have to agree with Glyn that
this is not sufficient to implement a module activator.
The mechanism I have in mind can be registered only by code that have
the
Hi Glyn,
Glyn Normington wrote:
Yes, but my point was that separating lifecycle out in that way would
make it harder to enforce constraints like if a module's state is
initialised, the module's activator completed successfully.
The mechanism I suggested is simply for informing the
My original email did not seem to go through ... resend.
- Stanley
Original Message
Subject: Re: Strawman: Services and service-providers support
Date: Tue, 12 Jun 2007 17:07:05 -0700
From: Stanley M. Ho [EMAIL PROTECTED]
Organization: Sun Microsystems, Inc.
To: Java Community
Resend.
Bryan Atsatt wrote:
...
Stanley's idea was that a Repository implementation could return a
*copy* of a ModuleDefinition created by a different Repository. Such a
Repository would in fact form an isolation context. And caching Module
instances becomes trivial: each definition can just
This is a resend.
Glyn Normington wrote:
Hi Stanley
Any chance of updating the public part of the JSR 277 page?
The content of the public page is for the original JSR proposal, and is
administrated and maintained by the JCP PMO office. I have contacted the
office and the answer is no.
Hi Bryan,
Bryan Atsatt wrote:
How are people supposed to find this? Shouldn't there be an easily
spotted link somewhere on the public 277 page?
Yes, it is mentioned in the JSR 277 community update page:
http://jcp.org/en/egc/view?id=277
but unfortunately it requires JCP member login.
It is
Hi Bryan,
I would like to get closures on a few open issues first, so my responses
will be limited to those threads rather than all the new threads that
have been started recently.
Bryan Atsatt wrote:
Hi Stanley,
Sorry if I'm not being clear. Let me try to summarize:
- I *do* want 277 to
Bryan Atsatt wrote:
And we haven't done so in the spec, either. I think we should.
Query was not declared as Serializable in the spec because it was
unclear if we wanted to allow custom Query implementations and how it
might impact these custom Query implementations.
Now that we have decided
Hi Bryan,
Bryan Atsatt wrote:
...
Rather than surfacing the import-by-package at the API level, I think we
can solve #3 by generalizing the import dependency concept as
import-by-name, and this name can be mapped to superpackage-name in JSR
277 and OSGi-bundle-name or OSGi-exported-package-name
Hi,
Glyn Normington wrote:
*Bryan Atsatt [EMAIL PROTECTED]* wrote on 30/05/2007 07:57:59:
...
So the open issue is the richness of the import language: must we
support only lowest-common-denominator, or can we do better without
over-complicating the design?
I for one would like to be
Hi Richard,
Richard S. Hall wrote:
Hey Stanley,
...
To me, this sounds like what we call the extender model for the OSGi
framework. The way it works is that bundles that want to participate in
certain scenarios simply include some metadata inside of themselves,
then some infrastructure can
21 matches
Mail list logo
