Wildfly Quickstarts
by Eduardo Martins
I have been updating Wildfly Quickstarts, for now mostly reworking Maven POMs to use the updated dependencies, but it’s a long way to go, there are a lot of quickstarts, and no way all of these will be ready for primetime when WFLY 8 is out. So I was thinking in changing my strategy, and define a list with quickstarts of highest priority to be ready very soon.
The quickstarts list can be seen at http://www.jboss.org/jdf/quickstarts/get-started/
May a person related to each Java EE spec/technology go through that list and help my build the priority list? My guess is that first priority is to have the ones that show off Java EE and Wildfly 8 features only, leaving the ones that show integration with other JBoss projects for a second release, but still this will be a big list so I definitely need help.
Also, we will need new Batch quickstart(s).
Thanks in advance.
—E
10 years, 9 months
cli variables
by Alexey Loubyansky
There is this issue to provide CLI preferences
https://issues.jboss.org/browse/WFLY-1063. Here I'd like to address
mainly this part
"prod-db = /subsystem=jadada/database=jadada/
so you could call prod-db:read-resource"
I'd like to get some opinion on the way it's gonna be implemented (and
what I've done so far on a local branch).
So, to address that I introduced variables. A variable starts with a $,
e.g. $prod_db. (Using simply prod_db is not a good idea since it might
conflict with actual parts of the paths, names, etc)
Variables can be introduced with
[disconnected /] set prod_db=/subsystem=datasources/data-source=ExampleDS
Read with
[standalone@localhost:9990 /] echo prod_db
/subsystem=datasources/data-source=ExampleDS
And unset with
[standalone@localhost:9990 /] unset prod_db
'echo' without parameters will list all the variables and their values,
'set prod_db=' will have the same effect as 'unset prod_db',
set/echo/unset will work with and w/o '$' prefix, tab-completion works
everywhere.
The variables may appear in:
- operation request addresses, e.g. $prod_db/statistics=jdbc:read-resource;
- operation names, e.g. $prod_db:$op(include-runtime=true);
- operation parameter names and values, e.g.
$prod_db:$op($param=$param_value);
- the same for commands.
Tab-completion helps complete the names as long as you type in '$' and
then the rest of the line after the variable as usual.
Variables added during the session are not persisted anywhere. But I've
added .jbossclirc file. This file can be located in the current
directory, wildfly home bin directory or specified with a system
property. The content of the file is usual CLI commands and/or
operations. So, the variables could be initialized there. This file, if
located, will be executed before the CLI session (interactive or not)
starts (but also after the system properties specified with --properties
are set).
As a side effect, '$' is now a special character and will have to be
escaped. Otherwise the CLI might complain about an unresolved variable.
So, this could potentially cause problems for existing scripts using $.
Note, most of this replacement stuff can already be done with system
properties using ${xxx} format (and btw scripts using '$' as in '${xxx}'
won't be affected, of course).
And for now I've made variable names follow the rules for Java identifiers.
Any remarks, objections or suggestions?
Thanks,
Alexey
10 years, 9 months
access to mgmt api/services
by Bill Burke
Is there an example somewhere of getting access to the mgmt api from a
deployed servlet app? I'd like to be able to manage subsystem
configuration and store it (within standalone.xml or whatever).
Also, what is the best practice for managing in-VM services that are
shared between deployments (specifically services shared between web
deployments)?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 9 months
"It's The Final Countdown!"
by Jason Greene
No this isn’t the Europe song (Sorry to disappoint!).
It is however the countdown to WildFly 8 Final release!
The key things that remain are:
1) Final Components - We need PRs upgrading to “Final” for all outstanding
subcomponents[1]. If you own one of them, then please make this a high priority.
The sooner the better.
2) Identify Blockers - We need to identify all remaining blockers that have been
reported against CR1. I’m hoping everyone can look through the forms for likely
blockers and convert them to JIRAs. As a reminder a blocker is anything that is
mass user effecting and severe in nature. Examples include: hangs, crashes,
memory leaks, vulnerabilities, and data corruption.
3) JASPIC Acceptance - A few of you on this list have noted issues. We need to
ensure that the Final release has addressed the outstanding issues.
Thanks!
[1] Outstanding components.
io.undertow 1.0.0.Beta30
io.undertow.jastow 1.0.0.CR1
org.glassfish.javax.el 3.0-b07
org.hibernate.search 4.5.0.Alpha2 *exception*
org.infinispan.protostream 1.0.0.CR1
org.jberet 1.0.0.CR1
org.jboss.ejb-client 2.0.0.Beta5
org.jboss.narayana 5.0.0.CR2
org.jboss.jsfunit 2.0.0.Beta1
org.jboss.logging.jboss-logging-tools 1.2.0.Beta1
org.jboss.metadata 8.0.0.CR1
org.jboss.mod_cluster 1.3.0.Alpha1
org.jboss.msc.jboss-msc 1.2.0.CR1
org.jboss.xnio.netty.netty-xnio-transport 0.1.1.CR2
org.jboss.remote-naming 2.0.0.Beta2
org.jboss.remoting 4.0.0.Beta3
org.jboss.remotingjmx.remoting-jmx 2.0.0.CR4
org.jboss.sasl 1.0.4.CR1
org.jboss.spec.javax.el.jboss-el-api_3.0_spec 1.0.0.Beta1
org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.1_spec 1.0.0.Alpha1
org.jboss.spec.javax.security.jacc.jboss-jacc-api_1.5_spec 1.0.0.Beta1
org.jboss.spec.javax.servlet.jsp.jboss-jsp-api_2.3_spec 1.0.0.Beta1
org.jboss.spec.javax.servlet.jstl.jboss-jstl-api_1.2_spec 1.0.4.Beta1
org.jboss.xnio 3.2.0.Beta4
org.picketbox 4.0.20.Beta4
org.wildfly.security.manager 1.0.0.Beta3
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
10 years, 9 months
How to deal with resource refs when deploying JPA container managed entity managers (WFLY-2841)
by Scott Marlow
WFLY-2841 reports a deployment failure that occurs when a deployments
[1] persistence.xml, tries to use a resource reference [2] for the
datasource [3]. The error [4] mentions an unresolved (DataSource)
service dependency that is added to the persistence unit service [5],
instead of resolving the resource reference (and using the underlying
DataSource).
How should we handle resource references for this case? Is there a way
to resolve the resource reference directly from deployers? Or do we
represent the resource reference as a service?
Scott
[1] test app is at https://github.com/umartin/wfds/
[2] jboss-web.xml
<jboss-web>
<context-root>/wfds</context-root>
<resource-ref>
<res-ref-name>jdbc/MyDS</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
</resource-ref>
</jboss-web>
[3] persistence.xml pu def
<persistence-unit name="wfdsPU" transaction-type="JTA">
<jta-data-source>java:comp/env/MyDS</jta-data-source>
</persistence-unit>
[4] {"JBAS014771: Services with missing/unavailable dependencies" =>
["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
is missing
[jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
[5]
https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org...
10 years, 9 months
Re: [wildfly-dev] How to deal with resource refs when deploying JPA container managed entity managers (WFLY-2841)
by arjan tijms
On Fri, Jan 31, 2014 at 5:11 PM, Eduardo Martins <emartins(a)redhat.com>wrote:
> Sure, all you said is correct, I just said that ideally java:app bindings
> should be done at app level, and provide the reasoning behind that.
>
Indeed, but then if there's only ever a war then web.xml is at the app
level, and java:app bindings can be set without architectural concerns in
web.xml, can't they?
>
> --E
>
> On 31 Jan 2014, at 15:58, arjan tijms <arjan.tijms(a)gmail.com> wrote:
>
> Hi,
>
> On Fri, Jan 31, 2014 at 4:45 PM, Eduardo Martins <emartins(a)redhat.com>wrote:
>
>> Yes, but design wise this should be done at EAR level, preventing the
>> mistake of multiple components trying to bind same entry in java:app.
>>
>
> Is that really true if there only ever is the .war? E.g. in the sense as
> mentioned by Adam here:
> http://adam-bien.com/roller/abien/entry/is_java_ee_6_war
>
> Also, don't EJBs inside a .war share java:comp with the web module's
> single java:comp? So the entire concept of EJB beans having their own
> component namespace just goes away then. I think in the modern usage
> pattern of EJBs there's not much use for this anyway. If the CDI bean model
> effectively replaces the EJB component model in some future Java EE release
> then all of this is surely history.
>
> Effectively, in a pure web application (.war, no .ear involved) java:comp
> is effectively java:module, which should be more straightforward to
> resolve, shouldn't it?
>
>
>
>
>
>
>
>>
>> --E
>>
>> On 31 Jan 2014, at 15:08, arjan tijms <arjan.tijms(a)gmail.com> wrote:
>>
>> Hi,
>>
>> On Fri, Jan 31, 2014 at 3:03 PM, Eduardo Martins <emartins(a)redhat.com>wrote:
>>
>>> or use an ear and define a java:app bind at application.xml, to be
>>> shared by all modules and components?
>>>
>>
>> If you have just a .war, you can use java:app just as well, can't you? I
>> don't think there's a specific need to use an ear just for java:app.
>>
>> Kind regards,
>> Arjan
>>
>>
>>
>>
>>
>>
>>>
>>> --E
>>>
>>>
>>> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow(a)redhat.com> wrote:
>>>
>>> > Great, thanks for reporting the issue Martin! Great to bring more
>>> > awareness of the deployment problem and workaround.
>>> >
>>> > Scott
>>> > On 01/31/2014 08:04 AM, Martin Andersson wrote:
>>> >> Thanks a lot!
>>> >>
>>> >> I can confirm that the app works now.
>>> >>
>>> >> Br,
>>> >> Martin Andersson
>>> >> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>>> >>
>>> >>
>>> >> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow(a)redhat.com
>>> >> <mailto:smarlow@redhat.com>> wrote:
>>> >>
>>> >> Hi Arjan,
>>> >>
>>> >> Great catch! Your change and adding an persistence unit hint that
>>> the
>>> >> persistence unit doesn't need to be started early:
>>> >>
>>> >> <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>>> >>
>>> >> Helps the deployment succeed.
>>> >>
>>> >> It looks like ResourceReferenceProcessor is running during the
>>> >> Phase.POST_MODULE deployment phase, so we need to add a hint to the
>>> >> persistence.xml, that helps the persistence unit deploy later.
>>> >>
>>> >> [6]
>>> >>
>>> https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss...
>>> >>
>>> >> Scott
>>> >>
>>> >> On 01/31/2014 06:25 AM, arjan tijms wrote:
>>> >>> Hi,
>>> >>>
>>> >>> I looks like there's one bug in the example.
>>> >>>
>>> >>> jboss-web.xml defines jdbc/MyDS
>>> >>>
>>> >>> But persistence.xml references java:comp/env/MyDS
>>> >>>
>>> >>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>>> >> Regardless,
>>> >>> even with matching names it indeed doesn't work.
>>> >>>
>>> >>> Kind regards,
>>> >>> Arjan Tijms
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow(a)redhat.com
>>> >> <mailto:smarlow@redhat.com>
>>> >>> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>> wrote:
>>> >>>
>>> >>> WFLY-2841 reports a deployment failure that occurs when a
>>> >> deployments
>>> >>> [1] persistence.xml, tries to use a resource reference [2]
>>> >> for the
>>> >>> datasource [3]. The error [4] mentions an unresolved
>>> >> (DataSource)
>>> >>> service dependency that is added to the persistence unit
>>> >> service [5],
>>> >>> instead of resolving the resource reference (and using the
>>> >> underlying
>>> >>> DataSource).
>>> >>>
>>> >>> How should we handle resource references for this case? Is
>>> >> there a way
>>> >>> to resolve the resource reference directly from deployers?
>>> >> Or do we
>>> >>> represent the resource reference as a service?
>>> >>>
>>> >>> Scott
>>> >>>
>>> >>> [1] test app is at https://github.com/umartin/wfds/
>>> >>>
>>> >>> [2] jboss-web.xml
>>> >>> <jboss-web>
>>> >>> <context-root>/wfds</context-root>
>>> >>> <resource-ref>
>>> >>> <res-ref-name>jdbc/MyDS</res-ref-name>
>>> >>> <res-type>javax.sql.DataSource</res-type>
>>> >>>
>>> >>> <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>>> >>> </resource-ref>
>>> >>> </jboss-web>
>>> >>>
>>> >>> [3] persistence.xml pu def
>>> >>> <persistence-unit name="wfdsPU" transaction-type="JTA">
>>> >>> <jta-data-source>java:comp/env/MyDS</jta-data-source>
>>> >>> </persistence-unit>
>>> >>>
>>> >>> [4] {"JBAS014771: Services with missing/unavailable
>>> >> dependencies" =>
>>> >>>
>>> >>
>>> ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>>> >>> is missing
>>> >>>
>>> >>
>>> [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>>> >>>
>>> >>>
>>> >>> [5]
>>> >>>
>>> >>
>>> https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org...
>>> >>> _______________________________________________
>>> >>> wildfly-dev mailing list
>>> >>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>>> >> <mailto:wildfly-dev@lists.jboss.org
>>> >> <mailto:wildfly-dev@lists.jboss.org>>
>>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >>>
>>> >>>
>>> >>
>>> >> _______________________________________________
>>> >> wildfly-dev mailing list
>>> >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Hälsningar,
>>> >> Martin Andersson
>>> >> Purple Scout AB
>>> >> +46 732 05 14 01
>>> >
>>> > _______________________________________________
>>> > 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, 9 months
No checksum key with wildfly download.
by saurabh
Dear all,
First of all I would like to thank this community for building such a
great open source application.
I am using wildfly since it's beta release and its really amazing.
One thing I wanted to bring in to notice is that there is no
cryptographic key (md5 or sha1 sum) provided with the download.
If we could provide one it would be very helpful to verify the tampering
of the file or incomplete download.
Thanks,
Saurabh.
--
Saurabh Kumar
RHCVA,RHCSA,RHCE
10 years, 9 months
Proposal: Availability subsystem
by David M. Lloyd
I've been sitting on this idea for a while so I thought I'd put it out
there and get some feedback on it.
Problem: People want things to happen when the container is "up".
Unfortunately, there really isn't a black-and-white concept for what
"up" means. Often times, the user is simply going for "my application
will function correctly", so they can make a load-balancing decision or
perform some other monitoring action.
Semantically, the desire would be for some external mechanism to receive
a notification when the services corresponding to the specifically
applicable components have completely started or are going to stop. The
obvious implementation of such a mechanism is a service which depends on
the set of component services.
Solution 1: In theory, a user could create a deployment that performs
availability tasks in a service which depends on all the requisite
services. The user needs specific knowledge of service names in this
case, which may change, or they must use specific technologies (for
example, use a singleton EJB which @DependsOn each dependency).
Solution 2: Introduce a subsystem which allows definition of different
availability configurations. The configuration would enumerate the
items that are required for the configuration to be considered
available. The configuration would be associated with an action. We
would use management.next-style extensibility points to let the user
define add-in items like EJBs, servlets, POJOs, MBeans, CDI beans, etc.
without the subsystem needing specific knowledge of the service schemes
for each.
We could make solution 1 work more effectively by providing a more
uniform deployment-based dependency mechanism, but that seems more
complex to me than just introducing a subsystem and SPI for this purpose.
With a subsystem we could bundle actions for things like mod_cluster,
other potential future Undertow- and Remoting-based proxies, simple
notification schemes like MBean notification or logging, POST
notification, and so on.
The timeline would not be 8 (obviously), nor 9. I think having the
simplified management SPI in place is a definite prerequisite, else the
effort/reward ratio is far too low to justify doing this. Otherwise, I
think this is a simple idea that could be pretty damn useful, so I want
to put it out here so it's in the back of everyone's mind.
--
- DML
10 years, 9 months
Re: [wildfly-dev] Favour jboss-persistence.xml if present
by Klein, Christopher
> > On Jan 29, 2014, at 3:33 PM, Scott Marlow <smarlow(a)redhat.com> wrote:
> >
> >> On 01/29/2014 04:24 PM, Brian Stansberry wrote:
> >>> On 1/29/14, 3:20 PM, Scott Marlow wrote:
> >>>> On 01/29/2014 03:17 PM, Jason Greene wrote:
> >>>>
> >>>>> On Jan 29, 2014, at 2:11 PM, Scott Marlow <smarlow(a)redhat.com>
> wrote:
> >>>>>
> >>>>>> On 01/29/2014 02:44 PM, David M. Lloyd wrote:
> >>>>>>> On 01/29/2014 01:39 PM, Klein, Christopher wrote:
> >>>>>>> Hey guys,
> >>>>>>> I already filled out a feature request in JIRA
> (https://issues.jboss.org/browse/WFLY-2816).
> >>>>>>>
> >>>>>>> We have the situation that our development environment
> (currently JBoss AS 7.1.1) differs from the production instance (WebSphere
> 8.5). Our persistence.xml has to be adjusted for production environment:
> different jta-data-source, different properties. The dirty solution for this
> problem would be to generate separate build artifacts for both
> environments. As you can imagine I don't like the idea of having two binaries
> just because of a few different settings. Other options (WildFly or
> WebSphere specific JPA properties; extending Hibernate persistence
> provider) do not work.
> >>>>>>>
> >>>>>>> A much nicer solution would be: WildFly checks on deployment
> process for the existence of a jboss-persistence.xml. If it does, the jboss-
> persistence.xml is used for configuring the JPA subsystem. Otherwise it falls
> back to the standard persistence.xml. The jboss-persistence.xml would use
> the XML schema from persistence.xml.
> >>>>>>>
> >>>>>>> I lookup into the WildFly sources and this change should be an easy
> patch which I would provide.
> >>>>>>>
> >>>>>>> So here are my questsions:
> >>>>>>> 1. Are you generally interested in accepting such a pull request or is
> it a feature you don't want?
> >>>>>>> 2. Does another solution exists to my problem apart from
> generating different artifacts which makes this pull request needless?
> >>>>>>
> >>>>>> It sounds like a reasonable idea that actually applies generally.
> >>>>>> If I recall correctly, we have something of a mix today of
> >>>>>> descriptors which override versus supplementing existing
> >>>>>> configuration. But overall the unofficial policy for new
> >>>>>> descriptors has been to add them in to jboss-all.xml as
> subdescriptors, FWIW.
> >>>>>
> >>>>> I'm not sure that jboss-all.xml would be a good place for the
> >>>>> persistence unit definitions.
> >>>>
> >>>> I would agree that this is probably impractical.
> >>>>
> >>>>>
> >>>>> I think that the proposed jboss-persistence.xml (or
> >>>>> wildfly-persistence.xml) could be helpful for anyone that wants to
> >>>>> only develop on WildFly but deploy on other application servers.
> >>>>> I suppose this could help someone that wants to migrate off of
> >>>>> WildFly as well (to prepare for a switch to something else). Is
> >>>>> that what you mean by the proposed solution applying generally?
> >>>>
> >>>> It does sound a lot like a vendor specific alt-dd feature. We have some
> other solutions as well that might be relevant:
> >>>>
> >>>> 1) Deployment overlay feature - This allows you to override the
> descriptors in a deployment without modifying the deployment. These are
> added in a separate management op with a match pattern, and preserved
> outside the lifecycle of the deployment. Available in WildFly 8 and EAP 6.2
> (can’t recall if it made EAP 6.1).
> >>>
> >>> I was just reading
> >>> https://docs.jboss.org/author/display/WFLY8/Deployment+Overlays
> but
> >>> I'm not sure that would help with this use case. Since the
> >>> deployment will fail due to the persistence.xml targeting WebSphere
> >>> (persistence unit property
> >>> "hibernate.transaction.manager_lookup_class" is set to
> "org.hibernate.transaction.WebSphereExtendedJTATransactionLookup").
> >>
> >> The persistence.xml that is the deployment overlay would not include
> >> those settings. The deployment overlay feature hides the original
> >> persistence.xml in the deployment archive from the deployment
> >> processors; they only see the overlay.
> >
> > Thanks Brian, I missed that the deployment overlay is created before
> > deploying. So that could help someone crack open an archive and
> > replace the persistence.xml with one that will work.
>
> Right exactly. The disadvantage is every update to the descriptor requires an
> updates overlay.
>
> Just thinking out loud that we could do a proprietary alt-dd thing in jboss-
> all.xml where we allow you to set replacement names. E.g web.xml=other-
> web.xml etc.
>
> Then we just parse this before anything else and it would apply AFTER
> overlay.
I wasn’t aware of the overlay feature and it would indeed solve my problem, but I think it has the following disadvantages:
- The write-once-deploy-everywhere concept is a little bit broken. Every time I want to deploy the WAR into a new WildFly server I have to add the overlay command line.
- As already mentioned, a change in persistence.xml means changing the overlay file in every application server. Just redeploying with a jboss-persistence.xml is much easier.
- As a developer just by looking at the source code I don't get it instantly that the settings in persistence.xml won't be used by WildFly. Having a jbos-persistence.xml in the same directory shows me that WildFly uses other settings without reading the whole documentation. Using the overlay seems to be counterintuitively.
I looked upon the WildFly sources, did a small hack and tested it yesterday - only to showing you what I want to achieve: https://github.com/schakko/wildfly/tree/WLDFLY-2816
> >
> >>
> >>> What might help is if we could ignore (or auto-magically remove
> >>> during
> >>> deployment) certain persistence unit property settings that we know
> >>> will cause the deployment to fail.
> >>>
> >>>>
> >>>> 2) Property Substituion - There is a flag you can optionally enable in
> standalone/domain.xml that allows descriptors to contain property
> expressions. However, this only works for this use case if all venders are
> using the same expression language (unlikely). I just thought I would
> mention it.
+1
During my research how to solve the problem I wrote a very simple persistence provider which extends Hibernate (https://gist.github.com/schakko/8703966). This provider allows you to define properties like
<!-- If env var applicationserver.runtime equals jboss, rewrite this setting -->
<property name="?(applicationserver.runtime=jboss)hibernate.transaction.manager_lookup_class" value="" />
But this hasn't helped me to reference another jta-data-source :-/
10 years, 9 months
