Where to add module definition in wildfly/build
by Cheng Fang
When I add a new module definition for a new sub-module into
wildfly/build directory, what is the right place?
wildfly/build/src/main/resources/modules/system/layers/base/org/wildfly/extension?
I see various modules using 3 different places:
wildfly/build/src/main/resources/modules/system/layers/base/org/wildfly/extension
wildfly/build/src/main/resources/modules/system/layers/base/org/wildfly
wildfly/build/src/main/resources/modules/system/layers/base/org/jboss/as
The hacking page (https://community.jboss.org/wiki/HackingOnWildFly)
says to use the jboss/as one, but I suspect it could be out of date.
Thanks,
Cheng
10 years, 3 months
Layering docs?
by Heiko Braun
I am looking for some documentation on the PRD layering (EAP 6.1) is supposed to work. Can someone point me into the right direction?
Regards, Heiko
10 years, 3 months
Re: [wildfly-dev] duel between JPA use of ClassFileTransformer and CDI implicit/explicit Bean Manager (why can't we just get along)...
by Scott Marlow
On 06/10/2013 09:05 AM, Steve Ebersole wrote:
> As Scott stated, Hibernate is doing the CDI calls as part of the
> EntityManagerFactory bootstrap (however that translates to WildFly
> deployment phases...). There is a difficulty with delaying these CDI
> calls. Getting around that would require either:
> 1) a 2-phase bootstrap process for the EntityManagerFactory. Even
> though that proposal was not accepted into the JPA spec, I went ahead
> and broke out Hibernate's bootstrapping into a 2-phase process, so
> WildFly (via jipijapa) could leverage that.
Lets do it this way, we can push this into JipiJapa so that only
Hibernate can do this initially. Other persistence providers can do the
same thing in JipiJapa if they also add the 2-phase support.
> 2) Creating proxies of the listeners that delegate to the real listeners
> and perform the init on first call. Ugh. Proxies calling proxies
> calling proxies... not a recipe for great performance. Not to mention
> don't call me to debug through that mess ;)
>
> There is a third option. How entity listeners are built is hidden
> behind an interface (called ListenerFactory oddly enough). I can expose
> that as an integration point for WildFly to be able to plug in whatever
> "delayed init" scheme it deems appropriate. The only reason I'd suggest
> this is if y'all feel strongly about option 2 above (I'm not comfortable
> implementing that in the Hibernate code base). But my vote would be for
> the first option.
>
> I am open to other suggestions.
>
>
> On Mon 10 Jun 2013 02:10:38 AM CDT, Jozef Hartinger wrote:
>> Weld can be started before a JPA impl without a risk of suppressing
>> ClassFileTransformers under condition that all entities are annotated
>> with @Vetoed. We could document that as a requirement.
>>
>> On 06/07/2013 06:20 PM, Scott Marlow wrote:
>>> For application deployments that use ClassFileTransformer to
>>> enhance/rewrite entity classes, we start the persistence unit service
>>> (PersistenceProvider.createContainerEntityManagerFactory()) during the
>>> Phase.FIRST_MODULE_USE (before any application classes have been
>>> loaded).
>>>
>>> For application deployments that have an explicit CDI Bean Manager,
>>> there is a beans.xml that means the ClassFileTransformer will not work,
>>> since the CDI Bean Manager will scan all of the application classes
>>> (loading them), before the persistence unit service is started (so that
>>> the persistence provider can use CDI in entity listeners).
>>>
>>> The same is also true for implicit CDI Bean manager support [1], expect
>>> all application deployments that contain an ejb3 module, will be wired
>>> for CDI (meaning JPA ClassFileTransformer support will work even less).
>>>
>>> I raised this on the JPA 2.1 EG [2] in response to an earlier
>>> discussion, about switching to a two phase approach to address problems
>>> like this (didn't discuss CDI implicit support then but am raising that
>>> now).
>>>
>>> [3] talks about why we don't create the CDI bean managers before the
>>> Install phase (would cause all application classes to be read which
>>> breaks JPA ClassFileTransformer use).
>>>
>>> [4] is for adding implicit CDI support but is blocked currently by [5].
>>>
>>> We can add persistence unit flags (jboss.as.jpa.classtransformer=false)
>>> for disabling JPA ClassFileTransformer support as a workaround but that
>>> doesn't help enough since many deployments will have implicit CDI
>>> support enabled (since they contain EJB modules). We could add a way to
>>> disable implicit CDI support as another workaround for deployments that
>>> want to use ClassFileTransformer.
>>>
>>> I'm not yet seeing a proper fix for this. Anyone else?
>>>
>>> Scott
>>>
>>> [1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_archive
>>> [2]
>>> https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2013-06/m...
>>>
>>> [3] https://issues.jboss.org/browse/WFLY-1322
>>> [4] https://issues.jboss.org/browse/WFLY-476
>>> [5] https://issues.jboss.org/browse/WFLY-1463
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
10 years, 3 months
SDDS (Silly Deployment Detector Subsystem)
by Nicklas Karlsson
(I know there has been some discussion on the topic (old community AS7-dev
postings, IRC-chat with Tomaz Cerar etc)
Hanging around the forums, I've noticed that a frequent source of
hard-to-debug deployment problems and other non-linear-behavior is that
people often try to deploy archives with conflicting dependencies (various
EE APIs/impls already on the AS, JDBC drivers, maven plugins, you name it).
Would it be worthwhile to implement a deployment processor (disabled by
default) that would act as a helpful bouncer for the deployment archive? We
could have a simple isSane(Archive) interface or something and people could
write their own implementations (that would be picked up through the java
services system or listed explicitly in some module?). Default
implementation that come to mind is
* Blacklisted packages (using Tattletale to warn users if they are bundling
e.g. EE impls/APIs)
* Version limiter (using Tattletale to warn if deployment contains too old
version of lib, e.g. Spring)
* Unused libs (using Tattletale to warn if deployment contains unused jars)
* Server provided libs (using Tattletale and JBoss Modules) to show which
dependencies could be handled by a server module dependency)
I'm not sure JBoss Modules contains any "directory" for
which-modules-provides functionality but I guess the module root could be
scanned and the resources indexed or something. Performance would not be an
issue because it's still going to be faster that a user playing around with
dependencies for days.
Thoughts?
--
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina
10 years, 3 months
Blocker on jbosgi release
by Thomas Diesler
Folks,
could someone please attend #4589 in time for Alpha2. It is a blocker for the first R5 compliant jbosgi release.
cheers
--thomas
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
10 years, 3 months
lots of tmp files from deployments
by Bill Burke
I'm running on Windows. Both AS7.1.1 and Wildfly . I've been starting
stopping the same jboss instances with the same deployments for weeks
now. There's about 100 deployments (TCK). I found that these
deployments are exploded in the standalone/tmp directory hundreds of
times so that I had like 300M+ files. I only noticed it because it
wreaked havoc on GIT and Intellij indexing.
Is this a known problem?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 3 months
Maven central repo sync
by Martin Kouba
Hi All,
is there a plan to sync WildFly artifacts (e.g. arquillian container)
with maven central?
Thanks
Martin
--
Martin Kouba
JBoss Quality Assurance Engineer
CDI TCK lead
Red Hat, Czech Republic
10 years, 3 months
JAXR backward compat
by Bartosz Baranowski
Hi
Im working on https://bugzilla.redhat.com/show_bug.cgi?id=964202 and there seems to be a problem.
Ive tried to reproduce this issue in upstream and it seems:
[Host Controller] 10:29:49,081 INFO [org.jboss.as.domain.controller.mgmt] (Remoting "port2:MANAGEMENT" task-10) JBAS010920: Server [Server:server-two] registered using connection [Channel ID 316dfe98 (inbound) of Remoting connection 248c1402 to /127.0.0.1:42158]
[Host Controller] 10:29:49,117 ERROR [org.jboss.as.controller.management-operation] (server-registration-threads - 1) JBAS014613: Operation ("describe") failed - address: ([
[Host Controller] ("profile" => "full"),
[Host Controller] ("subsystem" => "jaxr")
[Host Controller] ]) - failure description: "JBAS013452: Legacy extension 'org.jboss.as.jaxr' is not supported on servers running this version. The extension is only supported for use by hosts running a previous release in a mixed-version managed domain"
Support for this has been dropped.
Offending are two last commits: https://github.com/wildfly/wildfly/commits/master/jaxr/src/main/java/org/...
Shouldn't EAP 6 and 7 be backward compatible? If in this case answer is 'no' - is there any way to setup AS8 to reproduce this issue?
10 years, 3 months
