Re: [jboss-dev-forums] [JBoss AS 7 Development] - AS7 Password Vault on Windows
by merlin vincent
merlin vincent [https://community.jboss.org/people/mermeister] commented on the document
"AS7 Password Vault on Windows"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-17763#comment-10958
--------------------------------------------------
I'm running with both Java and JBossAS7 installed in directories that include spaces. This causes problems in the definition of JAVA_HOME and in the classpath used in the vault.bat file.
Given:
JAVA_HOME set to C:\Program Files (x86)\Java\jdk1.7.0_07
JBoss installed to C:\My Application Name\jboss-as-7.1.1.Final
This is the error message I got when running the vault.bat file:
\Java\jdk1.7.0_07\bin\java was unexpected at this time.
I fixed it by editing the \bin\vault.bat batch file as follows:
-- Add quotes around %JAVA_HOME% in the code that sets the JAVA environment variable (line 17):
set JAVA="%JAVA_HOME%"\bin\java
-- Add quotes around %JBOSS_VAULT_CLASSPATH% in the line that invokes the VaultTool (line 52):
%JAVA% -classpath "%JBOSS_VAULT_CLASSPATH%" org.jboss.as.security.vault.VaultTool
--------------------------------------------------
11 years, 6 months
[JBoss AS 7 Development] - Jprobe 9.6 configuration issue with Jboss AS7
by Nilofar Sayyad
Nilofar Sayyad [https://community.jboss.org/people/nilofar_sayyad] created the discussion
"Jprobe 9.6 configuration issue with Jboss AS7"
To view the discussion, visit: https://community.jboss.org/message/766275#766275
--------------------------------------------------------------
Hi,
I need to use Jprobe 9.6 with Jboss AS7 for Performance Engg Activities. Could you please help me in resolving the below issue I am facing:
I have defined a configuration for performance analysis.But when I run the script file generated by jprobe I get the following error stacktrace on console:
JProbe version 9.6.0
Copyright 2012 Quest Software Inc. ALL RIGHTS RESERVED.
JProbe is a registered trademark of Quest Software Inc.
Performance analysis started.
JProbe Connection Manager is available for Console connections on port 52991
10:26:54,445 INFO [org.jboss.modules] JBoss Modules version 1.0.2.GA
Exception in thread "main" javax.management.JMRuntimeException: Failed to load M
BeanServerBuilder class org.jboss.system.server.jmx.MBeanServerBuilderImpl: java
.lang.ClassNotFoundException: org.jboss.system.server.jmx.MBeanServerBuilderImpl
at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServ
1. erFactory.java:502)
at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanSer
* verFactory.java:538)
at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory
.java:315)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFact
* ory.java:230)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFact
* ory.java:191)
at java.lang.management.ManagementFactory.getPlatformMBeanServer(Managem
1. entFactory.java:466)
at org.jboss.modules.ModuleLoader$RealMBeanReg$1.run(ModuleLoader.java:7
41)
at org.jboss.modules.ModuleLoader$RealMBeanReg$1.run(ModuleLoader.java:7
39)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.modules.ModuleLoader$RealMBeanReg.<init>(ModuleLoader.java:
739)
at org.jboss.modules.ModuleLoader$TempMBeanReg.installReal(ModuleLoader.
java:723)
at org.jboss.modules.ModuleLoader.installMBeanServer(ModuleLoader.java:1
60)
at org.jboss.modules.Main.main(Main.java:313)
Caused by: java.lang.ClassNotFoundException: org.jboss.system.server.jmx.MBeanSe
rverBuilderImpl
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFacto
1. ry.java:445)
at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServ
1. erFactory.java:487)
... 12 more
Does jboss 7 require any specific configurations to integrate with jprobe 9.6?I have attached my <timestamp>.bat file generated by jprobe.
Thanks & regards,
Nilofar.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/766275#766275]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 6 months
[JBoss AS 7 Development] - Creating a custom HTTPSConnector is JBOSS AS 7.1
by Saran Arul
Saran Arul [https://community.jboss.org/people/saransna] created the discussion
"Creating a custom HTTPSConnector is JBOSS AS 7.1"
To view the discussion, visit: https://community.jboss.org/message/765533#765533
--------------------------------------------------------------
I need to extend the default HTTPS connector in JBOSS AS 7.1 and add some custom code. Are there any examples I can look into to get started ?
<subsystem xmlns="urn:jboss:domain:web:1.2" default-virtual-server="default-host" native="false">
<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" enable-lookups="false" secure="true">
<ssl name="ssl"
key-alias="test"
password="nextgen!"
certificate-key-file="/Users/sarul/jboss-as-7.1.3.Final/standalone/configuration/test.keystore"
protocol="TLSv1"
verify-client="false"/>
</connector>
<connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
<virtual-server name="default-host" enable-welcome-root="true">
<alias name="localhost"/>
<alias name="example.com"/>
</virtual-server>
</subsystem>
I guess my questions at this point are,
1. Which class implements the default HTTPS connector highlighted above ?
2. Is this class extensible ? Where can I find an example to do that ?
3. Once I have the extended class, how do I package it and what configuration should I change in standalone.xml to enable by custom connector ?
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/765533#765533]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 6 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Single Installation Patching
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] commented on the document
"Single Installation Patching"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-47500#comment-10948
--------------------------------------------------
I previously sent this via email, but now that yesterday's jboss.org issues are cleared up, I'll repeat it for others to see:
> Jeff Mesnil wrote:
>
>
> >
> > Brian Stansberry wrote:
> >
> > What's in thie previous-cumulative file? Just the name of the applied to version?
> Yes, for history purpose, I think it's important to tell the user which version the patch has been applied to (among all the acceptable <applies-to-version> of the patch). He would want to know what will be the resulting version of a rollback prior to perform it.
Makes sense.
> >
> > I think we are going to need to store the patch.xml, which contains that information plus much more. That or something similar. For sure we are going to need to store the hashes of any files changed in a one-off patch, plus data about any misc file changes that the user elected not to have applied. We'll need this information for when we apply a CP on top of a one-off patch.
> This contradicts the previous sentence about cumulative patches invalidating all one-off patches.
Once the patch is applied, any change made by an earlier one-off patch needs to be removed. That's what I mean by "invalidating."
What I'm talking about in the paragraph above is related to the "Patch Conflict Detection" algorithm discussed on the main article, in particular the "Misc files" part. The goal is to detect *end user modifications* to the misc files and require the user to declare that overriding that modification with the patch is OK.
Say we have a 6.1.1 CP patch with an applies-to version of 6.1.0. The patch.xml includes a mod to standalone.sh with an existing-hash of "123", the hash of the file present in 6.1.0.
But the user has already applied a one-off that changed the file to one with hash "234". Quite possibly the same hash as the new file in 6.1.1, but not necessarily.
The patch application tool should understand that given the status of the installation "234" is now the expected "existing-hash" for the file and should recognize there is no conflict requiring user input. To do that it will need to know that one-off patch XYZ changed the file to one with hash "234".
>
> what do you think of this "stack" representation of the patches? Is it correct?
Yes, that's correct. I have doubts about relying on dates for ordering. They are useful for providing information to users about when they did things, but I think we'd be better off specifically maintaining an order.
--------------------------------------------------
11 years, 6 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Design of AS7 multi-JSF feature
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] commented on the document
"Design of AS7 multi-JSF feature"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-47689#comment-10945
--------------------------------------------------
I don't see any fundamental issues with this from a patching point of view. The described process does not modify any existing modules or misc files in the distribution; it simply adds new modules. Users are free to do this, and application of a subsequent patch will not blindly disable those modules. A subsequent patch could have one of 3 effects with respect to those modules:
1) The patch doesn't include any modules with the same name and slot as one of these, nor does it include other modules with the same packages/classes. No problem. The x.y.z.mojarra-2.2.0-m05 modules will still be loadable.
2) The patch includes a newly added module with the same name and slot as one of these modules. This is extremely unlikely, given the slot names you are using. But if it did happen, the patch tool will regard the presence of the user-added module as a patch conflict and the user will have to include a param to the patch operation stating that the patch should be applied even though the patch will override a user-modified (in this case, added) module.
See https://community.jboss.org/docs/DOC-47500 Single Installation Patching for more on patch conflict detection and resolution.
3) The patch installs a new module with a different name/slot that contains jars with the same packages/classes. Now there will be two modules available that provide the same packages/classes. Which module gets used in a particular situation depends on the context. If the jsf integration somehow set up a situation where both javax.faces.api.mojarra-2.2.0-m05 and a javax.faces.api.main that contained different versions of the same classes were visible, that would probably be an issue (I haven't thought about it deeply) but that issue has nothing to do with patching. And I assume your impl was designed to deal with that.
--------------------------------------------------
11 years, 6 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Design of AS7 multi-JSF feature
by Stan Silvert
Stan Silvert [https://community.jboss.org/people/ssilvert] commented on the document
"Design of AS7 multi-JSF feature"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-47689#comment-10939
--------------------------------------------------
> Max Rydahl Andersen wrote:
>
>
>
> how would tooling know which jars to include/refer to for proper classpath setup ?
>
The default is still the default. So for now, the default impl is the one in the "main" slots in the com.sun.jsf-impl and javax.faces.api modules.
If the developer uses the JSF_CONFIG_NAME context param, then you will use the jars in the slot specified. We have this problem already. In AS7.0.x forward, you can use the value of "Mojarra-1.2" to refer to the "1.2" slot that ships with AS7. I'm just reusing that context param to let you specify more slots.
So the short answer for now is, you have to look at web.xml.
The next step in multi-JSF will be to add two attributes to the JSF subsystem. The first is a read-only attribute that lists all of the installed JSF implementations. The second is a read/write attribute that allows you to change the default JSF implementation. So I can imagine a tool that reads the list and presents the user with a choice of implementations. Then it fills in the context param appropriately.
--------------------------------------------------
11 years, 6 months
