[JBoss AS 7 Development] - How to use modules with ServiceLoader....
by Martin Wortner
Martin Wortner [https://community.jboss.org/people/wortner] created the discussion
"How to use modules with ServiceLoader...."
To view the discussion, visit: https://community.jboss.org/message/777163#777163
--------------------------------------------------------------
Hi,
we switched recently to JBoss 7(from 5:)
We have some "strange" design. Our ear application is using Java ServiceLoader service to load some, let's say, plugins from "plugins" folder we created in profile directory. We can change these jars only during server restart.
Now what I want to reach using jBoss 7.
- I'd like to be able to redeploy "plugins" jar on the fly i.e. using Maven jboss-as-plugin.
- Have possibility to drop the jars in the deployment folder to redeploying them.
- Maybe utilize the JBoss modules framework to do this(but I'm affraid of these dependencies and modules.xmls etc. seams to complicated)
So mainly is there a possibility to redeploy jars on the fly?
Can I create one module, with all plugins inside, just to enable loading from main ear's ServiceLoader?(the ear will need only one dependency to this module with all plugins)
What exactly are the "dynamic modules" how can I use them, static are copyied to "modules" folder, what about these dynamic ones?
Isn't the easiest solution just to use extracted ear and copy/ overwrite the plugins in the /lib folder?
What if the plugins formerly loaded only throught ServiceLoader have dependencies on the ear's libraries? Can ear have dependency on a module and the module dependency back to the ear???
What exactly happens when module is loaded, is just the module classpath added to the dependent ear's classpath??? When I some how redeploy the module will it stop the parent ear file?
Sorry for so many question, that are not so clear, because I have mixed so much things together, but just starting to understand this area.
But any hints how can I "Hot deploy" plugins, probably using jboss module, are really appreciated.
Best regards to all of you.
M.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/777163#777163]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 5 months
[JBoss AS 7 Development] - HornetQ issue while started on 7.1.3.Final
by Albert Dabrowski
Albert Dabrowski [https://community.jboss.org/people/aldab] created the discussion
"HornetQ issue while started on 7.1.3.Final"
To view the discussion, visit: https://community.jboss.org/message/777162#777162
--------------------------------------------------------------
After suceesful jboss AS 7.1.3.Final startup on standalone-full configuration some warning regarding disconnection on hornetq occurs. It's raw start-up with no changes and no deployments.
Do anyone had such similar issues? Once I remove connection pooling this warning will disapear but would be good to know what's the issue.
Environment: Windows, jboss AS 7.1.3.Final build taken from a tag
09:43:59,872 INFO [org.jboss.modules] JBoss Modules version 1.1.3.GA
09:44:00,012 INFO [org.jboss.msc] JBoss MSC version 1.0.2.GA
09:44:00,059 INFO [org.jboss.as] JBAS015899: JBoss AS 7.1.3.Final "Arges" starting
09:44:01,044 INFO [org.xnio] XNIO Version 3.0.6.GA
09:44:01,044 INFO [org.jboss.as.server] JBAS015888: Creating http management service using socket-binding (management-http)
09:44:01,044 INFO [org.xnio.nio] XNIO NIO Implementation Version 3.0.6.GA
09:44:01,059 INFO [org.jboss.remoting] JBoss Remoting version 3.2.8.SP1
09:44:01,075 INFO [org.jboss.as.logging] JBAS011502: Removing bootstrap log handlers
09:44:01,122 INFO [org.jboss.as.configadmin] (ServerService Thread Pool -- 32) JBAS016200: Activating ConfigAdmin Subsystem
09:44:01,137 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 33) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
09:44:01,169 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 37) JBAS010280: Activating Infinispan subsystem.
09:44:01,262 INFO [org.jboss.as.jacorb] (ServerService Thread Pool -- 38) JBAS016300: Activating JacORB Subsystem
09:44:01,325 INFO [org.jboss.as.connector.logging] (MSC service thread 1-2) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
09:44:01,340 INFO [org.jboss.as.osgi] (ServerService Thread Pool -- 49) JBAS011906: Activating OSGi Subsystem
09:44:01,356 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 48) JBAS011800: Activating Naming Subsystem
09:44:01,356 INFO [org.jboss.as.naming] (MSC service thread 1-1) JBAS011802: Starting Naming Service
09:44:01,387 INFO [org.jboss.as.security] (ServerService Thread Pool -- 54) JBAS013171: Activating Security Subsystem
09:44:01,403 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 58) JBAS015537: Activating WebServices Extension
09:44:01,403 INFO [org.jboss.jaxr] (MSC service thread 1-1) JBAS014000: Started JAXR subsystem, binding JAXR connection factory into JNDI as: java:jboss/jaxr/ConnectionFactory
09:44:01,419 INFO [org.jboss.as.security] (MSC service thread 1-1) JBAS013170: Current PicketBox version=4.0.13.Final
09:44:01,434 INFO [org.jboss.as.mail.extension] (MSC service thread 1-3) JBAS015400: Bound mail session [java:jboss/mail/Default]
09:44:01,840 WARN [org.jboss.as.messaging] (MSC service thread 1-1) JBAS011600: AIO wasn't located on this platform, it will fall back to using pure Java NIO. If your platform is Linux, install LibAIO to enable the AIO journal
09:44:01,840 WARN [jacorb.codeset] (MSC service thread 1-2) Warning - unknown codeset (Cp1252) - defaulting to ISO-8859-1
09:44:01,872 INFO [org.jboss.as.jacorb] (MSC service thread 1-2) JBAS016330: CORBA ORB Service started
09:44:01,919 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-4) Starting Coyote HTTP/1.1 on http-localhost/127.0.0.1:8080
09:44:02,028 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-1) live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=C:\Motorola\test\jboss-as-7.1.3.Final\standalone\data\messagingjournal,bindingsDirectory=C:\Motorola\test\jboss-as-7.1.3.Final\standalone\data\messagingbindings,largeMessagesDirectory=C:\Motorola\test\jboss-as-7.1.3.Final\standalone\data\messaginglargemessages,pagingDirectory=C
:\Motorola\test\jboss-as-7.1.3.Final\standalone\data\messagingpaging)
09:44:02,028 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-1) Waiting to obtain live lock
09:44:02,169 INFO [org.hornetq.core.persistence.impl.journal.JournalStorageManager] (MSC service thread 1-1) Using NIO Journal
09:44:02,200 INFO [org.jboss.as.jacorb] (MSC service thread 1-2) JBAS016328: CORBA Naming Service started
09:44:02,247 INFO [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-3) JBoss Web Services - Stack CXF Server 4.0.5.GA
09:44:02,247 INFO [org.hornetq.core.server.impl.FileLockNodeManager] (MSC service thread 1-1) Waiting to obtain live lock
09:44:02,247 INFO [org.hornetq.core.server.impl.FileLockNodeManager] (MSC service thread 1-1) Live Server Obtained live lock
09:44:02,340 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) JBAS015012: Started FileSystemDeploymentService for directory C:\Motorola\test\jboss-as-7.1.3.Final\standalone\deployments
09:44:02,356 INFO [org.jboss.as.remoting] (MSC service thread 1-3) JBAS017100: Listening on 127.0.0.1:9999
09:44:02,356 INFO [org.jboss.as.remoting] (MSC service thread 1-3) JBAS017100: Listening on 127.0.0.1:4447
09:44:02,528 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
09:44:02,559 INFO [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-1) Started Netty Acceptor version 3.2.6.Final-20df069 127.0.0.1:5455 for CORE protocol
09:44:02,559 INFO [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-1) Started Netty Acceptor version 3.2.6.Final-20df069 127.0.0.1:5445 for CORE protocol
09:44:02,559 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-1) Server is now live
09:44:02,559 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-1) HornetQ Server version 2.2.21.SNAPSHOT (HQ_2_2_21_final, 122) [ec7e3342-321d-11e2-9852-4db017d6b448]) started
09:44:02,575 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 61) JBAS011601: Bound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
09:44:02,575 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 60) JBAS011601: Bound messaging object to jndi name java:/ConnectionFactory
09:44:02,606 INFO [org.jboss.as.deployment.connector] (MSC service thread 1-1) JBAS010406: Registered connection factory java:/JmsXA
09:44:02,637 INFO [org.hornetq.ra.HornetQResourceAdapter] (MSC service thread 1-1) HornetQ resource adaptor started
09:44:02,637 INFO [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-1) IJ020002: Deployed: file://RaActivatorhornetq-ra
09:44:02,637 INFO [org.jboss.as.deployment.connector] (MSC service thread 1-1) JBAS010401: Bound JCA ConnectionFactory [java:/JmsXA]
09:44:02,669 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
09:44:02,669 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
09:44:02,669 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.1.3.Final "Arges" started in 3032ms - Started 166 of 252 services (85 services are passive or on-demand)
09:46:04,574 WARN [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl] (hornetq-failure-check-thread) Connection failure has been detected: Did not receive data from invm:0. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=3]
09:46:04,574 WARN [org.hornetq.jms.server.recovery.RecoveryDiscovery] (Thread-1 (HornetQ-client-global-threads-2022533)) Notified of connection failure in xa discovery, we will retry on the next recovery: HornetQException[errorCode=2 message=Channel disconnected]
at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.21.Final.jar:2.2.21.SNAPSHOT (HQ_2_2_21_final, 122)]
at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.21.Final.jar:2.2.21.SNAPSHOT (HQ_2_2_21_final, 122)]
at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.21.Final.jar:2.2.21.SNAPSHOT (HQ_2_2_21_final, 122)]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_02]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_02]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_02]
09:46:12,574 WARN [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl] (hornetq-failure-check-thread) Connection failure has been detected: Did not receive data from invm:0. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=3]
09:46:12,574 WARN [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Client connection failed, clearing up resources for session 4ac5c5dc-3225-11e2-a523-c7d24ec98fd0
09:46:12,574 WARN [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Cleared up resources for session 4ac5c5dc-3225-11e2-a523-c7d24ec98fd0
09:46:12,574 WARN [org.hornetq.jms.server.recovery.HornetQXAResourceWrapper] (Thread-0 (HornetQ-client-global-threads-2022533)) Notified of connection failure in xa recovery connectionFactory for provider ClientSessionFactoryImpl [serverLocator=ServerLocatorImpl [initialConnectors=[org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryGroupConfiguration=null], connectorConfig=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0, backupConfig=null] will
attempt reconnect on next pass: HornetQException[errorCode=2 message=Channel disconnected]
at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.21.Final.jar:2.2.21.SNAPSHOT (HQ_2_2_21_final, 122)]
at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.21.Final.jar:2.2.21.SNAPSHOT (HQ_2_2_21_final, 122)]
at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.21.Final.jar:2.2.21.SNAPSHOT (HQ_2_2_21_final, 122)]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_02]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_02]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_02]
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/777162#777162]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 5 months
[JBoss Tools Development] - How to Build JBoss Tools with Maven 3
by Mickael Istria
Mickael Istria [https://community.jboss.org/people/mickael_istria] modified the document:
"How to Build JBoss Tools with Maven 3"
To view the document, visit: https://community.jboss.org/docs/DOC-16604
--------------------------------------------------------------
**
#Environment_Setup Environment Setup
***
#Prerequisistes Prerequisistes
***
#Maven_and_Java Maven and Java
***
#Maven_settings Maven settings
***
#Maven__Java_Memory_Configuration Maven & Java Memory Configuration
**
#Verify_or_Install_ Verify or Install ?
**
#About_Target_Platform_and_related_profiles About Target Platform and related profiles
***
#Using_published_Target_Platform_definition_Recommanded Using published Target Platform definition (Recommanded)
***
#Or_getting_a_local_copy_of_the_Target_Platform Or, getting a local copy of the Target Platform
****
#Get_it Get it
*****
#_Download_TP_as_a_zip_and_install_it_by_yourself Download TP as a zip and install it by yourself
*****
#OR_use_MavenAnt_to_get_it OR, use Maven+Ant to get it
****
#Use_it Use it
****
#As_Maven_mirror_Recommended As Maven mirror (Recommended)
****
#OR_with_local_profiles_DEPRECATED OR, with local profiles (DEPRECATED)
**
#Optional_Build_parent_and_target_platform (Optional) Build parent and target platform
**
#Building_Individual_Components_Locally_Via_Commandline Building Individual Components Locally Via Commandline
***
#Build_a_component_resolving_to_a_recent_aggregation_build_for_other_JBT_dependencies_Recommanded Build a component resolving to a recent aggregation build for other JBT dependencies (Recommanded)
***
#Build_a_component_resolving_to_the_latest_CI_builds_for_other_JBT_dependencies Build a component resolving to the latest CI builds for other JBT dependencies
***
#Build_a_component_along_with_all_its_dependencies_from_sources_bootstrap_build Build a component along with all its dependencies from sources ("bootstrap" build)
**
#Building_Everything_In_One_Build_Locally_Via_Commandline Building Everything In One Build Locally Via Commandline
**
#Building_Locally_In_Eclipse Building Locally In Eclipse
**
#Installation_Testing__making_sure_your_stuff_can_be_installed_ Installation Testing - making sure your stuff can be installed
**
#Adding_a_new_feature_or_plugin_to_an_existing_component Adding a new feature or plugin to an existing component
**
#Dealing_with_timeouts_for_tests Dealing with timeouts for tests
**
#Tips_and_tricks_for_making_BOTH_PDE_UI_and_headless_Maven_builds_happy Tips and tricks for making BOTH PDE UI and headless Maven builds happy
***
#Check_your_buildproperties Check your build.properties
***
#Check_your_manifestmf_dependencies Check your manifest.mf dependencies
+*This article is a replacement for its precursor, https://community.jboss.org/docs/DOC-15513 How to Build JBoss Tools 3.2 with Maven 3.*+
+*Note that this article only discusses building from trunk. If you need to build from a branch, or switch between branches and/or trunk, see* https://community.jboss.org/docs/DOC-17497 How to Build JBoss Tools With Maven3 - Working With Branches+*.*
*+Looking for how to build our documentation? See+ https://community.jboss.org/docs/DOC-13341 Building JBoss Tools Documentation.*
h2. Environment Setup
h3. Prerequisistes
1. Java 1.6 SDK
2. Maven 3.0.3
3. About 6 GB of free disk space if you want to run all integration tests for (JBoss AS, Seam and Web Services Tools) - *requires VPN access*
4. subversion client 1.6.X (should work with lower version as well, but newer versions may not work as expected)
h3. Maven and Java
Make sure your maven 3 is available by default and Java 1.6 is used.
mvn -version
should print out something like
*Apache Maven 3.0.3* (r1075438; 2011-02-28 12:31:09-0500)
*Java version: 1.6.0_25*, vendor: Sun Microsystems Inc.
*Java home: /usr/java/jdk1.6.0_25/jre*
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "2.6.42.3-2.fc15.x86_64", arch: "amd64", family: "unix"
h3. Maven settings
Follow https://community.jboss.org/docs/DOC-15170 these instructions to add reference to JBoss Repositories into your settings.xml. You'll also probably need access to the SNAPSHOT repository. So here is what you should see in your ~/.m2/settings.xml
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
....
<profiles>
....
<profile>
<id>jboss-default</id>
<repositories>
<!-- To resolve parent artifact -->
<repository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Repository Group</name>
<url>http://repository.jboss.org/nexus/content/groups/public/</url>
</repository>
<repository>
<id>jboss-snapshots-repository</id>
<name>JBoss Snapshots Repository</name>
<url>https://repository.jboss.org/nexus/content/repositories/snapshots/</url>
</repository>
</repositories>
<pluginRepositories>
<!-- To resolve parent artifact -->
<pluginRepository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Repository Group</name>
<url>http://repository.jboss.org/nexus/content/groups/public/</url>
</pluginRepository>
<pluginRepository>
<id>jboss-snapshots-repository</id>
<name>JBoss Snapshots Repository</name>
<url>https://repository.jboss.org/nexus/content/repositories/snapshots/</url>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>jboss-default</activeProfile>
...
</activeProfiles>
</settings>
#
*What if Maven can't find the upstream artifacts in Nexus?*
Sometimes, Maven can't find the upstream artifacts - parent pom, tycho plugins, minimum (Juno SR0) or maximum (Juno SR1 or later) target platforms. To work around this, just build them locally:
cd /tmp; svn co http://anonsvn.jboss.org/repos/jbosstools/trunk/build/
mvn install -U -f build/parent/pom.xml
mvn install -U -f build/tycho-plugins/pom.xml
mvn install -U -f build/target-platforms/pom.xml -Pjbosstools-maximum,jbosstools-minimum
h3. Maven & Java Memory Configuration
To configure the amount of memory used by Maven, you can define MVN_OPTS as follows, either in the mvn / mvn.bat script you use to run Maven, or set as global environment variables. Here's how to do so for http://forums.fedoraforum.org/showthread.php?t=262465 Fedora, https://help.ubuntu.com/community/EnvironmentVariables Ubuntu, http://forums.techarena.in/windows-xp-support/1152405.htm Windows, http://www.digitaledgesw.com/node/31 OSX.
{code}
set MAVEN_OPTS=-Xms512m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m
{code}
h2. Verify or Install ?
+mvn verify+ will perform all build and test steps, but it won't install the bundles in your local repository. +mvn install+ does install in you local repository. When an eclipse-plugin is installed in your repo, it is always used as default when resolving dependency. It is not possible to roll-back a local installation of a bundle, so in most cases, +mvn verify+ is to be prefered to +mvn install+. However, if you want to build stuff sequentially through several maven invocations, and you want to resolve against just-built stuff, you'll need to use +mvn install+.
In this page, we'll encourage people to use *mvn verify* as much as possible to ensure *isolation*; but you can mvn install the same way if your use-case requires it.
h2. About Target Platform and related profiles
The target platform (TP) lists all dependencies (coming from Eclipse.or and other 3rd-party update sites) that are used by JBoss Tools. This target platform is materialized as an Eclipse p2 repository (formerly update-site) that is used during build to resolve dependencies. Target Platform is managed by JBoss Tools people, and only dependencies from this TP are allowed to be used in code.
If you need a new dependency in the TP, feel free to https://issues.jboss.org/secure/CreateIssueDetails!init.jspa?pid=10020&su... open a ticket to request it.
Here are several ways to build locally using this target platform. It's up to you to choose the one that match your needs:
h3. Using published Target Platform definition (Recommanded)
unified.target refers to the dependency as published in the Target Platfrom repository.
* Pros:* No additional thing to do than invoking Maven
* Always up-to-date
* Cons: Speed - (to evaluate)
Consume it by adding* +-Punified.target+* to you Maven invocation command-line
h3. Or, getting a local copy of the Target Platform
* Pros: Speed +++
* Cons: Step to be repeated whenever https://source.jboss.org/browse/JBossTools/trunk/build/target-platform/un... target platform changes
h4. Get it
h5. Download TP as a zip and install it by yourself
You can either download the TP as a zip and unpack it into some folder on your disk. For convenience, the easiest is to unzip into jbosstools/build/target-platform/REPO/, since that's where the Maven or Ant process will by default operate.
You can get it with a browser or a command line tool such as wget or curl at the following url:
http://download.jboss.org/jbosstools/updates/juno/SR0c/ http://download.jboss.org/jbosstools/updates/juno/SR0c/ http://download.jboss.org/jbosstools/updates/juno/SR0c/e420-wtp340.target... e420-wtp340.target.zip (current minimum TP)
http://download.jboss.org/jbosstools/updates/juno/SR1a/ http://download.jboss.org/jbosstools/updates/juno/SR1a/ http://download.jboss.org/jbosstools/updates/juno/SR1a/e421-wtp341.target... e421-wtp341.target.zip (current maximum TP)
and then unzip it :
unzip *.target.zip -d /path/to/my jbosstools/build/target-platforms/jbosstools-JunoSR0c/local/target/REPO/
or
unzip *.target.zip -d /path/to/my jbosstools/build/target-platforms/jbosstools-JunoSR1a/local/target/REPO/
*(Note that the default path used for <local.site> will change every time a new target platform is released which is a significant change over the previous (eg., SR1, SR2), so if this breaks because the default not points at an empty folder, it's time to get a new TP! Hurray for build-time notification you're using an old target platform!)*
h5. OR, use Maven+Ant to get it
In that case, you also need Ant 1.8.2 or later*.*
cd jbosstools/build/target-platform
mvn clean install -Pget.local.target
The get.local.target profile will resolve the target platform file, multiple.target, as a p2 repository on your local disk in ~/trunk/build/target-platform/REPO/. It may take a while, so you're better off from a speed point-of-view simply fetching the latest zip [5]. However, if you want to see what actually happens to create the TP (as done in Hudson) this is the approach to take.
Since the Maven profile is simply a wrapper call to Ant, you can also use Ant 1.8 or later directly:
cd jbosstools/build/target-platform
ant help # show usage instructions
h4. Use it
h4. As Maven mirror (Recommended)
Once you get the target platform available locally, you can use it instead of the remote sites to save time. For this, we can simply use Tycho target-platform mirroring: http://wiki.eclipse.org/Tycho/Target_Platform/Authentication_and_Mirrors#... http://wiki.eclipse.org/Tycho/Target_Platform/Authentication_and_Mirrors#...
So you can simply edit to your ~/.m2/settings.xml the definition of the repositories to mirror:
| |
| <settings>
<mirrors>
<!-- IMPORTANT: Sites in target platforms: must not have trailing slash! -->
<mirror>
<id>jenkins.jbosstools-JunoSR0c</id>
<mirrorOf>http://download.jboss.org/jbosstools/updates/juno/SR0c/REPO</mirrorOf>
<url>file:///home/hudson/static_build_env/jbds/target-platform_4.0.juno.SR0c/e420-wtp340.target/</url>
<layout>p2</layout>
<mirrorOfLayouts>p2</mirrorOfLayouts>
</mirror>
<mirror>
<id>jenkins.jbosstools-JunoSR1a</id>
<mirrorOf>http://download.jboss.org/jbosstools/updates/juno/SR1a/REPO</mirrorOf>
<url>file:///home/hudson/static_build_env/jbds/target-platform_4.0.juno.SR1a/e421-wtp341.target</url>
<layout>p2</layout>
<mirrorOfLayouts>p2</mirrorOfLayouts>
</mirror>
<mirror>
<id>jenkins.jbdevstudio-JunoSR0c</id>
<mirrorOf>http://www.qa.jboss.com/binaries/RHDS/updates/jbds-target-platform_4.0.ju...</mirrorOf>
<url>file:///home/hudson/static_build_env/jbds/jbds-target-platform_4.0.juno.SR0c/jbds600-e420-wtp340.target</url>
<layout>p2</layout>
<mirrorOfLayouts>p2</mirrorOfLayouts>
</mirror>
<mirror>
<id>jenkins.jbdevstudio-JunoSR1a</id>
<mirrorOf>http://www.qa.jboss.com/binaries/RHDS/updates/jbds-target-platform_4.0.ju...</mirrorOf>
<url>file:///home/hudson/static_build_env/jbds/jbds-target-platform_4.0.juno.SR1a/jbds600-e421-wtp341.target</url>
<layout>p2</layout>
<mirrorOfLayouts>p2</mirrorOfLayouts>
</mirror>
</mirrors>
</settings> |
h4. OR, with local profiles (DEPRECATED)
Just add -*P local.site -Dlocal.site=file:///path/to/target/repository/*
*NOTE:* You must specify a path starting with *file:///* (three or more slashes) to avoid errors such as "+p2.core.ProvisionException URI has an authority component+".
Examples
*LINUX / MAC USERS*
cd build
mvn clean install -U -B -fae -e -*P local.site -Dlocal.site=file:///${HOME}/trunk/build/target-platform/REPO/*| tee build.all.log.txt
*WINDOWS USERS*
cd c:\trunk\build
mvn3 clean install -U -B -fae -e -Plocal.site *-Dlocal.site=file:///C:/trunk/build/target-platform/REPO/* > build.all.log.txt
h2. (Optional) Build parent and target platform
This step is only useful if you are actually working on the parent or the target platform and want to test it locally. Otherwise, Maven will simply retrieve parent and TP from *https://repository.jboss.org/nexus/content/repositories/snapshots/org/jboss/tools/ JBoss Nexus* to perform your build.
This is only necessary when the TP change, prior to 3.3.Beta3
svn co http://svn.jboss.org/repos/jbosstools/trunk jbosstools
cd jbosstools/build/parent
mvn clean install
...
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Tools Target Platform Definition ............ SUCCESS [0.724s]
[INFO] JBoss Tools Parent ................................ SUCCESS [0.461s]
...
*NOTE: You need not fetch the entire JBoss Tools tree from SVN (or Git (http://divby0.blogspot.com/2011/01/howto-partially-clone-svn-repo-to-git....
*Instead, you can just fetch the build/ folder and one or more component folders, then as before,*
*build the parent pom. After that, go into the component folder and run maven there (#runmavenpercomponent).*
mkdir jbosstools
cd jbosstools
svn co http://svn.jboss.org/repos/jbosstools/trunk/ http://svn.jboss.org/repos/jbosstools/trunk/build
svn co http://svn.jboss.org/repos/jbosstools/trunk/ http://svn.jboss.org/repos/jbosstools/trunk/jmx
cd jbosstools/build/parent
mvn clean install
...
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Tools Target Platform Definition ............ SUCCESS [0.724s]
[INFO] JBoss Tools Parent ................................ SUCCESS [0.461s]
...
h2. Building Individual Components Locally Via Commandline
h3. Build a component resolving to a recent aggregation build for other JBT dependencies (Recommanded)
* Pros:* You build only your component
* You only need source for your component
* Speed to resolve deps: +
* You get generally the latest build for you component
* Cons:* Takes some time to resolve dependencies on other component
* Can sometimes be out of sync if no build occured recently for a component you rely on and had some important change. More risk to get out of sync than with the staging site.
Tracked by https://issues.jboss.org/browse/JBIDE-11516 https://issues.jboss.org/browse/JBIDE-11516
example:
*cd jmx*
mvn verify -P unified.target *-Pjbosstools-staging-aggregate*
h3. Build a component resolving to the latest CI builds for other JBT dependencies
* Pros:* You build only your component
* You only need source for your component
* You get generally the latest build for you component
* Cons* Takes some time to resolve dependencies on other component
* Can sometimes be out of sync if no build occured recently for a component you rely on and had some important change
* Speed to resolve deps: -
This profile is the one use for CI builds on Hudson.
*cd jmx*
mvn verify -P unified.target *-Pjbosstools-nightly-staging-composite*
h3. Build a component along with all its dependencies from sources ("bootstrap" build)
This will build exactly what you have locally
* Pros:* You are sure of the version of sources that is used for your JBT dependencies
* You don't loose time in resolving your JBT deps
* Cons:* You need sources for your dependencies too
* You often build more stuff that what you really want to test
cd ~/trunk/build
mvn verify -P unified.target -*P jmx-bootstrap*
h2. Building Everything In One Build Locally Via Commandline
Assuming you have a local copy of the target platform in ${HOME}/trunk/build/target-platform/REPO/ (as explained previously:
*LINUX / MAC USERS*
cd build
mvn clean install -P local.site -Dlocal.site=file:///${HOME}/trunk/build/target-platform/REPO/ | tee build.all.log.txt
(tee is a program that pipes console output to BOTH console and a file so you can watch the build AND keep a log.)
*WINDOWS USERS*
cd c:\trunk\build
mvn3 clean verify -P local.site -Dlocal.site=file:///C:/trunk/build/target-platform/REPO/
or
mvn3 clean verify -Plocal.site -Dlocal.site=file:///C:/trunk/build/target-platform/REPO/ > build.all.log.txt
If you downloaded the zip and unpacked is somewhere else, use -Dlocal.site=file:///.../ to point at that folder instead
h2. Building Locally In Eclipse
First, you must have installed m2eclipse into your Eclipse (or JBDS). You can install the currently supported version from this update site:
http://download.jboss.org/jbosstools/updates/indigo/ http://download.jboss.org/jbosstools/updates/indigo/
Next, start up Eclipse or JBDS and do *File > Import* to import the project(s) you already checked out from SVN above into your workspace.
https://community.jboss.org/servlet/JiveServlet/showImage/102-16604-57-13... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-5...
Browse to where you have the project(s) checked out, and select a folder to import pom projects. In this case, I'm importing the parent pom (which refers to the target platform pom). Optionally, you can add these new projects to a working set to collect them in your Package Explorer view.
https://community.jboss.org/servlet/JiveServlet/showImage/102-16604-57-13... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-5...
Once the project(s) are imported, you'll want to build them. You can either do *CTRL-SHIFT-X,M (Run Maven Build),* or right-click the project and select *Run As > Maven Build*. The following screenshots show how to configure a build job.
First, on the *Main* tab, set a *Name*, *Goals*, *Profile*(s), and add a *Parameter*. Or, if you prefer, put everything in the *Goals* field for simplicity:
+clean install -U -B -fae -e -Plocal.site -Dlocal.site=file://home/nboldt/tmp/JBT_REPO_Indigo/+
Be sure to check *Resolve Workspace artifacts*, and, if you have a newer version of Maven installed, point your build at that *Maven Runtime* instead of the bundled one that ships with m2eclipse.
https://community.jboss.org/servlet/JiveServlet/showImage/102-16604-57-13... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-5...
On the *JRE* tab, make sure you're using a 6.0 JDK.
https://community.jboss.org/servlet/JiveServlet/showImage/102-16604-57-13... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-5...
On the *Refresh* tab, define which workspace resources you want to refresh when the build's done.
https://community.jboss.org/servlet/JiveServlet/showImage/102-16604-57-13... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-5...
On the *Common* tab, you can store the output of the build in a log file in case it's particularly long and you need to refer back to it.
https://community.jboss.org/servlet/JiveServlet/showImage/102-16604-57-13... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-5...
Click *Run* to run the build.
https://community.jboss.org/servlet/JiveServlet/showImage/102-16604-57-13... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-5...
Now you can repeat the above step to build any other component or plugin or feature or update site from the JBoss Tools repo. Simply import the project(s) and build them as above.
h2. Installation Testing - making sure your stuff can be installed
Each component, when built, produces a update site zip and an unpacked update site which can be used to install your freshly-built features and plugins into a running Eclipse or JBDS instance.
Simply point your Eclipse at that folder or zip, eg., jar:file:/home/rob/code/jbtools/jbosstools/trunk/runtime/site/target/runtime.site.zip! or file:///home/rob/code/jbtools/jbosstools/trunk/runtime/site/target/repository/, and browse the site. If your component requires other upstream components to install, eg., Runtime Detection depends on JBoss Common, you will also need to provide a URL from which Eclipse can resolve these missing dependencies. In order of freshness, you can use:
1. http://download.jboss.org/jbosstools/updates/nightly/core/trunk/ http://download.jboss.org/jbosstools/updates/nightly/core/trunk/ (Nightly Trunk Site - updated every few hours or at least daily - *bleeding edge*)
2. http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/ http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/ (Composite Staging Site - updated every time a component respins - *bleedinger edge*)
3. http://anonsvn.jboss.org/repos/jbosstools/trunk/build/aggregate/local-site/ http://anonsvn.jboss.org/repos/jbosstools/trunk/build/aggregate/local-site/ (see the README.txt for how to use this site to refer to things you built locally - *bleedingest edge*)
h2. Adding a new feature or plugin to an existing component
Need to tweak a component to add a new plugin or feature? See https://community.jboss.org/docs/DOC-18373 https://community.jboss.org/wiki/AddingAPluginandorFeatureToAnExistingCom....
h2. Dealing with timeouts for tests
(To be rewritten soon...) http://lists.jboss.org/pipermail/jbosstools-dev/2012-September/005835.html http://lists.jboss.org/pipermail/jbosstools-dev/2012-September/005835.html
h2. Tips and tricks for making BOTH PDE UI and headless Maven builds happy
It's fairly common to have plugins compiling in eclipse while tycho would not work. Basically you could say that tycho is far more picky compared to Eclipse PDE.
h3.
Check your build.properties
Check build.properties in your plugin. If it has warnings in Eclipse, you'll most likely end with tycho failing to compile your sources. You'll have to make sure that you correct all warnings.
Especially check your build.properties to have entries for *source..* and *output..* -- these are needed to *http://wiki.eclipse.org/Minerva#Source generate source plugins and features*.
*
*
source.. = src/
output.. = bin/
src.includes = *
src.excludes = src
bin.includes = <your own,\
list of,\
files for inclusion,\
in the jar>
h3. Check your manifest.mf dependencies
A new issue when building against juno shows that all compilation dependencies MUST be EXPLICITLY mentioned in your manifest.mf list of dependencies. A recent example of how this can cause compilation errors is the archives module, which failed to build due to the org.eclipse.ui.views plugin, and its IPropertySheetPage interface, not being found during the build. After investigation, it was discovered that the archives.ui plugin did not explicitly declare a dependency on org.eclipse.ui.views.
Inside eclipse and during indigo builds, however, the depencency was found and there were no compilation errors. This was because a plugin archives.ui explicitly dependend on (org.eclipse.ui.ide) had an explicit dependency on org.eclipse.ui.views. The IDE was able to see that archives.ui dependended on org.eclipse.ui.ide, and org.eclipse.ui.ide depended on org.eclipse.ui.views.
Resolving nested dependencies no longer seems to be guaranteed, and so anything you have a compilation dependency on must now be explicitly declared in your manifest.mf
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-16604]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 5 months
[Javassist Development] - javassist and interfaces defining a method which throws an exception question
by ami tabak
ami tabak [https://community.jboss.org/people/amitabakoptier] created the discussion
"javassist and interfaces defining a method which throws an exception question"
To view the discussion, visit: https://community.jboss.org/message/777034#777034
--------------------------------------------------------------
A Question regarding the JVM spec and how javassist is expected to handle it.
I’ve an interface IMyFactory extending the Remote interface.
It declares a method foo() which declares throws RemoteException so will be deemed as remotable API
The implementing class implements the method but *doesn’t* declare itself as throwing the remote.
Code wise the JVM picked this method as valid Remote API
Javassist when interrogated class MyFactory.foo() method doesn’t provide any data on its being a throwing RemoteException
*Questions*
1. The JVM spec defines a method by its name and properties, not by its exception throwing.
In addition it allows an implementing method to declare less “throws” then its super / defining interface without loss of polymorphism
1. e.g. this foo() implementer is deemed the same as in the interface.
Why wont javassist provide me the exception data defined in the Interface’s CtClass ?
2) Is there a “recoursive” API in javassist that will wllow me to intergoate a method up to its interface definition to see if some one above it has defined it to be an
Throwable thrower or do I need to implement such search myself ?
*Code example:*
1. 1. MyFactory implements IMyFactory
{...
@Override
public int foo() //on purpose didn’t declare “throws java.rmi.RemoteException”
{
// TODO Auto-generated method stub
return 0;
}
1. 2. public interface IMyFactory extends Remote
{
public int foo() throws RemoteException;
}
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/777034#777034]
Start a new discussion in Javassist Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 5 months
[JBoss AS 7 Development] - Connection Re-Authentication and Security Propagation [DRAFT / Work In Progress]
by Darran Lofthouse
Darran Lofthouse [https://community.jboss.org/people/dlofthouse] modified the document:
"Connection Re-Authentication and Security Propagation [DRAFT / Work In Progress]"
To view the document, visit: https://community.jboss.org/docs/DOC-47864
--------------------------------------------------------------
h2. Introduction
The purpose of this article is to outline the problems that we are attempting to solve and the solution currently being considered, this work is being tracked under the following Jira issue: -
https://issues.jboss.org/browse/AS7-5901 https://issues.jboss.org/browse/AS7-5901
Currently for remote EJB invocations (Actually all invocations to the server but in this case EJB invocations are the priority) a Remoting connection is established by the client, early in establishing this connection the remote client performs authentication using SASL - once authenticated the authentication is valid for the life of the connection. As EJB invocations are received the identity on this connection is the identity used for the EJB call.
The following diagram illustrates the exising calls for remote EJB clients: -
https://community.jboss.org/servlet/JiveServlet/showImage/19891/Existing+... https://community.jboss.org/servlet/JiveServlet/downloadImage/19891/Exist...
The established connection here is a Remoting connection, the connection itself is independent of any service being accessed and on establishing the connection authentication is performed using the associated realm. Subsequently when the client connects to the EJB Container and sends a request to a deployed EJB the identity used for the EJB call is the identity taken from the underlying connection. As the authentication takes place as the connection is established the only way for the clients to send in requests as an alternative user is to establish a new connection as the new user.
A second scenario is where the call is also passed from one server to another: -
https://community.jboss.org/servlet/JiveServlet/showImage/19892/Existing+... https://community.jboss.org/servlet/JiveServlet/downloadImage/19892/Exist...
In this second scenario there is now a connection from the first server to the second server, this connection also requires authentication and the call to the EJB on the second server runs as the identity of this second connection.
These two diagrams illustrate the problems to be solved: -
* For a client to run as different identities different connections are required for each identity.
* For a server to server call the identity on the second server is the identity of the connection and not the original caller.
h3. Remoting Authentication
Before reviewing alternative solutions it is worth describing the decisions relating to the authentication of the actual connection as at the very minimum it is desirable that we do not undermine this with a solution that allows interception of the exchanges in such a way that either passwords are revealed or items are revealed that could be basis for a plain text attack.
When a client attempts to connect to the Remoting connection a challenge is sent back to the client containing a list of supported authentication SASL mechanisms that the client can select from to attempt to authenticate, the client selects on and attempts the authentication. If authentication succeeds then the client can then request to connect to the service it wished to use, if not the client is re-challenged with the list of mechanisms and this is repeated until the client either successfully authenticates or the list is exhausted.
The SASL mechanisms that are offered are selected based on the capabilities of the backing user store - as an example if we have a user store what we can query to obtain the users password or a pre-prepared hash of their password we offer the client the Digest-MD5 mechanism - however if we can only verify a supplied password but not generate the hashes required for Digest based authenitcation then PLAIN is offered as a mechanism.
A second SASL mechanism that we also support is the External mechanism, this mechanism is a special mechanism in that it automatically authenticates as an identity associated with the surrounding connection - currently we use this for ClientCert style authentication where after a TLS connection is established authentication will then proceed based on the clients certificate.
Another mechanism that we are currently adding support for is GSSAPI, this is a mechanism that authenticates a user by the use of authentication tokens with no exchange of passwords between the points involved in the authentication process.
The ability to authenticate using these different approaches where we can reduce the places where either passwords or replayable tokens are visible is the key reason why we do not want to introduce those kind of vulnerabilities in the solution to the two problems being described here.
h2. Proposed Solutions
This section describes the solutions currently considered and where appropriate describes why those solutions are currently discounted, at this point this is intended to be for discussion rather than a final definitive decision.
h3. Solution from Previous Releases
In previous AS releases unless a custom RMI socket was used the connections to the application server were not authenticated, instead the username and credential would be passed along with the EJB invocation and intercepted before the call reached the EJB - the supplied information would then be used to authenticate the remote user before allowing the call to proceed.
https://community.jboss.org/servlet/JiveServlet/showImage/19893/Previous+... https://community.jboss.org/servlet/JiveServlet/downloadImage/19893/Previ...
Where a client wanted to run as multiple identities that was fine as for each invocation a different username and password could be set for the call.
This approach also potentially allowed for the security context to be passed onto subsequent servers as the contents from this message invocation are available.
https://community.jboss.org/servlet/JiveServlet/showImage/19894/Previous+... https://community.jboss.org/servlet/JiveServlet/downloadImage/19894/Previ...
Whilst this approach does solve the problem of being able to switch identities and propagate identities it suffers from the problem that the users password is sent in the clear so should we undertake a similar solution for AS7 it would undermine the protection available from the currently available SASL mechanisms, in addition to this it is assuming that a username / password based authentication is always the approach we will want to take even though there are now alternative mechanisms in common use.
h3. Reauthenticate The Connection
As the calls are executed as the identity of the connection one approach could be to allow the client side to initiate a re-authentication of the connection so that a different identity can be used.
https://community.jboss.org/servlet/JiveServlet/showImage/19895/Reauthent... https://community.jboss.org/servlet/JiveServlet/downloadImage/19895/Reaut...
Whilst this would allow a client to switch identities and it could potentially be implemented using the SASL mechanisms the biggest issue here is if the client is multi-threaded and wants to run as multiple identities concurrently. At best the client would need to maintain a pool of connections one for each identity in use and if all identities could be used at once then it is no better than the current situation.
The multi threaded client issue is also made worse in the server to server case where sharing a single connection would be a major benefit in reducing the resources used.
For the server to server case there is also the issue regarding how is the users identity propagated to the second server, for this possible solution the multi-threaded client problem appears to be sufficiently blocking so will cover that in subsequent solutions.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-47864]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 5 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-11150
--------------------------------------------------
Of course, any modifications made to the ear at runtime will be lost when the patch is applied, since the old version of the module will no longer take precedence on the module path and will not be used.
I recommend you talk to the portal folks about how I recommended they deal with a requirement to use an exploded deployment. In their case it was user-modifiable and couldn't be deployed from inside a module.
Better yet, just write to the data/ dir or something and don't write inside the ear.
--------------------------------------------------
11 years, 5 months
.png){kind=link}
.png){kind=link}
