Mike >Well we arn't using our own classloaders (though I cant rule out that we >will never do that). But the problem can come up any time you pass the >name of a class to another block as a string. If that block tries to >instantiate that class, it wont be able to find it because a different >block can't load classes in another sar's lib directory. > >(let me know if that did not make any sense, im not sure if it made >sense to me) > I makes sense. Phoenix mounts each SAR in a different classloader. One of out pending concerns is how to get them to communicate (long term issue).
For your case, I have to ask - how is SAR1 "speaking" to blocks in SAR2 ? I think you might be pushing some envelopes.... - Paul > > >----------- >Mike Miller >Programmer >General American Corporation >[EMAIL PROTECTED] > >>Dependancies? You are mounting your own classloaders inside your >>phoenix app? That is quite normal. EOB & Jesktop do it. JAMES (I >>guess) does it. FtpServer will for Ftplets another day. If >>yes, I think >>your issues is cause by the constructor for JdbcConnectionFactory not >>having classloader as a parameter. Is that right? >> >>- Paul >> >>>We are having a problem with including the jdbc driver in >>> >>with our sars. >> >>>Basically the classloader avaliable to JdbcConnectionFactory >>> >>cannot read >> >>>the jdbc drivers' Driver class because it is in our application's lib >>>directory. If we put the jdbc driver's jar in the phoenix/lib dir it >>>will be available to all packages and the factory will be able to >>>Class.forName the jdbc driver. Is there a better way to get around >>>this? How do you make a resource included with one application >>>avaliable to it's dependancies? >>> > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
