Menu
▾
▴
jboss-dev-forums — The jboss development forum posts
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(157) |
May
(789) |
Jun
(608) |
Jul
(554) |
Aug
(868) |
Sep
(654) |
Oct
(994) |
Nov
(803) |
Dec
(982) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1006) |
Feb
(1054) |
Mar
(1345) |
Apr
(1305) |
May
(1392) |
Jun
(1016) |
Jul
(265) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(19) |
| 2007 |
Jan
(20) |
Feb
(10) |
Mar
(20) |
Apr
(8) |
May
(4) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(6) |
Oct
(12) |
Nov
(7) |
Dec
(13) |
| 2008 |
Jan
(5) |
Feb
(4) |
Mar
(34) |
Apr
(32) |
May
(22) |
Jun
(21) |
Jul
(30) |
Aug
(18) |
Sep
(30) |
Oct
(23) |
Nov
(86) |
Dec
(51) |
| 2009 |
Jan
(25) |
Feb
(26) |
Mar
(34) |
Apr
(47) |
May
(38) |
Jun
(25) |
Jul
(36) |
Aug
(9) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(17) |
| 2010 |
Jan
(7) |
Feb
(9) |
Mar
(26) |
Apr
(49) |
May
(52) |
Jun
(48) |
Jul
(39) |
Aug
(27) |
Sep
(9) |
Oct
(14) |
Nov
(7) |
Dec
(10) |
| 2011 |
Jan
(12) |
Feb
(9) |
Mar
(17) |
Apr
(33) |
May
(39) |
Jun
(36) |
Jul
(29) |
Aug
(26) |
Sep
(29) |
Oct
(38) |
Nov
(35) |
Dec
(27) |
| 2012 |
Jan
(20) |
Feb
(34) |
Mar
(29) |
Apr
(33) |
May
(45) |
Jun
(46) |
Jul
(50) |
Aug
(35) |
Sep
(55) |
Oct
(68) |
Nov
(79) |
Dec
(45) |
| 2013 |
Jan
(67) |
Feb
(20) |
Mar
(55) |
Apr
(52) |
May
(25) |
Jun
(25) |
Jul
(34) |
Aug
(27) |
Sep
(21) |
Oct
(21) |
Nov
(19) |
Dec
(12) |
| 2014 |
Jan
(10) |
Feb
(8) |
Mar
(13) |
Apr
(18) |
May
(36) |
Jun
(26) |
Jul
(17) |
Aug
(19) |
Sep
(13) |
Oct
(8) |
Nov
(7) |
Dec
(5) |
| 2015 |
Jan
(11) |
Feb
(2) |
Mar
(13) |
Apr
(15) |
May
(7) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
(1) |
| 2016 |
Jan
(3) |
Feb
(5) |
Mar
(19) |
Apr
(34) |
May
(9) |
Jun
(10) |
Jul
(5) |
Aug
(10) |
Sep
(5) |
Oct
(11) |
Nov
(19) |
Dec
(7) |
| 2017 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(5) |
May
(12) |
Jun
(5) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <sco...@jb...> - 2005-05-02 18:48:08
|
So I created such a minimal build file that only references the apache-commons component: | <?xml version="1.0"?> | | <project name="jbossas-thirdparty" | default="synchronize" | basedir="."> | <!-- Import the types --> | <import file="../tools/etc/jbossbuild/tasks.xml"/> | | <property file="synchronize.properties"/> | <property file="local.properties"/> | | <build id="jbossas-thirdparty" | impltitle="JBossAS" | implversion="4.0.2" | implvendor="JBoss Inc." | implurl="http://www.jboss.org" | description="JBoss Application Server" | cvsroot="${cvs.prefix}@cvs.forge.jboss.com:/cvsroot/jboss" | thirdpartypath="../thirdparty/" | location="http://cruisecontrol.jboss.com/repository" | targetdefs="targets"> | | <component id="apache-commons" | version="mixed"> | <artifact id="commons-logging.jar" release="lib"/> | <artifact id="commons-httpclient.jar" release="lib"/> | <artifact id="commons-discovery.jar"/> | <artifact id="commons-collections.jar"/> | </component> | | </build> | | <!-- Generate the targets --> | <generate generate="jbossas-thirdparty"/> | | </project> | but when I try to execute the build, it says there is no synchronize target. Using synchronize.artifacts works, so is that what you meant or is there a synchronize target that is supposed to be created? | [starksm@banshee9100 jboss-4.0_thirdparty]$ ant -projecthelp | Buildfile: build.xml | Overriding previous definition of reference to jbossas-thirdparty | | Main targets: | | show Show the targets | synchronize.artifacts Synchronize for all the artifacts | synchronize.commons-collections.jar Synchronize for the artifact commons-collections.jar | synchronize.commons-discovery.jar Synchronize for the artifact commons-discovery.jar | synchronize.commons-httpclient.jar Synchronize for the artifact commons-httpclient.jar | synchronize.commons-logging.jar Synchronize for the artifact commons-logging.jar | Default target: synchronize | | [starksm@banshee9100 jboss-4.0_thirdparty]$ ant synchronize | Buildfile: build.xml | Overriding previous definition of reference to jbossas-thirdparty | | BUILD FAILED | Target `synchronize' does not exist in this project. | | Total time: 0 seconds | Also, why is there the anonymous wrote : Overriding previous definition of reference to jbossas-thirdparty message? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876191#3876191 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876191 |
|
From: naveen_arur <nu...@jb...> - 2005-05-02 18:42:34
|
Where can I download the Jboss/tomcat5 bundle?? Honestly I am lost. There is no link (or I can't find any). The tomcat link just takes me to the tomcat site. Or is it that jboss is pre-intgrated with tomcat starting from jboss4. or sholud I do it manualy.Guide me please View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876190#3876190 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876190 |
|
From: <sco...@jb...> - 2005-05-02 18:31:45
|
Yes, there is a red flag issue once you have a service trying to interact with multiple class loaders, but it should be possible if designed for this. The only classes that are subject to linkage errors and class cast expections are those that show up in the service's interface (ignoring any bugs due to caching of types by the class loader or other layers). This of course means a detyped interface in general. An interesting question is, if such an interface was modifed to use generics, is there any type leakage. As far as I understand the generics type nullifcation mechanism, the type binding would be in the client usage context and therefore its class loader context, but this is something I would like to verify, and verify that it works with type reloading in the client class loader. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876187#3876187 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876187 |
|
From: <cle...@jb...> - 2005-05-02 17:09:49
|
We (Ryan and I) were running cruisecontrol using the PermSize option at the startserver. We have used both the default JVM (1.4.2) and changed it to 1.5_01, just to see what happens. When using JVM 1.4.2 with PermSize option, the Server's JVM hangs. it hangs so badly that even a kill -3 was ignored by that JVM. We don't have any core dumped. When using JVM 1.5_01 with PermSize option, the testsuite passed ok: http://cruisecontrol.jboss.com/cc/artifacts/jboss-4.0-testsuite/20050502111308/results/index.html We are now removing the PermSize, and running it again with JVM 1.5, but it looks like we have some issue going on here. I don't want to make any guesses now, but I will try to look for ClassLoading issues regarding deployments and undeployments happening on the testsuite. Clebert View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876176#3876176 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876176 |
|
From: wobbet <nu...@jb...> - 2005-05-02 16:42:01
|
Ahhhhh... The problem appears to be that this is a headless workstation running only in CLI mode. I don't have X11 installed at all. Is there another easy install or am I going to have to do the basic install and then manual configuration? What about the build instructions at http://wiki.jboss.org/wiki/Wiki.jsp?page=MailServicesBuilding? Will those work for me or is there more that I will have to do beyond setting up user accounts? Thanks! rjsjr View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876174#3876174 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876174 |
|
From: wobbet <nu...@jb...> - 2005-05-02 16:25:41
|
Running on Linux - some RedHat distro running the 2.4 kernel. PIII 500 MHz machine (yes, it does still run...). Java 1.4.2_08 Just downloaded M2 of JBossMail services and tried to run the build... I do have JAVA_HOME and JBOSS_HOME set. I do *not* have ANT_HOME set. I get the following build error. rjsjr [root@www jbossmail]# ./install.sh --help Launching ant from ./ant/apache-ant-1.6.1/bin Buildfile: build.xml graphical-install: [hostname] java.lang.ArrayIndexOutOfBoundsException: 1 [hostname] at org.jboss.cheese.HostNameTask.execute(HostNameTask.java:42) [hostname] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:269) [hostname] at org.apache.tools.ant.Task.perform(Task.java:364) [hostname] at org.apache.tools.ant.Target.execute(Target.java:301) [hostname] at org.apache.tools.ant.Target.performTasks(Target.java:328) [hostname] at org.apache.tools.ant.Project.executeTarget(Project.java:1215) [hostname] at org.apache.tools.ant.Project.executeTargets(Project.java:1063) [hostname] at org.apache.tools.ant.Main.runBuild(Main.java:632) [hostname] at org.apache.tools.ant.Main.startAnt(Main.java:183) [hostname] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:197) [hostname] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:56) [Cheese] execute for cheese [Cheese] ue.taskname at cheese Splash BUILD FAILED java.lang.UnsatisfiedLinkError: /usr/java/j2sdk1.4.2_08/jre/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory Total time: 3 seconds View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876172#3876172 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876172 |
|
From: <ad...@jb...> - 2005-05-02 16:22:20
|
I think chaining is likely to lead all sorts of linkage errors or Class Casts. If you don't want an MBean to run under its own classloader you can do this, e.g. just doing a plain registerMBean without specifying a classloader will do this. Or could not use a JMX invocation and allow a getInstance() method to bypass the JMX Bus. A more general solution would be to add metadata on which operations should be run in the caller classloader versus the deployment classloader like lifecycle operations. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876170#3876170 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876170 |
|
From: <ad...@jb...> - 2005-05-02 15:59:30
|
Finally, the cross-cutting and deployment versioning must eventually allow for node specific configuration where the nodes heterogenous. In this case, some nodes will need their own local configuration overrides because they are not as capable as other nodes. You can also imagine nodes co-operating more to manage resources. e.g. If you one node has idle db connections while another is running out, the idle connections could be closed in favour of the busier node. But we are getting slightly off the topic of deployment at here. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876167#3876167 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876167 |
|
From: <ad...@jb...> - 2005-05-02 15:55:20
|
Like I said, a lot of this should be subject to policy. e.g. in a cluster you don't need to hold new requests while the switch is taking place, instead you can force them to failover to a machine that is not currently making a switch between deployment versions. e.g. you may not be bothered about some state surviving redeployment View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876164#3876164 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876164 |
|
From: <ad...@jb...> - 2005-05-02 15:53:25
|
On recovery This is a bit more complicated, but again a simple solution is to use the elected cluster "co-ordinator" as a reference (assuming you don't have a reference node as described above in the version processing). If the co-ordinator can deploy something and another node fails, this will generally mean that it has got out-of-sync or has some other problem. The obvious solution then is for that machine to be automatically restarted so it can recover its deployment state from the correct versioned deployment either from the co-oridinator or the reference node. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876162#3876162 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876162 |
|
From: <ad...@jb...> - 2005-05-02 15:50:51
|
On Staging The most obvious solution is to take each machine to the point where we know the new deployment will work, but then flip each individually in a round robin manner. This means only one node is not serving requests and state can be retrieved from the rest of the cluster. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876161#3876161 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876161 |
|
From: <ad...@jb...> - 2005-05-02 15:49:17
|
On Transactional Deployment. This is where you want the deployment to work on all nodes or none at all. In general this will require the atomic deployment described above, but it also needs to take into staging and recovery features, both should be pluggable policy features. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876159#3876159 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876159 |
|
From: <ad...@jb...> - 2005-05-02 15:47:43
|
On Atomic Deployments. The aim here is to replace redeploy == undeploy/deploy with something as near atomic and undistruptive as possible. The redeploy will become something like: * See whether the deployment can be constructed * If it works, wait for current requests to complete and hold new requests (this is called the "valve") * Once current requests are done, switch the from old to new deployment, e.g. flip the jndi bindings and other outward facing references - this may also require some handoff of state, e.g. handing over cache/session objects * Remove the old/replaced deployments NOTE: Because of classloading requirements, the cache/session handover will almost certain require some of form serialzation. Either passivation of the sessions to disk or replication from the other cluster nodes. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876158#3876158 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876158 |
|
From: <sco...@jb...> - 2005-05-02 15:44:15
|
APT combined with the Java Compiler API effort: http://www.jcp.org/en/jsr/detail?id=199 which is also being considered for jdk6 I would think be providing that info. I guess the big mismatch here is that these are source based tools and we really need bytecode based tools. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876157#3876157 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876157 |
|
From: <ad...@jb...> - 2005-05-02 15:42:22
|
The second direction is versioned deployment which will eventually lead to "atomic deployments". The original aim of this feature is to allow a reference machine (not a production machine) to be configured from a known production configuration (e.g. version 5). When the admin is happy with the new config, he can make it the production config (version 6). At any point, if problems are found, the admin can "rollback" to a known config version. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876155#3876155 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876155 |
|
From: <ad...@jb...> - 2005-05-02 15:39:48
|
The first direction we will be taking in JBoss5 is to make the notion farm, singleton, replication, federation, etc. an aspect of each deployment rather than have different folders for these notions. This allows the features to be "mixed and matched" more easily. e.g. being able to farm a singleton where you deploy it to one node, it is distributed to all nodes but only activated on one. This is our "aspectized" deployment framework, here's the original requirements docs if you are not familiar with it: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossKernel These features will be configurable on individual services, not just whole deployments so you can have for example an EAR that has some components as singletons and others doing what farm does today. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876154#3876154 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876154 |
|
From: <ad...@jb...> - 2005-05-02 15:34:02
|
First here's a critique of the farm service. The major concern with the farm service is that It lacks the ability to stage deployments. 1) It just distributes the deployments on a best effort across the cluster with no reconciliation on whether the deployment works on each peer. 2) There is the potential that every node in the cluster could be redeploying the application, making it generally unavailable. 3) There are race conditions where two nodes could deploy things in different orders based on farm deployments to different nodes "at the same time". View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876153#3876153 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876153 |
|
From: <ad...@jb...> - 2005-05-02 15:30:26
|
This discussion really belongs in the deployment forum, so I will move it there. It also deals with a number of "cross cutting concerns" so I will deal with each individually and give a sort of road-map of our thinking for JBoss5. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876152#3876152 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876152 |
|
From: Scott.Marlow.Novell <nu...@jb...> - 2005-05-02 15:26:24
|
I'm trying to help with Farm deployment and would like to start a forum discussion on issue JBCLUSTER-26. Ben Wang and I discussed the need for atomic deployment support last week, the information below is partly based on our conversation and my understanding of the task. These are my words and not his (okay, disclosure is complete :-) Deployment should be atomic or atomic like. Deployment should only complete on any machine if the application can be copied to all nodes and deployed on all nodes. If the deployment fails on any one machine, the deployment should rollback on every machine to its previous state. If a user farm deploys a newer application that is already farm deployed, the new application replaces the old one, unless we have to rollback (in which case we stick with the old app version.) The user that initiates the deployment should be considered the administrator for the deployment operation, results from the cluster nodes should be delivered to the administrator machine in some form (something like ?CrimePortalBeans.jar successfully copied to node1, CrimePortalBeans.jar deployed on node1, CrimePortalBeans.jar failed to be copied to node2, rollback...?.) The results for each node should also be logged locally on each node to help with troubleshooting. Does this sound right? Should we go with a two phase approach backed by a transaction log or take a lighter approach to tighten up the current support. Some interesting cases might be: 1.Reboot server during farm deploy (after file is copied into farm folder). rollback should occur after reboot. Do the same for all nodes in the cluster, rollback should occur after reboot. 2.Same as #1 but previous copy of the application exists already and needs to be restored to the farm folder without appearing as a new update. 3.Read only farm folders (http url) may present some challenges, not sure how they fit into the atomic model. 4.Start cluster node1 with app already in farm folder, then start node2, make sure that application changes deploy in the right direction. This is difficult because the current information is ambiguous (should the app be removed from node1 or added to node2). I propose that the decision should always be to add the app to the cluster rather than remove it from the cluster. If you want to remove an application from a cluster, you will have to remove it from a ?live? cluster node (node that is currently part of the cluster). 5.If we use a transaction log (would contain changes to the cluster) how does the user manage it? 6.Rollback operation may fail, how do we handle rollback failures? A third approach might be to support farm deployment from a source control system. This might be nice as you would know exactly what is in use on the cluster and have a nice history of deployed archives. This solves different problems than atomic deployment but wanted to mention it in case others thought it would help. The objective would be to maintain a ?single truth? as to what should be running on the cluster. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876150#3876150 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876150 |
|
From: mikezzz <nu...@jb...> - 2005-05-02 15:21:42
|
Even with release 2.0 I would like to maintain jdk 1.4 compatibility. I think we could do it through some kind of adapter layer. Wouldn't be as good as the NIO stuff, but would provide a fall back for users that need it. I would probably only drop 1.4 support completely if it turned out to be a real pain to maintain. I will put this on the back burner and focus on 1.0 features for the time being. Mike View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876151#3876151 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876151 |
|
From: sven.schulz <nu...@jb...> - 2005-05-02 14:50:15
|
Roy, I don't know why the ADF crew is doing what they do (remember it's closed source). I believe that they are simply not aware that there are other options to access e.g. context values using FacesContext. Julien, I'm happy to hear that. Could you elaborate on how to use this adapter and state when it will be available? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876146#3876146 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876146 |
|
From: <sco...@jb...> - 2005-05-02 14:47:46
|
The mbean invokers set the current thread context class loader to that of the mbean on op dispatches. This is what you want in general, but if the mbean represents a shared service like a cache that interacts with other isolated deployments, the thread context class loader needs to be that of the caller. We need a notion of a chained thread context class loader which would combine the incoming thread context class loader with that of the mbean service as its parent to allow for visibility into both layers. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876145#3876145 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876145 |
|
From: <ju...@jb...> - 2005-05-02 14:42:07
|
Jetspeed portal bridges has a good way to circumvent this.
| public interface ServletContextProvider
| {
| ServletContext getServletContext(GenericPortlet portlet);
|
| HttpServletRequest getHttpServletRequest(GenericPortlet portlet, PortletRequest request);
|
| HttpServletResponse getHttpServletResponse(GenericPortlet portlet, PortletResponse response);
| }
|
We are implementing it on our side. I think it is a reasonable agreement between the portal and the bridges as usual.
In that case running oracle ADF would need to use that implementation through an adapter.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876144#3876144
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876144
|
|
From: <roy...@jb...> - 2005-05-02 14:36:37
|
I'm curious... what is it you need from HTTPServletRequest that is not found in PortletRequest? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876143#3876143 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876143 |
|
From: <ad...@jb...> - 2005-05-02 14:21:50
|
Having said that, a CodeDOM like in .NET where you can pre-analyse code to see what it needs and modify it (annotations/interfaces/mixins) is pretty much what we need. At least for the MC. General AOP has more requirements. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876142#3876142 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876142 |
1965 messages has been excluded from this view by a project administrator.
