JBossDeveloper

Yes, I'll write the schema if I still like these elements next week

I shouldn't have pushed that stuff to my github repo. I just wanted to do stuff, you know! Now that I see you have your own repo, I'll be much less likely to put stuff in based on forum posts; much better to pull when it's ready.

One problem of git that is obvious to me however is that people start having their own version of things For example, I forked Emanuel's repo, and I don't even know how to apply his changes to my repo using github.

I'm pretty much a novice. What I've been doing is using my github repo as origin for the local repo on my laptop. I add other folks' github repo as a remote on my laptop repo. Then I fetch/merge/pull stuff from others plus develop locally and push to github.

The #jboss-dev and #jboss-as7 rooms are freenode are the best places to discuss git issues.

The whole git workflow is going to be interesting; we'll see how it works long term. Here's how it's working during the AS 7 infancy.

Right now, dmlloyd's github jboss-as repo is the "official" one -- he's pulling from everyone else. Eventually Jason will take over that role, but David's doing it for now.

Jason wants a process where everything gets reviewed by someone other than the author before ending up in the "official" repo. David/Jason can't review everything, so that will mean delegating areas to other people, and David/Jason will just accept what those people push in their respective areas. I'm playing that role right now for the schema stuff, so when you or other have schema stuff you want pulled in, let me know.

Alexey, an "everything gets reviewed" process means I shouldn't be pushing my own schema changes directly to the master branch on my github repo. So I created a "schema-dev" branch; things I do myself I'll push there and if you think they're right you can merge into your master and I can pull back from you. As the process gets going faster I can see us changing roles, where you're the guy David/Jason pull from for the schema. You're more of an expert than I.

Brian Stansberry wrote:

 

A note on style. Elsewhere in the schema we seem to have settled on lower case with "-" to separate words in our element and attribute names. So, we should be consistent:

 

<xs:attributeGroup name="ssl-attlist">
    <xs:attribute name="key-alias" default="jbossweb"/>
    <xs:attribute name="password"/>
    <xs:attribute name="certificate-key-file" default="${user.home}/.keystore"/>
    <xs:attribute name="cipher-suite" default="ALL"/>
    <xs:attribute name="protocol" default="ALL" type="SSlProtocolType"/>
    <xs:attribute name="verify-client" default="none"/>
    <xs:attribute name="verify-depth" default="10"/>
    <xs:attribute name="certificate-file"/>
    <xs:attribute name="ca-certificate-file"/>
    <xs:attribute name="ca-revocation-url"/>
    <xs:attribute name="session-cache-size" default="0"/>
    <xs:attribute name="session-timeout" default="86400"/>
  </xs:attributeGroup>

 

Also, should "ALL" be in the SSLProtocolType enumeration? Or do we change the default value for the protocol attribute?

According to the standard names doc (http://java.sun.com/javase/6/docs/technotes/guides/security/StandardNames.html#SSLContext) the current options are:

1. SSL
2. SSLv2
3. SSLv3
4. TLS
5. TLSv1
6. TLSv1.1

According to the docs, SSLv2 really means "SSLv2 or higher" and there is no option for SSLv2+SSLv3 versus just SSLv2.

So maybe this should just be a String which is looked up by whatever the current provider is (JSSE or APR/OpenSSL I presume)?

David Lloyd wrote:

 

So maybe this should just be a String which is looked up by whatever the current provider is (JSSE or APR/OpenSSL I presume)?

Hmm, maybe. I think i was asking something like this to be an enumeration, since it's not very likely to change on a daily basis. Meaning that it would also be useful to see what options are actually available. So obviously it could be interesting to see how far restrictions in the configuration should go, since this could be just documentation i guess.

Emanuel Muckenhuber wrote:

 

David Lloyd wrote:

 

So maybe this should just be a String which is looked up by whatever the current provider is (JSSE or APR/OpenSSL I presume)?

Hmm, maybe. I think i was asking something like this to be an enumeration, since it's not very likely to change on a daily basis. Meaning that it would also be useful to see what options are actually available. So obviously it could be interesting to see how far restrictions in the configuration should go, since this could be just documentation i guess.

Yeah, I like the idea of restricting whenever possible, but I also think that we should think of things like this (where the range of values is dictated fully by a provider) as different.  We definitely don't want to restrict this one in particular (think of the recent renegotation vulernability - we don't want to lock people out of a fix for that kind of thing due to a XSD restriction).

On the other hand, IIUC, the schema locks the configuration options for the specific release. From that perspective, enumerating supported values for this specific version makes sense.

Brian Stansberry wrote:

Alexey, an "everything gets reviewed" process means I shouldn't be pushing my own schema changes directly to the master branch on my github repo. So I created a "schema-dev" branch; things I do myself I'll push there and if you think they're right you can merge into your master and I can pull back from you. As the process gets going faster I can see us changing roles, where you're the guy David/Jason pull from for the schema. You're more of an expert than I.

I've pulled your stuff. There are currently a lot of inconsistencies between the XML and schemas. I'm gonna fix that, post the changes and also add XML validation tests.

Thanks. They are inconsistent. Hopefully not too much so in the interfaces/socket area.

The bof-xxx-example.xml files should just be deleted; they were whipped up for a BOF and will just get out of date.

Areas I know are inconsistent between example and schema are java config stuff where David and I did some brainstorming via the example file; that needs discussion/validation; I'll open a thread on that today/tomorrow if your or David don't do it first. The "profile" notion also snuck back into the example, since a mechanism to have a named set of subsystems that can be easily applied to different server groups was necessary. I believe there's already an older thread around deployments/profiles that can be revived.

Beyond that I'm sure there are other inconsistencies.

Alexey Loubyansky wrote:

 

On the other hand, IIUC, the schema locks the configuration options for the specific release. From that perspective, enumerating supported values for this specific version makes sense.

Yeah but my point is, those values come from the environment, not from us.  For example another JVM vendor might have more or different options.  A user may choose to use that JVM just because of those options.  For JSSE/JCE especially I don't think we should ever restrict what is a valid choice for protocols or provider names.

Brief update on what I've committed today:
- added missing types and elements to reflect new things in the xml;
- adjusted some existing element and attribute names in the XML and XSD to make them consistent;
- moved uncommon (domain.xml and host.xml specific) type declarations from the common schema to the schemas they are (exclusively) used in;
- added XML validation testcase.

In the host.xml example a few changes I'd like to mention:

* namespace "urn:jboss:host:1.0" became "urn:jboss:domain:1.0"

* listed system property (under jvm element) should have a value specified?
             <system-properties>
-                <property name="foo"/>
+                <property name="foo" value="bar"/>
             </system-properties>

* jvm environment-properties changed to jvm-properties according to the existing schema

From host XSD, named-interfacesType is not used anywhere. named-interfaceType is used only as the base for specified-interfaceType.

I've commented out and added a TODO comment for cluster configuration in jboss-domain-example.xml since there is nothing close in the XSD at the moment. If that's a more or less complete example of the configuration I could add this to the schema.

And I would probably move the XML examples out of 'schema' to a separate  directory.

Alexey Loubyansky wrote:

 

* listed system property (under jvm element) should have a value specified?

             <system-properties>
-                <property name="foo"/>
+                <property name="foo" value="bar"/>
             </system-properties>

 

* jvm environment-properties changed to jvm-properties according to the existing schema

Since the JVM allows you to define system properties without a value (i.e. "-DsomeProperty"), maybe we should allow it too?  It would just mean that the value defaults to "".

I don't like "jvm-properties".  These properties are actually the environment variables for that JVM instance.  Nothing about "jvm-properties" says "environment variables" to me.  I originally chose "environment-properties" because they're environment variables but the "properties" type is reused to avoid having two types which behave identically.

I'm going to fork this thread, with a couple other ones in a minute, as this is getting far afield from the web container schema.

Ok, so I'll be dropping the shared web.xml element.

About the shared web JARs element, it would be used to point out to JARs containing TLDs and servlet container initializers. Or we could go back to looking for that in all JARs.

Where would these jars be located?