Changing AttributeDefinition default for allowExpressions
by Tomaz Cerar
Hi,
Given lots of input from different channels it would make sense to change default for all AttributeDefintions to have allowExpresions set to true.
That would come into play for all code that uses AttributeDefintion but would not apply to those subsystems not yet converted AS7-4788
It would still make be possible to disable support for expressions if you explicitly do not want them.
But please note that even if we do change default to true, it would still not work for all use cases as many subsystems still do not properly parse xml / read model to actually benefit from this
but it would still solve many issues when all rules are obeyed but attribute was not marked to support expressions.
wdyt?
--
tomaz
13 years, 12 months
session replication don't work within different server
by 陈操
Hi all:
I am using JBoss EAP 6.0.0.GA (AS 7.1.2.Final-redhat-1)
When I startup 2 nodes in the same server, it work fine. below is the
command:
./standalone.sh -Djboss.node.name=jb1 --server-config=standalone-ha.xml
./standalone.sh -Djboss.node.name=jb2 --server-config=standalone-ha.xml
-Djboss.socket.binding.port-offset=100
But, if 2 nodes within different server(172.16.105.234 for node1,
172.16.105.235 for node2), session replication is only work from 235 to
234. command:
./standalone.sh --server-config=standalone-ha.xml -b 172.16.105.234
-bmanagement 172.16.105.234 -Djboss.node.name=jb2
./standalone.sh --server-config=standalone-ha.xml -b 172.16.105.235
-bmanagement 172.16.105.235 -Djboss.node.name=jb3
anyone could help me?
--
致
礼
==========================
///
(. .)
-----ooO--(_)--Ooo-----
My Team's home site：http://www.imobive.com
===============================================================
本邮件及其附件含有公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information, which is
intended only for the person or entity whose address is listed above. Any
use of the information contained herein in any way (including, but not
limited to,total or partial disclosure, reproduction, or dissemination) by
persons other than the intended recipient(s) is prohibited. If you receive
this e-mail in error, please notify the sender by phone or email
immediately and delete it!
13 years, 12 months
ClassLoader leak in branch 7.1
by Thomas Diesler
Folks,
we have a CL leak in branch 7.1, which makes pull request validation
difficult. Is this being taken care of? Who do I need to talk to about this?
Running org.jboss.as.test.manualmode.classloading.leak.ClassloaderLeakWarTestCase
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.14 sec <<< FAILURE!
Running org.jboss.as.test.manualmode.classloading.leak.ClassloaderLeakEarTestCase
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 33.728 sec <<< FAILURE!
http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-param-pull/330...
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years
JBoss Modules & object serialization
by Jeff Mesnil
I'm working on a messaging issue[1] where an user can not deserialize a JMS ObjectMessage that contains an org.w3c.dom.Document
object (an instance of org.apache.xerces.dom.DocumentImpl loaded from module "org.apache.xerces:main").
HornetQ is not able to deserialize the document object and fails with a CNFE:
java.lang.ClassNotFoundException: org.apache.xerces.dom.DocumentImpl from [Module "org.hornetq:main" from local module
loader @23aa0933 (roots:
/home/jmesnil/Developer/jboss-as/testsuite/integration/smoke/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules)]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
Doing some debugging, it appears that HornetQ is not able to find the class in the TCCL (it then tries to resolve it with its
own classloader, hence the exception above)
Trying to understand the root cause, I have a simple test[2] that creates a DOM document inside a Servlet, serialize it and
unserialize it.
The test fails when I deserialize it with a CNFE from the TCCL:
java.lang.ClassNotFoundException: org.apache.xerces.dom.DocumentImpl from [Module
"deployment.objectmessage.ear.objectmessage.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
at java.lang.Class.forName0(Native Method)
I was expecting this test to succeed. Is there a reason why I could not deserialize a class in the same context that I have
serialized it?
Thanks,
jeff
[1] https://issues.jboss.org/browse/AS7-1271
[2]
https://github.com/jmesnil/jboss-as/blob/AS7-1271_ObjectMessage_Classload...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
14 years
Inclusion of War in AS Distribution
by Darran Lofthouse
Hello all,
I am just finishing off some tasks regarding JBoss Negotiation for the
next AS 7 tags and one task I am looking at is how users can access the
war that is recommended for testing an installation before adding the
complexity of integrating with their own application. At the moment it
is difficult as users tend to need to download the war from the maven repo.
I am wondering would it make sense to include it under: -
{jboss.home}/docs/examples/kerberos
Alternatively I could remove it from the JBoss Negotiation project and
add it as a quickstart, however it is dependent on a number of
configuration steps being performed before a user can use it.
Regards,
Darran Lofthouse.
14 years
Re: [jboss-as7-dev] Fwd: Late for the train
by Andrew Dinn
On 27/07/12 11:21, Geoffrey De Smet wrote:
> It's up to the "conflict resolution" and "classpath/modulepath" specs to
> decide how to deal with the obvious version conflict in your example.
> In a modulepath world (= a graph of dependencies, just like Maven and
> OSGi), it could run both X-1.0.0 and X-1.1.0 simultaneously (if pluginA
> and pluginB don't communicate to each other with X).
Well, yes but that's the hard bit isn't it? -- what to do if they do
communicate with each other? Thomas is right that it is hard to manage
this by hand when you have an ecosystem the size of EE. But the tools
which are supposed to automate this clearly don't work very well either.
Personally, I think automation is a pipe dream but your mileage may vary.
Anyway that's not really why I am responding here. There is a more
important point to make here which this strand of the discussion has
really brought to the surface. The real problem we are facing here is
how we reconcile the different needs of JDK (and relatively small-scale)
app modularization vs EE middleware and EE app modularization. Jigsaw is
providing a conventional module mechanism as used by many other
languages for structuring both the base runtime and components of an
application. That's not only a useful thing to do it is actually vital
for the health of the JDK runtime.
Suggesting that this does not address the needs of EE libraries is not a
valid gambit. If Jigsaw answers real requirements for structuring Java
app code without dealing with the problems EE poses then it has done its
job. Providing a mechanism that will support the scale and complexity of
interdependence that EE and the many application libaries, components
and frameworks which sit on top of EE is not a problem Jigsaw /has/ to
solve. Clearly, as it currently stands it won't solve those problems
because baking modules into the code means resolving conflicts requires
rereleasing code and that's just not feasible on the scale of EE
middleware/apps -- something will always be broken no matter how fast
teh release cycles.
Now there's not necessarily any problem if we just leave it at that. A
conventional module system like Jigsaw provides certain capabilities for
structuring and managing code components, an EE module system like OSGi
or JBoss Modules provides alternative capabilities. In theory we can
have and use both mechanisms. However the dangers we face if we have two
ways of doing these two things are obvious: i) the two mechanisms will
be conflated and the wrong mechanism selected for managing specific
versioning/update requirements; and/or, worse, ii) the two different
(types of) mechanism(s) will not be defined with understanding of each
other's competing needs and hence use of one will invalidate or severely
compromise use of the other.
This is why it is critical that we get some purchase on the Jigsaw
project. Not to 'correct' it and certainly not to 'derail' it. Just to
make sure that we can arrive somewhere which avoids these two potential
dangers. So, much as I feel this discussion is now making good forward
progress the really important thing is to ensure that it feeds into the
Jigsaw project.
regards,
Andrew Dinn
-----------
14 years
Re: [jboss-as7-dev] Fwd: Late for the train
by Thomas Diesler
> it could run both X-1.0.0 and X-1.1.0 simultaneously
Well said. It (the resolver) could! It is not the responsibility or
either pluginA nor pluginB to provide the wiring metadata. Nor can this
decision (based on module identity) be made at build time.
On 07/27/2012 12:21 PM, Geoffrey De Smet wrote:
> Op 27-07-12 12:04, Thomas Diesler schreef:
>> > a 1 to 1 mapping from a jar (which is the unit of release) to a
>> "module identification" (which is the unit of reuse)
>>
>> Yes, if you use a system of "module identification" to build a wiring
>> graph this is important. I claim that this approach is flawed for
>> complex systems where the provider of moduleA does not know about
>> moduleB. Perhaps you like to show a solution to the simple problem
>> that I mentioned?
>>
>> Here it is again: pluginA has a requirement on libraryX-1.0.0 and
>> pluginB has a requirement on libraryX-1.1.0. How do you propose that
>> libraryX is distributed in the target system?
> I am sorry, I don't see the distribution problem.
>
> The distribution system could use the same principle of RPM's and
> Maven (which both follow the release/reuse principle):
> Grab the artifact from a repository and put it into a local cache of
> that repository (which might be zipped into the release zip of pluginA).
> Both libraryX-1.0.0.jar and libraryX-1.1.0.jar are in that local cache
> of that repository.
> The advantage of "reuse/release" principle is, based on a moduleId,
> the jar can easily and unambiguously found in a repository.
>
> It's up to the "conflict resolution" and "classpath/modulepath" specs
> to decide how to deal with the obvious version conflict in your example.
> In a modulepath world (= a graph of dependencies, just like Maven and
> OSGi), it could run both X-1.0.0 and X-1.1.0 simultaneously (if
> pluginA and pluginB don't communicate to each other with X).
>
> With kind regards,
> Geoffrey De Smet
>>
>> On 07/27/2012 11:48 AM, Geoffrey De Smet wrote:
>>> Op 27-07-12 11:22, Thomas Diesler schreef:
>>>> Geoffrey,
>>>>
>>>> > unlike OSGi - the unit of reuse is the unit of release
>>> Let me clarify that concept, as you're interpreting it very
>>> differently than me.
>>>
>>> It just means: We are releasing "jars", so there must be a 1 to 1
>>> mapping from a jar (which is the unit of release) to a "module
>>> identification" (which is the unit of reuse).
>>> Unlike OSGi, a single jar, for example "foo.jar", can not export 2
>>> or more module identifications, such as "org.foo:bar1" and
>>> "org.foo:bar2".
>>> Instead, it exports only 1 module identification, for example
>>> "org.foo:foo".
>>> (For simplicity I am ignoring versions in the example above).
>>>
>>> This is important, because client-modules declare their dependencies
>>> using module identifications.
>>> In your example:
>>> pluginA depends on libraryX 1.0.0
>>> pluginB depends on libraryX 1.1.0
>>> That means there should be exactly 1 libraryX-1.0.0.jar and exactly
>>> 1 libraryX-1.1.0.jar.
>>> In OSGi, libraryX-1.0.0 could as well be in the pluto-5.0.0.jar,
>>> intermingled with the modules libraryY-2.0.0 and libraryZ-1.2.0.
>>> And libraryX-1.1.0 could be in the saturn-0.1.0.jar, intermingled
>>> with the module libraryZ-1.0.0.
>>>
>>> More info here:
>>> libraryX-1.0.0 could as well be in the pluto-5.0.0.jar,
>>> intermingled with the modules libraryY-2.0.0 and libraryZ-1.2.0.
>>>>
>>>> in an ecosystem of distributed module providers, how can one
>>>> provider reason about the requirements of another provider such
>>>> that their requirements converge? Any complex system that has the
>>>> notion of plugin would face this problem. For example, pluginA has
>>>> a requirement on libraryX-1.0.0 and pluginB has a requirement on
>>>> libraryX-1.1.0. How do you propose that libraryX is distributed in
>>>> the target system?
>>>>
>>>> Here some options:
>>>>
>>>> #1 libraryX is available in both versions. pluginA/B bind to their
>>>> respective versions
>>>> #2 libraryX is available in the highest compatible version (i.e.
>>>> libraryX-1.1.0). pluginA/B bind to that
>>>>
>>>> The problem with #1 is that it fails (is inconsistent) as soon as
>>>> pluginA/B exchange a type from libraryX - you get a CCE
>>>> The problem with #2 is that you have to touch pluginA's wiring
>>>> metadata - which contradicts "unit of reuse is the unit of release".
>>> No, it doesn't: the "unit of reuse is the unit of release"
>>> restriction states nothing when dependencies should be resolved and
>>> whether or not it can be overwritten at runtime.
>>>> pluginA must know that pluginB exists, which it cannot because A/B
>>>> may be installed independently on user request.
>>>>
>>>> ...
>>>>
>>>> In a nutshell: "unit of reuse is the unit of release" is too
>>>> simplistic for complex modularity systems
>>> No, see clarification of this principle above.
>>>
>>> With kind regards,
>>> Geoffrey De Smet
>>>>
>>>> cheers
>>>> -thomas
>>>>
>>>>
>>>> On 07/18/2012 09:07 AM, Geoffrey De Smet wrote:
>>>>> From what I 've read so far about Jigsaw, I like it.
>>>>> It would have consistent resolution (unlike OSGi - the unit of
>>>>> reuse is the unit of release),
>>>>> it would be straightforward (unlike Maven - there would be no
>>>>> "Maven dependency puzzlers").
>>>>> And it would allow for runtime optimization.
>>>>> So basically, it would be JBoss modules ;)
>>>>>
>>>>> Anything particular why it would be a train wreck?
>>>>>
>>>>> With kind regards,
>>>>> Geoffrey De Smet
>>>>>
>>>>> Op 17-07-12 18:11, David M. Lloyd schreef:
>>>>>> This is actually great news for us... Jigsaw is a train wreck.
>>>>>> Maybe we'll have a chance to get in this game after all.
>>>>>>
>>>>>> -------- Original Message --------
>>>>>> Subject: Late for the train
>>>>>> Date: Tue, 17 Jul 2012 08:57:39 -0700
>>>>>> From: mark.reinhold(a)oracle.com
>>>>>> To: jigsaw-dev(a)openjdk.java.net
>>>>>>
>>>>>> As some of you are already aware, I've concluded with regret that
>>>>>> Project
>>>>>> Jigsaw isn't going to make Java 8 as planned. I've set out my
>>>>>> reasoning
>>>>>> in a blog entry [1], and I've asked the Java SE 8 EG to consider
>>>>>> dropping
>>>>>> the module system and modularization from the release [2].
>>>>>>
>>>>>> Slipping Jigsaw to Java 9 isn't an easy decision, but I think
>>>>>> it's the
>>>>>> best of a set of unpleasant options. We've made a lot of
>>>>>> progress over
>>>>>> the past year, and I'm determined that we do our best to maintain
>>>>>> our
>>>>>> momentum from here to Java 9. I thank those who've contributed
>>>>>> to this
>>>>>> effort so far, in ways both large and small, and I hope you'll
>>>>>> all be
>>>>>> able to stay aboard for the rest of the journey.
>>>>>>
>>>>>> - Mark
>>>>>>
>>>>>>
>>>>>> [1] http://mreinhold.org/blog/late-for-the-train
>>>>>> [2]
>>>>>> http://mail.openjdk.java.net/pipermail/java-se-8-spec-observers/2012-July...
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years
ARQ configuration properties
by Thomas Diesler
Hi Aslak,
could you please remind me how properties on the ContainerConfiguration
are supposed to get handled. I vaguely remember that there was some auto
magic fall back to system properties if not specified in arquillian.xml.
In AS7 ManagedContainerConfiguration we access system properties
explicitly, is this right?
https://github.com/jbossas/jboss-as/pull/2755/files?_nid=65796751#r1250241
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years
Re: [jboss-as7-dev] Fwd: Late for the train
by Thomas Diesler
> a 1 to 1 mapping from a jar (which is the unit of release) to a
"module identification" (which is the unit of reuse)
Yes, if you use a system of "module identification" to build a wiring
graph this is important. I claim that this approach is flawed for
complex systems where the provider of moduleA does not know about
moduleB. Perhaps you like to show a solution to the simple problem that
I mentioned?
Here it is again: pluginA has a requirement on libraryX-1.0.0 and
pluginB has a requirement on libraryX-1.1.0. How do you propose that
libraryX is distributed in the target system?
On 07/27/2012 11:48 AM, Geoffrey De Smet wrote:
> Op 27-07-12 11:22, Thomas Diesler schreef:
>> Geoffrey,
>>
>> > unlike OSGi - the unit of reuse is the unit of release
> Let me clarify that concept, as you're interpreting it very
> differently than me.
>
> It just means: We are releasing "jars", so there must be a 1 to 1
> mapping from a jar (which is the unit of release) to a "module
> identification" (which is the unit of reuse).
> Unlike OSGi, a single jar, for example "foo.jar", can not export 2 or
> more module identifications, such as "org.foo:bar1" and "org.foo:bar2".
> Instead, it exports only 1 module identification, for example
> "org.foo:foo".
> (For simplicity I am ignoring versions in the example above).
>
> This is important, because client-modules declare their dependencies
> using module identifications.
> In your example:
> pluginA depends on libraryX 1.0.0
> pluginB depends on libraryX 1.1.0
> That means there should be exactly 1 libraryX-1.0.0.jar and exactly 1
> libraryX-1.1.0.jar.
> In OSGi, libraryX-1.0.0 could as well be in the pluto-5.0.0.jar,
> intermingled with the modules libraryY-2.0.0 and libraryZ-1.2.0.
> And libraryX-1.1.0 could be in the saturn-0.1.0.jar, intermingled with
> the module libraryZ-1.0.0.
>
> More info here:
> libraryX-1.0.0 could as well be in the pluto-5.0.0.jar, intermingled
> with the modules libraryY-2.0.0 and libraryZ-1.2.0.
>>
>> in an ecosystem of distributed module providers, how can one provider
>> reason about the requirements of another provider such that their
>> requirements converge? Any complex system that has the notion of
>> plugin would face this problem. For example, pluginA has a
>> requirement on libraryX-1.0.0 and pluginB has a requirement on
>> libraryX-1.1.0. How do you propose that libraryX is distributed in
>> the target system?
>>
>> Here some options:
>>
>> #1 libraryX is available in both versions. pluginA/B bind to their
>> respective versions
>> #2 libraryX is available in the highest compatible version (i.e.
>> libraryX-1.1.0). pluginA/B bind to that
>>
>> The problem with #1 is that it fails (is inconsistent) as soon as
>> pluginA/B exchange a type from libraryX - you get a CCE
>> The problem with #2 is that you have to touch pluginA's wiring
>> metadata - which contradicts "unit of reuse is the unit of release".
> No, it doesn't: the "unit of reuse is the unit of release" restriction
> states nothing when dependencies should be resolved and whether or not
> it can be overwritten at runtime.
>> pluginA must know that pluginB exists, which it cannot because A/B
>> may be installed independently on user request.
>>
>> ...
>>
>> In a nutshell: "unit of reuse is the unit of release" is too
>> simplistic for complex modularity systems
> No, see clarification of this principle above.
>
> With kind regards,
> Geoffrey De Smet
>>
>> cheers
>> -thomas
>>
>>
>> On 07/18/2012 09:07 AM, Geoffrey De Smet wrote:
>>> From what I 've read so far about Jigsaw, I like it.
>>> It would have consistent resolution (unlike OSGi - the unit of reuse
>>> is the unit of release),
>>> it would be straightforward (unlike Maven - there would be no
>>> "Maven dependency puzzlers").
>>> And it would allow for runtime optimization.
>>> So basically, it would be JBoss modules ;)
>>>
>>> Anything particular why it would be a train wreck?
>>>
>>> With kind regards,
>>> Geoffrey De Smet
>>>
>>> Op 17-07-12 18:11, David M. Lloyd schreef:
>>>> This is actually great news for us... Jigsaw is a train wreck.
>>>> Maybe we'll have a chance to get in this game after all.
>>>>
>>>> -------- Original Message --------
>>>> Subject: Late for the train
>>>> Date: Tue, 17 Jul 2012 08:57:39 -0700
>>>> From: mark.reinhold(a)oracle.com
>>>> To: jigsaw-dev(a)openjdk.java.net
>>>>
>>>> As some of you are already aware, I've concluded with regret that
>>>> Project
>>>> Jigsaw isn't going to make Java 8 as planned. I've set out my
>>>> reasoning
>>>> in a blog entry [1], and I've asked the Java SE 8 EG to consider
>>>> dropping
>>>> the module system and modularization from the release [2].
>>>>
>>>> Slipping Jigsaw to Java 9 isn't an easy decision, but I think it's the
>>>> best of a set of unpleasant options. We've made a lot of progress
>>>> over
>>>> the past year, and I'm determined that we do our best to maintain our
>>>> momentum from here to Java 9. I thank those who've contributed to
>>>> this
>>>> effort so far, in ways both large and small, and I hope you'll all be
>>>> able to stay aboard for the rest of the journey.
>>>>
>>>> - Mark
>>>>
>>>>
>>>> [1] http://mreinhold.org/blog/late-for-the-train
>>>> [2]
>>>> http://mail.openjdk.java.net/pipermail/java-se-8-spec-observers/2012-July...
>>>>
>>>
>>>
>>
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years
Re: [jboss-as7-dev] Fwd: Late for the train
by Thomas Diesler
Geoffrey,
> unlike OSGi - the unit of reuse is the unit of release
in an ecosystem of distributed module providers, how can one provider
reason about the requirements of another provider such that their
requirements converge? Any complex system that has the notion of plugin
would face this problem. For example, pluginA has a requirement on
libraryX-1.0.0 and pluginB has a requirement on libraryX-1.1.0. How do
you propose that libraryX is distributed in the target system?
Here some options:
#1 libraryX is available in both versions. pluginA/B bind to their
respective versions
#2 libraryX is available in the highest compatible version (i.e.
libraryX-1.1.0). pluginA/B bind to that
The problem with #1 is that it fails (is inconsistent) as soon as
pluginA/B exchange a type from libraryX - you get a CCE
The problem with #2 is that you have to touch pluginA's wiring metadata
- which contradicts "unit of reuse is the unit of release". pluginA must
know that pluginB exists, which it cannot because A/B may be installed
independently on user request.
Generally, in a complex modular system it must be possible to reason
about A without having to think/know about B. Following this principal
it not possible to make build time (release time) decisions that are
guaranteed to be consistent at runtime. Instead you need to have an
external authority that guarantees runtime consistency based on
capabilities/requirements that can be defined at build time.
It's easy to see that a system based on human wiring decisions (may they
be in manifest.mf, modules.xml or hard coded in DUPs) will fail as soon
as complexity increases beyond a point where it cannot be managed any
more by one team. It's in the nature of these complex systems that they
are developed by distributed teams that don't even know about their
respective existence.
In a nutshell: "unit of reuse is the unit of release" is too simplistic
for complex modularity systems
cheers
-thomas
On 07/18/2012 09:07 AM, Geoffrey De Smet wrote:
> From what I 've read so far about Jigsaw, I like it.
> It would have consistent resolution (unlike OSGi - the unit of reuse
> is the unit of release),
> it would be straightforward (unlike Maven - there would be no "Maven
> dependency puzzlers").
> And it would allow for runtime optimization.
> So basically, it would be JBoss modules ;)
>
> Anything particular why it would be a train wreck?
>
> With kind regards,
> Geoffrey De Smet
>
> Op 17-07-12 18:11, David M. Lloyd schreef:
>> This is actually great news for us... Jigsaw is a train wreck. Maybe
>> we'll have a chance to get in this game after all.
>>
>> -------- Original Message --------
>> Subject: Late for the train
>> Date: Tue, 17 Jul 2012 08:57:39 -0700
>> From: mark.reinhold(a)oracle.com
>> To: jigsaw-dev(a)openjdk.java.net
>>
>> As some of you are already aware, I've concluded with regret that
>> Project
>> Jigsaw isn't going to make Java 8 as planned. I've set out my reasoning
>> in a blog entry [1], and I've asked the Java SE 8 EG to consider
>> dropping
>> the module system and modularization from the release [2].
>>
>> Slipping Jigsaw to Java 9 isn't an easy decision, but I think it's the
>> best of a set of unpleasant options. We've made a lot of progress over
>> the past year, and I'm determined that we do our best to maintain our
>> momentum from here to Java 9. I thank those who've contributed to this
>> effort so far, in ways both large and small, and I hope you'll all be
>> able to stay aboard for the rest of the journey.
>>
>> - Mark
>>
>>
>> [1] http://mreinhold.org/blog/late-for-the-train
>> [2]
>> http://mail.openjdk.java.net/pipermail/java-se-8-spec-observers/2012-July...
>>
>
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years
