December 2011 - jboss-as7-dev - Jboss List Archives

by Bill Burke

Weird, a user is getting NCDFE for javax/net/ssl/SSLSocketFactory, any ideas why? -------- Original Message -------- Subject: [Resteasy-developers] Resteasy client with https in Jboss 7 Date: Tue, 06 Dec 2011 11:23:55 -0300 From: Fabricio Lemos <fabricio.lemos(a)sefaz.ce.gov.br> To: resteasy-developers(a)lists.sourceforge.net Is it possible to use resteasy client with https in Jboss 7? This code works with a standalone Java application: System.out.println(new ClientRequest(MyHttpsURL).get().getStatus()); but fails with Jboss 7.0.1 and 7.1.0.Beta1 My certification is imported with the args: -Djavax.net.ssl.trustStoreType=jks -Djavax.net.ssl.trustStore=D:\java\certificados\cacert -Djavax.net.debug=ssl -Djavax.net.ssl.trustStorePassword=myPswd I assume the certification is being imported correctly because HttpsURLConnection conn = (HttpsURLConnection) url.openConnection() works with both standalone and a deployed client The error with resteasy client in Jboss 7 is this: 10:47:54,410 BOM [javax.enterprise.resource.webcontainer.jsf.application] (http--127.0.0.1-8080-2) processAction(j_idt4) 10:47:54,660 DEBUG [org.apache.commons.httpclient.HttpClient] (http--127.0.0.1-8080-2) Java version: 1.6.0_25 10:47:54,660 DEBUG [org.apache.commons.httpclient.HttpClient] (http--127.0.0.1-8080-2) Java vendor: Sun Microsystems Inc. 10:47:54,660 DEBUG [org.apache.commons.httpclient.HttpClient] (http--127.0.0.1-8080-2) Java class path: D:\java\servidores\jboss\jboss-as-7.1.0.Beta1\jboss-modules.jar 10:47:54,660 DEBUG [org.apache.commons.httpclient.HttpClient] (http--127.0.0.1-8080-2) Operating system name: Windows XP 10:47:54,660 DEBUG [org.apache.commons.httpclient.HttpClient] (http--127.0.0.1-8080-2) Operating system architecture: x86 10:47:54,660 DEBUG [org.apache.commons.httpclient.HttpClient] (http--127.0.0.1-8080-2) Operating system version: 5.1 10:47:54,660 DEBUG [org.apache.commons.httpclient.HttpClient] (http--127.0.0.1-8080-2) jboss-sasl 1.0: JBoss SASL Provider 1.0.0.Beta6 10:47:54,660 DEBUG [org.apache.commons.httpclient.HttpClient] (http--127.0.0.1-8080-2) SUN 1.6: SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP, Collection CertStores, JavaPolicy Policy; JavaLoginConfig Configuration) 10:47:54,660 DEBUG [org.apache.commons.httpclient.HttpClient] (http--127.0.0.1-8080-2) SunRsaSign 1.5: Sun RSA signature provider 10:47:54,660 DEBUG [org.apache.commons.httpclient.HttpClient] (http--127.0.0.1-8080-2) SunJSSE 1.6: Sun JSSE provider(PKCS12, SunX509 key/trust factories, SSLv3, TLSv1) 10:47:54,660 DEBUG [org.apache.commons.httpclient.HttpClient] (http--127.0.0.1-8080-2) SunJCE 1.6: SunJCE Provider (implements RSA, DES, Triple DES, AES, Blowfish, ARCFOUR, RC2, PBE, Diffie-Hellman, HMAC) 10:47:54,660 DEBUG [org.apache.commons.httpclient.HttpClient] (http--127.0.0.1-8080-2) SunJGSS 1.0: Sun (Kerberos v5, SPNEGO) 10:47:54,660 DEBUG [org.apache.commons.httpclient.HttpClient] (http--127.0.0.1-8080-2) SunSASL 1.5: Sun SASL provider(implements client mechanisms for: DIGEST-MD5, GSSAPI, EXTERNAL, PLAIN, CRAM-MD5; server mechanisms for: DIGEST-MD5, GSSAPI, CRAM-MD5) 10:47:54,660 DEBUG [org.apache.commons.httpclient.HttpClient] (http--127.0.0.1-8080-2) XMLDSig 1.0: XMLDSig (DOM XMLSignatureFactory; DOM KeyInfoFactory) 10:47:54,660 DEBUG [org.apache.commons.httpclient.HttpClient] (http--127.0.0.1-8080-2) SunPCSC 1.6: Sun PC/SC provider 10:47:54,660 DEBUG [org.apache.commons.httpclient.HttpClient] (http--127.0.0.1-8080-2) SunMSCAPI 1.6: Sun's Microsoft Crypto API provider 10:47:54,676 DEBUG [org.apache.commons.httpclient.params.DefaultHttpParams] (http--127.0.0.1-8080-2) Set parameter http.useragent = Jakarta Commons-HttpClient/3.1 10:47:54,676 DEBUG [org.apache.commons.httpclient.params.DefaultHttpParams] (http--127.0.0.1-8080-2) Set parameter http.protocol.version = HTTP/1.1 10:47:54,676 DEBUG [org.apache.commons.httpclient.params.DefaultHttpParams] (http--127.0.0.1-8080-2) Set parameter http.connection-manager.class = class org.apache.commons.httpclient.SimpleHttpConnectionManager 10:47:54,676 DEBUG [org.apache.commons.httpclient.params.DefaultHttpParams] (http--127.0.0.1-8080-2) Set parameter http.protocol.cookie-policy = default 10:47:54,676 DEBUG [org.apache.commons.httpclient.params.DefaultHttpParams] (http--127.0.0.1-8080-2) Set parameter http.protocol.element-charset = US-ASCII 10:47:54,676 DEBUG [org.apache.commons.httpclient.params.DefaultHttpParams] (http--127.0.0.1-8080-2) Set parameter http.protocol.content-charset = ISO-8859-1 10:47:54,676 DEBUG [org.apache.commons.httpclient.params.DefaultHttpParams] (http--127.0.0.1-8080-2) Set parameter http.method.retry-handler = org.apache.commons.httpclient.DefaultHttpMethodRetryHandler@1e8e6aa 10:47:54,676 DEBUG [org.apache.commons.httpclient.params.DefaultHttpParams] (http--127.0.0.1-8080-2) Set parameter http.dateparser.patterns = [EEE, dd MMM yyyy HH:mm:ss zzz, EEEE, dd-MMM-yy HH:mm:ss zzz, EEE MMM d HH:mm:ss yyyy, EEE, dd-MMM-yyyy HH:mm:ss z, EEE, dd-MMM-yyyy HH-mm-ss z, EEE, dd MMM yy HH:mm:ss z, EEE dd-MMM-yyyy HH:mm:ss z, EEE dd MMM yyyy HH:mm:ss z, EEE dd-MMM-yyyy HH-mm-ss z, EEE dd-MMM-yy HH:mm:ss z, EEE dd MMM yy HH:mm:ss z, EEE,dd-MMM-yy HH:mm:ss z, EEE,dd-MMM-yyyy HH:mm:ss z, EEE, dd-MM-yyyy HH:mm:ss z] 10:47:55,129 INFO [br.gov.ce.sefaz.jee.intranet.RestEasyAstraWS] (http--127.0.0.1-8080-2) URI de autenticação no Astra : https://dese2.sefaz.ce.gov.br/sisseg-jee-ws/resource/autenticacao/?siglaS... 10:47:55,207 DEBUG [org.apache.commons.httpclient.HttpConnection] (http--127.0.0.1-8080-2) Open connection to dese2.sefaz.ce.gov.br:443 10:47:55,207 DEBUG [org.apache.commons.httpclient.HttpConnection] (http--127.0.0.1-8080-2) Releasing connection back to connection manager. 10:47:55,207 BOM [javax.enterprise.resource.webcontainer.jsf.application] (http--127.0.0.1-8080-2) java.lang.NoClassDefFoundError: javax/net/ssl/SSLSocketFactory: javax.faces.el.EvaluationException: java.lang.NoClassDefFoundError: javax/net/ssl/SSLSocketFactory at org.jboss.seam.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:58) [seam-faces-3.0.0.Final.jar:] at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.1.3-b02-jbossorg-2.jar:] at org.jboss.seam.faces.component.UIViewAction.broadcast(UIViewAction.java:365) [seam-faces-3.0.0.Final.jar:] at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:] at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:] at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.3-b02-jbossorg-2.jar:] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.3-b02-jbossorg-2.jar:] at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.3-b02-jbossorg-2.jar:] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.3.Final.jar:] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.3.Final.jar:] at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) [weld-core-1.1.4.Final.jar:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.3.Final.jar:] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.3.Final.jar:] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.3.Final.jar:] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.3.Final.jar:] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:151) [jboss-as-web-7.1.0.Beta1.jar:] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.3.Final.jar:] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.3.Final.jar:] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.3.Final.jar:] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.3.Final.jar:] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.3.Final.jar:] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.3.Final.jar:] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.3.Final.jar:] at java.lang.Thread.run(Thread.java:662) [:1.6.0_25] Caused by: java.lang.NoClassDefFoundError: javax/net/ssl/SSLSocketFactory at org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(SSLProtocolSocketFactory.java:82) [commons-httpclient-3.1.jar:] at org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(SSLProtocolSocketFactory.java:127) [commons-httpclient-3.1.jar:] at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707) [commons-httpclient-3.1.jar:] at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387) [commons-httpclient-3.1.jar:] at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171) [commons-httpclient-3.1.jar:] at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) [commons-httpclient-3.1.jar:] at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323) [commons-httpclient-3.1.jar:] at org.jboss.resteasy.client.core.executors.ApacheHttpClientExecutor.execute(ApacheHttpClientExecutor.java:81) [resteasy-jaxrs-2.2.3.GA.jar:] at org.jboss.resteasy.core.interception.ClientExecutionContextImpl.proceed(ClientExecutionContextImpl.java:39) [resteasy-jaxrs-2.2.3.GA.jar:] at org.jboss.resteasy.plugins.interceptors.encoding.AcceptEncodingGZIPInterceptor.execute(AcceptEncodingGZIPInterceptor.java:40) [resteasy-jaxrs-2.2.3.GA.jar:] at org.jboss.resteasy.core.interception.ClientExecutionContextImpl.proceed(ClientExecutionContextImpl.java:45) [resteasy-jaxrs-2.2.3.GA.jar:] at org.jboss.resteasy.client.ClientRequest.execute(ClientRequest.java:473) [resteasy-jaxrs-2.2.3.GA.jar:] at org.jboss.resteasy.client.ClientRequest.httpMethod(ClientRequest.java:704) [resteasy-jaxrs-2.2.3.GA.jar:] at org.jboss.resteasy.client.ClientRequest.get(ClientRequest.java:509) [resteasy-jaxrs-2.2.3.GA.jar:] at org.jboss.resteasy.client.ClientRequest.get(ClientRequest.java:537) [resteasy-jaxrs-2.2.3.GA.jar:] at br.gov.ce.sefaz.jee.intranet.RestEasyAstraWS.autenticarUsuario(RestEasyAstraWS.java:30) [jee-intranet-sefaz-0.0.3-SNAPSHOT.jar:] at br.gov.ce.sefaz.jee.intranet.AutenticadorAstra.authenticate(AutenticadorAstra.java:52) [jee-intranet-sefaz-0.0.3-SNAPSHOT.jar:] at br.gov.ce.sefaz.jee.intranet.AutenticadorAstra$Proxy$_$$_WeldClientProxy.authenticate(AutenticadorAstra$Proxy$_$$_WeldClientProxy.java) [jee-intranet-sefaz-0.0.3-SNAPSHOT.jar:] at org.jboss.seam.security.IdentityImpl.authenticate(IdentityImpl.java:305) [seam-security-3.0.0.Final.jar:] at org.jboss.seam.security.IdentityImpl.login(IdentityImpl.java:229) [seam-security-3.0.0.Final.jar:] at org.jboss.seam.security.IdentityImpl$Proxy$_$$_WeldClientProxy.login(IdentityImpl$Proxy$_$$_WeldClientProxy.java) [seam-security-3.0.0.Final.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_25] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_25] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_25] at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_25] at org.apache.el.parser.AstValue.invoke(AstValue.java:196) [jbossweb-7.0.3.Final.jar:] at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) [jbossweb-7.0.3.Final.jar:] at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:39) [weld-core-1.1.4.Final.jar:] at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-1.1.4.Final.jar:] at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.3-b02-jbossorg-2.jar:] at org.jboss.seam.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:48) [seam-faces-3.0.0.Final.jar:] ... 24 more Caused by: java.lang.ClassNotFoundException: javax.net.ssl.SSLSocketFactory from [Module "org.apache.commons.httpclient:main" from local module loader @542529 (roots: D:\java\servidores\jboss\jboss-as-7.1.0.Beta1\modules)] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:485) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:444) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:421) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:143) ... 55 more thanks in advance, Fabrício Lemos ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Resteasy-developers mailing list Resteasy-developers(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-developers

13 years

4
5
0 / 0

Wrong SecurityManagement/AuthenticationManager

by Dieter Tengelmann

Hi, I've configured my security-domain with cache-type="default" in the standalone.xml, an instance of JBossCachedAuthenticationManager is initialized correctly via JNDIBasedSecurityManagement, but my application is permanently authenticating via the JAAS login module. I realized that "JBossAuthenticationManager" is used in all EJB parts, only the JBOSS web realm is using the JBossCachedAuthenticationManager... JBossSecurityContext.getAuthenticationManager() delivers via "DefaultSecurityManagement" an instance of JbossAuthenticationManager Is there a workaround for me to receive/set the correct AuthenticationManager till you fix this bug? Not using the cache causes some serious problems in my application... Best regards, Dieter Tengelmann

13 years

2
2
0 / 0

patching is problematic

by Bill Burke

I just had another user submit a bug when they tried to upgrade resteasy with AS7 and didn't know they had to edit a module.xml file. Can we make this easier for users? i.e. a wildcard resteasy-jaxrs-*.jar? Or have it load every jar in the directory by default? Or something? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

13 years

3
2
0 / 0

Error logging / tracing log writer for resource adapters

by Buerenheide, Christian

Hi all, we implemented a resource adapter which makes use of the PrintWriter instance injected to the managed connection factory for error logging/tracing purposes. By searching for a way to enable/disable tracing during runtime we found out that the JCA container of jboss-as-7.1.0.CR1 just injects a System.out printer during deployment time. If I this isn't right, please correct me. The JCA (1.5) spec says the following: "An application server manages the association of a log writer with a ManagedConnectionFactory. When a ManagedConnectionFactory instance is created, the log writer is initially null and logging is disabled. Associating a log writer with a ManagedConnectionFactory instance enables logging and tracing for the ManagedConnectionFactory instance." This is exactly the behaviour that we would like to have :-) In our opinion it would be a better idea to write to a specific JBoss logger rather than to System.out. I checked out the sources from github and locally tested with a PrintWriter wrapper subclass which prints out to a org.jboss.logging.Logger instance if trace is enabled for that particular logger. It would be also nice if we could get notified about log level changes so that we could reset the ManagedConnection.logWriter back to null if tracing gets disabled. If so, the log writer could be null checked within the RA implementation so that the trace code (e.g. message formatting) doesn't need to be executed if trace is disabled... Is there a kind of callback mechanism implemented in jboss logging? What's your opinion about a suitable solution? Do you have any proposals? Best regards Christian WINCOR NIXDORF International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193 Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

13 years

2
1
0 / 0

Re: [jboss-as7-dev] rollout plans

by Brian Stansberry

I was chatting with Jason and he had a good idea. In domain.xml <rollout-plans> <plan-configs name="plans-x" sha1="xxxxxx"/> <fs-plan-configs path="plans-y.xml" relative-to="path-to-var/jbossas"/> </rollout-plans> The former we'd store in the content repo; the latter would be external. The domain API would just provide load and store methods. (For the "fs-plan-config" case perhaps just load if we don't want to deal with the possibility of not being able to write.) The tools are responsible for any manipulation of the plans; they just send the DMR back to the HC for storage. My assumption was each "(fs-)plan-configs" item could include multiple plans. Basically this just formalizes the contract for how plan files are stored and uses the domain content repo as a readily available store (one that replicates so its usable if another HC takes over as master or if the client is only making host level changes to a slave HC.) On 12/6/11 9:50 AM, Alexey Loubyansky wrote: > Then we are changing the domain configuration, i.e. extending it, to > include the rollout plans, right? > > Alexey > > On 12/06/2011 04:10 PM, Brian Stansberry wrote: >> Let's go with 1) unless Heiko has some idea how to persist the state >> client side in a reasonable manner. I think a requirement is there has >> to be an option for sharing the persistent state between users. That can >> be done with the CLI by having them point to the same file. It's not so >> straightforward with a browser. >> >> On 12/5/11 5:06 PM, Alexey Loubyansky wrote: >>> I would propose two choices to consider for now: >>> >>> 1. Rollout plans included in the domain management model. >>> >>> Pros: >>> - they are stored in one location and are managed using the existing >>> domain management api; >>> - they are based on the server group names that are defined in the >>> domain config, so keeping them next to each other is an advantage, >>> separating them will increase the chance of inconsistencies between the >>> two; >>> - all tools will benefit from the same config. >>> >>> Cons: >>> - this data does not really belong to the domain configuration, it's a >>> convenience config for users to perform operations; >>> - they are shared among users, meaning they are not personalized for a >>> specific user but for all of them. >>> >>> 2. Keep it to the client, i.e. each tool will keep it's own config per >>> user (or per tool setup). >>> >>> The Pros and Cons above change their signs here. >>> >>> These are two edge options. They could be combined. For now though, I'd >>> implement one of them. >>> >>> Alexey >>> >>> On 12/05/2011 07:33 PM, Brian Stansberry wrote: >>>> I'll look for both of you in #jboss-as7 when get in tomorrow AM. If >>>> you're there it's faster to chat. (If not it's ok; I'm not setting up a >>>> formal meeting here.) Or feel free to ping me before then if either of >>>> you notice we're all in the room. >>>> >>>> On 12/5/11 5:50 AM, Alexey Loubyansky wrote: >>>>> I don't think it makes sense to invent another protocol. >>>>> >>>> >>>> For sure. >>>> >>>>> Well, now it gets kind of closer to the domain management model. >>>>> Which I >>>>> wanted to avoid originally, since it's an additional user data. But if >>>>> we are talking about a general config, it naturally becomes shared >>>>> between the users. From this point of view, it might make sense to >>>>> include them in the model. >>>>> >>>> >>>> It doesn't *have* to be that way, e.g. the operations behind a rollout >>>> plan could include a param for the storage location. But that gets >>>> really nasty pretty fast. It basically reduces the API for managing >>>> these to "load" and "save"; no fine grained changes would be possible >>>> without a lot of ugliness. And users would need understand what >>>> filesystem locations the server can see etc. >>>> >>>> A possibility is another config file in domain/configuration for these, >>>> but that just adds complexity with no clear benefit. An HC would >>>> have to >>>> know what the config file is at boot or its no different than making >>>> the >>>> user specify what the storage location is with any request. >>>> >>>> We could support storing these in both a jboss-cli.xml and in >>>> domain.xml. The latter would be the only option for console users; the >>>> former could be used for stuff a CLI user doesn't need/want to share. >>>> There's a potential name conflict issue the CLI would need to deal with >>>> though. >>>> >>>>> If we go that way, it might also make sense to include support for >>>>> referencing a stored rollout plan from the DMR operation request. >>>>> >>>> >>>> Agreed. That could just be another header variant, e.g. >>>> >>>> "operation-headers" => { >>>> "named-rollout-plan" => "planA" >>>> } >>>> >>>> as an alternative to >>>> >>>> >>>> "operation-headers" => { >>>> "rollout-plan" => { ... the details ... } >>>> } >>>> >>>>> Alexey >>>>> >>>>> On 12/05/2011 12:38 PM, Heiko Braun wrote: >>>>>> >>>>>> >>>>>> I don't have anything yet. As for sharing API/Interfaces: >>>>>> >>>>>> Ideally this would become a DMR operation/resource to work on. >>>>>> That's at >>>>>> least how we'd integrate at the moment and I think it would make the >>>>>> most sense to keep it that way. Unless something forces us to move to >>>>>> custom protocol. >>>>>> If we stick to DMR, then actual service API/Impl doesn't matter that >>>>>> much. >>>>>> >>>>>> >>>>>> So the question is: What shared protocol do we use? DMR is something >>>>>> both the CLI and Console already use. A custom protocol would need to >>>>>> have a reasonable HTTP mapping in order to work with the console. >>>>>> >>>>>> On Dec 5, 2011, at 12:32 PM, Alexey Loubyansky wrote: >>>>>> >>>>>>> Which means we could also share an api interface/impl. >>>>>> >>>>>> -- >>>>>> >>>>>> Heiko Braun >>>>>> Senor Software Engineer >>>>>> JBoss by Red Hat >>>>>> http://about.me/hbraun >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >> >> -- Brian Stansberry Principal Software Engineer JBoss by Red Hat

13 years

1
0
0 / 0

System property replacement in deployment descriptors

by Jaikiran Pai

In previous versions of JBoss AS, we used to allow system property replacement in deployment descriptors (just like we now do in standalone/domain.xml). It seems to have been pretty popular and I have already seen more than a couple of users asking for this in AS7. Should we add support for this (hopefully in a central/common place for all deployment descriptors including non EE ones like jboss-deployment-structure.xml)? -Jaikiran

13 years

1
0
0 / 0

Re: [jboss-as7-dev] [jboss-as] Move non-standard config files to the docs/examples/configs directory (#790)

by Brian Stansberry

FYI, the pull request below is moving config files other than the default one, the full profile one and the HA one to docs/examples/configs. This was done on my recommendation (i.e. blame me) in order to reduce clutter in the configuration/ dir. Otherwise over time we are going to end up with a multitude of config file variants. (Carlo has a pull request out there with another one.) Speak now or forever hold your peace. ;) On 12/2/11 11:49 AM, Kabir Khan wrote: > It looks like ParseAndMarshalModelsTestCase never tested the standalone-hornetq-colocated.xml file. I fixed it up a bit but created https://issues.jboss.org/browse/AS7-2901 > > You can merge this Pull Request by running: > > git pull https://github.com/kabir/jboss-as special-configs-in-docs > > Or you can view, comment on it, or merge it online at: > > https://github.com/jbossas/jboss-as/pull/790 > > -- Commit Summary -- > > * Move non-standard config files to the docs/examples/configs directory > > -- File Changes -- > > A build/src/main/resources/docs/examples/configs/domain-osgi-only.xml (0) > M build/src/main/resources/docs/examples/configs/standalone-hornetq-colocated.xml (17) > A build/src/main/resources/docs/examples/configs/standalone-osgi-only.xml (0) > A build/src/main/resources/docs/examples/configs/standalone-xts.xml (0) > M testsuite/integration/smoke/src/test/java/org/jboss/as/test/smoke/embedded/parse/ParseAndMarshalModelsTestCase.java (39) > > -- Patch Links -- > > https://github.com/jbossas/jboss-as/pull/790.patch > https://github.com/jbossas/jboss-as/pull/790.diff > > --- > Reply to this email directly or view it on GitHub: > https://github.com/jbossas/jboss-as/pull/790 > _______________________________________________ > jbossas-pull-requests mailing list > jbossas-pull-requests(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests -- Brian Stansberry Principal Software Engineer JBoss by Red Hat

13 years

3
5
0 / 0

Fwd: Testsuite -Dtest

by Kabir Khan

Missed the list in my original reply :-) Begin forwarded message: > From: Kabir Khan <kabir.khan(a)jboss.com> > Date: 6 December 2011 14:38:55 GMT > To: Peter Skopek <pskopek(a)redhat.com> > Subject: Re: [jboss-as7-dev] Testsuite -Dtest > > Perfect, thanks! > On 6 Dec 2011, at 14:28, Peter Skopek wrote: > >> Kabir, >> >> try this: >> >> <profile> >> <id>onlyOneSurefireExecution.basic.profile</id> >> <activation><property><name>test</name></property></activation> >> <build> >> <plugins> >> <plugin> >> <groupId>org.apache.maven.plugins</groupId> >> <artifactId>maven-surefire-plugin</artifactId> >> <executions> >> <execution><id>basic-integration-default- >> full.surefire</id><phase>test</phase></execution> >> <execution><id>basic-integration-default- >> web.surefire</id><phase>none</phase></execution> >> <execution><id>basic- >> integration-2nd.surefire</id><phase>none</phase></execution> >> </executions> >> </plugin> >> </plugins> >> </build> >> </profile> >> >> It works for me on basic/pom.xml. >> >> Peter >> >> >> On Tuesday, December 06, 2011 15:01:32 Kabir Khan wrote: >>> Not sure, it used to be possible to do it the way I put in. >>> >>> I've put it back to what we used to have by commenting out the >>> onlyOneSurefireExecution profiles from smoke and basic. It will try to run >>> the test for each execution, i.e. full and web. However full is done >>> first, so tests should pass there. The web execution might fail if the >>> test targets the full profile. >>> >>> On 6 Dec 2011, at 13:03, David Bosschaert wrote: >>>> I thought you'd always pass in the test's bare name (without the >>>> package), e.g.: >>>> >>>> mvn clean install -Dtest=ParseAndMarshalModelsTestCase >>>> >>>> >>>> Cheers, >>>> >>>> David >>>> >>>> On 06/12/2011 12:42, Kabir Khan wrote: >>>>> It seems the latest commit to the testsuite now breaks the ability to do >>>>> cd testsuite/integration/smoke >>>>> mvn clean install >>>>> -Dtest=org.jboss.as.test.smoke.embedded.parse.ParseAndMarshalModelsTest >>>>> Case _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >

13 years

1
0
0 / 0

EJB passivation/activation, clustering and JPA extended persistence context handling...

by Scott Marlow

Hi, I'm looking into handling serialization of the extended persistence context (for both clustering and EJB3.1 passivation/activation). The (JPA subsystem) spi is still developing for this but if anyone has feedback or wants to follow. A sketch for the spi is at https://github.com/scottmarlow/jboss-as/blob/d7ec51ac14afb47ced7d203f8b36... One question that comes up is why. Why not just throw NotSerializableException instead of serializing the extended persistence context. If anyone feels strongly that we should throw NotSerializableException instead of serializing the extended persistence context, I'd like to hear why. I've made internal changes on https://github.com/scottmarlow/jboss-as/tree/cluster1 to support clustering extended persistence contexts. Next is to do the actual serialization. Scott

13 years

5
17
0 / 0

Metadata validation in StAX

by Thomas Diesler

Hi Frederic, here is a sample how stax can be used to validate https://github.com/tdiesler/metadata/tree/staxval Please note, that woodstox delegates to jaxb to create the schema object. At first sight it is not obvious how to plug in the entity resolver into that processing step - so because of network access the test is terribly slow. A little research might show how to optimize this. Anyway, I think we decided to do the validation as an optional/additional processing step (i.e. not during the StAX parsing phase). In AS7 I get a DOM tree of the EE descriptor and validate that against a JAXP validator - after StAX processing is done. Also note, that the jaxp validator does not catch invalid element duplicates, which may be caused by the schema not being in sync with the spec (i.e you can't have multiple session-config elements in web.xml). This we handle hard coded in WebCommonMetaDataParser. cheers -thomas On 12/02/2011 12:38 PM, jean-frederic clere wrote: > Hi. > > Is there a way to get stax making the validation before we process the > metadata? It is some work to add the validation in metadata (and it > would be hard coded). > > Please help. > > Cheers > > Jean-Frederic -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler JBoss OSGi Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

13 years

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

jboss-as7-dev December 2011