How can I have objects in second scene be affected by lighting?
One thing comes to mind:

Create the same light source in your second scene (weapons scene) at the same origin, with all properties being the same as the light source in the first scene.

Then save the transformation matrix of your camera from the first scene -> inverse the matrix -> and apply it onto the light source in the second scene.

This way the light source in scene2  will move according to the player movement (camera), and will affect the weapons in the correct way.



Now, to have even more realism, we would want to stop seeing the light affecting the weapon, when the player is outside the direct reach of the light source. The simplest solution would be, casting a ray from the 8 corners of the bounding box (bbox) of the player, towards the desired light source, if any of them gets to the light source without hitting any obstacle on the way (we assume no transparent objects), than some part of the player is still in the light, so we set a flag, like so: bool inLight = true. 
This flag is used in the second scene, and we compute the light affecting the weapon, only if the flag is true...
Now if you like to be even more specific than that you can create a bbox in scene1, in the place where the weapon would be, and do the same procedure. However, I wouldn't bother going into so much detail in a game (keep it lighter), especially in a FPS game.
What I would do to achieve a similar effect for an FPS game is just cast a single ray from some offset from the front of the character (presumably where the weapon would be) and proceed with the check.  



As for the ray-tracing check, in the case that you do not have a space partitioning algorithm (octree, kd-tree, etc), you would have to check the ray, brute force, against all objects (not very nice, especially in a game), so I suggest at least having a Bounding Volume Hierarchy to store the objects in your scene, as that would optimise things, and I strongly recommend using a spacial partitioning algorithm too. However prove that it works first, with the easiest way! Slow and correct is better than quick and wrong! Not always true for games though. ;)