November 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ] Rob Stryker commented on WFLY-2426: ----------------------------------- > resp. https://github.com/jbossas/jboss-eap/blob/b8f636d9a765fcfe67cf0a8e2ff2804... This file is already scanned by our tools to get the information. There were previous bugs in our implementation regarding our incorrect implementation of it (see JBIDE-14993, there was a 2nd jira about it but i cant find it). We had previously been looking in "modules/system/layers/" + layer + "/org/jboss/as/product/" + layer + "/dir/META-INF"; but it seems we should have been looking in "modules/system/layers/" + layer + "/org/jboss/as/product/" + slot + "/dir/META-INF"; I don't think this file needs to be moved to root. It's useful where it is now, since all finally agree on where this file should live. But I believe this needs to be more official and perhaps have some type of unit test if it's at all possible to ensure that every release has this file in the proper location. It's pretty official now, and more people do depend on it, so it seems it's pretty stable at this point and won't need to be moved up to root. > Easily accessible static information describing the release > ----------------------------------------------------------- > > Key: WFLY-2426 > URL: https://issues.jboss.org/browse/WFLY-2426 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Server > Reporter: Brian Stansberry > > Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly. > This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build. > The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity. > The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution? > The solution to this issue should consider the implications for the patching tool. > [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2471) jboss-as-infinispan_1_4.xsd differs between EAP and WildFly

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2471?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-2471: ----------------------------------- Assignee: Paul Ferraro (was: Darran Lofthouse) > jboss-as-infinispan_1_4.xsd differs between EAP and WildFly > ----------------------------------------------------------- > > Key: WFLY-2471 > URL: https://issues.jboss.org/browse/WFLY-2471 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Darran Lofthouse > Assignee: Paul Ferraro > Fix For: 8.0.0.CR1 > > > The schema 'jboss-as-infinispan_1_4.xsd' is not in sync between EAP and WildFly. > For a given namespace there is supposed to be only one definition and that definition is frozen as soon as it reaches a Final release. > The following commit affected version 1.4 of the schema in WildFly but did not make it to the EAP version: - > https://github.com/wildfly/wildfly/commit/a9ed468bba498d55c2aa8008100f0f9... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2427) Launcher API

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/WFLY-2427?page=com.atlassian.jira.plugin.... ] Rob Stryker commented on WFLY-2427: ----------------------------------- I agree with all points here above. As far as the way jbt currently works, the areas that we constantly have to replicate each time a new app server comes out is getting: 1) The required classpath 2) The default launch program args 3) The default vm args If we were only using this to acquire the default arguments, then it seems useful for us. I'm sure others may use the launch() method, but not tools, as has been said above. I agree that which vm to use is out of scope, but, if in any situation the arguments will change based on the VM, then we (tools) should be given the opportunity to pass in a VM location. I'm not sure if this is easily accomplished on the utility lib's end, though. If we were to pass to you a specific VM root directory, would you be able to figure out how to customize the args based on that? > Launcher API > ------------ > > Key: WFLY-2427 > URL: https://issues.jboss.org/browse/WFLY-2427 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Server > Reporter: Brian Stansberry > Assignee: Rob Stryker > > 1) The AS should have some sort of API for launching our processes so tools that want a process have a clear contract instead of having to guess at what's relevant in our ever-changing scripts. > 2) We want the main class in our process launch to be what's invoked by java -jar jboss-modules.jar. We don't want java -jar jboss-as-launcher.jar which does some stuff and then calls org.jboss.modules.Main. > 3) JBoss Modules itself shouldn't have a lot of the stuff in it that's relevant to an AS launcher API, because many of those things are not relevant to JBoss Modules in a generic sense. > What we could do though is provide a launcher lib that isn't involved at all in our normal boot. Something that would only be used by tools that want to launch a separate, i.e. non-embedded, AS process. > So, some sort of stable configuration API and then a simple > java.lang.Process launch() > Basically, a utility that does the ProcessBuilder stuff that everybody is doing themselves now. > h2. HOWEVER... > Eclipse-based tools like JBDS use Eclipse APIs for launch and would not use the above launch() method. > So, besides that launch method, look into adding some methods to give the necessary inputs to the Eclipse API be useful. So Eclipse-based tools don't ask it for the process but can still get a standard launch configuration. > I'd only want to do that if those methods would return something generally understandable, but a String or List<String> for classpath, List<String>s for vm/program args, some representation that "-jar jboss-modules.jar" is the way to get the main class -- those all seem generic enough. > Any "which VM" stuff is consider out of scope; choosing the VM is the responsibility of the tool. Options that are not universally supported across VMs and are those a function of VM choice, like whether to use -server, are also out of scope. > h2. Example of EAP 6.0 launch: > VM arguments: > -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/max/products/runtimes/jboss-eap-6.0/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/max/products/runtimes/jboss-eap-6.0/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/max/products/runtimes/jboss-eap-6.0" > Program argument: > -mp "/Users/max/products/runtimes/jboss-eap-6.0/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b localhost --server-config=standalone.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-795) jboss-ejb-iiop_1_0.xsd has both use="required" and default attributes on some elements

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-795?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration updated WFLY-795: ----------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1028412 > jboss-ejb-iiop_1_0.xsd has both use="required" and default attributes on some elements > -------------------------------------------------------------------------------------- > > Key: WFLY-795 > URL: https://issues.jboss.org/browse/WFLY-795 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Reporter: James Livingston > Assignee: David Lloyd > Fix For: 8.0.0.CR1 > > > In jboss-ejb-iiop_1_0.xsd, the "integrity", "confidentiality", "establish-trust-in-client", and "establish-trust-in-target" attributes on the "iorTransportConfigType" complexType, and the "auth-method", "realm" and "required" attributes on the "iorASContextType" complexType have both use="required" and a default attribute. > This does not make sense because default values are only applicable to optional attributes. I'm not sure which is correct, but either the attributes should be optional or the default values removed. This problem causes the XSD to not validate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-795) jboss-ejb-iiop_1_0.xsd has both use="required" and default attributes on some elements

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-795?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-795: ---------------------------------------------- Darran Lofthouse <darran.lofthouse(a)redhat.com> made a comment on [bug 1028412|https://bugzilla.redhat.com/show_bug.cgi?id=1028412] Description of problem: The WildFly version of this schema was cleaned up meaning the EAP version is no longer in sync - as the upstream changes were to fix the schema these changes should be backported to EAP so that the schemas match again. > jboss-ejb-iiop_1_0.xsd has both use="required" and default attributes on some elements > -------------------------------------------------------------------------------------- > > Key: WFLY-795 > URL: https://issues.jboss.org/browse/WFLY-795 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Reporter: James Livingston > Assignee: David Lloyd > Fix For: 8.0.0.CR1 > > > In jboss-ejb-iiop_1_0.xsd, the "integrity", "confidentiality", "establish-trust-in-client", and "establish-trust-in-target" attributes on the "iorTransportConfigType" complexType, and the "auth-method", "realm" and "required" attributes on the "iorASContextType" complexType have both use="required" and a default attribute. > This does not make sense because default values are only applicable to optional attributes. I'm not sure which is correct, but either the attributes should be optional or the default values removed. This problem causes the XSD to not validate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2473) Upgrade to JBossWS 4.2.3.Final

by Alessio Soldano (JIRA)

Alessio Soldano created WFLY-2473: ------------------------------------- Summary: Upgrade to JBossWS 4.2.3.Final Key: WFLY-2473 URL: https://issues.jboss.org/browse/WFLY-2473 Project: WildFly Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Web Services Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: 8.0.0.CR1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2472) jboss-as-xts_1_0.xsd in WildFly modified since EAP release

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-2472: -------------------------------------- Summary: jboss-as-xts_1_0.xsd in WildFly modified since EAP release Key: WFLY-2472 URL: https://issues.jboss.org/browse/WFLY-2472 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Transactions Reporter: Darran Lofthouse Assignee: Tom Jenkinson Fix For: 8.0.0.CR1 The schema 'jboss-as-xts_1_0.xsd' has been modified in WildFly making it incompatible with the version in EAP - additional elements have been added. The following commit is where additional elements were added: - https://github.com/wildfly/wildfly/commit/09dda67ed71b9f5cf4c9f865f08bbe3... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2471) jboss-as-infinispan_1_4.xsd differs between EAP and WildFly

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2471?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-2471: ----------------------------------- Summary: jboss-as-infinispan_1_4.xsd differs between EAP and WildFly (was: jboss-as-infinispan_1_4.xsd) > jboss-as-infinispan_1_4.xsd differs between EAP and WildFly > ----------------------------------------------------------- > > Key: WFLY-2471 > URL: https://issues.jboss.org/browse/WFLY-2471 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.CR1 > > > The schema 'jboss-as-infinispan_1_4.xsd' is not in sync between EAP and WildFly. > For a given namespace there is supposed to be only one definition and that definition is frozen as soon as it reaches a Final release. > The following commit affected version 1.4 of the schema: - > https://github.com/wildfly/wildfly/commit/a9ed468bba498d55c2aa8008100f0f9... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2471) jboss-as-infinispan_1_4.xsd differs between EAP and WildFly

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2471?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-2471: ----------------------------------- Description: The schema 'jboss-as-infinispan_1_4.xsd' is not in sync between EAP and WildFly. For a given namespace there is supposed to be only one definition and that definition is frozen as soon as it reaches a Final release. The following commit affected version 1.4 of the schema in WildFly but did not make it to the EAP version: - https://github.com/wildfly/wildfly/commit/a9ed468bba498d55c2aa8008100f0f9... was: The schema 'jboss-as-infinispan_1_4.xsd' is not in sync between EAP and WildFly. For a given namespace there is supposed to be only one definition and that definition is frozen as soon as it reaches a Final release. The following commit affected version 1.4 of the schema: - https://github.com/wildfly/wildfly/commit/a9ed468bba498d55c2aa8008100f0f9... > jboss-as-infinispan_1_4.xsd differs between EAP and WildFly > ----------------------------------------------------------- > > Key: WFLY-2471 > URL: https://issues.jboss.org/browse/WFLY-2471 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.CR1 > > > The schema 'jboss-as-infinispan_1_4.xsd' is not in sync between EAP and WildFly. > For a given namespace there is supposed to be only one definition and that definition is frozen as soon as it reaches a Final release. > The following commit affected version 1.4 of the schema in WildFly but did not make it to the EAP version: - > https://github.com/wildfly/wildfly/commit/a9ed468bba498d55c2aa8008100f0f9... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2471) jboss-as-infinispan_1_4.xsd

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-2471: -------------------------------------- Summary: jboss-as-infinispan_1_4.xsd Key: WFLY-2471 URL: https://issues.jboss.org/browse/WFLY-2471 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 8.0.0.CR1 The schema 'jboss-as-infinispan_1_4.xsd' is not in sync between EAP and WildFly. For a given namespace there is supposed to be only one definition and that definition is frozen as soon as it reaches a Final release. The following commit affected version 1.4 of the schema: - https://github.com/wildfly/wildfly/commit/a9ed468bba498d55c2aa8008100f0f9... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2013