November 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss ESB] - Re: ESB Packaging

by Kevin.Conner＠jboss.com

Hiya Sacha. I agree that the MK can probably provide most of the required functionality but I believe we should be looking further out. We should be aiming the next release at the MC or OSGi frameworks (or even both). I am looking at both of these for a post GA task. You will not find anyone on the ESB team who disagrees with you about componentising the ESB. This is definitely important, especially if we are to obtain the ability to dynamically configure as much of the functionality as possible. As for configuration, ESB currently uses the TS property manager. This does not require the configuration file to be JVM-wide nor does it require the properties to be exposed via System properties. While doing this is possible with the TS property code it is usually not done unless some dependent jar requires it. I do not believe any of the ESB properties are exposed via System properties but I may be wrong. If they are then it should be a quick fix. It should, therefore, be straight forward to repackage the main ear/configuration file into a single exploded sar. Whether these jars can be further componentised at this time is really a question that only Esteban, Daniel, Kurt and Tom can answer. As far as the dependency on AS is concerned, that comment was really targetted at small form devices (such as mobile phones and PDAs) but also extends to other devices. I strongly believe we should be constructing the ESB using small, self contained plugins which remain as neutral as possible to the deployed environment. These plugins could then be combined as needed and, with an appropriate adapter layer, could then execute using the frameworks installed on the devices. If we are able to achieve this then I believe we will see the ESB being used in various configurations and devices which we have yet to consider. Kev View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988609#3988609 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988609

19 years, 4 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Accessing UserModule with MyFaces

by thomas.heute＠jboss.com

Please read the README of the forum. Your questions belong to the user forum, not the developer forum. Moving this topic. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988608#3988608 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988608

19 years, 4 months

1
0
0 / 0

[Design of JBoss Portal] - Re: missing required library ..thirdparty\jbossas..

by thomas.heute＠jboss.com

This question clearly belongs to the user forum not the developer forum. I already answered that question there. I'm moving this topic. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988606#3988606 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988606

19 years, 4 months

1
0
0 / 0

[Design of JBoss Portal] - Re: missing required library ..thirdparty\jbossas..

by chris.laprun＠jboss.com

Build Portal once with ant... The first time the script is run, thirdparty is created and the appropriate jar files are downloaded. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988603#3988603 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988603

19 years, 4 months

1
0
0 / 0

[Design of JBoss Portal] - missing required library ..thirdparty\jbossas..

by spomytki

it's probably lame and/or unimportant question but I wasn't able to resolve it in 5 min. so, it might worth posting.. I'm trying to build portal server v. 2.6 from sources I got JBossIDE for Eclipse Version: 2.0.0 (Build id: 2.0.0.Beta2) downloaded jboss-portal-2.6.0-DR1-src installed SVN plug in and attempted to import anonymous-projectSet.psf from jboss-portal-2.6.0-DR1-src\build\ide\eclipse\3.2\team it went fine except projects failed to compile cause they all depend on bunch of libraries from third-party folder (missing in src archive) hence failing with errors like Project bridge is missing required library: '\thirdparty\jbossas\core-libs\lib\jboss-common.jar' Question - is there any easier way to obtain all of this jars then just hunting them one by one, crossing fingers I got right version? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988599#3988599 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988599

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: TODO: RAR metadata repository

by weston.price＠jboss.com

More If we got rid of | org.jboss.resource.connectionmanager.RARDeployment | and replaced it with an updated version, say something more appropriate like ManagedConnectionFactoryDeployment we could pass more deployment hints as to the underlying metadata (transaction support, reauthentication support etc). Since we now have 3 classes named RARDeployment, this might not be such a bad thing ;-). Plus, he was always a bit sketchy to being with. Not sure why we ever exposed him as a ManagedConnectionFactory since a majority of those methods are useless from a management perspective. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988592#3988592 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988592

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: TODO: RAR metadata repository

by weston.price＠jboss.com

Also, in looking at | org.jboss.resource.metadata.ConnectorMetaData | the | org.jboss.resource.metadata.TransactionSupportMetaData | is found at the ConnectorMetaData level. I would actually expect this to be hanging of the ConnectionDefinitionMetaData as it is only applicable to outbound connection factories. Was this done this way for a reason or did it just slip through? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988591#3988591 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988591

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: TODO: RAR metadata repository

by weston.price＠jboss.com

Because the new *-dsx.xml deployment work could really benefit from something like this I started thinking about it and implementing a simple prototype. Right now the JcaMetaDataRepository is pretty basic with an internal HashMap() and a set of JcaMetaDataRepostoryKeys. Each key corresponds to a particual type of RAR deployment object OutBoundConnectionFactory MessageListener AdminObject However, the problem quickly becomes apparent in trying to do a 'match'. Our JDBC RAR(s) have the same connection definition (javax.sql.DataSource), and it doesn't take much to come up with a pretty trivial example of a message listener conflict (say jms-ra.rar and another JMS providers' RAR both supporting javax.jms.MessageListener). The ra.xml metadata is not the problem, its the limited amount of knowledge the XDeployment types have about their target environment. RARDeployment (the old guy in connectionmanager) simply has the connection defintion and that's about it everything else known is driven on the ConnectorMetaData fetched using the oldRarDeployment name. The EJB(X) deployer has just as limited amount of information in the form of the messageType. Of course we don't want to start forcing more that we have to in the *-ds.xml/*-dsx.xml because at that point, sticking with the oldRarDeployment hack starts to look better and better. On the ConnectionFactory side, we could add an attribute to the RARDeployment, say, transaction support and that would narrow it down some. The message listener and the admin object are still problematic. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988590#3988590 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988590

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Zero turnaround Java/JBoss

by gavin.king＠jboss.com

What is most urgently needed is: (1) the ability to efficiently "redeploy", under the assumption that the metamodel has not changed. So the internal implementation of the components might have changed, but there is no reason to actually restart the EJB container and the webapp. (2) the ability to do this without losing the state of existing SFSB instances and the HttpSession. The slowest part of the compile-deploy-test cycle today is logging back into the application and getting to the page you want to test. anonymous wrote : I'm pretty sure that a schema change to a .class file will generate a different SerialVersionUUID for default serialization. So, we would need to use JBoss Serialization to ignore version id mismatches. Or just tell the user to add a serialVersionUID to their classes. Easy, I don't see them minding that. For SFSBs, we could probably do it for them. anonymous wrote : I don't know if a schema change (an additional field added) would break the serialized HTTP Session/SFSB Session on deserialization. Changing (adding/removing) a non-transient field definitely would break standard Java serialization, but there is no reason for it to need to break JBoss serialization, since there is an incredibly natural and trivial way you can define this: (1) if a field has been added, set it to Java language default (2) if a field has been removed, throw away its state (3) if the field type has changed, try to typecase This is of course what dynamic languages do in the same situation. anonymous wrote : Because of both of these problems, I think just using the IDE to do non-schema code changes during and within a test run is good enough. This is definitely not true. The problem with using IDEs and HotSwap to debug JBoss is that as soon as a single schema change occurs, HotSwap stops working until you restart the whole JBoss process. Redeploying the webapp is NOT enough to get HotSwap working again, because the IDE does not see that as a class reload. Try this in eclipse. As soon as you make one single schema change to any class, HotSwap is hosed until you restart JBoss. Of course, this is totally crap, but that tells you how crap HotSwap is. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988587#3988587 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988587

19 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: ESB Packaging

by sacha.labourey＠jboss.com

Hello Kevin, For what's needed at this point, the current MK can probably provide you with everything that is necessary for clean redeploys. Concerning the reliance on the AS, that is pretty obvious, yes. I can provide you with a minimal distro of the AS (or scripts to setup one for the ESB) if needed, that's pretty easy. The current setup is fine to test the ESB behaviour but not as a final distribution mechanism (it is way to overloaded). Same for the minimal/all distributions, we probably don't need them for the OS => the final ESB distrib will most probably be much smaller than the OS one. Finally, I think it would be a mistake not to properly componentize the ESB in services with proper packaging /configuration for the GA: that would make it much more difficult to setup and understand. Also, many JBoss AS users would find it *trivial* to use the ESB if it had a similar look-n-feel-n-configure. However, if they face an AS distribution with static JARs inside an EAR and JVM-wide configuration files available as System Properties, I bet the experience will not be the same at all. That won't help MarkL's 30 minutes criteria ;) Cheers, Sacha View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988571#3988571 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988571

19 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2006