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: mikezzz <nu...@jb...> - 2005-06-27 19:33:03
|
I tried that (bundling the commons-collections.jar in the mail.ear file), but it didn't seem to work. It would still throw a NoClassDefFoundError (albeit on a different class). It try it again and see if I can work out. Mike. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882889#3882889 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882889 |
|
From: bendis <nu...@jb...> - 2005-06-27 19:08:54
|
Hi! @RemoteBinding annotation solves this problem, but IMHO very badly. IP addresses, ports etc. should *not* be directly in the Java code of beans! What if I move some beans to JBoss behind firewall? What if I change the port number? I must edit and recompile *every* EJB. Specifying the adrress using this annotation is like hard-coding JDBC URLs directly into Java code! This information should be stored somewhere in the JBoss configuration... And it is - the clientConnectAddress and clientConnectPort attributes in ejb3.deployer/META-INF/jboss-service.xml (see the post above). But EJB3.0 silently ignores this information and uses hard-coded default socket://0.0.0.0:3873 - unless specified by @RemoteBinding. My opinion is that @RemoteBinding annotation should have no clientBindUrl attribute. Instead, there should be some attribute which would refer to some specific org.jboss.remoting.transport.Connector MBean configuration. What is your opinion? I consider @RemoteBinding.clientBindUrl as a serious design flaw - should I file a bug? Regards, Bendis View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882887#3882887 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882887 |
|
From: <aco...@jb...> - 2005-06-27 18:25:43
|
One more twist. If "localhost" and "localhost.localdomain" and "localdomain" are ALL in the local domain list then I should be able to set any of "test@localhost" or "test@localhost.localdomain" or "test@localdomain" as the from address. Does that make sense? -Andy View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882884#3882884 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882884 |
|
From: <aco...@jb...> - 2005-06-27 18:22:40
|
Why not just include the hibernate dependencies in the jbmail distro? Then we can make this easy. BTW, I'm dumping cheese for izpack (TODO). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882883#3882883 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882883 |
|
From: <aco...@jb...> - 2005-06-27 18:21:28
|
Yes. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882882#3882882 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882882 |
|
From: comodi <nu...@jb...> - 2005-06-27 16:35:06
|
In a mixed architecture (here an example):
[HostA, HostB are Jboss instance on separated machine and Part1, Part2, Part3 are Jboss defined partitions]
HostA: member of Part1 and Part2
HostB: member of Part1 and Part3
How can HostA leave Part2 and join Part3?
Is there a not-standard way to define partitions?
Here an example of Part1 configuration file:
|
| <server>
| <classpath codebase="lib" archives="jbossha.jar"/>
|
| <mbean code="org.jboss.ha.framework.server.ClusterPartition"
| name="jboss:service=Part1Partition">
|
| <!-- Name of the partition being built -->
| <attribute name="PartitionName">Part1Partition</attribute>
| <!-- The address used to determine the node name -->
| <attribute name="NodeAddress">${jboss.bind.address}</attribute>
| <!-- Determine if deadlock detection is enabled -->
| <attribute name="DeadlockDetection">False</attribute>
|
| <!-- Time in milliseconds to wait for state to be transferred -->
| <attribute name="StateTransferTimeout">60000</attribute>
|
| <!-- The JGroups protocol configuration -->
| <attribute name="PartitionConfig">
| <Config>
|
| <UDP mcast_addr="228.1.2.5" mcast_port="45569" bind_addr="192.168.20.102"
| ip_ttl="32" ip_mcast="true"
| mcast_send_buf_size="800000" mcast_recv_buf_size="150000"
| ucast_send_buf_size="800000" ucast_recv_buf_size="150000"
| loopback="true" />
| <PING timeout="2000" num_initial_members="3"
| up_thread="true" down_thread="true" />
| <MERGE2 min_interval="10000" max_interval="20000" />
| <FD shun="true" up_thread="true" down_thread="true"
| timeout="2500" max_tries="5" />
| <VERIFY_SUSPECT timeout="3000" num_msgs="3"
| up_thread="true" down_thread="true" />
| <pbcast.NAKACK gc_lag="50" retransmit_timeout="300,600,1200,2400,4800"
| max_xmit_size="8192"
| up_thread="true" down_thread="true" />
| <UNICAST timeout="300,600,1200,2400,4800" window_size="100" min_threshold="10"
| down_thread="true" />
| <pbcast.STABLE desired_avg_gossip="20000"
| up_thread="true" down_thread="true" />
| <FRAG frag_size="8192"
| down_thread="true" up_thread="true" />
| <pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
| shun="true" print_local_addr="true" />
| <pbcast.STATE_TRANSFER up_thread="true" down_thread="true" />
| </Config>
| </attribute>
|
| </mbean>
| </server>
|
|
Thanks for collaboration! :-)
L.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882868#3882868
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882868
|
|
From: studie <nu...@jb...> - 2005-06-27 14:47:22
|
BTTT, has anyone manged to get any of this role / permission stuff working?. Thanks, Stuart View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882853#3882853 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882853 |
|
From: <ad...@jb...> - 2005-06-27 14:35:33
|
Rhetorical question. Also, can we stop dumping everything in org.jboss.system/deployment? System is for the core kernel, not for every possible helper class that uses system and deployment. The helper classes should be written to the system api not digging around in implementation details. I know we don't have a project that for helpers except varia which is just another form of dumping ground. This whole dependency on implementation thing is getting way out of hand. It is going to be impossible to change a single line of code soon without breaking backwards compatibility. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882850#3882850 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882850 |
|
From: <ad...@jb...> - 2005-06-27 14:31:34
|
My objections to this still stand to this. This is not something I want to support going forward in this format. 1) How does it cope with class redeployment of the interceptor, who holds the state? 2) The lifecycle is wrong since the interceptor waits for the service, thus potentially missing some deployments: | <depends-list optional-attribute-name="Interceptables"> | <depends-list-element>jboss.ejb:service=EJBDeployer</depends-list-element> | <depends-list-element>jboss.ejb3:service=EJB3Deployer</depends-list-element> | <depends-list-element>jboss.web:service=WebServer</depends-list-element> | </depends-list> | 3) When it is late bound how does it intercept previous deployments? 4) When the interceptor is unbound does it "unintercept" 5) How does this play with the already overly compliated (and broken) deployer/subdeployment lifecycle. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882849#3882849 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882849 |
|
From: mikezzz <nu...@jb...> - 2005-06-27 14:25:45
|
Sounds good. Attach the patch to the task in JIRA. Cheers, Mike. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882848#3882848 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882848 |
|
From: <dim...@jb...> - 2005-06-27 14:11:43
|
So the ability to dynamically attach jmx interceptors to any XBeans in general, and a set of SubDeployers in particular, exists both in 4.x.(3) and HEAD. The EJB, EJB3, and Web Deployes can be currently intercepted, (i.e. they've been XMBea-nized, with the DynamicInterceptor attached) but we may do the same for any subdeployer. Note, this is standard xmbean stuff, it's not related to jboss aop. This feature is already used in HEAD for the new WebService subdeployers, that can attach dynamically, do their own thing and fail a deployment if something goes wrong with the webservices part of the deployment. There is also an older prototyped LoginConfigInterceptor that detects the presence of a META-IN/login-config.xml and creates/destroys a security domain upon deployment, undeployment (although this needs work when dealing with multiple/nested login-config.xml descriptors>) Except for WebServices, this feature should be useful to the JBoss Portal deployer. We could also try to process custom log4j.xml descriptors? You can read about it here: http://wiki.jboss.org/wiki/Wiki.jsp?page=SubDeployerInterceptorSupport http://wiki.jboss.org/wiki/Wiki.jsp?page=InterceptorServiceMBeanSupport http://wiki.jboss.org/wiki/Wiki.jsp?page=DynamicInterceptor A related forum posting is this: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=57296&postdays=0&postorder=asc&start=0 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882846#3882846 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882846 |
|
From: <kab...@jb...> - 2005-06-27 10:19:37
|
Download jboss aop 1.3 and install in your version of JBoss. I am not 100% sure if this will work, so if you can download the JBoss 4.0.3 release candidate. Having done that refer to sections 10.3.2 and 10.3.3 depending on what JDK you are using for how to enable the class loading hooks. Note that in the latest version of JBoss AOP the attribute on the AspectManager service has been changed to EnableLoadtimeWeaving. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882826#3882826 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882826 |
|
From: javierpena <nu...@jb...> - 2005-06-27 05:23:14
|
I'm having the same exception as rakeshtl had before and looks like some other people in this forum also getting same problem. I modified the JBossDukesBank example that comes with the J2EE tutorial to use RMI/IIOP. The example works fine when not using IIOP. I did everything that is mentioned in the http://www.jboss.org/developers/projects/jboss/IIOP document as far as modifing the jboss.xml file in the dd/ejb directory and changing the jndi.properties file in the dd/client directory. I tried several things for the java.naming.provider.url property in the jndi.properties. I tried using the corbaloc address with localhost, 127.0.0.1, 10.0.1.2 with no luck. I even tried without a corbaloc address and just the IOR string with the bunch of hex digits that JBoss server shows in the console and still didn't work. I'm using JBoss 4.0.2 and Java 1.4.2 on MacOS X Tiger for the client and the server. I'm actually running the java client on the same machine as the server. Here's my jndi.properties file # For IIOP client communication java.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory #java.naming.provider.url=corbaloc::127.0.0.1:3528/JBoss/Naming/root java.naming.provider.url=corbaloc::10.0.1.2:3528/JBoss/Naming/root #java.naming.provider.url=corbaloc::localhost:3528/JBoss/Naming/root #java.naming.provider.url=corbaloc::aluminio.local:3528/JBoss/Naming/root #java.naming.provider.url=corbaloc::192.168.1.104:3528/JBoss/Naming/root #java.naming.provider.url=IOR:000000000000002B49444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578744578743A312E3000000000000200000000000000D0000102000000000931302E302E312E3200000DC8000000114A426F73732F4E616D696E672F726F6F74000000000000050000000000000008000000004A414300000000010000001C00000000000100010000000105010001000101090000000105010001000000210000004C000000000000000100000000000000240000001C0000007E00000000000000010000000931302E302E312E3200000DC9000000000000000000000000000000000000000000000000000000000000002000000004000000000000001F0000000400000003000000010000002000000000000000020000002000000004000000000000001F0000000400000003 # Uncomment this out if no IIOP comunication is needed #java.naming.factory.initial=org.jboss.security.jndi.LoginInitialContextFactory #java.naming.provider.url=jnp://localhost:1099 # this was commented out before #org.jnp.interfaces.NamingContextFactory java.naming.factory.url.pkgs=org.jboss.naming.client java.naming.security.principal=200 java.naming.security.credentials=j2ee java.naming.security.protocol=client-login j2ee.clientName=bank-client I also added the java arguments mentioned by Francisco in the previous post so the jboss-build.xml file looks like the following for running the client. <!-- Run the standalone client --> ${java.class.path} <!-- The following vm args are needed for connecting the client via IIOP --> <!-- this was the one added for the bank example --> when I run the java client I get the following exception [java] javax.naming.NameNotFoundException [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0] [java] at com.sun.jndi.cosnaming.ExceptionMapper.mapException(ExceptionMapper.java:44) [java] at com.sun.jndi.cosnaming.CNCtx.callResolve(CNCtx.java:453) [java] at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:492) [java] at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:470) [java] at javax.naming.InitialContext.lookup(InitialContext.java:347) [java] at org.jboss.naming.client.java.javaURLContextFactory$EncContextProxy.invoke(javaURLContextFactory.java:114) [java] at $Proxy0.lookup(Unknown Source) [java] at javax.naming.InitialContext.lookup(InitialContext.java:347) [java] at com.sun.ebank.util.EJBGetter.getCustomerControllerHome(EJBGetter.java:69) [java] at com.sun.ebank.appclient.DataModel.(DataModel.java:126) [java] at com.sun.ebank.appclient.EventHandle.(EventHandle.java:52) [java] at com.sun.ebank.appclient.BankAdmin.main(BankAdmin.java:593) [java] Caused by: org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0 [java] at org.omg.CosNaming.NamingContextPackage.NotFoundHelper.read(NotFoundHelper.java:72) [java] at org.omg.CosNaming._NamingContextStub.resolve(_NamingContextStub.java:251) [java] at com.sun.jndi.cosnaming.CNCtx.callResolve(CNCtx.java:440) [java] ... 10 more Can someone out there show me what I'm doing wrong? I'm stuck with this problem for more than a week and I ran out of options. Could this exception been caused by some security enforced in the bank's example? rakeshtl, if you resolved your problem can you share the solution with me or post it? I will really appreciate it. thanks in advance -Javier View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882796#3882796 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882796 |
|
From: <ovi...@jb...> - 2005-06-27 05:20:23
|
85.61% pass before the alpha release. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882795#3882795 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882795 |
|
From: javierpena <nu...@jb...> - 2005-06-27 04:48:00
|
test View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882792#3882792 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882792 |
|
From: <sco...@jb...> - 2005-06-27 00:03:49
|
I would doubt there is much usage of thie api (maybe by only you), but checking for both properties is not a big deal. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882788#3882788 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882788 |
|
From: dpasiuk <nu...@jb...> - 2005-06-26 22:44:29
|
Link is working again. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882783#3882783 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882783 |
|
From: <ad...@jb...> - 2005-06-26 21:27:47
|
Comment by Scott from the dev list: On Sun, 2005-06-26 at 15:59, Scott M Stark wrote: The jboss-head version was going to be updated to the same org.jboss.xb > as the jbossxb the latest classes in 4.0. The legacy (4.0.2 version) is > what exists in the org.jboss.xml. It could just be easier to refactor > that in head. > > ad...@jb... wrote: > > >Is this just a case of refactoring package names? > > > >In JBoss4 I can see both package names but the org.jboss.xb stuff is more complete > >with some duplication across the packages. > > > >I'm going to see whether I can create a compatibility layer for now > >by making org.jboss.xb classes that extend org.jboss.xml.binding in head. > > > >I'm only going to do enough to get the MC tests working in jboss4. > > > >This is just a temporary solution such that I can get my stuff backported. > > > View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882781#3882781 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882781 |
|
From: <ad...@jb...> - 2005-06-26 20:54:19
|
I've removed Alex as the default assignee for JBossXB in JIRA Otherwise, we don't know what Alex is actually working on. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882778#3882778 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882778 |
|
From: <ad...@jb...> - 2005-06-26 20:27:03
|
Another issue is whether the system properties in Marshaller should be org.jboss.xml or org.jboss.xb I'm going to leave them in org.jboss.xml to be compatible with JBoss4, but we should probably accept both? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882777#3882777 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882777 |
|
From: <ovi...@jb...> - 2005-06-26 20:09:51
|
Tim, Could you please have a look at MessageConsumerTest.testDurableSubscriptionOnlyOneConsumer()? It fails. To me, it seems that a duplicate durable subscription should be detected in ServerSessionDelegate.createConsumerDelegate() but when I added the test there, I noticed that durable.close() doesn't clean up the map properly , so I stopped there. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882775#3882775 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882775 |
|
From: Scott M S. <sco...@jb...> - 2005-06-26 20:00:08
|
The jboss-head version was going to be updated to the same org.jboss.xb as the jbossxb the latest classes in 4.0. The legacy (4.0.2 version) is what exists in the org.jboss.xml. It could just be easier to refactor that in head. ad...@jb... wrote: >Is this just a case of refactoring package names? > >In JBoss4 I can see both package names but the org.jboss.xb stuff is more complete >with some duplication across the packages. > >I'm going to see whether I can create a compatibility layer for now >by making org.jboss.xb classes that extend org.jboss.xml.binding in head. > >I'm only going to do enough to get the MC tests working in jboss4. > >This is just a temporary solution such that I can get my stuff backported. > >View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882768#3882768 > >Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882768 > > -- xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx |
|
From: <ad...@jb...> - 2005-06-26 19:41:43
|
Similarly: XniJBossXBParser.toSaxAttributes() is never used XsdBinder$SharedElements.anyType is set but never used View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882772#3882772 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882772 |
|
From: <ad...@jb...> - 2005-06-26 19:35:04
|
Why does this method do so much work then always return true? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882771#3882771 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882771 |
|
From: <ad...@jb...> - 2005-06-26 19:15:06
|
"ad...@jb..." wrote : | I'm going to see whether I can create a compatibility layer for now | by making org.jboss.xb classes that extend org.jboss.xml.binding in head. | This can't work because the object types created internally are still in the org.jboss.xml package. It will compile, but it gets ClassCastExceptions when I try to downcast at runtime. I'll try to refactor it (and figure out where the package names are referenced in xml, xsd, etc) and if that fails, I'll just do a copy. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882769#3882769 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882769 |
1965 messages has been excluded from this view by a project administrator.
