From jmesnil at redhat.com  Mon Jun  1 05:27:03 2015
From: jmesnil at redhat.com (Jeff Mesnil)
Date: Mon, 1 Jun 2015 11:27:03 +0200
Subject: [wildfly-dev] Transaction subsystem dependencies
In-Reply-To: <556881D6.1010804@redhat.com>
References: <55685A0F.6030405@redhat.com>
	<27530020.1447.1432906944030.JavaMail.andrigtmiller@worklaptop.miller.org>
	<5568737D.4000709@redhat.com>
	<18375281.1467.1432909055689.JavaMail.andrigtmiller@worklaptop.miller.org>
	<556881D6.1010804@redhat.com>
Message-ID: <F2B0B1E0-19EB-4570-AEB1-759DCF9EE285@redhat.com>


> On 29 May 2015, at 17:12, Michael Musgrove <mmusgrov at redhat.com> wrote:
> 
> Thanks,
> 
> I have added JBTM-2424 to get the dependency moved to hornetq-journal 
> (instead of hornetq-core).

Maybe you should move away from the hornetq-journal module and use instead the org.apache.activemq:artemis-journal instead.
HornetQ code has been donated to Apache ActiveMQ and is now in maintenance mode only.

I?ll soon submit a PR to replace HornetQ by ActiveMQ Artemis[1]. You?ll then be able to use its journal artifact afterwards. One related task is to clean up the HornetQ dependencies in WildFly modules. Ideally, I don?t want to keep any HornetQ dependency that could be replaced by an equivalent dependency to Artemis.

jeff

[1] https://issues.jboss.org/browse/WFLY-4584
-- 
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/



From mmusgrov at redhat.com  Mon Jun  1 10:48:15 2015
From: mmusgrov at redhat.com (Michael Musgrove)
Date: Mon, 01 Jun 2015 15:48:15 +0100
Subject: [wildfly-dev] 10.0.0.Alpha2 released & 9 status update
In-Reply-To: <D8B7AC23-7769-4D46-8445-CF7B10CC0390@redhat.com>
References: <D8B7AC23-7769-4D46-8445-CF7B10CC0390@redhat.com>
Message-ID: <556C70AF.4080708@redhat.com>

On 30/05/15 04:55, Jason Greene wrote:
> Hello Everyone,
>
> WildFly 10.0.0.Alpha2 and WildFly Core 2.0.0.Alpha3 are released.
>
> As a reminder, we are doing bi-weekly alpha releases of full, and weekly of core. Due to the high frequency, I am currently not publishing them to the website, so that it does not clutter the WildFly download page.
>
> I plan to redesign the download site in the coming weeks to better fit this new approach.
>
> In the meantime, you can download the Alpha stream from maven:
> https://repository.jboss.org/nexus/content/groups/developer/org/wildfly/wildfly-dist/10.0.0.Alpha2/wildfly-dist-10.0.0.Alpha2.zip
>
> Next week we are hoping to release 9 CR2. The last blocker is an issue with IIOP shutdown (requires a Naryana update). If all goes well it will be the last CR.

I have raised https://github.com/wildfly/wildfly/pull/7548 for the 
narayana update but it has what looks like unrelated intermittent test 
failures - I updated the PR with my evaluation. So I just need someone 
to take a look and agree that it is safe to merge my PR.

Mike

>
> Thanks!
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


-- 
Michael Musgrove
Red Hat UK Ltd, Transactions Team
e: mmusgrov at redhat.com
t: +44 191 243 0870

Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)


From smarlow at redhat.com  Mon Jun  1 11:08:39 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 01 Jun 2015 11:08:39 -0400
Subject: [wildfly-dev] Using a custom module to preview "next-gen"
 Hibernate versions on WildFly 9
In-Reply-To: <CAFm4XO1E2PXoZ=9swNK+L1FcLhR=QChMVognUAyvxV09fYNM0Q@mail.gmail.com>
References: <CAFm4XO1E2PXoZ=9swNK+L1FcLhR=QChMVognUAyvxV09fYNM0Q@mail.gmail.com>
Message-ID: <556C7577.80508@redhat.com>

I suspect that this is a bug in WildFly that we need to track down.  I'm 
guessing that the condition is that we are trying to use a custom 
Hibernate module when there is an existing Hibernate module that matches 
the Persistence provider name.  Or something like that.

On 05/21/2015 07:30 AM, Sanne Grinovero wrote:
> Hi all,
> I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1
> to use a preview of Hibernate ORM version 5.
>
> It seems the JPA deployer isn't allowing me to run such experiments:
>
> # First experiment - providerModule set to custom module
>
> In my first attempt, I create a custom set of jboss modules which
> include the snapshot builds of ORM 5, add them to my standalone WF9
> instance and set the persistence.xml property:
>   jboss.as.jpa.providerModule = my-custom-module-name
>
> and then get:
>
> Caused by: java.util.ServiceConfigurationError:
> org.hibernate.integrator.spi.Integrator: Provider
> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype
> at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51]
> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) [rt.jar:1.7.0_51]
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369)
> [rt.jar:1.7.0_51]
> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) [rt.jar:1.7.0_51]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341)
> at org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57)
> at org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188)
> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45)
> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57)
> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38)
> at org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173)
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243)
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60)
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118)
> ... 7 more
>
> Clearly it looks like I'm being served classes from the bundled
> Hibernate 4.x implementation - on top of those from the module I'm
> requesting. This isn't what the deployer should be doing, right?
>
> # Second experiment - use the "application provided"
>
> In this case I hope to hint the JPA  deployer to not add the default
> implementor but look for a JPA implementation within my deployment,
> but still package my custom Hibernate build as a module.
>
>   - use the same custom module containing Hibernate ORM 5 (a preview snapshot)
>   - Add a "Dependency:" section to the manifest to import (and export)
> my custom module
>   - set the "jboss.as.jpa.providerModule" property to value "application"
>
> This gets me:
>
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException:
> WFLYJPA0027: Persistence provider module load error application (class
> org.hibernate.jpa.HibernatePersistenceProvider)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131)
> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1]
> ... 5 more
> Caused by: org.jboss.modules.ModuleNotFoundException: application:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236)
> [jboss-modules.jar:1.4.3.Final]
> at org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978)
> ... 10 more
>
> Remarks:
>   - it's attempting to load the "application:main" module?! that's not
> what I'd expect from reading [1]
>   - the provider should be available to the deployment classpath, so
> I'm not sure why it's not finding the Provider? (I'm even exporting
> it, although I'm not sure if that was required).
>
> Any suggestions to get this running please?
>
> Also I wonder if some of these should warrant opening a JIRA, but I'm
> not sure how far I misunderstood the intentions of these JPA deployer
> properties.
>
> Thanks,
> Sanne
>
> [1] - https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties
>

From fjuma at redhat.com  Mon Jun  1 11:56:10 2015
From: fjuma at redhat.com (Farah Juma)
Date: Mon, 1 Jun 2015 11:56:10 -0400 (EDT)
Subject: [wildfly-dev] WildFly 10.0.0.Alpha2 is now on OpenShift
In-Reply-To: <493296206.7267342.1433173690754.JavaMail.zimbra@redhat.com>
Message-ID: <636161097.7269468.1433174170344.JavaMail.zimbra@redhat.com>

Details for getting started can be found in the usual location:

https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/wildfly-10

Enjoy!


From brian.stansberry at redhat.com  Mon Jun  1 12:07:29 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 01 Jun 2015 11:07:29 -0500
Subject: [wildfly-dev] Model attributes and default values
In-Reply-To: <5568718B.5040409@redhat.com>
References: <5568718B.5040409@redhat.com>
Message-ID: <556C8341.7060009@redhat.com>

You need to handle it yourself, which admittedly isn't ideal.

It's that way because doing a full resolution of "currentValue" isn't 
valid, as some factor in the resolution (say the value of a system prop) 
may have changed since the time that value was last resolved in the 
runtime. So you'd be finding out what it resolved to right now, not what 
it was.

If currentValue is undefined you can call getAttributeDefinition to get 
the AD and then get the default value via 
AttributeDefinition.getDefaultValue().

If currentValue is an expression you basically have to make an 
assumption that the value has changed. Which makes sense; why would a 
user mutate an attribute except to make a changed?

A simple enhancement we could look at would be to encapsulate the above 
in a protected method on AbstractWriteAttributeHandler.

On 5/29/15 9:02 AM, Alessio Soldano wrote:
> Hi,
> QA has been testing various value transitions on the attributes in the
> webservices subsystem of the model and found something unexpected for
> attributes with default values. I had a look and found that when running
> the following commands:
>
> /subsystem=webservices:undefine-attribute(name=modify-wsdl-address)
> reload
> /subsystem=webservices:undefine-attribute(name=modify-wsdl-address)
>
> for the last command the
> WSServerConfigAttributeHandler#applyUpdateToRuntime method is passed
> true as resolvedValue and undefined as currentValue. The resolvedValue
> being true is because of the default value for that attribute being
> true, but is it correct to get undefined as currentValue in that case?
> Do I have to manually figure out there's a default value for the
> attribute and hence decide nothing was changed if currentValue is
> undefined and resolvedValue equals default value... or is there's a
> specific way to deal with this scenario?
>
> Thanks
> Alessio
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From asoldano at redhat.com  Mon Jun  1 12:24:12 2015
From: asoldano at redhat.com (Alessio Soldano)
Date: Mon, 01 Jun 2015 18:24:12 +0200
Subject: [wildfly-dev] Model attributes and default values
In-Reply-To: <556C8341.7060009@redhat.com>
References: <5568718B.5040409@redhat.com> <556C8341.7060009@redhat.com>
Message-ID: <556C872C.1090703@redhat.com>

Thanks Brian,
will try and send a PR / let you know.

Alessio

On 01/06/15 18:07, Brian Stansberry wrote:
> You need to handle it yourself, which admittedly isn't ideal.
>
> It's that way because doing a full resolution of "currentValue" isn't
> valid, as some factor in the resolution (say the value of a system prop)
> may have changed since the time that value was last resolved in the
> runtime. So you'd be finding out what it resolved to right now, not what
> it was.
>
> If currentValue is undefined you can call getAttributeDefinition to get
> the AD and then get the default value via
> AttributeDefinition.getDefaultValue().
>
> If currentValue is an expression you basically have to make an
> assumption that the value has changed. Which makes sense; why would a
> user mutate an attribute except to make a changed?
>
> A simple enhancement we could look at would be to encapsulate the above
> in a protected method on AbstractWriteAttributeHandler.
>
> On 5/29/15 9:02 AM, Alessio Soldano wrote:
>> Hi,
>> QA has been testing various value transitions on the attributes in the
>> webservices subsystem of the model and found something unexpected for
>> attributes with default values. I had a look and found that when running
>> the following commands:
>>
>> /subsystem=webservices:undefine-attribute(name=modify-wsdl-address)
>> reload
>> /subsystem=webservices:undefine-attribute(name=modify-wsdl-address)
>>
>> for the last command the
>> WSServerConfigAttributeHandler#applyUpdateToRuntime method is passed
>> true as resolvedValue and undefined as currentValue. The resolvedValue
>> being true is because of the default value for that attribute being
>> true, but is it correct to get undefined as currentValue in that case?
>> Do I have to manually figure out there's a default value for the
>> attribute and hence decide nothing was changed if currentValue is
>> undefined and resolvedValue equals default value... or is there's a
>> specific way to deal with this scenario?
>>
>> Thanks
>> Alessio
>>
>


-- 
Alessio Soldano
Web Service Lead, JBoss


From tadamski at redhat.com  Mon Jun  1 12:37:54 2015
From: tadamski at redhat.com (Tomasz Adamski)
Date: Mon, 1 Jun 2015 12:37:54 -0400 (EDT)
Subject: [wildfly-dev] 10.0.0.Alpha2 released & 9 status update
In-Reply-To: <556C70AF.4080708@redhat.com>
References: <D8B7AC23-7769-4D46-8445-CF7B10CC0390@redhat.com>
	<556C70AF.4080708@redhat.com>
Message-ID: <1293838532.7402776.1433176674081.JavaMail.zimbra@redhat.com>

I had to add another fix to iiop subsystem: switch POA destruction to synchronous mode. 
I have created a PR: https://github.com/wildfly/wildfly/pull/7552 which consist of this fix + update openjdk library to final version.
With those changes ORB reload seems to work correctly - I have tested it and wasn't able to reproduce any of previously occurring errors.

-- 
Tomasz Adamski
Software Engineer
JBoss by Red Hat 

----- Mail original -----
> De: "Michael Musgrove" <mmusgrov at redhat.com>
> ?: "Jason Greene" <jason.greene at redhat.com>, "Wildfly Developers" <wildfly-dev at lists.jboss.org>
> Envoy?: Lundi 1 Juin 2015 16:48:15
> Objet: Re: [wildfly-dev] 10.0.0.Alpha2 released & 9 status update
> 
> On 30/05/15 04:55, Jason Greene wrote:
> > Hello Everyone,
> >
> > WildFly 10.0.0.Alpha2 and WildFly Core 2.0.0.Alpha3 are released.
> >
> > As a reminder, we are doing bi-weekly alpha releases of full, and weekly of
> > core. Due to the high frequency, I am currently not publishing them to the
> > website, so that it does not clutter the WildFly download page.
> >
> > I plan to redesign the download site in the coming weeks to better fit this
> > new approach.
> >
> > In the meantime, you can download the Alpha stream from maven:
> > https://repository.jboss.org/nexus/content/groups/developer/org/wildfly/wildfly-dist/10.0.0.Alpha2/wildfly-dist-10.0.0.Alpha2.zip
> >
> > Next week we are hoping to release 9 CR2. The last blocker is an issue with
> > IIOP shutdown (requires a Naryana update). If all goes well it will be the
> > last CR.
> 
> I have raised https://github.com/wildfly/wildfly/pull/7548 for the
> narayana update but it has what looks like unrelated intermittent test
> failures - I updated the PR with my evaluation. So I just need someone
> to take a look and agree that it is safe to merge my PR.
> 
> Mike
> 
> >
> > Thanks!
> >
> > --
> > Jason T. Greene
> > WildFly Lead / JBoss EAP Platform Architect
> > JBoss, a division of Red Hat
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> --
> Michael Musgrove
> Red Hat UK Ltd, Transactions Team
> e: mmusgrov at redhat.com
> t: +44 191 243 0870
> 
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US),
> Michael O'Neill(Ireland)
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 


From brian.stansberry at redhat.com  Mon Jun  1 13:13:33 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 01 Jun 2015 12:13:33 -0500
Subject: [wildfly-dev] HTTP API support for plain JBoss-CLI commands
In-Reply-To: <18079FF4-F04E-4070-9581-669FBC23EDDE@redhat.com>
References: <CAJZnQ0-mvtrv6XPrdEref8iEXjkp_z6ArCJ67Ks6vVBzQC5rsw@mail.gmail.com>	<90CA789A-ACFA-4129-BED5-40E7087EC6D3@redhat.com>	<C0C996B8-DF34-4AF1-8A8D-BBA275824818@redhat.com>	<CAJZnQ0_Hnc7OENJ+=mJJA0whc8Gx_zrjq-quzr6EfA+vetfY1Q@mail.gmail.com>	<BE95B144-76AC-4362-98BC-09DF9FC8963A@redhat.com>	<CAJZnQ08NecSRgKxroL1RZ=zwcF_fHUJ_iAatxC2MhjgqMa65Lg@mail.gmail.com>	<55685A0C.4000102@jboss.com>	<CAJZnQ0-eVKCtRZ-CXx2y6HGJQAq5xtpJ5brRuU1qdEufum9QAQ@mail.gmail.com>	<556860DF.2050308@jboss.com>
	<55687907.80008@redhat.com>	<C2BF57C3-0452-42F4-9A83-E5935951E33F@redhat.com>	<5568A161.4020002@redhat.com>
	<18079FF4-F04E-4070-9581-669FBC23EDDE@redhat.com>
Message-ID: <556C92BD.5080903@redhat.com>

On 5/29/15 12:48 PM, Jason T. Greene wrote:
>
>> On May 29, 2015, at 12:27 PM, Emmanuel Hugonnet <ehugonne at redhat.com> wrote:
>>
>>
>>
>> Le 29/05/2015 18:52, Jason Greene a ?crit :
>>>
>>>> On May 29, 2015, at 9:34 AM, Alexey Loubyansky <alexey.loubyansky at redhat.com> wrote:
>>>>
>>>>> On 05/29/2015 02:51 PM, Darran Lofthouse wrote:
>>>>> What we really have internally is a HTTP management interface and we
>>>>> used to expose a native (JBoss Remoting) management interface that the
>>>>> CLI would connect to - subsequently the CLI does connect to the HTTP
>>>>> management interface but it performs a HTTP upgrade to now talk Remoting
>>>>> over HTTP using DMR formatted messages.
>>>>>
>>>>> For the HTTP management interface json was selected as the payload type
>>>>> so that clients could be written in many languages that have libraries
>>>>> to talk HTTP and handle json.
>>>>>
>>>>> The CLI was then subsequently developed but with an emphasis on
>>>>> assisting administrators constructing a request so things like tab
>>>>> completion and automatic conversion.
>>>>>
>>>>> A couple of things this thread throws up that I think could be useful: -
>>>>>   - The ability to enter raw json requests into the CLI.
>>>>
>>>> There is a Jira issue open for this
>>>> https://issues.jboss.org/browse/WFCORE-418
>>>>
>>>>>   - The ability to output the json representation of a command
>>>>> constructed by the CLI.
>>>>
>>>> This is an easy one. There is echo-dmr command already. It could accept
>>>> --json argument to further transform the result to JSON.
>>>
>>> Additionally I think we need:
>>>
>>> - Ability to transform a ModelNode into CLI calls, and potentially code in various languages (WFCORE-721)
>>> - Enhance the HTTP server API to follow REST patterns, including JSON patching (WFCORE-722)
>>> - Add support for CLI style addressing within a ModelNode operation (instead of doing a list of kv pairs, you just pass it a CLI style address string(?/foo=bar/blah=something/etc=etc?)
>>
>> This last bit is already in WF9 ;) https://issues.jboss.org/browse/WFCORE-537
>> Emmanuel
>
> Awesome! I didn't realize it was already in.
>

That handles the address param in a more friendly fashion, but it's not 
full support of CLI syntax. That is this works now:

{
  "operation"="add",
  "address"="/foo=bar/blah=something/etc=etc",
  "thingy"=2
}

but "/foo=bar/blah=something/etc=etc:add(thingy=2)" would not.

>>
>>>
>>> --
>>> Jason T. Greene
>>> WildFly Lead / JBoss EAP Platform Architect
>>> JBoss, a division of Red Hat
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From brian.stansberry at redhat.com  Mon Jun  1 13:21:05 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 01 Jun 2015 12:21:05 -0500
Subject: [wildfly-dev] Capabilities and Requirements - Common Definitions
In-Reply-To: <55644A68.6090301@jboss.com>
References: <555F056B.3040406@jboss.com>	<555F27A2.2000306@redhat.com>	<555F3B66.2070700@jboss.com>	<555F586D.7060706@redhat.com>	<555F6D77.10108@jboss.com>	<555F6ED1.3030202@redhat.com>	<555F7022.4060201@jboss.com>
	<5560B7B5.7060203@redhat.com> <55644A68.6090301@jboss.com>
Message-ID: <556C9481.2020802@redhat.com>

I'm fine with that.

On 5/26/15 5:26 AM, Darran Lofthouse wrote:
> Ok so David's view is essentially my option one - we do this entirely by
> convention / documentation and have no shared constants.
>
> Everyone happy with this? Or any strong arguments towards having constants?
>
> Regards,
> Darran Lofthouse.
>
>
> On 23/05/15 18:24, David M. Lloyd wrote:
>> On 05/22/2015 01:06 PM, Darran Lofthouse wrote:
>>>
>>>
>>> On 22/05/15 19:00, David M. Lloyd wrote:
>>>> On 05/22/2015 12:55 PM, Darran Lofthouse wrote:
>>>>>
>>>>>
>>>>> On 22/05/15 17:25, Brian Stansberry wrote:
>>>>>> On 5/22/15 9:21 AM, Darran Lofthouse wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 22/05/15 13:57, Brian Stansberry wrote:
>>>>>>>> Thanks for raising this; it's a good set of questions.
>>>>>>>>
>>>>>>>> I'll be AFK for a week starting late today, so I'll start with point #2
>>>>>>>> even though that's backwards. It's just the one where I have a stronger
>>>>>>>> opinion.
>>>>>>>>
>>>>>>>> The controller module should be about basic API for creating resources,
>>>>>>>> attributes, handlers. Having other stuff like the actual
>>>>>>>> ModelControllerImpl in there isn't pure, but I don't mind much. But then
>>>>>>>> over time I and others have put some stuff in there basically just
>>>>>>>> because both server and host-controller use it. We need to move away
>>>>>>>> from that kind of thing, and not add more.
>>>>>>>
>>>>>>> I can move it to a different module but most likely I think that would
>>>>>>> be a new module, 'server' could have been a candidate but that depends
>>>>>>> on too many artifacts that will also need to reference these.
>>>>>>>
>>>>>>>> As for your question 1, I don't feel strongly at all, just have some
>>>>>>>> thoughts. To initially use a capability, people are going to have to
>>>>>>>> look up data. We're not going to stick all of these in controller, so
>>>>>>>> that means there's going to be a search, and these kinds of classes are
>>>>>>>> going to be dispersed. Trying to maintain some fairly centralized
>>>>>>>> document somewhere would actually make that initial search easier.
>>>>>>>
>>>>>>> At the moment with this PR all I am proposing is a central location for
>>>>>>> capabilities that we know will be widely used, in this case the server
>>>>>>> and subsystems etc. are going to have hard coded dependencies on Elytron
>>>>>>> APIs - what is not hard coded is how the implementations of those APIs
>>>>>>> are actually made available.
>>>>>>>
>>>>>>
>>>>>> Who is the consumer of these? A requirer only needs the String names,
>>>>>> none of the "public static final RuntimeCapability" instances.
>>>>>
>>>>> The consumers will be: -
>>>>>        - Various resources in core.
>>>>>        - Subsystems in general.
>>>>>        - Deployments.
>>>>>
>>>>> One possible problem I am seeing with only using a String on the
>>>>> consumer side is that there is no type associated even though the
>>>>> dependency injection for dynamic capabilities at least is going to
>>>>> depend on a mutually agreed type.
>>>>
>>>> I don't think that really makes a huge difference in this case.  There
>>>> will be a fairly small number of consumers, and type safety in this case
>>>> is not going to be critical.  And really I don't anticipate that type
>>>> safety would catch any bugs that wouldn't be caught in any event by the
>>>> simpler string-based system at the same time.
>>>>
>>>>>> The different providers of the capability can use the RuntimeCapability
>>>>>> constants, but I think those should be separated somehow. They are
>>>>>> really none of the business of the requirers.
>>>>>
>>>>> The providers will be: -
>>>>>        - The Elytron Subsystem (Optional)
>>>>>        - Any other subsytem that wants to provide one or more of these
>>>>> capabilities.
>>>>>
>>>>> For separation we could have different classes, different modules or
>>>>> even some factory class to convert from the name to the
>>>>> RuntimeCapability instance.
>>>>
>>>> Too complex - I think we need to think minimally here.  Keep the
>>>> mechanism as simple as possible.
>>>
>>> Which part was too complex?  The Factory?
>>>
>>> IMO I think go for one new module, 2 classes in this module, 1 class for
>>> the String constants and 1 class for the statically defined
>>> RuntimeCapability definitions.
>>
>> Having a module for every capability, which is what this implies, is too
>> complex.  We should have zero modules with zero classes and every
>> consumer can have their own copy of the one string that they need.  Many
>> providers won't even need special classes, so setting this precedent
>> doesn't really make any sense.
>>
>>>>> I think single new module with two classes may be the better compromise
>>>>> for now otherwise we risk two new modules - each with a single class.
>>
>> ^^^ This right here is the warning sign.  If we're creating four-class
>> modules, let alone two- or one-class modules, we've made a wrong turn.
>> More modules per anything is a massive and unnecessary increase in
>> complexity and maintenance burden.
>>
>>>>> The main point being that WildFly Core is the single common dependency
>>>>> for everything
>>>>
>>>> For the moment.  Not forever though.
>>>
>>> In what way?  Everything is depending on 'controller' as that is where
>>> the notion of capabilities are defined - are we saying the core of core
>>> can be split out even further?
>>
>> The core of core may not even continue to exist in its current form
>> beyond WildFly 10 or 11 once we implement the new management code.
>>
>>>>>>> The Elytron project could not contain these definitions as that has no
>>>>>>> dependencies on WildFly, the Elytron Subsystem can not contain this as
>>>>>>> that is an optional module.
>>>>>>>
>>>>>>>> Using constants like in your PR is helpful for later maintenance. If
>>>>>>>> some constant is deprecated, referrers will see that in their IDE. They
>>>>>>>> can easily click to read javadoc and learn if the requirement's dynamic
>>>>>>>> and the service type.
>>>>>>>>
>>>>>>>> The biggest concern I have is avoiding premature classloading links.
>>>>>>>> This is important in the case of optional requirements. If a requirement
>>>>>>>> is optional, it's critical that the declaration of the requirement in
>>>>>>>> the code doesn't force loading of classes from the required capability's
>>>>>>>> module. Otherwise that module is no longer optional and its harder to
>>>>>>>> create a slim distribution.
>>>>>>>
>>>>>>> In this case the only classes being referenced are classes from the
>>>>>>> Elytron module and that module is going to be mandatory within the
>>>>>>> server.
>>>>>>>
>>>>>>
>>>>>> Yep. This classloading thing is more of a general concern, not
>>>>>> particularly relevant to this particular case. People tend to code
>>>>>> things up by copying existing code though, so it's good to consider the
>>>>>> general problem before establishing precedents.
>>>>>>
>>>>>>> Generally it sounds like 'controller' is a no-go so the format of any
>>>>>>> constants in code will probably dictate where this lives.
>>>>>>>
>>>>>>> If we are only talking Strings I may be able to add it to the
>>>>>>> 'wildfly-core-security-api' module although javadoc can not reference
>>>>>>> any capability related classes so that may not be preferable - of I can
>>>>>>> create a new module with a dependency on controller and everything else
>>>>>>> that uses Elytron capabilities can then depend on this new artifact /
>>>>>>> module.
>>>>>>>
>>>>>>>> On 5/22/15 5:31 AM, Darran Lofthouse wrote:
>>>>>>>>> Following on from PR https://github.com/wildfly/wildfly-core/pull/757
>>>>>>>>> and my final comment in the PR we need to have a discussion on how we
>>>>>>>>> coordinate capability and requirement definitions - especially where
>>>>>>>>> multiple components need a common definition.
>>>>>>>>>
>>>>>>>>> The first option is to do it all by convention and have no shared
>>>>>>>>> constants, the down side of this is we now need to document this and
>>>>>>>>> keep the document maintained.  A document would also make it hard in
>>>>>>>>> the
>>>>>>>>> future to flag certain capabilities as deprecated if preferred
>>>>>>>>> alternatives are made available.
>>>>>>>>>
>>>>>>>>> The second option would be to just define the Strings somewhere and use
>>>>>>>>> Javadoc to specify if the capability is dynamic and it's service type.
>>>>>>>>>
>>>>>>>>> The third option is defining the string and RuntimeCapability instances
>>>>>>>>> in a central place so they can both be referenced as needed.
>>>>>>>>>
>>>>>>>>> Any other options?
>>>>>>>>>
>>>>>>>>> Where these live will be a second point to discuss but that is heavily
>>>>>>>>> driven based on what we will share in the first place.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Darran Lofthouse.
>>>>>>>>> _______________________________________________
>>>>>>>>> wildfly-dev mailing list
>>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From brian.stansberry at redhat.com  Mon Jun  1 14:38:07 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 01 Jun 2015 13:38:07 -0500
Subject: [wildfly-dev] Question on frozen management client
In-Reply-To: <55681464.6020909@redhat.com>
References: <55681464.6020909@redhat.com>
Message-ID: <556CA68F.1070802@redhat.com>

It looks like the issue is on the client side. The ModelControllerClient 
uses an internal executor service with threads named 
"management-client-thread XXX". The stack traces only show 1 such 
thread, sitting idle. The core pool size on the executor is 2, so there 
should be a 2nd thread, and presumably that's the one that should be 
doing the work (i.e. waiting for the server response.

That sounds like something has happened that propagated all the way back 
to the pool and killed the thread.

I don't know what though, or why it would fail for you but not with the 
CLI. The request has reached the server and at that point the code 
should be executing the same basic code path as the CLI.

On 5/29/15 2:25 AM, Rob Stryker wrote:
> Hey All:
>
> I've been trying to dig into this for a while but really haven't gotten
> very far.   Glance at https://issues.jboss.org/browse/JBIDE-19641
>
> It seems our client (jbosstools) appears to have frozen while sending a
> large war over mgmt api for deployment. Unfortunately, looking at the
> stacks doesn't show anything strange. In fact, it seems the transfer is
> still in effect.  However, our user indicates that disk activity (ie
> transfer) has ceased, and yet the client jar classes have not indicated
> the transfer was done or aborted.
>
>
>
> The class we use to perform the mgmt publish is
> https://github.com/jbosstools/jbosstools-server/blob/master/as/plugins/org.jboss.ide.eclipse.as.management.wildfly8/src/org/jboss/ide/eclipse/as/internal/management/wildfly8/Wildfly8Manager.java
>
> It's pretty simple, but QE is indicating it freezes and after a short
> while, nothing happens.
>
>     I was wondering if anyone here might have any insight?  QE indicates
> the transfer works fine over jboss-cli, but not in jbt.
>
> Thanks in advance.
>
> - Rob Stryker
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From brian.stansberry at redhat.com  Mon Jun  1 14:43:16 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 01 Jun 2015 13:43:16 -0500
Subject: [wildfly-dev] Question on frozen management client
In-Reply-To: <556CA68F.1070802@redhat.com>
References: <55681464.6020909@redhat.com> <556CA68F.1070802@redhat.com>
Message-ID: <556CA7C4.9030808@redhat.com>

Please pretty much disregard this; I inadvertently hit "Send".

While I think it's odd there's only one management-client-thread, that 
doesn't necessarily mean the other one failed. In particular I don't 
expect a thread to be blocking waiting for a response. It's all based on 
callbacks when xnio/remoting gets data.

On 6/1/15 1:38 PM, Brian Stansberry wrote:
> It looks like the issue is on the client side. The ModelControllerClient
> uses an internal executor service with threads named
> "management-client-thread XXX". The stack traces only show 1 such
> thread, sitting idle. The core pool size on the executor is 2, so there
> should be a 2nd thread, and presumably that's the one that should be
> doing the work (i.e. waiting for the server response.
>
> That sounds like something has happened that propagated all the way back
> to the pool and killed the thread.
>
> I don't know what though, or why it would fail for you but not with the
> CLI. The request has reached the server and at that point the code
> should be executing the same basic code path as the CLI.
>
> On 5/29/15 2:25 AM, Rob Stryker wrote:
>> Hey All:
>>
>> I've been trying to dig into this for a while but really haven't gotten
>> very far.   Glance at https://issues.jboss.org/browse/JBIDE-19641
>>
>> It seems our client (jbosstools) appears to have frozen while sending a
>> large war over mgmt api for deployment. Unfortunately, looking at the
>> stacks doesn't show anything strange. In fact, it seems the transfer is
>> still in effect.  However, our user indicates that disk activity (ie
>> transfer) has ceased, and yet the client jar classes have not indicated
>> the transfer was done or aborted.
>>
>>
>>
>> The class we use to perform the mgmt publish is
>> https://github.com/jbosstools/jbosstools-server/blob/master/as/plugins/org.jboss.ide.eclipse.as.management.wildfly8/src/org/jboss/ide/eclipse/as/internal/management/wildfly8/Wildfly8Manager.java
>>
>> It's pretty simple, but QE is indicating it freezes and after a short
>> while, nothing happens.
>>
>>      I was wondering if anyone here might have any insight?  QE indicates
>> the transfer works fine over jboss-cli, but not in jbt.
>>
>> Thanks in advance.
>>
>> - Rob Stryker
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From mazz at redhat.com  Tue Jun  2 16:45:30 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 2 Jun 2015 16:45:30 -0400 (EDT)
Subject: [wildfly-dev] deploying module subsystem extension in wf-swarm
In-Reply-To: <1605703741.9464216.1433276320852.JavaMail.zimbra@redhat.com>
Message-ID: <567319437.9472566.1433277930317.JavaMail.zimbra@redhat.com>

Is there an example of WildFly Swarm that (instead of deploying a WAR) deploys a module subsystem extension? Today, I have a subsystem that I deploy in WildFly's /modules and add it to standalone.xml via <extension> and <subsystem> and I was wondering how to take that and deploy it in WF-Swarm?

I see some things that are "close" (e.g. https://github.com/wildfly-swarm/example-datasource-subsystem ) but this isn't exactly it, at least it doesn't seem so. Unless I have to write my own subsystem's analogy to "DatasourcesFraction" and related classes?

I see when I build wf-swarm using the mvn plugin, my extension jar goes in "app" and all its dependencies go in m2repo. I see nothing that is analogous to standalone.xml (so I'm not sure how I configure my extension, which I normally do via the child elements under my <subsystem>).

So, if anyone has an example of doing something like this, let me know.

Thanks.
--John Mazz

From sanne at hibernate.org  Tue Jun  2 20:15:29 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 3 Jun 2015 01:15:29 +0100
Subject: [wildfly-dev] Using a custom module to preview "next-gen"
 Hibernate versions on WildFly 9
In-Reply-To: <556C7577.80508@redhat.com>
References: <CAFm4XO1E2PXoZ=9swNK+L1FcLhR=QChMVognUAyvxV09fYNM0Q@mail.gmail.com>
	<556C7577.80508@redhat.com>
Message-ID: <CAFm4XO22NTvgC-mrzYtEcEQrJZPbYW_Wuataohj4T7gLCrq1zw@mail.gmail.com>

Hi Scott,
finally got back on this upgrade. You were right, the problem is that
JipiJapa figures out that I'm using Hibernate - even though I'm not
hard coding the provider name, as in that case it will just default to
Hibernate anyway - and because of that it's adding both the JPA
adaptors for Hibernate 4 and the wrong version of the Hibernate
dependencies as well.

This is the temporary solution I'm going to use:
https://github.com/hibernate/hibernate-search/commit/d2b05ef7511815d6c0a0779734b95a69cdcbf56d

Thanks for all pointers!
Sanne


On 1 June 2015 at 16:08, Scott Marlow <smarlow at redhat.com> wrote:
> I suspect that this is a bug in WildFly that we need to track down.  I'm
> guessing that the condition is that we are trying to use a custom Hibernate
> module when there is an existing Hibernate module that matches the
> Persistence provider name.  Or something like that.
>
>
> On 05/21/2015 07:30 AM, Sanne Grinovero wrote:
>>
>> Hi all,
>> I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1
>> to use a preview of Hibernate ORM version 5.
>>
>> It seems the JPA deployer isn't allowing me to run such experiments:
>>
>> # First experiment - providerModule set to custom module
>>
>> In my first attempt, I create a custom set of jboss modules which
>> include the snapshot builds of ORM 5, add them to my standalone WF9
>> instance and set the persistence.xml property:
>>   jboss.as.jpa.providerModule = my-custom-module-name
>>
>> and then get:
>>
>> Caused by: java.util.ServiceConfigurationError:
>> org.hibernate.integrator.spi.Integrator: Provider
>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype
>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51]
>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181)
>> [rt.jar:1.7.0_51]
>> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369)
>> [rt.jar:1.7.0_51]
>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
>> [rt.jar:1.7.0_51]
>> at
>> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341)
>> at
>> org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57)
>> at
>> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247)
>> at
>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520)
>> at
>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208)
>> at
>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188)
>> at
>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45)
>> at
>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57)
>> at
>> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38)
>> at
>> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173)
>> at
>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243)
>> at
>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60)
>> at
>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118)
>> ... 7 more
>>
>> Clearly it looks like I'm being served classes from the bundled
>> Hibernate 4.x implementation - on top of those from the module I'm
>> requesting. This isn't what the deployer should be doing, right?
>>
>> # Second experiment - use the "application provided"
>>
>> In this case I hope to hint the JPA  deployer to not add the default
>> implementor but look for a JPA implementation within my deployment,
>> but still package my custom Hibernate build as a module.
>>
>>   - use the same custom module containing Hibernate ORM 5 (a preview
>> snapshot)
>>   - Add a "Dependency:" section to the manifest to import (and export)
>> my custom module
>>   - set the "jboss.as.jpa.providerModule" property to value "application"
>>
>> This gets me:
>>
>> Caused by:
>> org.jboss.as.server.deployment.DeploymentUnitProcessingException:
>> WFLYJPA0027: Persistence provider module load error application (class
>> org.hibernate.jpa.HibernatePersistenceProvider)
>> at
>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985)
>> at
>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267)
>> at
>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200)
>> at
>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131)
>> at
>> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
>> at
>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1]
>> ... 5 more
>> Caused by: org.jboss.modules.ModuleNotFoundException: application:main
>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236)
>> [jboss-modules.jar:1.4.3.Final]
>> at
>> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65)
>> at
>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978)
>> ... 10 more
>>
>> Remarks:
>>   - it's attempting to load the "application:main" module?! that's not
>> what I'd expect from reading [1]
>>   - the provider should be available to the deployment classpath, so
>> I'm not sure why it's not finding the Provider? (I'm even exporting
>> it, although I'm not sure if that was required).
>>
>> Any suggestions to get this running please?
>>
>> Also I wonder if some of these should warrant opening a JIRA, but I'm
>> not sure how far I misunderstood the intentions of these JPA deployer
>> properties.
>>
>> Thanks,
>> Sanne
>>
>> [1] -
>> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties
>>
>

From lanabe.lanabe at gmail.com  Wed Jun  3 06:53:29 2015
From: lanabe.lanabe at gmail.com (lanabe)
Date: Wed, 03 Jun 2015 10:53:29 +0000
Subject: [wildfly-dev] deploying module subsystem extension in wf-swarm
In-Reply-To: <567319437.9472566.1433277930317.JavaMail.zimbra@redhat.com>
References: <1605703741.9464216.1433276320852.JavaMail.zimbra@redhat.com>
	<567319437.9472566.1433277930317.JavaMail.zimbra@redhat.com>
Message-ID: <CAKhWDPRW4RAJjTf=DqnUnKM1skciwTrRnOBq6GO0-eqXrc3b1A@mail.gmail.com>

Hi, John.

I think you are right(you need to write a fraction for your own
extension/subsystem).

It seems there is no entrypoint to deploy your subsystem from your
application, maybe. So, this should be discussed.

Can you file it on github?
https://github.com/wildfly-swarm/wildfly-swarm/issues


On Wed, Jun 3, 2015 at 5:45 AM John Mazzitelli <mazz at redhat.com> wrote:

> Is there an example of WildFly Swarm that (instead of deploying a WAR)
> deploys a module subsystem extension? Today, I have a subsystem that I
> deploy in WildFly's /modules and add it to standalone.xml via <extension>
> and <subsystem> and I was wondering how to take that and deploy it in
> WF-Swarm?
>
> I see some things that are "close" (e.g.
> https://github.com/wildfly-swarm/example-datasource-subsystem ) but this
> isn't exactly it, at least it doesn't seem so. Unless I have to write my
> own subsystem's analogy to "DatasourcesFraction" and related classes?
>
> I see when I build wf-swarm using the mvn plugin, my extension jar goes in
> "app" and all its dependencies go in m2repo. I see nothing that is
> analogous to standalone.xml (so I'm not sure how I configure my extension,
> which I normally do via the child elements under my <subsystem>).
>
> So, if anyone has an example of doing something like this, let me know.
>
> Thanks.
> --John Mazz
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150603/5740144f/attachment.html 

From mazz at redhat.com  Wed Jun  3 09:31:38 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 3 Jun 2015 09:31:38 -0400 (EDT)
Subject: [wildfly-dev] deploying module subsystem extension in wf-swarm
In-Reply-To: <CAKhWDPRW4RAJjTf=DqnUnKM1skciwTrRnOBq6GO0-eqXrc3b1A@mail.gmail.com>
References: <1605703741.9464216.1433276320852.JavaMail.zimbra@redhat.com>
	<567319437.9472566.1433277930317.JavaMail.zimbra@redhat.com>
	<CAKhWDPRW4RAJjTf=DqnUnKM1skciwTrRnOBq6GO0-eqXrc3b1A@mail.gmail.com>
Message-ID: <406009104.9995476.1433338298550.JavaMail.zimbra@redhat.com>

> Can you file it on github?
> https://github.com/wildfly-swarm/wildfly-swarm/issues
> 

Done: https://github.com/wildfly-swarm/wildfly-swarm/issues/41

Thanks

From smarlow at redhat.com  Wed Jun  3 11:55:40 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 03 Jun 2015 11:55:40 -0400
Subject: [wildfly-dev] Using a custom module to preview "next-gen"
 Hibernate versions on WildFly 9
In-Reply-To: <CAFm4XO22NTvgC-mrzYtEcEQrJZPbYW_Wuataohj4T7gLCrq1zw@mail.gmail.com>
References: <CAFm4XO1E2PXoZ=9swNK+L1FcLhR=QChMVognUAyvxV09fYNM0Q@mail.gmail.com>
	<556C7577.80508@redhat.com>
	<CAFm4XO22NTvgC-mrzYtEcEQrJZPbYW_Wuataohj4T7gLCrq1zw@mail.gmail.com>
Message-ID: <556F237C.3030002@redhat.com>

Hi Sanne,

I was able to reproduce one of the below errors that occur when 
packaging Hibernate ORM jars with the application 
http://pastie.org/10221793.  This is with the 
"jboss.as.jpa.providerModule" property set to value "application".

Test is pushed to [1] and is based on a test that I added for the [2] 
pull request.  Once [2] is merged to WildFly master, it should be easy 
to fix the bug.  The only change that I needed to [2], was to remove the 
provider from the persistence.xml.

For the first approach below, we should probably allow the 
"jboss.as.jpa.adapterClass" to specify the 
"org.jboss.as.jpa.processor.PersistenceProviderAdaptorLoader.noopAdaptor" (by 
name or via a special value).

Scott

[1] https://github.com/scottmarlow/wildfly/tree/test_orm41_bundled

[2] https://github.com/wildfly/wildfly/pull/7509

On 06/02/2015 08:15 PM, Sanne Grinovero wrote:
> Hi Scott,
> finally got back on this upgrade. You were right, the problem is that
> JipiJapa figures out that I'm using Hibernate - even though I'm not
> hard coding the provider name, as in that case it will just default to
> Hibernate anyway - and because of that it's adding both the JPA
> adaptors for Hibernate 4 and the wrong version of the Hibernate
> dependencies as well.
>
> This is the temporary solution I'm going to use:
> https://github.com/hibernate/hibernate-search/commit/d2b05ef7511815d6c0a0779734b95a69cdcbf56d
>
> Thanks for all pointers!
> Sanne
>
>
> On 1 June 2015 at 16:08, Scott Marlow <smarlow at redhat.com> wrote:
>> I suspect that this is a bug in WildFly that we need to track down.  I'm
>> guessing that the condition is that we are trying to use a custom Hibernate
>> module when there is an existing Hibernate module that matches the
>> Persistence provider name.  Or something like that.
>>
>>
>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote:
>>>
>>> Hi all,
>>> I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1
>>> to use a preview of Hibernate ORM version 5.
>>>
>>> It seems the JPA deployer isn't allowing me to run such experiments:
>>>
>>> # First experiment - providerModule set to custom module
>>>
>>> In my first attempt, I create a custom set of jboss modules which
>>> include the snapshot builds of ORM 5, add them to my standalone WF9
>>> instance and set the persistence.xml property:
>>>    jboss.as.jpa.providerModule = my-custom-module-name
>>>
>>> and then get:
>>>
>>> Caused by: java.util.ServiceConfigurationError:
>>> org.hibernate.integrator.spi.Integrator: Provider
>>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype
>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51]
>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181)
>>> [rt.jar:1.7.0_51]
>>> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369)
>>> [rt.jar:1.7.0_51]
>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
>>> [rt.jar:1.7.0_51]
>>> at
>>> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341)
>>> at
>>> org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57)
>>> at
>>> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247)
>>> at
>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520)
>>> at
>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208)
>>> at
>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188)
>>> at
>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45)
>>> at
>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57)
>>> at
>>> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38)
>>> at
>>> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173)
>>> at
>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243)
>>> at
>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60)
>>> at
>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118)
>>> ... 7 more
>>>
>>> Clearly it looks like I'm being served classes from the bundled
>>> Hibernate 4.x implementation - on top of those from the module I'm
>>> requesting. This isn't what the deployer should be doing, right?
>>>
>>> # Second experiment - use the "application provided"
>>>
>>> In this case I hope to hint the JPA  deployer to not add the default
>>> implementor but look for a JPA implementation within my deployment,
>>> but still package my custom Hibernate build as a module.
>>>
>>>    - use the same custom module containing Hibernate ORM 5 (a preview
>>> snapshot)
>>>    - Add a "Dependency:" section to the manifest to import (and export)
>>> my custom module
>>>    - set the "jboss.as.jpa.providerModule" property to value "application"
>>>
>>> This gets me:
>>>
>>> Caused by:
>>> org.jboss.as.server.deployment.DeploymentUnitProcessingException:
>>> WFLYJPA0027: Persistence provider module load error application (class
>>> org.hibernate.jpa.HibernatePersistenceProvider)
>>> at
>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985)
>>> at
>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267)
>>> at
>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200)
>>> at
>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131)
>>> at
>>> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
>>> at
>>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1]
>>> ... 5 more
>>> Caused by: org.jboss.modules.ModuleNotFoundException: application:main
>>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236)
>>> [jboss-modules.jar:1.4.3.Final]
>>> at
>>> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65)
>>> at
>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978)
>>> ... 10 more
>>>
>>> Remarks:
>>>    - it's attempting to load the "application:main" module?! that's not
>>> what I'd expect from reading [1]
>>>    - the provider should be available to the deployment classpath, so
>>> I'm not sure why it's not finding the Provider? (I'm even exporting
>>> it, although I'm not sure if that was required).
>>>
>>> Any suggestions to get this running please?
>>>
>>> Also I wonder if some of these should warrant opening a JIRA, but I'm
>>> not sure how far I misunderstood the intentions of these JPA deployer
>>> properties.
>>>
>>> Thanks,
>>> Sanne
>>>
>>> [1] -
>>> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties
>>>
>>

From sanne at hibernate.org  Wed Jun  3 12:09:49 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 3 Jun 2015 17:09:49 +0100
Subject: [wildfly-dev] Using a custom module to preview "next-gen"
 Hibernate versions on WildFly 9
In-Reply-To: <556F237C.3030002@redhat.com>
References: <CAFm4XO1E2PXoZ=9swNK+L1FcLhR=QChMVognUAyvxV09fYNM0Q@mail.gmail.com>
	<556C7577.80508@redhat.com>
	<CAFm4XO22NTvgC-mrzYtEcEQrJZPbYW_Wuataohj4T7gLCrq1zw@mail.gmail.com>
	<556F237C.3030002@redhat.com>
Message-ID: <CAFm4XO2GGgM=QcqeqbBuDxSeBz1SRdg00AA7K3=MqhMQdmNECQ@mail.gmail.com>

On 3 June 2015 at 16:55, Scott Marlow <smarlow at redhat.com> wrote:
> Hi Sanne,
>
> I was able to reproduce one of the below errors that occur when packaging
> Hibernate ORM jars with the application http://pastie.org/10221793.  This is
> with the "jboss.as.jpa.providerModule" property set to value "application".
>
> Test is pushed to [1] and is based on a test that I added for the [2] pull
> request.  Once [2] is merged to WildFly master, it should be easy to fix the
> bug.  The only change that I needed to [2], was to remove the provider from
> the persistence.xml.
>
> For the first approach below, we should probably allow the
> "jboss.as.jpa.adapterClass" to specify the
> "org.jboss.as.jpa.processor.PersistenceProviderAdaptorLoader.noopAdaptor"
> (by name or via a special value).

Right, being able to "force" usage of the no-op Adaptor like I did
with my Byteman rule would give us a lot of nice flexibility.

BTW once I did that, I noticed that the scanning of entities broke.
Apparently entity scanning for Hibernate requires the Scanner which
you would provide with the adaptor; would you know why?
I'm wondering because it seems related to an Hibernate OGM issue: in
that case we don't disable the adapter but still auto-detection of
entities doesn't work.

Thanks!
Sanne

>
> Scott
>
> [1] https://github.com/scottmarlow/wildfly/tree/test_orm41_bundled
>
> [2] https://github.com/wildfly/wildfly/pull/7509
>
>
> On 06/02/2015 08:15 PM, Sanne Grinovero wrote:
>>
>> Hi Scott,
>> finally got back on this upgrade. You were right, the problem is that
>> JipiJapa figures out that I'm using Hibernate - even though I'm not
>> hard coding the provider name, as in that case it will just default to
>> Hibernate anyway - and because of that it's adding both the JPA
>> adaptors for Hibernate 4 and the wrong version of the Hibernate
>> dependencies as well.
>>
>> This is the temporary solution I'm going to use:
>>
>> https://github.com/hibernate/hibernate-search/commit/d2b05ef7511815d6c0a0779734b95a69cdcbf56d
>>
>> Thanks for all pointers!
>> Sanne
>>
>>
>> On 1 June 2015 at 16:08, Scott Marlow <smarlow at redhat.com> wrote:
>>>
>>> I suspect that this is a bug in WildFly that we need to track down.  I'm
>>> guessing that the condition is that we are trying to use a custom
>>> Hibernate
>>> module when there is an existing Hibernate module that matches the
>>> Persistence provider name.  Or something like that.
>>>
>>>
>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote:
>>>>
>>>>
>>>> Hi all,
>>>> I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1
>>>> to use a preview of Hibernate ORM version 5.
>>>>
>>>> It seems the JPA deployer isn't allowing me to run such experiments:
>>>>
>>>> # First experiment - providerModule set to custom module
>>>>
>>>> In my first attempt, I create a custom set of jboss modules which
>>>> include the snapshot builds of ORM 5, add them to my standalone WF9
>>>> instance and set the persistence.xml property:
>>>>    jboss.as.jpa.providerModule = my-custom-module-name
>>>>
>>>> and then get:
>>>>
>>>> Caused by: java.util.ServiceConfigurationError:
>>>> org.hibernate.integrator.spi.Integrator: Provider
>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype
>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231)
>>>> [rt.jar:1.7.0_51]
>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181)
>>>> [rt.jar:1.7.0_51]
>>>> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369)
>>>> [rt.jar:1.7.0_51]
>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
>>>> [rt.jar:1.7.0_51]
>>>> at
>>>>
>>>> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341)
>>>> at
>>>>
>>>> org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57)
>>>> at
>>>>
>>>> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247)
>>>> at
>>>>
>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520)
>>>> at
>>>>
>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208)
>>>> at
>>>>
>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188)
>>>> at
>>>>
>>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45)
>>>> at
>>>>
>>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57)
>>>> at
>>>>
>>>> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38)
>>>> at
>>>>
>>>> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173)
>>>> at
>>>>
>>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243)
>>>> at
>>>>
>>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60)
>>>> at
>>>>
>>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118)
>>>> ... 7 more
>>>>
>>>> Clearly it looks like I'm being served classes from the bundled
>>>> Hibernate 4.x implementation - on top of those from the module I'm
>>>> requesting. This isn't what the deployer should be doing, right?
>>>>
>>>> # Second experiment - use the "application provided"
>>>>
>>>> In this case I hope to hint the JPA  deployer to not add the default
>>>> implementor but look for a JPA implementation within my deployment,
>>>> but still package my custom Hibernate build as a module.
>>>>
>>>>    - use the same custom module containing Hibernate ORM 5 (a preview
>>>> snapshot)
>>>>    - Add a "Dependency:" section to the manifest to import (and export)
>>>> my custom module
>>>>    - set the "jboss.as.jpa.providerModule" property to value
>>>> "application"
>>>>
>>>> This gets me:
>>>>
>>>> Caused by:
>>>> org.jboss.as.server.deployment.DeploymentUnitProcessingException:
>>>> WFLYJPA0027: Persistence provider module load error application (class
>>>> org.hibernate.jpa.HibernatePersistenceProvider)
>>>> at
>>>>
>>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985)
>>>> at
>>>>
>>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267)
>>>> at
>>>>
>>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200)
>>>> at
>>>>
>>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131)
>>>> at
>>>>
>>>> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
>>>> at
>>>>
>>>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1]
>>>> ... 5 more
>>>> Caused by: org.jboss.modules.ModuleNotFoundException: application:main
>>>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236)
>>>> [jboss-modules.jar:1.4.3.Final]
>>>> at
>>>>
>>>> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65)
>>>> at
>>>>
>>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978)
>>>> ... 10 more
>>>>
>>>> Remarks:
>>>>    - it's attempting to load the "application:main" module?! that's not
>>>> what I'd expect from reading [1]
>>>>    - the provider should be available to the deployment classpath, so
>>>> I'm not sure why it's not finding the Provider? (I'm even exporting
>>>> it, although I'm not sure if that was required).
>>>>
>>>> Any suggestions to get this running please?
>>>>
>>>> Also I wonder if some of these should warrant opening a JIRA, but I'm
>>>> not sure how far I misunderstood the intentions of these JPA deployer
>>>> properties.
>>>>
>>>> Thanks,
>>>> Sanne
>>>>
>>>> [1] -
>>>>
>>>> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties
>>>>
>>>
>

From steve at hibernate.org  Wed Jun  3 12:15:23 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 03 Jun 2015 16:15:23 +0000
Subject: [wildfly-dev] Using a custom module to preview "next-gen"
 Hibernate versions on WildFly 9
In-Reply-To: <CAFm4XO2GGgM=QcqeqbBuDxSeBz1SRdg00AA7K3=MqhMQdmNECQ@mail.gmail.com>
References: <CAFm4XO1E2PXoZ=9swNK+L1FcLhR=QChMVognUAyvxV09fYNM0Q@mail.gmail.com>
	<556C7577.80508@redhat.com>
	<CAFm4XO22NTvgC-mrzYtEcEQrJZPbYW_Wuataohj4T7gLCrq1zw@mail.gmail.com>
	<556F237C.3030002@redhat.com>
	<CAFm4XO2GGgM=QcqeqbBuDxSeBz1SRdg00AA7K3=MqhMQdmNECQ@mail.gmail.com>
Message-ID: <CAFdSV9sYpq5AQGqETqoQuMnbqtTjaYeQQARXgT1FF2kjJ9oCEA@mail.gmail.com>

Because scanning in WildFly requires VFS hooks that Jipijapa provided in
its scanner specializations.

On Wed, Jun 3, 2015 at 11:10 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 3 June 2015 at 16:55, Scott Marlow <smarlow at redhat.com> wrote:
> > Hi Sanne,
> >
> > I was able to reproduce one of the below errors that occur when packaging
> > Hibernate ORM jars with the application http://pastie.org/10221793.
> This is
> > with the "jboss.as.jpa.providerModule" property set to value
> "application".
> >
> > Test is pushed to [1] and is based on a test that I added for the [2]
> pull
> > request.  Once [2] is merged to WildFly master, it should be easy to fix
> the
> > bug.  The only change that I needed to [2], was to remove the provider
> from
> > the persistence.xml.
> >
> > For the first approach below, we should probably allow the
> > "jboss.as.jpa.adapterClass" to specify the
> > "org.jboss.as.jpa.processor.PersistenceProviderAdaptorLoader.noopAdaptor"
> > (by name or via a special value).
>
> Right, being able to "force" usage of the no-op Adaptor like I did
> with my Byteman rule would give us a lot of nice flexibility.
>
> BTW once I did that, I noticed that the scanning of entities broke.
> Apparently entity scanning for Hibernate requires the Scanner which
> you would provide with the adaptor; would you know why?
> I'm wondering because it seems related to an Hibernate OGM issue: in
> that case we don't disable the adapter but still auto-detection of
> entities doesn't work.
>
> Thanks!
> Sanne
>
> >
> > Scott
> >
> > [1] https://github.com/scottmarlow/wildfly/tree/test_orm41_bundled
> >
> > [2] https://github.com/wildfly/wildfly/pull/7509
> >
> >
> > On 06/02/2015 08:15 PM, Sanne Grinovero wrote:
> >>
> >> Hi Scott,
> >> finally got back on this upgrade. You were right, the problem is that
> >> JipiJapa figures out that I'm using Hibernate - even though I'm not
> >> hard coding the provider name, as in that case it will just default to
> >> Hibernate anyway - and because of that it's adding both the JPA
> >> adaptors for Hibernate 4 and the wrong version of the Hibernate
> >> dependencies as well.
> >>
> >> This is the temporary solution I'm going to use:
> >>
> >>
> https://github.com/hibernate/hibernate-search/commit/d2b05ef7511815d6c0a0779734b95a69cdcbf56d
> >>
> >> Thanks for all pointers!
> >> Sanne
> >>
> >>
> >> On 1 June 2015 at 16:08, Scott Marlow <smarlow at redhat.com> wrote:
> >>>
> >>> I suspect that this is a bug in WildFly that we need to track down.
> I'm
> >>> guessing that the condition is that we are trying to use a custom
> >>> Hibernate
> >>> module when there is an existing Hibernate module that matches the
> >>> Persistence provider name.  Or something like that.
> >>>
> >>>
> >>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote:
> >>>>
> >>>>
> >>>> Hi all,
> >>>> I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1
> >>>> to use a preview of Hibernate ORM version 5.
> >>>>
> >>>> It seems the JPA deployer isn't allowing me to run such experiments:
> >>>>
> >>>> # First experiment - providerModule set to custom module
> >>>>
> >>>> In my first attempt, I create a custom set of jboss modules which
> >>>> include the snapshot builds of ORM 5, add them to my standalone WF9
> >>>> instance and set the persistence.xml property:
> >>>>    jboss.as.jpa.providerModule = my-custom-module-name
> >>>>
> >>>> and then get:
> >>>>
> >>>> Caused by: java.util.ServiceConfigurationError:
> >>>> org.hibernate.integrator.spi.Integrator: Provider
> >>>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype
> >>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231)
> >>>> [rt.jar:1.7.0_51]
> >>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181)
> >>>> [rt.jar:1.7.0_51]
> >>>> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369)
> >>>> [rt.jar:1.7.0_51]
> >>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
> >>>> [rt.jar:1.7.0_51]
> >>>> at
> >>>>
> >>>>
> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341)
> >>>> at
> >>>>
> >>>>
> org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57)
> >>>> at
> >>>>
> >>>>
> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247)
> >>>> at
> >>>>
> >>>>
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520)
> >>>> at
> >>>>
> >>>>
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208)
> >>>> at
> >>>>
> >>>>
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188)
> >>>> at
> >>>>
> >>>>
> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45)
> >>>> at
> >>>>
> >>>>
> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57)
> >>>> at
> >>>>
> >>>>
> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38)
> >>>> at
> >>>>
> >>>>
> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173)
> >>>> at
> >>>>
> >>>>
> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243)
> >>>> at
> >>>>
> >>>>
> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60)
> >>>> at
> >>>>
> >>>>
> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118)
> >>>> ... 7 more
> >>>>
> >>>> Clearly it looks like I'm being served classes from the bundled
> >>>> Hibernate 4.x implementation - on top of those from the module I'm
> >>>> requesting. This isn't what the deployer should be doing, right?
> >>>>
> >>>> # Second experiment - use the "application provided"
> >>>>
> >>>> In this case I hope to hint the JPA  deployer to not add the default
> >>>> implementor but look for a JPA implementation within my deployment,
> >>>> but still package my custom Hibernate build as a module.
> >>>>
> >>>>    - use the same custom module containing Hibernate ORM 5 (a preview
> >>>> snapshot)
> >>>>    - Add a "Dependency:" section to the manifest to import (and
> export)
> >>>> my custom module
> >>>>    - set the "jboss.as.jpa.providerModule" property to value
> >>>> "application"
> >>>>
> >>>> This gets me:
> >>>>
> >>>> Caused by:
> >>>> org.jboss.as.server.deployment.DeploymentUnitProcessingException:
> >>>> WFLYJPA0027: Persistence provider module load error application (class
> >>>> org.hibernate.jpa.HibernatePersistenceProvider)
> >>>> at
> >>>>
> >>>>
> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985)
> >>>> at
> >>>>
> >>>>
> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267)
> >>>> at
> >>>>
> >>>>
> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200)
> >>>> at
> >>>>
> >>>>
> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131)
> >>>> at
> >>>>
> >>>>
> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
> >>>> at
> >>>>
> >>>>
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> >>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1]
> >>>> ... 5 more
> >>>> Caused by: org.jboss.modules.ModuleNotFoundException: application:main
> >>>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236)
> >>>> [jboss-modules.jar:1.4.3.Final]
> >>>> at
> >>>>
> >>>>
> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65)
> >>>> at
> >>>>
> >>>>
> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978)
> >>>> ... 10 more
> >>>>
> >>>> Remarks:
> >>>>    - it's attempting to load the "application:main" module?! that's
> not
> >>>> what I'd expect from reading [1]
> >>>>    - the provider should be available to the deployment classpath, so
> >>>> I'm not sure why it's not finding the Provider? (I'm even exporting
> >>>> it, although I'm not sure if that was required).
> >>>>
> >>>> Any suggestions to get this running please?
> >>>>
> >>>> Also I wonder if some of these should warrant opening a JIRA, but I'm
> >>>> not sure how far I misunderstood the intentions of these JPA deployer
> >>>> properties.
> >>>>
> >>>> Thanks,
> >>>> Sanne
> >>>>
> >>>> [1] -
> >>>>
> >>>>
> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties
> >>>>
> >>>
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150603/2bef01eb/attachment.html 

From smarlow at redhat.com  Wed Jun  3 14:20:20 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 03 Jun 2015 14:20:20 -0400
Subject: [wildfly-dev] Using a custom module to preview "next-gen"
 Hibernate versions on WildFly 9
In-Reply-To: <CAFdSV9sYpq5AQGqETqoQuMnbqtTjaYeQQARXgT1FF2kjJ9oCEA@mail.gmail.com>
References: <CAFm4XO1E2PXoZ=9swNK+L1FcLhR=QChMVognUAyvxV09fYNM0Q@mail.gmail.com>
	<556C7577.80508@redhat.com>
	<CAFm4XO22NTvgC-mrzYtEcEQrJZPbYW_Wuataohj4T7gLCrq1zw@mail.gmail.com>
	<556F237C.3030002@redhat.com>
	<CAFm4XO2GGgM=QcqeqbBuDxSeBz1SRdg00AA7K3=MqhMQdmNECQ@mail.gmail.com>
	<CAFdSV9sYpq5AQGqETqoQuMnbqtTjaYeQQARXgT1FF2kjJ9oCEA@mail.gmail.com>
Message-ID: <556F4564.2070004@redhat.com>

I'm not really sure why the following doesn't work with EclipseLink + 
Hibernate.  Probably a bad assumption on my part (although it made sense 
when I single stepped through the logic in a debugger and seemed to get 
reasonable results from evaluating the URL).  Our OpenJPA unit test 
seems to work, so maybe someone needs to contribute a Hibernate ORM 
patch (I'm not sure myself why it doesn't just work).   :-)

WildFly (JPA deployer) implementation of 
javax.persistence.spi.PersistenceUnitInfo.getPersistenceUnitRootUrl() 
looks like:

java.net.URL getPersistenceUnitRootUrl() {
   VirtualFile persistence_xml = ... ;
   // persistence.xml parent == META-INF
   // META-INF parent is returned in URL form, which represents PU root
   return persistence_xml.getParent().getParent().toURL();
}

Scott

On 06/03/2015 12:15 PM, Steve Ebersole wrote:
> Because scanning in WildFly requires VFS hooks that Jipijapa provided in
> its scanner specializations.
>
> On Wed, Jun 3, 2015 at 11:10 AM Sanne Grinovero <sanne at hibernate.org
> <mailto:sanne at hibernate.org>> wrote:
>
>     On 3 June 2015 at 16:55, Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>> wrote:
>      > Hi Sanne,
>      >
>      > I was able to reproduce one of the below errors that occur when
>     packaging
>      > Hibernate ORM jars with the application
>     http://pastie.org/10221793.  This is
>      > with the "jboss.as.jpa.providerModule" property set to value
>     "application".
>      >
>      > Test is pushed to [1] and is based on a test that I added for the
>     [2] pull
>      > request.  Once [2] is merged to WildFly master, it should be easy
>     to fix the
>      > bug.  The only change that I needed to [2], was to remove the
>     provider from
>      > the persistence.xml.
>      >
>      > For the first approach below, we should probably allow the
>      > "jboss.as.jpa.adapterClass" to specify the
>      >
>     "org.jboss.as.jpa.processor.PersistenceProviderAdaptorLoader.noopAdaptor"
>      > (by name or via a special value).
>
>     Right, being able to "force" usage of the no-op Adaptor like I did
>     with my Byteman rule would give us a lot of nice flexibility.
>
>     BTW once I did that, I noticed that the scanning of entities broke.
>     Apparently entity scanning for Hibernate requires the Scanner which
>     you would provide with the adaptor; would you know why?
>     I'm wondering because it seems related to an Hibernate OGM issue: in
>     that case we don't disable the adapter but still auto-detection of
>     entities doesn't work.
>
>     Thanks!
>     Sanne
>
>      >
>      > Scott
>      >
>      > [1] https://github.com/scottmarlow/wildfly/tree/test_orm41_bundled
>      >
>      > [2] https://github.com/wildfly/wildfly/pull/7509
>      >
>      >
>      > On 06/02/2015 08:15 PM, Sanne Grinovero wrote:
>      >>
>      >> Hi Scott,
>      >> finally got back on this upgrade. You were right, the problem is
>     that
>      >> JipiJapa figures out that I'm using Hibernate - even though I'm not
>      >> hard coding the provider name, as in that case it will just
>     default to
>      >> Hibernate anyway - and because of that it's adding both the JPA
>      >> adaptors for Hibernate 4 and the wrong version of the Hibernate
>      >> dependencies as well.
>      >>
>      >> This is the temporary solution I'm going to use:
>      >>
>      >>
>     https://github.com/hibernate/hibernate-search/commit/d2b05ef7511815d6c0a0779734b95a69cdcbf56d
>      >>
>      >> Thanks for all pointers!
>      >> Sanne
>      >>
>      >>
>      >> On 1 June 2015 at 16:08, Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>> wrote:
>      >>>
>      >>> I suspect that this is a bug in WildFly that we need to track
>     down.  I'm
>      >>> guessing that the condition is that we are trying to use a custom
>      >>> Hibernate
>      >>> module when there is an existing Hibernate module that matches the
>      >>> Persistence provider name.  Or something like that.
>      >>>
>      >>>
>      >>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote:
>      >>>>
>      >>>>
>      >>>> Hi all,
>      >>>> I'm attempting to deploy some integration tests on WildFly
>     9.0.0.CR1
>      >>>> to use a preview of Hibernate ORM version 5.
>      >>>>
>      >>>> It seems the JPA deployer isn't allowing me to run such
>     experiments:
>      >>>>
>      >>>> # First experiment - providerModule set to custom module
>      >>>>
>      >>>> In my first attempt, I create a custom set of jboss modules which
>      >>>> include the snapshot builds of ORM 5, add them to my
>     standalone WF9
>      >>>> instance and set the persistence.xml property:
>      >>>>    jboss.as.jpa.providerModule = my-custom-module-name
>      >>>>
>      >>>> and then get:
>      >>>>
>      >>>> Caused by: java.util.ServiceConfigurationError:
>      >>>> org.hibernate.integrator.spi.Integrator: Provider
>      >>>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype
>      >>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231)
>      >>>> [rt.jar:1.7.0_51]
>      >>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181)
>      >>>> [rt.jar:1.7.0_51]
>      >>>> at
>     java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369)
>      >>>> [rt.jar:1.7.0_51]
>      >>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
>      >>>> [rt.jar:1.7.0_51]
>      >>>> at
>      >>>>
>      >>>>
>     org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341)
>      >>>> at
>      >>>>
>      >>>>
>     org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57)
>      >>>> at
>      >>>>
>      >>>>
>     org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247)
>      >>>> at
>      >>>>
>      >>>>
>     org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520)
>      >>>> at
>      >>>>
>      >>>>
>     org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208)
>      >>>> at
>      >>>>
>      >>>>
>     org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188)
>      >>>> at
>      >>>>
>      >>>>
>     org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45)
>      >>>> at
>      >>>>
>      >>>>
>     org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57)
>      >>>> at
>      >>>>
>      >>>>
>     org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38)
>      >>>> at
>      >>>>
>      >>>>
>     org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173)
>      >>>> at
>      >>>>
>      >>>>
>     org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243)
>      >>>> at
>      >>>>
>      >>>>
>     org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60)
>      >>>> at
>      >>>>
>      >>>>
>     org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118)
>      >>>> ... 7 more
>      >>>>
>      >>>> Clearly it looks like I'm being served classes from the bundled
>      >>>> Hibernate 4.x implementation - on top of those from the module I'm
>      >>>> requesting. This isn't what the deployer should be doing, right?
>      >>>>
>      >>>> # Second experiment - use the "application provided"
>      >>>>
>      >>>> In this case I hope to hint the JPA  deployer to not add the
>     default
>      >>>> implementor but look for a JPA implementation within my
>     deployment,
>      >>>> but still package my custom Hibernate build as a module.
>      >>>>
>      >>>>    - use the same custom module containing Hibernate ORM 5 (a
>     preview
>      >>>> snapshot)
>      >>>>    - Add a "Dependency:" section to the manifest to import
>     (and export)
>      >>>> my custom module
>      >>>>    - set the "jboss.as.jpa.providerModule" property to value
>      >>>> "application"
>      >>>>
>      >>>> This gets me:
>      >>>>
>      >>>> Caused by:
>      >>>> org.jboss.as.server.deployment.DeploymentUnitProcessingException:
>      >>>> WFLYJPA0027: Persistence provider module load error
>     application (class
>      >>>> org.hibernate.jpa.HibernatePersistenceProvider)
>      >>>> at
>      >>>>
>      >>>>
>     org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985)
>      >>>> at
>      >>>>
>      >>>>
>     org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267)
>      >>>> at
>      >>>>
>      >>>>
>     org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200)
>      >>>> at
>      >>>>
>      >>>>
>     org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131)
>      >>>> at
>      >>>>
>      >>>>
>     org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
>      >>>> at
>      >>>>
>      >>>>
>     org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
>      >>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1]
>      >>>> ... 5 more
>      >>>> Caused by: org.jboss.modules.ModuleNotFoundException:
>     application:main
>      >>>> at
>     org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236)
>      >>>> [jboss-modules.jar:1.4.3.Final]
>      >>>> at
>      >>>>
>      >>>>
>     org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65)
>      >>>> at
>      >>>>
>      >>>>
>     org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978)
>      >>>> ... 10 more
>      >>>>
>      >>>> Remarks:
>      >>>>    - it's attempting to load the "application:main" module?!
>     that's not
>      >>>> what I'd expect from reading [1]
>      >>>>    - the provider should be available to the deployment
>     classpath, so
>      >>>> I'm not sure why it's not finding the Provider? (I'm even
>     exporting
>      >>>> it, although I'm not sure if that was required).
>      >>>>
>      >>>> Any suggestions to get this running please?
>      >>>>
>      >>>> Also I wonder if some of these should warrant opening a JIRA,
>     but I'm
>      >>>> not sure how far I misunderstood the intentions of these JPA
>     deployer
>      >>>> properties.
>      >>>>
>      >>>> Thanks,
>      >>>> Sanne
>      >>>>
>      >>>> [1] -
>      >>>>
>      >>>>
>     https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties
>      >>>>
>      >>>
>      >
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From rory.odonnell at oracle.com  Fri Jun  5 05:05:44 2015
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 05 Jun 2015 10:05:44 +0100
Subject: [wildfly-dev] Early Access builds for JDK 9 b66 and JDK 8u60 b18
 are available on java.net
Message-ID: <55716668.6000302@oracle.com>


Hi Jason/Tomaz,

Early Access build for JDK 8u60 b18 <http://jdk8.java.net/download.html> 
is available on java.net, summary of changes are listed here. 
<http://www.java.net/download/jdk8u60/changes/jdk8u60-b18.html>
As we enter the later phases of development for JDK 8u60, please log any 
show stoppers as soon as possible.

Early Access build for JDK 9 b66 <https://jdk9.java.net/download/> is 
available on java.net, summary of  changes are listed here 
<http://www.java.net/download/jdk9/changes/jdk9-b66.html>.

The JDK 9 schedule of record is available on the JDK 9 Project page: 
http://openjdk.java.net/projects/jdk9

At https://wiki.openjdk.java.net/display/Adoption/JDK+9+Outreach you can 
find a (preliminary) list of other
changes that might affect your project's code in JDK 9, and other things 
to consider when testing with JDK 9.
I'd be curious to know if there is anything on that list you'd consider 
to have an effect on your project.

Please keep in mind that as JEPs and others changes are integrated into 
(or out of) JDK 9, the list will change
over time.

Rgds,Rory

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150605/25ec99a9/attachment.html 

From rstryker at redhat.com  Sat Jun  6 00:38:16 2015
From: rstryker at redhat.com (Rob Stryker)
Date: Sat, 06 Jun 2015 00:38:16 -0400
Subject: [wildfly-dev] Question on version of wildfly-protocol jars
Message-ID: <55727938.4010502@redhat.com>

Hey all:

Here's a table of wf releases and what protocol jar version it has. I 
was just curious if there was a discussion on this, and going backwards 
in version was intentional?  Is there anyone (customers, clients, etc) 
out there likely to be confused by this? Or are we just considering it 
internal details and not relevant?

Wildfly Release
	wildfly-protocol jar version
8.0
	wildfly-protocol-8.0.0.Final.jar
8.1
	wildfly-protocol-8.1.0.Final.jar
9.0.CR1
	wildfly-protocol-1.0.0.CR1.jar
EAP7 DR3
	wildfly-protocol-2.0.0.Alpha3.jar



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150606/a300c9cc/attachment.html 

From tomaz.cerar at gmail.com  Sat Jun  6 05:13:07 2015
From: tomaz.cerar at gmail.com (=?utf-8?Q?Toma=C5=BE_Cerar?=)
Date: Sat, 6 Jun 2015 11:13:07 +0200
Subject: [wildfly-dev] Question on version of wildfly-protocol jars
In-Reply-To: <55727938.4010502@redhat.com>
References: <55727938.4010502@redhat.com>
Message-ID: <5572b9a4.c755c20a.9135.4c5b@mx.google.com>

With wildfly 9 we split code to wildfly and wildfly-core.
Protocol jar you are talking about is part of wildfly core and as such has version of the core and not of full app server.

If you look at maven coordinates you will see that protocol jar in 9+ has groupid org.wildfly.core instead of org.wildfly it had in older versions.

Tomaz

Sent from my Phone

-----Original Message-----
From: "Rob Stryker" <rstryker at redhat.com>
Sent: ?6.?6.?2015 6:38
To: "wildfly-dev at lists.jboss.org" <wildfly-dev at lists.jboss.org>
Subject: [wildfly-dev] Question on version of wildfly-protocol jars

Hey all:

Here's a table of wf releases and what protocol jar version it has.  I was just curious if there was a discussion on this, and going backwards in version was intentional?  Is there anyone (customers, clients, etc) out there likely to be confused by this? Or are we just considering it internal details and not relevant?

Wildfly Release
wildfly-protocol jar version

8.0
wildfly-protocol-8.0.0.Final.jar

8.1
wildfly-protocol-8.1.0.Final.jar

9.0.CR1
wildfly-protocol-1.0.0.CR1.jar

EAP7 DR3
wildfly-protocol-2.0.0.Alpha3.jar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150606/5b30b869/attachment.html 

From darran.lofthouse at jboss.com  Sat Jun  6 07:24:04 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Sat, 06 Jun 2015 12:24:04 +0100
Subject: [wildfly-dev] Question on version of wildfly-protocol jars
In-Reply-To: <5572b9a4.c755c20a.9135.4c5b@mx.google.com>
References: <55727938.4010502@redhat.com>
	<5572b9a4.c755c20a.9135.4c5b@mx.google.com>
Message-ID: <5572D854.5040406@jboss.com>

The issue however is that anything that handles ordering of the versions 
is now going to get it wrong - maybe we need a new GA (as in GAV)) if we 
are going to start again for V.



On 06/06/15 10:13, Toma? Cerar wrote:
> With wildfly 9 we split code to wildfly and wildfly-core.
> Protocol jar you are talking about is part of wildfly core and as such
> has version of the core and not of full app server.
>
> If you look at maven coordinates you will see that protocol jar in 9+
> has groupid org.wildfly.core instead of org.wildfly it had in older
> versions.
>
> Tomaz
>
> Sent from my Phone
> ------------------------------------------------------------------------
> From: Rob Stryker <mailto:rstryker at redhat.com>
> Sent: ?6.?6.?2015 6:38
> To: wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> Subject: [wildfly-dev] Question on version of wildfly-protocol jars
>
> Hey all:
>
> Here's a table of wf releases and what protocol jar version it has. I
> was just curious if there was a discussion on this, and going backwards
> in version was intentional?  Is there anyone (customers, clients, etc)
> out there likely to be confused by this? Or are we just considering it
> internal details and not relevant?
>
> Wildfly Release
> 	wildfly-protocol jar version
> 8.0
> 	wildfly-protocol-8.0.0.Final.jar
> 8.1
> 	wildfly-protocol-8.1.0.Final.jar
> 9.0.CR1
> 	wildfly-protocol-1.0.0.CR1.jar
> EAP7 DR3
> 	wildfly-protocol-2.0.0.Alpha3.jar
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From rstryker at redhat.com  Sat Jun  6 14:42:09 2015
From: rstryker at redhat.com (Rob Stryker)
Date: Sat, 06 Jun 2015 14:42:09 -0400
Subject: [wildfly-dev] Question on version of wildfly-protocol jars
In-Reply-To: <5572b9a4.c755c20a.9135.4c5b@mx.google.com>
References: <55727938.4010502@redhat.com>
	<5572b9a4.c755c20a.9135.4c5b@mx.google.com>
Message-ID: <55733F01.1010401@redhat.com>

Yeah, I was aware that this was due to the core split. Didn't notice the 
groupid difference though, so just thought it was possible some others 
might be confused.

Thanks, though.

- Rob Stryker

On 06/06/2015 05:13 AM, Toma? Cerar wrote:
> With wildfly 9 we split code to wildfly and wildfly-core.
> Protocol jar you are talking about is part of wildfly core and as such 
> has version of the core and not of full app server.
>
> If you look at maven coordinates you will see that protocol jar in 9+ 
> has groupid org.wildfly.core instead of org.wildfly it had in older 
> versions.
>
> Tomaz
>
> Sent from my Phone
> ------------------------------------------------------------------------
> From: Rob Stryker <mailto:rstryker at redhat.com>
> Sent: ?6.?6.?2015 6:38
> To: wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> Subject: [wildfly-dev] Question on version of wildfly-protocol jars
>
> Hey all:
>
> Here's a table of wf releases and what protocol jar version it has.  I 
> was just curious if there was a discussion on this, and going 
> backwards in version was intentional?  Is there anyone (customers, 
> clients, etc) out there likely to be confused by this? Or are we just 
> considering it internal details and not relevant?
>
> Wildfly Release
> 	wildfly-protocol jar version
> 8.0
> 	wildfly-protocol-8.0.0.Final.jar
> 8.1
> 	wildfly-protocol-8.1.0.Final.jar
> 9.0.CR1
> 	wildfly-protocol-1.0.0.CR1.jar
> EAP7 DR3
> 	wildfly-protocol-2.0.0.Alpha3.jar
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150606/d3b2e379/attachment.html 

From kustos at gmx.net  Mon Jun  8 02:25:27 2015
From: kustos at gmx.net (Philippe Marschall)
Date: Mon, 08 Jun 2015 08:25:27 +0200
Subject: [wildfly-dev] SimpleRoleGroup#roles
Message-ID: <55753557.9070409@gmx.net>

Hi

I?m aware this may no technically be the right list to discuss this but 
this list is impacted by this and fairly active.

During load testing of our application we found a case we spend 10% of 
your CPU time in SimpleRole#equals (see attachment). This is because 
SimpleRoleGroup uses an ArrayList to maintain a unique set of roles. As 
a result it has to call ArrayList#contains a lot, which is itself O(n). 
In fact because that?s done when iterating over all the roles it becomes 
O(n^2). In our case our principals can have up to 200 roles. I don?t 
know if this is exceptionally many or a common case.

We would like to work on a patch but we need your guidance. There are 
several possible solutions and it all comes down to whether we can 
change the List in the RoleGroup interface to a Collection. All the 
users we searched for in WildFly only used the return value for 
iterating over, nobody used the index. In fact they all used it an a 
for-each loop so the change would even be source compatible but 
unfortunately not binary compatible. If we can change the interface then 
we can just change the ArrayList in SimpleRoleGroup to a HashSet and be 
done with it. If the order is important the we can either use a TreeSet 
or a LinkedHashSet.
If changing the RoleGroup interface is not possible then there are two 
other possibilities. The first is only internally using a Set but in 
getRoles perform a copy. This would produce more garbage. The second 
option would be a having a Set and List (to avoid having to do copies) 
in SimpleRoleGroup. This would avoid having to do a copy and the Set can 
be used for contains checks. Only removeRole would still be O(n) due to 
the scan over ArrayList. The only user we found was 
OptionsRoleMappingProvider.
All of these would change the serialized form. If it is important to 
support reading old instances that could be added as well.

Cheers
Philippe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SimpleRole-equals.png
Type: image/png
Size: 61538 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150608/eeea02d8/attachment-0001.png 

From arjan.tijms at gmail.com  Mon Jun  8 06:08:57 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 8 Jun 2015 12:08:57 +0200
Subject: [wildfly-dev] SimpleRoleGroup#roles
In-Reply-To: <55753557.9070409@gmx.net>
References: <55753557.9070409@gmx.net>
Message-ID: <CAE=-AhC=EH22dYx=Dd5YDaJLBmrHEKuQggr5_=PXMqcJfdnAjQ@mail.gmail.com>

Hi,

On Mon, Jun 8, 2015 at 8:25 AM, Philippe Marschall <kustos at gmx.net> wrote:

> Hi
>
> I?m aware this may no technically be the right list to discuss this but
> this list is impacted by this and fairly active.
>
> During load testing of our application we found a case we spend 10% of
> your CPU time in SimpleRole#equals (see attachment). This is because
> SimpleRoleGroup uses an ArrayList to maintain a unique set of roles. As a
> result it has to call ArrayList#contains a lot, which is itself O(n). In
> fact because that?s done when iterating over all the roles it becomes
> O(n^2). In our case our principals can have up to 200 roles. I don?t know
> if this is exceptionally many or a common case.
>

200 doesn't seem like so many. The "problem" often is that the term "role"
makes people think they are only allowed to use it for things like
"administrator" and "manager" and such. In that view 200 may be much.

But, nothing in Java EE security imposes this, and if you want to use roles
with names like "can_see_updated_interest", then 200 is really nothing.

>From the call stack, I guess this is triggered via @RolesAllowed on an EJB
right?

Theoretically, this is where JACC could come in according to the Java EE
standards. This would allow you to implement your own (optimized if
necessary) logic for "is user/caller in role".

However despite being Java EE 7 certified, it seems it's not actually
possible to install a JACC provider on JBoss. This is a bit of a spec hole,
unfortunately. Most of the code seems to be there in JBoss (WildFly), but
there's just no place where you can actually put your own JACC provider.

Kind regards,
Arjan Tijms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150608/30974861/attachment.html 

From sguilhen at redhat.com  Mon Jun  8 09:20:36 2015
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Mon, 08 Jun 2015 10:20:36 -0300
Subject: [wildfly-dev] SimpleRoleGroup#roles
In-Reply-To: <55753557.9070409@gmx.net>
References: <55753557.9070409@gmx.net>
Message-ID: <557596A4.8000606@redhat.com>

The order of the roles is not important. I think we should change the 
SimpleRole implementation in PicketBox to use Collection (HashSet) 
reference instead of List and then change any WildFly code that might be 
using the List reference.

On 06/08/2015 03:25 AM, Philippe Marschall wrote:
> Hi
>
> I?m aware this may no technically be the right list to discuss this 
> but this list is impacted by this and fairly active.
>
> During load testing of our application we found a case we spend 10% of 
> your CPU time in SimpleRole#equals (see attachment). This is because 
> SimpleRoleGroup uses an ArrayList to maintain a unique set of roles. 
> As a result it has to call ArrayList#contains a lot, which is itself 
> O(n). In fact because that?s done when iterating over all the roles it 
> becomes O(n^2). In our case our principals can have up to 200 roles. I 
> don?t know if this is exceptionally many or a common case.
>
> We would like to work on a patch but we need your guidance. There are 
> several possible solutions and it all comes down to whether we can 
> change the List in the RoleGroup interface to a Collection. All the 
> users we searched for in WildFly only used the return value for 
> iterating over, nobody used the index. In fact they all used it an a 
> for-each loop so the change would even be source compatible but 
> unfortunately not binary compatible. If we can change the interface 
> then we can just change the ArrayList in SimpleRoleGroup to a HashSet 
> and be done with it. If the order is important the we can either use a 
> TreeSet or a LinkedHashSet.
> If changing the RoleGroup interface is not possible then there are two 
> other possibilities. The first is only internally using a Set but in 
> getRoles perform a copy. This would produce more garbage. The second 
> option would be a having a Set and List (to avoid having to do copies) 
> in SimpleRoleGroup. This would avoid having to do a copy and the Set 
> can be used for contains checks. Only removeRole would still be O(n) 
> due to the scan over ArrayList. The only user we found was 
> OptionsRoleMappingProvider.
> All of these would change the serialized form. If it is important to 
> support reading old instances that could be added as well.
>
> Cheers
> Philippe
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150608/62dc57aa/attachment.html 

From sguilhen at redhat.com  Mon Jun  8 09:42:16 2015
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Mon, 08 Jun 2015 10:42:16 -0300
Subject: [wildfly-dev] SimpleRoleGroup#roles
In-Reply-To: <CAE=-AhC=EH22dYx=Dd5YDaJLBmrHEKuQggr5_=PXMqcJfdnAjQ@mail.gmail.com>
References: <55753557.9070409@gmx.net>
	<CAE=-AhC=EH22dYx=Dd5YDaJLBmrHEKuQggr5_=PXMqcJfdnAjQ@mail.gmail.com>
Message-ID: <55759BB8.9000808@redhat.com>

On 06/08/2015 07:08 AM, arjan tijms wrote:
>
> Theoretically, this is where JACC could come in according to the Java 
> EE standards. This would allow you to implement your own (optimized if 
> necessary) logic for "is user/caller in role".
>
> However despite being Java EE 7 certified, it seems it's not actually 
> possible to install a JACC provider on JBoss. This is a bit of a spec 
> hole, unfortunately. Most of the code seems to be there in JBoss 
> (WildFly), but there's just no place where you can actually put your 
> own JACC provider.

Huh? We would not be certified if we didn't support custom providers as 
the TCK requires the installation of its own provider. The 
javax.security.jacc.PolicyConfigurationFactory.provider and 
javax.security.jacc.policy.provider system properties are both supported 
by WildFly.

>
> Kind regards,
> Arjan Tijms
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150608/e3eb6f36/attachment.html 

From arjan.tijms at gmail.com  Mon Jun  8 09:55:00 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 8 Jun 2015 15:55:00 +0200
Subject: [wildfly-dev] SimpleRoleGroup#roles
In-Reply-To: <55759BB8.9000808@redhat.com>
References: <55753557.9070409@gmx.net>
	<CAE=-AhC=EH22dYx=Dd5YDaJLBmrHEKuQggr5_=PXMqcJfdnAjQ@mail.gmail.com>
	<55759BB8.9000808@redhat.com>
Message-ID: <CAE=-AhC1oCXAPsH2=8=Y4-8+LZESrd9Xe1pPbmCupErZ=QVW8Q@mail.gmail.com>

Hi,

On Mon, Jun 8, 2015 at 3:42 PM, Stefan Guilhen <sguilhen at redhat.com> wrote:

>  On 06/08/2015 07:08 AM, arjan tijms wrote:
>
>
> Theoretically, this is where JACC could come in according to the Java EE
> standards. This would allow you to implement your own (optimized if
> necessary) logic for "is user/caller in role".
>
>  However despite being Java EE 7 certified, it seems it's not actually
> possible to install a JACC provider on JBoss. This is a bit of a spec hole,
> unfortunately. Most of the code seems to be there in JBoss (WildFly), but
> there's just no place where you can actually put your own JACC provider.
>
>
> Huh? We would not be certified if we didn't support custom providers as
> the TCK requires the installation of its own provider. The
> javax.security.jacc.PolicyConfigurationFactory.provider and
> javax.security.jacc.policy.provider system properties are both supported by
> WildFly.
>

Indeed, you would say that. But I do know that a TCK can be lacking "a
little", specifically where it concerns JASPIC and JACC, unfortunately.
There are a few other major violations in various certified products. With
JASPIC for instance it was possible to certify a product that just didn't
implement the actual authentication, which is the core of the core of
JASPIC :X

Those properties are of course supported, but where does one put the
classes (or jar containing these classes)? I tried for hours at end and
asked in the JBoss forum, but it never became clear. The documentation
doesn't mention it either. See this for my question about this:
https://developer.jboss.org/thread/254106

Would be really cool if the location could become clear. Thanks!

Kind regards,
Arjan Tijms




















>
>
>  Kind regards,
> Arjan Tijms
>
>
> _______________________________________________
> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150608/07609b32/attachment.html 

From sgilda at redhat.com  Mon Jun  8 11:48:28 2015
From: sgilda at redhat.com (Sande Gilda)
Date: Mon, 08 Jun 2015 11:48:28 -0400
Subject: [wildfly-dev] WildFly 10 documentation is now available: Migration
	content needed!
In-Reply-To: <5554BDE2.1080308@redhat.com>
References: <5554BDE2.1080308@redhat.com>
Message-ID: <5575B94C.9060900@redhat.com>

I am responsible for documenting how to migrate an application from AS 7 
to Wildfly 10 and have created the following page to document these changes:

    https://docs.jboss.org/author/display/WFLY10/How+do+I+migrate+my+application+from+AS7+to+WildFly

If you worked on a component that has changed or been replaced, or have 
experience or knowledge about what needs to be updated when migrating an 
AS 7 application to Wildfly 10, please consider adding content to this 
page. Those of you who were around for AS 7 will recall I did this for 
migration from AS5/6 --> AS7 (see 
https://docs.jboss.org/author/display/AS72/How+do+I+migrate+my+application+from+AS5+or+AS6+to+AS7) 
and everyone was great about contributing to that content.

Thanks in advance and please contact me if you have any questions!

Thanks,
Sande


On 05/14/2015 11:23 AM, Scott Marlow wrote:
> We cloned the WildFly 9 documentation into WildFly 10.  Please go
> through and correct the references to WildFly 9 (or 8) in your area.  In
> some cases, it might make sense to remove the version number to make
> this easier next time (if the context still makes sense).
>
> Thanks,
> Scott
>
> [1]https://docs.jboss.org/author/display/WFLY10
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150608/d587f5d0/attachment-0001.html 

From sgilda at redhat.com  Mon Jun  8 11:53:00 2015
From: sgilda at redhat.com (Sande Gilda)
Date: Mon, 08 Jun 2015 11:53:00 -0400
Subject: [wildfly-dev] Migration content needed for AS 7 --> WildFly 10
In-Reply-To: <5575B94C.9060900@redhat.com>
References: <5554BDE2.1080308@redhat.com> <5575B94C.9060900@redhat.com>
Message-ID: <5575BA5C.90805@redhat.com>

$Subject change :-)

On 06/08/2015 11:48 AM, Sande Gilda wrote:
> I am responsible for documenting how to migrate an application from AS 
> 7 to WildFly 10 and have created the following page to document these 
> changes:
>
>     https://docs.jboss.org/author/display/WFLY10/How+do+I+migrate+my+application+from+AS7+to+WildFly
>
> If you worked on a component that has changed or been replaced, or 
> have experience or knowledge about what needs to be updated when 
> migrating an AS 7 application to WildFly 10, please consider adding 
> content to this page. Those of you who were around for AS 7 will 
> recall I did this for migration from AS5/6 --> AS7 (see 
> https://docs.jboss.org/author/display/AS72/How+do+I+migrate+my+application+from+AS5+or+AS6+to+AS7) 
> and everyone was great about contributing to that content.
>
> Thanks in advance and please contact me if you have any questions!
>
> Thanks,
> Sande
>
>
> On 05/14/2015 11:23 AM, Scott Marlow wrote:
>> We cloned the WildFly 9 documentation into WildFly 10.  Please go
>> through and correct the references to WildFly 9 (or 8) in your area.  In
>> some cases, it might make sense to remove the version number to make
>> this easier next time (if the context still makes sense).
>>
>> Thanks,
>> Scott
>>
>> [1]https://docs.jboss.org/author/display/WFLY10
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150608/f47171dd/attachment.html 

From sgilda at redhat.com  Mon Jun  8 12:40:31 2015
From: sgilda at redhat.com (Sande Gilda)
Date: Mon, 08 Jun 2015 12:40:31 -0400
Subject: [wildfly-dev] Migration content needed for AS 7 --> WildFly 10
Message-ID: <5575C57F.60501@redhat.com>

I am responsible for documenting how to migrate an application from AS 7 
to Wildfly 10 and have created the following page to document these changes:

    https://docs.jboss.org/author/display/WFLY10/How+do+I+migrate+my+application+from+AS7+to+WildFly

If you worked on a component that has changed or been replaced, or have 
experience or knowledge about what needs to be updated when migrating an 
AS 7 application to Wildfly 10, please consider adding content to this 
page. Those of you who were around for AS 7 will recall I did this for 
migration from AS5/6 --> AS7 (see 
https://docs.jboss.org/author/display/AS72/How+do+I+migrate+my+application+from+AS5+or+AS6+to+AS7) 
and everyone was great about contributing to that content.

Thanks in advance and please contact me if you have any questions!

Thanks,
Sande

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150608/90f9ce1a/attachment.html 

From jkinlaw at redhat.com  Mon Jun  8 13:40:32 2015
From: jkinlaw at redhat.com (Josh Kinlaw)
Date: Mon, 8 Jun 2015 13:40:32 -0400 (EDT)
Subject: [wildfly-dev] Help with module.xml - Getting a ProcessingException
	at Runtime
In-Reply-To: <197721997.11496952.1433783019141.JavaMail.zimbra@redhat.com>
Message-ID: <1307804255.11515076.1433785232601.JavaMail.zimbra@redhat.com>

Hi Wildfly,

I am running into what appears to be a module.xml issue. I am using resteasy to post a multipart/form-data entity but am running into the following exception at runtime:

12:56:34,869 ERROR [stderr] (Thread-91) javax.ws.rs.ProcessingException: Unable to invoke request
12:56:34,869 ERROR [stderr] (Thread-91) 	at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:287)
12:56:34,870 ERROR [stderr] (Thread-91) 	at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:407)
12:56:34,870 ERROR [stderr] (Thread-91) 	at org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilder.post(ClientInvocationBuilder.java:195)
12:56:34,870 ERROR [stderr] (Thread-91) 	at com.redhat.gss.redhat_support_lib.infrastructure.BaseQuery.upload(BaseQuery.java:169)
12:56:34,870 ERROR [stderr] (Thread-91) 	at org.jboss.as.telemetry.extension.TelemetryService.sendJdr(TelemetryService.java:354)
12:56:34,870 ERROR [stderr] (Thread-91) 	at org.jboss.as.telemetry.extension.TelemetryService.access$300(TelemetryService.java:34)
12:56:34,871 ERROR [stderr] (Thread-91) 	at org.jboss.as.telemetry.extension.TelemetryService$1.run(TelemetryService.java:120)
12:56:34,871 ERROR [stderr] (Thread-91) Caused by: javax.ws.rs.ProcessingException: could not find writer for content-type multipart/form-data type: org.jboss.resteasy.plugins.providers.multipart.MultipartFormDataOutput
12:56:34,871 ERROR [stderr] (Thread-91) 	at org.jboss.resteasy.core.interception.ClientWriterInterceptorContext.throwWriterNotFoundException(ClientWriterInterceptorContext.java:40)
12:56:34,871 ERROR [stderr] (Thread-91) 	at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.getWriter(AbstractWriterInterceptorContext.java:138)
12:56:34,871 ERROR [stderr] (Thread-91) 	at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:117)
12:56:34,871 ERROR [stderr] (Thread-91) 	at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.writeRequestBody(ClientInvocation.java:341)
12:56:34,872 ERROR [stderr] (Thread-91) 	at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.writeRequestBodyToOutputStream(ApacheHttpClient4Engine.java:558)
12:56:34,872 ERROR [stderr] (Thread-91) 	at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.buildEntity(ApacheHttpClient4Engine.java:524)
12:56:34,872 ERROR [stderr] (Thread-91) 	at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.loadHttpMethod(ApacheHttpClient4Engine.java:423)
12:56:34,872 ERROR [stderr] (Thread-91) 	at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:281)
12:56:34,872 ERROR [stderr] (Thread-91) 	... 6 more

I'm including resteasy-multipart-provider in my submodule's pom and module.xml and if I run the unit tests for the submodule (redhat-support-lib) everything passes. This leads me to believe it is an issue with the module.xml of either resteasy-multipart-provider or redhat-support-lib. Below are the module.xml's:

resteasy-multipart-provider:

<?xml version="1.0" encoding="UTF-8"?>

<module xmlns="urn:jboss:module:1.3" name="org.jboss.resteasy.resteasy-multipart-provider">

    <resources>
        <resource-root path="resteasy-multipart-provider-3.0.11.Final.jar"/>
    </resources>

    <dependencies>
        <module name="javax.xml.bind.api"/>
        <module name="javax.api"/>
        <module name="javax.enterprise.api"/>
        <module name="javax.mail.api"/>
        <module name="javax.servlet.api"/>
        <module name="javax.ws.rs.api"/>
        <module name="org.apache.james.mime4j"/>
        <module name="org.jboss.resteasy.resteasy-jaxb-provider"/>
        <module name="org.jboss.resteasy.resteasy-jaxrs"/>
        <module name="org.jboss.resteasy.tjws"/>
    </dependencies>
</module>


redhat-support-lib:

<module xmlns="urn:jboss:module:1.0" name="com.redhat.gss.redhat-support-lib">
    <resources>
        <resource-root path="jboss-redhat-support-lib.jar"/>
    </resources>
    
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.ws.rs.api"/>
        <module name="javax.net.ssl"/>
        <module name="org.apache.commons.net"/>
        <module name="org.apache.httpcomponents"/>
        <module name="org.jboss.staxmapper"/>
        <module name="org.jboss.as.controller"/>
        <module name="org.jboss.as.server"/>
        <module name="org.jboss.modules"/>
        <module name="org.jboss.msc"/>
        <module name="org.jboss.logging"/>
        <module name="org.jboss.resteasy.resteasy-multipart-provider" services="export" export="true"/>
        <module name="org.jboss.resteasy.resteasy-jaxrs"/>
        <module name="org.jboss.vfs"/>        
    </dependencies>
</module>


I'm a little stuck at this point. Does anyone have any ideas? My git repo is at https://github.com/Kinlaw/wildfly/tree/telemetry.

Josh Kinlaw



From sguilhen at redhat.com  Mon Jun  8 14:26:42 2015
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Mon, 08 Jun 2015 15:26:42 -0300
Subject: [wildfly-dev] SimpleRoleGroup#roles
In-Reply-To: <CAE=-AhC1oCXAPsH2=8=Y4-8+LZESrd9Xe1pPbmCupErZ=QVW8Q@mail.gmail.com>
References: <55753557.9070409@gmx.net>	<CAE=-AhC=EH22dYx=Dd5YDaJLBmrHEKuQggr5_=PXMqcJfdnAjQ@mail.gmail.com>	<55759BB8.9000808@redhat.com>
	<CAE=-AhC1oCXAPsH2=8=Y4-8+LZESrd9Xe1pPbmCupErZ=QVW8Q@mail.gmail.com>
Message-ID: <5575DE62.80207@redhat.com>

Arjan,

On 06/08/2015 10:55 AM, arjan tijms wrote:
> Hi,
>
> Indeed, you would say that. But I do know that a TCK can be lacking "a 
> little", specifically where it concerns JASPIC and JACC, 
> unfortunately. There are a few other major violations in various 
> certified products. With JASPIC for instance it was possible to 
> certify a product that just didn't implement the actual 
> authentication, which is the core of the core of JASPIC :X

The TCK coverage (or lack thereof) has nothing to do with the ability to 
configure custom JACC providers. If we didn't support it not a single 
test of the JACC testsuite would pass so the TCK is not to be blamed in 
this case. The JASPIC testsuite is another story and I think we both 
agree that it is broken from our previous conversations. Arun's JEE 
testsuite, to which you contributed your JASPIC tests, has been much 
more valuable as a tool to validate the implementation than the TCK itself.

Having said that, the documentation does really seem to be missing a 
section about custom JACC providers so I went to check the TCK setup. It 
looks like the TCK JACC providers are bundled in a jar and this jar is 
being set as a resource of the org.jboss.as.security module. I'm not 
sure why it was done this way but I believe it should be also possible 
to define your own module containing the classes and then wire it to the 
security module as a dependency instead of a resource.

>
> Those properties are of course supported, but where does one put the 
> classes (or jar containing these classes)? I tried for hours at end 
> and asked in the JBoss forum, but it never became clear. The 
> documentation doesn't mention it either. See this for my question 
> about this: https://developer.jboss.org/thread/254106
>
> Would be really cool if the location could become clear. Thanks!
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>>
>>     Kind regards,
>>     Arjan Tijms
>>
>>
>>     _______________________________________________
>>     wildfly-dev mailing list
>>     wildfly-dev at lists.jboss.org  <mailto:wildfly-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150608/1ac79add/attachment.html 

From arjan.tijms at gmail.com  Mon Jun  8 15:04:54 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 8 Jun 2015 21:04:54 +0200
Subject: [wildfly-dev] SimpleRoleGroup#roles
In-Reply-To: <5575DE62.80207@redhat.com>
References: <55753557.9070409@gmx.net>
	<CAE=-AhC=EH22dYx=Dd5YDaJLBmrHEKuQggr5_=PXMqcJfdnAjQ@mail.gmail.com>
	<55759BB8.9000808@redhat.com>
	<CAE=-AhC1oCXAPsH2=8=Y4-8+LZESrd9Xe1pPbmCupErZ=QVW8Q@mail.gmail.com>
	<5575DE62.80207@redhat.com>
Message-ID: <CAE=-AhDy6dvxi2gSU8wfdNdf43Fh9czYgKg3DAkfprMX_g08Yg@mail.gmail.com>

Hi there,

On Mon, Jun 8, 2015 at 8:26 PM, Stefan Guilhen <sguilhen at redhat.com> wrote:

>  The TCK coverage (or lack thereof) has nothing to do with the ability to
> configure custom JACC providers. If we didn't support it not a single test
> of the JACC testsuite would pass so the TCK is not to be blamed in this
> case.
>

Well, one of the requirements of JACC is that the Java EE product has a
default JACC provider (which implements the authorization algorithms as
defined by both the Servlet and EJB containers). So it could
*theoretically* have been the case that the TCK only tests that one. Of
course I don't know if this is indeed the case.

JBoss indeed has such a default provider. However, the spec also requires
(I think) that in a full Java EE server all authorization decisions (for
the APIs defined by Servlet and EJB) go via JACC, which clearly does not
happen in JBoss. As far as I know, only GlassFish really does this, while
TMaxSoft JEUS comes close.




> The JASPIC testsuite is another story and I think we both agree that it is
> broken from our previous conversations. Arun's JEE testsuite, to which you
> contributed your JASPIC tests, has been much more valuable as a tool to
> validate the implementation than the TCK itself.
>

I'm really glad they helped ;)



>
> Having said that, the documentation does really seem to be missing a
> section about custom JACC providers so I went to check the TCK setup. It
> looks like the TCK JACC providers are bundled in a jar and this jar is
> being set as a resource of the org.jboss.as.security module. I'm not sure
> why it was done this way but I believe it should be also possible to define
> your own module containing the classes and then wire it to the security
> module as a dependency instead of a resource.
>

Hmmm, how would one go about doing that exactly? I think I created a module
for my custom JACC provider, then set that as a dependency for the security
module (since that was the place the default implementation lives), but it
again did not work (class not found exceptions). Could well be the case
that I did something wrong, so an example would be great.

Kind regards,
Arjan Tijms



>
>
>
> Those properties are of course supported, but where does one put the
> classes (or jar containing these classes)? I tried for hours at end and
> asked in the JBoss forum, but it never became clear. The documentation
> doesn't mention it either. See this for my question about this:
> https://developer.jboss.org/thread/254106
>
>  Would be really cool if the location could become clear. Thanks!
>
>  Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>>
>>
>>  Kind regards,
>> Arjan Tijms
>>
>>
>> _______________________________________________
>> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150608/4a43f832/attachment-0001.html 

From stuart.w.douglas at gmail.com  Tue Jun  9 01:09:34 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 09 Jun 2015 05:09:34 +0000
Subject: [wildfly-dev] Help with module.xml - Getting a
 ProcessingException at Runtime
In-Reply-To: <1307804255.11515076.1433785232601.JavaMail.zimbra@redhat.com>
References: <197721997.11496952.1433783019141.JavaMail.zimbra@redhat.com>
	<1307804255.11515076.1433785232601.JavaMail.zimbra@redhat.com>
Message-ID: <CAAoo=c5RfTKtrUOk3t8Ck8SnApRE7OybVYRyxkA-uDmUGnzTZA@mail.gmail.com>

What TCCL is set when you are creating the client/client builder ? AFAIK
Resteasy will use the TCCL to look for providers in this case, so if it is
not set to your modules TCCL you may have problems.

Stuart

On Mon, 8 Jun 2015 at 19:41 Josh Kinlaw <jkinlaw at redhat.com> wrote:

> Hi Wildfly,
>
> I am running into what appears to be a module.xml issue. I am using
> resteasy to post a multipart/form-data entity but am running into the
> following exception at runtime:
>
> 12:56:34,869 ERROR [stderr] (Thread-91) javax.ws.rs.ProcessingException:
> Unable to invoke request
> 12:56:34,869 ERROR [stderr] (Thread-91)         at
> org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:287)
> 12:56:34,870 ERROR [stderr] (Thread-91)         at
> org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:407)
> 12:56:34,870 ERROR [stderr] (Thread-91)         at
> org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilder.post(ClientInvocationBuilder.java:195)
> 12:56:34,870 ERROR [stderr] (Thread-91)         at
> com.redhat.gss.redhat_support_lib.infrastructure.BaseQuery.upload(BaseQuery.java:169)
> 12:56:34,870 ERROR [stderr] (Thread-91)         at
> org.jboss.as.telemetry.extension.TelemetryService.sendJdr(TelemetryService.java:354)
> 12:56:34,870 ERROR [stderr] (Thread-91)         at
> org.jboss.as.telemetry.extension.TelemetryService.access$300(TelemetryService.java:34)
> 12:56:34,871 ERROR [stderr] (Thread-91)         at
> org.jboss.as.telemetry.extension.TelemetryService$1.run(TelemetryService.java:120)
> 12:56:34,871 ERROR [stderr] (Thread-91) Caused by: javax.ws.rs.ProcessingException:
> could not find writer for content-type multipart/form-data type:
> org.jboss.resteasy.plugins.providers.multipart.MultipartFormDataOutput
> 12:56:34,871 ERROR [stderr] (Thread-91)         at
> org.jboss.resteasy.core.interception.ClientWriterInterceptorContext.throwWriterNotFoundException(ClientWriterInterceptorContext.java:40)
> 12:56:34,871 ERROR [stderr] (Thread-91)         at
> org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.getWriter(AbstractWriterInterceptorContext.java:138)
> 12:56:34,871 ERROR [stderr] (Thread-91)         at
> org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:117)
> 12:56:34,871 ERROR [stderr] (Thread-91)         at
> org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.writeRequestBody(ClientInvocation.java:341)
> 12:56:34,872 ERROR [stderr] (Thread-91)         at
> org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.writeRequestBodyToOutputStream(ApacheHttpClient4Engine.java:558)
> 12:56:34,872 ERROR [stderr] (Thread-91)         at
> org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.buildEntity(ApacheHttpClient4Engine.java:524)
> 12:56:34,872 ERROR [stderr] (Thread-91)         at
> org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.loadHttpMethod(ApacheHttpClient4Engine.java:423)
> 12:56:34,872 ERROR [stderr] (Thread-91)         at
> org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:281)
> 12:56:34,872 ERROR [stderr] (Thread-91)         ... 6 more
>
> I'm including resteasy-multipart-provider in my submodule's pom and
> module.xml and if I run the unit tests for the submodule
> (redhat-support-lib) everything passes. This leads me to believe it is an
> issue with the module.xml of either resteasy-multipart-provider or
> redhat-support-lib. Below are the module.xml's:
>
> resteasy-multipart-provider:
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <module xmlns="urn:jboss:module:1.3"
> name="org.jboss.resteasy.resteasy-multipart-provider">
>
>     <resources>
>         <resource-root
> path="resteasy-multipart-provider-3.0.11.Final.jar"/>
>     </resources>
>
>     <dependencies>
>         <module name="javax.xml.bind.api"/>
>         <module name="javax.api"/>
>         <module name="javax.enterprise.api"/>
>         <module name="javax.mail.api"/>
>         <module name="javax.servlet.api"/>
>         <module name="javax.ws.rs.api"/>
>         <module name="org.apache.james.mime4j"/>
>         <module name="org.jboss.resteasy.resteasy-jaxb-provider"/>
>         <module name="org.jboss.resteasy.resteasy-jaxrs"/>
>         <module name="org.jboss.resteasy.tjws"/>
>     </dependencies>
> </module>
>
>
> redhat-support-lib:
>
> <module xmlns="urn:jboss:module:1.0"
> name="com.redhat.gss.redhat-support-lib">
>     <resources>
>         <resource-root path="jboss-redhat-support-lib.jar"/>
>     </resources>
>
>     <dependencies>
>         <module name="javax.api"/>
>         <module name="javax.ws.rs.api"/>
>         <module name="javax.net.ssl"/>
>         <module name="org.apache.commons.net"/>
>         <module name="org.apache.httpcomponents"/>
>         <module name="org.jboss.staxmapper"/>
>         <module name="org.jboss.as.controller"/>
>         <module name="org.jboss.as.server"/>
>         <module name="org.jboss.modules"/>
>         <module name="org.jboss.msc"/>
>         <module name="org.jboss.logging"/>
>         <module name="org.jboss.resteasy.resteasy-multipart-provider"
> services="export" export="true"/>
>         <module name="org.jboss.resteasy.resteasy-jaxrs"/>
>         <module name="org.jboss.vfs"/>
>     </dependencies>
> </module>
>
>
> I'm a little stuck at this point. Does anyone have any ideas? My git repo
> is at https://github.com/Kinlaw/wildfly/tree/telemetry.
>
> Josh Kinlaw
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150609/2730f109/attachment.html 

From kustos at gmx.net  Tue Jun  9 01:37:31 2015
From: kustos at gmx.net (Philippe Marschall)
Date: Tue, 09 Jun 2015 07:37:31 +0200
Subject: [wildfly-dev] SimpleRoleGroup#roles
In-Reply-To: <557596A4.8000606@redhat.com>
References: <55753557.9070409@gmx.net> <557596A4.8000606@redhat.com>
Message-ID: <55767B9B.3060400@gmx.net>

Very well, we can do that. How do you feel about breaking the serialized 
form?


On 08.06.2015 15:20, Stefan Guilhen wrote:
> The order of the roles is not important. I think we should change the
> SimpleRole implementation in PicketBox to use Collection (HashSet)
> reference instead of List and then change any WildFly code that might be
> using the List reference.
>
> On 06/08/2015 03:25 AM, Philippe Marschall wrote:
>> Hi
>>
>> I?m aware this may no technically be the right list to discuss this
>> but this list is impacted by this and fairly active.
>>
>> During load testing of our application we found a case we spend 10% of
>> your CPU time in SimpleRole#equals (see attachment). This is because
>> SimpleRoleGroup uses an ArrayList to maintain a unique set of roles.
>> As a result it has to call ArrayList#contains a lot, which is itself
>> O(n). In fact because that?s done when iterating over all the roles it
>> becomes O(n^2). In our case our principals can have up to 200 roles. I
>> don?t know if this is exceptionally many or a common case.
>>
>> We would like to work on a patch but we need your guidance. There are
>> several possible solutions and it all comes down to whether we can
>> change the List in the RoleGroup interface to a Collection. All the
>> users we searched for in WildFly only used the return value for
>> iterating over, nobody used the index. In fact they all used it an a
>> for-each loop so the change would even be source compatible but
>> unfortunately not binary compatible. If we can change the interface
>> then we can just change the ArrayList in SimpleRoleGroup to a HashSet
>> and be done with it. If the order is important the we can either use a
>> TreeSet or a LinkedHashSet.
>> If changing the RoleGroup interface is not possible then there are two
>> other possibilities. The first is only internally using a Set but in
>> getRoles perform a copy. This would produce more garbage. The second
>> option would be a having a Set and List (to avoid having to do copies)
>> in SimpleRoleGroup. This would avoid having to do a copy and the Set
>> can be used for contains checks. Only removeRole would still be O(n)
>> due to the scan over ArrayList. The only user we found was
>> OptionsRoleMappingProvider.
>> All of these would change the serialized form. If it is important to
>> support reading old instances that could be added as well.
>>
>> Cheers
>> Philippe
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From emartins at redhat.com  Tue Jun  9 06:09:22 2015
From: emartins at redhat.com (Eduardo Martins)
Date: Tue, 9 Jun 2015 11:09:22 +0100
Subject: [wildfly-dev] Migration content needed for AS 7 --> WildFly 10
In-Reply-To: <5575C57F.60501@redhat.com>
References: <5575C57F.60501@redhat.com>
Message-ID: <F445D4DA-3AAB-4CFE-B4D2-7DDB0E80C9DF@redhat.com>

Let?s work together on this, I?m gonna fill the technical info, and you do the editing.

?E

> On 08 Jun 2015, at 17:40, Sande Gilda <sgilda at redhat.com> wrote:
> 
> I am responsible for documenting how to migrate an application from AS 7 to Wildfly 10 and have created the following page to document these changes:
> https://docs.jboss.org/author/display/WFLY10/How+do+I+migrate+my+application+from+AS7+to+WildFly <https://docs.jboss.org/author/display/WFLY10/How+do+I+migrate+my+application+from+AS7+to+WildFly>
> If you worked on a component that has changed or been replaced, or have experience or knowledge about what needs to be updated when migrating an AS 7 application to Wildfly 10, please consider adding content to this page. Those of you who were around for AS 7 will recall I did this for migration from AS5/6 --> AS7 (see https://docs.jboss.org/author/display/AS72/How+do+I+migrate+my+application+from+AS5+or+AS6+to+AS7 <https://docs.jboss.org/author/display/AS72/How+do+I+migrate+my+application+from+AS5+or+AS6+to+AS7>) and everyone was great about contributing to that content.
> 
> Thanks in advance and please contact me if you have any questions!
> 
> Thanks,
> Sande
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150609/01458b1c/attachment.html 

From david.lloyd at redhat.com  Tue Jun  9 08:51:13 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 09 Jun 2015 07:51:13 -0500
Subject: [wildfly-dev] SimpleRoleGroup#roles
In-Reply-To: <55767B9B.3060400@gmx.net>
References: <55753557.9070409@gmx.net> <557596A4.8000606@redhat.com>
	<55767B9B.3060400@gmx.net>
Message-ID: <5576E141.3020108@redhat.com>

You don't have to break the serialized form to make this kind of change. 
  Have a look at this: 
https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250

Set that up, plus a customized readObject()/writeObject(), and you can 
retain serialization compatibility.

On 06/09/2015 12:37 AM, Philippe Marschall wrote:
> Very well, we can do that. How do you feel about breaking the serialized
> form?
>
>
> On 08.06.2015 15:20, Stefan Guilhen wrote:
>> The order of the roles is not important. I think we should change the
>> SimpleRole implementation in PicketBox to use Collection (HashSet)
>> reference instead of List and then change any WildFly code that might be
>> using the List reference.
>>
>> On 06/08/2015 03:25 AM, Philippe Marschall wrote:
>>> Hi
>>>
>>> I?m aware this may no technically be the right list to discuss this
>>> but this list is impacted by this and fairly active.
>>>
>>> During load testing of our application we found a case we spend 10% of
>>> your CPU time in SimpleRole#equals (see attachment). This is because
>>> SimpleRoleGroup uses an ArrayList to maintain a unique set of roles.
>>> As a result it has to call ArrayList#contains a lot, which is itself
>>> O(n). In fact because that?s done when iterating over all the roles it
>>> becomes O(n^2). In our case our principals can have up to 200 roles. I
>>> don?t know if this is exceptionally many or a common case.
>>>
>>> We would like to work on a patch but we need your guidance. There are
>>> several possible solutions and it all comes down to whether we can
>>> change the List in the RoleGroup interface to a Collection. All the
>>> users we searched for in WildFly only used the return value for
>>> iterating over, nobody used the index. In fact they all used it an a
>>> for-each loop so the change would even be source compatible but
>>> unfortunately not binary compatible. If we can change the interface
>>> then we can just change the ArrayList in SimpleRoleGroup to a HashSet
>>> and be done with it. If the order is important the we can either use a
>>> TreeSet or a LinkedHashSet.
>>> If changing the RoleGroup interface is not possible then there are two
>>> other possibilities. The first is only internally using a Set but in
>>> getRoles perform a copy. This would produce more garbage. The second
>>> option would be a having a Set and List (to avoid having to do copies)
>>> in SimpleRoleGroup. This would avoid having to do a copy and the Set
>>> can be used for contains checks. Only removeRole would still be O(n)
>>> due to the scan over ArrayList. The only user we found was
>>> OptionsRoleMappingProvider.
>>> All of these would change the serialized form. If it is important to
>>> support reading old instances that could be added as well.
>>>
>>> Cheers
>>> Philippe
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML

From chaowan at redhat.com  Tue Jun  9 09:59:30 2015
From: chaowan at redhat.com (Chao Wang)
Date: Tue, 09 Jun 2015 21:59:30 +0800
Subject: [wildfly-dev] Wildfly start-up as service script depends on console
 log to determinate start result
Message-ID: <5576F142.3030307@redhat.com>

Hi all,

The Wildfly start-up as service scripts wildfly-init-redhat.sh and 
wildfly-init-debian.sh currently depend on a grep action of key message 
'WFLYSRV0025:' in console log to determinate whether service start is 
successful. The log message indication is accurate, however, it's not 
that robust since user can always remove console handler from logging 
subsystem. I have opened a WFCORE enhancement jira 
https://issues.jboss.org/browse/WFCORE-747 for it.

For the moment, I have tried three options, they're all not that perfect 
to implement

1. Stay with exact log message, users need to define their jboss log 
directory such as $JBOSS_HOME/standalone/log/server.log for standalone 
and $JBOSS_HOME/domain/log/host-controller.log for domain instead of 
searching in console log. This is more like another workaround since it 
is also volatile once we update log message in future release.(EAP has 
'JBAS015874:')

2. Use service pid, this is not precise because a long start-up can 
crash in the last second. It needs to wait a suitable seconds before 
checking pid existence. and still it can not avoid fake success in rare 
case just before timeout.

3. Use read-attribute server-state through CLI connection as I did in 
Pull Request on Jira. This is declined as it is possible that 
authentication is required before connection. In such case, any  non 
encrypted password is not advised in configuration files.

Therefore, I would like to listen for your opinions for them. Any other 
suggestion is certainly welcomed in mail or on jira.

Best regards,

Chao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150609/b5295b91/attachment.html 

From jperkins at redhat.com  Tue Jun  9 13:34:43 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Tue, 09 Jun 2015 10:34:43 -0700
Subject: [wildfly-dev] CLI Command Builder
Message-ID: <557723B3.1040106@redhat.com>

Hello All,
I've had a few issues file recently against the wildfly-maven-plugin 
about CLI commands that aren't available to the plugin. The issue is I'm 
using the CLI API to take commands and create DMR operations out of 
them. Since the commands can be defined in the subsystems I don't see 
those commands as I'm not operating in a modular environment.

This led me to create a new API in for the Launcher API [1]. All this 
does is build a command to launch a new CLI process. I'm sure if it 
would be useful to others or not. If not maybe it doesn't belong in the 
launcher API and I should just keep it in the maven plugin.

Any opinions are welcome. Let me know if you'd find this useful.

[1]: https://github.com/wildfly/wildfly-core/pull/764

-- 
James R. Perkins
JBoss by Red Hat


From brian.stansberry at redhat.com  Tue Jun  9 15:57:20 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 09 Jun 2015 14:57:20 -0500
Subject: [wildfly-dev] CLI Command Builder
In-Reply-To: <557723B3.1040106@redhat.com>
References: <557723B3.1040106@redhat.com>
Message-ID: <55774520.5020002@redhat.com>

The biggest thing is whether Alexey and Joe are comfortable to commiting 
to what you've done as a long term API.

On 6/9/15 12:34 PM, James R. Perkins wrote:
> Hello All,
> I've had a few issues file recently against the wildfly-maven-plugin
> about CLI commands that aren't available to the plugin. The issue is I'm
> using the CLI API to take commands and create DMR operations out of
> them. Since the commands can be defined in the subsystems I don't see
> those commands as I'm not operating in a modular environment.
>
> This led me to create a new API in for the Launcher API [1]. All this
> does is build a command to launch a new CLI process. I'm sure if it
> would be useful to others or not. If not maybe it doesn't belong in the
> launcher API and I should just keep it in the maven plugin.
>
> Any opinions are welcome. Let me know if you'd find this useful.
>
> [1]: https://github.com/wildfly/wildfly-core/pull/764
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From jperkins at redhat.com  Tue Jun  9 16:17:53 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Tue, 09 Jun 2015 13:17:53 -0700
Subject: [wildfly-dev] CLI Command Builder
In-Reply-To: <55774520.5020002@redhat.com>
References: <557723B3.1040106@redhat.com> <55774520.5020002@redhat.com>
Message-ID: <557749F1.9070909@redhat.com>

I don't mind maintaining it, but yeah their input would be helpful. 
Though if I'm the only one that would use it then maybe it just doesn't 
belong in WildFly at all :)

On 06/09/2015 12:57 PM, Brian Stansberry wrote:
> The biggest thing is whether Alexey and Joe are comfortable to commiting
> to what you've done as a long term API.
>
> On 6/9/15 12:34 PM, James R. Perkins wrote:
>> Hello All,
>> I've had a few issues file recently against the wildfly-maven-plugin
>> about CLI commands that aren't available to the plugin. The issue is I'm
>> using the CLI API to take commands and create DMR operations out of
>> them. Since the commands can be defined in the subsystems I don't see
>> those commands as I'm not operating in a modular environment.
>>
>> This led me to create a new API in for the Launcher API [1]. All this
>> does is build a command to launch a new CLI process. I'm sure if it
>> would be useful to others or not. If not maybe it doesn't belong in the
>> launcher API and I should just keep it in the maven plugin.
>>
>> Any opinions are welcome. Let me know if you'd find this useful.
>>
>> [1]: https://github.com/wildfly/wildfly-core/pull/764
>>
>

-- 
James R. Perkins
JBoss by Red Hat


From bgaisford at punagroup.com  Tue Jun  9 21:36:36 2015
From: bgaisford at punagroup.com (Brandon Gaisford)
Date: Tue, 9 Jun 2015 15:36:36 -1000
Subject: [wildfly-dev] Migration content needed for AS 7 --> WildFly 10
In-Reply-To: <5575C57F.60501@redhat.com>
References: <5575C57F.60501@redhat.com>
Message-ID: <8114CCD0-832D-4350-B19E-8ED10CBD3C61@punagroup.com>


Would this content also be applicable to AS 8.x to Wildfly 10?  Or was there a major shift from AS 7 to AS 8?  Excuse my ignorance, I?ve been stuck in EAP 4.x/5.x for years :)    

On Jun 8, 2015, at 6:40 AM, Sande Gilda <sgilda at redhat.com> wrote:

> I am responsible for documenting how to migrate an application from AS 7 to Wildfly 10 and have created the following page to document these changes:
> https://docs.jboss.org/author/display/WFLY10/How+do+I+migrate+my+application+from+AS7+to+WildFly
> If you worked on a component that has changed or been replaced, or have experience or knowledge about what needs to be updated when migrating an AS 7 application to Wildfly 10, please consider adding content to this page. Those of you who were around for AS 7 will recall I did this for migration from AS5/6 --> AS7 (see https://docs.jboss.org/author/display/AS72/How+do+I+migrate+my+application+from+AS5+or+AS6+to+AS7) and everyone was great about contributing to that content.
> 
> Thanks in advance and please contact me if you have any questions!
> 
> Thanks,
> Sande
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150609/b02bb8d0/attachment.html 

From manderse at redhat.com  Wed Jun 10 03:27:40 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 10 Jun 2015 09:27:40 +0200
Subject: [wildfly-dev] CLI Command Builder
In-Reply-To: <557723B3.1040106@redhat.com>
References: <557723B3.1040106@redhat.com>
Message-ID: <CAD9EA9A-5AAC-4B33-A801-89508FBB9473@redhat.com>

I think it has potential and is interesting.

The big problem I keep having with these are that unless I'm missing 
something
I can't use one version of this library to control multiple versions of 
WildFly/EAP
- I must still have the matching jar to the exact runtime version, 
correct ?

meaning using it from tools that need to support multiple versions 
without
wanting to ask the user to choose a specific jar this is of limited use 
outside
something like maven plugins :/

/max


> Hello All,
> I've had a few issues file recently against the wildfly-maven-plugin
> about CLI commands that aren't available to the plugin. The issue is 
> I'm
> using the CLI API to take commands and create DMR operations out of
> them. Since the commands can be defined in the subsystems I don't see
> those commands as I'm not operating in a modular environment.
>
> This led me to create a new API in for the Launcher API [1]. All this
> does is build a command to launch a new CLI process. I'm sure if it
> would be useful to others or not. If not maybe it doesn't belong in 
> the
> launcher API and I should just keep it in the maven plugin.
>
> Any opinions are welcome. Let me know if you'd find this useful.
>
> [1]: https://github.com/wildfly/wildfly-core/pull/764
>
> -- 
> James R. Perkins
> JBoss by Red Hat
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


/max
http://about.me/maxandersen

From ehugonne at redhat.com  Wed Jun 10 03:32:26 2015
From: ehugonne at redhat.com (Emmanuel Hugonnet)
Date: Wed, 10 Jun 2015 09:32:26 +0200
Subject: [wildfly-dev] CLI Command Builder
In-Reply-To: <CAD9EA9A-5AAC-4B33-A801-89508FBB9473@redhat.com>
References: <557723B3.1040106@redhat.com>
	<CAD9EA9A-5AAC-4B33-A801-89508FBB9473@redhat.com>
Message-ID: <5577E80A.4000409@redhat.com>

Won't you miss some command handlers that can be loaded through the subsystems themselves ?
Emmanuel

Le 10/06/2015 09:27, Max Rydahl Andersen a ?crit :
> I think it has potential and is interesting.
> 
> The big problem I keep having with these are that unless I'm missing 
> something
> I can't use one version of this library to control multiple versions of 
> WildFly/EAP
> - I must still have the matching jar to the exact runtime version, 
> correct ?
> 
> meaning using it from tools that need to support multiple versions 
> without
> wanting to ask the user to choose a specific jar this is of limited use 
> outside
> something like maven plugins :/
> 
> /max
> 
> 
>> Hello All,
>> I've had a few issues file recently against the wildfly-maven-plugin
>> about CLI commands that aren't available to the plugin. The issue is 
>> I'm
>> using the CLI API to take commands and create DMR operations out of
>> them. Since the commands can be defined in the subsystems I don't see
>> those commands as I'm not operating in a modular environment.
>>
>> This led me to create a new API in for the Launcher API [1]. All this
>> does is build a command to launch a new CLI process. I'm sure if it
>> would be useful to others or not. If not maybe it doesn't belong in 
>> the
>> launcher API and I should just keep it in the maven plugin.
>>
>> Any opinions are welcome. Let me know if you'd find this useful.
>>
>> [1]: https://github.com/wildfly/wildfly-core/pull/764
>>
>> -- 
>> James R. Perkins
>> JBoss by Red Hat
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> /max
> http://about.me/maxandersen
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150610/32d180e0/attachment.bin 

From emartins at redhat.com  Wed Jun 10 06:09:23 2015
From: emartins at redhat.com (Eduardo Martins)
Date: Wed, 10 Jun 2015 11:09:23 +0100
Subject: [wildfly-dev] Migration content needed for AS 7 --> WildFly 10
In-Reply-To: <8114CCD0-832D-4350-B19E-8ED10CBD3C61@punagroup.com>
References: <5575C57F.60501@redhat.com>
	<8114CCD0-832D-4350-B19E-8ED10CBD3C61@punagroup.com>
Message-ID: <49C49D71-A63E-470B-A0CA-4B726586A6A7@redhat.com>

There was a major shift from AS6 to AS7, which the document referenced by Sande handled quite well, since that we have just been doing small updates in specific areas, but this time we are doing another big revision of this type of content.

?E

> On 10 Jun 2015, at 02:36, Brandon Gaisford <bgaisford at punagroup.com> wrote:
> 
> 
> Would this content also be applicable to AS 8.x to Wildfly 10?  Or was there a major shift from AS 7 to AS 8?  Excuse my ignorance, I?ve been stuck in EAP 4.x/5.x for years :)    
> 
> On Jun 8, 2015, at 6:40 AM, Sande Gilda <sgilda at redhat.com <mailto:sgilda at redhat.com>> wrote:
> 
>> I am responsible for documenting how to migrate an application from AS 7 to Wildfly 10 and have created the following page to document these changes:
>> https://docs.jboss.org/author/display/WFLY10/How+do+I+migrate+my+application+from+AS7+to+WildFly <https://docs.jboss.org/author/display/WFLY10/How+do+I+migrate+my+application+from+AS7+to+WildFly>
>> If you worked on a component that has changed or been replaced, or have experience or knowledge about what needs to be updated when migrating an AS 7 application to Wildfly 10, please consider adding content to this page. Those of you who were around for AS 7 will recall I did this for migration from AS5/6 --> AS7 (see https://docs.jboss.org/author/display/AS72/How+do+I+migrate+my+application+from+AS5+or+AS6+to+AS7 <https://docs.jboss.org/author/display/AS72/How+do+I+migrate+my+application+from+AS5+or+AS6+to+AS7>) and everyone was great about contributing to that content.
>> 
>> Thanks in advance and please contact me if you have any questions!
>> 
>> Thanks,
>> Sande
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150610/b953c24e/attachment-0001.html 

From ewertz at redhat.com  Wed Jun 10 07:01:38 2015
From: ewertz at redhat.com (Edward Wertz)
Date: Wed, 10 Jun 2015 07:01:38 -0400 (EDT)
Subject: [wildfly-dev] CLI Command Builder
In-Reply-To: <557749F1.9070909@redhat.com>
References: <557723B3.1040106@redhat.com> <55774520.5020002@redhat.com>
	<557749F1.9070909@redhat.com>
Message-ID: <24342210.54.1433934092638.JavaMail.joe@localhost.localdomain>

I was actually about to create a much more basic process builder to restructure the CLI tests a bit.

In a general sense I think I'm comfortable maintaining an API like this. If it's not maintained here, something similar, but more basic, should already be getting maintained in the testsuite anyway. Otherwise we're missing test coverage. So I don't see much additional work involved. It's just a matter of remembering where to do it. Not whether it would be getting done.

Unless there's some other impact I'm not seeing?

-- Joe

----- Original Message -----
> From: "James R. Perkins" <jperkins at redhat.com>
> To: wildfly-dev at lists.jboss.org
> Sent: Wednesday, June 10, 2015 4:17:53 AM
> Subject: Re: [wildfly-dev] CLI Command Builder
> 
> I don't mind maintaining it, but yeah their input would be helpful.
> Though if I'm the only one that would use it then maybe it just
> doesn't
> belong in WildFly at all :)
> 
> On 06/09/2015 12:57 PM, Brian Stansberry wrote:
> > The biggest thing is whether Alexey and Joe are comfortable to
> > commiting
> > to what you've done as a long term API.
> >
> > On 6/9/15 12:34 PM, James R. Perkins wrote:
> >> Hello All,
> >> I've had a few issues file recently against the
> >> wildfly-maven-plugin
> >> about CLI commands that aren't available to the plugin. The issue
> >> is I'm
> >> using the CLI API to take commands and create DMR operations out
> >> of
> >> them. Since the commands can be defined in the subsystems I don't
> >> see
> >> those commands as I'm not operating in a modular environment.
> >>
> >> This led me to create a new API in for the Launcher API [1]. All
> >> this
> >> does is build a command to launch a new CLI process. I'm sure if
> >> it
> >> would be useful to others or not. If not maybe it doesn't belong
> >> in the
> >> launcher API and I should just keep it in the maven plugin.
> >>
> >> Any opinions are welcome. Let me know if you'd find this useful.
> >>
> >> [1]: https://github.com/wildfly/wildfly-core/pull/764
> >>
> >
> 
> --
> James R. Perkins
> JBoss by Red Hat
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

From lkubik at redhat.com  Wed Jun 10 07:41:00 2015
From: lkubik at redhat.com (Lukas Kubik)
Date: Wed, 10 Jun 2015 07:41:00 -0400 (EDT)
Subject: [wildfly-dev] Github repo line endings unification advice
In-Reply-To: <1504536192.18199066.1433936280621.JavaMail.zimbra@redhat.com>
Message-ID: <1654554071.18203183.1433936460558.JavaMail.zimbra@redhat.com>

Hi,

I'm sorry that this is a little bit off-topic question but I already asked in the forum and nobody answered me. How do you guys deal with the line endings unification in your github repo? I saw that you don't have for example .jsp files in the .gitattributes file however all .jsp files in the WF repo uses LF ending. How do you check that windows CRLF won't get merged with some PR?

We are currently discussing the unification of the line endings in the Keycloak repo so I would like to kindly ask you for any advice.


Thank you for the answer.
Regards,

Lukas

From eduardo.santanadasilva at gmail.com  Wed Jun 10 07:52:50 2015
From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=)
Date: Wed, 10 Jun 2015 08:52:50 -0300
Subject: [wildfly-dev] Github repo line endings unification advice
In-Reply-To: <1654554071.18203183.1433936460558.JavaMail.zimbra@redhat.com>
References: <1504536192.18199066.1433936280621.JavaMail.zimbra@redhat.com>
	<1654554071.18203183.1433936460558.JavaMail.zimbra@redhat.com>
Message-ID: <CAFVp3Z6uGtjmD+YKfdabdAm4xx-m3p+aOdSxE0hjdY6jAtO1Bw@mail.gmail.com>

I believe that this is done by checkstyle.
I found this on the checkstyle project:

https://github.com/checkstyle/checkstyle/issues/893

<module name="RegexpMultiline">
    <property name="format" value="\r\n"/>
    <property name="message" value="Do not use Windows line endings"/>
</module>


2015-06-10 8:41 GMT-03:00 Lukas Kubik <lkubik at redhat.com>:

> Hi,
>
> I'm sorry that this is a little bit off-topic question but I already asked
> in the forum and nobody answered me. How do you guys deal with the line
> endings unification in your github repo? I saw that you don't have for
> example .jsp files in the .gitattributes file however all .jsp files in the
> WF repo uses LF ending. How do you check that windows CRLF won't get merged
> with some PR?
>
> We are currently discussing the unification of the line endings in the
> Keycloak repo so I would like to kindly ask you for any advice.
>
>
> Thank you for the answer.
> Regards,
>
> Lukas
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
__________________________
Eduardo Sant'Ana da Silva - Dr.
Pesquisador / Consultor de TI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150610/ba5ba212/attachment.html 

From jason.greene at redhat.com  Wed Jun 10 08:04:53 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Wed, 10 Jun 2015 08:04:53 -0400 (EDT)
Subject: [wildfly-dev] Github repo line endings unification advice
In-Reply-To: <1654554071.18203183.1433936460558.JavaMail.zimbra@redhat.com>
References: <1654554071.18203183.1433936460558.JavaMail.zimbra@redhat.com>
Message-ID: <E4DD0BC4-A440-4504-9BCC-BB6E5039F0BC@redhat.com>

It's a mistake that the jsp files aren't in gitatttibutes. The reason that it hasn't gotten CRLF is probably a bit of luck, and a bit of the fact that most code editors try to preserve them on their own even on windows.

> On Jun 10, 2015, at 6:41 AM, Lukas Kubik <lkubik at redhat.com> wrote:
> 
> Hi,
> 
> I'm sorry that this is a little bit off-topic question but I already asked in the forum and nobody answered me. How do you guys deal with the line endings unification in your github repo? I saw that you don't have for example .jsp files in the .gitattributes file however all .jsp files in the WF repo uses LF ending. How do you check that windows CRLF won't get merged with some PR?
> 
> We are currently discussing the unification of the line endings in the Keycloak repo so I would like to kindly ask you for any advice.
> 
> 
> Thank you for the answer.
> Regards,
> 
> Lukas
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From alexey.loubyansky at redhat.com  Wed Jun 10 08:07:21 2015
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Wed, 10 Jun 2015 14:07:21 +0200
Subject: [wildfly-dev] CLI Command Builder
In-Reply-To: <24342210.54.1433934092638.JavaMail.joe@localhost.localdomain>
References: <557723B3.1040106@redhat.com>
	<55774520.5020002@redhat.com>	<557749F1.9070909@redhat.com>
	<24342210.54.1433934092638.JavaMail.joe@localhost.localdomain>
Message-ID: <55782879.4050609@redhat.com>

I agree with Joe. Thanks James for looking into this.

Alexey

On 06/10/2015 01:01 PM, Edward Wertz wrote:
> I was actually about to create a much more basic process builder to restructure the CLI tests a bit.
>
> In a general sense I think I'm comfortable maintaining an API like this. If it's not maintained here, something similar, but more basic, should already be getting maintained in the testsuite anyway. Otherwise we're missing test coverage. So I don't see much additional work involved. It's just a matter of remembering where to do it. Not whether it would be getting done.
>
> Unless there's some other impact I'm not seeing?
>
> -- Joe
>
> ----- Original Message -----
>> From: "James R. Perkins" <jperkins at redhat.com>
>> To: wildfly-dev at lists.jboss.org
>> Sent: Wednesday, June 10, 2015 4:17:53 AM
>> Subject: Re: [wildfly-dev] CLI Command Builder
>>
>> I don't mind maintaining it, but yeah their input would be helpful.
>> Though if I'm the only one that would use it then maybe it just
>> doesn't
>> belong in WildFly at all :)
>>
>> On 06/09/2015 12:57 PM, Brian Stansberry wrote:
>>> The biggest thing is whether Alexey and Joe are comfortable to
>>> commiting
>>> to what you've done as a long term API.
>>>
>>> On 6/9/15 12:34 PM, James R. Perkins wrote:
>>>> Hello All,
>>>> I've had a few issues file recently against the
>>>> wildfly-maven-plugin
>>>> about CLI commands that aren't available to the plugin. The issue
>>>> is I'm
>>>> using the CLI API to take commands and create DMR operations out
>>>> of
>>>> them. Since the commands can be defined in the subsystems I don't
>>>> see
>>>> those commands as I'm not operating in a modular environment.
>>>>
>>>> This led me to create a new API in for the Launcher API [1]. All
>>>> this
>>>> does is build a command to launch a new CLI process. I'm sure if
>>>> it
>>>> would be useful to others or not. If not maybe it doesn't belong
>>>> in the
>>>> launcher API and I should just keep it in the maven plugin.
>>>>
>>>> Any opinions are welcome. Let me know if you'd find this useful.
>>>>
>>>> [1]: https://github.com/wildfly/wildfly-core/pull/764
>>>>
>>>
>>
>> --
>> James R. Perkins
>> JBoss by Red Hat
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From jperkins at redhat.com  Wed Jun 10 11:37:52 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Wed, 10 Jun 2015 08:37:52 -0700
Subject: [wildfly-dev] CLI Command Builder
In-Reply-To: <CAD9EA9A-5AAC-4B33-A801-89508FBB9473@redhat.com>
References: <557723B3.1040106@redhat.com>
	<CAD9EA9A-5AAC-4B33-A801-89508FBB9473@redhat.com>
Message-ID: <557859D0.2070601@redhat.com>

I don't see why it wouldn't work with all versions. All it really does 
is create command strings to be passed to a ProcessBuilder. Since it's 
new in WildFly it will default to WildFly settings, but you should be 
able to override them. In most cases, maybe all, no parameters entry 
parameters have changed.

If the tooling can have a hard dependency on something like 
org.wildfly.core:wildfly-launcher I don't see why it wouldn't work with 
any version. Let me know if I'm missing something though.

Last time I tested the wildfly-maven-plugin will work with EAP, it's 
just not it's target so the defaults don't match for connecting the 
controller. The only thing you'd have to do is override the port to 9999.

On 06/10/2015 12:27 AM, Max Rydahl Andersen wrote:
> I think it has potential and is interesting.
>
> The big problem I keep having with these are that unless I'm missing 
> something
> I can't use one version of this library to control multiple versions 
> of WildFly/EAP
> - I must still have the matching jar to the exact runtime version, 
> correct ?
>
> meaning using it from tools that need to support multiple versions 
> without
> wanting to ask the user to choose a specific jar this is of limited 
> use outside
> something like maven plugins :/
>
> /max
>
>
>> Hello All,
>> I've had a few issues file recently against the wildfly-maven-plugin
>> about CLI commands that aren't available to the plugin. The issue is I'm
>> using the CLI API to take commands and create DMR operations out of
>> them. Since the commands can be defined in the subsystems I don't see
>> those commands as I'm not operating in a modular environment.
>>
>> This led me to create a new API in for the Launcher API [1]. All this
>> does is build a command to launch a new CLI process. I'm sure if it
>> would be useful to others or not. If not maybe it doesn't belong in the
>> launcher API and I should just keep it in the maven plugin.
>>
>> Any opinions are welcome. Let me know if you'd find this useful.
>>
>> [1]: https://github.com/wildfly/wildfly-core/pull/764
>>
>> -- 
>> James R. Perkins
>> JBoss by Red Hat
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> /max
> http://about.me/maxandersen

-- 
James R. Perkins
JBoss by Red Hat


From jperkins at redhat.com  Wed Jun 10 11:40:38 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Wed, 10 Jun 2015 08:40:38 -0700
Subject: [wildfly-dev] CLI Command Builder
In-Reply-To: <5577E80A.4000409@redhat.com>
References: <557723B3.1040106@redhat.com>
	<CAD9EA9A-5AAC-4B33-A801-89508FBB9473@redhat.com>
	<5577E80A.4000409@redhat.com>
Message-ID: <55785A76.6000807@redhat.com>

That's the reason I created this was so the wildfly-maven-plugin could 
use jboss-modules to launch CLI and execute commands which means it 
should discover them. At least that's how I thought it worked.

On 06/10/2015 12:32 AM, Emmanuel Hugonnet wrote:
> Won't you miss some command handlers that can be loaded through the subsystems themselves ?
> Emmanuel
>
> Le 10/06/2015 09:27, Max Rydahl Andersen a ?crit :
>> I think it has potential and is interesting.
>>
>> The big problem I keep having with these are that unless I'm missing
>> something
>> I can't use one version of this library to control multiple versions of
>> WildFly/EAP
>> - I must still have the matching jar to the exact runtime version,
>> correct ?
>>
>> meaning using it from tools that need to support multiple versions
>> without
>> wanting to ask the user to choose a specific jar this is of limited use
>> outside
>> something like maven plugins :/
>>
>> /max
>>
>>
>>> Hello All,
>>> I've had a few issues file recently against the wildfly-maven-plugin
>>> about CLI commands that aren't available to the plugin. The issue is
>>> I'm
>>> using the CLI API to take commands and create DMR operations out of
>>> them. Since the commands can be defined in the subsystems I don't see
>>> those commands as I'm not operating in a modular environment.
>>>
>>> This led me to create a new API in for the Launcher API [1]. All this
>>> does is build a command to launch a new CLI process. I'm sure if it
>>> would be useful to others or not. If not maybe it doesn't belong in
>>> the
>>> launcher API and I should just keep it in the maven plugin.
>>>
>>> Any opinions are welcome. Let me know if you'd find this useful.
>>>
>>> [1]: https://github.com/wildfly/wildfly-core/pull/764
>>>
>>> -- 
>>> James R. Perkins
>>> JBoss by Red Hat
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> /max
>> http://about.me/maxandersen
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>

-- 
James R. Perkins
JBoss by Red Hat


From brian.stansberry at redhat.com  Wed Jun 10 11:44:32 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 10 Jun 2015 10:44:32 -0500
Subject: [wildfly-dev] Launching multiple versions from the launcher jar
In-Reply-To: <CAD9EA9A-5AAC-4B33-A801-89508FBB9473@redhat.com>
References: <557723B3.1040106@redhat.com>
	<CAD9EA9A-5AAC-4B33-A801-89508FBB9473@redhat.com>
Message-ID: <55785B60.20408@redhat.com>

I changed the title as this is a different topic.

It's a good point, Max. It seems like it should be possible to have some 
sort of factory API to specify the version of the process being launched.

Apologies in advance, James, if that's already there.

There are funny details to consider, e.g. how to specify the version, 
since now it's really WildFly Core versions that are relevant, while 
previous releases are AS or EAP or WildFly full.

My guess is what's there now will work for any release we've had since 
AS 7.0. We haven't been changing our launch commands. Of course there 
may be some new args introduced over time that won't work on old 
releases, but that's to be expected.

On 6/10/15 2:27 AM, Max Rydahl Andersen wrote:
> I think it has potential and is interesting.
>
> The big problem I keep having with these are that unless I'm missing
> something
> I can't use one version of this library to control multiple versions of
> WildFly/EAP
> - I must still have the matching jar to the exact runtime version,
> correct ?
>
> meaning using it from tools that need to support multiple versions
> without
> wanting to ask the user to choose a specific jar this is of limited use
> outside
> something like maven plugins :/
>
> /max
>
>
>> Hello All,
>> I've had a few issues file recently against the wildfly-maven-plugin
>> about CLI commands that aren't available to the plugin. The issue is
>> I'm
>> using the CLI API to take commands and create DMR operations out of
>> them. Since the commands can be defined in the subsystems I don't see
>> those commands as I'm not operating in a modular environment.
>>
>> This led me to create a new API in for the Launcher API [1]. All this
>> does is build a command to launch a new CLI process. I'm sure if it
>> would be useful to others or not. If not maybe it doesn't belong in
>> the
>> launcher API and I should just keep it in the maven plugin.
>>
>> Any opinions are welcome. Let me know if you'd find this useful.
>>
>> [1]: https://github.com/wildfly/wildfly-core/pull/764
>>
>> --
>> James R. Perkins
>> JBoss by Red Hat
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> /max
> http://about.me/maxandersen
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From brian.stansberry at redhat.com  Wed Jun 10 12:44:51 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 10 Jun 2015 11:44:51 -0500
Subject: [wildfly-dev] Wildfly start-up as service script depends on
 console log to determinate start result
In-Reply-To: <5576F142.3030307@redhat.com>
References: <5576F142.3030307@redhat.com>
Message-ID: <55786983.2010500@redhat.com>

A couple thoughts:

1) Looking at wildfly-init-redhat.sh at least, I don't see how that 
check is actually testing for successful startup. It looks like it's 
just trying to delay start() returning for a while, max 30 secs.

So, what purpose is this fulfilling?

2) How does other software solve this problem? If it's solving a valid 
problem, it seems like there would be a typical solution.

On 6/9/15 8:59 AM, Chao Wang wrote:
> Hi all,
>
> The Wildfly start-up as service scripts wildfly-init-redhat.sh and
> wildfly-init-debian.sh currently depend on a grep action of key message
> 'WFLYSRV0025:' in console log to determinate whether service start is
> successful. The log message indication is accurate, however, it's not
> that robust since user can always remove console handler from logging
> subsystem. I have opened a WFCORE enhancement jira
> https://issues.jboss.org/browse/WFCORE-747 for it.
>
> For the moment, I have tried three options, they're all not that perfect
> to implement
>
> 1. Stay with exact log message, users need to define their jboss log
> directory such as $JBOSS_HOME/standalone/log/server.log for standalone
> and $JBOSS_HOME/domain/log/host-controller.log for domain instead of
> searching in console log. This is more like another workaround since it
> is also volatile once we update log message in future release.(EAP has
> 'JBAS015874:')
>
> 2. Use service pid, this is not precise because a long start-up can
> crash in the last second. It needs to wait a suitable seconds before
> checking pid existence. and still it can not avoid fake success in rare
> case just before timeout.
>
> 3. Use read-attribute server-state through CLI connection as I did in
> Pull Request on Jira. This is declined as it is possible that
> authentication is required before connection. In such case, any  non
> encrypted password is not advised in configuration files.
>
> Therefore, I would like to listen for your opinions for them. Any other
> suggestion is certainly welcomed in mail or on jira.
>
> Best regards,
>
> Chao
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From mazz at redhat.com  Thu Jun 11 15:20:31 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 11 Jun 2015 15:20:31 -0400 (EDT)
Subject: [wildfly-dev] failures in composite operations
In-Reply-To: <1156724315.735488.1434049236489.JavaMail.zimbra@redhat.com>
Message-ID: <1212216999.743854.1434050431713.JavaMail.zimbra@redhat.com>

Here's the use case: a monitoring app wants to monitor a WildFly instance - it will ask WildFly for the values of N attributes across M resources in one bulk composite request. This would avoid having to send one request for each individual attribute being collected (rather than one request for all of them at once).

Is there a way I can configure a composite request such that WildFly will not abort the entire composite request if a single step to read an attribute fails?

For example, suppose I send this - I'm basically asking Wildfly "tell me the status of my two deployed applications a.war and b.war" :

{
    "operation" => "composite",
    "address" => [],
    "steps" => [
        {
            "operation" => "read-attribute",
            "address" => [("deployment" => "a.war")],
            "include-runtime" => false,
            "name" => "status"
        },
        {
            "operation" => "read-attribute",
            "address" => [("deployment" => "b.war")],
            "include-runtime" => false,
            "name" => "status"
        }
    ]
}

Well, if someone undeployed a.war, that first step results in an error, but it also completely aborts the composite operation so I can't find the status of b.war either, unless a.war exists.

I would like composites like this to tell me the status of every read-attribute - whether a failure or not. If not possible, I'm forced to split this up and make two individual requests for each attribute.

Extrapolate that out - if I have N attributes I want to collect at the same time, I would be forced to make N individual requests rather than 1 composite request just to avoid the case where if one of them failed, I would lose the data for all N.

From mazz at redhat.com  Thu Jun 11 15:30:57 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 11 Jun 2015 15:30:57 -0400 (EDT)
Subject: [wildfly-dev] failures in composite operations
In-Reply-To: <1212216999.743854.1434050431713.JavaMail.zimbra@redhat.com>
References: <1212216999.743854.1434050431713.JavaMail.zimbra@redhat.com>
Message-ID: <1630274831.745660.1434051057596.JavaMail.zimbra@redhat.com>

FWIW: this is what the response would look like in my example if a.war was undeployed:

{
    "outcome" => "failed",
    "result" => {
        "step-1" => {
            "outcome" => "failed",
            "failure-description" => "JBAS014807: Management resource '[(\"deployment\" => \"a.war\")]' not found",
            "rolled-back" => true
        },
        "step-2" => {"outcome" => undefined}
    },
    "failure-description" => {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "JBAS014807: Management resource '[(\"deployment\" => \"a.war\")]' not found"}},
    "rolled-back" => true
}

----- Original Message -----
> Here's the use case: a monitoring app wants to monitor a WildFly instance -
> it will ask WildFly for the values of N attributes across M resources in one
> bulk composite request. This would avoid having to send one request for each
> individual attribute being collected (rather than one request for all of
> them at once).
> 
> Is there a way I can configure a composite request such that WildFly will not
> abort the entire composite request if a single step to read an attribute
> fails?
> 
> For example, suppose I send this - I'm basically asking Wildfly "tell me the
> status of my two deployed applications a.war and b.war" :
> 
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "operation" => "read-attribute",
>             "address" => [("deployment" => "a.war")],
>             "include-runtime" => false,
>             "name" => "status"
>         },
>         {
>             "operation" => "read-attribute",
>             "address" => [("deployment" => "b.war")],
>             "include-runtime" => false,
>             "name" => "status"
>         }
>     ]
> }
> 
> Well, if someone undeployed a.war, that first step results in an error, but
> it also completely aborts the composite operation so I can't find the status
> of b.war either, unless a.war exists.
> 
> I would like composites like this to tell me the status of every
> read-attribute - whether a failure or not. If not possible, I'm forced to
> split this up and make two individual requests for each attribute.
> 
> Extrapolate that out - if I have N attributes I want to collect at the same
> time, I would be forced to make N individual requests rather than 1
> composite request just to avoid the case where if one of them failed, I
> would lose the data for all N.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

From brian.stansberry at redhat.com  Thu Jun 11 16:11:12 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 11 Jun 2015 15:11:12 -0500
Subject: [wildfly-dev] failures in composite operations
In-Reply-To: <1630274831.745660.1434051057596.JavaMail.zimbra@redhat.com>
References: <1212216999.743854.1434050431713.JavaMail.zimbra@redhat.com>
	<1630274831.745660.1434051057596.JavaMail.zimbra@redhat.com>
Message-ID: <5579EB60.5050909@redhat.com>

Try this:

/deployment=*:read-attribute(name=status,include-runtime=true)

The composite op won't allow you to tell it ignore failures in reading 
the configuration model.

On 6/11/15 2:30 PM, John Mazzitelli wrote:
> FWIW: this is what the response would look like in my example if a.war was undeployed:
>
> {
>      "outcome" => "failed",
>      "result" => {
>          "step-1" => {
>              "outcome" => "failed",
>              "failure-description" => "JBAS014807: Management resource '[(\"deployment\" => \"a.war\")]' not found",
>              "rolled-back" => true
>          },
>          "step-2" => {"outcome" => undefined}
>      },
>      "failure-description" => {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "JBAS014807: Management resource '[(\"deployment\" => \"a.war\")]' not found"}},
>      "rolled-back" => true
> }
>
> ----- Original Message -----
>> Here's the use case: a monitoring app wants to monitor a WildFly instance -
>> it will ask WildFly for the values of N attributes across M resources in one
>> bulk composite request. This would avoid having to send one request for each
>> individual attribute being collected (rather than one request for all of
>> them at once).
>>
>> Is there a way I can configure a composite request such that WildFly will not
>> abort the entire composite request if a single step to read an attribute
>> fails?
>>
>> For example, suppose I send this - I'm basically asking Wildfly "tell me the
>> status of my two deployed applications a.war and b.war" :
>>
>> {
>>      "operation" => "composite",
>>      "address" => [],
>>      "steps" => [
>>          {
>>              "operation" => "read-attribute",
>>              "address" => [("deployment" => "a.war")],
>>              "include-runtime" => false,
>>              "name" => "status"
>>          },
>>          {
>>              "operation" => "read-attribute",
>>              "address" => [("deployment" => "b.war")],
>>              "include-runtime" => false,
>>              "name" => "status"
>>          }
>>      ]
>> }
>>
>> Well, if someone undeployed a.war, that first step results in an error, but
>> it also completely aborts the composite operation so I can't find the status
>> of b.war either, unless a.war exists.
>>
>> I would like composites like this to tell me the status of every
>> read-attribute - whether a failure or not. If not possible, I'm forced to
>> split this up and make two individual requests for each attribute.
>>
>> Extrapolate that out - if I have N attributes I want to collect at the same
>> time, I would be forced to make N individual requests rather than 1
>> composite request just to avoid the case where if one of them failed, I
>> would lose the data for all N.
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From mazz at redhat.com  Thu Jun 11 16:50:57 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 11 Jun 2015 16:50:57 -0400 (EDT)
Subject: [wildfly-dev] failures in composite operations
In-Reply-To: <5579EB60.5050909@redhat.com>
References: <1212216999.743854.1434050431713.JavaMail.zimbra@redhat.com>
	<1630274831.745660.1434051057596.JavaMail.zimbra@redhat.com>
	<5579EB60.5050909@redhat.com>
Message-ID: <1733656950.772396.1434055857800.JavaMail.zimbra@redhat.com>

> /deployment=*:read-attribute(name=status,include-runtime=true)

Problem there is that would assume I am asking for the same attribute on the same type of resource.

I'm monitoring pretty much everything (ok, not EVERYTHING), but the point is I might be collecting one attribute for the transaction manager, one on a datasource, and one on a deployment - different attributes across different types - but I'm collecting them all at the same time.  So I would like to do a bulk collection and just issue one request - but it sounds like I need to split it up and shotgun N requests each asking for a singular attribute value.

----- Original Message -----
> Try this:
> 
> /deployment=*:read-attribute(name=status,include-runtime=true)
> 
> The composite op won't allow you to tell it ignore failures in reading
> the configuration model.
> 
> On 6/11/15 2:30 PM, John Mazzitelli wrote:
> > FWIW: this is what the response would look like in my example if a.war was
> > undeployed:
> >
> > {
> >      "outcome" => "failed",
> >      "result" => {
> >          "step-1" => {
> >              "outcome" => "failed",
> >              "failure-description" => "JBAS014807: Management resource
> >              '[(\"deployment\" => \"a.war\")]' not found",
> >              "rolled-back" => true
> >          },
> >          "step-2" => {"outcome" => undefined}
> >      },
> >      "failure-description" => {"JBAS014653: Composite operation failed and
> >      was rolled back. Steps that failed:" => {"Operation step-1" =>
> >      "JBAS014807: Management resource '[(\"deployment\" => \"a.war\")]'
> >      not found"}},
> >      "rolled-back" => true
> > }
> >
> > ----- Original Message -----
> >> Here's the use case: a monitoring app wants to monitor a WildFly instance
> >> -
> >> it will ask WildFly for the values of N attributes across M resources in
> >> one
> >> bulk composite request. This would avoid having to send one request for
> >> each
> >> individual attribute being collected (rather than one request for all of
> >> them at once).
> >>
> >> Is there a way I can configure a composite request such that WildFly will
> >> not
> >> abort the entire composite request if a single step to read an attribute
> >> fails?
> >>
> >> For example, suppose I send this - I'm basically asking Wildfly "tell me
> >> the
> >> status of my two deployed applications a.war and b.war" :
> >>
> >> {
> >>      "operation" => "composite",
> >>      "address" => [],
> >>      "steps" => [
> >>          {
> >>              "operation" => "read-attribute",
> >>              "address" => [("deployment" => "a.war")],
> >>              "include-runtime" => false,
> >>              "name" => "status"
> >>          },
> >>          {
> >>              "operation" => "read-attribute",
> >>              "address" => [("deployment" => "b.war")],
> >>              "include-runtime" => false,
> >>              "name" => "status"
> >>          }
> >>      ]
> >> }
> >>
> >> Well, if someone undeployed a.war, that first step results in an error,
> >> but
> >> it also completely aborts the composite operation so I can't find the
> >> status
> >> of b.war either, unless a.war exists.
> >>
> >> I would like composites like this to tell me the status of every
> >> read-attribute - whether a failure or not. If not possible, I'm forced to
> >> split this up and make two individual requests for each attribute.
> >>
> >> Extrapolate that out - if I have N attributes I want to collect at the
> >> same
> >> time, I would be forced to make N individual requests rather than 1
> >> composite request just to avoid the case where if one of them failed, I
> >> would lose the data for all N.
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> 
> 
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

From brian.stansberry at redhat.com  Thu Jun 11 17:06:32 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 11 Jun 2015 16:06:32 -0500
Subject: [wildfly-dev] failures in composite operations
In-Reply-To: <1733656950.772396.1434055857800.JavaMail.zimbra@redhat.com>
References: <1212216999.743854.1434050431713.JavaMail.zimbra@redhat.com>
	<1630274831.745660.1434051057596.JavaMail.zimbra@redhat.com>
	<5579EB60.5050909@redhat.com>
	<1733656950.772396.1434055857800.JavaMail.zimbra@redhat.com>
Message-ID: <5579F858.40601@redhat.com>

You can include different wildcard reads as steps in a composite, if 
that helps. The question is whether for each type of read, do you only 
want specific resources (deployment=a.war,deployment=b.war), or do you 
want all of that type?

Otherwise, yes, it would require a new feature to support ignoring 
failures related to reading the configuration model.

Semi-OT: see https://issues.jboss.org/browse/WFCORE-287 for some new 
querying functionality available in WF 10.

On 6/11/15 3:50 PM, John Mazzitelli wrote:
>> /deployment=*:read-attribute(name=status,include-runtime=true)
>
> Problem there is that would assume I am asking for the same attribute on the same type of resource.
>
> I'm monitoring pretty much everything (ok, not EVERYTHING), but the point is I might be collecting one attribute for the transaction manager, one on a datasource, and one on a deployment - different attributes across different types - but I'm collecting them all at the same time.  So I would like to do a bulk collection and just issue one request - but it sounds like I need to split it up and shotgun N requests each asking for a singular attribute value.
>
> ----- Original Message -----
>> Try this:
>>
>> /deployment=*:read-attribute(name=status,include-runtime=true)
>>
>> The composite op won't allow you to tell it ignore failures in reading
>> the configuration model.
>>
>> On 6/11/15 2:30 PM, John Mazzitelli wrote:
>>> FWIW: this is what the response would look like in my example if a.war was
>>> undeployed:
>>>
>>> {
>>>       "outcome" => "failed",
>>>       "result" => {
>>>           "step-1" => {
>>>               "outcome" => "failed",
>>>               "failure-description" => "JBAS014807: Management resource
>>>               '[(\"deployment\" => \"a.war\")]' not found",
>>>               "rolled-back" => true
>>>           },
>>>           "step-2" => {"outcome" => undefined}
>>>       },
>>>       "failure-description" => {"JBAS014653: Composite operation failed and
>>>       was rolled back. Steps that failed:" => {"Operation step-1" =>
>>>       "JBAS014807: Management resource '[(\"deployment\" => \"a.war\")]'
>>>       not found"}},
>>>       "rolled-back" => true
>>> }
>>>
>>> ----- Original Message -----
>>>> Here's the use case: a monitoring app wants to monitor a WildFly instance
>>>> -
>>>> it will ask WildFly for the values of N attributes across M resources in
>>>> one
>>>> bulk composite request. This would avoid having to send one request for
>>>> each
>>>> individual attribute being collected (rather than one request for all of
>>>> them at once).
>>>>
>>>> Is there a way I can configure a composite request such that WildFly will
>>>> not
>>>> abort the entire composite request if a single step to read an attribute
>>>> fails?
>>>>
>>>> For example, suppose I send this - I'm basically asking Wildfly "tell me
>>>> the
>>>> status of my two deployed applications a.war and b.war" :
>>>>
>>>> {
>>>>       "operation" => "composite",
>>>>       "address" => [],
>>>>       "steps" => [
>>>>           {
>>>>               "operation" => "read-attribute",
>>>>               "address" => [("deployment" => "a.war")],
>>>>               "include-runtime" => false,
>>>>               "name" => "status"
>>>>           },
>>>>           {
>>>>               "operation" => "read-attribute",
>>>>               "address" => [("deployment" => "b.war")],
>>>>               "include-runtime" => false,
>>>>               "name" => "status"
>>>>           }
>>>>       ]
>>>> }
>>>>
>>>> Well, if someone undeployed a.war, that first step results in an error,
>>>> but
>>>> it also completely aborts the composite operation so I can't find the
>>>> status
>>>> of b.war either, unless a.war exists.
>>>>
>>>> I would like composites like this to tell me the status of every
>>>> read-attribute - whether a failure or not. If not possible, I'm forced to
>>>> split this up and make two individual requests for each attribute.
>>>>
>>>> Extrapolate that out - if I have N attributes I want to collect at the
>>>> same
>>>> time, I would be forced to make N individual requests rather than 1
>>>> composite request just to avoid the case where if one of them failed, I
>>>> would lose the data for all N.
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From jason.greene at redhat.com  Thu Jun 11 18:25:59 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 11 Jun 2015 17:25:59 -0500
Subject: [wildfly-dev] 9.0.0.CR2 Released!
Message-ID: <A7132606-CCA6-441B-99A1-F62788E6F091@redhat.com>

See:

http://wildfly.org/news/2015/06/10/WildFly9-CR2-Released/

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


From chaowan at redhat.com  Thu Jun 11 19:29:50 2015
From: chaowan at redhat.com (Chao Wang)
Date: Fri, 12 Jun 2015 07:29:50 +0800
Subject: [wildfly-dev] Wildfly start-up as service script depends on
 console log to determinate start result
In-Reply-To: <55786983.2010500@redhat.com>
References: <5576F142.3030307@redhat.com> <55786983.2010500@redhat.com>
Message-ID: <557A19EE.7030206@redhat.com>

Thanks for your reply. Please see in-line below

On 06/11/2015 12:44 AM, Brian Stansberry wrote:
> A couple thoughts:
>
> 1) Looking at wildfly-init-redhat.sh at least, I don't see how that
> check is actually testing for successful startup. It looks like it's
> just trying to delay start() returning for a while, max 30 secs.
>
> So, what purpose is this fulfilling?
My bad about issue background. It's actually an case in EAP 6 (not yet 
in wildfly). EAP 6.x script has launched state like: 
https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110 
(not in wildfly's script). Also, console log handler has been removed 
only in EAP full-ha mode long time ago due to performance 
concern.(wildfly keeps it for the moment). This leads to issue in 
bz1224170 <https://bugzilla.redhat.com/show_bug.cgi?id=1224170>.
That's why I try to seek an better option than current behavior from 
wildfly.
>
> 2) How does other software solve this problem? If it's solving a valid
> problem, it seems like there would be a typical solution.
I have checked some other application servers, most of them let users 
themselves to write a script to run as service for their OS. Geronimo 
does provide a script, Although I did damage to its configuration file 
to make a fatal error, terminal output still displays "Server started". 
In fact, process does not event exist and detail error can be seen in 
log file.
> On 6/9/15 8:59 AM, Chao Wang wrote:
>> Hi all,
>>
>> The Wildfly start-up as service scripts wildfly-init-redhat.sh and
>> wildfly-init-debian.sh currently depend on a grep action of key message
>> 'WFLYSRV0025:' in console log to determinate whether service start is
>> successful. The log message indication is accurate, however, it's not
>> that robust since user can always remove console handler from logging
>> subsystem. I have opened a WFCORE enhancement jira
>> https://issues.jboss.org/browse/WFCORE-747 for it.
>>
>> For the moment, I have tried three options, they're all not that perfect
>> to implement
>>
>> 1. Stay with exact log message, users need to define their jboss log
>> directory such as $JBOSS_HOME/standalone/log/server.log for standalone
>> and $JBOSS_HOME/domain/log/host-controller.log for domain instead of
>> searching in console log. This is more like another workaround since it
>> is also volatile once we update log message in future release.(EAP has
>> 'JBAS015874:')
>>
>> 2. Use service pid, this is not precise because a long start-up can
>> crash in the last second. It needs to wait a suitable seconds before
>> checking pid existence. and still it can not avoid fake success in rare
>> case just before timeout.
>>
>> 3. Use read-attribute server-state through CLI connection as I did in
>> Pull Request on Jira. This is declined as it is possible that
>> authentication is required before connection. In such case, any  non
>> encrypted password is not advised in configuration files.
>>
>> Therefore, I would like to listen for your opinions for them. Any other
>> suggestion is certainly welcomed in mail or on jira.
>>
>> Best regards,
>>
>> Chao
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1224170

-- 
Chao Wang
Software Engineer
JBoss by Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150612/c4e8e956/attachment.html 

From jai.forums2013 at gmail.com  Thu Jun 11 23:27:11 2015
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 12 Jun 2015 08:57:11 +0530
Subject: [wildfly-dev] 9.0.0.CR2 Released!
In-Reply-To: <A7132606-CCA6-441B-99A1-F62788E6F091@redhat.com>
References: <A7132606-CCA6-441B-99A1-F62788E6F091@redhat.com>
Message-ID: <557A518F.4020205@gmail.com>

Congratulations!

-Jaikiran

On Friday 12 June 2015 03:55 AM, Jason Greene wrote:
> See:
>
> http://wildfly.org/news/2015/06/10/WildFly9-CR2-Released/
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From jorsol at gmail.com  Fri Jun 12 01:25:07 2015
From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=)
Date: Thu, 11 Jun 2015 23:25:07 -0600
Subject: [wildfly-dev] Wildfly start-up as service script depends on
 console log to determinate start result
In-Reply-To: <557A19EE.7030206@redhat.com>
References: <5576F142.3030307@redhat.com> <55786983.2010500@redhat.com>
	<557A19EE.7030206@redhat.com>
Message-ID: <CA+cVU8MXT+n4B5bgHTBu4Aq+Oj__SOXgxx3mOtPjcgKhYgtDXQ@mail.gmail.com>

I think there is no easy fix, we can assume for example that after 3
seconds that the PID exists then the process is up and return OK, but if
the process stops latter, it will be a fake start.

I know that we should not rely on read the log as James stated, but until
we can figure out a better aproach this is my proposal, I can modify
wildfly-init-debian.sh to have this behavior

1. Add to logging subsystem to standalone*.xml:
            <logger category="org.jboss.as">
                <level name="INFO"/>
            </logger>

2. Remove JBOSS_CONSOLE_LOG and read JBOSS_LOG_DIR

3. If standalone read "$JBOSS_LOG_DIR/server.log"
 if domain read "$JBOSS_LOG_DIR/host-controller.log"
to find WFLYSRV0025 or the string used for EAP... this is probably volatile
but it's not changed frequently, in fact it has been changed only once.

4. Always check the status of pid (if dies return immediately).

5. If server.log is not found, deactivated or not print the correct output
there are two choices:
a. On wait timeout, send a warning about an unknow status (this is how
works right now).
b. On wait timeout, just check if PID is still up and return OK, otherwise
FAILURE.

I believe this approach avoids the problem of console log...

?
?
Best regards,


Jorge Sol?rzano
http://www.jorsol.com

On Thu, Jun 11, 2015 at 5:29 PM, Chao Wang <chaowan at redhat.com> wrote:

>  Thanks for your reply. Please see in-line below
>
> On 06/11/2015 12:44 AM, Brian Stansberry wrote:
>
> A couple thoughts:
>
> 1) Looking at wildfly-init-redhat.sh at least, I don't see how that
> check is actually testing for successful startup. It looks like it's
> just trying to delay start() returning for a while, max 30 secs.
>
> So, what purpose is this fulfilling?
>
>  My bad about issue background. It's actually an case in EAP 6 (not yet in
> wildfly). EAP 6.x script has launched state like:
> https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110
> (not in wildfly's script). Also, console log handler has been removed only
> in EAP full-ha mode long time ago due to performance concern.(wildfly keeps
> it for the moment). This leads to issue in bz1224170
> <https://bugzilla.redhat.com/show_bug.cgi?id=1224170>.
> That's why I try to seek an better option than current behavior from
> wildfly.
>
> 2) How does other software solve this problem? If it's solving a valid
> problem, it seems like there would be a typical solution.
>
>  I have checked some other application servers, most of them let users
> themselves to write a script to run as service for their OS. Geronimo does
> provide a script, Although I did damage to its configuration file to make a
> fatal error, terminal output still displays "Server started". In fact,
> process does not event exist and detail error can be seen in log file.
>
> On 6/9/15 8:59 AM, Chao Wang wrote:
>
>  Hi all,
>
> The Wildfly start-up as service scripts wildfly-init-redhat.sh and
> wildfly-init-debian.sh currently depend on a grep action of key message
> 'WFLYSRV0025:' in console log to determinate whether service start is
> successful. The log message indication is accurate, however, it's not
> that robust since user can always remove console handler from logging
> subsystem. I have opened a WFCORE enhancement jirahttps://issues.jboss.org/browse/WFCORE-747 for it.
>
> For the moment, I have tried three options, they're all not that perfect
> to implement
>
> 1. Stay with exact log message, users need to define their jboss log
> directory such as $JBOSS_HOME/standalone/log/server.log for standalone
> and $JBOSS_HOME/domain/log/host-controller.log for domain instead of
> searching in console log. This is more like another workaround since it
> is also volatile once we update log message in future release.(EAP has
> 'JBAS015874:')
>
> 2. Use service pid, this is not precise because a long start-up can
> crash in the last second. It needs to wait a suitable seconds before
> checking pid existence. and still it can not avoid fake success in rare
> case just before timeout.
>
> 3. Use read-attribute server-state through CLI connection as I did in
> Pull Request on Jira. This is declined as it is possible that
> authentication is required before connection. In such case, any  non
> encrypted password is not advised in configuration files.
>
> Therefore, I would like to listen for your opinions for them. Any other
> suggestion is certainly welcomed in mail or on jira.
> ??
>
> Best regards,
>
> Chao
>
>
> _______________________________________________
> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1224170
>
> --
> Chao Wang
> Software Engineer
> JBoss by Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150611/d5d7de8c/attachment-0001.html 

From hrupp at redhat.com  Fri Jun 12 06:35:56 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 12 Jun 2015 12:35:56 +0200
Subject: [wildfly-dev] failures in composite operations
In-Reply-To: <5579F858.40601@redhat.com>
References: <1212216999.743854.1434050431713.JavaMail.zimbra@redhat.com>
	<1630274831.745660.1434051057596.JavaMail.zimbra@redhat.com>
	<5579EB60.5050909@redhat.com>
	<1733656950.772396.1434055857800.JavaMail.zimbra@redhat.com>
	<5579F858.40601@redhat.com>
Message-ID: <4C8849C7-A369-404A-9E5F-1A9FE17C5FB0@redhat.com>

On 11 Jun 2015, at 23:06, Brian Stansberry wrote:

> Semi-OT: see https://issues.jboss.org/browse/WFCORE-287 for some new
> querying functionality available in WF 10.

This is awesome. Perhaps no exactly what is asked above, but I recall
talking about that years ago already.

I think the "ok to partially fail" flag for batches of read-* operations
may still be very helpful. If we talk to a DC and need data from 
connected HCs (or even their managed servers), it is better to send
requests as batch instead of multiple single simple requests for
network latency reasons.

  Heiko


From jason.greene at redhat.com  Fri Jun 12 08:06:05 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Fri, 12 Jun 2015 08:06:05 -0400 (EDT)
Subject: [wildfly-dev] Wildfly start-up as service script depends on
	console log to determinate start result
In-Reply-To: <55786983.2010500@redhat.com>
References: <5576F142.3030307@redhat.com> <55786983.2010500@redhat.com>
Message-ID: <4128C564-7AFB-43D9-9D8A-AD6ABCB24BE1@redhat.com>


> On Jun 10, 2015, at 11:46 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> So, what purpose is this fulfilling?
> 
> 2) How does other software solve this problem? If it's solving a valid 
> problem, it seems like there would be a typical solution.

The classic UNIX solution is that the daemon forks and returns, dropping a PID file of its child to disk, after it is done initializing and exits with an error code when there is a problem.

Systemd added other approaches, where a daemon can signal systemd directly, or it can use dbus to send a message.

The former can't be done efficiently in Java because it doesn't have a pure fork(), only an exec. Although it would be possible to emulate with an exec with an unacceptable hit to boot time. The latter options are too Linux specific.

I think the best solution would be for us to add a signaling mechanism specifically for this purpose. We could use sun.misc.Signal (potentially an issue on Java 9), or we could exec the kill command to signal a process. 

We could also use a specially status file (e.g standalone.sh --start-status-file=blah) for a script to monitor.

Thoughts?

From david.lloyd at redhat.com  Fri Jun 12 08:57:25 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 12 Jun 2015 07:57:25 -0500
Subject: [wildfly-dev] Wildfly start-up as service script depends on
 console log to determinate start result
In-Reply-To: <4128C564-7AFB-43D9-9D8A-AD6ABCB24BE1@redhat.com>
References: <5576F142.3030307@redhat.com> <55786983.2010500@redhat.com>
	<4128C564-7AFB-43D9-9D8A-AD6ABCB24BE1@redhat.com>
Message-ID: <557AD735.5020907@redhat.com>

This is yet another good use case for an idea I proposed at the last 
couple developer meeting: the idea of configurable "availability" 
services, where you add a configuration which says "when these 
components and/or configured services are available, perform this 
action" where the action might be to notify a load balancer, perform a 
notification to humans, or even drop a file to the filesystem (which 
would be directly useful to this use case).

Note (in case someone thinks this is a great idea and runs out to 
implement it right away) that when I say "configured services" I do not 
mean MSC service names; more like management capabilities where you have 
a constrained namespace and each subsystem can contribute services to 
this category.

Also note that Java 9 adds limited support for signalling unrelated 
processes, though at the moment on UNIX the signals are basically 
limited to TERM and KILL.

On 06/12/2015 07:06 AM, Jason T. Greene wrote:
>
>> On Jun 10, 2015, at 11:46 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> So, what purpose is this fulfilling?
>>
>> 2) How does other software solve this problem? If it's solving a valid
>> problem, it seems like there would be a typical solution.
>
> The classic UNIX solution is that the daemon forks and returns, dropping a PID file of its child to disk, after it is done initializing and exits with an error code when there is a problem.
>
> Systemd added other approaches, where a daemon can signal systemd directly, or it can use dbus to send a message.
>
> The former can't be done efficiently in Java because it doesn't have a pure fork(), only an exec. Although it would be possible to emulate with an exec with an unacceptable hit to boot time. The latter options are too Linux specific.
>
> I think the best solution would be for us to add a signaling mechanism specifically for this purpose. We could use sun.misc.Signal (potentially an issue on Java 9), or we could exec the kill command to signal a process.
>
> We could also use a specially status file (e.g standalone.sh --start-status-file=blah) for a script to monitor.
>
> Thoughts?
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML

From brian.stansberry at redhat.com  Fri Jun 12 10:27:50 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 12 Jun 2015 09:27:50 -0500
Subject: [wildfly-dev] Wildfly start-up as service script depends on
 console log to determinate start result
In-Reply-To: <557A19EE.7030206@redhat.com>
References: <5576F142.3030307@redhat.com> <55786983.2010500@redhat.com>
	<557A19EE.7030206@redhat.com>
Message-ID: <557AEC66.1080008@redhat.com>

How does EAP 5 deal with this? IIRC disabling console logging is not 
something new in EAP 6.

On 6/11/15 6:29 PM, Chao Wang wrote:
> Thanks for your reply. Please see in-line below
>
> On 06/11/2015 12:44 AM, Brian Stansberry wrote:
>> A couple thoughts:
>>
>> 1) Looking at wildfly-init-redhat.sh at least, I don't see how that
>> check is actually testing for successful startup. It looks like it's
>> just trying to delay start() returning for a while, max 30 secs.
>>
>> So, what purpose is this fulfilling?
> My bad about issue background. It's actually an case in EAP 6 (not yet
> in wildfly). EAP 6.x script has launched state like:
> https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110
> (not in wildfly's script). Also, console log handler has been removed
> only in EAP full-ha mode long time ago due to performance
> concern.(wildfly keeps it for the moment). This leads to issue in
> bz1224170 <https://bugzilla.redhat.com/show_bug.cgi?id=1224170>.
> That's why I try to seek an better option than current behavior from
> wildfly.
>>
>> 2) How does other software solve this problem? If it's solving a valid
>> problem, it seems like there would be a typical solution.
> I have checked some other application servers, most of them let users
> themselves to write a script to run as service for their OS. Geronimo
> does provide a script, Although I did damage to its configuration file
> to make a fatal error, terminal output still displays "Server started".
> In fact, process does not event exist and detail error can be seen in
> log file.
>> On 6/9/15 8:59 AM, Chao Wang wrote:
>>> Hi all,
>>>
>>> The Wildfly start-up as service scripts wildfly-init-redhat.sh and
>>> wildfly-init-debian.sh currently depend on a grep action of key message
>>> 'WFLYSRV0025:' in console log to determinate whether service start is
>>> successful. The log message indication is accurate, however, it's not
>>> that robust since user can always remove console handler from logging
>>> subsystem. I have opened a WFCORE enhancement jira
>>> https://issues.jboss.org/browse/WFCORE-747  for it.
>>>
>>> For the moment, I have tried three options, they're all not that perfect
>>> to implement
>>>
>>> 1. Stay with exact log message, users need to define their jboss log
>>> directory such as $JBOSS_HOME/standalone/log/server.log for standalone
>>> and $JBOSS_HOME/domain/log/host-controller.log for domain instead of
>>> searching in console log. This is more like another workaround since it
>>> is also volatile once we update log message in future release.(EAP has
>>> 'JBAS015874:')
>>>
>>> 2. Use service pid, this is not precise because a long start-up can
>>> crash in the last second. It needs to wait a suitable seconds before
>>> checking pid existence. and still it can not avoid fake success in rare
>>> case just before timeout.
>>>
>>> 3. Use read-attribute server-state through CLI connection as I did in
>>> Pull Request on Jira. This is declined as it is possible that
>>> authentication is required before connection. In such case, any  non
>>> encrypted password is not advised in configuration files.
>>>
>>> Therefore, I would like to listen for your opinions for them. Any other
>>> suggestion is certainly welcomed in mail or on jira.
>>>
>>> Best regards,
>>>
>>> Chao
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1224170
>
> --
> Chao Wang
> Software Engineer
> JBoss by Red Hat
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From jorsol at gmail.com  Fri Jun 12 12:32:24 2015
From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=)
Date: Fri, 12 Jun 2015 10:32:24 -0600
Subject: [wildfly-dev] Wildfly start-up as service script depends on
 console log to determinate start result
In-Reply-To: <557AEC66.1080008@redhat.com>
References: <5576F142.3030307@redhat.com> <55786983.2010500@redhat.com>
	<557A19EE.7030206@redhat.com> <557AEC66.1080008@redhat.com>
Message-ID: <CA+cVU8NCy=xcxyDNOQvjxtdWonP7ZyVarTKFvJ4Mh+1kSRfKSA@mail.gmail.com>

It has been considered the use of Java Service Wrapper[1]? it depends on
native binaries but almost all platforms are supported.

[1] http://wrapper.tanukisoftware.com


Jorge Sol?rzano
http://www.jorsol.com

On Fri, Jun 12, 2015 at 8:27 AM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> How does EAP 5 deal with this? IIRC disabling console logging is not
> something new in EAP 6.
>
> On 6/11/15 6:29 PM, Chao Wang wrote:
> > Thanks for your reply. Please see in-line below
> >
> > On 06/11/2015 12:44 AM, Brian Stansberry wrote:
> >> A couple thoughts:
> >>
> >> 1) Looking at wildfly-init-redhat.sh at least, I don't see how that
> >> check is actually testing for successful startup. It looks like it's
> >> just trying to delay start() returning for a while, max 30 secs.
> >>
> >> So, what purpose is this fulfilling?
> > My bad about issue background. It's actually an case in EAP 6 (not yet
> > in wildfly). EAP 6.x script has launched state like:
> >
> https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110
> > (not in wildfly's script). Also, console log handler has been removed
> > only in EAP full-ha mode long time ago due to performance
> > concern.(wildfly keeps it for the moment). This leads to issue in
> > bz1224170 <https://bugzilla.redhat.com/show_bug.cgi?id=1224170>.
> > That's why I try to seek an better option than current behavior from
> > wildfly.
> >>
> >> 2) How does other software solve this problem? If it's solving a valid
> >> problem, it seems like there would be a typical solution.
> > I have checked some other application servers, most of them let users
> > themselves to write a script to run as service for their OS. Geronimo
> > does provide a script, Although I did damage to its configuration file
> > to make a fatal error, terminal output still displays "Server started".
> > In fact, process does not event exist and detail error can be seen in
> > log file.
> >> On 6/9/15 8:59 AM, Chao Wang wrote:
> >>> Hi all,
> >>>
> >>> The Wildfly start-up as service scripts wildfly-init-redhat.sh and
> >>> wildfly-init-debian.sh currently depend on a grep action of key message
> >>> 'WFLYSRV0025:' in console log to determinate whether service start is
> >>> successful. The log message indication is accurate, however, it's not
> >>> that robust since user can always remove console handler from logging
> >>> subsystem. I have opened a WFCORE enhancement jira
> >>> https://issues.jboss.org/browse/WFCORE-747  for it.
> >>>
> >>> For the moment, I have tried three options, they're all not that
> perfect
> >>> to implement
> >>>
> >>> 1. Stay with exact log message, users need to define their jboss log
> >>> directory such as $JBOSS_HOME/standalone/log/server.log for standalone
> >>> and $JBOSS_HOME/domain/log/host-controller.log for domain instead of
> >>> searching in console log. This is more like another workaround since it
> >>> is also volatile once we update log message in future release.(EAP has
> >>> 'JBAS015874:')
> >>>
> >>> 2. Use service pid, this is not precise because a long start-up can
> >>> crash in the last second. It needs to wait a suitable seconds before
> >>> checking pid existence. and still it can not avoid fake success in rare
> >>> case just before timeout.
> >>>
> >>> 3. Use read-attribute server-state through CLI connection as I did in
> >>> Pull Request on Jira. This is declined as it is possible that
> >>> authentication is required before connection. In such case, any  non
> >>> encrypted password is not advised in configuration files.
> >>>
> >>> Therefore, I would like to listen for your opinions for them. Any other
> >>> suggestion is certainly welcomed in mail or on jira.
> >>>
> >>> Best regards,
> >>>
> >>> Chao
> >>>
> >>>
> >>> _______________________________________________
> >>> wildfly-dev mailing list
> >>> wildfly-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>
> >>
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1224170
> >
> > --
> > Chao Wang
> > Software Engineer
> > JBoss by Red Hat
> >
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150612/cc59a85f/attachment-0001.html 

From jason.greene at redhat.com  Fri Jun 12 12:51:04 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 12 Jun 2015 11:51:04 -0500
Subject: [wildfly-dev] Wildfly start-up as service script depends on
	console log to determinate start result
In-Reply-To: <CA+cVU8NCy=xcxyDNOQvjxtdWonP7ZyVarTKFvJ4Mh+1kSRfKSA@mail.gmail.com>
References: <5576F142.3030307@redhat.com> <55786983.2010500@redhat.com>
	<557A19EE.7030206@redhat.com> <557AEC66.1080008@redhat.com>
	<CA+cVU8NCy=xcxyDNOQvjxtdWonP7ZyVarTKFvJ4Mh+1kSRfKSA@mail.gmail.com>
Message-ID: <908D037E-1B4C-4CA3-B52F-A80F1898200B@redhat.com>

That just monitors console output.

> On Jun 12, 2015, at 11:32 AM, Jorge Sol?rzano <jorsol at gmail.com> wrote:
> 
> It has been considered the use of Java Service Wrapper[1]? it depends on native binaries but almost all platforms are supported. 
> 
> [1] http://wrapper.tanukisoftware.com <http://wrapper.tanukisoftware.com/>
> 
> 
> Jorge Sol?rzano
> http://www.jorsol.com <http://www.jorsol.com/>
> On Fri, Jun 12, 2015 at 8:27 AM, Brian Stansberry <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
> How does EAP 5 deal with this? IIRC disabling console logging is not
> something new in EAP 6.
> 
> On 6/11/15 6:29 PM, Chao Wang wrote:
> > Thanks for your reply. Please see in-line below
> >
> > On 06/11/2015 12:44 AM, Brian Stansberry wrote:
> >> A couple thoughts:
> >>
> >> 1) Looking at wildfly-init-redhat.sh at least, I don't see how that
> >> check is actually testing for successful startup. It looks like it's
> >> just trying to delay start() returning for a while, max 30 secs.
> >>
> >> So, what purpose is this fulfilling?
> > My bad about issue background. It's actually an case in EAP 6 (not yet
> > in wildfly). EAP 6.x script has launched state like:
> > https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110 <https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110>
> > (not in wildfly's script). Also, console log handler has been removed
> > only in EAP full-ha mode long time ago due to performance
> > concern.(wildfly keeps it for the moment). This leads to issue in
> > bz1224170 <https://bugzilla.redhat.com/show_bug.cgi?id=1224170 <https://bugzilla.redhat.com/show_bug.cgi?id=1224170>>.
> > That's why I try to seek an better option than current behavior from
> > wildfly.
> >>
> >> 2) How does other software solve this problem? If it's solving a valid
> >> problem, it seems like there would be a typical solution.
> > I have checked some other application servers, most of them let users
> > themselves to write a script to run as service for their OS. Geronimo
> > does provide a script, Although I did damage to its configuration file
> > to make a fatal error, terminal output still displays "Server started".
> > In fact, process does not event exist and detail error can be seen in
> > log file.
> >> On 6/9/15 8:59 AM, Chao Wang wrote:
> >>> Hi all,
> >>>
> >>> The Wildfly start-up as service scripts wildfly-init-redhat.sh and
> >>> wildfly-init-debian.sh currently depend on a grep action of key message
> >>> 'WFLYSRV0025:' in console log to determinate whether service start is
> >>> successful. The log message indication is accurate, however, it's not
> >>> that robust since user can always remove console handler from logging
> >>> subsystem. I have opened a WFCORE enhancement jira
> >>> https://issues.jboss.org/browse/WFCORE-747 <https://issues.jboss.org/browse/WFCORE-747>  for it.
> >>>
> >>> For the moment, I have tried three options, they're all not that perfect
> >>> to implement
> >>>
> >>> 1. Stay with exact log message, users need to define their jboss log
> >>> directory such as $JBOSS_HOME/standalone/log/server.log for standalone
> >>> and $JBOSS_HOME/domain/log/host-controller.log for domain instead of
> >>> searching in console log. This is more like another workaround since it
> >>> is also volatile once we update log message in future release.(EAP has
> >>> 'JBAS015874:')
> >>>
> >>> 2. Use service pid, this is not precise because a long start-up can
> >>> crash in the last second. It needs to wait a suitable seconds before
> >>> checking pid existence. and still it can not avoid fake success in rare
> >>> case just before timeout.
> >>>
> >>> 3. Use read-attribute server-state through CLI connection as I did in
> >>> Pull Request on Jira. This is declined as it is possible that
> >>> authentication is required before connection. In such case, any  non
> >>> encrypted password is not advised in configuration files.
> >>>
> >>> Therefore, I would like to listen for your opinions for them. Any other
> >>> suggestion is certainly welcomed in mail or on jira.
> >>>
> >>> Best regards,
> >>>
> >>> Chao
> >>>
> >>>
> >>> _______________________________________________
> >>> wildfly-dev mailing list
> >>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> >>>
> >>
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1224170 <https://bugzilla.redhat.com/show_bug.cgi?id=1224170>
> >
> > --
> > Chao Wang
> > Software Engineer
> > JBoss by Red Hat
> >
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> >
> 
> 
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150612/3c9d034b/attachment.html 

From jorsol at gmail.com  Fri Jun 12 13:02:27 2015
From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=)
Date: Fri, 12 Jun 2015 11:02:27 -0600
Subject: [wildfly-dev] Wildfly start-up as service script depends on
 console log to determinate start result
In-Reply-To: <908D037E-1B4C-4CA3-B52F-A80F1898200B@redhat.com>
References: <5576F142.3030307@redhat.com> <55786983.2010500@redhat.com>
	<557A19EE.7030206@redhat.com> <557AEC66.1080008@redhat.com>
	<CA+cVU8NCy=xcxyDNOQvjxtdWonP7ZyVarTKFvJ4Mh+1kSRfKSA@mail.gmail.com>
	<908D037E-1B4C-4CA3-B52F-A80F1898200B@redhat.com>
Message-ID: <CA+cVU8OvXgDQ4KfjnA_RySBweLUeMF=xzXwocv2FqV8vvF1Xhg@mail.gmail.com>

On Fri, Jun 12, 2015 at 10:51 AM, Jason Greene <jason.greene at redhat.com>
wrote:

> That just monitors console output.
>
> ?Not exacly, there are various modes of integration, posibly the most
complex but flexible aproach is to use a listener[1] so it can be adapted
properly to what we want.

[1] http://wrapper.tanukisoftware.com/doc/english/integrate-listener.html?




> On Jun 12, 2015, at 11:32 AM, Jorge Sol?rzano <jorsol at gmail.com> wrote:
>
> It has been considered the use of Java Service Wrapper[1]? it depends on
> native binaries but almost all platforms are supported.
>
> [1] http://wrapper.tanukisoftware.com
>
>
> Jorge Sol?rzano
> http://www.jorsol.com
>
> On Fri, Jun 12, 2015 at 8:27 AM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>> How does EAP 5 deal with this? IIRC disabling console logging is not
>> something new in EAP 6.
>>
>> On 6/11/15 6:29 PM, Chao Wang wrote:
>> > Thanks for your reply. Please see in-line below
>> >
>> > On 06/11/2015 12:44 AM, Brian Stansberry wrote:
>> >> A couple thoughts:
>> >>
>> >> 1) Looking at wildfly-init-redhat.sh at least, I don't see how that
>> >> check is actually testing for successful startup. It looks like it's
>> >> just trying to delay start() returning for a while, max 30 secs.
>> >>
>> >> So, what purpose is this fulfilling?
>> > My bad about issue background. It's actually an case in EAP 6 (not yet
>> > in wildfly). EAP 6.x script has launched state like:
>> >
>> https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110
>> > (not in wildfly's script). Also, console log handler has been removed
>> > only in EAP full-ha mode long time ago due to performance
>> > concern.(wildfly keeps it for the moment). This leads to issue in
>> > bz1224170 <https://bugzilla.redhat.com/show_bug.cgi?id=1224170>.
>> > That's why I try to seek an better option than current behavior from
>> > wildfly.
>> >>
>> >> 2) How does other software solve this problem? If it's solving a valid
>> >> problem, it seems like there would be a typical solution.
>> > I have checked some other application servers, most of them let users
>> > themselves to write a script to run as service for their OS. Geronimo
>> > does provide a script, Although I did damage to its configuration file
>> > to make a fatal error, terminal output still displays "Server started".
>> > In fact, process does not event exist and detail error can be seen in
>> > log file.
>> >> On 6/9/15 8:59 AM, Chao Wang wrote:
>> >>> Hi all,
>> >>>
>> >>> The Wildfly start-up as service scripts wildfly-init-redhat.sh and
>> >>> wildfly-init-debian.sh currently depend on a grep action of key
>> message
>> >>> 'WFLYSRV0025:' in console log to determinate whether service start is
>> >>> successful. The log message indication is accurate, however, it's not
>> >>> that robust since user can always remove console handler from logging
>> >>> subsystem. I have opened a WFCORE enhancement jira
>> >>> https://issues.jboss.org/browse/WFCORE-747  for it.
>> >>>
>> >>> For the moment, I have tried three options, they're all not that
>> perfect
>> >>> to implement
>> >>>
>> >>> 1. Stay with exact log message, users need to define their jboss log
>> >>> directory such as $JBOSS_HOME/standalone/log/server.log for standalone
>> >>> and $JBOSS_HOME/domain/log/host-controller.log for domain instead of
>> >>> searching in console log. This is more like another workaround since
>> it
>> >>> is also volatile once we update log message in future release.(EAP has
>> >>> 'JBAS015874:')
>> >>>
>> >>> 2. Use service pid, this is not precise because a long start-up can
>> >>> crash in the last second. It needs to wait a suitable seconds before
>> >>> checking pid existence. and still it can not avoid fake success in
>> rare
>> >>> case just before timeout.
>> >>>
>> >>> 3. Use read-attribute server-state through CLI connection as I did in
>> >>> Pull Request on Jira. This is declined as it is possible that
>> >>> authentication is required before connection. In such case, any  non
>> >>> encrypted password is not advised in configuration files.
>> >>>
>> >>> Therefore, I would like to listen for your opinions for them. Any
>> other
>> >>> suggestion is certainly welcomed in mail or on jira.
>> >>>
>> >>> Best regards,
>> >>>
>> >>> Chao
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> wildfly-dev mailing list
>> >>> wildfly-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>>
>> >>
>> >
>> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1224170
>> >
>> > --
>> > Chao Wang
>> > Software Engineer
>> > JBoss by Red Hat
>> >
>> >
>> >
>> > _______________________________________________
>> > wildfly-dev mailing list
>> > wildfly-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150612/33530d66/attachment-0001.html 

From jperkins at redhat.com  Fri Jun 12 13:32:01 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Fri, 12 Jun 2015 10:32:01 -0700
Subject: [wildfly-dev] Wildfly start-up as service script depends on
 console log to determinate start result
In-Reply-To: <CA+cVU8MXT+n4B5bgHTBu4Aq+Oj__SOXgxx3mOtPjcgKhYgtDXQ@mail.gmail.com>
References: <5576F142.3030307@redhat.com>
	<55786983.2010500@redhat.com>	<557A19EE.7030206@redhat.com>
	<CA+cVU8MXT+n4B5bgHTBu4Aq+Oj__SOXgxx3mOtPjcgKhYgtDXQ@mail.gmail.com>
Message-ID: <557B1791.10601@redhat.com>

This won't work as there's no guarantee there will be a server.log 
and/or that it would live in log directory. The best solution involves 
not reading logs at all. I don't have any great ideas on the best way to 
currently do that.

On 06/11/2015 10:25 PM, Jorge Sol?rzano wrote:
> I think there is no easy fix, we can assume for example that after 3 
> seconds that the PID exists then the process is up and return OK, but 
> if the process stops latter, it will be a fake start.
>
> I know that we should not rely on read the log as James stated, but 
> until we can figure out a better aproach this is my proposal, I can 
> modify wildfly-init-debian.sh to have this behavior
>
> 1. Add to logging subsystem to standalone*.xml:
>             <logger category="org.jboss.as <http://org.jboss.as>">
>                 <level name="INFO"/>
>             </logger>
>
> 2. Remove JBOSS_CONSOLE_LOG and read JBOSS_LOG_DIR
>
> 3. If standalone read "$JBOSS_LOG_DIR/server.log"
>  if domain read "$JBOSS_LOG_DIR/host-controller.log"
> to find WFLYSRV0025 or the string used for EAP... this is probably 
> volatile but it's not changed frequently, in fact it has been changed 
> only once.
>
> 4. Always check the status of pid (if dies return immediately).
>
> 5. If server.log is not found, deactivated or not print the correct 
> output there are two choices:
> a. On wait timeout, send a warning about an unknow status (this is how 
> works right now).
> b. On wait timeout, just check if PID is still up and return OK, 
> otherwise FAILURE.
>
> I believe this approach avoids the problem of console log...
>
> ?
> ?
> Best regards,
>
>
> Jorge Sol?rzano
> http://www.jorsol.com
>
> On Thu, Jun 11, 2015 at 5:29 PM, Chao Wang <chaowan at redhat.com 
> <mailto:chaowan at redhat.com>> wrote:
>
>     Thanks for your reply. Please see in-line below
>
>     On 06/11/2015 12:44 AM, Brian Stansberry wrote:
>>     A couple thoughts:
>>
>>     1) Looking at wildfly-init-redhat.sh at least, I don't see how that
>>     check is actually testing for successful startup. It looks like it's
>>     just trying to delay start() returning for a while, max 30 secs.
>>
>>     So, what purpose is this fulfilling?
>     My bad about issue background. It's actually an case in EAP 6 (not
>     yet in wildfly). EAP 6.x script has launched state like:
>     https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110
>     (not in wildfly's script). Also, console log handler has been
>     removed only in EAP full-ha mode long time ago due to performance
>     concern.(wildfly keeps it for the moment). This leads to issue in
>     bz1224170 <https://bugzilla.redhat.com/show_bug.cgi?id=1224170>.
>     That's why I try to seek an better option than current behavior
>     from wildfly.
>>     2) How does other software solve this problem? If it's solving a valid
>>     problem, it seems like there would be a typical solution.
>     I have checked some other application servers, most of them let
>     users themselves to write a script to run as service for their OS.
>     Geronimo does provide a script, Although I did damage to its
>     configuration file to make a fatal error, terminal output still
>     displays "Server started". In fact, process does not event exist
>     and detail error can be seen in log file.
>>     On 6/9/15 8:59 AM, Chao Wang wrote:
>>>     Hi all,
>>>
>>>     The Wildfly start-up as service scripts wildfly-init-redhat.sh and
>>>     wildfly-init-debian.sh currently depend on a grep action of key message
>>>     'WFLYSRV0025:' in console log to determinate whether service start is
>>>     successful. The log message indication is accurate, however, it's not
>>>     that robust since user can always remove console handler from logging
>>>     subsystem. I have opened a WFCORE enhancement jira
>>>     https://issues.jboss.org/browse/WFCORE-747  for it.
>>>
>>>     For the moment, I have tried three options, they're all not that perfect
>>>     to implement
>>>
>>>     1. Stay with exact log message, users need to define their jboss log
>>>     directory such as $JBOSS_HOME/standalone/log/server.log for standalone
>>>     and $JBOSS_HOME/domain/log/host-controller.log for domain instead of
>>>     searching in console log. This is more like another workaround since it
>>>     is also volatile once we update log message in future release.(EAP has
>>>     'JBAS015874:')
>>>
>>>     2. Use service pid, this is not precise because a long start-up can
>>>     crash in the last second. It needs to wait a suitable seconds before
>>>     checking pid existence. and still it can not avoid fake success in rare
>>>     case just before timeout.
>>>
>>>     3. Use read-attribute server-state through CLI connection as I did in
>>>     Pull Request on Jira. This is declined as it is possible that
>>>     authentication is required before connection. In such case, any  non
>>>     encrypted password is not advised in configuration files.
>>>
>>>     Therefore, I would like to listen for your opinions for them. Any other
>>>     suggestion is certainly welcomed in mail or on jira.
>>>     ??
>>>
>>>     Best regards,
>>>
>>>     Chao
>>>
>>>
>>>     _______________________________________________
>>>     wildfly-dev mailing list
>>>     wildfly-dev at lists.jboss.org  <mailto:wildfly-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>
>     [1] https://bugzilla.redhat.com/show_bug.cgi?id=1224170
>
>     -- 
>     Chao Wang
>     Software Engineer
>     JBoss by Red Hat
>
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
James R. Perkins
JBoss by Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150612/fadeb5cd/attachment.html 

From jorsol at gmail.com  Fri Jun 12 14:11:29 2015
From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=)
Date: Fri, 12 Jun 2015 12:11:29 -0600
Subject: [wildfly-dev] Wildfly start-up as service script depends on
 console log to determinate start result
In-Reply-To: <557B1791.10601@redhat.com>
References: <5576F142.3030307@redhat.com> <55786983.2010500@redhat.com>
	<557A19EE.7030206@redhat.com>
	<CA+cVU8MXT+n4B5bgHTBu4Aq+Oj__SOXgxx3mOtPjcgKhYgtDXQ@mail.gmail.com>
	<557B1791.10601@redhat.com>
Message-ID: <CA+cVU8MxBcXOvBZWDvUg57UA=6i2YiYaF=o2jEeAdeYcOfDoVw@mail.gmail.com>

?

On Fri, Jun 12, 2015 at 11:32 AM, James R. Perkins <jperkins at redhat.com>
wrote:

>  This won't work as there's no guarantee there will be a server.log and/or
> that it would live in log directory. The best solution involves not reading
> logs at all. I don't have any great ideas on the best way to currently do
> that.
>
>
> ?James, that why in step 5 i mention 2 aproach, if timeout return a
warning, or if timeout check if pid is still up and return ok. It's not
perfect since it return control until timeout, but it's more reliable that
depend on console output.



> On 06/11/2015 10:25 PM, Jorge Sol?rzano wrote:
>
>  I think there is no easy fix, we can assume for example that after 3
> seconds that the PID exists then the process is up and return OK, but if
> the process stops latter, it will be a fake start.
>
>  I know that we should not rely on read the log as James stated, but
> until we can figure out a better aproach this is my proposal, I can modify
> wildfly-init-debian.sh to have this behavior
>
>  1. Add to logging subsystem to standalone*.xml:
>             <logger category="org.jboss.as">
>                 <level name="INFO"/>
>             </logger>
>
>  2. Remove JBOSS_CONSOLE_LOG and read JBOSS_LOG_DIR
>
>  3. If standalone read "$JBOSS_LOG_DIR/server.log"
>  if domain read "$JBOSS_LOG_DIR/host-controller.log"
>  to find WFLYSRV0025 or the string used for EAP... this is probably
> volatile but it's not changed frequently, in fact it has been changed only
> once.
>
>  4. Always check the status of pid (if dies return immediately).
>
>  5. If server.log is not found, deactivated or not print the correct
> output there are two choices:
>  a. On wait timeout, send a warning about an unknow status (this is how
> works right now).
>  b. On wait timeout, just check if PID is still up and return OK,
> otherwise FAILURE.
>
>  I believe this approach avoids the problem of console log...
>
>  ?
> ?
> Best regards,
>
>
> Jorge Sol?rzano
> http://www.jorsol.com
>
> On Thu, Jun 11, 2015 at 5:29 PM, Chao Wang <chaowan at redhat.com> wrote:
>
>>  Thanks for your reply. Please see in-line below
>>
>> On 06/11/2015 12:44 AM, Brian Stansberry wrote:
>>
>> A couple thoughts:
>>
>> 1) Looking at wildfly-init-redhat.sh at least, I don't see how that
>> check is actually testing for successful startup. It looks like it's
>> just trying to delay start() returning for a while, max 30 secs.
>>
>> So, what purpose is this fulfilling?
>>
>>  My bad about issue background. It's actually an case in EAP 6 (not yet
>> in wildfly). EAP 6.x script has launched state like:
>> https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110
>> (not in wildfly's script). Also, console log handler has been removed only
>> in EAP full-ha mode long time ago due to performance concern.(wildfly keeps
>> it for the moment). This leads to issue in bz1224170
>> <https://bugzilla.redhat.com/show_bug.cgi?id=1224170>.
>> That's why I try to seek an better option than current behavior from
>> wildfly.
>>
>> 2) How does other software solve this problem? If it's solving a valid
>> problem, it seems like there would be a typical solution.
>>
>>  I have checked some other application servers, most of them let users
>> themselves to write a script to run as service for their OS. Geronimo does
>> provide a script, Although I did damage to its configuration file to make a
>> fatal error, terminal output still displays "Server started". In fact,
>> process does not event exist and detail error can be seen in log file.
>>
>> On 6/9/15 8:59 AM, Chao Wang wrote:
>>
>>  Hi all,
>>
>> The Wildfly start-up as service scripts wildfly-init-redhat.sh and
>> wildfly-init-debian.sh currently depend on a grep action of key message
>> 'WFLYSRV0025:' in console log to determinate whether service start is
>> successful. The log message indication is accurate, however, it's not
>> that robust since user can always remove console handler from logging
>> subsystem. I have opened a WFCORE enhancement jirahttps://issues.jboss.org/browse/WFCORE-747 for it.
>>
>> For the moment, I have tried three options, they're all not that perfect
>> to implement
>>
>> 1. Stay with exact log message, users need to define their jboss log
>> directory such as $JBOSS_HOME/standalone/log/server.log for standalone
>> and $JBOSS_HOME/domain/log/host-controller.log for domain instead of
>> searching in console log. This is more like another workaround since it
>> is also volatile once we update log message in future release.(EAP has
>> 'JBAS015874:')
>>
>> 2. Use service pid, this is not precise because a long start-up can
>> crash in the last second. It needs to wait a suitable seconds before
>> checking pid existence. and still it can not avoid fake success in rare
>> case just before timeout.
>>
>> 3. Use read-attribute server-state through CLI connection as I did in
>> Pull Request on Jira. This is declined as it is possible that
>> authentication is required before connection. In such case, any  non
>> encrypted password is not advised in configuration files.
>>
>> Therefore, I would like to listen for your opinions for them. Any other
>> suggestion is certainly welcomed in mail or on jira.
>> ??
>>
>> Best regards,
>>
>> Chao
>>
>>
>> _______________________________________________
>> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1224170
>>
>> --
>> Chao Wang
>> Software Engineer
>> JBoss by Red Hat
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> _______________________________________________
> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> --
> James R. Perkins
> JBoss by Red Hat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150612/864c0c53/attachment-0001.html 

From jason.greene at redhat.com  Fri Jun 12 15:40:09 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 12 Jun 2015 14:40:09 -0500
Subject: [wildfly-dev] Wildfly start-up as service script depends on
	console log to determinate start result
In-Reply-To: <CA+cVU8OvXgDQ4KfjnA_RySBweLUeMF=xzXwocv2FqV8vvF1Xhg@mail.gmail.com>
References: <5576F142.3030307@redhat.com> <55786983.2010500@redhat.com>
	<557A19EE.7030206@redhat.com> <557AEC66.1080008@redhat.com>
	<CA+cVU8NCy=xcxyDNOQvjxtdWonP7ZyVarTKFvJ4Mh+1kSRfKSA@mail.gmail.com>
	<908D037E-1B4C-4CA3-B52F-A80F1898200B@redhat.com>
	<CA+cVU8OvXgDQ4KfjnA_RySBweLUeMF=xzXwocv2FqV8vvF1Xhg@mail.gmail.com>
Message-ID: <90605A7D-738E-46D8-A422-0AAB20DBC40D@redhat.com>

We wouldn?t be able to use that approach because its shipped under an incompatible viral license (GPL with additional restrictions). Theres also the other negative that we try to avoid shipping native bits if at all possible. 

> On Jun 12, 2015, at 12:02 PM, Jorge Sol?rzano <jorsol at gmail.com> wrote:
> 
> 
> On Fri, Jun 12, 2015 at 10:51 AM, Jason Greene <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
> That just monitors console output.
> 
> ?Not exacly, there are various modes of integration, posibly the most complex but flexible aproach is to use a listener[1] so it can be adapted properly to what we want.
> 
> [1] http://wrapper.tanukisoftware.com/doc/english/integrate-listener.html <http://wrapper.tanukisoftware.com/doc/english/integrate-listener.html>?
> 
> 
>  
>> On Jun 12, 2015, at 11:32 AM, Jorge Sol?rzano <jorsol at gmail.com <mailto:jorsol at gmail.com>> wrote:
>> 
>> It has been considered the use of Java Service Wrapper[1]? it depends on native binaries but almost all platforms are supported. 
>> 
>> [1] http://wrapper.tanukisoftware.com <http://wrapper.tanukisoftware.com/>
>> 
>> 
>> Jorge Sol?rzano
>> http://www.jorsol.com <http://www.jorsol.com/>
>> On Fri, Jun 12, 2015 at 8:27 AM, Brian Stansberry <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
>> How does EAP 5 deal with this? IIRC disabling console logging is not
>> something new in EAP 6.
>> 
>> On 6/11/15 6:29 PM, Chao Wang wrote:
>> > Thanks for your reply. Please see in-line below
>> >
>> > On 06/11/2015 12:44 AM, Brian Stansberry wrote:
>> >> A couple thoughts:
>> >>
>> >> 1) Looking at wildfly-init-redhat.sh at least, I don't see how that
>> >> check is actually testing for successful startup. It looks like it's
>> >> just trying to delay start() returning for a while, max 30 secs.
>> >>
>> >> So, what purpose is this fulfilling?
>> > My bad about issue background. It's actually an case in EAP 6 (not yet
>> > in wildfly). EAP 6.x script has launched state like:
>> > https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110 <https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110>
>> > (not in wildfly's script). Also, console log handler has been removed
>> > only in EAP full-ha mode long time ago due to performance
>> > concern.(wildfly keeps it for the moment). This leads to issue in
>> > bz1224170 <https://bugzilla.redhat.com/show_bug.cgi?id=1224170 <https://bugzilla.redhat.com/show_bug.cgi?id=1224170>>.
>> > That's why I try to seek an better option than current behavior from
>> > wildfly.
>> >>
>> >> 2) How does other software solve this problem? If it's solving a valid
>> >> problem, it seems like there would be a typical solution.
>> > I have checked some other application servers, most of them let users
>> > themselves to write a script to run as service for their OS. Geronimo
>> > does provide a script, Although I did damage to its configuration file
>> > to make a fatal error, terminal output still displays "Server started".
>> > In fact, process does not event exist and detail error can be seen in
>> > log file.
>> >> On 6/9/15 8:59 AM, Chao Wang wrote:
>> >>> Hi all,
>> >>>
>> >>> The Wildfly start-up as service scripts wildfly-init-redhat.sh and
>> >>> wildfly-init-debian.sh currently depend on a grep action of key message
>> >>> 'WFLYSRV0025:' in console log to determinate whether service start is
>> >>> successful. The log message indication is accurate, however, it's not
>> >>> that robust since user can always remove console handler from logging
>> >>> subsystem. I have opened a WFCORE enhancement jira
>> >>> https://issues.jboss.org/browse/WFCORE-747 <https://issues.jboss.org/browse/WFCORE-747>  for it.
>> >>>
>> >>> For the moment, I have tried three options, they're all not that perfect
>> >>> to implement
>> >>>
>> >>> 1. Stay with exact log message, users need to define their jboss log
>> >>> directory such as $JBOSS_HOME/standalone/log/server.log for standalone
>> >>> and $JBOSS_HOME/domain/log/host-controller.log for domain instead of
>> >>> searching in console log. This is more like another workaround since it
>> >>> is also volatile once we update log message in future release.(EAP has
>> >>> 'JBAS015874:')
>> >>>
>> >>> 2. Use service pid, this is not precise because a long start-up can
>> >>> crash in the last second. It needs to wait a suitable seconds before
>> >>> checking pid existence. and still it can not avoid fake success in rare
>> >>> case just before timeout.
>> >>>
>> >>> 3. Use read-attribute server-state through CLI connection as I did in
>> >>> Pull Request on Jira. This is declined as it is possible that
>> >>> authentication is required before connection. In such case, any  non
>> >>> encrypted password is not advised in configuration files.
>> >>>
>> >>> Therefore, I would like to listen for your opinions for them. Any other
>> >>> suggestion is certainly welcomed in mail or on jira.
>> >>>
>> >>> Best regards,
>> >>>
>> >>> Chao
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> wildfly-dev mailing list
>> >>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>> >>>
>> >>
>> >
>> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1224170 <https://bugzilla.redhat.com/show_bug.cgi?id=1224170>
>> >
>> > --
>> > Chao Wang
>> > Software Engineer
>> > JBoss by Red Hat
>> >
>> >
>> >
>> > _______________________________________________
>> > wildfly-dev mailing list
>> > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>> >
>> 
>> 
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150612/f0c7be2c/attachment.html 

From brian.stansberry at redhat.com  Fri Jun 12 16:22:16 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 12 Jun 2015 15:22:16 -0500
Subject: [wildfly-dev] Capability naming conventions
Message-ID: <557B3F78.1090907@redhat.com>

The capability and requirement stuff[1] is far enough along that real 
usage is happening, so actual capability names are being created.[2] I 
wanted to get some input regarding naming conventions for capability 
names so it doesn't devovle into chaos, and so I don't end up making up 
a lot of names people hate.

The key thing is capabilities need to be namespaced to avoid collisions 
between capability creators. Beyond that the names should be "good", 
whatever that means (user friendly, properly targeted, not overly tied 
to implementation, etc).

My initial thinking on this was:

1) The WildFly family projects own the "org.wildfly" namespace. So all 
capabilities we create fit in that namespace, and no one else puts 
things there. This I think is a must.

2) Capabilities not used by or provided by the WildFly kernel go in 
subspace org.wildfly.extension.<name_of_extension>. Idea there was just 
to avoid naming collisions between different extensions.

I don't think 2) is such a great idea any more. A given capability be 
provided by more than one extension, so there isn't a clean conceptual 
mapping. And the word "extension" is really an implementation detail.

So, I'm inclined to drop the "extension" bit.

Any thoughts on this, or other aspects of how to name capabilities?

FYI, see [3] for some names of capabilities that will be used by the kernel.

[1] The "Runtime" aspect of https://developer.jboss.org/docs/DOC-52712
[2] https://github.com/wildfly/wildfly/pull/7596
[3] https://developer.jboss.org/docs/DOC-53383

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From david.lloyd at redhat.com  Fri Jun 12 17:24:55 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 12 Jun 2015 16:24:55 -0500
Subject: [wildfly-dev] Capability naming conventions
In-Reply-To: <557B3F78.1090907@redhat.com>
References: <557B3F78.1090907@redhat.com>
Message-ID: <557B4E27.4080708@redhat.com>

On 06/12/2015 03:22 PM, Brian Stansberry wrote:
> The capability and requirement stuff[1] is far enough along that real
> usage is happening, so actual capability names are being created.[2] I
> wanted to get some input regarding naming conventions for capability
> names so it doesn't devovle into chaos, and so I don't end up making up
> a lot of names people hate.
>
> The key thing is capabilities need to be namespaced to avoid collisions
> between capability creators. Beyond that the names should be "good",
> whatever that means (user friendly, properly targeted, not overly tied
> to implementation, etc).
>
> My initial thinking on this was:
>
> 1) The WildFly family projects own the "org.wildfly" namespace. So all
> capabilities we create fit in that namespace, and no one else puts
> things there. This I think is a must.
>
> 2) Capabilities not used by or provided by the WildFly kernel go in
> subspace org.wildfly.extension.<name_of_extension>. Idea there was just
> to avoid naming collisions between different extensions.
>
> I don't think 2) is such a great idea any more. A given capability be
> provided by more than one extension, so there isn't a clean conceptual
> mapping. And the word "extension" is really an implementation detail.
>
> So, I'm inclined to drop the "extension" bit.
>
> Any thoughts on this, or other aspects of how to name capabilities?

Sounds good to me.  I'd like to add that internally, we should make sure 
we continue to maintain some registry of our org.wildfly name spaces 
somewhere (maybe even just a git repository would be OK) so we don't 
conflict among ourselves.

-- 
- DML

From anilsaldhana at gmail.com  Fri Jun 12 17:30:46 2015
From: anilsaldhana at gmail.com (Anil Saldhana)
Date: Fri, 12 Jun 2015 16:30:46 -0500
Subject: [wildfly-dev] Capability naming conventions
In-Reply-To: <557B4E27.4080708@redhat.com>
References: <557B3F78.1090907@redhat.com>
	<557B4E27.4080708@redhat.com>
Message-ID: <CAAJh=gBYQ08FA+j_ogtE6EfpiKNyBMNqXnXB9CKs7bQ3b-56JA@mail.gmail.com>

Is there an inbuilt mechanism in the capabilities ecosystem that disallows
system integrators from writing capabilities in the org.wildfly namespace?
This is important lest it becomes a wild west in terms of capabilities. :-)

On Fri, Jun 12, 2015 at 4:24 PM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> On 06/12/2015 03:22 PM, Brian Stansberry wrote:
> > The capability and requirement stuff[1] is far enough along that real
> > usage is happening, so actual capability names are being created.[2] I
> > wanted to get some input regarding naming conventions for capability
> > names so it doesn't devovle into chaos, and so I don't end up making up
> > a lot of names people hate.
> >
> > The key thing is capabilities need to be namespaced to avoid collisions
> > between capability creators. Beyond that the names should be "good",
> > whatever that means (user friendly, properly targeted, not overly tied
> > to implementation, etc).
> >
> > My initial thinking on this was:
> >
> > 1) The WildFly family projects own the "org.wildfly" namespace. So all
> > capabilities we create fit in that namespace, and no one else puts
> > things there. This I think is a must.
> >
> > 2) Capabilities not used by or provided by the WildFly kernel go in
> > subspace org.wildfly.extension.<name_of_extension>. Idea there was just
> > to avoid naming collisions between different extensions.
> >
> > I don't think 2) is such a great idea any more. A given capability be
> > provided by more than one extension, so there isn't a clean conceptual
> > mapping. And the word "extension" is really an implementation detail.
> >
> > So, I'm inclined to drop the "extension" bit.
> >
> > Any thoughts on this, or other aspects of how to name capabilities?
>
> Sounds good to me.  I'd like to add that internally, we should make sure
> we continue to maintain some registry of our org.wildfly name spaces
> somewhere (maybe even just a git repository would be OK) so we don't
> conflict among ourselves.
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150612/d1700db2/attachment-0001.html 

From brian.stansberry at redhat.com  Fri Jun 12 17:31:08 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 12 Jun 2015 16:31:08 -0500
Subject: [wildfly-dev] Capability naming conventions
In-Reply-To: <557B4E27.4080708@redhat.com>
References: <557B3F78.1090907@redhat.com> <557B4E27.4080708@redhat.com>
Message-ID: <557B4F9C.1090200@redhat.com>

On 6/12/15 4:24 PM, David M. Lloyd wrote:

>
> Sounds good to me.  I'd like to add that internally, we should make sure
> we continue to maintain some registry of our org.wildfly name spaces
> somewhere (maybe even just a git repository would be OK) so we don't
> conflict among ourselves.
>

Like a text file per capability, with some doc on the capability in the 
file? Files organized in a tree from the names?

That sounds good; much better than some wiki.

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From brian.stansberry at redhat.com  Fri Jun 12 17:34:00 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 12 Jun 2015 16:34:00 -0500
Subject: [wildfly-dev] Capability naming conventions
In-Reply-To: <CAAJh=gBYQ08FA+j_ogtE6EfpiKNyBMNqXnXB9CKs7bQ3b-56JA@mail.gmail.com>
References: <557B3F78.1090907@redhat.com>	<557B4E27.4080708@redhat.com>
	<CAAJh=gBYQ08FA+j_ogtE6EfpiKNyBMNqXnXB9CKs7bQ3b-56JA@mail.gmail.com>
Message-ID: <557B5048.60905@redhat.com>

No, there isn't.

On 6/12/15 4:30 PM, Anil Saldhana wrote:
> Is there an inbuilt mechanism in the capabilities ecosystem that
> disallows system integrators from writing capabilities in the
> org.wildfly namespace?
> This is important lest it becomes a wild west in terms of capabilities. :-)
>
> On Fri, Jun 12, 2015 at 4:24 PM, David M. Lloyd <david.lloyd at redhat.com
> <mailto:david.lloyd at redhat.com>> wrote:
>
>     On 06/12/2015 03:22 PM, Brian Stansberry wrote:
>     > The capability and requirement stuff[1] is far enough along that real
>     > usage is happening, so actual capability names are being created.[2] I
>     > wanted to get some input regarding naming conventions for capability
>     > names so it doesn't devovle into chaos, and so I don't end up making up
>     > a lot of names people hate.
>     >
>     > The key thing is capabilities need to be namespaced to avoid collisions
>     > between capability creators. Beyond that the names should be "good",
>     > whatever that means (user friendly, properly targeted, not overly tied
>     > to implementation, etc).
>     >
>     > My initial thinking on this was:
>     >
>     > 1) The WildFly family projects own the "org.wildfly" namespace. So all
>     > capabilities we create fit in that namespace, and no one else puts
>     > things there. This I think is a must.
>     >
>     > 2) Capabilities not used by or provided by the WildFly kernel go in
>     > subspace org.wildfly.extension.<name_of_extension>. Idea there was just
>     > to avoid naming collisions between different extensions.
>     >
>     > I don't think 2) is such a great idea any more. A given capability be
>     > provided by more than one extension, so there isn't a clean conceptual
>     > mapping. And the word "extension" is really an implementation detail.
>     >
>     > So, I'm inclined to drop the "extension" bit.
>     >
>     > Any thoughts on this, or other aspects of how to name capabilities?
>
>     Sounds good to me.  I'd like to add that internally, we should make sure
>     we continue to maintain some registry of our org.wildfly name spaces
>     somewhere (maybe even just a git repository would be OK) so we don't
>     conflict among ourselves.
>
>     --
>     - DML
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From anilsaldhana at gmail.com  Fri Jun 12 17:41:05 2015
From: anilsaldhana at gmail.com (Anil Saldhana)
Date: Fri, 12 Jun 2015 16:41:05 -0500
Subject: [wildfly-dev] Capability naming conventions
In-Reply-To: <557B5048.60905@redhat.com>
References: <557B3F78.1090907@redhat.com> <557B4E27.4080708@redhat.com>
	<CAAJh=gBYQ08FA+j_ogtE6EfpiKNyBMNqXnXB9CKs7bQ3b-56JA@mail.gmail.com>
	<557B5048.60905@redhat.com>
Message-ID: <CAAJh=gA49_didN9FdS43EYfSjvN_9fs28qpAfL2zOCuWvPuEYg@mail.gmail.com>

It probably is not a big deal TBH.  A proper documented wiki with
guidelines for capabilities is all you need. A capability namespace
enforcement model (though a capability of its own) is an overkill.  I was
just curious. ;)

May I suggest adding some diagrams on your capabilities wiki page
explaining the key concepts behind it. I had to dig deep to understand the
differences between capabilities and modules.

On Fri, Jun 12, 2015 at 4:34 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> No, there isn't.
>
> On 6/12/15 4:30 PM, Anil Saldhana wrote:
> > Is there an inbuilt mechanism in the capabilities ecosystem that
> > disallows system integrators from writing capabilities in the
> > org.wildfly namespace?
> > This is important lest it becomes a wild west in terms of capabilities.
> :-)
> >
> > On Fri, Jun 12, 2015 at 4:24 PM, David M. Lloyd <david.lloyd at redhat.com
> > <mailto:david.lloyd at redhat.com>> wrote:
> >
> >     On 06/12/2015 03:22 PM, Brian Stansberry wrote:
> >     > The capability and requirement stuff[1] is far enough along that
> real
> >     > usage is happening, so actual capability names are being
> created.[2] I
> >     > wanted to get some input regarding naming conventions for
> capability
> >     > names so it doesn't devovle into chaos, and so I don't end up
> making up
> >     > a lot of names people hate.
> >     >
> >     > The key thing is capabilities need to be namespaced to avoid
> collisions
> >     > between capability creators. Beyond that the names should be
> "good",
> >     > whatever that means (user friendly, properly targeted, not overly
> tied
> >     > to implementation, etc).
> >     >
> >     > My initial thinking on this was:
> >     >
> >     > 1) The WildFly family projects own the "org.wildfly" namespace. So
> all
> >     > capabilities we create fit in that namespace, and no one else puts
> >     > things there. This I think is a must.
> >     >
> >     > 2) Capabilities not used by or provided by the WildFly kernel go in
> >     > subspace org.wildfly.extension.<name_of_extension>. Idea there was
> just
> >     > to avoid naming collisions between different extensions.
> >     >
> >     > I don't think 2) is such a great idea any more. A given capability
> be
> >     > provided by more than one extension, so there isn't a clean
> conceptual
> >     > mapping. And the word "extension" is really an implementation
> detail.
> >     >
> >     > So, I'm inclined to drop the "extension" bit.
> >     >
> >     > Any thoughts on this, or other aspects of how to name capabilities?
> >
> >     Sounds good to me.  I'd like to add that internally, we should make
> sure
> >     we continue to maintain some registry of our org.wildfly name spaces
> >     somewhere (maybe even just a git repository would be OK) so we don't
> >     conflict among ourselves.
> >
> >     --
> >     - DML
> >     _______________________________________________
> >     wildfly-dev mailing list
> >     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150612/eb0e00f1/attachment.html 

From jorsol at gmail.com  Fri Jun 12 18:05:59 2015
From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=)
Date: Fri, 12 Jun 2015 16:05:59 -0600
Subject: [wildfly-dev] Wildfly start-up as service script depends on
 console log to determinate start result
In-Reply-To: <90605A7D-738E-46D8-A422-0AAB20DBC40D@redhat.com>
References: <5576F142.3030307@redhat.com> <55786983.2010500@redhat.com>
	<557A19EE.7030206@redhat.com> <557AEC66.1080008@redhat.com>
	<CA+cVU8NCy=xcxyDNOQvjxtdWonP7ZyVarTKFvJ4Mh+1kSRfKSA@mail.gmail.com>
	<908D037E-1B4C-4CA3-B52F-A80F1898200B@redhat.com>
	<CA+cVU8OvXgDQ4KfjnA_RySBweLUeMF=xzXwocv2FqV8vvF1Xhg@mail.gmail.com>
	<90605A7D-738E-46D8-A422-0AAB20DBC40D@redhat.com>
Message-ID: <CA+cVU8Mw3aKR4jJ56RDPQDrWAeo6Bjpxd54yP9yS=fCWKeO40A@mail.gmail.com>

On Fri, Jun 12, 2015 at 1:40 PM, Jason Greene <jason.greene at redhat.com>
wrote:

> We wouldn?t be able to use that approach because its shipped under an
> incompatible viral license (GPL with additional restrictions). Theres also
> the other negative that we try to avoid shipping native bits if at all
> possible.
>
> That a good reason? to avoid that...

And what about Commons Daemon?, it stills depends on the native part, but
wildfly already includes native binaries for windows, a separate download
of the native part could be an option for both unix and windows...



> On Jun 12, 2015, at 12:02 PM, Jorge Sol?rzano <jorsol at gmail.com> wrote:
>
>
> On Fri, Jun 12, 2015 at 10:51 AM, Jason Greene <jason.greene at redhat.com>
> wrote:
>
>> That just monitors console output.
>>
>> ?Not exacly, there are various modes of integration, posibly the most
> complex but flexible aproach is to use a listener[1] so it can be adapted
> properly to what we want.
>
> [1] http://wrapper.tanukisoftware.com/doc/english/integrate-listener.html?
>
>
>
>
>> On Jun 12, 2015, at 11:32 AM, Jorge Sol?rzano <jorsol at gmail.com> wrote:
>>
>> It has been considered the use of Java Service Wrapper[1]? it depends on
>> native binaries but almost all platforms are supported.
>>
>> [1] http://wrapper.tanukisoftware.com
>>
>>
>> Jorge Sol?rzano
>> http://www.jorsol.com
>>
>> On Fri, Jun 12, 2015 at 8:27 AM, Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>>
>>> How does EAP 5 deal with this? IIRC disabling console logging is not
>>> something new in EAP 6.
>>>
>>> On 6/11/15 6:29 PM, Chao Wang wrote:
>>> > Thanks for your reply. Please see in-line below
>>> >
>>> > On 06/11/2015 12:44 AM, Brian Stansberry wrote:
>>> >> A couple thoughts:
>>> >>
>>> >> 1) Looking at wildfly-init-redhat.sh at least, I don't see how that
>>> >> check is actually testing for successful startup. It looks like it's
>>> >> just trying to delay start() returning for a while, max 30 secs.
>>> >>
>>> >> So, what purpose is this fulfilling?
>>> > My bad about issue background. It's actually an case in EAP 6 (not yet
>>> > in wildfly). EAP 6.x script has launched state like:
>>> >
>>> https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110
>>> > (not in wildfly's script). Also, console log handler has been removed
>>> > only in EAP full-ha mode long time ago due to performance
>>> > concern.(wildfly keeps it for the moment). This leads to issue in
>>> > bz1224170 <https://bugzilla.redhat.com/show_bug.cgi?id=1224170>.
>>> > That's why I try to seek an better option than current behavior from
>>> > wildfly.
>>> >>
>>> >> 2) How does other software solve this problem? If it's solving a valid
>>> >> problem, it seems like there would be a typical solution.
>>> > I have checked some other application servers, most of them let users
>>> > themselves to write a script to run as service for their OS. Geronimo
>>> > does provide a script, Although I did damage to its configuration file
>>> > to make a fatal error, terminal output still displays "Server started".
>>> > In fact, process does not event exist and detail error can be seen in
>>> > log file.
>>> >> On 6/9/15 8:59 AM, Chao Wang wrote:
>>> >>> Hi all,
>>> >>>
>>> >>> The Wildfly start-up as service scripts wildfly-init-redhat.sh and
>>> >>> wildfly-init-debian.sh currently depend on a grep action of key
>>> message
>>> >>> 'WFLYSRV0025:' in console log to determinate whether service start is
>>> >>> successful. The log message indication is accurate, however, it's not
>>> >>> that robust since user can always remove console handler from logging
>>> >>> subsystem. I have opened a WFCORE enhancement jira
>>> >>> https://issues.jboss.org/browse/WFCORE-747  for it.
>>> >>>
>>> >>> For the moment, I have tried three options, they're all not that
>>> perfect
>>> >>> to implement
>>> >>>
>>> >>> 1. Stay with exact log message, users need to define their jboss log
>>> >>> directory such as $JBOSS_HOME/standalone/log/server.log for
>>> standalone
>>> >>> and $JBOSS_HOME/domain/log/host-controller.log for domain instead of
>>> >>> searching in console log. This is more like another workaround since
>>> it
>>> >>> is also volatile once we update log message in future release.(EAP
>>> has
>>> >>> 'JBAS015874:')
>>> >>>
>>> >>> 2. Use service pid, this is not precise because a long start-up can
>>> >>> crash in the last second. It needs to wait a suitable seconds before
>>> >>> checking pid existence. and still it can not avoid fake success in
>>> rare
>>> >>> case just before timeout.
>>> >>>
>>> >>> 3. Use read-attribute server-state through CLI connection as I did in
>>> >>> Pull Request on Jira. This is declined as it is possible that
>>> >>> authentication is required before connection. In such case, any  non
>>> >>> encrypted password is not advised in configuration files.
>>> >>>
>>> >>> Therefore, I would like to listen for your opinions for them. Any
>>> other
>>> >>> suggestion is certainly welcomed in mail or on jira.
>>> >>>
>>> >>> Best regards,
>>> >>>
>>> >>> Chao
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> wildfly-dev mailing list
>>> >>> wildfly-dev at lists.jboss.org
>>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >>>
>>> >>
>>> >
>>> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1224170
>>> >
>>> > --
>>> > Chao Wang
>>> > Software Engineer
>>> > JBoss by Red Hat
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > wildfly-dev mailing list
>>> > wildfly-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150612/df1ed160/attachment-0001.html 

From brian.stansberry at redhat.com  Fri Jun 12 18:20:39 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 12 Jun 2015 17:20:39 -0500
Subject: [wildfly-dev] Capability naming conventions
In-Reply-To: <CAAJh=gA49_didN9FdS43EYfSjvN_9fs28qpAfL2zOCuWvPuEYg@mail.gmail.com>
References: <557B3F78.1090907@redhat.com>	<557B4E27.4080708@redhat.com>	<CAAJh=gBYQ08FA+j_ogtE6EfpiKNyBMNqXnXB9CKs7bQ3b-56JA@mail.gmail.com>	<557B5048.60905@redhat.com>
	<CAAJh=gA49_didN9FdS43EYfSjvN_9fs28qpAfL2zOCuWvPuEYg@mail.gmail.com>
Message-ID: <557B5B37.803@redhat.com>

On 6/12/15 4:41 PM, Anil Saldhana wrote:
> It probably is not a big deal TBH.  A proper documented wiki with
> guidelines for capabilities is all you need. A capability namespace
> enforcement model (though a capability of its own) is an overkill.  I
> was just curious. ;)
>

Ok, good, as that wouldn't be trivial!

> May I suggest adding some diagrams on your capabilities wiki page
> explaining the key concepts behind it. I had to dig deep to understand
> the differences between capabilities and modules.
>

I want to add a section to the "Extending WildFly" docs[1]. This 
distinction is a good one to clarify.

Perhaps I should call if a "managed capability" as this is all about 
stuff that functionality via the WildFly Core management layer.

The distinction between an extension and a managed capability is another 
good one.

[1] https://docs.jboss.org/author/display/WFLY9/Extending+WildFly

> On Fri, Jun 12, 2015 at 4:34 PM, Brian Stansberry
> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
>
>     No, there isn't.
>
>     On 6/12/15 4:30 PM, Anil Saldhana wrote:
>     > Is there an inbuilt mechanism in the capabilities ecosystem that
>     > disallows system integrators from writing capabilities in the
>     > org.wildfly namespace?
>     > This is important lest it becomes a wild west in terms of capabilities. :-)
>     >
>     > On Fri, Jun 12, 2015 at 4:24 PM, David M. Lloyd <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>
>      > <mailto:david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>>>
>     wrote:
>      >
>      >     On 06/12/2015 03:22 PM, Brian Stansberry wrote:
>      >     > The capability and requirement stuff[1] is far enough along
>     that real
>      >     > usage is happening, so actual capability names are being
>     created.[2] I
>      >     > wanted to get some input regarding naming conventions for
>     capability
>      >     > names so it doesn't devovle into chaos, and so I don't end
>     up making up
>      >     > a lot of names people hate.
>      >     >
>      >     > The key thing is capabilities need to be namespaced to
>     avoid collisions
>      >     > between capability creators. Beyond that the names should
>     be "good",
>      >     > whatever that means (user friendly, properly targeted, not
>     overly tied
>      >     > to implementation, etc).
>      >     >
>      >     > My initial thinking on this was:
>      >     >
>      >     > 1) The WildFly family projects own the "org.wildfly"
>     namespace. So all
>      >     > capabilities we create fit in that namespace, and no one
>     else puts
>      >     > things there. This I think is a must.
>      >     >
>      >     > 2) Capabilities not used by or provided by the WildFly
>     kernel go in
>      >     > subspace org.wildfly.extension.<name_of_extension>. Idea
>     there was just
>      >     > to avoid naming collisions between different extensions.
>      >     >
>      >     > I don't think 2) is such a great idea any more. A given
>     capability be
>      >     > provided by more than one extension, so there isn't a clean
>     conceptual
>      >     > mapping. And the word "extension" is really an
>     implementation detail.
>      >     >
>      >     > So, I'm inclined to drop the "extension" bit.
>      >     >
>      >     > Any thoughts on this, or other aspects of how to name
>     capabilities?
>      >
>      >     Sounds good to me.  I'd like to add that internally, we
>     should make sure
>      >     we continue to maintain some registry of our org.wildfly name
>     spaces
>      >     somewhere (maybe even just a git repository would be OK) so
>     we don't
>      >     conflict among ourselves.
>      >
>      >     --
>      >     - DML
>      >     _______________________________________________
>      >     wildfly-dev mailing list
>      > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     <mailto:wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>>
>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > wildfly-dev mailing list
>     >wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     >https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>
>
>     --
>     Brian Stansberry
>     Senior Principal Software Engineer
>     JBoss by Red Hat
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From kabir.khan at jboss.com  Sat Jun 13 05:00:55 2015
From: kabir.khan at jboss.com (Kabir Khan)
Date: Sat, 13 Jun 2015 10:00:55 +0100
Subject: [wildfly-dev] Capability naming conventions
In-Reply-To: <557B4F9C.1090200@redhat.com>
References: <557B3F78.1090907@redhat.com> <557B4E27.4080708@redhat.com>
	<557B4F9C.1090200@redhat.com>
Message-ID: <21E52078-A52B-4C9E-AA27-B6D4DC088D14@jboss.com>


> On 12 Jun 2015, at 22:31, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> On 6/12/15 4:24 PM, David M. Lloyd wrote:
> 
>> 
>> Sounds good to me.  I'd like to add that internally, we should make sure
>> we continue to maintain some registry of our org.wildfly name spaces
>> somewhere (maybe even just a git repository would be OK) so we don't
>> conflict among ourselves.
>> 
> 
> Like a text file per capability, with some doc on the capability in the 
> file? Files organized in a tree from the names?
> 
> That sounds good; much better than some wiki.
+1
I don?t know enough about this yet to suggest a format, but having it somewhere in the source is a lot better than a wiki. A wiki brings to mind that horrible log ids page we used for AS 7.
> 
> -- 
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From chaowan at redhat.com  Sun Jun 14 23:31:48 2015
From: chaowan at redhat.com (Chao Wang)
Date: Mon, 15 Jun 2015 11:31:48 +0800
Subject: [wildfly-dev] Wildfly start-up as service script depends on
 console log to determinate start result
In-Reply-To: <557AEC66.1080008@redhat.com>
References: <5576F142.3030307@redhat.com>
	<55786983.2010500@redhat.com>	<557A19EE.7030206@redhat.com>
	<557AEC66.1080008@redhat.com>
Message-ID: <557E4724.4060101@redhat.com>

On 06/12/2015 10:27 PM, Brian Stansberry wrote:
> How does EAP 5 deal with this? IIRC disabling console logging is not
> something new in EAP 6.
Yes, it also removed console logger for production configuration in EAP 5.
The script is at 
https://anonsvn.jboss.org/repos/jbossas/branches/JBPAPP_5/server/src/bin/jboss_init_redhat.sh 
It simply calls start-up script and does not provide any result check as:

eval $JBOSS_CMD_START >${JBOSS_CONSOLE} 2>&1 &


> On 6/11/15 6:29 PM, Chao Wang wrote:
>> Thanks for your reply. Please see in-line below
>>
>> On 06/11/2015 12:44 AM, Brian Stansberry wrote:
>>> A couple thoughts:
>>>
>>> 1) Looking at wildfly-init-redhat.sh at least, I don't see how that
>>> check is actually testing for successful startup. It looks like it's
>>> just trying to delay start() returning for a while, max 30 secs.
>>>
>>> So, what purpose is this fulfilling?
>> My bad about issue background. It's actually an case in EAP 6 (not yet
>> in wildfly). EAP 6.x script has launched state like:
>> https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110
>> (not in wildfly's script). Also, console log handler has been removed
>> only in EAP full-ha mode long time ago due to performance
>> concern.(wildfly keeps it for the moment). This leads to issue in
>> bz1224170 <https://bugzilla.redhat.com/show_bug.cgi?id=1224170>.
>> That's why I try to seek an better option than current behavior from
>> wildfly.
>>> 2) How does other software solve this problem? If it's solving a valid
>>> problem, it seems like there would be a typical solution.
>> I have checked some other application servers, most of them let users
>> themselves to write a script to run as service for their OS. Geronimo
>> does provide a script, Although I did damage to its configuration file
>> to make a fatal error, terminal output still displays "Server started".
>> In fact, process does not event exist and detail error can be seen in
>> log file.
>>> On 6/9/15 8:59 AM, Chao Wang wrote:
>>>> Hi all,
>>>>
>>>> The Wildfly start-up as service scripts wildfly-init-redhat.sh and
>>>> wildfly-init-debian.sh currently depend on a grep action of key message
>>>> 'WFLYSRV0025:' in console log to determinate whether service start is
>>>> successful. The log message indication is accurate, however, it's not
>>>> that robust since user can always remove console handler from logging
>>>> subsystem. I have opened a WFCORE enhancement jira
>>>> https://issues.jboss.org/browse/WFCORE-747  for it.
>>>>
>>>> For the moment, I have tried three options, they're all not that perfect
>>>> to implement
>>>>
>>>> 1. Stay with exact log message, users need to define their jboss log
>>>> directory such as $JBOSS_HOME/standalone/log/server.log for standalone
>>>> and $JBOSS_HOME/domain/log/host-controller.log for domain instead of
>>>> searching in console log. This is more like another workaround since it
>>>> is also volatile once we update log message in future release.(EAP has
>>>> 'JBAS015874:')
>>>>
>>>> 2. Use service pid, this is not precise because a long start-up can
>>>> crash in the last second. It needs to wait a suitable seconds before
>>>> checking pid existence. and still it can not avoid fake success in rare
>>>> case just before timeout.
>>>>
>>>> 3. Use read-attribute server-state through CLI connection as I did in
>>>> Pull Request on Jira. This is declined as it is possible that
>>>> authentication is required before connection. In such case, any  non
>>>> encrypted password is not advised in configuration files.
>>>>
>>>> Therefore, I would like to listen for your opinions for them. Any other
>>>> suggestion is certainly welcomed in mail or on jira.
>>>>
>>>> Best regards,
>>>>
>>>> Chao
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1224170
>>
>> --
>> Chao Wang
>> Software Engineer
>> JBoss by Red Hat
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>


-- 
Chao Wang
Software Engineer
JBoss by Red Hat


From lkubik at redhat.com  Mon Jun 15 14:23:43 2015
From: lkubik at redhat.com (Lukas Kubik)
Date: Mon, 15 Jun 2015 14:23:43 -0400 (EDT)
Subject: [wildfly-dev] Github repo line endings unification advice
In-Reply-To: <E4DD0BC4-A440-4504-9BCC-BB6E5039F0BC@redhat.com>
References: <1654554071.18203183.1433936460558.JavaMail.zimbra@redhat.com>
	<E4DD0BC4-A440-4504-9BCC-BB6E5039F0BC@redhat.com>
Message-ID: <2094117030.22140744.1434392623734.JavaMail.zimbra@redhat.com>

Hi Jason,

Thanks for the explanation. Is there any reason why you don't use "* text=auto" option?


Lukas

----- Original Message -----
From: "Jason T. Greene" <jason.greene at redhat.com>
To: "Lukas Kubik" <lkubik at redhat.com>
Cc: wildfly-dev at lists.jboss.org
Sent: Wednesday, June 10, 2015 2:04:53 PM
Subject: Re: [wildfly-dev] Github repo line endings unification advice

It's a mistake that the jsp files aren't in gitatttibutes. The reason that it hasn't gotten CRLF is probably a bit of luck, and a bit of the fact that most code editors try to preserve them on their own even on windows.

> On Jun 10, 2015, at 6:41 AM, Lukas Kubik <lkubik at redhat.com> wrote:
> 
> Hi,
> 
> I'm sorry that this is a little bit off-topic question but I already asked in the forum and nobody answered me. How do you guys deal with the line endings unification in your github repo? I saw that you don't have for example .jsp files in the .gitattributes file however all .jsp files in the WF repo uses LF ending. How do you check that windows CRLF won't get merged with some PR?
> 
> We are currently discussing the unification of the line endings in the Keycloak repo so I would like to kindly ask you for any advice.
> 
> 
> Thank you for the answer.
> Regards,
> 
> Lukas
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From lkubik at redhat.com  Mon Jun 15 14:30:02 2015
From: lkubik at redhat.com (Lukas Kubik)
Date: Mon, 15 Jun 2015 14:30:02 -0400 (EDT)
Subject: [wildfly-dev] Github repo line endings unification advice
In-Reply-To: <CAFVp3Z6uGtjmD+YKfdabdAm4xx-m3p+aOdSxE0hjdY6jAtO1Bw@mail.gmail.com>
References: <1504536192.18199066.1433936280621.JavaMail.zimbra@redhat.com>
	<1654554071.18203183.1433936460558.JavaMail.zimbra@redhat.com>
	<CAFVp3Z6uGtjmD+YKfdabdAm4xx-m3p+aOdSxE0hjdY6jAtO1Bw@mail.gmail.com>
Message-ID: <1383432588.22145199.1434393002465.JavaMail.zimbra@redhat.com>

Hi Eduardo,

I haven't found this settings in the Wildfly checkstyle settings so that's one of the reasons why I asked about the line endings.
Thanks for the possible solution.


Regards,
Lukas

----- Original Message -----
From: "Eduardo Sant?Ana da Silva" <eduardo.santanadasilva at gmail.com>
To: "Lukas Kubik" <lkubik at redhat.com>
Cc: wildfly-dev at lists.jboss.org
Sent: Wednesday, June 10, 2015 1:52:50 PM
Subject: Re: [wildfly-dev] Github repo line endings unification advice

I believe that this is done by checkstyle.
I found this on the checkstyle project:

https://github.com/checkstyle/checkstyle/issues/893

<module name="RegexpMultiline">
    <property name="format" value="\r\n"/>
    <property name="message" value="Do not use Windows line endings"/>
</module>


2015-06-10 8:41 GMT-03:00 Lukas Kubik <lkubik at redhat.com>:

> Hi,
>
> I'm sorry that this is a little bit off-topic question but I already asked
> in the forum and nobody answered me. How do you guys deal with the line
> endings unification in your github repo? I saw that you don't have for
> example .jsp files in the .gitattributes file however all .jsp files in the
> WF repo uses LF ending. How do you check that windows CRLF won't get merged
> with some PR?
>
> We are currently discussing the unification of the line endings in the
> Keycloak repo so I would like to kindly ask you for any advice.
>
>
> Thank you for the answer.
> Regards,
>
> Lukas
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
__________________________
Eduardo Sant'Ana da Silva - Dr.
Pesquisador / Consultor de TI


From fjuma at redhat.com  Mon Jun 15 14:48:50 2015
From: fjuma at redhat.com (Farah Juma)
Date: Mon, 15 Jun 2015 14:48:50 -0400 (EDT)
Subject: [wildfly-dev] WildFly 9.0.0.CR2 is now on OpenShift
In-Reply-To: <1396665362.17980424.1434393907342.JavaMail.zimbra@redhat.com>
Message-ID: <887737387.17981100.1434394130797.JavaMail.zimbra@redhat.com>

As usual, see https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/wildfly-9 to get started.


From ssilvert at redhat.com  Tue Jun 16 08:18:30 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 16 Jun 2015 08:18:30 -0400
Subject: [wildfly-dev] [keycloak-dev] 2 places to edit modules now?
In-Reply-To: <557F30BA.5070700@redhat.com>
References: <557F30BA.5070700@redhat.com>
Message-ID: <55801416.7050503@redhat.com>

Cross-posting to wildfly-dev.

It sounds like we need a way to standardize module.xml definitions 
across projects and have them accessible from maven GAV's.   These 
module.xml files are rarely different between projects and it doesn't 
make sense for each feature pack to define its own copy.

On 6/15/2015 4:08 PM, Bill Burke wrote:
> Module definition is now done in 3 places?  Copies of one another?
>
> eap6-service-overlay
> server-feature-pack
> adapter-feature-pack
>
> This is very very error prone guys.  I guarantee somebody will forget to
> update something.
>
>


From tomaz.cerar at gmail.com  Tue Jun 16 08:36:27 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 16 Jun 2015 14:36:27 +0200
Subject: [wildfly-dev] [keycloak-dev] 2 places to edit modules now?
In-Reply-To: <55801416.7050503@redhat.com>
References: <557F30BA.5070700@redhat.com>
	<55801416.7050503@redhat.com>
Message-ID: <CAMquZP427YXr=02Pe0ZtS7baESdxQT3_yyqHmLt0p-2i_NdK+w@mail.gmail.com>

A feature-pack can extend another feature pack,
I am sure you guys know that.

so you could have "keycloak-base" feature pack that all other 3 extend.

the base would than have all common modules defined.
and other 3 extra specializations.

--
tomaz

On Tue, Jun 16, 2015 at 2:18 PM, Stan Silvert <ssilvert at redhat.com> wrote:

> Cross-posting to wildfly-dev.
>
> It sounds like we need a way to standardize module.xml definitions
> across projects and have them accessible from maven GAV's.   These
> module.xml files are rarely different between projects and it doesn't
> make sense for each feature pack to define its own copy.
>
> On 6/15/2015 4:08 PM, Bill Burke wrote:
> > Module definition is now done in 3 places?  Copies of one another?
> >
> > eap6-service-overlay
> > server-feature-pack
> > adapter-feature-pack
> >
> > This is very very error prone guys.  I guarantee somebody will forget to
> > update something.
> >
> >
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150616/99747ec1/attachment-0001.html 

From mohlek at gmail.com  Tue Jun 16 08:41:40 2015
From: mohlek at gmail.com (Maurice Mohlek)
Date: Tue, 16 Jun 2015 14:41:40 +0200
Subject: [wildfly-dev] web console messed up
Message-ID: <CAHVKusqN96OsW1_vc9EcmTe8ehOVrMDqFnt9N9FnF7g3YAb8WQ@mail.gmail.com>

On my wildfly 9 CR2  the web console is all messed up.

labels are overlapping, some buttons arn't working and the reload
button is gone.
The web console looks like a mobile site which is quiet annoying.

Do you have the same problems?

If yes how could this pass the quality checks? I mean the web console
is nearly useless now.

Greetings,
maurice

From hpehl at redhat.com  Tue Jun 16 08:45:48 2015
From: hpehl at redhat.com (Harald Pehl)
Date: Tue, 16 Jun 2015 14:45:48 +0200
Subject: [wildfly-dev] web console messed up
In-Reply-To: <CAHVKusqN96OsW1_vc9EcmTe8ehOVrMDqFnt9N9FnF7g3YAb8WQ@mail.gmail.com>
References: <CAHVKusqN96OsW1_vc9EcmTe8ehOVrMDqFnt9N9FnF7g3YAb8WQ@mail.gmail.com>
Message-ID: <16D4F1FE-9BC1-49B1-BAAA-859E57D51E44@redhat.com>

Can you provide some more details? What browser are you using? Can you click on the version number in the lower left corner of the console and report the version numbers shown there?

Thanks
Harald

> Am 16.06.2015 um 14:41 schrieb Maurice Mohlek <mohlek at gmail.com>:
> 
> On my wildfly 9 CR2  the web console is all messed up.
> 
> labels are overlapping, some buttons arn't working and the reload
> button is gone.
> The web console looks like a mobile site which is quiet annoying.
> 
> Do you have the same problems?
> 
> If yes how could this pass the quality checks? I mean the web console
> is nearly useless now.
> 
> Greetings,
> maurice
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

---
Harald Pehl
JBoss by Red Hat
http://hpehl.info



From hbraun at redhat.com  Tue Jun 16 08:49:53 2015
From: hbraun at redhat.com (Heiko Braun)
Date: Tue, 16 Jun 2015 14:49:53 +0200
Subject: [wildfly-dev] web console messed up
In-Reply-To: <CAHVKusqN96OsW1_vc9EcmTe8ehOVrMDqFnt9N9FnF7g3YAb8WQ@mail.gmail.com>
References: <CAHVKusqN96OsW1_vc9EcmTe8ehOVrMDqFnt9N9FnF7g3YAb8WQ@mail.gmail.com>
Message-ID: <DB6284BA-086A-47D4-AD31-4557F6C8C577@redhat.com>


To me this sounds like the some artefacts (i.e. css) are not fully loaded. Try to clear your browser cache and reload. In any case we would need to know the browser/os combination you are using.

Regards, Heiko


> On 16 Jun 2015, at 14:41, Maurice Mohlek <mohlek at gmail.com> wrote:
> 
> On my wildfly 9 CR2  the web console is all messed up.
> 
> labels are overlapping, some buttons arn't working and the reload
> button is gone.
> The web console looks like a mobile site which is quiet annoying.
> 
> Do you have the same problems?
> 
> If yes how could this pass the quality checks? I mean the web console
> is nearly useless now.
> 
> Greetings,
> maurice
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From belaran at redhat.com  Tue Jun 16 08:50:27 2015
From: belaran at redhat.com (Romain PELISSE)
Date: Tue, 16 Jun 2015 14:50:27 +0200
Subject: [wildfly-dev] web console messed up
In-Reply-To: <16D4F1FE-9BC1-49B1-BAAA-859E57D51E44@redhat.com>
References: <CAHVKusqN96OsW1_vc9EcmTe8ehOVrMDqFnt9N9FnF7g3YAb8WQ@mail.gmail.com>
	<16D4F1FE-9BC1-49B1-BAAA-859E57D51E44@redhat.com>
Message-ID: <20150616125027.GF2375@august.redhat.com>

Never assume whatever is render is render the same everywhere else ;) -
so could you provide a screenshot ?

On Tue, Jun 16, 2015 at 02:45:48PM +0200, Harald Pehl wrote:
> Can you provide some more details? What browser are you using? Can you click on the version number in the lower left corner of the console and report the version numbers shown there?
>
> Thanks
> Harald
>
> > Am 16.06.2015 um 14:41 schrieb Maurice Mohlek <mohlek at gmail.com>:
> >
> > On my wildfly 9 CR2  the web console is all messed up.
> >
> > labels are overlapping, some buttons arn't working and the reload
> > button is gone.
> > The web console looks like a mobile site which is quiet annoying.
> >
> > Do you have the same problems?
> >
> > If yes how could this pass the quality checks? I mean the web console
> > is nearly useless now.
> >
> > Greetings,
> > maurice
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> ---
> Harald Pehl
> JBoss by Red Hat
> http://hpehl.info
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Best Regards,
http://developerblog.redhat.com/author/rpelisse/

Romain PELISSE
Software Engineer
Red Hat GmbH
Zieher Business Centers,
Am Treptower Park 75,
12435 Berlin
Germany
Cell (DE): +49 (0) 172-7442628
Cell (FR): +33 (0) 669304455

Delivering value year after year


Red Hat ranks # 1 in value among software vendors


http://www.redhat.com/promo/vendor/


Freedom...Courage...Commitment...Accountability

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters

From ssilvert at redhat.com  Tue Jun 16 09:24:50 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 16 Jun 2015 09:24:50 -0400
Subject: [wildfly-dev] [keycloak-dev] 2 places to edit modules now?
In-Reply-To: <CAMquZP427YXr=02Pe0ZtS7baESdxQT3_yyqHmLt0p-2i_NdK+w@mail.gmail.com>
References: <557F30BA.5070700@redhat.com> <55801416.7050503@redhat.com>
	<CAMquZP427YXr=02Pe0ZtS7baESdxQT3_yyqHmLt0p-2i_NdK+w@mail.gmail.com>
Message-ID: <558023A2.3080103@redhat.com>

On 6/16/2015 8:36 AM, Toma? Cerar wrote:
> A feature-pack can extend another feature pack,
> I am sure you guys know that.
>
> so you could have "keycloak-base" feature pack that all other 3 extend.
>
> the base would than have all common modules defined.
> and other 3 extra specializations.
That's an OK approach if there is a well-defined base of modules that 
several projects use.   But that's really not the case.

In any feature pack I should be able to just list the artifacts I'm 
using and it provides a default module.xml file for that.
>
> --
> tomaz
>
> On Tue, Jun 16, 2015 at 2:18 PM, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     Cross-posting to wildfly-dev.
>
>     It sounds like we need a way to standardize module.xml definitions
>     across projects and have them accessible from maven GAV's.  These
>     module.xml files are rarely different between projects and it doesn't
>     make sense for each feature pack to define its own copy.
>
>     On 6/15/2015 4:08 PM, Bill Burke wrote:
>     > Module definition is now done in 3 places?  Copies of one another?
>     >
>     > eap6-service-overlay
>     > server-feature-pack
>     > adapter-feature-pack
>     >
>     > This is very very error prone guys.  I guarantee somebody will
>     forget to
>     > update something.
>     >
>     >
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150616/5e01dadb/attachment.html 

From mstrukel at redhat.com  Tue Jun 16 09:48:06 2015
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 16 Jun 2015 09:48:06 -0400 (EDT)
Subject: [wildfly-dev] [keycloak-dev]   2 places to edit modules now?
In-Reply-To: <558023A2.3080103@redhat.com>
References: <557F30BA.5070700@redhat.com> <55801416.7050503@redhat.com>
	<CAMquZP427YXr=02Pe0ZtS7baESdxQT3_yyqHmLt0p-2i_NdK+w@mail.gmail.com>
	<558023A2.3080103@redhat.com>
Message-ID: <1071170582.2821893.1434462486816.JavaMail.zimbra@redhat.com>

I see two issues here ...

1. For Keycloak we are targetting previous wildfly / eap versions as well. Feature packs functionality targets Wildfly 9+ IIUC so we can't use it for previous versions.

2. We support distribution packaging we call overlay distribution ... where all we provide is modules + configuration resources which users simply unzip into existing wildfly / eap directory. I'm not sure feature packs support this at all. For example, can I do a feature pack that only produces a set of modules, and where I can specify which jboss-modules version to target?

Currently we use old school modules generation (ant plugin, build.xml, lib.xml) for previous versions of wildfly / eap, and feature pack for Wildfly 9 where we cheat for overlay distributions by doing full pack and only copy modules from it into our distribution archive.


----- Original Message -----
> On 6/16/2015 8:36 AM, Toma? Cerar wrote:
> 
> 
> 
> A feature-pack can extend another feature pack,
> I am sure you guys know that.
> 
> so you could have "keycloak-base" feature pack that all other 3 extend.
> 
> the base would than have all common modules defined.
> and other 3 extra specializations.
> That's an OK approach if there is a well-defined base of modules that several
> projects use. But that's really not the case.
> 
> In any feature pack I should be able to just list the artifacts I'm using and
> it provides a default module.xml file for that.
> 
> 
> 
> 
> --
> tomaz
> 
> On Tue, Jun 16, 2015 at 2:18 PM, Stan Silvert < ssilvert at redhat.com > wrote:
> 
> 
> Cross-posting to wildfly-dev.
> 
> It sounds like we need a way to standardize module.xml definitions
> across projects and have them accessible from maven GAV's. These
> module.xml files are rarely different between projects and it doesn't
> make sense for each feature pack to define its own copy.
> 
> On 6/15/2015 4:08 PM, Bill Burke wrote:
> > Module definition is now done in 3 places? Copies of one another?
> > 
> > eap6-service-overlay
> > server-feature-pack
> > adapter-feature-pack
> > 
> > This is very very error prone guys. I guarantee somebody will forget to
> > update something.
> > 
> > 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From chaowan at redhat.com  Tue Jun 16 10:30:04 2015
From: chaowan at redhat.com (Chao Wang)
Date: Tue, 16 Jun 2015 22:30:04 +0800
Subject: [wildfly-dev] web console messed up
In-Reply-To: <DB6284BA-086A-47D4-AD31-4557F6C8C577@redhat.com>
References: <CAHVKusqN96OsW1_vc9EcmTe8ehOVrMDqFnt9N9FnF7g3YAb8WQ@mail.gmail.com>
	<DB6284BA-086A-47D4-AD31-4557F6C8C577@redhat.com>
Message-ID: <558032EC.2090602@redhat.com>

On 06/16/2015 08:49 PM, Heiko Braun wrote:
> To me this sounds like the some artefacts (i.e. css) are not fully loaded. Try to clear your browser cache and reload. In any case we would need to know the browser/os combination you are using.
I also saw similar issue in Wildfly9 CR2 with version 2.7.1.Final, 
Fedora 22 + Firefox 38.0.5 and Chrome 43.0.2357.81. Current master 
2.8.0.Alpha0 looks like the same.

> Regards, Heiko
>
>
>> On 16 Jun 2015, at 14:41, Maurice Mohlek<mohlek at gmail.com>  wrote:
>>
>> On my wildfly 9 CR2  the web console is all messed up.
>>
>> labels are overlapping, some buttons arn't working and the reload
>> button is gone.
>> The web console looks like a mobile site which is quiet annoying.
>>
>> Do you have the same problems?
>>
>> If yes how could this pass the quality checks? I mean the web console
>> is nearly useless now.
>>
>> Greetings,
>> maurice
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


-- 
Chao Wang
Software Engineer
JBoss by Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150616/108fb180/attachment.html 

From hbraun at redhat.com  Tue Jun 16 10:34:14 2015
From: hbraun at redhat.com (Heiko Braun)
Date: Tue, 16 Jun 2015 16:34:14 +0200
Subject: [wildfly-dev] web console messed up
In-Reply-To: <558032EC.2090602@redhat.com>
References: <CAHVKusqN96OsW1_vc9EcmTe8ehOVrMDqFnt9N9FnF7g3YAb8WQ@mail.gmail.com>
	<DB6284BA-086A-47D4-AD31-4557F6C8C577@redhat.com>
	<558032EC.2090602@redhat.com>
Message-ID: <F388EB08-F00C-42EB-BA6D-11393379F62A@redhat.com>


A similar issue, you mean broken layouts? 
Did clearing the cache help? 
Can you provide a screenshot?

Regards, Heiko


> On 16 Jun 2015, at 16:30, Chao Wang <chaowan at redhat.com> wrote:
> 
> On 06/16/2015 08:49 PM, Heiko Braun wrote:
>> To me this sounds like the some artefacts (i.e. css) are not fully loaded. Try to clear your browser cache and reload. In any case we would need to know the browser/os combination you are using.
> I also saw similar issue in Wildfly9 CR2 with version 2.7.1.Final, Fedora 22 + Firefox 38.0.5 and Chrome 43.0.2357.81. Current master 2.8.0.Alpha0 looks like the same.
> 
>> Regards, Heiko
>> 
>> 
>>> On 16 Jun 2015, at 14:41, Maurice Mohlek <mohlek at gmail.com> <mailto:mohlek at gmail.com> wrote:
>>> 
>>> On my wildfly 9 CR2  the web console is all messed up.
>>> 
>>> labels are overlapping, some buttons arn't working and the reload
>>> button is gone.
>>> The web console looks like a mobile site which is quiet annoying.
>>> 
>>> Do you have the same problems?
>>> 
>>> If yes how could this pass the quality checks? I mean the web console
>>> is nearly useless now.
>>> 
>>> Greetings,
>>> maurice
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> 
> 
> -- 
> Chao Wang
> Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150616/f7bdf3f2/attachment-0001.html 

From hbraun at redhat.com  Tue Jun 16 10:42:59 2015
From: hbraun at redhat.com (Heiko Braun)
Date: Tue, 16 Jun 2015 16:42:59 +0200
Subject: [wildfly-dev] Fwd:  web console messed up
References: <558034F4.6010401@redhat.com>
Message-ID: <A0962526-DCBF-4D0A-A436-A0769C5D7A8E@redhat.com>



> Begin forwarded message:
> 
> From: Chao Wang <chaowan at redhat.com>
> Subject: Re: [wildfly-dev] web console messed up
> Date: 16 Jun 2015 16:38:44 CEST
> To: Heiko Braun <hbraun at redhat.com>
> 
> On 06/16/2015 10:34 PM, Heiko Braun wrote:
>> 
>> A similar issue, you mean broken layouts? 
>> Did clearing the cache help? 
>> Can you provide a screenshot?
> Yes, it seems broken. I have tried to clear browsing data for the past day. It did not help.
> please check attachments files with Firefox screenshot.
>> 
>> Regards, Heiko
>> 
>> 
>>> On 16 Jun 2015, at 16:30, Chao Wang <chaowan at redhat.com <mailto:chaowan at redhat.com>> wrote:
>>> 
>>> On 06/16/2015 08:49 PM, Heiko Braun wrote:
>>>> To me this sounds like the some artefacts (i.e. css) are not fully loaded. Try to clear your browser cache and reload. In any case we would need to know the browser/os combination you are using.
>>> I also saw similar issue in Wildfly9 CR2 with version 2.7.1.Final, Fedora 22 + Firefox 38.0.5 and Chrome 43.0.2357.81. Current master 2.8.0.Alpha0 looks like the same.
>>> 
>>>> Regards, Heiko
>>>> 
>>>> 
>>>>> On 16 Jun 2015, at 14:41, Maurice Mohlek <mohlek at gmail.com> <mailto:mohlek at gmail.com> wrote:
>>>>> 
>>>>> On my wildfly 9 CR2  the web console is all messed up.
>>>>> 
>>>>> labels are overlapping, some buttons arn't working and the reload
>>>>> button is gone.
>>>>> The web console looks like a mobile site which is quiet annoying.
>>>>> 
>>>>> Do you have the same problems?
>>>>> 
>>>>> If yes how could this pass the quality checks? I mean the web console
>>>>> is nearly useless now.
>>>>> 
>>>>> Greetings,
>>>>> maurice
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>> 
>>> 
>>> -- 
>>> Chao Wang
>>> Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> 
> 
> -- 
> Chao Wang
> Software Engineer
> JBoss by Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150616/7d26dd69/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conole.jpeg.png
Type: image/png
Size: 43827 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150616/7d26dd69/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: console-2.8.0.Alpha0.png
Type: image/png
Size: 35115 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150616/7d26dd69/attachment-0003.png 

From hbraun at redhat.com  Tue Jun 16 10:44:09 2015
From: hbraun at redhat.com (Heiko Braun)
Date: Tue, 16 Jun 2015 16:44:09 +0200
Subject: [wildfly-dev] web console messed up
In-Reply-To: <A0962526-DCBF-4D0A-A436-A0769C5D7A8E@redhat.com>
References: <558034F4.6010401@redhat.com>
	<A0962526-DCBF-4D0A-A436-A0769C5D7A8E@redhat.com>
Message-ID: <E80A3E49-DF0A-4D9E-A6AA-E8B391B1BEF9@redhat.com>

thanks chao.

@maurice what browser/os are you using?

> On 16 Jun 2015, at 16:42, Heiko Braun <hbraun at redhat.com> wrote:
> 
> 
> 
>> Begin forwarded message:
>> 
>> From: Chao Wang <chaowan at redhat.com <mailto:chaowan at redhat.com>>
>> Subject: Re: [wildfly-dev] web console messed up
>> Date: 16 Jun 2015 16:38:44 CEST
>> To: Heiko Braun <hbraun at redhat.com <mailto:hbraun at redhat.com>>
>> 
>> On 06/16/2015 10:34 PM, Heiko Braun wrote:
>>> 
>>> A similar issue, you mean broken layouts? 
>>> Did clearing the cache help? 
>>> Can you provide a screenshot?
>> Yes, it seems broken. I have tried to clear browsing data for the past day. It did not help.
>> please check attachments files with Firefox screenshot.
>>> 
>>> Regards, Heiko
>>> 
>>> 
>>>> On 16 Jun 2015, at 16:30, Chao Wang <chaowan at redhat.com <mailto:chaowan at redhat.com>> wrote:
>>>> 
>>>> On 06/16/2015 08:49 PM, Heiko Braun wrote:
>>>>> To me this sounds like the some artefacts (i.e. css) are not fully loaded. Try to clear your browser cache and reload. In any case we would need to know the browser/os combination you are using.
>>>> I also saw similar issue in Wildfly9 CR2 with version 2.7.1.Final, Fedora 22 + Firefox 38.0.5 and Chrome 43.0.2357.81. Current master 2.8.0.Alpha0 looks like the same.
>>>> 
>>>>> Regards, Heiko
>>>>> 
>>>>> 
>>>>>> On 16 Jun 2015, at 14:41, Maurice Mohlek <mohlek at gmail.com> <mailto:mohlek at gmail.com> wrote:
>>>>>> 
>>>>>> On my wildfly 9 CR2  the web console is all messed up.
>>>>>> 
>>>>>> labels are overlapping, some buttons arn't working and the reload
>>>>>> button is gone.
>>>>>> The web console looks like a mobile site which is quiet annoying.
>>>>>> 
>>>>>> Do you have the same problems?
>>>>>> 
>>>>>> If yes how could this pass the quality checks? I mean the web console
>>>>>> is nearly useless now.
>>>>>> 
>>>>>> Greetings,
>>>>>> maurice
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>> 
>>>> 
>>>> -- 
>>>> Chao Wang
>>>> Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>> 
>> 
>> -- 
>> Chao Wang
>> Software Engineer
>> JBoss by Red Hat
>> <conole.jpeg.png><console-2.8.0.Alpha0.png>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150616/3f9121eb/attachment.html 

From hbraun at redhat.com  Tue Jun 16 10:53:35 2015
From: hbraun at redhat.com (Heiko Braun)
Date: Tue, 16 Jun 2015 16:53:35 +0200
Subject: [wildfly-dev] Fwd:  web console messed up
References: <CAHVKusqfYj1zGUhRHFTYKwktZbsEc0g3Spj01PO2SQ4bPGRhSw@mail.gmail.com>
Message-ID: <802B04B7-7EB1-4B06-83C9-90B316B3F11E@redhat.com>


FYI https://issues.jboss.org/browse/HAL-694 <https://issues.jboss.org/browse/HAL-694>

> Begin forwarded message:
> 
> From: Maurice Mohlek <mohlek at gmail.com>
> Subject: Re: [wildfly-dev] web console messed up
> Date: 16 Jun 2015 16:47:48 CEST
> To: Heiko Braun <hbraun at redhat.com>
> 
> Firefox 38 on CentOS 7
> 
> Heiko Braun <hbraun at redhat.com <mailto:hbraun at redhat.com>> schrieb am Di., 16. Juni 2015 16:44:
> thanks chao.
> 
> @maurice what browser/os are you using?
> 
> 
>> On 16 Jun 2015, at 16:42, Heiko Braun <hbraun at redhat.com <mailto:hbraun at redhat.com>> wrote:
>> 
> 
>>> Begin forwarded message:
>>> 
>>> From: Chao Wang <chaowan at redhat.com <mailto:chaowan at redhat.com>>
>>> Subject: Re: [wildfly-dev] web console messed up
>>> Date: 16 Jun 2015 16:38:44 CEST
>>> To: Heiko Braun <hbraun at redhat.com <mailto:hbraun at redhat.com>>
>>> 
> 
>>> On 06/16/2015 10:34 PM, Heiko Braun wrote:
>>>> 
>>>> A similar issue, you mean broken layouts? 
>>>> Did clearing the cache help? 
>>>> Can you provide a screenshot?
>>> Yes, it seems broken. I have tried to clear browsing data for the past day. It did not help.
>>> please check attachments files with Firefox screenshot.
>>>> 
>>>> Regards, Heiko
>>>> 
>>>> 
>>>>> On 16 Jun 2015, at 16:30, Chao Wang <chaowan at redhat.com <mailto:chaowan at redhat.com>> wrote:
>>>>> 
>>>>> On 06/16/2015 08:49 PM, Heiko Braun wrote:
>>>>>> To me this sounds like the some artefacts (i.e. css) are not fully loaded. Try to clear your browser cache and reload. In any case we would need to know the browser/os combination you are using.
>>>>> I also saw similar issue in Wildfly9 CR2 with version 2.7.1.Final, Fedora 22 + Firefox 38.0.5 and Chrome 43.0.2357.81. Current master 2.8.0.Alpha0 looks like the same.
>>>>> 
>>>>>> Regards, Heiko
>>>>>> 
>>>>>> 
>>>>>>> On 16 Jun 2015, at 14:41, Maurice Mohlek <mohlek at gmail.com> <mailto:mohlek at gmail.com> wrote:
>>>>>>> 
>>>>>>> On my wildfly 9 CR2  the web console is all messed up.
>>>>>>> 
>>>>>>> labels are overlapping, some buttons arn't working and the reload
>>>>>>> button is gone.
>>>>>>> The web console looks like a mobile site which is quiet annoying.
>>>>>>> 
>>>>>>> Do you have the same problems?
>>>>>>> 
>>>>>>> If yes how could this pass the quality checks? I mean the web console
>>>>>>> is nearly useless now.
>>>>>>> 
>>>>>>> Greetings,
>>>>>>> maurice
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Chao Wang
>>>>> Software Engineer
>>>>> JBoss by Red Hat
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>> 
>>> 
>>> -- 
>>> Chao Wang
>>> Software Engineer
>>> JBoss by Red Hat
> 
>>> <conole.jpeg.png><console-2.8.0.Alpha0.png>
>> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150616/e0bc5e5d/attachment-0001.html 

From hbraun at redhat.com  Tue Jun 16 11:46:19 2015
From: hbraun at redhat.com (Heiko Braun)
Date: Tue, 16 Jun 2015 17:46:19 +0200
Subject: [wildfly-dev] web console messed up
In-Reply-To: <802B04B7-7EB1-4B06-83C9-90B316B3F11E@redhat.com>
References: <CAHVKusqfYj1zGUhRHFTYKwktZbsEc0g3Spj01PO2SQ4bPGRhSw@mail.gmail.com>
	<802B04B7-7EB1-4B06-83C9-90B316B3F11E@redhat.com>
Message-ID: <89C7CF1C-8359-46C6-B8FF-EE6B6A8D063E@redhat.com>


@Maurice: We have problems reproducing the issue on linux/ff38. can you confirm that you?ve cleared the browser cache and the problem still exists?

Regards, Heiko

> On 16 Jun 2015, at 16:53, Heiko Braun <hbraun at redhat.com> wrote:
> 
> 
> FYI https://issues.jboss.org/browse/HAL-694 <https://issues.jboss.org/browse/HAL-694>
> 
>> Begin forwarded message:
>> 
>> From: Maurice Mohlek <mohlek at gmail.com <mailto:mohlek at gmail.com>>
>> Subject: Re: [wildfly-dev] web console messed up
>> Date: 16 Jun 2015 16:47:48 CEST
>> To: Heiko Braun <hbraun at redhat.com <mailto:hbraun at redhat.com>>
>> 
>> Firefox 38 on CentOS 7
>> 
>> Heiko Braun <hbraun at redhat.com <mailto:hbraun at redhat.com>> schrieb am Di., 16. Juni 2015 16:44:
>> thanks chao.
>> 
>> @maurice what browser/os are you using?
>> 
>> 
>>> On 16 Jun 2015, at 16:42, Heiko Braun <hbraun at redhat.com <mailto:hbraun at redhat.com>> wrote:
>>> 
>> 
>>>> Begin forwarded message:
>>>> 
>>>> From: Chao Wang <chaowan at redhat.com <mailto:chaowan at redhat.com>>
>>>> Subject: Re: [wildfly-dev] web console messed up
>>>> Date: 16 Jun 2015 16:38:44 CEST
>>>> To: Heiko Braun <hbraun at redhat.com <mailto:hbraun at redhat.com>>
>>>> 
>> 
>>>> On 06/16/2015 10:34 PM, Heiko Braun wrote:
>>>>> 
>>>>> A similar issue, you mean broken layouts? 
>>>>> Did clearing the cache help? 
>>>>> Can you provide a screenshot?
>>>> Yes, it seems broken. I have tried to clear browsing data for the past day. It did not help.
>>>> please check attachments files with Firefox screenshot.
>>>>> 
>>>>> Regards, Heiko
>>>>> 
>>>>> 
>>>>>> On 16 Jun 2015, at 16:30, Chao Wang <chaowan at redhat.com <mailto:chaowan at redhat.com>> wrote:
>>>>>> 
>>>>>> On 06/16/2015 08:49 PM, Heiko Braun wrote:
>>>>>>> To me this sounds like the some artefacts (i.e. css) are not fully loaded. Try to clear your browser cache and reload. In any case we would need to know the browser/os combination you are using.
>>>>>> I also saw similar issue in Wildfly9 CR2 with version 2.7.1.Final, Fedora 22 + Firefox 38.0.5 and Chrome 43.0.2357.81. Current master 2.8.0.Alpha0 looks like the same.
>>>>>> 
>>>>>>> Regards, Heiko
>>>>>>> 
>>>>>>> 
>>>>>>>> On 16 Jun 2015, at 14:41, Maurice Mohlek <mohlek at gmail.com> <mailto:mohlek at gmail.com> wrote:
>>>>>>>> 
>>>>>>>> On my wildfly 9 CR2  the web console is all messed up.
>>>>>>>> 
>>>>>>>> labels are overlapping, some buttons arn't working and the reload
>>>>>>>> button is gone.
>>>>>>>> The web console looks like a mobile site which is quiet annoying.
>>>>>>>> 
>>>>>>>> Do you have the same problems?
>>>>>>>> 
>>>>>>>> If yes how could this pass the quality checks? I mean the web console
>>>>>>>> is nearly useless now.
>>>>>>>> 
>>>>>>>> Greetings,
>>>>>>>> maurice
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Chao Wang
>>>>>> Software Engineer
>>>>>> JBoss by Red Hat
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>> 
>>>> 
>>>> -- 
>>>> Chao Wang
>>>> Software Engineer
>>>> JBoss by Red Hat
>> 
>>>> <conole.jpeg.png><console-2.8.0.Alpha0.png>
>>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150616/5d2ccae5/attachment.html 

From hbraun at redhat.com  Tue Jun 16 12:00:06 2015
From: hbraun at redhat.com (Heiko Braun)
Date: Tue, 16 Jun 2015 18:00:06 +0200
Subject: [wildfly-dev] web console messed up
In-Reply-To: <89C7CF1C-8359-46C6-B8FF-EE6B6A8D063E@redhat.com>
References: <CAHVKusqfYj1zGUhRHFTYKwktZbsEc0g3Spj01PO2SQ4bPGRhSw@mail.gmail.com>
	<802B04B7-7EB1-4B06-83C9-90B316B3F11E@redhat.com>
	<89C7CF1C-8359-46C6-B8FF-EE6B6A8D063E@redhat.com>
Message-ID: <00280240-68A1-4C5F-A8A9-B843B0CA10F4@redhat.com>



From Maurice (for the records):

I solved the problem with harald and it was the cache. i had somehow trash from cr1 in the cache. 


> On 16 Jun 2015, at 17:46, Heiko Braun <hbraun at redhat.com> wrote:
> 
> 
> @Maurice: We have problems reproducing the issue on linux/ff38. can you confirm that you?ve cleared the browser cache and the problem still exists?
> 
> Regards, Heiko
> 
>> On 16 Jun 2015, at 16:53, Heiko Braun <hbraun at redhat.com <mailto:hbraun at redhat.com>> wrote:
>> 
>> 
>> FYI https://issues.jboss.org/browse/HAL-694 <https://issues.jboss.org/browse/HAL-694>
>> 
>>> Begin forwarded message:
>>> 
>>> From: Maurice Mohlek <mohlek at gmail.com <mailto:mohlek at gmail.com>>
>>> Subject: Re: [wildfly-dev] web console messed up
>>> Date: 16 Jun 2015 16:47:48 CEST
>>> To: Heiko Braun <hbraun at redhat.com <mailto:hbraun at redhat.com>>
>>> 
>>> Firefox 38 on CentOS 7
>>> 
>>> Heiko Braun <hbraun at redhat.com <mailto:hbraun at redhat.com>> schrieb am Di., 16. Juni 2015 16:44:
>>> thanks chao.
>>> 
>>> @maurice what browser/os are you using?
>>> 
>>> 
>>>> On 16 Jun 2015, at 16:42, Heiko Braun <hbraun at redhat.com <mailto:hbraun at redhat.com>> wrote:
>>>> 
>>> 
>>>>> Begin forwarded message:
>>>>> 
>>>>> From: Chao Wang <chaowan at redhat.com <mailto:chaowan at redhat.com>>
>>>>> Subject: Re: [wildfly-dev] web console messed up
>>>>> Date: 16 Jun 2015 16:38:44 CEST
>>>>> To: Heiko Braun <hbraun at redhat.com <mailto:hbraun at redhat.com>>
>>>>> 
>>> 
>>>>> On 06/16/2015 10:34 PM, Heiko Braun wrote:
>>>>>> 
>>>>>> A similar issue, you mean broken layouts? 
>>>>>> Did clearing the cache help? 
>>>>>> Can you provide a screenshot?
>>>>> Yes, it seems broken. I have tried to clear browsing data for the past day. It did not help.
>>>>> please check attachments files with Firefox screenshot.
>>>>>> 
>>>>>> Regards, Heiko
>>>>>> 
>>>>>> 
>>>>>>> On 16 Jun 2015, at 16:30, Chao Wang <chaowan at redhat.com <mailto:chaowan at redhat.com>> wrote:
>>>>>>> 
>>>>>>> On 06/16/2015 08:49 PM, Heiko Braun wrote:
>>>>>>>> To me this sounds like the some artefacts (i.e. css) are not fully loaded. Try to clear your browser cache and reload. In any case we would need to know the browser/os combination you are using.
>>>>>>> I also saw similar issue in Wildfly9 CR2 with version 2.7.1.Final, Fedora 22 + Firefox 38.0.5 and Chrome 43.0.2357.81. Current master 2.8.0.Alpha0 looks like the same.
>>>>>>> 
>>>>>>>> Regards, Heiko
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 16 Jun 2015, at 14:41, Maurice Mohlek <mohlek at gmail.com> <mailto:mohlek at gmail.com> wrote:
>>>>>>>>> 
>>>>>>>>> On my wildfly 9 CR2  the web console is all messed up.
>>>>>>>>> 
>>>>>>>>> labels are overlapping, some buttons arn't working and the reload
>>>>>>>>> button is gone.
>>>>>>>>> The web console looks like a mobile site which is quiet annoying.
>>>>>>>>> 
>>>>>>>>> Do you have the same problems?
>>>>>>>>> 
>>>>>>>>> If yes how could this pass the quality checks? I mean the web console
>>>>>>>>> is nearly useless now.
>>>>>>>>> 
>>>>>>>>> Greetings,
>>>>>>>>> maurice
>>>>>>>>> _______________________________________________
>>>>>>>>> wildfly-dev mailing list
>>>>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> Chao Wang
>>>>>>> Software Engineer
>>>>>>> JBoss by Red Hat
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Chao Wang
>>>>> Software Engineer
>>>>> JBoss by Red Hat
>>> 
>>>>> <conole.jpeg.png><console-2.8.0.Alpha0.png>
>>>> 
>>> 
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150616/d4d457f0/attachment-0001.html 

From brian.stansberry at redhat.com  Tue Jun 16 16:17:06 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 16 Jun 2015 15:17:06 -0500
Subject: [wildfly-dev] Capability naming conventions
In-Reply-To: <21E52078-A52B-4C9E-AA27-B6D4DC088D14@jboss.com>
References: <557B3F78.1090907@redhat.com> <557B4E27.4080708@redhat.com>
	<557B4F9C.1090200@redhat.com>
	<21E52078-A52B-4C9E-AA27-B6D4DC088D14@jboss.com>
Message-ID: <55808442.6070602@redhat.com>

On 6/13/15 4:00 AM, Kabir Khan wrote:
>
>> On 12 Jun 2015, at 22:31, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>
>>>
>>> Sounds good to me.  I'd like to add that internally, we should make sure
>>> we continue to maintain some registry of our org.wildfly name spaces
>>> somewhere (maybe even just a git repository would be OK) so we don't
>>> conflict among ourselves.
>>>
>>
>> Like a text file per capability, with some doc on the capability in the
>> file? Files organized in a tree from the names?
>>
>> That sounds good; much better than some wiki.
> +1
> I don?t know enough about this yet to suggest a format, but having it somewhere in the source is a lot better than a wiki. A wiki brings to mind that horrible log ids page we used for AS 7.

How about this?

https://github.com/bstansberry/wildfly-core/

The README.md explains things pretty clearly.

At this point it just has a couple capabilities; ones added in the PR at

https://github.com/wildfly/wildfly-core/pull/810

That repo has a LICENSE file, which specifies ASL 2.0. I don't know if 
such a thing is really necessary, or if some other license, like 
Creative Commons, is more appropriate.

>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From manderse at redhat.com  Wed Jun 17 07:44:41 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 17 Jun 2015 13:44:41 +0200
Subject: [wildfly-dev] WildFly 9.0.0.CR2 is now on OpenShift
In-Reply-To: <887737387.17981100.1434394130797.JavaMail.zimbra@redhat.com>
References: <887737387.17981100.1434394130797.JavaMail.zimbra@redhat.com>
Message-ID: <38921523-CFCD-4A43-8DD3-D442A9E4DC65@redhat.com>

On 15 Jun 2015, at 20:48, Farah Juma wrote:

> As usual, see 
> https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/wildfly-9 
> to get started.

Very nice.

FYI, might be worth mentioning you can also just install OpenShift tools 
into eclipse and you get this for "free"
since you made this available as part of the quickstarts available to 
openshift v2.

See ![](cid:306F1871-CB5B-4757-A3D6-DE81A6F30E9D at redhat.com 
"New_OpenShift_Application_and_Java_-__Users_max_Documents_workspace_jbosstools-ws__metadata__log_-_Eclipse_-__Users_max_Documents_workspace_jbosstools-ws.png")

/max

>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


/max
http://about.me/maxandersen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: New_OpenShift_Application_and_Java_-__Users_max_Documents_workspace_jbosstools-ws__metadata__log_-_Eclipse_-__Users_max_Documents_workspace_jbosstools-ws.png
Type: image/png
Size: 58251 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150617/fff3d8e2/attachment-0001.png 

From fjuma at redhat.com  Wed Jun 17 10:17:58 2015
From: fjuma at redhat.com (Farah Juma)
Date: Wed, 17 Jun 2015 10:17:58 -0400 (EDT)
Subject: [wildfly-dev] WildFly 9.0.0.CR2 is now on OpenShift
In-Reply-To: <38921523-CFCD-4A43-8DD3-D442A9E4DC65@redhat.com>
References: <887737387.17981100.1434394130797.JavaMail.zimbra@redhat.com>
	<38921523-CFCD-4A43-8DD3-D442A9E4DC65@redhat.com>
Message-ID: <1695997949.19179113.1434550678859.JavaMail.zimbra@redhat.com>

Thanks, Max. I've updated the README.md with this information.

Farah

----- Original Message -----
> From: "Max Rydahl Andersen" <manderse at redhat.com>
> To: "Farah Juma" <fjuma at redhat.com>
> Cc: "WildFly Dev" <wildfly-dev at lists.jboss.org>
> Sent: Wednesday, June 17, 2015 7:44:41 AM
> Subject: Re: [wildfly-dev] WildFly 9.0.0.CR2 is now on OpenShift
> 
> On 15 Jun 2015, at 20:48, Farah Juma wrote:
> 
> > As usual, see
> > https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/wildfly-9
> > to get started.
> 
> Very nice.
> 
> FYI, might be worth mentioning you can also just install OpenShift tools
> into eclipse and you get this for "free"
> since you made this available as part of the quickstarts available to
> openshift v2.
> 
> See ![](cid:306F1871-CB5B-4757-A3D6-DE81A6F30E9D at redhat.com
> "New_OpenShift_Application_and_Java_-__Users_max_Documents_workspace_jbosstools-ws__metadata__log_-_Eclipse_-__Users_max_Documents_workspace_jbosstools-ws.png")
> 
> /max
> 
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> /max
> http://about.me/maxandersen

From johara at redhat.com  Wed Jun 17 10:26:34 2015
From: johara at redhat.com (John O'Hara)
Date: Wed, 17 Jun 2015 15:26:34 +0100
Subject: [wildfly-dev] Module dependencies WF10
Message-ID: <5581839A.2040203@redhat.com>

When I build WF10 in a build env. and move the built app server to a 
different env. I am unable to start WF10.  This is due to the modules 
now resolving jars from the local maven repo. The build process 
downloads and installs the required jars to local maven repo. that are 
not available on the target environment.

Is there a way to either
a) build WF10 and package all the module jars into the build so that it 
is portable,
or b) for the WF10 bootstrap process to download missing packages from a 
remote maven repo on startup where any modules are missing in the local 
repo?

Thanks

-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
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 Michael O'Neill (Ireland).


From david.lloyd at redhat.com  Wed Jun 17 11:05:05 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 17 Jun 2015 10:05:05 -0500
Subject: [wildfly-dev] Module dependencies WF10
In-Reply-To: <5581839A.2040203@redhat.com>
References: <5581839A.2040203@redhat.com>
Message-ID: <55818CA1.1090703@redhat.com>

AFAIK the build app server is not supposed to refer to Maven in the 
final output.  Maybe our build process has gotten munged up somehow?  Or 
else that translation now happens during distribution only?

On 06/17/2015 09:26 AM, John O'Hara wrote:
> When I build WF10 in a build env. and move the built app server to a
> different env. I am unable to start WF10.  This is due to the modules
> now resolving jars from the local maven repo. The build process
> downloads and installs the required jars to local maven repo. that are
> not available on the target environment.
>
> Is there a way to either
> a) build WF10 and package all the module jars into the build so that it
> is portable,
> or b) for the WF10 bootstrap process to download missing packages from a
> remote maven repo on startup where any modules are missing in the local
> repo?
>
> Thanks
>

-- 
- DML

From jai.forums2013 at gmail.com  Wed Jun 17 11:07:34 2015
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 17 Jun 2015 20:37:34 +0530
Subject: [wildfly-dev] Module dependencies WF10
In-Reply-To: <5581839A.2040203@redhat.com>
References: <5581839A.2040203@redhat.com>
Message-ID: <55818D36.1040404@gmail.com>

On Wednesday 17 June 2015 07:56 PM, John O'Hara wrote:
> When I build WF10 in a build env. and move the built app server to a
> different env. I am unable to start WF10.

Are you sure you aren't copying over the distribution from 
WFLY_SRC_CHECKOUT_HOME/build/target/ folder? You should instead be using 
the one from WFLY_SRC_CHECKOUT_HOME/dist/target/

-Jaikiran

>   This is due to the modules
> now resolving jars from the local maven repo. The build process
> downloads and installs the required jars to local maven repo. that are
> not available on the target environment.
>
> Is there a way to either
> a) build WF10 and package all the module jars into the build so that it
> is portable,
> or b) for the WF10 bootstrap process to download missing packages from a
> remote maven repo on startup where any modules are missing in the local
> repo?
>
> Thanks
>


From eduardo.santanadasilva at gmail.com  Wed Jun 17 11:14:19 2015
From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva)
Date: Wed, 17 Jun 2015 12:14:19 -0300
Subject: [wildfly-dev] Module dependencies WF10
In-Reply-To: <5581839A.2040203@redhat.com>
References: <5581839A.2040203@redhat.com>
Message-ID: <EAEF59C4-5ECE-45DF-B2CC-C76D4450E8C1@gmail.com>

But it is happening as John said.
I've just tested, renaming my maven repository in a way that wildlfy could not reach it and I've got:


 ./standalone.sh 
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: .... /Wildfly/Neutral/wildfly-10.0.0.Alpha3-SNAPSHOT

  JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home//bin/java

  JAVA_OPTS:  -server -XX:+UseCompressedOops  -server -XX:+UseCompressedOops -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

Exception in thread "main" org.jboss.modules.ModuleLoadException: Error loading module from /Users/eduardo/Applications/Dev/Servers/Wildfly/Neutral/wildfly-10.0.0.Alpha3-SNAPSHOT/modules/system/layers/base/org/apache/xerces/main/module.xml
	at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:150)
	at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:127)
	at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:150)
	at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:144)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:144)
	at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:452)
	at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:355)
	at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:302)
	at org.jboss.modules.Module.addPaths(Module.java:1028)
	at org.jboss.modules.Module.link(Module.java:1398)
	at org.jboss.modules.Module.relinkIfNecessary(Module.java:1426)
	at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:238)
	at org.jboss.modules.Main.main(Main.java:384)
Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to resolve artifact 'xerces:xercesImpl:2.11.0.SP3' (position: END_TAG seen ...resources>\n        <artifact name="xerces:xercesImpl:2.11.0.SP3"/>... @28:56) 
	at org.jboss.modules.ModuleXmlParser.parseArtifact(ModuleXmlParser.java:756)
	at org.jboss.modules.ModuleXmlParser.parseResources(ModuleXmlParser.java:650)
	at org.jboss.modules.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:446)
	at org.jboss.modules.ModuleXmlParser.parseDocument(ModuleXmlParser.java:261)
	at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:148)
	... 13 more


On Jun 17, 2015, at 11:26 AM, John O'Hara <johara at redhat.com> wrote:

> When I build WF10 in a build env. and move the built app server to a 
> different env. I am unable to start WF10.  This is due to the modules 
> now resolving jars from the local maven repo. The build process 
> downloads and installs the required jars to local maven repo. that are 
> not available on the target environment.
> 
> Is there a way to either
> a) build WF10 and package all the module jars into the build so that it 
> is portable,
> or b) for the WF10 bootstrap process to download missing packages from a 
> remote maven repo on startup where any modules are missing in the local 
> repo?
> 
> Thanks
> 
> -- 
> John O'Hara
> johara at redhat.com
> 
> JBoss, by Red Hat
> 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 Michael O'Neill (Ireland).
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150617/4c776b42/attachment.html 

From jason.greene at redhat.com  Wed Jun 17 11:14:51 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Wed, 17 Jun 2015 11:14:51 -0400 (EDT)
Subject: [wildfly-dev] Module dependencies WF10
In-Reply-To: <55818D36.1040404@gmail.com>
References: <5581839A.2040203@redhat.com> <55818D36.1040404@gmail.com>
Message-ID: <658FA919-C27A-4DE6-8085-533BDC39C6BB@redhat.com>



> On Jun 17, 2015, at 10:08 AM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
> 
>> On Wednesday 17 June 2015 07:56 PM, John O'Hara wrote:
>> When I build WF10 in a build env. and move the built app server to a
>> different env. I am unable to start WF10.
> 
> Are you sure you aren't copying over the distribution from 
> WFLY_SRC_CHECKOUT_HOME/build/target/ folder? You should instead be using 
> the one from WFLY_SRC_CHECKOUT_HOME/dist/target/

Note that you have to build with -Drelease to get that, and also you probably will need to beef up the maven max mem settings as the zip plugin seems to consume massive memory:

MAVEN_OPTS=-Xmx2g mvn clean install -Drelease -DskipTests

I need to fix build.sh so that this is no longer necessary.

> 
> -Jaikiran
> 
>>  This is due to the modules
>> now resolving jars from the local maven repo. The build process
>> downloads and installs the required jars to local maven repo. that are
>> not available on the target environment.
>> 
>> Is there a way to either
>> a) build WF10 and package all the module jars into the build so that it
>> is portable,
>> or b) for the WF10 bootstrap process to download missing packages from a
>> remote maven repo on startup where any modules are missing in the local
>> repo?
>> 
>> Thanks
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From johara at redhat.com  Wed Jun 17 11:15:03 2015
From: johara at redhat.com (John O'Hara)
Date: Wed, 17 Jun 2015 16:15:03 +0100
Subject: [wildfly-dev] Module dependencies WF10
In-Reply-To: <55818D36.1040404@gmail.com>
References: <5581839A.2040203@redhat.com> <55818D36.1040404@gmail.com>
Message-ID: <55818EF7.90604@redhat.com>

On 17/06/15 16:07, Jaikiran Pai wrote:
> On Wednesday 17 June 2015 07:56 PM, John O'Hara wrote:
>> When I build WF10 in a build env. and move the built app server to a
>> different env. I am unable to start WF10.
> Are you sure you aren't copying over the distribution from
> WFLY_SRC_CHECKOUT_HOME/build/target/ folder? You should instead be using
> the one from WFLY_SRC_CHECKOUT_HOME/dist/target/
>
> -Jaikiran
That's what I was doing wrong, knew it would be something simple

Thanks
>>    This is due to the modules
>> now resolving jars from the local maven repo. The build process
>> downloads and installs the required jars to local maven repo. that are
>> not available on the target environment.
>>
>> Is there a way to either
>> a) build WF10 and package all the module jars into the build so that it
>> is portable,
>> or b) for the WF10 bootstrap process to download missing packages from a
>> remote maven repo on startup where any modules are missing in the local
>> repo?
>>
>> Thanks
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
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 Michael O'Neill (Ireland).


From eduardo.santanadasilva at gmail.com  Wed Jun 17 11:17:06 2015
From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva)
Date: Wed, 17 Jun 2015 12:17:06 -0300
Subject: [wildfly-dev] Module dependencies WF10
In-Reply-To: <EAEF59C4-5ECE-45DF-B2CC-C76D4450E8C1@gmail.com>
References: <5581839A.2040203@redhat.com>
	<EAEF59C4-5ECE-45DF-B2CC-C76D4450E8C1@gmail.com>
Message-ID: <B3DD6AA8-87D3-48AD-A2C5-CB5E54660D66@gmail.com>

Sorry, seems that to me the error isn't related.

On Jun 17, 2015, at 12:14 PM, Eduardo Sant'Ana da Silva <eduardo.santanadasilva at gmail.com> wrote:

> But it is happening as John said.
> I've just tested, renaming my maven repository in a way that wildlfy could not reach it and I've got:
> 
> 
>  ./standalone.sh 
> =========================================================================
> 
>   JBoss Bootstrap Environment
> 
>   JBOSS_HOME: .... /Wildfly/Neutral/wildfly-10.0.0.Alpha3-SNAPSHOT
> 
>   JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home//bin/java
> 
>   JAVA_OPTS:  -server -XX:+UseCompressedOops  -server -XX:+UseCompressedOops -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> 
> =========================================================================
> 
> Exception in thread "main" org.jboss.modules.ModuleLoadException: Error loading module from /Users/eduardo/Applications/Dev/Servers/Wildfly/Neutral/wildfly-10.0.0.Alpha3-SNAPSHOT/modules/system/layers/base/org/apache/xerces/main/module.xml
> 	at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:150)
> 	at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:127)
> 	at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:150)
> 	at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:144)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:144)
> 	at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:452)
> 	at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:355)
> 	at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:302)
> 	at org.jboss.modules.Module.addPaths(Module.java:1028)
> 	at org.jboss.modules.Module.link(Module.java:1398)
> 	at org.jboss.modules.Module.relinkIfNecessary(Module.java:1426)
> 	at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:238)
> 	at org.jboss.modules.Main.main(Main.java:384)
> Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to resolve artifact 'xerces:xercesImpl:2.11.0.SP3' (position: END_TAG seen ...resources>\n        <artifact name="xerces:xercesImpl:2.11.0.SP3"/>... @28:56) 
> 	at org.jboss.modules.ModuleXmlParser.parseArtifact(ModuleXmlParser.java:756)
> 	at org.jboss.modules.ModuleXmlParser.parseResources(ModuleXmlParser.java:650)
> 	at org.jboss.modules.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:446)
> 	at org.jboss.modules.ModuleXmlParser.parseDocument(ModuleXmlParser.java:261)
> 	at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:148)
> 	... 13 more
> 
> 
> On Jun 17, 2015, at 11:26 AM, John O'Hara <johara at redhat.com> wrote:
> 
>> When I build WF10 in a build env. and move the built app server to a 
>> different env. I am unable to start WF10.  This is due to the modules 
>> now resolving jars from the local maven repo. The build process 
>> downloads and installs the required jars to local maven repo. that are 
>> not available on the target environment.
>> 
>> Is there a way to either
>> a) build WF10 and package all the module jars into the build so that it 
>> is portable,
>> or b) for the WF10 bootstrap process to download missing packages from a 
>> remote maven repo on startup where any modules are missing in the local 
>> repo?
>> 
>> Thanks
>> 
>> -- 
>> John O'Hara
>> johara at redhat.com
>> 
>> JBoss, by Red Hat
>> 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 Michael O'Neill (Ireland).
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150617/03f28cea/attachment.html 

From jai.forums2013 at gmail.com  Wed Jun 17 11:17:49 2015
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 17 Jun 2015 20:47:49 +0530
Subject: [wildfly-dev] Module dependencies WF10
In-Reply-To: <658FA919-C27A-4DE6-8085-533BDC39C6BB@redhat.com>
References: <5581839A.2040203@redhat.com> <55818D36.1040404@gmail.com>
	<658FA919-C27A-4DE6-8085-533BDC39C6BB@redhat.com>
Message-ID: <55818F9D.5040705@gmail.com>

Hi Jason,

On Wednesday 17 June 2015 08:44 PM, Jason T. Greene wrote:
>
>> On Jun 17, 2015, at 10:08 AM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>>
>>> On Wednesday 17 June 2015 07:56 PM, John O'Hara wrote:
>>> When I build WF10 in a build env. and move the built app server to a
>>> different env. I am unable to start WF10.
>> Are you sure you aren't copying over the distribution from
>> WFLY_SRC_CHECKOUT_HOME/build/target/ folder? You should instead be using
>> the one from WFLY_SRC_CHECKOUT_HOME/dist/target/
> Note that you have to build with -Drelease to get that, and also you probably will need to beef up the maven max mem settings as the zip plugin seems to consume massive memory:

I just do:

mvn clean install -DskipTests=true

(and sometimes without skipTests) and it generates the binary in the 
dist/target just fine. By fine, I mean, I have been able to use that 
binary as if I download it from the WildFly downloads.

The one in the build/target folder though, I always run into the same 
issues as others have noted here, even when I have full access to the 
Maven repo (just like I did while building).

-Jaikiran




>
> MAVEN_OPTS=-Xmx2g mvn clean install -Drelease -DskipTests
>
> I need to fix build.sh so that this is no longer necessary.
>
>> -Jaikiran
>>
>>>   This is due to the modules
>>> now resolving jars from the local maven repo. The build process
>>> downloads and installs the required jars to local maven repo. that are
>>> not available on the target environment.
>>>
>>> Is there a way to either
>>> a) build WF10 and package all the module jars into the build so that it
>>> is portable,
>>> or b) for the WF10 bootstrap process to download missing packages from a
>>> remote maven repo on startup where any modules are missing in the local
>>> repo?
>>>
>>> Thanks
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From johara at redhat.com  Wed Jun 17 11:18:33 2015
From: johara at redhat.com (John O'Hara)
Date: Wed, 17 Jun 2015 16:18:33 +0100
Subject: [wildfly-dev] Module dependencies WF10
In-Reply-To: <55818D36.1040404@gmail.com>
References: <5581839A.2040203@redhat.com> <55818D36.1040404@gmail.com>
Message-ID: <55818FC9.7050604@redhat.com>

On 17/06/15 16:07, Jaikiran Pai wrote:
> On Wednesday 17 June 2015 07:56 PM, John O'Hara wrote:
>> When I build WF10 in a build env. and move the built app server to a
>> different env. I am unable to start WF10.
> Are you sure you aren't copying over the distribution from
> WFLY_SRC_CHECKOUT_HOME/build/target/ folder? You should instead be using
> the one from WFLY_SRC_CHECKOUT_HOME/dist/target/
>
> -Jaikiran
>
>>    This is due to the modules
>> now resolving jars from the local maven repo. The build process
>> downloads and installs the required jars to local maven repo. that are
>> not available on the target environment.
>>
>> Is there a way to either
>> a) build WF10 and package all the module jars into the build so that it
>> is portable,
>> or b) for the WF10 bootstrap process to download missing packages from a
>> remote maven repo on startup where any modules are missing in the local
>> repo?
>>
>> Thanks
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
Is this something that has changed since WF8? I might be wrong, but I am 
certain i used to grab the build from build/target before?
(I have not tried this with WF9)

-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
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 Michael O'Neill (Ireland).


From johara at redhat.com  Wed Jun 17 11:20:33 2015
From: johara at redhat.com (John O'Hara)
Date: Wed, 17 Jun 2015 16:20:33 +0100
Subject: [wildfly-dev] Module dependencies WF10
In-Reply-To: <B3DD6AA8-87D3-48AD-A2C5-CB5E54660D66@gmail.com>
References: <5581839A.2040203@redhat.com>
	<EAEF59C4-5ECE-45DF-B2CC-C76D4450E8C1@gmail.com>
	<B3DD6AA8-87D3-48AD-A2C5-CB5E54660D66@gmail.com>
Message-ID: <55819041.4020000@redhat.com>

That was the error i was seeing, the xerces:xercesImpl:2.11.0.SP3 
artifact was not on the target environment

On 17/06/15 16:17, Eduardo Sant'Ana da Silva wrote:
> Sorry, seems that to me the error isn't related.
>
> On Jun 17, 2015, at 12:14 PM, Eduardo Sant'Ana da Silva 
> <eduardo.santanadasilva at gmail.com 
> <mailto:eduardo.santanadasilva at gmail.com>> wrote:
>
>> But it is happening as John said.
>> I've just tested, renaming my maven repository in a way that wildlfy 
>> could not reach it and I've got:
>>
>>
>>  ./standalone.sh
>> =========================================================================
>>
>>   JBoss Bootstrap Environment
>>
>> JBOSS_HOME: .... /Wildfly/Neutral/wildfly-10.0.0.Alpha3-SNAPSHOT
>>
>>   JAVA: 
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home//bin/java
>>
>> JAVA_OPTS:  -server -XX:+UseCompressedOops  -server 
>> -XX:+UseCompressedOops -Xms64m -Xmx512m 
>> -Djava.net.preferIPv4Stack=true 
>> -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
>>
>> =========================================================================
>>
>> Exception in thread "main" org.jboss.modules.ModuleLoadException: 
>> Error loading module from 
>> /Users/eduardo/Applications/Dev/Servers/Wildfly/Neutral/wildfly-10.0.0.Alpha3-SNAPSHOT/modules/system/layers/base/org/apache/xerces/main/module.xml
>> at 
>> org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:150)
>> at 
>> org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:127)
>> at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:150)
>> at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:144)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at 
>> org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:144)
>> at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:452)
>> at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:355)
>> at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:302)
>> at org.jboss.modules.Module.addPaths(Module.java:1028)
>> at org.jboss.modules.Module.link(Module.java:1398)
>> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1426)
>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:238)
>> at org.jboss.modules.Main.main(Main.java:384)
>> Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to 
>> resolve artifact 'xerces:xercesImpl:2.11.0.SP3' (position: END_TAG 
>> seen ...resources>\n <artifact 
>> name="xerces:xercesImpl:2.11.0.SP3"/>... @28:56)
>> at 
>> org.jboss.modules.ModuleXmlParser.parseArtifact(ModuleXmlParser.java:756)
>> at 
>> org.jboss.modules.ModuleXmlParser.parseResources(ModuleXmlParser.java:650)
>> at 
>> org.jboss.modules.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:446)
>> at 
>> org.jboss.modules.ModuleXmlParser.parseDocument(ModuleXmlParser.java:261)
>> at 
>> org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:148)
>> ... 13 more
>>
>>
>> On Jun 17, 2015, at 11:26 AM, John O'Hara <johara at redhat.com 
>> <mailto:johara at redhat.com>> wrote:
>>
>>> When I build WF10 in a build env. and move the built app server to a
>>> different env. I am unable to start WF10.  This is due to the modules
>>> now resolving jars from the local maven repo. The build process
>>> downloads and installs the required jars to local maven repo. that are
>>> not available on the target environment.
>>>
>>> Is there a way to either
>>> a) build WF10 and package all the module jars into the build so that it
>>> is portable,
>>> or b) for the WF10 bootstrap process to download missing packages 
>>> from a
>>> remote maven repo on startup where any modules are missing in the local
>>> repo?
>>>
>>> Thanks
>>>
>>> -- 
>>> John O'Hara
>>> johara at redhat.com <mailto:johara at redhat.com>
>>>
>>> JBoss, by Red Hat
>>> 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 Michael O'Neill (Ireland).
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>


-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
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 Michael O'Neill (Ireland).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150617/a47e7371/attachment-0001.html 

From eduardo.santanadasilva at gmail.com  Wed Jun 17 11:23:34 2015
From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva)
Date: Wed, 17 Jun 2015 12:23:34 -0300
Subject: [wildfly-dev] Module dependencies WF10
In-Reply-To: <55819041.4020000@redhat.com>
References: <5581839A.2040203@redhat.com>
	<EAEF59C4-5ECE-45DF-B2CC-C76D4450E8C1@gmail.com>
	<B3DD6AA8-87D3-48AD-A2C5-CB5E54660D66@gmail.com>
	<55819041.4020000@redhat.com>
Message-ID: <0BDD8854-77D6-4D4D-9559-3E664863B779@gmail.com>

I thought that was my mistake, because I've renamed back the maven repository and the errors still the same.

On Jun 17, 2015, at 12:20 PM, John O'Hara <johara at redhat.com> wrote:

> That was the error i was seeing, the xerces:xercesImpl:2.11.0.SP3 artifact was not on the target environment
> 
> On 17/06/15 16:17, Eduardo Sant'Ana da Silva wrote:
>> Sorry, seems that to me the error isn't related.
>> 
>> On Jun 17, 2015, at 12:14 PM, Eduardo Sant'Ana da Silva <eduardo.santanadasilva at gmail.com> wrote:
>> 
>>> But it is happening as John said.
>>> I've just tested, renaming my maven repository in a way that wildlfy could not reach it and I've got:
>>> 
>>> 
>>>  ./standalone.sh 
>>> =========================================================================
>>> 
>>>   JBoss Bootstrap Environment
>>> 
>>>   JBOSS_HOME: .... /Wildfly/Neutral/wildfly-10.0.0.Alpha3-SNAPSHOT
>>> 
>>>   JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home//bin/java
>>> 
>>>   JAVA_OPTS:  -server -XX:+UseCompressedOops  -server -XX:+UseCompressedOops -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
>>> 
>>> =========================================================================
>>> 
>>> Exception in thread "main" org.jboss.modules.ModuleLoadException: Error loading module from /Users/eduardo/Applications/Dev/Servers/Wildfly/Neutral/wildfly-10.0.0.Alpha3-SNAPSHOT/modules/system/layers/base/org/apache/xerces/main/module.xml
>>>  at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:150)
>>>  at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:127)
>>>  at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:150)
>>>  at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:144)
>>>  at java.security.AccessController.doPrivileged(Native Method)
>>>  at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:144)
>>>  at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:452)
>>>  at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:355)
>>>  at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:302)
>>>  at org.jboss.modules.Module.addPaths(Module.java:1028)
>>>  at org.jboss.modules.Module.link(Module.java:1398)
>>>  at org.jboss.modules.Module.relinkIfNecessary(Module.java:1426)
>>>  at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:238)
>>>  at org.jboss.modules.Main.main(Main.java:384)
>>> Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to resolve artifact 'xerces:xercesImpl:2.11.0.SP3' (position: END_TAG seen ...resources>\n        <artifact name="xerces:xercesImpl:2.11.0.SP3"/>... @28:56) 
>>>  at org.jboss.modules.ModuleXmlParser.parseArtifact(ModuleXmlParser.java:756)
>>>  at org.jboss.modules.ModuleXmlParser.parseResources(ModuleXmlParser.java:650)
>>>  at org.jboss.modules.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:446)
>>>  at org.jboss.modules.ModuleXmlParser.parseDocument(ModuleXmlParser.java:261)
>>>  at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:148)
>>>  ... 13 more
>>> 
>>> 
>>> On Jun 17, 2015, at 11:26 AM, John O'Hara <johara at redhat.com> wrote:
>>> 
>>>> When I build WF10 in a build env. and move the built app server to a 
>>>> different env. I am unable to start WF10.  This is due to the modules 
>>>> now resolving jars from the local maven repo. The build process 
>>>> downloads and installs the required jars to local maven repo. that are 
>>>> not available on the target environment.
>>>> 
>>>> Is there a way to either
>>>> a) build WF10 and package all the module jars into the build so that it 
>>>> is portable,
>>>> or b) for the WF10 bootstrap process to download missing packages from a 
>>>> remote maven repo on startup where any modules are missing in the local 
>>>> repo?
>>>> 
>>>> Thanks
>>>> 
>>>> -- 
>>>> John O'Hara
>>>> johara at redhat.com
>>>> 
>>>> JBoss, by Red Hat
>>>> 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 Michael O'Neill (Ireland).
>>>> 
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> 
>> 
> 
> 
> -- 
> John O'Hara
> johara at redhat.com
> 
> JBoss, by Red Hat
> 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 Michael O'Neill (Ireland).
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150617/f0fd1552/attachment.html 

From jason.greene at redhat.com  Wed Jun 17 11:33:11 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Wed, 17 Jun 2015 11:33:11 -0400 (EDT)
Subject: [wildfly-dev] Module dependencies WF10
In-Reply-To: <55818F9D.5040705@gmail.com>
References: <5581839A.2040203@redhat.com> <55818D36.1040404@gmail.com>
	<658FA919-C27A-4DE6-8085-533BDC39C6BB@redhat.com>
	<55818F9D.5040705@gmail.com>
Message-ID: <F76D323F-5E65-4471-8061-02D955B509CF@redhat.com>



Sent from my iPhone

> On Jun 17, 2015, at 10:18 AM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
> 
> Hi Jason,
> 
>> On Wednesday 17 June 2015 08:44 PM, Jason T. Greene wrote:
>> 
>>>> On Jun 17, 2015, at 10:08 AM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>>>> 
>>>> On Wednesday 17 June 2015 07:56 PM, John O'Hara wrote:
>>>> When I build WF10 in a build env. and move the built app server to a
>>>> different env. I am unable to start WF10.
>>> Are you sure you aren't copying over the distribution from
>>> WFLY_SRC_CHECKOUT_HOME/build/target/ folder? You should instead be using
>>> the one from WFLY_SRC_CHECKOUT_HOME/dist/target/
>> Note that you have to build with -Drelease to get that, and also you probably will need to beef up the maven max mem settings as the zip plugin seems to consume massive memory:
> 
> I just do:
> 
> mvn clean install -DskipTests=true
> 
> (and sometimes without skipTests) and it generates the binary in the dist/target just fine. By fine, I mean, I have been able to use that binary as if I download it from the WildFly downloads.


Ah interesting. I didn't realize we were doing that by default now. I'll have to check if it's only building the full dist, which is fine if so.

> 
> The one in the build/target folder though, I always run into the same issues as others have noted here, even when I have full access to the Maven repo (just like I did while building).
> 
> -Jaikiran
> 
> 
> 
> 
>> 
>> MAVEN_OPTS=-Xmx2g mvn clean install -Drelease -DskipTests
>> 
>> I need to fix build.sh so that this is no longer necessary.
>> 
>>> -Jaikiran
>>> 
>>>>  This is due to the modules
>>>> now resolving jars from the local maven repo. The build process
>>>> downloads and installs the required jars to local maven repo. that are
>>>> not available on the target environment.
>>>> 
>>>> Is there a way to either
>>>> a) build WF10 and package all the module jars into the build so that it
>>>> is portable,
>>>> or b) for the WF10 bootstrap process to download missing packages from a
>>>> remote maven repo on startup where any modules are missing in the local
>>>> repo?
>>>> 
>>>> Thanks
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 


From jason.greene at redhat.com  Wed Jun 17 11:34:12 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Wed, 17 Jun 2015 11:34:12 -0400 (EDT)
Subject: [wildfly-dev] Module dependencies WF10
In-Reply-To: <55818FC9.7050604@redhat.com>
References: <5581839A.2040203@redhat.com> <55818D36.1040404@gmail.com>
	<55818FC9.7050604@redhat.com>
Message-ID: <639CA449-4C06-4B03-A148-04F4B8A61546@redhat.com>


> On Jun 17, 2015, at 10:19 AM, John O'Hara <johara at redhat.com> wrote:
> 
>> On 17/06/15 16:07, Jaikiran Pai wrote:
>>> On Wednesday 17 June 2015 07:56 PM, John O'Hara wrote:
>>> When I build WF10 in a build env. and move the built app server to a
>>> different env. I am unable to start WF10.
>> Are you sure you aren't copying over the distribution from
>> WFLY_SRC_CHECKOUT_HOME/build/target/ folder? You should instead be using
>> the one from WFLY_SRC_CHECKOUT_HOME/dist/target/
>> 
>> -Jaikiran
>> 
>>>   This is due to the modules
>>> now resolving jars from the local maven repo. The build process
>>> downloads and installs the required jars to local maven repo. that are
>>> not available on the target environment.
>>> 
>>> Is there a way to either
>>> a) build WF10 and package all the module jars into the build so that it
>>> is portable,
>>> or b) for the WF10 bootstrap process to download missing packages from a
>>> remote maven repo on startup where any modules are missing in the local
>>> repo?
>>> 
>>> Thanks
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> Is this something that has changed since WF8? I might be wrong, but I am 
> certain i used to grab the build from build/target before?
> (I have not tried this with WF9)

Yes this is a change since 9, it's part of the feature pack build system. 

> 
> -- 
> John O'Hara
> johara at redhat.com
> 
> JBoss, by Red Hat
> 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 Michael O'Neill (Ireland).
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From tomaz.cerar at gmail.com  Wed Jun 17 15:11:18 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 17 Jun 2015 21:11:18 +0200
Subject: [wildfly-dev] Module dependencies WF10
In-Reply-To: <F76D323F-5E65-4471-8061-02D955B509CF@redhat.com>
References: <5581839A.2040203@redhat.com> <55818D36.1040404@gmail.com>
	<658FA919-C27A-4DE6-8085-533BDC39C6BB@redhat.com>
	<55818F9D.5040705@gmail.com>
	<F76D323F-5E65-4471-8061-02D955B509CF@redhat.com>
Message-ID: <CAMquZP5iLM_tTfF0QovXdsieN20Ej6H3-SRGbjDLBmrJA=ey9A@mail.gmail.com>

On Wed, Jun 17, 2015 at 5:33 PM, Jason T. Greene <jason.greene at redhat.com>
wrote:

> Ah interesting. I didn't realize we were doing that by default now. I'll
> have to check if it's only building the full dist, which is fine if so.



yes we did it so testsuite would work properly. as we are using dist/target
build for testsuite instead of build/target we used in before.
Plan for future is to use provisioning plugin for testsuite so this wont be
needed again.

but it only creates the inflated distro, it doesn't produce zip, tar.gz &
friends that happens when you add -Prelease

--
tomaz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150617/76b1004e/attachment-0001.html 

From jason.greene at redhat.com  Wed Jun 17 17:43:56 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 17 Jun 2015 16:43:56 -0500
Subject: [wildfly-dev] WildFly 10 Schedule
Message-ID: <B88D0B40-6B37-4F5A-A572-EEF23F391D56@redhat.com>

In addition to the biweekly Alphas, the following are the key dates for the WildFly 10 schedule:

WildFly 10 Beta1            - August, 6th    
WildFly 10 CR1              - September 9th  
WildFly 10 CR2 (if needed)  - September 16th 
WildFly 10 Final            - October 8th*

All new feature development needs to be wrapped by August, and preferably most PRs already submitted in July. 

Happy Hacking!

* As always, Final releases are contingent on the last CR being blocker-free. If we aren?t blocker free, we will introduce another CR

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From jorsol at gmail.com  Thu Jun 18 01:19:24 2015
From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=)
Date: Wed, 17 Jun 2015 23:19:24 -0600
Subject: [wildfly-dev] WildFly 10 Schedule
In-Reply-To: <B88D0B40-6B37-4F5A-A572-EEF23F391D56@redhat.com>
References: <B88D0B40-6B37-4F5A-A572-EEF23F391D56@redhat.com>
Message-ID: <CA+cVU8OPaEPQAWb9Q2_2c=YEfjBHt7PbC8BeRYywg_hvZcopNw@mail.gmail.com>

Hi Jason,

Sorry if this is a silly question but what feature, reason or motive make
qualifying for a completely new version?

It's just following a "rapid release" like browsers? I belive in the
release early, release often
philosophy, so I'm want to be sure the approach of the versioning used in
WildFlyC

AFAIK, EAP versioning means something, the major version is the Java EE
specification supported.


?Cheers and Happy Hacking!?


Jorge Sol?rzano
http://www.jorsol.com

On Wed, Jun 17, 2015 at 3:43 PM, Jason Greene <jason.greene at redhat.com>
wrote:

> In addition to the biweekly Alphas, the following are the key dates for
> the WildFly 10 schedule:
>
> WildFly 10 Beta1            - August, 6th
> WildFly 10 CR1              - September 9th
> WildFly 10 CR2 (if needed)  - September 16th
> WildFly 10 Final            - October 8th*
>
> All new feature development needs to be wrapped by August, and preferably
> most PRs already submitted in July.
>
> Happy Hacking!
>
> * As always, Final releases are contingent on the last CR being
> blocker-free. If we aren?t blocker free, we will introduce another CR
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150617/b2836f37/attachment.html 

From anmiller at redhat.com  Thu Jun 18 08:23:16 2015
From: anmiller at redhat.com (Andrig T. Miller)
Date: Thu, 18 Jun 2015 08:23:16 -0400 (EDT)
Subject: [wildfly-dev] WildFly 10 Schedule
In-Reply-To: <CA+cVU8OPaEPQAWb9Q2_2c=YEfjBHt7PbC8BeRYywg_hvZcopNw@mail.gmail.com>
References: <B88D0B40-6B37-4F5A-A572-EEF23F391D56@redhat.com>
	<CA+cVU8OPaEPQAWb9Q2_2c=YEfjBHt7PbC8BeRYywg_hvZcopNw@mail.gmail.com>
Message-ID: <27393005.139.1434630195214.JavaMail.andrigtmiller@worklaptop.miller.org>

----- Original Message -----

> From: "Jorge Sol?rzano" <jorsol at gmail.com>
> To: "Jason Greene" <jason.greene at redhat.com>
> Cc: "WildFly Developers" <wildfly-dev at lists.jboss.org>
> Sent: Wednesday, June 17, 2015 11:19:24 PM
> Subject: Re: [wildfly-dev] WildFly 10 Schedule

> Hi Jason,

> Sorry if this is a silly question but what feature, reason or motive
> make qualifying for a completely new version?

> It's just following a "rapid release" like browsers? I belive in the
> release early, release often
> philosophy, so I'm want to be sure the approach of the versioning
> used in WildFlyC

> AFAIK, EAP versioning means something, the major version is the Java
> EE specification supported.

I would say that is more a coincidence than a true meaning. 

Andy 

> Cheers and Happy Hacking!

> Jorge Sol?rzano
> http://www.jorsol.com

> On Wed, Jun 17, 2015 at 3:43 PM, Jason Greene <
> jason.greene at redhat.com > wrote:

> > In addition to the biweekly Alphas, the following are the key dates
> > for the WildFly 10 schedule:
> 

> > WildFly 10 Beta1 - August, 6th
> 
> > WildFly 10 CR1 - September 9th
> 
> > WildFly 10 CR2 (if needed) - September 16th
> 
> > WildFly 10 Final - October 8th*
> 

> > All new feature development needs to be wrapped by August, and
> > preferably most PRs already submitted in July.
> 

> > Happy Hacking!
> 

> > * As always, Final releases are contingent on the last CR being
> > blocker-free. If we aren?t blocker free, we will introduce another
> > CR
> 

> > --
> 
> > Jason T. Greene
> 
> > WildFly Lead / JBoss EAP Platform Architect
> 
> > JBoss, a division of Red Hat
> 

> > _______________________________________________
> 
> > wildfly-dev mailing list
> 
> > wildfly-dev at lists.jboss.org
> 
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150618/4dd407ea/attachment.html 

From dandread at redhat.com  Thu Jun 18 13:39:41 2015
From: dandread at redhat.com (Dimitris Andreadis)
Date: Thu, 18 Jun 2015 19:39:41 +0200
Subject: [wildfly-dev] WildFly 10 Schedule
In-Reply-To: <27393005.139.1434630195214.JavaMail.andrigtmiller@worklaptop.miller.org>
References: <B88D0B40-6B37-4F5A-A572-EEF23F391D56@redhat.com>	<CA+cVU8OPaEPQAWb9Q2_2c=YEfjBHt7PbC8BeRYywg_hvZcopNw@mail.gmail.com>
	<27393005.139.1434630195214.JavaMail.andrigtmiller@worklaptop.miller.org>
Message-ID: <5583025D.3000902@redhat.com>

EAP releases have been tracking the EE version up to now, but it could change at some point.

On 18/06/2015 14:23, Andrig T. Miller wrote:
>
>
> --------------------------------------------------------------------------------------------
>
>     *From: *"Jorge Sol?rzano" <jorsol at gmail.com>
>     *To: *"Jason Greene" <jason.greene at redhat.com>
>     *Cc: *"WildFly Developers" <wildfly-dev at lists.jboss.org>
>     *Sent: *Wednesday, June 17, 2015 11:19:24 PM
>     *Subject: *Re: [wildfly-dev] WildFly 10 Schedule
>
>     Hi Jason,
>
>     Sorry if this is a silly question but what feature, reason or motive make qualifying for
>     a completely new version?
>
>     It's just following a "rapid release" like browsers? I belive in the release early,
>     release often
>     philosophy, so I'm want to be sure the approach of the versioning used in WildFlyC
>
>     AFAIK, EAP versioning means something, the major version is the Java EE specification
>     supported.
>
> I would say that is more a coincidence than a true meaning.
>
> Andy
>
>
>
>     ?Cheers and Happy Hacking!?
>
>
>     Jorge Sol?rzano
>     http://www.jorsol.com
>
>     On Wed, Jun 17, 2015 at 3:43 PM, Jason Greene <jason.greene at redhat.com
>     <mailto:jason.greene at redhat.com>> wrote:
>
>         In addition to the biweekly Alphas, the following are the key dates for the WildFly
>         10 schedule:
>
>         WildFly 10 Beta1            - August, 6th
>         WildFly 10 CR1              - September 9th
>         WildFly 10 CR2 (if needed)  - September 16th
>         WildFly 10 Final            - October 8th*
>
>         All new feature development needs to be wrapped by August, and preferably most PRs
>         already submitted in July.
>
>         Happy Hacking!
>
>         * As always, Final releases are contingent on the last CR being blocker-free. If we
>         aren?t blocker free, we will introduce another CR
>
>         --
>         Jason T. Greene
>         WildFly Lead / JBoss EAP Platform Architect
>         JBoss, a division of Red Hat
>
>
>         _______________________________________________
>         wildfly-dev mailing list
>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From brian.stansberry at redhat.com  Thu Jun 18 15:28:39 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 18 Jun 2015 14:28:39 -0500
Subject: [wildfly-dev] Capability naming conventions
In-Reply-To: <21E52078-A52B-4C9E-AA27-B6D4DC088D14@jboss.com>
References: <557B3F78.1090907@redhat.com> <557B4E27.4080708@redhat.com>
	<557B4F9C.1090200@redhat.com>
	<21E52078-A52B-4C9E-AA27-B6D4DC088D14@jboss.com>
Message-ID: <55831BE7.60207@redhat.com>

On 6/13/15 4:00 AM, Kabir Khan wrote:
>
>> On 12 Jun 2015, at 22:31, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>
>>>
>>> Sounds good to me.  I'd like to add that internally, we should make sure
>>> we continue to maintain some registry of our org.wildfly name spaces
>>> somewhere (maybe even just a git repository would be OK) so we don't
>>> conflict among ourselves.
>>>
>>
>> Like a text file per capability, with some doc on the capability in the
>> file? Files organized in a tree from the names?
>>
>> That sounds good; much better than some wiki.
> +1
> I don?t know enough about this yet to suggest a format, but having it somewhere in the source is a lot better than a wiki. A wiki brings to mind that horrible log ids page we used for AS 7.

How about this?

https://github.com/bstansberry/wildfly-capabilities

The README.md explains things pretty clearly.

At this point it just has the capabilities currentl in core, including 
unmerged ones added in the PR at

https://github.com/wildfly/wildfly-core/pull/810

That repo has a LICENSE file, which specifies ASL 2.0. I don't know if 
such a thing is really necessary, or if some other license, like 
Creative Commons, is more appropriate.

>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From manderse at redhat.com  Fri Jun 19 09:18:37 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 19 Jun 2015 15:18:37 +0200
Subject: [wildfly-dev] Capability naming conventions
In-Reply-To: <55831BE7.60207@redhat.com>
References: <557B3F78.1090907@redhat.com> <557B4E27.4080708@redhat.com>
	<557B4F9C.1090200@redhat.com>
	<21E52078-A52B-4C9E-AA27-B6D4DC088D14@jboss.com>
	<55831BE7.60207@redhat.com>
Message-ID: <578110CB-B5F7-4B5D-AA50-5EBD160167B0@redhat.com>

Just one quick suggestion.

Instead of .txt, use .adoc then it will actually render nicely on github 
out-of-box and you get access to
do tables and lists etc. in something that is readable as text and look 
nice rendered.

/max

> On 6/13/15 4:00 AM, Kabir Khan wrote:
>>
>>> On 12 Jun 2015, at 22:31, Brian Stansberry 
>>> <brian.stansberry at redhat.com> wrote:
>>>
>>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>>
>>>>
>>>> Sounds good to me.  I'd like to add that internally, we should make 
>>>> sure
>>>> we continue to maintain some registry of our org.wildfly name 
>>>> spaces
>>>> somewhere (maybe even just a git repository would be OK) so we 
>>>> don't
>>>> conflict among ourselves.
>>>>
>>>
>>> Like a text file per capability, with some doc on the capability in 
>>> the
>>> file? Files organized in a tree from the names?
>>>
>>> That sounds good; much better than some wiki.
>> +1
>> I don?t know enough about this yet to suggest a format, but having 
>> it somewhere in the source is a lot better than a wiki. A wiki brings 
>> to mind that horrible log ids page we used for AS 7.
>
> How about this?
>
> https://github.com/bstansberry/wildfly-capabilities
>
> The README.md explains things pretty clearly.
>
> At this point it just has the capabilities currentl in core, including
> unmerged ones added in the PR at
>
> https://github.com/wildfly/wildfly-core/pull/810
>
> That repo has a LICENSE file, which specifies ASL 2.0. I don't know if
> such a thing is really necessary, or if some other license, like
> Creative Commons, is more appropriate.
>
>>>
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> -- 
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


/max
http://about.me/maxandersen

From brian.stansberry at redhat.com  Fri Jun 19 09:37:56 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 19 Jun 2015 08:37:56 -0500
Subject: [wildfly-dev] Capability naming conventions
In-Reply-To: <578110CB-B5F7-4B5D-AA50-5EBD160167B0@redhat.com>
References: <557B3F78.1090907@redhat.com> <557B4E27.4080708@redhat.com>
	<557B4F9C.1090200@redhat.com>
	<21E52078-A52B-4C9E-AA27-B6D4DC088D14@jboss.com>
	<55831BE7.60207@redhat.com>
	<578110CB-B5F7-4B5D-AA50-5EBD160167B0@redhat.com>
Message-ID: <55841B34.9070801@redhat.com>

Thanks; that's a good idea.

On 6/19/15 8:18 AM, Max Rydahl Andersen wrote:
> Just one quick suggestion.
>
> Instead of .txt, use .adoc then it will actually render nicely on github
> out-of-box and you get access to
> do tables and lists etc. in something that is readable as text and look
> nice rendered.
>
> /max
>
>> On 6/13/15 4:00 AM, Kabir Khan wrote:
>>>
>>>> On 12 Jun 2015, at 22:31, Brian Stansberry
>>>> <brian.stansberry at redhat.com> wrote:
>>>>
>>>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>>>
>>>>>
>>>>> Sounds good to me.  I'd like to add that internally, we should make
>>>>> sure
>>>>> we continue to maintain some registry of our org.wildfly name spaces
>>>>> somewhere (maybe even just a git repository would be OK) so we don't
>>>>> conflict among ourselves.
>>>>>
>>>>
>>>> Like a text file per capability, with some doc on the capability in the
>>>> file? Files organized in a tree from the names?
>>>>
>>>> That sounds good; much better than some wiki.
>>> +1
>>> I don?t know enough about this yet to suggest a format, but having it
>>> somewhere in the source is a lot better than a wiki. A wiki brings to
>>> mind that horrible log ids page we used for AS 7.
>>
>> How about this?
>>
>> https://github.com/bstansberry/wildfly-capabilities
>>
>> The README.md explains things pretty clearly.
>>
>> At this point it just has the capabilities currentl in core, including
>> unmerged ones added in the PR at
>>
>> https://github.com/wildfly/wildfly-core/pull/810
>>
>> That repo has a LICENSE file, which specifies ASL 2.0. I don't know if
>> such a thing is really necessary, or if some other license, like
>> Creative Commons, is more appropriate.
>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> /max
> http://about.me/maxandersen


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From darran.lofthouse at jboss.com  Mon Jun 22 07:51:07 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 22 Jun 2015 12:51:07 +0100
Subject: [wildfly-dev] Capability naming conventions
In-Reply-To: <CAAJh=gBYQ08FA+j_ogtE6EfpiKNyBMNqXnXB9CKs7bQ3b-56JA@mail.gmail.com>
References: <557B3F78.1090907@redhat.com>	<557B4E27.4080708@redhat.com>
	<CAAJh=gBYQ08FA+j_ogtE6EfpiKNyBMNqXnXB9CKs7bQ3b-56JA@mail.gmail.com>
Message-ID: <5587F6AB.6090206@jboss.com>

On 12/06/15 22:30, Anil Saldhana wrote:
> Is there an inbuilt mechanism in the capabilities ecosystem that
> disallows system integrators from writing capabilities in the
> org.wildfly namespace?
> This is important lest it becomes a wild west in terms of capabilities. :-)

Actually it is desirable that system integrators do use the names we 
define, if we define that a capability is provided under a specific name 
the integrator can do two different things: -

  1 - Depend on a capability that we supply.
  2 - Provide their own implementation of that capability.

e.g. in the future I would love to see a situation where a third party 
company specialising in security software could add their own subsystem 
that provides the TrustManager capability to plug in their own trust 
infrastructure.

> On Fri, Jun 12, 2015 at 4:24 PM, David M. Lloyd <david.lloyd at redhat.com
> <mailto:david.lloyd at redhat.com>> wrote:
>
>     On 06/12/2015 03:22 PM, Brian Stansberry wrote:
>     > The capability and requirement stuff[1] is far enough along that real
>     > usage is happening, so actual capability names are being created.[2] I
>     > wanted to get some input regarding naming conventions for capability
>     > names so it doesn't devovle into chaos, and so I don't end up making up
>     > a lot of names people hate.
>     >
>     > The key thing is capabilities need to be namespaced to avoid collisions
>     > between capability creators. Beyond that the names should be "good",
>     > whatever that means (user friendly, properly targeted, not overly tied
>     > to implementation, etc).
>     >
>     > My initial thinking on this was:
>     >
>     > 1) The WildFly family projects own the "org.wildfly" namespace. So all
>     > capabilities we create fit in that namespace, and no one else puts
>     > things there. This I think is a must.
>     >
>     > 2) Capabilities not used by or provided by the WildFly kernel go in
>     > subspace org.wildfly.extension.<name_of_extension>. Idea there was just
>     > to avoid naming collisions between different extensions.
>     >
>     > I don't think 2) is such a great idea any more. A given capability be
>     > provided by more than one extension, so there isn't a clean conceptual
>     > mapping. And the word "extension" is really an implementation detail.
>     >
>     > So, I'm inclined to drop the "extension" bit.
>     >
>     > Any thoughts on this, or other aspects of how to name capabilities?
>
>     Sounds good to me.  I'd like to add that internally, we should make sure
>     we continue to maintain some registry of our org.wildfly name spaces
>     somewhere (maybe even just a git repository would be OK) so we don't
>     conflict among ourselves.
>
>     --
>     - DML
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From darran.lofthouse at jboss.com  Mon Jun 22 07:54:02 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 22 Jun 2015 12:54:02 +0100
Subject: [wildfly-dev] Capability naming conventions
In-Reply-To: <21E52078-A52B-4C9E-AA27-B6D4DC088D14@jboss.com>
References: <557B3F78.1090907@redhat.com>
	<557B4E27.4080708@redhat.com>	<557B4F9C.1090200@redhat.com>
	<21E52078-A52B-4C9E-AA27-B6D4DC088D14@jboss.com>
Message-ID: <5587F75A.7010609@jboss.com>

IMO if we add it to our source repo we should just add it to our source, 
that would also provide a central point other subsystems can reference 
it from.

Having a policy of put it in a text file in our source repo but don't 
allow it in a shared class file seems wrong.

On 13/06/15 10:00, Kabir Khan wrote:
>
>> On 12 Jun 2015, at 22:31, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>
>>>
>>> Sounds good to me.  I'd like to add that internally, we should make sure
>>> we continue to maintain some registry of our org.wildfly name spaces
>>> somewhere (maybe even just a git repository would be OK) so we don't
>>> conflict among ourselves.
>>>
>>
>> Like a text file per capability, with some doc on the capability in the
>> file? Files organized in a tree from the names?
>>
>> That sounds good; much better than some wiki.
> +1
> I don?t know enough about this yet to suggest a format, but having it somewhere in the source is a lot better than a wiki. A wiki brings to mind that horrible log ids page we used for AS 7.
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From david.lloyd at redhat.com  Mon Jun 22 08:33:16 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 22 Jun 2015 07:33:16 -0500
Subject: [wildfly-dev] Capability naming conventions
In-Reply-To: <5587F75A.7010609@jboss.com>
References: <557B3F78.1090907@redhat.com>	<557B4E27.4080708@redhat.com>	<557B4F9C.1090200@redhat.com>	<21E52078-A52B-4C9E-AA27-B6D4DC088D14@jboss.com>
	<5587F75A.7010609@jboss.com>
Message-ID: <5588008C.2080207@redhat.com>

The problem is, that's not *really* central.  The version of 
wildfly-core does not impact what namespaces exist or are recognized by 
subsystems.  However, putting the registry in that repository means that 
certain names, which are possibly not even referenced from wildfly-core, 
become unavailable for no good reason.

On the other hand, having a separate registry encourages add-on packages 
and other third parties to participate in registration without the 
additional coordination overhead required in creating releases for the 
change to become visible to the greater world.  This becomes even more 
significant as we maintain multiple branches.

Finally, having external name registries is standard practice for plenty 
of situations similar to this one (RFC implementations for example), for 
all the reasons I've given above.

On 06/22/2015 06:54 AM, Darran Lofthouse wrote:
> IMO if we add it to our source repo we should just add it to our source,
> that would also provide a central point other subsystems can reference
> it from.
>
> Having a policy of put it in a text file in our source repo but don't
> allow it in a shared class file seems wrong.
>
> On 13/06/15 10:00, Kabir Khan wrote:
>>
>>> On 12 Jun 2015, at 22:31, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>
>>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>>
>>>>
>>>> Sounds good to me.  I'd like to add that internally, we should make sure
>>>> we continue to maintain some registry of our org.wildfly name spaces
>>>> somewhere (maybe even just a git repository would be OK) so we don't
>>>> conflict among ourselves.
>>>>
>>>
>>> Like a text file per capability, with some doc on the capability in the
>>> file? Files organized in a tree from the names?
>>>
>>> That sounds good; much better than some wiki.
>> +1
>> I don?t know enough about this yet to suggest a format, but having it somewhere in the source is a lot better than a wiki. A wiki brings to mind that horrible log ids page we used for AS 7.
>>>
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML

From darran.lofthouse at jboss.com  Mon Jun 22 08:46:40 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 22 Jun 2015 13:46:40 +0100
Subject: [wildfly-dev] Capability naming conventions
In-Reply-To: <5588008C.2080207@redhat.com>
References: <557B3F78.1090907@redhat.com>	<557B4E27.4080708@redhat.com>	<557B4F9C.1090200@redhat.com>	<21E52078-A52B-4C9E-AA27-B6D4DC088D14@jboss.com>	<5587F75A.7010609@jboss.com>
	<5588008C.2080207@redhat.com>
Message-ID: <558803B0.4040301@jboss.com>

Do we have other naming conventions where we could make use of a central 
registry?

Thinking about HTTP and SASL authentication mechanisms, these are 
predominantly using IANA registered names but we do have a few exceptions.

If we ever want to be doing anything with custom LDAP schemas these can 
require OID definitions.

We do also have a large number of XML schema namespaces although 
probably not a good example as we have not experienced conflict here.


On 22/06/15 13:33, David M. Lloyd wrote:
> The problem is, that's not *really* central.  The version of
> wildfly-core does not impact what namespaces exist or are recognized by
> subsystems.  However, putting the registry in that repository means that
> certain names, which are possibly not even referenced from wildfly-core,
> become unavailable for no good reason.
>
> On the other hand, having a separate registry encourages add-on packages
> and other third parties to participate in registration without the
> additional coordination overhead required in creating releases for the
> change to become visible to the greater world.  This becomes even more
> significant as we maintain multiple branches.
>
> Finally, having external name registries is standard practice for plenty
> of situations similar to this one (RFC implementations for example), for
> all the reasons I've given above.
>
> On 06/22/2015 06:54 AM, Darran Lofthouse wrote:
>> IMO if we add it to our source repo we should just add it to our source,
>> that would also provide a central point other subsystems can reference
>> it from.
>>
>> Having a policy of put it in a text file in our source repo but don't
>> allow it in a shared class file seems wrong.
>>
>> On 13/06/15 10:00, Kabir Khan wrote:
>>>
>>>> On 12 Jun 2015, at 22:31, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>>
>>>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>>>
>>>>>
>>>>> Sounds good to me.  I'd like to add that internally, we should make sure
>>>>> we continue to maintain some registry of our org.wildfly name spaces
>>>>> somewhere (maybe even just a git repository would be OK) so we don't
>>>>> conflict among ourselves.
>>>>>
>>>>
>>>> Like a text file per capability, with some doc on the capability in the
>>>> file? Files organized in a tree from the names?
>>>>
>>>> That sounds good; much better than some wiki.
>>> +1
>>> I don?t know enough about this yet to suggest a format, but having it somewhere in the source is a lot better than a wiki. A wiki brings to mind that horrible log ids page we used for AS 7.
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>

From david.lloyd at redhat.com  Mon Jun 22 09:00:32 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 22 Jun 2015 08:00:32 -0500
Subject: [wildfly-dev] Capability naming conventions
In-Reply-To: <558803B0.4040301@jboss.com>
References: <557B3F78.1090907@redhat.com>	<557B4E27.4080708@redhat.com>	<557B4F9C.1090200@redhat.com>	<21E52078-A52B-4C9E-AA27-B6D4DC088D14@jboss.com>	<5587F75A.7010609@jboss.com>	<5588008C.2080207@redhat.com>
	<558803B0.4040301@jboss.com>
Message-ID: <558806F0.2080903@redhat.com>

Yes, definitely.  I already maintain SLP identifiers and related hokum 
in "RHANANA" which is AFAIK presently internal-only (but is also the 
place where we should be maintaining OIDs and other IANA stuff), but 
there are definitely at least a couple of other things that I believe 
can/should be centralized outside of the code base; off the top of my head:

* Deployment descriptor schemas
* (Perhaps controversially) Resource names and descriptions incl. XML 
schemas

On 06/22/2015 07:46 AM, Darran Lofthouse wrote:
> Do we have other naming conventions where we could make use of a central
> registry?
>
> Thinking about HTTP and SASL authentication mechanisms, these are
> predominantly using IANA registered names but we do have a few exceptions.
>
> If we ever want to be doing anything with custom LDAP schemas these can
> require OID definitions.
>
> We do also have a large number of XML schema namespaces although
> probably not a good example as we have not experienced conflict here.
>
>
> On 22/06/15 13:33, David M. Lloyd wrote:
>> The problem is, that's not *really* central.  The version of
>> wildfly-core does not impact what namespaces exist or are recognized by
>> subsystems.  However, putting the registry in that repository means that
>> certain names, which are possibly not even referenced from wildfly-core,
>> become unavailable for no good reason.
>>
>> On the other hand, having a separate registry encourages add-on packages
>> and other third parties to participate in registration without the
>> additional coordination overhead required in creating releases for the
>> change to become visible to the greater world.  This becomes even more
>> significant as we maintain multiple branches.
>>
>> Finally, having external name registries is standard practice for plenty
>> of situations similar to this one (RFC implementations for example), for
>> all the reasons I've given above.
>>
>> On 06/22/2015 06:54 AM, Darran Lofthouse wrote:
>>> IMO if we add it to our source repo we should just add it to our source,
>>> that would also provide a central point other subsystems can reference
>>> it from.
>>>
>>> Having a policy of put it in a text file in our source repo but don't
>>> allow it in a shared class file seems wrong.
>>>
>>> On 13/06/15 10:00, Kabir Khan wrote:
>>>>
>>>>> On 12 Jun 2015, at 22:31, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>>>
>>>>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>>>>
>>>>>>
>>>>>> Sounds good to me.  I'd like to add that internally, we should make sure
>>>>>> we continue to maintain some registry of our org.wildfly name spaces
>>>>>> somewhere (maybe even just a git repository would be OK) so we don't
>>>>>> conflict among ourselves.
>>>>>>
>>>>>
>>>>> Like a text file per capability, with some doc on the capability in the
>>>>> file? Files organized in a tree from the names?
>>>>>
>>>>> That sounds good; much better than some wiki.
>>>> +1
>>>> I don?t know enough about this yet to suggest a format, but having it somewhere in the source is a lot better than a wiki. A wiki brings to mind that horrible log ids page we used for AS 7.
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Senior Principal Software Engineer
>>>>> JBoss by Red Hat
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML

From bgaisford at punagroup.com  Mon Jun 22 14:35:08 2015
From: bgaisford at punagroup.com (Brandon Gaisford)
Date: Mon, 22 Jun 2015 08:35:08 -1000
Subject: [wildfly-dev] WFCORE-648 Cascade Ear Exclusions Test Case
Message-ID: <364FBE5A-B12F-49FF-A556-FC8BBF20A516@punagroup.com>

Hey all,

I?ve completed my initial coding for this issue and spent 2-3 hours now trying to come up with a good test case.  I?ve created a test ear that I was planning to include as a test resource to deploy during unit testing. 

When I debug using the test ear during normal server startup, I?m seeing this operation and resource within the DeploymentDeployHandler:

operation
{
  "operation" => "deploy",
  "address" => [("deployment" => "test-ear.ear")]
}

resource
{
  "persistent" => false,
  "owner" => [
      ("subsystem" => "deployment-scanner"),
      ("scanner" => "default")
  ],
  "runtime-name" => "test-ear.ear",
  "content" => [{"hash" => bytes {
      0x00, 0xbb, 0x8a, 0x3a, 0x61, 0x12, 0xa6, 0xec,
      0x59, 0x69, 0xab, 0x9d, 0xda, 0xe1, 0x48, 0x0e,
      0x68, 0x92, 0x9a, 0x03
  }}],
  "enabled" => undefined
}

I was thinking I could model my test case after the existing DeploymentAddHandlerTestCase (but instead target DeploymentDeployHandler) and then during the deployment phase inspect some internal state to verify the exclusions are correct in the ModuleStructureSpec.  But now I?m questioning whether this is a bridge too far.

Does anyone have any bright ideas or advice on how I might move forward on this test case?

Thanks,

Brandon

From brian.stansberry at redhat.com  Mon Jun 22 15:12:22 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 22 Jun 2015 14:12:22 -0500
Subject: [wildfly-dev] WFCORE-648 Cascade Ear Exclusions Test Case
In-Reply-To: <364FBE5A-B12F-49FF-A556-FC8BBF20A516@punagroup.com>
References: <364FBE5A-B12F-49FF-A556-FC8BBF20A516@punagroup.com>
Message-ID: <55885E16.7010809@redhat.com>

I don't know enough about the details of this to have any suggestions 
re: how to validate that the exclusions are correct. But I don't think 
DeploymentAddHandlerTestCase is a good base to work from. It's a unit 
test of a particular class that uses mocks and doesn't involve 
DeploymentUnitProcessors at all. You probably need an integration test.

On 6/22/15 1:35 PM, Brandon Gaisford wrote:
> Hey all,
>
> I?ve completed my initial coding for this issue and spent 2-3 hours now trying to come up with a good test case.  I?ve created a test ear that I was planning to include as a test resource to deploy during unit testing.
>
> When I debug using the test ear during normal server startup, I?m seeing this operation and resource within the DeploymentDeployHandler:
>
> operation
> {
>    "operation" => "deploy",
>    "address" => [("deployment" => "test-ear.ear")]
> }
>
> resource
> {
>    "persistent" => false,
>    "owner" => [
>        ("subsystem" => "deployment-scanner"),
>        ("scanner" => "default")
>    ],
>    "runtime-name" => "test-ear.ear",
>    "content" => [{"hash" => bytes {
>        0x00, 0xbb, 0x8a, 0x3a, 0x61, 0x12, 0xa6, 0xec,
>        0x59, 0x69, 0xab, 0x9d, 0xda, 0xe1, 0x48, 0x0e,
>        0x68, 0x92, 0x9a, 0x03
>    }}],
>    "enabled" => undefined
> }
>
> I was thinking I could model my test case after the existing DeploymentAddHandlerTestCase (but instead target DeploymentDeployHandler) and then during the deployment phase inspect some internal state to verify the exclusions are correct in the ModuleStructureSpec.  But now I?m questioning whether this is a bridge too far.
>
> Does anyone have any bright ideas or advice on how I might move forward on this test case?
>
> Thanks,
>
> Brandon
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From gytis at redhat.com  Tue Jun 23 10:20:50 2015
From: gytis at redhat.com (Gytis Trikleris)
Date: Tue, 23 Jun 2015 15:20:50 +0100
Subject: [wildfly-dev] Getting ManagedThreadFactory in a subsystem
Message-ID: <55896B42.2040706@redhat.com>

Hello,

I?ve got an issue with my subsystem 
(https://github.com/wildfly/wildfly/tree/master/transactions) where I 
cannot access BeanManager or UserTransaction from JNDI (I can however 
lookup datasources). This error is currently happening during periodic 
recovery i.e. on PeriodicRecovery thread. My assumption is that the CDI 
and EE JNDI environment are not initialized because PeriodicRecovery 
extends Thread and was created with the ?new? operator rather than 
ManagedThreadFactory and I know that EE apps are meant to use this 
approach to ensure their environments are initialized correctly - does 
this restriction apply to subsystems too? One issue I am coming up 
against during prototyping is that I?m not sure how to get the 
ManagedThreadFactory during our subsystems boot time as it does not 
appear in JNDI.

I would like to know if it is possible to inject the 
ManagedThreadFactory into my subsystem so I am not reliant upon its 
availability in JNDI.

Thanks,
Gytis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150623/bb855283/attachment.html 

From stuart.w.douglas at gmail.com  Tue Jun 23 11:34:46 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 23 Jun 2015 15:34:46 +0000
Subject: [wildfly-dev] Getting ManagedThreadFactory in a subsystem
In-Reply-To: <55896B42.2040706@redhat.com>
References: <55896B42.2040706@redhat.com>
Message-ID: <CAAoo=c5PNFpSec=PaUCQL6e-BVhzM3H-DzxJmeV9i-85NZjU5g@mail.gmail.com>

I don't know if ManagedThreadFactory is a great option, as then you have a
hard dependency on this being available,  which may not be the case in some
cut down configurations.

Does this thread run in the context of a particular deployment, otherwise
this does not make a great deal of sense, as the JNDI context is a per
deployment construct.

If this is a per deployment thing then you can manually set up the per
deployment contexts using the actions
under org.jboss.as.server.deployment.Attachments#SETUP_ACTIONS.

Stuart

On Tue, 23 Jun 2015 at 16:21 Gytis Trikleris <gytis at redhat.com> wrote:

>  Hello,
>
> I?ve got an issue with my subsystem (
> https://github.com/wildfly/wildfly/tree/master/transactions) where I
> cannot access BeanManager or UserTransaction from JNDI (I can however
> lookup datasources). This error is currently happening during periodic
> recovery i.e. on PeriodicRecovery thread. My assumption is that the CDI and
> EE JNDI environment are not initialized because PeriodicRecovery extends
> Thread and was created with the ?new? operator rather than
> ManagedThreadFactory and I know that EE apps are meant to use this approach
> to ensure their environments are initialized correctly - does this
> restriction apply to subsystems too? One issue I am coming up against
> during prototyping is that I?m not sure how to get the ManagedThreadFactory
> during our subsystems boot time as it does not appear in JNDI.
>
> I would like to know if it is possible to inject the ManagedThreadFactory
> into my subsystem so I am not reliant upon its availability in JNDI.
>
> Thanks,
> Gytis
>  _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150623/bc79a4e7/attachment.html 

From bgaisford at punagroup.com  Tue Jun 23 13:45:37 2015
From: bgaisford at punagroup.com (Brandon Gaisford)
Date: Tue, 23 Jun 2015 07:45:37 -1000
Subject: [wildfly-dev] WFCORE-648 Cascade Ear Exclusions Test Case
In-Reply-To: <55885E16.7010809@redhat.com>
References: <364FBE5A-B12F-49FF-A556-FC8BBF20A516@punagroup.com>
	<55885E16.7010809@redhat.com>
Message-ID: <82A69932-E9E5-4E88-9ECB-BDB5614877C9@punagroup.com>


Thanks, I?ve created a PR for visibility.  I?ll keep working on the test cases.

https://github.com/wildfly/wildfly-core/pull/834

Brandon

On Jun 22, 2015, at 9:12 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:

> I don't know enough about the details of this to have any suggestions 
> re: how to validate that the exclusions are correct. But I don't think 
> DeploymentAddHandlerTestCase is a good base to work from. It's a unit 
> test of a particular class that uses mocks and doesn't involve 
> DeploymentUnitProcessors at all. You probably need an integration test.
> 
> On 6/22/15 1:35 PM, Brandon Gaisford wrote:
>> Hey all,
>> 
>> I?ve completed my initial coding for this issue and spent 2-3 hours now trying to come up with a good test case.  I?ve created a test ear that I was planning to include as a test resource to deploy during unit testing.
>> 
>> When I debug using the test ear during normal server startup, I?m seeing this operation and resource within the DeploymentDeployHandler:
>> 
>> operation
>> {
>>   "operation" => "deploy",
>>   "address" => [("deployment" => "test-ear.ear")]
>> }
>> 
>> resource
>> {
>>   "persistent" => false,
>>   "owner" => [
>>       ("subsystem" => "deployment-scanner"),
>>       ("scanner" => "default")
>>   ],
>>   "runtime-name" => "test-ear.ear",
>>   "content" => [{"hash" => bytes {
>>       0x00, 0xbb, 0x8a, 0x3a, 0x61, 0x12, 0xa6, 0xec,
>>       0x59, 0x69, 0xab, 0x9d, 0xda, 0xe1, 0x48, 0x0e,
>>       0x68, 0x92, 0x9a, 0x03
>>   }}],
>>   "enabled" => undefined
>> }
>> 
>> I was thinking I could model my test case after the existing DeploymentAddHandlerTestCase (but instead target DeploymentDeployHandler) and then during the deployment phase inspect some internal state to verify the exclusions are correct in the ModuleStructureSpec.  But now I?m questioning whether this is a bridge too far.
>> 
>> Does anyone have any bright ideas or advice on how I might move forward on this test case?
>> 
>> Thanks,
>> 
>> Brandon
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
> 
> 
> -- 
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From bgaisford at punagroup.com  Wed Jun 24 00:57:33 2015
From: bgaisford at punagroup.com (Brandon Gaisford)
Date: Tue, 23 Jun 2015 18:57:33 -1000
Subject: [wildfly-dev] Hacking on WildFly - 2015
Message-ID: <19C73149-5578-4D4C-ADF5-4233FEA2F835@punagroup.com>

Hey All,

I?m hoping an effort is already underway to update the ?Hacking on WildFly? development article (https://developer.jboss.org/wiki/HackingOnWildFly) based on all the latest project changes.  I?m tempted to volunteer to do it, but I don?t have enough background yet to pull it off.  The existing article is great and was my gateway into open source development.  However, the article is out of date and needs to be updated to account for the new dual wildfly/wildfly-core project structure.  I?d also like to pass along the development issues I?ve struggled with along the way so others don?t have to repeat the same.  What do you guys think?

Brandon 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150623/2334910c/attachment.html 

From gytis at redhat.com  Wed Jun 24 04:31:21 2015
From: gytis at redhat.com (Gytis Trikleris)
Date: Wed, 24 Jun 2015 09:31:21 +0100
Subject: [wildfly-dev] Getting ManagedThreadFactory in a subsystem
In-Reply-To: <CAAoo=c5PNFpSec=PaUCQL6e-BVhzM3H-DzxJmeV9i-85NZjU5g@mail.gmail.com>
References: <55896B42.2040706@redhat.com>
	<CAAoo=c5PNFpSec=PaUCQL6e-BVhzM3H-DzxJmeV9i-85NZjU5g@mail.gmail.com>
Message-ID: <558A6AD9.2050906@redhat.com>

This thread is created when transaction subsystem starts and is active 
through the life cycle of the application server. If failure happens in 
any of the applications, periodic recovery finds the name of the 
compensation handler in tx-object-store. That handler is a CDI bean 
implemented by the application and has to be invoked in order to redo 
the work of the application. We use BeanManager to instantiate that 
handler and currently use JNDI to get it. Also, when compensate method 
is invoked it is very likely that implementation of it will need access 
to JNDI as well to get UserTransaction for example.

Additionally, before invoking the compensation handler we need to enable 
application's class loader (I still need to figure out the best way to 
store them, but I'm thinking of providing them to periodic recovery 
during the deployment of each application). Would that class loader help 
to solve JNDI issue or is there extra context I should save maybe?

Gytis

On 23/06/15 16:34, Stuart Douglas wrote:
> I don't know if ManagedThreadFactory is a great option, as then you 
> have a hard dependency on this being available,  which may not be the 
> case in some cut down configurations.
>
> Does this thread run in the context of a particular deployment, 
> otherwise this does not make a great deal of sense, as the JNDI 
> context is a per deployment construct.
>
> If this is a per deployment thing then you can manually set up the per 
> deployment contexts using the actions 
> under org.jboss.as.server.deployment.Attachments#SETUP_ACTIONS.
>
> Stuart
>
> On Tue, 23 Jun 2015 at 16:21 Gytis Trikleris <gytis at redhat.com 
> <mailto:gytis at redhat.com>> wrote:
>
>     Hello,
>
>     I?ve got an issue with my subsystem
>     (https://github.com/wildfly/wildfly/tree/master/transactions)
>     where I cannot access BeanManager or UserTransaction from JNDI (I
>     can however lookup datasources). This error is currently happening
>     during periodic recovery i.e. on PeriodicRecovery thread. My
>     assumption is that the CDI and EE JNDI environment are not
>     initialized because PeriodicRecovery extends Thread and was
>     created with the ?new? operator rather than ManagedThreadFactory
>     and I know that EE apps are meant to use this approach to ensure
>     their environments are initialized correctly - does this
>     restriction apply to subsystems too? One issue I am coming up
>     against during prototyping is that I?m not sure how to get the
>     ManagedThreadFactory during our subsystems boot time as it does
>     not appear in JNDI.
>
>     I would like to know if it is possible to inject the
>     ManagedThreadFactory into my subsystem so I am not reliant upon
>     its availability in JNDI.
>
>     Thanks,
>     Gytis
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150624/a691e995/attachment-0001.html 

From brian.stansberry at redhat.com  Wed Jun 24 11:52:37 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 24 Jun 2015 10:52:37 -0500
Subject: [wildfly-dev] Hacking on WildFly - 2015
In-Reply-To: <19C73149-5578-4D4C-ADF5-4233FEA2F835@punagroup.com>
References: <19C73149-5578-4D4C-ADF5-4233FEA2F835@punagroup.com>
Message-ID: <558AD245.5030104@redhat.com>

Just brainstorming here. Perhaps add two pages, "Hacking on WildFly 
Core" and "Hacking on WildFly Full"?

And then the existing "Hacking on WildFly" page just describes the core 
vs full code split and explains how to decide which one it is you want 
to hack on.

There will end up being redundant information, as a lot of it is 
mechanics where just names and paths will be different, but the upside 
is each page is conceptually clear.

On 6/23/15 11:57 PM, Brandon Gaisford wrote:
> Hey All,
>
> I?m hoping an effort is already underway to update the ?Hacking on
> WildFly? development article
> (https://developer.jboss.org/wiki/HackingOnWildFly) based on all the
> latest project changes.  I?m tempted to volunteer to do it, but I don?t
> have enough background yet to pull it off.  The existing article is
> great and was my gateway into open source development.  However, the
> article is out of date and needs to be updated to account for the new
> dual wildfly/wildfly-core project structure.  I?d also like to pass
> along the development issues I?ve struggled with along the way so others
> don?t have to repeat the same.  What do you guys think?
>
> Brandon
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From bgaisford at punagroup.com  Wed Jun 24 16:29:09 2015
From: bgaisford at punagroup.com (Brandon Gaisford)
Date: Wed, 24 Jun 2015 10:29:09 -1000
Subject: [wildfly-dev] Hacking on WildFly - 2015
In-Reply-To: <558AD245.5030104@redhat.com>
References: <19C73149-5578-4D4C-ADF5-4233FEA2F835@punagroup.com>
	<558AD245.5030104@redhat.com>
Message-ID: <E0130A29-2848-48C1-B50E-86C81E84BE6F@punagroup.com>


Simply acknowledging wildly full and wildly core would go a long way.  Highlight what a developer needs to do to build full to include core (mvn install -Dversion.org.wildfly.core=2.0.0.Alpha5-SNAPSHOT).  Highlight the integration test suite and unit testing infrastructure in place.  Keep it simple.  I got stuck on each of these things the first time.

Brandon

On Jun 24, 2015, at 5:52 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:

> Just brainstorming here. Perhaps add two pages, "Hacking on WildFly 
> Core" and "Hacking on WildFly Full"?
> 
> And then the existing "Hacking on WildFly" page just describes the core 
> vs full code split and explains how to decide which one it is you want 
> to hack on.
> 
> There will end up being redundant information, as a lot of it is 
> mechanics where just names and paths will be different, but the upside 
> is each page is conceptually clear.
> 
> On 6/23/15 11:57 PM, Brandon Gaisford wrote:
>> Hey All,
>> 
>> I?m hoping an effort is already underway to update the ?Hacking on
>> WildFly? development article
>> (https://developer.jboss.org/wiki/HackingOnWildFly) based on all the
>> latest project changes.  I?m tempted to volunteer to do it, but I don?t
>> have enough background yet to pull it off.  The existing article is
>> great and was my gateway into open source development.  However, the
>> article is out of date and needs to be updated to account for the new
>> dual wildfly/wildfly-core project structure.  I?d also like to pass
>> along the development issues I?ve struggled with along the way so others
>> don?t have to repeat the same.  What do you guys think?
>> 
>> Brandon
>> 
>> 
>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
> 
> 
> -- 
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From frank.langelage at osnanet.de  Fri Jun 26 01:47:27 2015
From: frank.langelage at osnanet.de (Frank Langelage)
Date: Fri, 26 Jun 2015 07:47:27 +0200
Subject: [wildfly-dev] WFLYCTL0218: A node is already registered at
	'/deployment=*/subsystem=datasources/xa-data-source=*/statistics=jdbc'
Message-ID: <558CE76F.5000601@osnanet.de>

I have a Deja-Vu, I'm very I saw this some months ago. Not it reappears.

Possibly due to the commit #7605 with changes for "WFLY-4429 Refactor 
JCA subsystem".

26.06. 00:25:37,390 INFO 
[org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer#deployXADataSource] 
IJ020018: Enabling <validate-on-match> for 
java:jboss/datasources/maj2e-langfr-dev
26.06. 00:25:37,445 INFO 
[org.jboss.as.connector.subsystems.datasources#transition] WFLYJCA0001: 
Bound data source [java:jboss/datasources/DefaultDS]
26.06. 00:25:37,501 INFO 
[org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue] 
IJ020018: Enabling <validate-on-match> for 
java:/eis/maj2e-langfr-dev/ControllerConnector
26.06. 00:25:37,509 INFO 
[org.jboss.as.connector.deployment#bindConnectionFactory] WFLYJCA0007: 
Registered connection factory java:/eis/maj2e-langfr-dev/ControllerConnector
26.06. 00:25:37,514 INFO 
[org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue] 
IJ020002: Deployed: 
file:/mbi/tools/jboss/10.0/standalone/tmp/vfs/temp/temp91b455ac091637f0/content-9d63fac1b393fd1c/contents/
26.06. 00:25:37,801 INFO 
[org.jboss.as.connector.subsystems.datasources#transition] WFLYJCA0001: 
Bound data source [java:jboss/datasources/maj2e-langfr-dev]
26.06. 00:25:37,990 ERROR [org.jboss.msc.service.fail#startFailed] 
MSC000001: Failed to start service 
jboss.data-source.java:jboss/datasources/maj2e-langfr-dev.statistics: 
org.jboss.msc.service.StartException in service 
jboss.data-source.java:jboss/datasources/maj2e-langfr-dev.statistics: 
Failed to start service
     at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
     at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
     at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
     at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: WFLYCTL0218: A node is 
already registered at 
'/deployment=*/subsystem=datasources/xa-data-source=*/statistics=jdbc'
     at 
org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:147)
     at 
org.jboss.as.connector.services.datasources.statistics.DataSourceStatisticsService.start(DataSourceStatisticsService.java:83) 
at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
     at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
     ... 3 more



From emartins at redhat.com  Fri Jun 26 12:07:50 2015
From: emartins at redhat.com (Eduardo Martins)
Date: Fri, 26 Jun 2015 17:07:50 +0100
Subject: [wildfly-dev] Getting ManagedThreadFactory in a subsystem
In-Reply-To: <558A6AD9.2050906@redhat.com>
References: <55896B42.2040706@redhat.com>
	<CAAoo=c5PNFpSec=PaUCQL6e-BVhzM3H-DzxJmeV9i-85NZjU5g@mail.gmail.com>
	<558A6AD9.2050906@redhat.com>
Message-ID: <FC3E67A3-8590-4902-A15C-28C3B70ED07F@redhat.com>

ManagedThreadFactory is useful only for app code, it creates threads which run its task with the invocation context (class loader, jndi, security, etc.) present when the thread was created. From what I understood on your previous mail you want to create a subsystem owned thread, thus makes no sense to use the ManagedThreadFactory to create it. 

By the way, JNDI is truly an app code resource, subsystem code should use a MSC service that is injected (through a dependency) with what was bound to JNDI, for instance the UserTransaction is managed by the service named

org.jboss.as.txn.service.UserTransactionService.SERVICE_NAME

so for a subsystem?s service to depend on it, and get injected with its value, on its creation do:

serviceBuilder.addDependency(UserTransactionService.SERVICE_NAME, UserTransaction.class, service.getValueToInjectWithUserTransaction());

Same recipe for BeanManager or any other resource, all you need is to find the name of the service that manages it. But beware, the subsystem will then depend on the subsystem managing such resource?

?E

> On 24 Jun 2015, at 09:31, Gytis Trikleris <gytis at redhat.com> wrote:
> 
> This thread is created when transaction subsystem starts and is active through the life cycle of the application server. If failure happens in any of the applications, periodic recovery finds the name of the compensation handler in tx-object-store. That handler is a CDI bean implemented by the application and has to be invoked in order to redo the work of the application. We use BeanManager to instantiate that handler and currently use JNDI to get it. Also, when compensate method is invoked it is very likely that implementation of it will need access to JNDI as well to get UserTransaction for example.
> 
> Additionally, before invoking the compensation handler we need to enable application's class loader (I still need to figure out the best way to store them, but I'm thinking of providing them to periodic recovery during the deployment of each application). Would that class loader help to solve JNDI issue or is there extra context I should save maybe?
> 
> Gytis
> 
> On 23/06/15 16:34, Stuart Douglas wrote:
>> I don't know if ManagedThreadFactory is a great option, as then you have a hard dependency on this being available,  which may not be the case in some cut down configurations. 
>> 
>> Does this thread run in the context of a particular deployment, otherwise this does not make a great deal of sense, as the JNDI context is a per deployment construct. 
>> 
>> If this is a per deployment thing then you can manually set up the per deployment contexts using the actions under org.jboss.as.server.deployment.Attachments#SETUP_ACTIONS.
>> 
>> Stuart
>> 
>> On Tue, 23 Jun 2015 at 16:21 Gytis Trikleris <gytis at redhat.com <mailto:gytis at redhat.com>> wrote:
>> Hello,
>> 
>> I?ve got an issue with my subsystem (https://github.com/wildfly/wildfly/tree/master/transactions <https://github.com/wildfly/wildfly/tree/master/transactions>) where I cannot access BeanManager or UserTransaction from JNDI (I can however lookup datasources). This error is currently happening during periodic recovery i.e. on PeriodicRecovery thread. My assumption is that the CDI and EE JNDI environment are not initialized because PeriodicRecovery extends Thread and was created with the ?new? operator rather than ManagedThreadFactory and I know that EE apps are meant to use this approach to ensure their environments are initialized correctly - does this restriction apply to subsystems too? One issue I am coming up against during prototyping is that I?m not sure how to get the ManagedThreadFactory during our subsystems boot time as it does not appear in JNDI.
>> 
>> I would like to know if it is possible to inject the ManagedThreadFactory into my subsystem so I am not reliant upon its availability in JNDI.
>> 
>> Thanks,
>> Gytis
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150626/f128a94e/attachment.html 

From jperkins at redhat.com  Fri Jun 26 20:22:43 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Fri, 26 Jun 2015 17:22:43 -0700
Subject: [wildfly-dev] WildFly Core 2.0.0.Alpha5 Released
Message-ID: <558DECD3.3040906@redhat.com>

WildFly Core 2.0.0.Alpha5 was released and a PR has been sent to update 
WildFly Full.

Once merged into full there some new methods for dynamic capabilities 
were introduced in this version of core for those starting to use the 
new feature.

-- 
James R. Perkins
JBoss by Red Hat


From jason.greene at redhat.com  Sat Jun 27 00:00:00 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 26 Jun 2015 23:00:00 -0500
Subject: [wildfly-dev] WildFly 10.0.0.Alpha4 Released & 9 Status Update
Message-ID: <D12976DF-630F-49BC-A9E7-7A5F09A91826@redhat.com>

The latest edition of our biweekly Alpha series has been released to maven here:
https://repository.jboss.org/nexus/content/groups/developer/org/wildfly/wildfly-dist/10.0.0.Alpha4/wildfly-dist-10.0.0.Alpha4.zip

JIRA Release Notes:
https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12313721&version=12327286

The largest change is the switch from HornetQ to ActiveMQ Artemis, a new ActiveMQ project derived from the HornetQ code donation.

For those interested in 9, we are currently waiting on one last blocker, which is that we need a JGroups update to fix clustering on OpenShift:
https://issues.jboss.org/browse/WFLY-4674

The fix is already complete, we are simply waiting on the release.

Happy Hacking!

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From emartins at redhat.com  Mon Jun 29 11:37:38 2015
From: emartins at redhat.com (Eduardo Martins)
Date: Mon, 29 Jun 2015 16:37:38 +0100
Subject: [wildfly-dev] Migration content needed for AS 7 --> WildFly 10
In-Reply-To: <5575C57F.60501@redhat.com>
References: <5575C57F.60501@redhat.com>
Message-ID: <9CC2853B-D743-4B2D-B7E0-280C96DE49EB@redhat.com>

I would like to invite everyone to have a quick look at current state of the document, and see if there are missing topics (I think there is chance wrt server a clustering section is needed, and wrt apps a Logging section may be needed) or incorrect information.

Wrt the TODOs in the docs, these I?m working out.

?E

> On 08 Jun 2015, at 17:40, Sande Gilda <sgilda at redhat.com> wrote:
> 
> I am responsible for documenting how to migrate an application from AS 7 to Wildfly 10 and have created the following page to document these changes:
> https://docs.jboss.org/author/display/WFLY10/How+do+I+migrate+my+application+from+AS7+to+WildFly <https://docs.jboss.org/author/display/WFLY10/How+do+I+migrate+my+application+from+AS7+to+WildFly>
> If you worked on a component that has changed or been replaced, or have experience or knowledge about what needs to be updated when migrating an AS 7 application to Wildfly 10, please consider adding content to this page. Those of you who were around for AS 7 will recall I did this for migration from AS5/6 --> AS7 (see https://docs.jboss.org/author/display/AS72/How+do+I+migrate+my+application+from+AS5+or+AS6+to+AS7 <https://docs.jboss.org/author/display/AS72/How+do+I+migrate+my+application+from+AS5+or+AS6+to+AS7>) and everyone was great about contributing to that content.
> 
> Thanks in advance and please contact me if you have any questions!
> 
> Thanks,
> Sande
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150629/1f79a91b/attachment.html 

From tsegismo at redhat.com  Mon Jun 29 12:04:28 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 29 Jun 2015 18:04:28 +0200
Subject: [wildfly-dev] Wildfly 9 BOM changes
Message-ID: <55916C8C.5060508@redhat.com>

Hi everyone,

While working on upgrading Hawkular to Wildfly 9 CR2, we have noticed 
that the Wildfly BOM now declares provided scope for some dependencies.

I guess the goal is to help users which forget to set the provided scope 
in their POM to end up with all the libraries in their WAR.

On the other hand, if you use some libraries in your tests, then 
dependency resolution can be broken. For example, if you add 
org.jboss.resteasy::resteasy-client in test scope, your tests fail due 
to a missing class from commons-io, because commons-io should be 
resolved as a transitive dependency of 
org.jboss.resteasy::resteasy-jaxrs, but it's now in scope provided, 
instead of test.

Have you considered this use case? Are there other motivations than 
helping Maven beginners?

Best regards,
Thomas

From bgaisford at punagroup.com  Mon Jun 29 16:12:13 2015
From: bgaisford at punagroup.com (Brandon Gaisford)
Date: Mon, 29 Jun 2015 10:12:13 -1000
Subject: [wildfly-dev] WFCORE-648 Cascade Ear Exclusions Test Case
In-Reply-To: <82A69932-E9E5-4E88-9ECB-BDB5614877C9@punagroup.com>
References: <364FBE5A-B12F-49FF-A556-FC8BBF20A516@punagroup.com>
	<55885E16.7010809@redhat.com>
	<82A69932-E9E5-4E88-9ECB-BDB5614877C9@punagroup.com>
Message-ID: <3FFC7368-B30B-43E3-97B1-2BC1459F41FD@punagroup.com>


Hey all,

I?ve completed the integration test case for WFCORE-648.  I?m just about to commit and create a PR against full.  Given that the core functionality doesn?t exist yet (outstanding PR in core) from the perspective of full, this integration test will fail the automatic tests kicked off by the CI.  I?m wondering if I should proceed with the PR?

Brandon    

On Jun 23, 2015, at 7:45 AM, Brandon Gaisford <bgaisford at punagroup.com> wrote:

> 
> Thanks, I?ve created a PR for visibility.  I?ll keep working on the test cases.
> 
> https://github.com/wildfly/wildfly-core/pull/834
> 
> Brandon
> 
> On Jun 22, 2015, at 9:12 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
>> I don't know enough about the details of this to have any suggestions 
>> re: how to validate that the exclusions are correct. But I don't think 
>> DeploymentAddHandlerTestCase is a good base to work from. It's a unit 
>> test of a particular class that uses mocks and doesn't involve 
>> DeploymentUnitProcessors at all. You probably need an integration test.
>> 
>> On 6/22/15 1:35 PM, Brandon Gaisford wrote:
>>> Hey all,
>>> 
>>> I?ve completed my initial coding for this issue and spent 2-3 hours now trying to come up with a good test case.  I?ve created a test ear that I was planning to include as a test resource to deploy during unit testing.
>>> 
>>> When I debug using the test ear during normal server startup, I?m seeing this operation and resource within the DeploymentDeployHandler:
>>> 
>>> operation
>>> {
>>>  "operation" => "deploy",
>>>  "address" => [("deployment" => "test-ear.ear")]
>>> }
>>> 
>>> resource
>>> {
>>>  "persistent" => false,
>>>  "owner" => [
>>>      ("subsystem" => "deployment-scanner"),
>>>      ("scanner" => "default")
>>>  ],
>>>  "runtime-name" => "test-ear.ear",
>>>  "content" => [{"hash" => bytes {
>>>      0x00, 0xbb, 0x8a, 0x3a, 0x61, 0x12, 0xa6, 0xec,
>>>      0x59, 0x69, 0xab, 0x9d, 0xda, 0xe1, 0x48, 0x0e,
>>>      0x68, 0x92, 0x9a, 0x03
>>>  }}],
>>>  "enabled" => undefined
>>> }
>>> 
>>> I was thinking I could model my test case after the existing DeploymentAddHandlerTestCase (but instead target DeploymentDeployHandler) and then during the deployment phase inspect some internal state to verify the exclusions are correct in the ModuleStructureSpec.  But now I?m questioning whether this is a bridge too far.
>>> 
>>> Does anyone have any bright ideas or advice on how I might move forward on this test case?
>>> 
>>> Thanks,
>>> 
>>> Brandon
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> 
>> 
>> 
>> -- 
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 



From brian.stansberry at redhat.com  Mon Jun 29 16:18:15 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 29 Jun 2015 15:18:15 -0500
Subject: [wildfly-dev] WFCORE-648 Cascade Ear Exclusions Test Case
In-Reply-To: <3FFC7368-B30B-43E3-97B1-2BC1459F41FD@punagroup.com>
References: <364FBE5A-B12F-49FF-A556-FC8BBF20A516@punagroup.com>	<55885E16.7010809@redhat.com>	<82A69932-E9E5-4E88-9ECB-BDB5614877C9@punagroup.com>
	<3FFC7368-B30B-43E3-97B1-2BC1459F41FD@punagroup.com>
Message-ID: <5591A807.7000605@redhat.com>

Sure, that's fine. Just leave a comment about it in the PR description. 
For example, https://github.com/wildfly/wildfly/pull/7635

On 6/29/15 3:12 PM, Brandon Gaisford wrote:
>
> Hey all,
>
> I?ve completed the integration test case for WFCORE-648.  I?m just about to commit and create a PR against full.  Given that the core functionality doesn?t exist yet (outstanding PR in core) from the perspective of full, this integration test will fail the automatic tests kicked off by the CI.  I?m wondering if I should proceed with the PR?
>
> Brandon
>
> On Jun 23, 2015, at 7:45 AM, Brandon Gaisford <bgaisford at punagroup.com> wrote:
>
>>
>> Thanks, I?ve created a PR for visibility.  I?ll keep working on the test cases.
>>
>> https://github.com/wildfly/wildfly-core/pull/834
>>
>> Brandon
>>
>> On Jun 22, 2015, at 9:12 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>>> I don't know enough about the details of this to have any suggestions
>>> re: how to validate that the exclusions are correct. But I don't think
>>> DeploymentAddHandlerTestCase is a good base to work from. It's a unit
>>> test of a particular class that uses mocks and doesn't involve
>>> DeploymentUnitProcessors at all. You probably need an integration test.
>>>
>>> On 6/22/15 1:35 PM, Brandon Gaisford wrote:
>>>> Hey all,
>>>>
>>>> I?ve completed my initial coding for this issue and spent 2-3 hours now trying to come up with a good test case.  I?ve created a test ear that I was planning to include as a test resource to deploy during unit testing.
>>>>
>>>> When I debug using the test ear during normal server startup, I?m seeing this operation and resource within the DeploymentDeployHandler:
>>>>
>>>> operation
>>>> {
>>>>   "operation" => "deploy",
>>>>   "address" => [("deployment" => "test-ear.ear")]
>>>> }
>>>>
>>>> resource
>>>> {
>>>>   "persistent" => false,
>>>>   "owner" => [
>>>>       ("subsystem" => "deployment-scanner"),
>>>>       ("scanner" => "default")
>>>>   ],
>>>>   "runtime-name" => "test-ear.ear",
>>>>   "content" => [{"hash" => bytes {
>>>>       0x00, 0xbb, 0x8a, 0x3a, 0x61, 0x12, 0xa6, 0xec,
>>>>       0x59, 0x69, 0xab, 0x9d, 0xda, 0xe1, 0x48, 0x0e,
>>>>       0x68, 0x92, 0x9a, 0x03
>>>>   }}],
>>>>   "enabled" => undefined
>>>> }
>>>>
>>>> I was thinking I could model my test case after the existing DeploymentAddHandlerTestCase (but instead target DeploymentDeployHandler) and then during the deployment phase inspect some internal state to verify the exclusions are correct in the ModuleStructureSpec.  But now I?m questioning whether this is a bridge too far.
>>>>
>>>> Does anyone have any bright ideas or advice on how I might move forward on this test case?
>>>>
>>>> Thanks,
>>>>
>>>> Brandon
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From lthon at redhat.com  Tue Jun 30 04:00:02 2015
From: lthon at redhat.com (Ladislav Thon)
Date: Tue, 30 Jun 2015 10:00:02 +0200
Subject: [wildfly-dev] Migration content needed for AS 7 --> WildFly 10
In-Reply-To: <9CC2853B-D743-4B2D-B7E0-280C96DE49EB@redhat.com>
References: <5575C57F.60501@redhat.com>
	<9CC2853B-D743-4B2D-B7E0-280C96DE49EB@redhat.com>
Message-ID: <55924C82.3090003@redhat.com>

Regarding clustering, the changes are described in detail in
https://developer.jboss.org/wiki/ClusteringChangesInWildFly8

The user-facing changes I'm aware of are:

- deprecations/reinterpretations of the configuration in jboss-web.xml
- EJBs no longer have to be marked @Clustered
- new (and public) API for HA singletons
- clustered SSO

LT

On 29.6.2015 17:37, Eduardo Martins wrote:
> I would like to invite everyone to have a quick look at current state of
> the document, and see if there are missing topics (I think there is
> chance wrt server a clustering section is needed, and wrt apps a Logging
> section may be needed) or incorrect information.
> 
> Wrt the TODOs in the docs, these I?m working out.
> 
> ?E
> 
>> On 08 Jun 2015, at 17:40, Sande Gilda <sgilda at redhat.com
>> <mailto:sgilda at redhat.com>> wrote:
>>
>> I am responsible for documenting how to migrate an application from AS
>> 7 to Wildfly 10 and have created the following page to document these
>> changes:
>>
>>     https://docs.jboss.org/author/display/WFLY10/How+do+I+migrate+my+application+from+AS7+to+WildFly
>>
>> If you worked on a component that has changed or been replaced, or
>> have experience or knowledge about what needs to be updated when
>> migrating an AS 7 application to Wildfly 10, please consider adding
>> content to this page. Those of you who were around for AS 7 will
>> recall I did this for migration from AS5/6 --> AS7 (see
>> https://docs.jboss.org/author/display/AS72/How+do+I+migrate+my+application+from+AS5+or+AS6+to+AS7)
>> and everyone was great about contributing to that content.
>>
>> Thanks in advance and please contact me if you have any questions!
>>
>> Thanks,
>> Sande
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 


From brian.stansberry at redhat.com  Tue Jun 30 14:30:12 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 30 Jun 2015 13:30:12 -0500
Subject: [wildfly-dev] Capabilit integration from services and
	DeploymentUnitProcessors
Message-ID: <5592E034.1080505@redhat.com>

tl;dr; DUPs may need access to the integration APIs provided by 
capabilities. I've got a first cut solution to that, but there are edge 
cases that don't work well and we may need to restrict how capabilities 
work a bit.

Long version.

WildFly Core capabilities are meant to provide a standardized way for 
parts of the server to integrate with each other.[1]

Use of these is proceeding pretty nicely in the OperationStepHandlers 
the kernel and subsystems use for executing management operations. But 
in some cases, the code that needs to integrate with a capability isn't 
in an OSH. It can be in a service start method, particularly in a 
DeploymentUnitProcessor. (DUPs run in a service start method.)

A simple example would be a deployment descriptor or annotation includes 
a chunk of config that specifies the use of a subsystem-provided 
resource, say a cache. The DUP then wants to figure out the service name 
of that resource, using capabilities.

So I've started to give some thought to how to handle that. See 
https://github.com/bstansberry/wildfly-core/commit/ba7321bc30374b2d0aa99cbf344d50b50fa2eea6 
for a first cut.

Basically the OperationContext exposes a "CapabilityServiceSupport" 
object that OSHs can provide to services they install. The services can 
then use that to look up service names and any custom runtime API 
provided by a capability.

Typical pattern would be the OSH for a "deploy" op would make the 
CapabilityServiceSupport available to RootDeploymentUnitService, which 
would expose it to DUPs via a DeploymentPhaseContext attachment. DUPs, 
as they install services would use the CapabilityServiceSupport to look 
up service names and add dependencies to that new service.

The service doesn't register any requirement for the capability. If it 
tries to use a non-existent capability, an exception is thrown and the 
service has to deal with it. *This is the main problem.* The caller is 
unable to register a dependency (since it can't get the service name) so 
the MSC behavior of letting the service be installed but fail to start 
due to a missing dependency is short circuited.

In most cases, if a service is installed but fails to start due to a 
missing dependency, the management op that installed it is rolled back, 
so the end result is the same. But we do support the 
"rollback-on-runtime-failure=false" management op header, and if that's 
used our behavior would be changed for the worse.

A possible partial solution to this would be to tighten down the rules 
for how service names are created from capability names. Basically, any 
capability could only provide 1 service, and the name of the service 
would be the result of passing the name of the capability to 
ServiceName.parse(name). That's the default behavior now, but we support 
other options.

That would fix the service name discovery problem, by making the name 
discovery algorithm completely static. It wouldn't help with a case 
where a DUP needs access to a custom runtime API exposed by a 
capability. But that is much more of a corner case. Probably better to 
discuss on a sub branch of this thread. :)

What would we lose if we tightened down the service name rules?

1) Capabilities would not be able to tell the service name discovery 
logic to produce some legacy service naming pattern (i.e. keep service 
names as they were in earlier releases.)

This one I don't think is a big deal, as the capability can always 
register an alias for the service that uses the legacy service name.

2) A capability cannot provide services of > 1 value type. It's nice if 
capabilities can represent something that's meaningful to an end user, 
and there's no reason why something that's meaningful to an end user 
might not expose more than one service to other capabilities. If we 
limit capabilities to exposing a single service, then we may end up with 
multiple capabilities. See [2] for an example case, where a proposed 
"org.wildfly.iiop" (nice and simple for an end user to understand) 
installs two services, an ORB and a NamingContextExt.

At this point though, capability names aren't really exposed to end 
users, so perhaps we can put this problem aside for now. If it becomes 
an issue later, there are solutions, e.g. a user-friendly 
"org.wildfly.iiop" capability automatically registers the detailed 
"org.wildfly.iiop.orb" and "org.wildfly.iiop.naming" capabilities, 
helping the user ignore the details.

Sorry for the long tome; by now I expect folks are used to it!

[1] Specifically, to validate that references to other parts of the 
configuration are valid, to determine the names of MSC services provided 
by other parts of the system, and to access any custom runtime 
integration API exposed by another part of the system.

[2] 
https://github.com/bstansberry/wildfly/commit/b9de64e046404531df466288cf4fb1f99b917636#diff-04ae38c6384a018059f5411e261f0d61R86

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From jperkins at redhat.com  Tue Jun 30 17:44:41 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Tue, 30 Jun 2015 14:44:41 -0700
Subject: [wildfly-dev] Capabilit integration from services and
 DeploymentUnitProcessors
In-Reply-To: <5592E034.1080505@redhat.com>
References: <5592E034.1080505@redhat.com>
Message-ID: <55930DC9.7050703@redhat.com>



On 06/30/2015 11:30 AM, Brian Stansberry wrote:
> tl;dr; DUPs may need access to the integration APIs provided by
> capabilities. I've got a first cut solution to that, but there are edge
> cases that don't work well and we may need to restrict how capabilities
> work a bit.
>
> Long version.
>
> WildFly Core capabilities are meant to provide a standardized way for
> parts of the server to integrate with each other.[1]
>
> Use of these is proceeding pretty nicely in the OperationStepHandlers
> the kernel and subsystems use for executing management operations. But
> in some cases, the code that needs to integrate with a capability isn't
> in an OSH. It can be in a service start method, particularly in a
> DeploymentUnitProcessor. (DUPs run in a service start method.)
>
> A simple example would be a deployment descriptor or annotation includes
> a chunk of config that specifies the use of a subsystem-provided
> resource, say a cache. The DUP then wants to figure out the service name
> of that resource, using capabilities.
Data sources are another good example. A data source can be defined in 
the datasource subsystem, in a deployment with an *-ds.xml descriptor or 
a couple standard Java EE ways. I've opened a PR [1] to expose the 
subsystem resource as a capability. I registered the legacy service name 
as an alias to the capabilities resolved service name. I don't however 
use the capability service name for the services added via the DUP's. 
One reason being the support wasn't there for it, though it could be 
done with some simple helpers. The second reason is some what of a 
tangent and off topic, but I'll go ahead with it :)

For data source resources a dynamic RuntimeCapability is used. The 
dynamic name for the capability is the name of resource, e.g. ExampleDS 
for the default configuration. This is useful for things like the batch 
subsystem that may need a data source but don't want to rely on a JNDI 
name as it's messy. However deployments that define their own data 
source, say via @DataSourceDefinition annotation, don't have a resource 
so the name used for the service is the JNDI name. While that's 
irrelevant to a subsystem that wants the capability it is relevant to a 
say a JPA deployment that needs to know which data source to use based 
on the JNDI name. That requires that a service always have an alias to 
match the DUP dependency service name for the data source to avoid 
duplicate entries.

After re-reading the above I'm not sure what I'm on about and it seems 
very off topic for this subject. I'm leaving it however as just 
something for others to think about when add capabilities.

[1]: https://github.com/wildfly/wildfly/pull/7682
>
> So I've started to give some thought to how to handle that. See
> https://github.com/bstansberry/wildfly-core/commit/ba7321bc30374b2d0aa99cbf344d50b50fa2eea6
> for a first cut.
>
> Basically the OperationContext exposes a "CapabilityServiceSupport"
> object that OSHs can provide to services they install. The services can
> then use that to look up service names and any custom runtime API
> provided by a capability.
>
> Typical pattern would be the OSH for a "deploy" op would make the
> CapabilityServiceSupport available to RootDeploymentUnitService, which
> would expose it to DUPs via a DeploymentPhaseContext attachment. DUPs,
> as they install services would use the CapabilityServiceSupport to look
> up service names and add dependencies to that new service.
>
> The service doesn't register any requirement for the capability. If it
> tries to use a non-existent capability, an exception is thrown and the
> service has to deal with it. *This is the main problem.* The caller is
> unable to register a dependency (since it can't get the service name) so
> the MSC behavior of letting the service be installed but fail to start
> due to a missing dependency is short circuited.
If it's somewhat considered a capability maybe short-circuiting the MSC 
behavior is okay. I suppose in cases where that could be an issue an 
alias could be used and then a standard ServiceName dependency added to 
the DUP service.
>
> In most cases, if a service is installed but fails to start due to a
> missing dependency, the management op that installed it is rolled back,
> so the end result is the same. But we do support the
> "rollback-on-runtime-failure=false" management op header, and if that's
> used our behavior would be changed for the worse.
>
> A possible partial solution to this would be to tighten down the rules
> for how service names are created from capability names. Basically, any
> capability could only provide 1 service, and the name of the service
> would be the result of passing the name of the capability to
> ServiceName.parse(name). That's the default behavior now, but we support
> other options.
>
> That would fix the service name discovery problem, by making the name
> discovery algorithm completely static. It wouldn't help with a case
> where a DUP needs access to a custom runtime API exposed by a
> capability. But that is much more of a corner case. Probably better to
> discuss on a sub branch of this thread. :)
>
> What would we lose if we tightened down the service name rules?
>
> 1) Capabilities would not be able to tell the service name discovery
> logic to produce some legacy service naming pattern (i.e. keep service
> names as they were in earlier releases.)
>
> This one I don't think is a big deal, as the capability can always
> register an alias for the service that uses the legacy service name.
>
> 2) A capability cannot provide services of > 1 value type. It's nice if
> capabilities can represent something that's meaningful to an end user,
> and there's no reason why something that's meaningful to an end user
> might not expose more than one service to other capabilities. If we
> limit capabilities to exposing a single service, then we may end up with
> multiple capabilities. See [2] for an example case, where a proposed
> "org.wildfly.iiop" (nice and simple for an end user to understand)
> installs two services, an ORB and a NamingContextExt.
>
> At this point though, capability names aren't really exposed to end
> users, so perhaps we can put this problem aside for now. If it becomes
> an issue later, there are solutions, e.g. a user-friendly
> "org.wildfly.iiop" capability automatically registers the detailed
> "org.wildfly.iiop.orb" and "org.wildfly.iiop.naming" capabilities,
> helping the user ignore the details.
Having more than one service tied to a capability is something I didn't 
think of. I like the idea of a 1-1 relationship between a service and a 
capability, but it does make sense what's happening here for IIOP.

I guess one idea might be to provide some kind of parent/child 
relationship. Maybe not a deep hierarchy but something where I could say 
as a consumer give me "org.wildfly.iiop" and I'd get "orb" and "naming" 
capabilities. Or just say give me the "org.wildfly.iiop.orb" only 
capability. Though this will probably really complicate things.
>
> Sorry for the long tome; by now I expect folks are used to it!
>
> [1] Specifically, to validate that references to other parts of the
> configuration are valid, to determine the names of MSC services provided
> by other parts of the system, and to access any custom runtime
> integration API exposed by another part of the system.
>
> [2]
> https://github.com/bstansberry/wildfly/commit/b9de64e046404531df466288cf4fb1f99b917636#diff-04ae38c6384a018059f5411e261f0d61R86
>

-- 
James R. Perkins
JBoss by Red Hat


From eduardo.santanadasilva at gmail.com  Tue Jun 30 20:52:03 2015
From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=)
Date: Tue, 30 Jun 2015 21:52:03 -0300
Subject: [wildfly-dev] WFLY-4200 WAR MDB cannot obtain superclass on
	module classpath
In-Reply-To: <CAFVp3Z5PYKDD1fk=bxs9M08Bdh+zYuyWaB6wmuYUOXJKgkqpYw@mail.gmail.com>
References: <CAFVp3Z5PYKDD1fk=bxs9M08Bdh+zYuyWaB6wmuYUOXJKgkqpYw@mail.gmail.com>
Message-ID: <CAFVp3Z5hzV+1ezqOaugfXpDqh8TAzEbiVhdas_TtJLGpvp5rdA@mail.gmail.com>

Hello, I'm planning to do something regarding  WFLY-4200, I've sent an
e-mail a few months ago about that and I will need some clarifications.

I don't know if I'm right, but I'm seeing a big problem with that if this
is really a bug. What other checks are being done that cause the deployment
abort in the other phases before resolving the dependencies that could be
turn the deployment in a qualified one?

https://issues.jboss.org/browse/WFLY-4200

Regards,
Eduardo Sant'Ana da Silva

2015-05-02 19:23 GMT-03:00 Eduardo Sant?Ana da Silva <
eduardo.santanadasilva at gmail.com>:

> I was looking at :WFLY-4200 WAR MDB cannot obtain superclass on module
> classpath
>
> This is what I posted about it:
>
>
> "I believe that the problem is because
> AnnotatedEJBComponentDescriptionDeploymentUnitProcessor executes in the
> parse phase:
>
> Phase.PARSE,Phase.PARSE_CREATE_COMPONENT_DESCRIPTIONS
>
> Since the dependencies will be resolved at  Phase.DEPENDENCIES, your build
> will not work.
> Regarding WFLY, my suggestion is not throw the
> EjbLogger.ROOT_LOGGER.mdbDoesNotImplementNorSpecifyMessageListener(beanClass)
> only bring up some flag that the required interfaces were not yet resolved,
> some attachment could be useful, just to retain the super class name. When
> the dependencies were solved, the class will be present on the class index
> and the test against the annotation should be performed again. Since that
> work will be done twice, to verify the required interfaces, this requires
> some experts advice."
>
> Thanks,
> --
> __________________________
> Eduardo Sant'Ana da Silva
>
>


--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150630/a18456ee/attachment.html