May 2012 - jboss-as7-dev - Jboss List Archives

by Shashank Bellary

Hi Guys, I'm trying to migrate to JBoss 7.1.1 from 4.0.5. In our application we use lot of symlinks to support CMS content which is managed externally and to support some file bases caching. Here is how the deployment looks like JBoss 4.0.5: ----------------- Under "/deploy/jboss-4.0.5.GA/server/czen/deploy" we've our exploded WAR directory release.war Here release.war is a symlink to '/deploy/webapp/current' which in turn is a symlink to an actual release folder like '/deploy/webapp/release-version-xyz' 'release-version-xyz' folder has the following structure - WEB-INF - JSP - Content - Cache - JS - CSS Here both Content and Cache folders are symlinks to /deploy/webapp/ - CMSContent - Cache respectively. This deployment structure worked perfectly fine on JBoss 4.0.5 and now I'm moving this app to JBoss 7.1.1 and here is the deployment structure Under "/deploy/jboss-as-7.1.1.Final/czen/deployments" I've moved our release.war as a symlink. Rest of the structure remains the same as mentioned above. With this setup JBoss 7 start up/ application initialization fails because it's not able to follow the symlink and find a file that my application is trying to read at startup. I looked over the documentation and forums to figure out a solution for this but no luck. Could you guys please help in troubleshooting this issue? Is there some configuration parameter that needs to be set or are there other ways. Please let me know, I've a deadline fast approaching Thanks & Regards Shashank This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.

11 years, 10 months

2
4
0 / 0

Can scroll on CLI GUI add Datasources

by Robb Greathouse

Hi, I was preparing video on using CLI. I went to add a Datasource using the CLI GUI. I found that I could not scroll. And so could not fill out the form or submit the form to add the datasource. This was on a MAC with maximum display pixels selected. Robb Greathouse Partner Enablement Middleware Business Unit JBoss, a Division of Red Hat cellphone 505-507-4906

11 years, 10 months

2
1
0 / 0

unreferenced jars ok?

by Bill Burke

I'm making a zip for resteasy that will allow people to upgrade resteasy in AS7. Is it ok for there to be unreferenced "dead" jars in the modules/ directory? There is no implicit jar pull-ins right? Everything wanted/needed is listed in the module.xml file correct? Thanks, Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

11 years, 10 months

3
2
0 / 0

Help need with JBoss 7 session timeout after 5 minutes

by Shanmugham, Boominathan

Hi Team, I have deployed an application in JBoss 7.1 and it worked well with minimum request. When we started with multiple action (mass delete of 200 records), getting session expired after 5 minutes and in parallel no users able to login. All the request has been blocked. Below is my configurations. <session-bean> <stateless> <bean-instance-pool-ref pool-name="ptest"/> </stateless> <stateful default-access-timeout="5000" cache-ref="simple"/> <singleton default-access-timeout="5000"/> </session-bean> <mdb> <resource-adapter-ref resource-adapter-name="hornetq-ra"/> <bean-instance-pool-ref pool-name="ptest-strict-max-pool"/> </mdb> <pools> <bean-instance-pools> <strict-max-pool name="slsb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/> <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/> <strict-max-pool name="ptest"/> <strict-max-pool name="ptest-strict-max-pool" max-pool-size="200" instance-acquisition-timeout="15" instance-acquisition-timeout-unit="MINUTES"/> </bean-instance-pools> </pools> Thanks and Regards, Boomi

11 years, 10 months

2
1
0 / 0

Subsystems external configuration files

by Dominik Pospisil

The transaction subsystem tries to read and parse $HOME/jbossts-properties.xml file and fails to start correctly if the file is incompatible with the runtime. [1] The general question is if it is OK when various subsystems as a default use external files (outside the domain configuration model and configured config dir) to get configuration? [1] https://issues.jboss.org/browse/JBPAPP-9170 Thanks, Dominik

11 years, 10 months

1
0
0 / 0

ipv6 "usability" question

by Max Rydahl Andersen

Hi guys, Trying to be sure our tools actually can connect/work with ipv6 enabled servers we're are hitting a bit of a snag. Is it expected that clients unescapes/escapes ipv6 addresses or is :::1 and [:::1] considered equivalent ? i.e. do code need to add []'s when constructing urls, and remove []'s when passing it to things that just need an address ? Just wondering if we could tells users to put [::1] into hostname fields if they want to use ipv6 - then we don't need to add all this escaping/unescaping for ipv6 in the UI layer of tools. /max

11 years, 11 months

4
5
0 / 0

Use a module to setup external dependencies for a JMS Bridge?

by Jeff Mesnil

still working on the JMS bridge... :) The JMS bridge uses JNDI to lookup the JMS resources of external JMS brokers. This means that I must have the client implementation classes of these brokers inside AS7 to instantiate them. More precisely, the JMS Bridge code is located in HornetQ jar, so the external jars must be made available to org.hornetq module. As I don't want to modify this module to be able to configure a JMS bridge, I did a more convoluted thing. There is already a reverse dependency from org.hornetq to org.jboss.as.messaging module (so that HornetQ can instantiate AS7 integration classes). Leveraging this, I added another org.jboss.as.messaging.bridge-integration module that is the placeholder for these external jars. This module is a dependency of org.hornetq through org.jboss.as.messaging. org.jboss.as.messaging.bridge-integration (contains external ^ brokers resources) | | depends-on | | org.jboss.as.messaging --depends-on--> org.hornetq (contains ^ | the JMS Bridge) | | | | | | +---------------------------------------+ reverse dependency so that HornetQ can instantiated AS integration classes It works, I am able to bridge ActiveMQ (I don't have the jars of other brokers to test) to HornetQ with it. It requires to: 1. add ActiveMQ client jars to module/org/jboss/as/messaging/bridge-integration/main 2. add them as <resource-root> to this bridge-integration module.xml wdyt? Is it acceptable to ask users to modify this module for JMS bridge integration? Is there a simpler/better way to achieve this? Am I shooting myself in the foot when I will bridge to an older AS version (haven't tried it yet)? I have now 2 modules (org.jboss.as.messaging and org.jboss.as.messaging.bridge-integration) for the messaging subsystem? Is that OK? thanks, jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/

11 years, 11 months

2
2
0 / 0

Modularity is the spawn of Lucifer and a stinking donkey

by Emmanuel Bernard

Now that I have your attention, I'd like to discuss issues we are experiencing when trying to modularize the Hibernate portfolio and make it work in AS 7.1. ## Disclaimer I perfectly understand all the coolness about modularity (speed, easier dependency isolation etc). I have also carefully read : - https://community.jboss.org/wiki/ModuleCompatibleClassloadingGuide - https://community.jboss.org/wiki/ModularSerialization But these tend to avoid the more complex cases of portable libraries that ought to run even outside AS 7 but have a wide variety of class and resource loading needs. I am not a complete modularity bozo but I am definitely not familiar with JBoss Modules nor similar solution. ## Requirements / Landscape Hibernate ORM uses the notion of service registry and integrator object that help during the integration or customization of the engine behavior by third-party frameworks. Enlistment of Integrators is done via the service locator pattern (a service file in META-INF/services/ that is looked up and contain the implementation class(es) at stake. Hibernate Envers is one of those customizer that depends on Hibernate ORM. Note that the core of Hibernate ORM does not depend on Hibernate Envers. The service locator file is contained in Hibernate Envers JAR. Hibernate OGM likewise, heavily customizes ORM and depends on Hibernate ORM classes - the reverse is not true. The service locator file is contained in Hibernate OGM JAR. Hibernate Search optionally depend on Hibernate ORM and JPA. The core of Hibernate Search is independent but an Hibernate Search ORM module has an integrator implementation. On top of that, Hibernate Search optionally depend on some JPA classes and behaves differently if they are there - we look them up in the classpath by reflection. On top of that, these projects do load resources (config files, classes): - from what Jason calls a Deployment classloader (the user application classes and resources really) - entities, custom analyzer implementations, resources files etc. A user could even write a custom Integrator and use the service locator pattern from his application. - from direct dependencies (Lucene is a declared dependency of Hibernate Search) - from dependencies of the deployment: for example an app developer adds the phonetic analyzer as a dependency of his application and ask Hibernate Search to use it - from modules that use these projects. Modeshape and Capedwarf are being modularized and are making use of Hibernate Search as a module. Properly loading the necessary classes located in Modeshape or Capedwarf's module but from Hibernate Search's engine proves to be very hard in our current approach. All of these projects should be able to run outside JBoss AS 7, so a modular friendly solution should somehow be abstracted and generic enough. ## What solution? More and more projects are being modularized including ones with complex resource loading dependencies like the ones I have described. AFAIK Infinispan is even in a worse situation as clustering and late class binding is at stake but let's put this one aside. I'd love to get a reference design outcome from this thread that could be copied across all these projects and future ones like Bean Validation. Today, we mostly use the good old and simple TCCL model which works fine if the jars are directly embedded in the app but fail the minute we start to move these dependencies into modules. Sanne, Strong, Scott Marlow and I are using dangerous amount of Advil to try and make everything work as expected. Some help would be awesome. To sum up: - can the Hibernate portfolio be supported within JBoss Module and how? - what kind of ClassloaderService contract should we use within these projects to be modular friendly (JBoss Modules and others)? - would such contract be generic enough to be extrapolated to JSRs in need of modular friendliness? - how to solve the chicken and egg issue of the bootstrapping: if we need to pass a ClassloaderService impl? How do we do that best in a modular environment without forcing the application developer to implement such godforsaken ClassloaderService contract or even worse pass directly to us the right classloader for each call. Thanks, Emmanuel

11 years, 11 months

9
36
0 / 0

Remote JNDI lookup from the messaging subsystem

by Jeff Mesnil

Hi, I'm working on a task to add managed JMS bridges to AS7 and needs some help with modules loading and dependencies. A JMS bridge is a piece of code provided by HornetQ that allows to consume messages from one "source" broker (often a legacy or proprietary broker) to another "target" broker (e.g. HornetQ). It is completely separated from HornetQ JMS implementation and relies only on JavaEE APIs (JNDI, JMS, JTA). I got something working using the simplest case possible: both the source and target brokers are the AS7 instance where the JMS bridge is deployed. It's useless but it's a start :) The 3 use cases that are useful are: 1. setup the source broker to be another AS7 instance 2. setup the source broker to be an older AS version (e.g. for updates) 3. setup the source broker to be *any other JMS implementation* (e.g. for migration) I'm having some issues with the use cases dealing with JNDI setup and modules. For all 3 use cases, the JMS bridge code (coming from HornetQ) instantiates a JNDI InitialContext with configurable properties to lookup the source and destination JMS resources. I got it working when everything is in the same AS7 instance. However, it doesn't when I am looking up from another AS7 instance using our JNDI remote: protocol. It's failing because org.jboss.as.messaging is not able to load org.jboss.remote.naming classes. I added org.jboss.remote-naming to the messaging modules.xml but it is not enough. I now get a linkage error (cf at the end of my mail) Basically my problem is do be able to do a remote JNDI lookup from inside an AS7 service. There is some documentation to do that for EJBs with outbound socket bindings[2]. I could make it work to lookup from another AS7 instance but it's not general enough. In real use case, the lookup will be to another broker (or an older AS version) with its own set of classes that needs to be isolated from the rest of the messaging service. Does someone have a pointer that could help? Have we another AS7 service doing something similar? btw, the documentation about modules[1] displays nothing: "Latest content for this page is not approved!" thanks, jeff [1]: https://docs.jboss.org/author/display/MODULES/Specifying+dependencies [2]: https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+... The linkage error: 17:39:45,979 WARN [org.jboss.modules] (MSC service thread 1-5) Failed to define class org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector in Module "org.jboss.remote-naming:main" from local module loader @851052d (roots: /home/jmesnil/Developer/jboss-as/build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules): java.lang.LinkageError: Failed to link org/jboss/naming/remote/client/ejb/RemoteNamingEjbClientContextSelector (Module "org.jboss.remote-naming:main" from local module loader @851052d (roots: /home/jmesnil/Developer/jboss-as/build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules)) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:396) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73) at org.jboss.modules.Module.loadModuleClass(Module.java:527) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) at org.jboss.naming.remote.client.InitialContextFactory.<clinit>(InitialContextFactory.java:118) [jboss-remote-naming-1.0.3.Final.jar:1.0.3.Final] at java.lang.Class.forName0(Native Method) [rt.jar:1.6.0_24] at java.lang.Class.forName(Class.java:264) [rt.jar:1.6.0_24] at org.jboss.as.naming.InitialContextFactoryBuilder.createInitialContextFactory(InitialContextFactoryBuilder.java:61) [jboss-as-naming-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:681) [rt.jar:1.6.0_24] at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305) [rt.jar:1.6.0_24] at javax.naming.InitialContext.init(InitialContext.java:240) [rt.jar:1.6.0_24] at javax.naming.InitialContext.<init>(InitialContext.java:214) [rt.jar:1.6.0_24] at org.hornetq.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:55) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:40) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1083) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.jms.bridge.impl.JMSBridgeImpl.start(JMSBridgeImpl.java:348) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.jboss.as.messaging.jms.bridge.JMSBridgeService.start(JMSBridgeService.java:57) [jboss-as-messaging-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.6.0_24] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.6.0_24] at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24] Caused by: java.lang.NoClassDefFoundError: org/jboss/ejb/client/ContextSelector at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_24] at java.lang.ClassLoader.defineClass(ClassLoader.java:634) [rt.jar:1.6.0_24] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) [rt.jar:1.6.0_24] at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:327) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:391) ... 26 more Caused by: java.lang.ClassNotFoundException: org.jboss.ejb.client.ContextSelector from [Module "org.jboss.remote-naming:main" from local module loader @851052d (roots: /home/jmesnil/Developer/jboss-as/build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules)] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) ... 31 more -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/

11 years, 11 months

2
3
0 / 0

Web console vs. CLI vs. CLI GUI

by Heiko Braun

Thanks for the explanation Stan. The web console uses a different paradigm then the other tools, and it does so on purpose. The result of what you describe would basically build on the "tree" paradigm and more or less expose the management functionality like the CLI and it's bigger cousin do. But it targets different persona and thus other needs. The console provides an interim information layer, that provides alternate conceptual views, that go beyond "trees". The biggest difference towards the other tools is that it tries to facilitate understanding of the underlying model. This includes arrangement, grouping and exposure of the underlying information aligned with the users tasks. You think of it too much in technical terms. Your approach is a valid one for people that can be considered "power users". Users that know the model. For them a "tree" paradigm work works well. The CLI GUI is a hybrid, but only serves former CLI users well. For them it might be an enhancement. But it's not serving the needs of the less experienced developer or administrator. A good comparison would probably be a data management tool. You can provide direct SQL access to the data or some web based interface that's much closer to business domain. The AS7 web console would be the later. >From my experience, people perceive the web interface as being simple and easy to get started. But designing for "simple" isn't easy. And it comes at a certain price. In our case we did sacrifice development time for user experience. Long story short: The management tools serve different audiences. Each audience brings their own experience, knowledge and skills. Building the web console on same paradigms the CLI tools would eliminate the for having it in the first place. /Heiko On May 18, 2012, at 1:53 PM, ssilvert(a)redhat.com wrote: > On 5/18/2012 5:56 AM, Heiko Braun wrote: >> >> Stan, >> >> you've said that you think the console project was going in the wrong direction. >> Can you elaborate on that? >> >> >> Regards, Heiko > > I didn't say it was going in the wrong direction. That's not how I > would put it. > > I think the project was architecturally wrong from the very beginning. > I know that's a strong statement and again I want to say that I'm proud > of what we accomplished. Hard work and clever programming can make up > for a lot of flaws. > > We couldn't be expected to make all the right choices at a time when we > didn't yet understand the management model that was still being > developed. And it is our misuse of the management model that > constitutes the fundamental architectural flaw. > > I think this is best explained with an example, so I'll give you the > same example I gave to Bruno yesterday. Open CLI GUI and navigate to > /subsystem=logging/logger=*. Right-click on the logger=* node and > select add. There you will see a fairly complex dialog with four types > of widgets. Also, the drop-downs are filled in with the proper values > and the required fields are marked appropriately. You can hover over > any field label to get context-sensitive help. > > I didn't write a single line of code to generate the "add logger" > dialog. It was all built from the metadata in the management model. > > This has tremendous implications on development time. Getting CLI GUI > to a point where it could do all this for every AS7 resource took about > two weeks. Yet, to develop the ability to manage just the logging > subsystem in the web console took months. And when the logging > subsystem changed on the back end I had to rewrite the front end over > again. > > Clearly, we are not leveraging the management model properly. > > I could go on and on about other technical issues. I'm sure we can get > to that in due time, but I've written enough for now. > > The last thing I want to make clear is that I'm not trying to replace > the web console with CLI GUI. We need a web console. But the > comparative ease with which functionality can be developed in CLI GUI > constitutes low hanging fruit that can't be ignored. > > I do have some ideas about how we can work together to leverage both > platforms in a mutually beneficial way. Because I think code speaks > louder than words, I'm working on a demo that shows how both platforms > might work together. I'm hoping to have something ready to show late > next week. > > Stan > > > >

11 years, 11 months

6
11
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

jboss-as7-dev May 2012