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: <rya...@jb...> - 2005-04-27 20:07:09
|
I see no reason why we couldn't do this for the 4.0 branch. + create an alias for jboss-4.0 which doesn't include the thirdparty directory (jboss-4.0-repo?) + add jbossas to jboss-4.0, and tag its contents as Branch_4_0. + remove all the jboss components from the jbossbuild.xml so that a synchronize will only download thirdparty components. + add synchronize target to build/build.xml which delegates to jbossas/jbossbuild.xml so that folks just need to: ant synchronize ant build View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875645#3875645 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875645 |
|
From: <ad...@jb...> - 2005-04-27 20:01:51
|
The reason for knowing about the SecurityDomain is a fundamental difference in the deployment strategies of AOP vs MC In AOP if the advice is not deployed it is not included in the stack. If a depdendency of the advice is not deployed you find out after requests are being processed with a runtime exception. In the MC if the advice and its dependencies are not installed the object is not created and the user is told to deploy the missing dependency. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875644#3875644 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875644 |
|
From: <ad...@jb...> - 2005-04-27 19:59:38
|
Ok, let's deal with a fundamental problem first. The MC does not necessarily use a ConstructorJoinPoint. It could use a factory to create the object. See the ConstructorMetaData. The idea of the ClassAdapter was that it would use this as a context for overrides on the object being constructed. The only other mechanism would be to pass the override context under the wire in a thread local. Of course we could disallow factories as a mechanism to construct objects, it certainly is a part of the javabean spec. But this limits the number of object heirarchies that can be deployed using the MC. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875643#3875643 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875643 |
|
From: dlsa <nu...@jb...> - 2005-04-27 18:20:13
|
No I am not. I just wrote some code with this framework, and have not yet run it, so I ended up putting the question here before seeing it happen. I hadn't seen any reference to it in the pdf, so I asked first Next time I'll try before asking. Sorry. Regards View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875636#3875636 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875636 |
|
From: <tom...@jb...> - 2005-04-27 17:56:23
|
The intention of the remoting framework was to provide a generic way of making remote invocations, regardless of transport or data marshalling (only config change required instead of code changes). An example of what you are asking about can be found in org.jboss.mx.remoting.JMXSubsystemInvocationHandler. This class is a JMX subsystem handler which maps the invocations to the proper JMX call. Although it has to have conditional code (just like would have if using a dynamic proxy), it only has to be written once and can change out the protocol over which it is called (http, socket, rmi, etc.) by just making configuration changes, and not code changes. If wanted even more flexibility in your handler, could have a concrete API class that the handler uses reflection to call upon based on the invocation object (would use NameBaseInvocation for this). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875633#3875633 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875633 |
|
From: <tom...@jb...> - 2005-04-27 17:40:33
|
Are you saying that your client does not get the MyException thrown to it when calling the invoke() method? It should. If it does not, then this is a bug and need to enter a jira issue (http://jira.jboss.com). There is a test case (org.jboss.remoting.exception.server.ServerExceptionTestCase), that test this explicitly as well. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875628#3875628 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875628 |
|
From: dlsa <nu...@jb...> - 2005-04-27 16:20:36
|
Hello, If I have a server side API, with a set of methods, how do I structure the code on the server ? I see it can be done in the following ways: option 1 - create a handler per subsystem, and then put conditional code on the handler to select between the various API calls within that subsystem. option 2 - create a handler per API call and assign a subsystem to it. This way there is no conditional code on the handlers, but there is one for each API call. I prefer the second because there is no conditional code. What did the developers had in mind when they created this framework ? Regards View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875620#3875620 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875620 |
|
From: <cle...@jb...> - 2005-04-27 16:19:53
|
My point is to find a minimal set of tests. For example in webservices, we have about 28 or 27 packages in the testsuite. (I've copied in this message for convenience). Do we need to exercize all of them to make sure the client API works? List of tests in web-services: org.jboss.test.webservice.admindevel org.jboss.test.webservice.attachment org.jboss.test.webservice.contextroot org.jboss.test.webservice.encstyle org.jboss.test.webservice.exception org.jboss.test.webservice.handlerflow org.jboss.test.webservice.header org.jboss.test.webservice.jbas897 org.jboss.test.webservice.jbws124 org.jboss.test.webservice.jbws128 org.jboss.test.webservice.jbws153 org.jboss.test.webservice.jbws64 org.jboss.test.webservice.jbws68 org.jboss.test.webservice.jbws70 org.jboss.test.webservice.jbws71 org.jboss.test.webservice.jbws79 org.jboss.test.webservice.jbws82 org.jboss.test.webservice.jbws83 org.jboss.test.webservice.jbws84 org.jboss.test.webservice.marshalltest org.jboss.test.webservice.message org.jboss.test.webservice.samples org.jboss.test.webservice.samples2 org.jboss.test.webservice.samples2docclient org.jboss.test.webservice.version org.jboss.test.webservice.ws4eesimple org.jboss.test.webservice.wsdlimport View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875619#3875619 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875619 |
|
From: dlsa <nu...@jb...> - 2005-04-27 16:04:54
|
On the implementation of a ServerInvocationHandler.invoke method :
public Object invoke(InvocationRequest request) throws Throwable {
try {
myObject.doSomething();
} catch (Exception e) {
throw new MyException(e.getMessage());
}
}
On the client:
...
InvokerLocator locator = new InvokerLocator(url);
Client aClient = new Client(locator);
aClient.connect();
...
try {
aClient.invoke("argument to doSomething");
} catch (MyException e) {
e.printStackTrace();
}
...
The exception MyException is thrown on the server and is caught on the client. It is propagated through the network by the remoting framework.
Hope it carified.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875615#3875615
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875615
|
|
From: <sco...@jb...> - 2005-04-27 15:37:27
|
Myfaces is now integrated under the jbossweb-tomcat55.sar/jsf-libs dir in the 4.0 branch and the jsf integration test is passing. Try out any other jsf examples you might have. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875613#3875613 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875613 |
|
From: reverbel <nu...@jb...> - 2005-04-27 15:16:40
|
"sco...@jb..." wrote : You are arguing for a transaction remoting module that combines the transaction and remoting codebases. This would be very easy to do, it is mostly a jar packaging decision. Right now the IIOP/OTS access to the core TM is already in the iiop module. We could do the same for the JBoss-remoting access to the TM, i.e., move org.jboss.tm.remoting to remoting module. The interfaces currently in org.jboss.tm.remoting.interfaces would remain in the transaction module. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875607#3875607 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875607 |
|
From: reverbel <nu...@jb...> - 2005-04-27 15:00:10
|
"ad...@jb..." wrote : In fact, the transaciton module needs to splitting up to separate the interfaces that define | the integartion points and the real implementations. And the rest of JBoss should | just use the interfaces/not the implementation. Yes. At some point I want to make TransactionImpl implement a new interface org.jboss.transaction.TransactionBranch (or something like that), which would extend javax.transaction.Transaction. A similar thing would be done with the TxManager class. The new interfaces would express more clearly the contract between the core TM and the rest of the world, including the remote access providers to it. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875605#3875605 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875605 |
|
From: reverbel <nu...@jb...> - 2005-04-27 14:49:46
|
"ad...@jb..." wrote : The transaction manager module exists independently of remote access or its | implementation details. Yes and no. Yes, the core transaction manager should not depend on implementation details of modules that provide remote access to it. The code in CVS satisfies this requirement. The transaction module should still compile if you delete everything under tm/remoting but the subdir tm/remoting/interfaces. No, the transaction manager must be aware of remote access, as it must know a set of interfaces implemented by remote access providers. It must keep references to remote resources (which implement a Resource interface), a reference to a parent coordinator (which implement a Coordinator interface), etc. It must call methods on remote Resource and Coordinator objects at appropriate times. Remote access interfaces currently live in org.jboss.tm.remoting.interfaces. Two remote access providers implement those interfaces: a remote access provider based on JBoss remoting and dynamic proxies, which consists of the remaining classes under tm/remoting, and an IIOP/OTS-based one, which lives in org.jboss.tm.iiop (in the iiop module). Perhaps you are simply saying that the code in org.jboss.tm.remoting.interfaces should be moved to another Java package? (I have actually considered creating a new package org.jboss.transaction, which would contain interfaces implemented either by the core TM or by remote access providers.) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875601#3875601 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875601 |
|
From: kharesam <nu...@jb...> - 2005-04-27 14:26:53
|
Hi, This is regarding the automatic primary key generation of primary keys for entity beans that have relationship with another entity bean in JBoss. Problem Statement:: ------------------- We are using JBoss 4.0.1SP1 for our application. In this application we have two EntityBeans, TestUser and TestFT. There is a Unidirectional, many to one relationship from TestFT to TestUser. Both these beans have auto-generated primary keys (We are using Sybase database). Now when we try to create an instance of TestFT, we get the following Exception: javax.ejb.CreateException: Primary key for created instance is null. at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.createEntity(JDBCStoreManager.java:574) at org.jboss.ejb.plugins.CMPPersistenceManager.createEntity(CMPPersistenceManager.java:222) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.createEntity(CachedConnectionInterceptor.java:266) at org.jboss.ejb.EntityContainer.createHome(EntityContainer.java:766) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.invocation.Invocation.performCall(Invocation.java:345) at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1113) at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:90) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:192) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:212) at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:90) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:117) at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:61) at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:28) at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:41) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:109) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:313) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:126) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:99) at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:121) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:93) at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:508) at org.jboss.ejb.Container.invoke(Container.java:891) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:144) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642) at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:805) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:406) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Unknown Source) at sun.rmi.transport.StreamRemoteCall.executeCall(Unknown Source) at sun.rmi.server.UnicastRef.invoke(Unknown Source) at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source) at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:118) at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:163) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:103) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55) at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:169) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:91) at $Proxy2.create(Unknown Source) at test.TestClient.main(Unknown Source) Tables corresponding to the above two beans are : TestFT: TransactionData(transactionId INTEGER IDENTITY PRIMARY KEY, userId INTEGER, UpdateTimestamp TIMESTAMP) TestUser: UserData ( userId INTEGER IDENTITY PRIMARY KEY, fullName VARCHAR(60), accountStatus VARCHAR (30) not null, statuschangeddate datetime default getdate() not null) The userId in TestFT refers to the userId of TestUser. NOTE:- We have successfully tested the primary key generation feature for Sybase on JBoss for beans that dont have any CMR mappings. It's only when we use CMR that this problem occurs. The Deployment Descriptors are given below: ######################################################################################################################### Ejb-jar.xml ========================================================================================================================= <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd"> <ejb-jar > <![CDATA[No Description.]]> <display-name>Generated by XDoclet</display-name> <enterprise-beans> <!-- Entity Beans --> <![CDATA[]]> <display-name>TestFT</display-name> <ejb-name>TestFT</ejb-name> com.ilts.abs.ejb.entity.TestFTHome com.ilts.abs.ejb.entity.TestFT <ejb-class>com.ilts.abs.ejb.entity.TestFTCMP</ejb-class> <persistence-type>Container</persistence-type> <prim-key-class>java.lang.Integer</prim-key-class> False <cmp-version>2.x</cmp-version> <abstract-schema-name>TestFT</abstract-schema-name> <cmp-field > <![CDATA[]]> <field-name>transactionId</field-name> </cmp-field> <cmp-field > <![CDATA[]]> <field-name>updateTimestamp</field-name> </cmp-field> <primkey-field>transactionId</primkey-field> <!-- Write a file named ejb-finders-TestFTBean.xml if you want to define extra finders. --> <![CDATA[]]> <display-name>TestUser</display-name> <ejb-name>TestUser</ejb-name> com.ilts.abs.ejb.entity.TestUserHome com.ilts.abs.ejb.entity.TestUser <ejb-class>com.ilts.abs.ejb.entity.TestUserCMP</ejb-class> <persistence-type>Container</persistence-type> <prim-key-class>java.lang.Integer</prim-key-class> False <cmp-version>2.x</cmp-version> <abstract-schema-name>TestUser</abstract-schema-name> <cmp-field > <![CDATA[]]> <field-name>userId</field-name> </cmp-field> <cmp-field > <![CDATA[]]> <field-name>fullName</field-name> </cmp-field> <cmp-field > <![CDATA[]]> <field-name>accountStatus</field-name> </cmp-field> <cmp-field > <![CDATA[]]> <field-name>statusChangedDate</field-name> </cmp-field> <primkey-field>userId</primkey-field> <!-- Write a file named ejb-finders-TestUserBean.xml if you want to define extra finders. --> <!-- To add entity beans that you have deployment descriptor info for, add a file to your XDoclet merge directory called entity-beans.xml that contains the markup for those beans. --> <!-- Message Driven Beans --> <!-- To add message driven beans that you have deployment descriptor info for, add a file to your XDoclet merge directory called message-driven-beans.xml that contains the <message-driven></message-driven> markup for those beans. --> </enterprise-beans> <!-- Relationships --> <ejb-relation > <ejb-relation-name>User-Funds</ejb-relation-name> <ejb-relationship-role > <ejb-relationship-role-name>FundsTransactions-of-User</ejb-relationship-role-name> Many <relationship-role-source > <ejb-name>TestFT</ejb-name> </relationship-role-source> <cmr-field > <cmr-field-name>user</cmr-field-name> </cmr-field> </ejb-relationship-role> <ejb-relationship-role > <ejb-relationship-role-name>User-performs-FundsTransactions</ejb-relationship-role-name> One <relationship-role-source > <ejb-name>TestUser</ejb-name> </relationship-role-source> </ejb-relationship-role> </ejb-relation> <!-- To add relationships for beans not managed by XDoclet, add a file to your XDoclet merge directory called relationships.xml that contains the <ejb-relation></ejb-relation> markups for those beans. --> <!-- Assembly Descriptor --> <!-- To specify your own assembly descriptor info here, add a file to your XDoclet merge directory called assembly-descriptor.xml that contains the <assembly-descriptor></assembly-descriptor> markup. --> <assembly-descriptor > <!-- To specify additional security-role elements, add a file in the merge directory called ejb-security-roles.xml that contains them. --> <!-- method permissions --> <!-- To specify additional method-permission elements, add a file in the merge directory called ejb-method-permissions.ent that contains them. --> <!-- finder permissions --> <!-- finder permissions --> <!-- finder permissions --> <!-- finder permissions --> <!-- finder permissions --> <!-- finder permissions --> <!-- finder permissions --> <!-- finder permissions --> <!-- finder permissions --> <!-- finder permissions --> <!-- transactions --> <!-- To specify additional container-transaction elements, add a file in the merge directory called ejb-container-transaction.ent that contains them. --> <!-- finder transactions --> <!-- To specify an exclude-list element, add a file in the merge directory called ejb-exclude-list.xml that contains it. --> </assembly-descriptor> </ejb-jar> ######################################################################################################################### jboss.xml ========================================================================================================================= <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE jboss PUBLIC "-//JBoss//DTD JBOSS 4.0//EN" "http://www.jboss.org/j2ee/dtd/jboss_4_0.dtd"> <enterprise-beans> <!-- To add beans that you have deployment descriptor info for, add a file to your XDoclet merge directory called jboss-beans.xml that contains the , and <message-driven></message-driven> markup for those beans. --> <ejb-name>TestFT</ejb-name> <jndi-name>abs.TestFT</jndi-name> <configuration-name>INSERT AFTER EJB_POST_CREATE CMP 2.x EntityBean</configuration-name> <method-attributes> </method-attributes> <ejb-name>TestUser</ejb-name> <jndi-name>abs.TestUser</jndi-name> <method-attributes> </method-attributes> </enterprise-beans> <resource-managers> </resource-managers> <container-configurations> <container-configuration> <container-name>BeanOptimisticLocking</container-name> <call-logging>false</call-logging> <invoker-proxy-binding-name>entity-rmi-invoker</invoker-proxy-binding-name> <sync-on-commit-only>false</sync-on-commit-only> <insert-after-ejb-post-create>true</insert-after-ejb-post-create> <call-ejb-store-on-clean>true</call-ejb-store-on-clean> <container-interceptors> org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor org.jboss.ejb.plugins.LogInterceptor org.jboss.ejb.plugins.SecurityInterceptor org.jboss.ejb.plugins.TxInterceptorCMT org.jboss.ejb.plugins.CallValidationInterceptor org.jboss.ejb.plugins.MetricsInterceptor org.jboss.ejb.plugins.EntityCreationInterceptor org.jboss.ejb.plugins.EntityLockInterceptor org.jboss.ejb.plugins.EntityInstanceInterceptor org.jboss.ejb.plugins.EntityReentranceInterceptor org.jboss.resource.connectionmanager.CachedConnectionInterceptor org.jboss.ejb.plugins.EntitySynchronizationInterceptor org.jboss.ejb.plugins.cmp.jdbc.JDBCRelationInterceptor </container-interceptors> <instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool> <instance-cache>org.jboss.ejb.plugins.InvalidableEntityInstanceCache</instance-cache> <persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</persistence-manager> <locking-policy>org.jboss.ejb.plugins.lock.JDBCOptimisticLock</locking-policy> <container-cache-conf> <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy> <cache-policy-conf> <min-capacity>50</min-capacity> <max-capacity>1000000</max-capacity> <overager-period>300</overager-period> <max-bean-age>600</max-bean-age> <resizer-period>400</resizer-period> <max-cache-miss-period>60</max-cache-miss-period> <min-cache-miss-period>1</min-cache-miss-period> <cache-load-factor>0.75</cache-load-factor> </cache-policy-conf> </container-cache-conf> <container-pool-conf> 100 </container-pool-conf> <commit-option>B</commit-option> </container-configuration> <container-configuration> <container-name>INSERT AFTER EJB_POST_CREATE CMP 2.x EntityBean</container-name> <call-logging>false</call-logging> <invoker-proxy-binding-name>entity-rmi-invoker</invoker-proxy-binding-name> <sync-on-commit-only>false</sync-on-commit-only> <insert-after-ejb-post-create>true</insert-after-ejb-post-create> <call-ejb-store-on-clean>true</call-ejb-store-on-clean> <container-interceptors> org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor org.jboss.ejb.plugins.LogInterceptor org.jboss.ejb.plugins.SecurityInterceptor org.jboss.ejb.plugins.TxInterceptorCMT org.jboss.ejb.plugins.CallValidationInterceptor org.jboss.ejb.plugins.MetricsInterceptor org.jboss.ejb.plugins.EntityCreationInterceptor org.jboss.ejb.plugins.EntityLockInterceptor org.jboss.ejb.plugins.EntityInstanceInterceptor org.jboss.ejb.plugins.EntityReentranceInterceptor org.jboss.resource.connectionmanager.CachedConnectionInterceptor org.jboss.ejb.plugins.EntitySynchronizationInterceptor org.jboss.ejb.plugins.cmp.jdbc.JDBCRelationInterceptor </container-interceptors> <instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool> <instance-cache>org.jboss.ejb.plugins.InvalidableEntityInstanceCache</instance-cache> <persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</persistence-manager> <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy> <container-cache-conf> <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy> <cache-policy-conf> <min-capacity>50</min-capacity> <max-capacity>1000000</max-capacity> <overager-period>300</overager-period> <max-bean-age>600</max-bean-age> <resizer-period>400</resizer-period> <max-cache-miss-period>60</max-cache-miss-period> <min-cache-miss-period>1</min-cache-miss-period> <cache-load-factor>0.75</cache-load-factor> </cache-policy-conf> </container-cache-conf> <container-pool-conf> 100 </container-pool-conf> <commit-option>B</commit-option> </container-configuration> </container-configurations> ######################################################################################################################### jbosscmp-jdbc.xml ========================================================================================================================= <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE jbosscmp-jdbc PUBLIC "-//JBoss//DTD JBOSSCMP-JDBC 4.0//EN" "http://www.jboss.org/j2ee/dtd/jbosscmp-jdbc_4_0.dtd"> <jbosscmp-jdbc> java:/sybaseDataSource <datasource-mapping>Sybase</datasource-mapping> <preferred-relation-mapping>foreign-key</preferred-relation-mapping> <enterprise-beans> <!-- To add beans that you have deployment descriptor info for, add a file to your XDoclet merge directory called jbosscmp-jdbc-beans.xml that contains the markup for those beans. --> <ejb-name>TestFT</ejb-name> <table-name>TransactionData</table-name> <cmp-field> <field-name>transactionId</field-name> <column-name>transactionId</column-name> </cmp-field> <cmp-field> <field-name>updateTimestamp</field-name> <column-name>UpdateTimestamp</column-name> </cmp-field> <unknown-pk> <unknown-pk-class>java.lang.Integer</unknown-pk-class> <column-name>transactionId</column-name> <jdbc-type>INTEGER</jdbc-type> <sql-type>INTEGER</sql-type> </unknown-pk> <entity-command name="sybase-fetch-key" class="org.jboss.ejb.plugins.cmp.jdbc.keygen.JDBCSybaseCreateCommand"> SELECT @@IDENTITY </entity-command> <!-- jboss 3.2 features --> <!-- optimistic locking does not express the exclusions needed --> <ejb-name>TestUser</ejb-name> <table-name>UserData</table-name> <cmp-field> <field-name>userId</field-name> <column-name>userId</column-name> </cmp-field> <cmp-field> <field-name>fullName</field-name> <column-name>fullName</column-name> </cmp-field> <cmp-field> <field-name>accountStatus</field-name> <column-name>accountStatus</column-name> </cmp-field> <cmp-field> <field-name>statusChangedDate</field-name> <column-name>StatusChangedDate</column-name> </cmp-field> <unknown-pk> <unknown-pk-class>java.lang.Integer</unknown-pk-class> <column-name>userId</column-name> <jdbc-type>INTEGER</jdbc-type> <sql-type>INTEGER</sql-type> </unknown-pk> <entity-command name="sybase-fetch-key" class="org.jboss.ejb.plugins.cmp.jdbc.keygen.JDBCSybaseCreateCommand"> SELECT @@IDENTITY </entity-command> <!-- jboss 3.2 features --> <!-- optimistic locking does not express the exclusions needed --> </enterprise-beans> <ejb-relation> <ejb-relation-name>User-Funds</ejb-relation-name> <foreign-key-mapping/> <ejb-relationship-role> <ejb-relationship-role-name>FundsTransactions-of-User</ejb-relationship-role-name> <fk-constraint>true</fk-constraint> <key-fields/> </ejb-relationship-role> <ejb-relationship-role> <ejb-relationship-role-name>User-performs-FundsTransactions</ejb-relationship-role-name> <key-fields> <key-field> <field-name>userId</field-name> <column-name>userId</column-name> <jdbc-type>INTEGER</jdbc-type> <sql-type>INTEGER</sql-type> </key-field> </key-fields> </ejb-relationship-role> </ejb-relation> <!-- To add jboss relationships for beans not managed by XDoclet, add a file to your XDoclet merge directory called jbosscmp-jdbc-relationships.xml that contains the <ejb-relation></ejb-relation> markups for those beans. --> </jbosscmp-jdbc> View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875595#3875595 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875595 |
|
From: gavinc <nu...@jb...> - 2005-04-27 12:37:21
|
Thanks for link Julien. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875582#3875582 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875582 |
|
From: liseed <nu...@jb...> - 2005-04-27 10:46:04
|
Hi, Everybody:
I have two application. One works on Tomcat5.5.7 , another works on JBoss3.2.6. I would't use the inside tomcat in JBoss3.2.6. I hope using outside tomcat(tomcat5.5.7).
How can i deploy them?
Thanks in advance
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875567#3875567
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875567
|
|
From: berkhurkan <nu...@jb...> - 2005-04-27 10:21:48
|
berkhurkan View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875564#3875564 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875564 |
|
From: <rya...@jb...> - 2005-04-27 05:09:59
|
The first release of jbossbuild is complete. While there is no released distribution as such, you can try out the new build system by following the directions at: http://docs.jboss.org/process-guide/en/html/build-reference.html#d0e485 Major Features: + Ability to download 3rd party libraries from online build repository + Builds a runnable incomplete distrubtion of JBossAS + Enables declarative builds + Enforces build uniformity Documentation: http://docs.jboss.org/process-guide/en/html/build-reference.htm This includes a tutorial on creating a component build, as well as adding a 3rd party component to the repository. Release Notes: http://jira.jboss.com/jira/secure/ReleaseNote.jspa?projectId=12310081&styleName=Html&version=12310181 Roadmap: http://jira.jboss.com/jira/browse/JBBUILD?report=com.atlassian.jira.plugin.system.project:roadmap-panel View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875537#3875537 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875537 |
|
From: <tom...@jb...> - 2005-04-27 04:41:39
|
I does this currently. Maybe you can clarify your question with an example? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875533#3875533 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875533 |
|
From: <tom...@jb...> - 2005-04-27 03:52:26
|
Andy, you are right about the new AJP connector stuff that Mladen did being very fast (actually faster than NIO). However, it is done using native code, so would have to consider if that would be acceptable for jboss mail. If it is, then don't think you'll find any faster way to do it (and the API is clean and simple), but will make install more complicated. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875530#3875530 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875530 |
|
From: <sco...@jb...> - 2005-04-27 03:01:47
|
jboss-faces.war is useless. It needs to be integrated as a library like everything else. I am doing this right now. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875528#3875528 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875528 |
|
From: <bil...@jb...> - 2005-04-27 02:41:47
|
As far as the requirements goes, with the current code integration I have: 1) Met class-weaved aspect dependency propagation to the MC. Please see the aspect/src/test/.../kernel tests. 2) I have implemented a proxy-based solution that will work with classes that HAVE NOT been implemented with AOP that will create a class-proxy with all interceptors,aspects,annotation overides, and mixins 3) I have implemented a PER BEAN to AOP when you want to add interceptors/aspects/annotation overrides on a per bean basis. Currently I have not tested this yet, but it is only implemented with proxies until I implement the same per-instance API into my bytecode weaver. So, I need to: * write some basic tests for #3 * Implement the refactored per-instance API for AOP. The thing is, having a design meeting in Boston was nice and all, it got things started, but the idea that you can actually define everything up front without writing one line of code is a bit naive. There's going to be changes in the interfaces as you iterate toward the final production release. At first I started going to the path of using ClassInfo's to do all the integration with the Microcontainer and AOP and later decided against this approach. What I found out was: 1) To use ClassInfo's in AOP would require a very large refactoring of JBoss AOP. I started down this path and actually wrote a lot of code, but figured that it would almost totally refactor JBoss AOP before I was able to run one test. I didn't think I could do this in the fragmented time slots I had to work on this with all the other stuff I am responsible for. 2) Using Javassist to create ClassInfo's as discussed in the Boston design meeting was just way too slow. Kernel boottime would just be crippled if we did this. The whole purpose of using Javassist to create ClassInfo's was that we needed to know aspect dependencies before the class had done static initialization because of the way JBoss AOP initialized itself. Using Java reflection to create ClassInfo's is JUST FINE. After some research I found that Java reflection only triggers class static initialization when Class.forName() is called, newInstance(), or a field/method invocation. So using Javassist to create ClassInfos is just pure overhead and not needed. 3) Although I agreed in Boston that per-bean AOP would be done through annotations, i had an issue that MC would be responsible for this. JBoss AOP already has an annotation override facility and there is no reason we cannot reuse this facility. This is why I added a recent changes to ClassAdapter and BeanMetaData (the metadata stuff). The MC is good at creating objects from XML. Might as well take advantage of it rather than creating a bunch of crappy gluecode. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875527#3875527 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875527 |
|
From: <bil...@jb...> - 2005-04-27 02:39:14
|
"ad...@jb..." wrote : I'm confused again. We always seem to be on completely different wavelengths :-) | | 1) I already had a MAP in the original implementation, but changed it to Annotation | since we agreed that all config will come from annotations (as opposed to ad hoc | invocation payload) | THis metadata I added has nothing to do with ad hoc invocation payloads. The metadata is needed by the ClassAdapter to resolve aspect dependencies and for the ConstructorJoinpoint so that it can either create a proxy or modify the object instance's InstanceAdvisor. anonymous wrote : | and this would make it easier for construct/configure from xml. | JBoss AOP already has an annotation override facility. What I added allows MC to take advantage of this facility without also tying MC to this facility. anonymous wrote : | In fact, there is an open issue on whether the MC should just use AOP's annotation | metadata model. | This sure would make things easier. anonymous wrote : | There is even a test in the jboss-aspects module using AbstractAnnotationMetaData: | http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-aspects/src/tests/org/jboss/test/aspects/microcontainer/test/InterceptorTestCase.java?rev=1.1&view=markup | If you want to fully redo what JBoss AOP already does, be my guest, but count me out... anonymous wrote : | Did you know that about FeatureMetaData or even the tasks I created after our Boston | meetings? | http://cvs.sourceforge.net/viewcvs.py/jboss/microkernel/src/main/org/jboss/beans/metadata/plugins/AbstractFeatureMetaData.java?r1=1.4&r2=1.5 | http://jira.jboss.com/jira/browse/JBMICROCONT-18 | Sure saw it, but again, didn't want to rewrite the entire JBoss AOP annotation facility. anonymous wrote : | 2) It is too late to pass this in the join point constructor isn't it? I need to tell JBoss/AOP | about the annotations to find out what they mean in terms of dependencies???? | You mean for dependencies like the SecurityDomain example? I don't see why you need to tell JBoss AOP these dependencies. JBoss AOP doesn't care about dependencies. It really depends on who is analyzing the annotations for the @DependsAttribute annotation (or whatever it will be). If it is the microcontainer, then no, it is not too late as the microcontainer can just add these to the dependency list itself. anonymous wrote : | This cannot be done at the construction stage, it must be done during DESCRIBE. | Otherwise, the MC/AOP integration serves no purpose. | | | | | | /** | | * Get a constructor join point | | * | | * @param constructorInfo the constructor info | | * @param metadata // THIS IS TOO LATE | | * @return the constructor join point | | * @throws JoinpointException when no such constructor | | */ | | ConstructorJoinpoint getConstructorJoinpoint(ConstructorInfo constructorInfo, Map metadata) throws JoinpointException; | | | | Maybe you have simplied this or found a way around the problem? But it | seems pretty fundamental to me? | Did you see that I added passing metadata to ClassAdapter.getDependencies()? getConstructorJoinpoint needs to know about annotation overrides, mixin definitions, etc... because the ConstructorJoinpoint itself needs to know about this information so that it knows wheter or not to create a proxy (if the class is not weaved) or to interact with the per-instance InstanceAdvised interface. If you do not pass in these annotation overrides into the ConstructorJoinpoint, then the ConstructorJoinpoint does not have the exact information it needs to make its decisions. anonymous wrote : | To repeat the only reasons for the reflection model are: | a) I need to be convinced that JBoss/AOP (really javassist) can be used in all environments | THis idea that everything has to work in all environments with the 1st iteration or even the first release of MC, MC+AOP is just stupid. Iterate! I've taken out the Javassist requirement for the MC /AOP integration. I've posted how/why on architecture council email list, I'll repost here. Load-time AOP probably just will not work on all environments. AOPC precompilation should work in all environments because Javassist is take out of the equation. If you have look at my MC/AOP integration code and tests you'll see that it supports a proxy based model. Currently proxies are created by Javassist for performance and flexibility reasons, but this could be changed to be fully java.lang.reflect.Proxy based if you so desire. anonymous wrote : | b) AOP's ClassAdapter wasn't finished but I needed to work on other things | AOP's ClassAdapter is not fully finished. I'll talk about this in another post. anonymous wrote : | If (a) can be satisfied, (i.e. in all circumstances no matter what the security/memory | restrictions are JBoss/AOP/Javasssit can be used) then I don't have any problem | with predecating JBoss/MC on JBoss/AOP and the need for an abstract | integration "ClassAdapter" disappears. (a) cannot uniformily be solved by JBoss AOP unless AOPC precompilation is a requirement. If you dislike AOPC precompilation as a requirement, then you just have to deal with less AOP funtionality and use proxies. JBoss AOP can support this and does partially support it now. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875526#3875526 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875526 |
|
From: <nor...@jb...> - 2005-04-27 01:34:23
|
Setting UseJBossWebLoader to false (a recent change in 4.0.2) makes jboss-faces.war useless. I now have to copy all the JSF JARs to my WEB-INF/lib directory to work. Before this change, I only needed to copy myfaces-impl.jar over to pick up the taglibs. (We have the same problem with the JSTL taglibs - you need jstl.jar in your WEB-INF/lib to pick up the tld for the taglib) How is JSF supposed to work now? It seems jboss-faces.war is useless now. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875523#3875523 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875523 |
|
From: <sco...@jb...> - 2005-04-27 01:09:38
|
Yes, that is what I wanted to test. Any client facing api needs to be tested, so remote ejbs, jms, webservices, jndi, jmx. These all have well defined packages in the testsuite. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875522#3875522 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875522 |
1965 messages has been excluded from this view by a project administrator.
