What repo is jboss-deployment-structure-1_0.xsd in?
by Rob Stryker
I've done a grep on the wildfly repo as well as the metadata repo, but
can't locate this xsd's source. All results are in a /target/ folder,
which (I assume) means it was brought in from elsewhere.
[rob@rawbdor jboss_stuff]$ du -a | grep "jboss-deployment-structure-1_0.xsd"
28
./wildfly/testsuite/integration/target/jbossas/docs/schema/jboss-deployment-structure-1_0.xsd
28
./wildfly/testsuite/integration/smoke/target/jbossas/docs/schema/jboss-deployment-structure-1_0.xsd
28
./wildfly/osgi/launcher/target/jbossas/docs/schema/jboss-deployment-structure-1_0.xsd
28
./wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/docs/schema/jboss-deployment-structure-1_0.xsd
28
./wildfly/arquillian/container-embedded/target/jbossas/docs/schema/jboss-deployment-structure-1_0.xsd
28
./wildfly/arquillian/container-managed-domain/target/jbossas/docs/schema/jboss-deployment-structure-1_0.xsd
28
./wildfly/arquillian/testng-integration/target/jbossas/docs/schema/jboss-deployment-structure-1_0.xsd
28
./wildfly/arquillian/container-managed/target/jbossas/docs/schema/jboss-deployment-structure-1_0.xsd
Question is due to a bug in the schema for which I'd like to make a PR
for. Specifically,
- <xsd:element name="sub-deployment" type="deploymentType" minOccurs="0"
maxOccurs="unbounded" >
+ <xsd:element name="sub-deployment" type="subDeploymentType"
minOccurs="0" maxOccurs="unbounded" >
Also, did we figure out a process for how and when to ensure the schema
at http://www.jboss.org/schema/jbossas are updated after changes to
their various repositories? ie, if my PR to
jboss-deployment-structure-1_0.xsd is accepted, how long will it take
for the website urls to be updated?
- Rob Stryker
9 years, 3 months
Early Access builds for JDK 9 b45, JDK 8u40 b21 & JDK 7u80 b04 are available on java.net
by Rory O'Donnell
Hi Jason/Tomaz,
Now that JDK 9 Early Access build images are modular [1], there is a fresh
Early Access build for JDK 9 b45 <https://jdk9.java.net/download/>
available on java.net.
The summary of changes are listed here
<http://www.java.net/download/jdk9/changes/jdk9-b45.html>
In addition, there are new Early Access builds for the ongoing update
releases.
The Early Access build for JDK 8u40 b21
<http://jdk8.java.net/download.html> is available on java.net, with the
summary of changes listed here.
<http://www.java.net/download/jdk8u40/changes/jdk8u40-b21.html>
Finally, the Early Access build for JDK 7u80 b04
<https://jdk7.java.net/download.html>is available on java.net,
with the summary of changes listed here.
<http://download.java.net/jdk7u80/changes/jdk7u80-b04.html>
As we enter the later phases of development for JDK 7u80 & JDK 8u40,
please log any show stoppers as soon as possible.
Rgds,Rory
[1] http://mreinhold.org/blog/jigsaw-modular-images
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
9 years, 3 months
ALPN support
by Stuart Douglas
Hi all,
Both SPDY and the upcoming HTTP2 protocol require the use of an SSL
extension called ALPN (Application Layer Protocol Negotiation).
Unfortunately this is not supported in current JDK's (it should appear in
JDK9), so the only way to support these protocols in Java at the moment is
to modify the boot class path and override the JDK SSL classes to add
support for this.
In practice this means add jetty-alpn-boot.jar to the boot class path,
however the exact version of the jar that is required depends on the JVM
version, which means we can't just ship a jar and add the boot class path
stuff to our startup scripts.
I have come up with a proof on concept[1] for how to deal with this, that
will download the appropriate ALPN jar for the current server if -alpn is
passed to the startup script, however we still need some way to handle this
in domain mode, where we need to make sure the servers are all started with
the appropriate parameter (worst case we could just require users to
install the appropriate JAR themselves, and then set the appropriate
JAVA_OPTS).
Hopefully the need for this will go away with Java 9, so I am not sure how
much effort we should spend dealing with this.
Does anyone have any thoughts on this?
Stuart
[1]
https://github.com/stuartwdouglas/wildfly-core/compare/wildfly:master...s...
9 years, 3 months
Core releases missing distribution binaries
by Tomaž Cerar
Hey guys,
Can we make sure that also zip files with release of wildfly core is
published in maven repo.
as for last few releases we are missing it.
This makes it hard to consume core itself for anything but usage in WildFly
full.
so guys that are doing releases, please add -Prelease or -Drelease to your
release / deploy commands.
this will also create proper distro in "dist" directory and upload it to
maven repo.
--
tomaz
9 years, 3 months
WSTestCase is failing - http://webservices.smoke.test.as.jboss.org/
by Eduardo Sant'Ana da Silva
Hello,
I'm not able to do a build with the latest version (9ae8a8d600dedd6aa6e80d469921aa2d8ee43eb1) , the test case WSTestCase is failing.
It is trying to connect with http://webservices.smoke.test.as.jboss.org/, that is unreachable.
14:04:24,873 WARN [org.apache.cxf.phase.PhaseInterceptorChain] (main) Interceptor for {http://webservices.smoke.test.as.jboss.org/}EndpointService#{http://webservices.smoke.test.as.jboss.org/}echoString has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: Could not send Message.
Am I doing something wrong? Is there anything to configure to override this address?
Regards,
Eduardo Sant'Ana da Silva
9 years, 3 months
Property substitution in EE annotations
by Jan Martiška
Hi,
let me ask a question. I am playing with property substitution in Java EE applications and I can't get it to work with annotations in anything else than EJB-related stuff (javax.ejb.* annotations). I tried so far:
- @javax.persistence.Table's name to parametrize the table name for an entity
- @javax.validation.constraints.Pattern's regexp parameter to parametrize a regular expression which validates a string
Neither of these seems to work for me --- Hibernate and Hibernate Validator see and try to use the raw string that I specified in the annotation (and of course fail because the syntax is wrong).
I have the /subsystem=ee:annotation-property-replacement=true, of course. As I said, for EJB-related things it works well (even when I add them to the same application).
I'm trying with the current WildFly master as well as EAP 6.3.
Per https://issues.jboss.org/browse/WFLY-2855 I understand that property replacement is meant to work with all Java EE annotations.
Is this expected, is it a bug, or might I be missing something?
Thanks!
Jan
9 years, 3 months
Re: [wildfly-dev] WildFly domain on OpenShift Origin
by Thomas Diesler
Lets start with requirements and a design that everybody who has a stake in this can be agreed on - I’ll get a doc started.
> On 18 Dec 2014, at 09:18, James Strachan <jstracha(a)redhat.com> wrote:
>
> If the EAP console is available as a Kubernetes Service we can easily add it to the hawtio nav bar like we do with Kibana, Grafana et al.
>
>> On 17 Dec 2014, at 16:17, Thomas Diesler <tdiesler(a)redhat.com <mailto:tdiesler@redhat.com>> wrote:
>>
>> Thanks James,
>>
>> I’ll look at the fabric8 hawtio console next I see if I can get it to work alongside with the wildfly console. Then I think I should meet with Heiko/Harald (for a long walk) and we talk about this some more.
>>
>> —thomas
>>
>> <PastedGraphic-1.tiff>
>>
>>> On 17 Dec 2014, at 15:59, James Strachan <jstracha(a)redhat.com <mailto:jstracha@redhat.com>> wrote:
>>>
>>> A persistent volume could be used for the pod running the DC; if the pod is restarted or if it fails over to another host the persistent volume will be preserved (using one of the shared volume mechanisms in kubernetes/openshift like Ceph/Gluster/Cinder/S3/EBS etc)
>>>
>>>> On 17 Dec 2014, at 14:42, Brian Stansberry <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote:
>>>>
>>>> On 12/17/14, 3:28 AM, Thomas Diesler wrote:
>>>>> Folks,
>>>>>
>>>>> following up on this topic, I worked a little more on WildFly-Camel in
>>>>> Kubernetes/OpenShift.
>>>>>
>>>>> These doc pages are targeted for the upcoming 2.1.0 release (01-Feb-2015)
>>>>>
>>>>> * WildFly-Camel on Docker
>>>>> <https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/docke... <https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/docke...>>
>>>>> * WildFly-Camel on OpenShift
>>>>> <https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/opens... <https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/opens...>>
>>>>>
>>>>
>>>> Great. :)
>>>>
>>>>>
>>>>> The setup looks like this
>>>>>
>>>>>
>>>>> We can now manage these individual wildfly nodes. The domain controller
>>>>> (DC) is replicated once, the host definition is replicated three times.
>>>>> Theoretically, this means that there is no single point of failure with
>>>>> the domain controller any more - kube would respawn the DC on failure
>>>>>
>>>>
>>>> I'm heading on PTO tomorrow so likely won't be able to follow up on this question for a while, but one concern I had with the Kubernetes respawn approach was retaining any changes that had been made to the domain configuration. Unless the domain.xml comes from / is written to some shared storage available to the respawned DC, any changes made will be lost.
>>>>
>>>> Of course, if the DC is only being used for reads, this isn't an issue.
>>>>
>>>>> Here some ideas for improvement …
>>>>>
>>>>> In a kube env we should be able to swap out containers based on some
>>>>> criteria. It should be possible to define these criteria, emit events
>>>>> based on them create/remove/replace containers automatically.
>>>>> Additionally a human should be able to make qualified decisions through
>>>>> a console and create/remove/replace containers easily.
>>>>> Much of the needed information is in jmx. Heiko told me that there is a
>>>>> project that can push events to influx db - something to look at.
>>>>>
>>>>> If information display contained in jmx in a console has value (e.g in
>>>>> hawtio) that information must be aggregated and visible for each node.
>>>>> Currently, we have a round robin service on 8080 which would show a
>>>>> different hawtio instance on every request - this is nonsense.
>>>>>
>>>>> I can see a number of high level items:
>>>>>
>>>>> #1 a thing that aggregates jmx content - possibly multiple MBeanServers
>>>>> in the DC VM that delegate to respective MBeanServers on other hosts, so
>>>>> that a management client can pickup the info from one service
>>>>> #2 look at the existing inluxdb thing and research into how to automate
>>>>> the replacement of containers
>>>>> #3 from the usability perspective, there may need to be an openshift
>>>>> profile in the console(s) because some operations may not make sense in
>>>>> that env
>>>>>
>>>>> cheers
>>>>> —thomas
>>>>>
>>>>> PS: looking forward to an exiting ride in 2015
>>>>>
>>>>>
>>>>>> On 5 Dec 2014, at 14:36, Thomas Diesler <tdiesler(a)redhat.com <mailto:tdiesler@redhat.com>
>>>>>> <mailto:tdiesler@redhat.com <mailto:tdiesler@redhat.com>>> wrote:
>>>>>>
>>>>>> Folks,
>>>>>>
>>>>>> I’ve recently been looking at WildFly container deployments on
>>>>>> OpenShift V3. The following setup is documented here
>>>>>> <https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/fabri... <https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/fabri...>>
>>>>>>
>>>>>> <example-rest-design.png>
>>>>>>
>>>>>> The example architecture consists of a set of three high available
>>>>>> (HA) servers running REST endpoints.
>>>>>> For server replication and failover we use Kubernetes. Each server
>>>>>> runs in a dedicated Pod that we access via Services.
>>>>>>
>>>>>> This approach comes with a number of benefits, which are sufficiently
>>>>>> explained in various OpenShift
>>>>>> <https://blog.openshift.com/openshift-v3-platform-combines-docker-kubernet... <https://blog.openshift.com/openshift-v3-platform-combines-docker-kubernet...>>,
>>>>>> Kubernetes
>>>>>> <https://github.com/GoogleCloudPlatform/kubernetes/blob/master/README.md <https://github.com/GoogleCloudPlatform/kubernetes/blob/master/README.md>> and
>>>>>> Docker <https://docs.docker.com/ <https://docs.docker.com/>> materials, but also with a number of
>>>>>> challenges. Lets look at those in more detail …
>>>>>>
>>>>>> In the example above Kubernetes replicates a number of standalone
>>>>>> containers and isolates them in a Pod each with limited access from
>>>>>> the outside world.
>>>>>>
>>>>>> * The management interfaces are not accessible
>>>>>> * The management consoles are not visible
>>>>>>
>>>>>> With WildFly-Camel we have a Hawt.io
>>>>>> <http://wildflyext.gitbooks.io/wildfly-camel/content/features/hawtio.html <http://wildflyext.gitbooks.io/wildfly-camel/content/features/hawtio.html>> console
>>>>>> that allows us to manage Camel Routes configured or deployed to the
>>>>>> WildFly runtime.
>>>>>> The WildFly console manages aspects of the appserver.
>>>>>>
>>>>>> In a more general sense, I was wondering how the WildFly domain model
>>>>>> maps to the Kubernetes runtime environment and how these server
>>>>>> instances are managed and information about them relayed back to the
>>>>>> sysadmin
>>>>>>
>>>>>> a) Should these individual wildfly instances somehow be connected to
>>>>>> each other (i.e. notion of domain)?
>>>>>> b) How would an HA singleton service work?
>>>>>> c) What level of management should be exposed to the outside?
>>>>>> d) Should it be possible to modify runtime behaviour of these servers
>>>>>> (i.e. write access to config)?
>>>>>> e) Should deployment be supported at all?
>>>>>> f) How can a server be detected that has gone bad?
>>>>>> g) Should logs be aggregated?
>>>>>> h) Should there be a common management view (i.e. console) for these
>>>>>> servers?
>>>>>> i) etc …
>>>>>>
>>>>>> Are these concerns already being addressed for WildFly?
>>>>>>
>>>>>> Is there perhaps even an already existing design that I could look at?
>>>>>>
>>>>>> Can such an effort be connected to the work that is going on in Fabric8?
>>>>>>
>>>>>> cheers
>>>>>> —thomas
>>>>>>
>>>>>> PS: it would be area that we @ wildfly-camel were interested to work on
>>>>>> _______________________________________________
>>>>>> 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 <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>
>>>
>>> James
>>> -------
>>> Red Hat
>>>
>>> Twitter: @jstrachan
>>> Email: jstracha(a)redhat.com <mailto:jstracha@redhat.com>
>>> Blog: http://macstrac.blogspot.com/ <http://macstrac.blogspot.com/>
>>>
>>> hawtio: http://hawt.io/ <http://hawt.io/>
>>> fabric8: http://fabric8.io/ <http://fabric8.io/>
>>>
>>> Open Source Integration
>>>
>>
>
>
> James
> -------
> Red Hat
>
> Twitter: @jstrachan
> Email: jstracha(a)redhat.com <mailto:jstracha@redhat.com>
> Blog: http://macstrac.blogspot.com/ <http://macstrac.blogspot.com/>
>
> hawtio: http:/ <http://fusesource.com/>/hawt.io/ <http://hawt.io/>
> fabric8: http:/ <http://fusesource.com/>/fabric8.io/ <http://fabric8.io/>
>
> Open Source Integration
>
9 years, 3 months
