file deployment availability ?
by Max Rydahl Andersen
Hi,
With JBoss Tools 3.2 out the door we are ready to start working on AS 7 support in the tools.
Things seem to be still be very fluid with respect to remote API's thus my initial plan were we
focus on start/stop of the container (by using the shell scripts) and the discussed file-deployment API
as discussed at Devoxx and http://community.jboss.org/message/572083.
My hope is that since these "contracts" are pretty simple we would be able to get something up an running
pretty fast and if things changes in internals of AS7 we won't be that much affected by it assuming you maintain
those "contracts".
I was wondering when this will be ready for us to tryout ? At Devoxx the word was "pretty soon now, latest end-of-february";
does that still hold ?
/max
13 years, 9 months
Metadata for AS
by Andrew Lee Rubinger
Alongside our metadata discussions this morning, I'd like to offer up a
prototype for use as the preferred metadata view for AS subsystems.
We've baked in the testing community a project currently branded
"ShrinkWrap Descriptors":
GitHub: https://github.com/shrinkwrap/descriptors
JIRA: https://issues.jboss.org/browse/SHRINKDESC
The end user view looks a bit like:
https://gist.github.com/828591
The purpose of the project is to define an object model for
specification and JBoss-specific metadata, with the following driving
tenets:
* No compile dependencies outside the JDK
* Pluggable backends (ie. DOM, XB, Stax, right now we use DOM and
straight hardcoded parsing logic)
* Easy import/export to/from File/URL/String/Stream/bytes
Other concerns are to be addressed at another level, namely:
* Merging
* Annotation scanning repo output > object model view
* Validation
* ...basically anything initiated during deployment.
Deployment logic should be, IMO:
Deployer takes in deployment > Gen object model > calls outside layers
for merging/validation/etc > deployer installs final view
The descriptors project is currently immature and could use a jumpstart
off the prototype. If we decide this is of interest to AS and
subsystems, that's enough of a demand for me to take it on exclusively
over the next few weeks to give us a cleaner, faster alternative to
jboss-metadata, which has in my opinion, the following drawbacks:
* The API *is* the backing model
* Too many dependencies
* Mixes in business logic (defaulting of values, spec validation)
* Not interface-based (resulting in wrapper classes and the like to tack
on functionality)
S,
ALR
13 years, 9 months
State of EJB3 in AS7
by ssilvert＠redhat.com
What is there right now?
More specifically, is the "EJBs in a WAR" stuff working and can I use
the "java:module" and "java:app" contexts?
Stan
13 years, 9 months
Security domains
by Rich Midwinter
Hi
Entering a security-domain tag in a jboss-web.xml results in a parse error
under JBoss 7.
Is there an implementation of security domains, or an alternative, yet
available for it?
Thanks
Rich
13 years, 9 months
doamain deployments
by Heiko Braun
taken form the jboss_7_0.xsd :
<xs:complexType name="deploymentType">
<xs:annotation>
<xs:documentation>Deployment represents anything that can be deployed (e.g. an application such as EJB-JAR,
WAR, EAR,
any kind of standard archive such as RAR or JBoss-specific deployment),
which can be enabled or disabled on a domain level.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="mapped-deploymentType">
<xs:attribute name="allowed" use="optional" type="xs:boolean" default="true">
<xs:annotation>
<xs:documentation>Whether the mapping the deployment to a server group is allowed.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Can somebody explain the attribute "allowed" to me? What does it mean, if a deployment is not "allowed" to be mapped
to a server group? Is this an equivalent to "disabled"?
Ike
13 years, 9 months
New Modules version!!
by David M. Lloyd
Everyone, I've updated the JBoss Modules used in master. Here's what
you need to know:
- URL parsing problems which were seen on Windows (smoke test failures)
are now fixed. URL parsing and generation problems relating to seal
base and code source are now fixed.
- Class linkage errors (i.e., missing dependencies) are now always
logged at WARN rather than TRACE, which should make it considerably
easier to debug problems.
- Minor performance boost. In addition, if you edit standalone.conf to
include "-Djboss.modules.lockless=true" in JAVA_OPTS, you should see an
even more substantial improvement. I'll make this the default if and
when I'm confident it's "safe" on all JVMs, which requires some research.
- Modules are now no longer automatically garbage-collected unless
they're explicitly unloaded.
- New MBean methods to get full text dumps of a module loader's status,
which can help debug module dependency problems.
- More comprehensive JavaDoc; see:
http://docs.jboss.org/jbossmodules/1.0.0.Beta14
- The confusing "System Module Loader" term is deprecated in favor of
the more accurate "Boot Module Loader" term. "System Module Loader" now
refers exclusively to the module loader which provides the single
"system" module.
- For once, we've retained binary compatibility between versions.
You're welcome! :-)
--
- DML
13 years, 9 months
No SchemaFactory?
by ssilvert＠redhat.com
Now that the system module is no longer a dependency of the WAR's
ModuleSpecification, JSF is no longer able to validate schemas. I
think it's agreed that system should not be there, but how do I deal
with this?
Caused by: java.lang.IllegalArgumentException: No SchemaFactory that
implements the schema language specified by:
http://www.w3.org/2001/XMLSchema could be loaded
at
javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207)
[:1.6.0_18]
at com.sun.faces.config.DbfFactory.initStatics(DbfFactory.java:228)
[file:C:%5Cprojects%5Cas7trunk%5Cjboss-as%5Cbuild%5Ctarget%5Cjboss-7.0.0.Alpha2%5Cmodules%5Cjavax%5Cfaces%5Cimpl%5Cmain%5Cjsf-impl-2.0.4-b09.jar:2.0.4-b09]
... 12 more
13 years, 9 months
Reducing the time spent in fixing CNFE issues due to missing dependencies in module.xml
by Jaikiran Pai
I have been quite frequently running into classloading problems while
working with AS7. It's mainly a result of not having the correct
dependencies setup in my module.xml. For example, if I have class which
imports some classes from jboss-common-core module (let's assume that's
the name) and some other classes from jboss-transaction-integration
module then the build completes successfully and it's only during
runtime that I start running into CNFE and/or NCDFE issues. I then I
have to individually track down these dependencies *one at a time* and
then go back to add it as a dependency in my module.xml.
Is there any better way to manage this? I am aware that just adding
anything and everything in the module.xml isn't a right approach, but
atleast for classes which are directly imported into other classes of a
module, it would be better to somehow automate (or better manage) the
process of setting up the module.xml. That would atleast minimize the
time spent in fixing the module.xml by trial and error method. Thoughts?
-Jaikiran
13 years, 9 months
Re: [jboss-as7-dev] testsuite
by Kabir Khan
You may be right but AS 7 only looks for it in META-INF/MANIFEST.MF. If that is wrong we should fix our end
On 15 Feb 2011, at 17:58, Andrew Lee Rubinger wrote:
> Hey Kabir:
>
> Hmm, I'm not sure which, then, is the correct location. Have a look at:
>
> https://issues.jboss.org/browse/SHRINKWRAP-241
>
> My comment on 09/Jan/11 notes the mappings we've chosen; for a WebArchive the manifest location is:
>
> /WEB-INF/classes/META-INF
>
> Disagree?
>
> I'm not finding docs that really support either position specifically for MANIFEST.MF in web archives. persistence.xml for instance goes in WEB-INF/classes/META-INF.
>
> S,
> ALR
>
> On 02/15/2011 06:50 AM, Kabir Khan wrote:
>> Hey Andrew,
>>
>> It seems that WebArchive.setManifest() adds the Manifest to WEB-INF/classes/META-INF/MANIFEST.MF instead of /META-INF/MANIFEST.MF.
>>
>> Begin forwarded message:
>>
>>> From: Kabir Khan<kabir.khan(a)jboss.com>
>>> Date: 15 February 2011 11:49:22 GMT
>>> To: Stan Silvert<ssilvert(a)redhat.com>
>>> Subject: Re: [jboss-as7-dev] testsuite
>>>
>>> This commit fixes it so that the manifest.mf containing the typical arquillian module dependencies goes in the right place (/META-INF/MANIFEST.MF):
>>> https://github.com/kabir/jboss-as/commit/a14f3013d68ab14e85cb4f17cf30af08...
>>>
>>> I still get this on the server, which is probably ok:
>>> 10:54:13,415 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/test]] (pool-2-thread-3) Servlet /test threw load() exception: java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory
>>> at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:804) [jsf-api-2.0.2-FCS.jar:2.0.2-FCS]
>>> at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:306) [jsf-api-2.0.2-FCS.jar:2.0.2-FCS]
>>> at javax.faces.webapp.FacesServlet.init(FacesServlet.java:166) [jsf-api-2.0.2-FCS.jar:2.0.2-FCS]
>>> at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1208) [jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT]
>>>
>>> And this now in the test report (i.e. shrinkwrap's Asset is now visible):
>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 7.383 sec<<< FAILURE!
>>> testInitialPage(org.jboss.jsfunit.example.hellojsf.HelloJSFTest) Time elapsed: 0.263 sec<<< ERROR!
>>> java.lang.NoClassDefFoundError: org/jboss/jsfunit/jsfsession/JSFServerSession
>>> at java.lang.Class.getDeclaredMethods0(Native Method)
>>> at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
>>> at java.lang.Class.getDeclaredMethods(Class.java:1791)
>>> at org.junit.runners.model.TestClass.<init>(TestClass.java:38)
>>> at org.junit.runners.ParentRunner.<init>(ParentRunner.java:65)
>>> at org.junit.runners.BlockJUnit4ClassRunner.<init>(BlockJUnit4ClassRunner.java:59)
>>> at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:74)
>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>>> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)
>>> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)
>>> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
>>> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
>>> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
>>> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
>>>
>>> So you'll need a module in AS for jsf if one isn't there already. Then you need to either include the dependency in a manifest.mf provided to your test archive, such as:
>>> ----
>>> Manifest-Version: 1.0
>>> Dependencies: my.jsf.module
>>> ----
>>> The demos contain more examples of manifests. OR if you determine early that this is a JSF deployment, you will probably want to always add the jsf dependencies in a deployment unit processor. See ManagedBeanDependencyProcessor which adds a dependency on the javaee.api for all managed beans deployments.
>>>
>>>
>>>
>>> On 15 Feb 2011, at 11:03, Kabir Khan wrote:
>>>
>>>> I think there is a problem with how the manifest containing the additional deps gets added to the war by ModuleApplicationProcessor. I added some debugging to make sure that the jboss arquillian processors get invoked
>>>>
>>>> The raw jar
>>>> test.war:
>>>> /WEB-INF/
>>>> /WEB-INF/faces-config.xml
>>>> /WEB-INF/beans.xml
>>>> /WEB-INF/web.xml
>>>> /WEB-INF/classes/
>>>> /WEB-INF/classes/org/
>>>> /WEB-INF/classes/org/jboss/
>>>> /WEB-INF/classes/org/jboss/jsfunit/
>>>> /WEB-INF/classes/org/jboss/jsfunit/example/
>>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/
>>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/HelloJSFTest.class
>>>> /WEB-INF/classes/META-INF/
>>>> /WEB-INF/classes/META-INF/beans.xml
>>>> /index.xhtml
>>>>
>>>> After ModuleApplicationArchiveProcessor has added the deps
>>>> test.war:
>>>> /WEB-INF/
>>>> /WEB-INF/faces-config.xml
>>>> /WEB-INF/beans.xml
>>>> /WEB-INF/web.xml
>>>> /WEB-INF/classes/
>>>> /WEB-INF/classes/org/
>>>> /WEB-INF/classes/org/jboss/
>>>> /WEB-INF/classes/org/jboss/jsfunit/
>>>> /WEB-INF/classes/org/jboss/jsfunit/example/
>>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/
>>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/HelloJSFTest.class
>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/
>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/FormAuthentication.class
>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/Browser.class
>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/InitialRequest.class
>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/InitialPage.class
>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/BrowserVersion.class
>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/JSFSessionFactory.class
>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/Cookies.class
>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/Proxy.class
>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/BasicAuthentication.class
>>>> /WEB-INF/classes/META-INF/
>>>> /WEB-INF/classes/META-INF/MANIFEST.MF<<<<<<<<< I think this should be in /META-INF/MANIFEST.MF
>>>> /WEB-INF/classes/META-INF/beans.xml
>>>> /index.xhtml
>>>>
>>>> I'll try to make it appear in the proper place
>>>>
>>>>
>>>> On 14 Feb 2011, at 23:35, ssilvert(a)redhat.com wrote:
>>>>
>>>>> Thanks for your help. It's really strange.
>>>>>
>>>>> Among other things, if you open up the war you will see that the only classes under WEB-INF are my test class and some JSFUnit CDI classes that JSFUnit puts there with an ApplicationArchiveProcessor.
>>>>>
>>>>>
>>>>> Quoting Kabir Khan<kabir.khan(a)jboss.com>:
>>>>>
>>>>>> I've had a quick look and can't see anything obvious, I'll take proper look tomorrow
>>>>>> On 14 Feb 2011, at 20:38, ssilvert(a)redhat.com wrote:
>>>>>>
>>>>>>> I'm creating a WebArchive. This test runs fine when it deploys against AS6. Can you take a quick look at it?
>>>>>>>
>>>>>>> * svn checkout http://anonsvn.jboss.org/repos/jsfunit/trunk/gettingstarted
>>>>>>> * Start AS7
>>>>>>> * mvn -Pjbossas-remote-7 test
>>>>>>>
>>>>>>> The test won't actually pass because JSF is not there yet. But it should still deploy and run.
>>>>>>>
>>>>>>> Stan
>>>>>>>
>>>>>>> Quoting Kabir Khan<kabir.khan(a)jboss.com>:
>>>>>>>
>>>>>>>>
>>>>>>>> On 14 Feb 2011, at 18:44, ssilvert(a)redhat.com wrote:
>>>>>>>>
>>>>>>>>> So let me ask it this way. What's the easiest way to get an
>>>>>>>>> Arquillian test running with AS7? It looks like the answer might be
>>>>>>>>> to use remote. I almost got that running with
>>>>>>>>> jboss-as-arquillian-container-remote. Am I required to use the forked
>>>>>>>>> Surefire with remote?
>>>>>>>>
>>>>>>>> The forked surefire plugin (which is not really being used yet) is not required for remote. To do an embedded test, simply copy what the smoke tests do.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Without it, I got this message in the AS7 console:
>>>>>>>>>
>>>>>>>>> 13:06:33,072 INFO [org.jboss.as.server.deployment] (pool-3-thread-4)
>>>>>>>>> Content wi
>>>>>>>>> th name test.war added at location
>>>>>>>>> C:\projects\as7trunk\jboss-as\build\target\jb
>>>>>>>>> oss-7.0.0.Alpha2\standalone\data\content\24\5a3cbc919f50f4d7384197c5755fd7fb5c83
>>>>>>>>> 9a\content
>>>>>>>>>
>>>>>>>>> But there were two strange things. First, I got this in my test output:
>>>>>>>>> -------------------------------------------------------------------------------
>>>>>>>>> Test set: org.jboss.jsfunit.example.hellojsf.HelloJSFTest
>>>>>>>>> -------------------------------------------------------------------------------
>>>>>>>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 13.846
>>>>>>>>> sec<<< FAILURE!
>>>>>>>>> testInitialPage(org.jboss.jsfunit.example.hellojsf.HelloJSFTest) Time
>>>>>>>>> elapsed: 6.089 sec<<< ERROR!
>>>>>>>>> java.lang.ClassNotFoundException:
>>>>>>>>> org.jboss.jsfunit.example.hellojsf.HelloJSFTest
>>>>>>>>>
>>>>>>>>> I can see that the test class was indeed added to the WEB-INF/classes.
>>>>>>>>> So I shouldn't get ClassNotFoundException.
>>>>>>>>>
>>>>>>>>> But, it looks like jboss-as-arquillian-container-remote doesn't know
>>>>>>>>> I'm creating a WAR because it put all the supporting classes in the
>>>>>>>>> root of my WAR instead of putting them in WEB-INF/lib or
>>>>>>>>> WEB-INF/classes.
>>>>>>>>
>>>>>>>> Unless you tell Shrinkwrap you're creating a web archive it will create a normal jar. From WarTestCase in smoke tests:
>>>>>>>>
>>>>>>>> @Deployment
>>>>>>>> public static Archive<?> getDeployment(){
>>>>>>>> return ShrinkWrapUtils.createWebArchive("demos/war-example.war", SimpleServlet.class.getPackage());
>>>>>>>> }
>>>>>>>>
>>>>>>>> public static WebArchive createWebArchive(String archiveName, Package...packages) {
>>>>>>>> WebArchive archive = ShrinkWrap.create(WebArchive.class, getBaseArchiveName(archiveName));
>>>>>>>> addPackages(archive, packages);
>>>>>>>> addResources(archiveName, archive);
>>>>>>>> return archive;
>>>>>>>> }
>>>>>>>>
>>>>>>>> IIRC ShrinkWrap will put things in the right place if you create a WebArchive. For all other archive types root is the default location
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
13 years, 9 months
Management Configuration
by Darran Lofthouse
Has there been any consideration yet regarding where the actual
configuration for the management of the servers will take place?
Looking at the schemas we have a 'managementType' that can exist either
in the standalone.xml or in the host.xml - at the moment this element
only controls which APIs are available and I think these locations make
sense as which to expose could be a host by host decision.
For the actual security of the management APIs I think we are going to
want something more central that applies to a full domain so something
that would be in both the domain.xml and the standalone.xml.
Also longer term could this require additional centralised
configuration? Possibly thinks like persistence policies, console
customisation, rules for which hosts can join etc...
Regards,
Darran Lofthouse.
13 years, 9 months
